Distributed tracing follows one request as it moves through many services. Each service records timed steps called spans and tags them with the same trace ID, which travels between services in a header. Afterward you can see the whole path and find which step was slow or failed.
Why do logs and metrics fall short?
Logs say what one component did. Metrics say how a service behaves in aggregate. Neither tells you, for one slow checkout, which of nine services ate the time. OpenTelemetry's documentation says logs lack context about where they were called from, and describes distributed tracing as the way to observe requests as they propagate through complex systems, including behavior that is hard to reproduce locally.
What is in a span?
OpenTelemetry defines a span as a unit of work with a name, a parent span ID (empty for a root span), start and end timestamps, a span context, attributes, events, links and a status. The span context holds the trace ID and the span ID. A trace is the tree of spans that share one trace ID.
Constructed example. A request hits the API gateway, which calls an orders service, which calls inventory and pricing. The gateway creates the root span. Orders creates a child, and inventory and pricing create grandchildren. The inventory span shows two attempts, 40 milliseconds and 900 milliseconds. You found your slow step without guessing.
How does the trace ID cross a service boundary?
Through context propagation. The W3C Trace Context specification defines the traceparent HTTP header so every vendor and library can read the same format. An example from the specification:
traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01
The four dash-separated parts are a version, the trace ID, the ID of the calling span (the parent), and trace flags, which carry details such as whether the caller recorded the trace. A companion header, tracestate, carries optional vendor-specific data, so two different tracing systems can exist in one request path without breaking the trace.
When a service receives the header, it creates a new span that points to the caller's span ID as its parent, then sends its own span ID onward in the next call.
Where do traces break?
- A proxy, queue or message broker that drops headers. The trace splits in two.
- Async work, such as a job placed on a queue, where nobody copies the context into the message.
- Mixed formats: one team uses a proprietary header and another uses traceparent.
- Sampling that records the front of a request but not the back, because services decide differently.
Is there a security angle?
Yes, because traces are data. Attributes can capture URLs, query strings, user identifiers and sometimes request bodies. Treat span attributes like logs: do not record secrets, tokens or personal data, redact before export, and control who can read the trace store. Also remember that headers cross trust boundaries. A caller outside your organization can send a traceparent header, so do not treat incoming trace IDs as proof of anything.
How to check or apply this
- Pick one critical user journey, such as sign-up or checkout.
- Instrument the entry point and two downstream services, using a library that speaks traceparent.
- Send one request and confirm one trace contains spans from all three services.
- Test the break points: a queue hop, a retry and a call through a proxy.
- Decide a sampling rule you can explain, and keep error traces.
- Write an attribute rule: no secrets, no raw personal data, redaction at the collector.
- Teach on-call engineers to start from the trace ID in an error log.
Quick check
Is distributed tracing the same as observability?
No. Tracing is one signal. OpenTelemetry describes observability as being able to ask questions about a system from the outside using signals such as traces, metrics and logs.
What does the parent ID in traceparent mean?
It is the ID of the span that made the call. The receiving service uses it as the parent of its own new span, which is how the tree is rebuilt later.
Sources
Last reviewed: 18 October 2026.
