When would you reach for a distributed trace rather than a metric or a log?

Metrics tell you something is wrong and roughly where. Logs tell you what happened inside one process. Traces tell you where the time went across services for a single request. Reach for a trace when latency is high but no individual service looks unhealthy, or when a request crosses many hops. Metrics are cheap and aggregate, logs are detailed and expensive, traces are sampled and relational.

I think of it as three questions. Metrics answer is it broken and how badly, logs answer what happened in this one process, and traces answer where did the time go across the whole request. The moment I reach for a trace is when the overall latency is up but every individual service dashboard looks fine, which almost always means the time is in a hop nobody owns. That happened to us with a service mesh sidecar adding retries we did not know about; the trace made it obvious in about a minute because we could see three identical spans nested under one call. The practical glue is putting trace and span ids into every log line, so you can jump from an aggregate metric to a slow exemplar trace to the exact log lines for that request. And I would sample traces head based at a low rate with tail based sampling for errors and slow requests, because keeping everything is not worth the bill.