Distributed Tracing
In plain English
Plain definition
Distributed tracing tracks a single request across multiple services by propagating a shared trace context, letting engineers see latency, errors and dependency paths in one connected timeline.
Technical Definition
Distributed tracing is an observability technique in which a unique trace identifier is generated at the start of a request and propagated across process, network and service boundaries via headers or context metadata. Each unit of work performed while handling that request is recorded as a span, containing a start time, duration, service name, operation name and optional attributes. Spans reference a parent span, forming a tree (or trace) that represents causal and temporal relationships between operations. Trace data is typically exported to a collector, sampled, stored, and later queried by trace identifier to reconstruct end-to-end request behaviour, including cross-service latency and error propagation.
Operational Relevance
In production systems built from many independently deployed services, a single user-facing request may traverse several APIs, queues, databases and third-party calls. Without distributed tracing, engineers investigating latency or errors must correlate logs and metrics manually across systems, which is slow and error-prone. Tracing gives a direct, request-scoped view of where time is spent and where failures originate, which shortens incident diagnosis and supports capacity and dependency analysis.
Architecture Relationship
Distributed tracing sits alongside logging and metrics as one of the three commonly cited observability pillars, but it is distinguished by carrying request-scoped context across service boundaries. It depends on consistent context propagation conventions (for example, a shared trace header format) being honoured by every service, proxy, and messaging layer a request passes through. It typically integrates with an instrumentation library or SDK inside each service, a collector or gateway that receives span data, and a backend store and query interface used to visualise traces. Sampling strategy, propagation format compatibility, and clock synchronisation across hosts are material architectural concerns that determine whether traces are complete and trustworthy.
Example
A checkout request enters an API gateway, which calls an inventory service, a pricing service and a payment service. With distributed tracing enabled, the gateway generates a trace identifier and passes it to each downstream call. Each service creates a span recording its own processing time and reports it back to a shared collector. If the payment service is slow, the resulting trace view shows that span taking disproportionately long relative to the others, pointing engineers directly at the affected component rather than requiring them to inspect every service’s logs individually.
Misunderstanding
A common misunderstanding is treating distributed tracing as equivalent to logging with extra detail. Logs are typically unstructured or loosely structured events emitted independently by each service, with no inherent cross-service linkage unless deliberately correlated. Tracing is structurally different: it depends on a propagated identifier and span hierarchy that exists specifically to reconstruct causal relationships between operations across services. A service that logs extensively but does not propagate or honour trace context will not produce usable distributed traces, regardless of log volume.
Related Terms
- Span — a single timed unit of work within a trace.
- Trace context propagation — the mechanism by which trace identifiers are passed between services.
- Sampling — the strategy determining which traces are recorded and retained.
- Observability — the broader discipline combining tracing, metrics and logging.
- Instrumentation — the code or agent responsible for generating spans within a service.
Further Reading
Readers evaluating or implementing distributed tracing should consult current platform documentation for the specific tracing tool or standard in use, since propagation formats, sampling defaults and collector configuration vary by implementation and by version. Confirm exact configuration options and supported protocols against the vendor’s current documentation before making architectural decisions.