Context Propagation

Properties

created 14.04.2026, 17:00

modified 26.07.2026, 13:29

published Empty

topics Distributed Tracing, Observability

authors Empty

ai-assisted Yes

Mechanism for passing trace context (traceId, spanId) across process boundaries ( OTel Context Propagation)
Without propagation, each service would start a new independent trace — no end-to-end visibility

# How It Works

Service A starts a span, holds traceId + spanId in local context
Before making an outbound HTTP/gRPC call, A injects context into the request headers
Service B receives the request, extracts context from headers
B creates a new child span using A’s spanId as parentSpanId and the same traceId
The two spans are now linked in the same trace tree

Standard HTTP header for trace propagation ( W3C Trace Context Spec)
Format: traceparent: 00-{traceId}-{parentSpanId}-{flags}
- 00 — version
- traceId — 32 hex chars (128-bit)
- parentSpanId — 16 hex chars (64-bit)
- flags — 01 = sampled, 00 = not sampled

Example

1
traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01

Format	Header	Notes
W3C Trace Context	`traceparent`	OTel default, modern standard
B3 (Zipkin)	`X-B3-TraceId`, `X-B3-SpanId`	Legacy, widely supported
Jaeger	`uber-trace-id`	Jaeger-specific
AWS X-Ray	`X-Amzn-Trace-Id`	AWS services

OTel supports multiple propagators simultaneously — useful when integrating with legacy services

Alongside trace context, OTel allows propagating arbitrary key-value baggage
Propagated via baggage HTTP header
Use case: pass user.id or tenant.id through the whole call chain for log correlation
Warning: baggage is sent with every outbound request — keep it small