What Is Distributed Tracing? How It Works

Last verified on Nov 8, 2026.

Distributed tracing follows a single request as it moves through the services that handle it, and records each step as a timed span. OpenTelemetry's glossary defines it as tracking the progression of one request, called a trace, across the services that make up an application, crossing process, network, and security boundaries. It answers "where did this request spend its time, and where did it fail?"

How a Request Becomes a Trace

Four things have to happen:

1. Instrumentation creates a span for each operation, such as the incoming request and each outgoing call.
2. Context propagation moves the trace ID and the caller's span ID to the next service. OpenTelemetry describes it this way: service A includes a trace ID and a span ID in its context, and service B uses them to create a span in the same trace with A's span as the parent.
3. Export sends finished spans to a collector or backend, usually over OTLP.
4. Assembly happens in the backend, which groups spans by trace ID and orders them by parent-child links.

OpenTelemetry's default propagator uses the headers defined by W3C Trace Context, so a service in one language can continue a trace that began in another.

An Example

A browser calls POST /checkout on the web service. That service calls a payments service and a database. The trace looks like this (timings are illustrative):

trace 5b8aa5a2d2c872e8321cf37308d69df2
POST /checkout            [web, server]      0 ms ======================= 412 ms
  charge card             [web, client]     18 ms ================== 371 ms
    POST /v1/charges      [payments, server] 31 ms =============== 350 ms
      SELECT card         [payments, client] 40 ms === 62 ms
  INSERT order            [web, client]    380 ms == 405 ms

One glance shows the slow part is inside payments, not the web tier. Metrics alone would show a slow /checkout and nothing more. Logs from the two services would show nothing connecting them, unless you add the trace ID to each line.

Distributed Tracing vs Logs and Metrics

Metrics aggregate numbers over time, so they tell you something is slow. Logs record individual events, but OpenTelemetry's primer notes they lack context such as where they were called from, and become far more useful when correlated with a trace and span. Traces supply the request-level path. The primer says tracing is especially useful for debugging behavior that is hard to reproduce locally. The three work best together, which is the idea behind observability.

Where Distributed Tracing Breaks

• Lost context. One uninstrumented service, a proxy that strips traceparent, or a custom HTTP client can split a trace in two. Each fragment gets its own trace ID.
• Asynchronous work. A queue breaks the parent-child chain in time. OpenTelemetry has producer and consumer span kinds for this, and span links to tie a later trace back to the earlier one.
• Untrusted callers. OpenTelemetry warns that malicious actors can send forged trace headers. At a public edge, you may want to ignore incoming context.
• Volume. OpenTelemetry says that when most requests succeed with acceptable latency, you do not need every trace. See trace sampling.

Next Steps

If you run microservices, start with a trace ID in every log line, as described in the microservices logging guide. Then add tracing with the OpenTelemetry setup for your language. Traces pair well with alerts on latency spikes and tail latency.

Sazabi, an AI-native observability and security platform, accepts OTLP traces and lets you search for a request by trace ID alongside its logs. Sazabi ingests OpenTelemetry metrics (Prometheus metrics through an OpenTelemetry Collector) and OTLP traces through the same intake as your logs. It stores each metric data point and each span as a log record that its agent queries alongside your logs, so there is no separate metrics store to run.