Distributed Tracing
Following one request’s path across every service it touches, via a shared trace ID, to see exactly where time and errors happen.
In a microservices system, a single user request can fan out across a dozen services — a plain log line from any one of them tells you almost nothing about the whole picture. Distributed tracing tags a request with a shared trace ID that every service propagates and logs against, then stitches every service’s span (its portion of the work) back into one timeline, showing exactly which hop was slow or which one failed.
Worked example: each request carries a trace id propagated across every service it touches, so you can reconstruct the full end-to-end path and see which hop consumed the latency. Gotcha: tracing every request is expensive, so systems sample (e.g. 1%); head-based sampling misses the rare slow request you actually want, which is why tail-based sampling (decide after seeing the whole trace) exists. Context must be threaded through every async boundary or the trace breaks.