Exercise 2: Finding a Rare Intermittent 500 Error — Possible Solution
====================================================================

Explanation:

Traces are the pillar that most directly helps here. A 500 error
happening once every few hundred attempts is, by definition, a
single-request problem -- something specific to that one request's own
path through the system, not a general trend. A trace captures exactly
that: the full path one specific request took across every service it
touched, with timing and outcome for each hop, letting you follow that
one failing request end to end and see precisely which service in the
chain actually produced the error.

Metrics alone wouldn't be enough -- a failure rate of roughly 1 in a
few hundred requests would barely register as a blip in an aggregated
error-rate graph, and even if it did show up, a metric only tells you
THAT errors are happening at some rate, never which individual request
failed or why.

Logs alone wouldn't be enough either, for a related reason: logs are
per-service and per-event, so unless every relevant service is
logging with a shared correlation ID AND you already know to go
looking at the right few seconds across the right several services,
you'd have no way to reliably connect "this log line in service A" to
"this log line in service B" as belonging to the same one failing
request out of hundreds of successful ones happening at the same time.

WHY THIS WORKS AS AN ANSWER
------------------------------
This identifies traces as the correct pillar specifically because the
problem described is a single-request failure rather than a general
trend, then explains concretely why metrics (too aggregated) and logs
alone (too hard to correlate without a trace to tie them together)
each fall short on their own for this exact scenario.