Context Propagation and Semantic Conventions
Context propagation carries trace context (trace ID, span ID, flags) and baggage across process boundaries. Two parts: in-process context (how the active span is stored/retrieved, e.g., thread-local or async context) and cross-process propagation via propagators that inject/extract context into carriers like HTTP headers.
Know the standards: W3C Trace Context (traceparent, tracestate) is the default and recommended propagator; Baggage uses the baggage header. B3 (Zipkin) is an alternative. A frequent trap: mismatched propagators between services break traces - if service A injects W3C and service B only extracts B3, the trace is severed and B starts a new root. Configure the composite propagator consistently across the fleet. Another trap: context does not automatically cross async boundaries or message queues unless you inject/extract at the boundary (e.g., into message headers).
Semantic conventions are standardized names/values for attributes so telemetry is portable: e.g., http.request.method, http.response.status_code, server.address, db.system, messaging.system. They define span names, attribute keys, and resource attributes (service.name, service.version, deployment.environment). service.name is especially important - it identifies the service in backends and defaults poorly if unset.
Traps: inventing custom attribute names where a convention exists; putting high-cardinality values in metric attributes; forgetting service.name; assuming baggage is auto-propagated to spans.
Rule of thumb: propagate W3C Trace Context + Baggage everywhere, and set service.name on every service's resource.
Worked example: Traces stop at a queue consumer. Fix: inject context into message headers on produce and extract on consume; ensure both sides use the same propagator.