Distributed tracing in outline: spans, parent IDs and W3C trace context propagation

What it is

A trace records one request as it moves through several services. It is a tree of spans. The OpenTelemetry documentation lists what a span contains: a name, a parent span ID (empty for the root span), start and end timestamps, a span context (trace ID and span ID), attributes, events, links and a status. Each span also has a kind (Client, Server, Internal, Producer or Consumer) that tells the backend how to assemble the tree: the parent of a server span is often a remote client span.

The tree only forms if identifiers cross process boundaries. The W3C Trace Context recommendation defines the traceparent HTTP header for that: version-trace-id-parent-id-trace-flags, where the trace ID is 32 lowercase hex characters (16 bytes), the parent ID is 16 hex characters (the calling span's ID), and the flags byte currently carries one bit, sampled. A second header, tracestate, holds vendor-specific data. The recommendation names two levels: a tool must at least propagate both headers so that traces are not broken (forwarding), or it may participate by creating its own span and rewriting the parent ID. The OpenTelemetry context-propagation page describes the same mechanism: the caller passes trace ID and span ID, the callee creates a child span with the caller's span as parent.

Why it matters

Logs from ten services describe ten separate events; a trace shows which belong to one request, in which order, and where the time went. Without propagation each service starts its own root span and the backend shows fragments that cannot be joined.

How to apply

• Create a server span for every incoming request and a client span for every outbound call, message publish or database query; framework instrumentation libraries do this automatically.
• Propagate through everything, not only HTTP: put traceparent into message headers for queues and into the job payload for background work, and restore it in the consumer.
• Write the trace ID into every log line of the request so logs and traces can be joined.
• Keep span names low-cardinality (GET /users/{id}, not the concrete URL); put variable parts into attributes.
• Services that do not run a tracing SDK should still forward traceparent and tracestate unchanged.

Pitfalls

Context is lost at asynchronous boundaries (thread pools, timers, batched writers) unless the library or the code carries it explicitly. The sampled flag is a hint from the caller; a sampling decision made per service produces traces with missing spans. Clock skew between hosts can make a child span appear to start before its parent. A public edge should decide deliberately whether to continue a trace supplied by an arbitrary client.