Context propagation transmits request-identifying trace context across process and network boundaries. It lets a distributed trace continue beyond one service as a request moves through microservices and protocols such as HTTP or gRPC. section 2.5 section 8.1.2
When a request enters the system, a trace ID and related metadata identify its execution. The calling service attaches that context to the downstream request; the child service uses it to create connected spans. Distributed tracing systems then stitch the spans into a trace for viewing, querying, and analysis. With OpenTelemetry, propagation commonly follows the W3C Trace Context recommendation for HTTP headers. section 2.5 section 8.1.2
Following a payment request
An e-commerce request can travel from one service to a billing service and then to a third-party payment provider. The billing service forwards the trace context with its network call, allowing the provider interaction to remain part of the end-to-end trace when the integration supports tracing. section 8.1.2
Reliable propagation depends on more than adding a header:
- Every participating service must forward the trace information; an uninstrumented provider or service can produce a broken or partial trace. section 8.3
- Mismatched headers may require an integration upgrade, middleware, or a translation layer between proprietary and W3C formats. section 8.3
- Propagation adds small latency, bandwidth, and resource costs; broader tracing also incurs instrumentation, collection, ingestion, storage, and query costs. section 2.5.3 section 8.4
Table 2.3 Overview of the costs of traces (view table figure)
| Lots of commercial offerings and some OSS (e.g., Tempo and Jaeger) |
Use the cost overview to compare instrumentation, collector, sampling, storage, and query considerations before selecting a tracing design. section 2.5.3
