What is distributed tracing?
Distributed tracing is a technique for following a single request as it travels across multiple services, linking each step into one timeline of spans through a shared trace ID and propagated context.
Definition
In a microservices or distributed system, a single user action — say, a checkout — may touch a dozen services before returning a response. Distributed tracing stitches that whole journey back together. When the request enters the system it's assigned a unique trace ID; every service it passes through records a span (a timed unit of work) tagged with that trace ID and the parent span it came from. Collected together, those spans form one end-to-end trace.
The mechanism that makes this work is context propagation: as a request crosses a service boundary (an HTTP call, a message on a queue), the trace context — the trace ID and current span ID — is passed along, typically in headers following the W3C Trace Context standard. The receiving service reads that context, creates a child span, and continues the chain. Without propagation each service would produce isolated, unconnectable spans.
Anatomy of a trace
A trace is a tree of spans connected by propagated context, usually visualized as a waterfall.
Trace
The complete record of one request's path through the system, identified by a single trace ID and made up of all the spans it generated.
Span
A single timed operation — a database query, an API call, a handler — with a start time, duration, attributes, and a link to its parent span.
Parent & child spans
Spans form a tree: a parent span (e.g. the incoming request) contains child spans for the downstream work it triggered, showing causality and nesting.
Context propagation
Passing the trace and span IDs across service boundaries, typically via W3C Trace Context headers, so independent services contribute to the same trace.
The waterfall view
Spans plotted on a timeline, revealing at a glance which step was slow, which ran in parallel, and where a failure cascaded through the request.
Why distributed tracing matters
In a monolith, a slow request lives in one process and one set of logs. In a distributed architecture, the same request fans out across services owned by different teams, and a single slow span deep in the chain can degrade the whole user experience. Logs alone can't connect those hops — they're separate streams with no shared thread. Distributed tracing supplies that thread, so a latency or error problem is attributable to a specific service and operation instead of being a system-wide mystery.
Tracing also reveals architecture you may not have on a diagram: which services actually call which, how deep your dependency chains run, and where retries or N+1 patterns quietly multiply work. That makes it indispensable both for debugging a specific incident and for understanding the real shape of a system as it evolves.
Distributed tracing with AllStak
AllStak ingests OTLP traces over HTTP, so you can instrument your services with OpenTelemetry and send spans straight to AllStak — no proprietary agent required. Traces are visualized as waterfalls where you can spot the slow or failing span, and because they share a platform with your errors and logs, you can pivot from a span to the exception or log line behind it.
Frequently asked questions
What is distributed tracing?
It is a way to follow one request across many services by tagging each step with a shared trace ID and propagating context, then assembling the steps into a single end-to-end timeline of spans.
What is the difference between a trace and a span?
A span is one timed operation within a request; a trace is the full collection of spans for that request. Many spans, linked by parent-child relationships, make up a single trace.
What is context propagation?
It is the passing of trace and span identifiers across service boundaries — usually via W3C Trace Context HTTP headers — so spans created in different services connect into the same trace.
Is distributed tracing the same as APM?
They overlap but aren't identical. Distributed tracing is the technique of following requests across services; APM is the broader discipline of monitoring application performance, which often uses tracing as one of its data sources.
Explore more
By framework
Trace requests end to end
Send OpenTelemetry traces to AllStak and see exactly where a request slows down or fails across your services.