> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Context Propagation > Explains OpenTelemetry context propagation including trace context and baggage, W3C and B3 formats, propagators, inject and extract workflows, and composite support for cross service distributed tracing. Hello, span explorers. This article explains context propagation — a core concept in distributed tracing — and shows how OpenTelemetry moves trace context and baggage across processes and services. Building on span basics (start/end time, events, attributes, span context, and baggage), you'll learn: * What span context and baggage contain * Why a universal trace format matters * How OpenTelemetry injects and extracts context across carriers * Common propagation formats you will encounter (W3C Trace Context, B3, Composite) Quick recap — what span context and baggage hold: * Trace ID: ties the entire trace together * Span ID: uniquely identifies a single span * Trace flags: indicates whether the span was sampled * Trace state: vendor-specific data Baggage is arbitrary key-value metadata that travels with the context (e.g., product ID, cart ID, promo code). This helps services downstream make decisions or add useful attributes to spans. The image illustrates the flow of key-value pairs in a request context from Service A to Service B to Service C, including information like product ID, cart ID, and promo code. Trace context contains the tracing identifiers and flags; baggage carries custom key/value metadata. To move both across service boundaries we need a standard wire format. The image illustrates the flow of request context and trace information between three services, labeled Service A, Service B, and Service C, highlighting the need for a universal trace format. Why a standard format? Historically, many APM vendors and open-source tools used proprietary HTTP headers for propagation. Non-standard headers are often dropped by middleware, load balancers, or proxies, which breaks distributed traces. To solve these interoperability problems, the W3C Trace Context standard (circa 2018) became the industry default and is the OpenTelemetry default format. W3C Trace Context ensures cross-vendor compatibility so services and tools can read and continue traces reliably. The image illustrates how APM vendors and open-source tools use their own defined HTTP headers, leading to issues like middleware complications and broken transactions. It emphasizes the importance of W3C TraceContext and Baggage for OTel. W3C Trace Context and W3C Baggage are HTTP header formats. The primary headers are `traceparent`, `tracestate`, and `baggage`. Example (illustrative): ```text theme={null} traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01 tracestate: vendorname=value baggage: user_id=42,region=us-east ``` * `traceparent`: core trace identifiers and flags * `tracestate`: optional vendor-specific metadata * `baggage`: arbitrary key-value pairs that travel with the request Note: propagation extends beyond HTTP. The same header concepts apply to gRPC metadata, message attributes in queues, and other carriers. When OpenTelemetry is configured and instrumented correctly, propagators automatically inject and extract these headers so traces continue across service boundaries. The image illustrates the flow of headers through a sequence of services labeled Service 1 to Service 4, under the concept of "W3C Trace Context & Baggage." Propagation workflow Before making an outbound call, the current trace context is injected into a carrier (HTTP headers, gRPC metadata, or a message). On the receiving side, the trace context is extracted from that carrier and restored into the receiving process so the trace can continue. The image illustrates the process of propagating context from "Service A" to "Service B" using HTTP/gRPC carriers, with context injected into and extracted from W3C headers. Propagation is simply the serialization and deserialization of the context object. That context contains trace ID, span ID, trace state, trace flags — plus baggage. Most OpenTelemetry instrumentation handles propagation automatically, but custom integrations use the propagators API directly. The image is an overview of propagation concepts, explaining the passing of context across processes, serialization/deserialization for information transfer, and the use of libraries and APIs for handling propagation. Context management A single process may have multiple spans concurrently (especially in async or multithreaded apps). The context manager tracks the active span and baggage so the correct span ID is injected into outgoing requests. Proper context management is essential to avoid leaking or mis-associating spans. The image explains the functions of a Context Manager in tracking active spans, including maintaining context, ensuring active spans, handling contexts, and supporting asynchronous and multi-threaded apps. Propagator API: core concepts * TextMapPropagator: interface that reads/writes context into carriers (key-value maps). * Carrier: the transport medium (HTTP headers, gRPC metadata, message attributes). * Setter/Getter: functions that write/read keys to/from the carrier. * inject: write the current context into an outgoing carrier. * extract: read context from an incoming carrier and restore it to the process. Pseudocode example: ```python theme={null} # Service A (outbound) propagator.inject(context, headers, setter) # Service B (inbound) context = propagator.extract(headers, getter) ``` The image explains how W3C headers work, detailing injection and extraction by TextMapPropagator methods and maintaining trace continuity across distributed systems. TextMapPropagator is transport-agnostic because it operates on generic key-value pairs. It works for HTTP headers, gRPC metadata, messaging attributes, and custom carriers. The image provides an overview of TextMapPropagators, an OpenTelemetry API interface for serializing and deserializing trace context, with icons representing these processes. The propagator bridges in-process context to out-of-process communication, enabling traces to be stitched across microservices. The image explains why TextMap Propagators are used, highlighting their function in enabling context propagation over protocols and bridging in-process context to out-of-process communication. API operations summary: * Inject: serialize a `context` into an outgoing carrier (e.g., HTTP headers). * Extract: deserialize a `context` from an incoming carrier for continued tracing. The image explains two API operations: "Inject" which writes context into an outgoing carrier like HTTP headers, and "Extract" which reads context from an incoming carrier to continue the trace. API building blocks: * Carrier: typically a dictionary-like map of headers or metadata. * Setter/Getter: functions for writing/reading the carrier entries. * Global propagator: application-level configuration that defines which propagation formats are used (e.g., W3C, B3, composite). The image outlines key concepts: Carrier, Setter/Getter, and Global Propagator, explaining their roles in data transport and configuration. B3 propagation B3 (from Zipkin) is a simpler, legacy propagation format still used by many systems (including Istio/Envoy). B3 headers include `X-B3-TraceId`, `X-B3-SpanId`, `X-B3-ParentSpanId` (optional), and `X-B3-Sampled`. The image explains B3 Propagation Basics, highlighting its purpose for Zipkin due to its simplicity and compatibility, and listing the headers used: X-B3-TraceId, X-B3-SpanId, and the optional X-B3-ParentSpanId. Example B3 headers: ```text theme={null} X-B3-TraceId: 4bf92f3577b34da6a3ce929d0e0e4736 X-B3-SpanId: 00f067aa0ba902b7 X-B3-Sampled: 1 ``` To enable B3 propagation in Python OpenTelemetry: ```python theme={null} from opentelemetry.propagate import set_global_textmap from opentelemetry.propagators.b3 import B3MultiFormat set_global_textmap(B3MultiFormat()) ``` B3 remains useful for backward compatibility with Zipkin-based ecosystems and tools that expect B3 headers. Composite propagators OpenTelemetry supports CompositePropagator, which injects and extracts using multiple formats (for example, W3C + B3). This is useful in mixed environments or during migrations. The image illustrates the use of composite propagators in OpenTelemetry, showing how the OpenTelemetry SDK injects and extracts context through multiple propagation formats and services. When injecting, the SDK can write both W3C and B3 headers to outgoing requests. On extraction, it will try multiple propagators until it finds a valid trace context. Composite propagators are useful for: * Supporting multiple vendors that require different formats * Hybrid environments where some services use W3C and others use B3 * Migrating formats while preserving backward compatibility The image explains when to use composite propagators in OpenTelemetry, highlighting scenarios involving multiple vendor integrations, different standards, and migration needs. Python example configuring a CompositePropagator: ```python theme={null} from opentelemetry.propagate import set_global_textmap from opentelemetry.propagators.composite import CompositePropagator from opentelemetry.propagators.b3 import B3MultiFormat from opentelemetry.propagators.tracecontext import TraceContextTextMapPropagator set_global_textmap( CompositePropagator([ TraceContextTextMapPropagator(), # W3C Trace Context B3MultiFormat() # B3 (Zipkin) ]) ) ``` The image is a table comparing scenarios with the benefits of composite propagation, highlighting support for B3 and W3C formats and integration solutions. Quick reference tables Headers and their purpose | Header | Purpose | Example | | -------------- | -------------------------------------------------------- | ---------------------------------- | | `traceparent` | Core W3C trace identifiers and flags | `00-4bf92f35...-01` | | `tracestate` | Vendor-specific trace metadata | `vendorname=value` | | `baggage` | Arbitrary key-value metadata that travels with the trace | `user_id=42,region=us-east` | | `X-B3-TraceId` | B3 trace identifier | `4bf92f3577b34da6a3ce929d0e0e4736` | | `X-B3-SpanId` | B3 span identifier | `00f067aa0ba902b7` | | `X-B3-Sampled` | B3 sampling flag | `1` | Propagator types | Propagator | Use case | Notes | | ------------------- | ------------------------------------------ | --------------------------------------- | | Trace Context (W3C) | Default in OpenTelemetry | Uses `traceparent`/`tracestate` | | W3C Baggage | Carry arbitrary metadata | Uses `baggage` header | | B3 | Legacy/Zipkin ecosystems | `X-B3-*` headers | | CompositePropagator | Multi-format compatibility | Combines multiple propagators | | Custom propagator | Proprietary carriers or unusual transports | Implement `TextMapPropagator` interface | The image is a table comparing various trace context propagation formats, including "W3C TraceContext," "W3C Baggage," "B3," "Jaeger," "OT Trace," "OpenCensus BinaryFormat," and "Vendor-specific," each with a brief description of its purpose or use. Other formats and legacy options You may still encounter other propagation formats (Jaeger headers, ot-trace from OpenTracing, OpenCensus binary formats, or vendor-specific headers). However, W3C Trace Context and W3C Baggage are the industry-standard defaults that OpenTelemetry prefers. The image is a table summarizing key takeaways about composite propagation benefits in various scenarios, such as Trace ID/Span ID, Context, Carrier, and more. Each scenario is paired with its corresponding benefit, detailing how metadata and APIs are used for context propagation. Recap — key concepts * Trace ID: unique identifier for a trace * Span ID: unique for a span; used as parent ID for child spans * Context: object that holds trace data (trace ID, span ID, flags, trace state) * Carrier: transport medium for context (HTTP headers, gRPC metadata, messaging attributes) * Inject/Extract: operations for writing/reading context to/from a carrier * TextMapPropagator: API responsible for serializing/deserializing context * Global propagator: config that selects active propagation formats in your application The image is a table summarizing key takeaways about propagation standards, including W3C Trace Context, W3C Baggage, B3 Propagation, and Composite Propagator. It details the headers used and provides a brief description of each standard. Final summary Context is the object that carries trace data (trace ID, span ID, trace flags, optional tracestate). Propagation is the mechanism that serializes and deserializes that context across process or service boundaries. OpenTelemetry defaults to W3C Trace Context and W3C Baggage, but supports other formats (B3, composite, and vendor-specific) via propagators to ensure backward compatibility and smooth migrations. The image is a summary of points regarding context and propagation in OpenTelemetry, highlighting standards, APIs, and support for older formats. OpenTelemetry defaults to the W3C Trace Context and W3C Baggage formats. Use composite propagators when you need to support multiple propagation standards simultaneously (for example, during a migration or when integrating with legacy tooling). Links and references * W3C Trace Context: [https://www.w3.org/TR/trace-context/](https://www.w3.org/TR/trace-context/) * W3C Baggage: [https://www.w3.org/TR/baggage/](https://www.w3.org/TR/baggage/) * OpenTelemetry Propagation (official docs): [https://opentelemetry.io/docs/reference/specification/context/api-propagators/](https://opentelemetry.io/docs/reference/specification/context/api-propagators/) * B3 Propagation (Zipkin): [https://github.com/openzipkin/b3-propagation](https://github.com/openzipkin/b3-propagation) That's it for this article on context propagation.