What Is Observability? introduced traces as one of the three pillars of telemetry, alongside logs and metrics, and specifically the one best suited to understanding how a single request behaves across a distributed system. This article goes deeper into how tracing actually works, and what the OpenTelemetry standard contributes to it.
Spans: the basic unit of a trace
A span represents one unit of work within a request — typically one operation within one service, such as handling an incoming HTTP request or making a call to a database. Each span records a start time, a duration, and metadata about what happened. A trace is the complete collection of spans generated as a single request moves through every service and operation it touches, linked together into a structure that shows not just that each operation happened, but how they relate to and depend on each other — which operation called which, and how long each one took relative to the whole request.
Trace context: how spans in different services get linked together
The genuinely hard problem distributed tracing solves is linking spans generated by entirely separate services, often running as separate processes with no shared memory, into one coherent trace. This works through trace context propagation: when one service calls another, it passes along a small piece of identifying context — a trace ID, and the ID of the span that made the call — typically in the request headers. The receiving service reads that context, creates its own span as a child of the one that called it, and passes updated context along to anything it, in turn, calls. The result is a chain of parent-child relationships across service boundaries, reconstructed afterward into the complete trace.
Why this matters specifically for microservices
A request handled entirely within one application is straightforward to debug: check that one application’s logs. A request that fans out across a dozen independently deployed services, a pattern discussed in Monolith vs. Microservices, is a fundamentally different problem — the failure or slowness could be in any one of them, or in the network calls between them, and no single service’s logs show the complete picture. Distributed tracing exists specifically to make that cross-service path visible as one connected structure, rather than requiring someone to manually correlate timestamps across many separate services’ individual logs.
OpenTelemetry: a vendor-neutral standard
OpenTelemetry, hosted by the Cloud Native Computing Foundation, defines a standard, vendor-neutral way to generate and export tracing (and metrics and logging) data. Its documentation on tracing as a signal lays out the span and trace model in detail. The practical significance of a standard here is real: before broad standardization, instrumenting an application for tracing often meant adopting a specific vendor’s proprietary instrumentation libraries, which made switching observability vendors later a genuinely expensive undertaking, since it meant re-instrumenting the application from scratch. OpenTelemetry decouples how an application is instrumented from which backend actually stores and analyzes the resulting data, so switching backends doesn’t require re-instrumenting the application.
What tracing doesn’t replace
Tracing shows the path and timing of a specific request; it doesn’t replace metrics for understanding aggregate system behavior over time, or logs for the detailed content of what happened within a single operation. The three signals remain complementary, as discussed in What Is Observability? — a metric might first indicate that latency has increased across the system, a trace shows which specific service in the request path is responsible, and that service’s logs show the specific error or condition causing it.
Key takeaway
Distributed tracing reconstructs the full path of a single request across many services by linking individual timed spans together through shared trace context passed along with the request — solving a problem that’s specific to, and increasingly unavoidable in, distributed and microservices architectures. OpenTelemetry’s contribution is standardizing how that data is generated and exported, so instrumenting an application for tracing doesn’t lock it into one specific observability vendor.
This article explains general observability and tracing concepts; specific instrumentation approaches vary by language and platform. See our disclaimer.