The ability to correlate events across service boundaries is one of the principle concepts behind distributed tracing. To find these correlations, components in a distributed system need to be able to collect, store, and transfer metadata referred to as context.
A context will often have information identifying the current span and trace, and can contain arbitrary correlations as key-value pairs.
Propagation is the means by which context is bundled and transferred in and across services, often via HTTP headers.
Together, context and propagation represent the engine behind distributed tracing. The following diagram takes a high-level look at the context propagation architecture in OpenTelemetry.
The context contains several pieces of information that can be passed between functions inside a process or between processes over an RPC.
OpenTelemetry traces are organized into spans that contain this context describing the work being done.
This context is divided into two types, span context and correlation context.
When using the OpenTracing Bridge for backwards compatibility, baggage context becomes correlation context in the OpenTelemetry environment. OpenTelemetry itself does not use or refer to ‘baggage.’
Span context represents the data required for moving trace information across service boundaries.
Span context contains the following metadata:
traceID: the trace identifier of the span context.
spanID: the span identifier of the span context.
traceFlags: the trace options for the span context.
traceState: the trace state for the span context.
Correlation context carries user-defined properties. These properties are typically data that you would like to eventually aggregate for correlation analysis or use to filter your trace data, such as a customer identifier, process hostname, data region or other telemetry that provide application-specific performance insights.
Correlation context is not required and components may choose to not carry or store this information.
Propagation is the mechanism by which a trace becomes a distributed trace, and facilitates the movement of context between services and processes.
Context is injected into a request and extracted by a receiving service to parent new spans. That service may then make additional requests, and inject context to be sent to other services…and so on.
There are several protocols for context propagation that OpenTelemetry recognizes.
Implicit vs. Explicit Propagation
There is in-process context propagation, and inter-process context propagation. In-process propagation can be done explicitly, or implicitly. All languages will have an option to manage context explicitly and it is required to some extent for edge case scenarios. Many languages will have implicit in-process context propagation, which frees programmers from having to explicitly pass context around. It is typically implemented using a mechanism such as thread local storage. Explicit context propagation, however, requires a programmer to take a context parameter and explicitly pass the context to an API.