Trace context is the small set of identifiers and options that allows independently instrumented components to contribute spans to the same trace. At minimum, it identifies the trace and the currently active span. It can also carry sampling decisions and vendor-neutral baggage.
How propagation works
- An instrumented entry point extracts context from an incoming request or creates new context when none exists.
- The application starts a span and makes it active for the current operation.
- Before an outbound call, instrumentation injects the active context into the transport.
- The receiving service extracts that context and creates a child span.
- The process repeats across HTTP, RPC, and messaging boundaries.
OpenTelemetry propagators perform injection and extraction. The concrete carrier depends on the protocol, such as HTTP headers or message metadata. Applications should use compatible propagator configuration across services so trace and parent-span IDs remain connected.
Common causes of broken traces
- a service is not instrumented;
- client or server instrumentation does not inject or extract context;
- asynchronous work loses the active context;
- a proxy or messaging layer removes propagation headers;
- services use incompatible propagators; or
- sampling decisions are applied inconsistently.
When propagation works, all related spans share a trace ID and each child refers to its caller’s span ID. When it fails, downstream work appears as a separate trace or as an orphaned span. Validate propagation whenever traces consistently stop at a particular service boundary.OpsRamp accepts OpenTelemetry trace identifiers and parent relationships. Propagation itself occurs in the application, SDK, service mesh, or collector path before data reaches OpsRamp.