Distributed tracing
Also known as: request tracing, distributed request tracing, end-to-end tracing
Distributed tracing tracks a single request, like a click on 'Buy now,' as it travels through all the services that handle it, recording how long each step took and where errors occurred.
The result looks like a timeline of the request's journey. While logs tell you what each service did, traces tell you how the pieces fit together, which is usually where modern outages hide.
Distributed tracing, explained at three levels
At home
Think of tracking a parcel online. You see when it left the warehouse, reached the sorting centre, went out on a truck, and arrived at your door, with times for each stop. Distributed tracing does the same for a single request inside an app, such as a click on 'Buy now,' recording every service it passes through and how long each one took.
At work
Distributed tracing follows individual requests as they travel through the many services that make up a modern application, recording each step's timing and any errors. The result is a timeline showing exactly where a request slowed down or failed. Businesses care because, when an app made of dozens of services is slow, tracing points engineers straight at the cause instead of leaving them to guess.
At home
When a request enters the system, it's given a unique trace ID. Each service it passes through records a span: a named, timed step that carries the trace ID and the ID of the step that called it. Those parent links let a tracing tool reassemble all the spans into a tree, usually drawn as a waterfall chart, where the longest bar shows where the time went.
At work
Trace context travels between services in request headers, standardized by the W3C traceparent format, so tools from different vendors can continue the same trace. OpenTelemetry libraries add and read these headers automatically for common frameworks and send spans to a collector, which forwards them to a backend such as Jaeger, Grafana Tempo, or a commercial platform. Spans carry attributes, such as HTTP status or customer region, that make traces searchable.
At home
Recording every request would be expensive, so systems sample. Head-based sampling decides at the start of a request, say keeping 1 in 100, which is cheap but blind to what happens later. Tail-based sampling buffers all spans and decides at the end, keeping the slow and failed requests. While tail sampling needs more memory and coordination, in my opinion it's worth it, because the interesting traces are the rare ones.
At work
Traces break wherever context isn't propagated: message queues, batch jobs, thread pools, and third-party services often drop it unless instrumented explicitly, for example by carrying trace context in message headers. Tail sampling requires routing all spans of a trace to the same collector, which shapes the collection architecture. Add business attributes to spans but keep personal data out, and link traces to logs and metrics through shared IDs to cut investigation time.
Real-world examples
At home
Thomas was learning microservices with a sample shopping app. When checkout took five seconds, a trace showed four of those seconds were spent in the recommendation service, which had nothing to do with checkout.
At work
Carlos is a site reliability engineer at a Canadian telecom. A billing page was timing out for some customers. Traces revealed a legacy service making 200 separate database calls per request, which his team fixed with a single batched query.
How it compares
| feature | Distributed tracing | Logging |
|---|---|---|
| View | One request across many services | Events within one service |
| Best for | Finding slow or failing steps | Detailed context about a specific event |
| Shared link | Trace ID | Usually none unless added |
| Cost driver | Number of requests traced | Volume of log lines |
Tracing shows the journey. Logs describe each stop.
For analysts
If your team spends incident calls debating which service is to blame, tracing is likely the missing piece. I'd start by tracing the two or three customer journeys that matter most to revenue.
History & origin
Google described its internal tracing system, Dapper, in a 2010 paper that became the blueprint for the field. Twitter open-sourced Zipkin, inspired by Dapper, in 2012, and Uber released Jaeger in 2017, which later graduated in the Cloud Native Computing Foundation. Competing instrumentation projects, OpenTracing and OpenCensus, merged into OpenTelemetry in 2019, and the W3C standardized a common Trace Context header so that traces could pass between different vendors' tools. In my view, standardizing the header mattered as much as any tool, because a trace that breaks at a vendor boundary isn't much of a trace.