OpenTelemetry Tracing Vocabulary: Spans, Traces, and Propagation in English

Observability has become a first-class concern for engineering teams, and OpenTelemetry is the standard that unifies how teams collect and export telemetry data. If you work on distributed systems and need to discuss tracing in English — in code reviews, architecture discussions, or incident post-mortems — this vocabulary guide covers the terms you will encounter most often.

Core Vocabulary

Span A named, timed operation representing a single unit of work within a distributed system. A span records a start time, end time, name, status, and optional attributes. Spans are the fundamental building blocks of distributed traces.

“The payment span shows a 340 ms duration — most of that time is a child span for the tax calculation service, which we didn’t expect to be so slow.”

Trace A collection of causally related spans that together represent a request’s complete journey through a distributed system. A trace has a unique trace ID shared by all its spans.

“When we looked at the full trace for the failed checkout request, we found the error originated in the inventory service, not the order service where we initially looked.”

Context propagation The mechanism by which a trace’s identity — the trace ID and span ID — is passed from one service to the next across process boundaries. Propagation typically uses HTTP headers so that downstream services can attach their spans to the same trace.

“Context propagation was broken between the frontend and the API gateway — the gateway was stripping the traceparent header, which is why all the gateway spans appeared as separate top-level traces.”

W3C TraceContext The standard HTTP header format for distributed trace propagation. It uses two headers: traceparent (containing the trace ID, span ID, and flags) and tracestate (for vendor-specific metadata).

“We standardised on W3C TraceContext headers across all services — previously each team was using a different proprietary header and traces couldn’t be correlated.”

Baggage Named key-value pairs that travel alongside the trace context. Baggage is accessible to all services in the trace and is useful for propagating business context — such as a tenant ID or feature flag value — without modifying API contracts.

“We propagate the tenant_id as baggage so that every span in the trace automatically includes it as an attribute — our dashboards can then filter all traces for a specific customer.”

Exporter A component in the OpenTelemetry SDK that takes completed spans and sends them to a backend — such as Jaeger, Grafana Tempo, or an OTel Collector. Different exporters target different backends.

“For local development, we configure the Jaeger exporter so developers can inspect traces in the Jaeger UI. In production, we export to the OTel Collector, which forwards to Tempo.”

Collector The OpenTelemetry Collector is a standalone pipeline that receives telemetry from applications, processes it (filtering, batching, enriching), and exports it to one or more backends. It decouples applications from backend-specific SDKs.

“The Collector handles all our telemetry routing — services send everything to the Collector, and we configure routing rules there rather than changing each service’s exporter.”

Instrumentation The code added to an application that generates telemetry signals — spans, metrics, and logs. Instrumentation can be automatic (using auto-instrumentation agents) or manual (using the OTel API directly).

“We use auto-instrumentation for HTTP and database spans — it handles 80% of what we need. We add manual instrumentation for business logic spans like ‘calculate discount’ that auto-instrumentation doesn’t know about.”

Sampling The process of deciding which traces to record and export, to manage the volume of telemetry data. Common strategies include head-based sampling (decided at trace start) and tail-based sampling (decided after the full trace is complete).

“With 50,000 requests per second, we can’t record every trace — we use tail-based sampling to keep 100% of error traces and 1% of successful ones.”

Key Collocations

• instrument a service — “Before we add the new payment provider, let’s instrument the service with manual spans so we have visibility into each step of the flow.”
• propagate context — “If you use a non-standard HTTP client, you need to manually propagate context by injecting the traceparent header into your outbound requests.”
• export spans — “The SDK batches spans in memory and exports spans every 5 seconds or when the buffer reaches 512 spans, whichever comes first.”
• sample traces — “We configured the Collector to sample traces at 10% head-based — engineers who need a specific trace can use forced sampling with a request header.”
• attach attributes — “We attach attributes like user_id and request_region to the root span so every child span in the trace inherits that context in our backend.”
• correlate logs and traces — “We inject the trace_id and span_id into every log line so we can correlate logs and traces in Grafana — click a log line, jump to the matching trace.”

Using This Vocabulary in Incident Discussions

During incidents, tracing vocabulary helps teams communicate rapidly. The phrase “look at the trace” is a call to action that replaces vague instructions like “check the logs.” More specific is: “Pull up the trace for request ID X and tell me where the latency is — look for the widest span.”

The phrase “the trace is broken” specifically means context propagation failed — the spans exist but don’t form a connected tree because the trace ID was lost between services. This is different from “the trace shows an error,” which means the trace is intact but a span has an error status.

When discussing sampling, teams often debate the “keep vs drop” question: “Are we keeping error traces? Are we dropping health check traces?” This phrasing is more natural in English than “include or exclude.”

Practice Tip

Take a real trace from a system you work on and describe it in English: how many spans does it have, what is the total duration, where does the latency come from, and does it propagate context correctly to all downstream services? Describing a real trace forces you to use span, trace, context propagation, and attributes together in one connected explanation — exactly the kind of communication that happens in incident reviews and architecture discussions.