Context is the product

Ask what OpenTelemetry gives you and the honest answer is not “traces, metrics and logs”. Those are output formats, and every observability vendor that came before had versions of all three. What is new is smaller and much less discussed: a single carrier that travels with your program’s work, holds whatever is true about this unit of work, and is the same object for all three signals.

The specification calls it Context, and the argument of this article is that it is the product. The signals are what you get because it exists.

The definition is conspicuously empty

Read the Context specification and notice what is not in it (source). There is no span. There is no metric, no log, no exporter, no sampler. Context is defined as an immutable object holding key-value entries, where writing produces a new context rather than modifying the old one, plus a notion of a “current” context for languages that can carry one implicitly.

That emptiness is the design. Because Context knows nothing about telemetry, it can carry telemetry — and anything else — without any of those things having to know about each other. The tracing API stores the active span in a context (source); the baggage API stores user values in a context (source); a log record picks up the trace ids by reading whatever span is in the context at the moment it is emitted.

Three subsystems, no coupling between them, one carrier. If Context had been defined as “the thing that holds the current span”, logs and metrics would each have needed their own version of it, and the correlation between them would have been a convention rather than a mechanism.

Immutability matters for the same reason. Concurrent work — a request handler and the three parallel calls it makes — needs each branch to add to the context without disturbing the others. A mutable ambient object would have made that a race; a new context per write makes each branch’s view naturally its own.

Implicit and explicit, and the trouble is always the same

Context can be carried in two ways, and the specification supports both because languages differ (source). Implicitly, in ambient storage the runtime associates with the current execution — a thread local, an async local — so that code deep in the stack can find the current span without every function signature mentioning it. Or explicitly, passed as an argument, which is what Go does and what every language does at boundaries where the ambient trick does not survive.

Practically every “my telemetry is not correlated” bug is the ambient version failing at exactly those boundaries: a task handed to a thread pool, a callback invoked later by a client library, a job pushed to a queue, a stream resumed on another thread. The work continues; the ambient context does not follow, because nothing copied it. The span you expected to be the parent is still open somewhere else, and the new work starts with an empty context and no error.

Which is worth stating as a rule, because it covers all of those cases at once: context follows execution only where something carries it. Inside one synchronous call stack the runtime carries it for you. Everywhere else — across a thread, across a process, across a queue — carrying it is code someone wrote, and if nobody wrote it, the crossing is silent.

Baggage: the part you choose

Trace context is the join, and it is mandatory: the identifiers and the sampling flag, in a fixed grammar, because the whole system depends on them meaning the same thing everywhere (source).

Baggage is the other kind of cargo — key-value pairs you decide to carry with the request, propagated alongside the trace context in a header of their own (source). A tenant id, a region, a feature-flag cohort: facts known at the edge that services deeper in the system have no other way to learn, short of asking someone.

Two things about it are easy to get wrong, and both are written down.

Baggage is not automatically attached to your telemetry (source). Carrying a value and recording it are separate acts; if you want a baggage entry to appear as a span attribute, something has to put it there. That looks like an inconvenience until you consider that baggage travels to every downstream service, including ones you do not operate. Auto-attaching it would mean any value anyone puts in baggage ends up recorded, in telemetry, everywhere — which is how a customer identifier becomes a permanent resident of three vendors’ storage.

Baggage is paid for on every request. It is a header on every hop, so its cost is bytes multiplied by your request volume, which is why the format specifies size limits rather than trusting good sense. Baggage is for the handful of facts that change how downstream services behave or how their telemetry is grouped — not for context in the everyday sense of “useful background”.

What this buys, stated plainly

Once Context exists, several things that look like separate features turn out to be the same feature.

A log line knows its trace because the record is emitted while a context holding a span is current. An exemplar knows its trace for the same reason: the measurement was recorded inside one. A downstream service continues your trace because a propagator wrote the context into a header and another one read it back (source). A sampling decision holds for the whole trace because it rode along in the same place.

None of those are three signals cooperating. They are three signals independently reading one carrier, which is why they can be developed, versioned and deployed separately and still agree.

And it explains the shape of the phase-four labs. Instrumenting a library is mostly not about producing spans — it is about not losing the context: extracting it at the entry point, keeping it across the async hop, injecting it before the outgoing call. Get that right and the telemetry follows. Get it wrong and you produce perfectly good spans that belong to nothing.

Where to go next: A trace is a tree nobody owns for what those carried identifiers assemble into, or The seam between the signals for the other joins this one makes possible. The full path is on the handbook page.