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.

Navigating Feedback with Confidence

The initial “undefined” post rightly highlights the common frustration of encountering an error message during debugging. However, a developer’s journey rarely ends with simply fixing a technical glitch. The real challenge often lies in communicating those fixes – and the reasoning behind them – to colleagues, stakeholders, or even future self. For non-native English speakers, this can be particularly daunting, as precise vocabulary and nuanced phrasing are crucial for conveying meaning effectively. Let’s consider a realistic scenario: Sarah, a junior developer on the “Phoenix” project, has just submitted a pull request addressing an intermittent bug in the user authentication module. During code review, her team lead, Mark, leaves a comment: “Can you explain the rationale behind this change? The previous implementation was working fine.”

Sarah’s immediate reaction might be to revert to simpler phrasing, perhaps something like “Fixed the error.” While technically accurate, it lacks context and could raise further questions. A more professional response would demonstrate understanding of the feedback and proactively address Mark’s concern. She could reply in Slack: “Absolutely, Mark. I noticed that the previous implementation was stable but identified a potential race condition during testing under high load. This change introduces a mutex lock to prevent concurrent access to the user database, mitigating the risk. The rationale aligns with our team’s established best practices for security and stability.” Notice the use of precise terminology – “race condition,” “mutex lock,” “concurrent access” – demonstrating Sarah’s technical understanding.

Furthermore, a well-crafted PR description further reinforces this communication. Instead of simply listing changes, she could write: “This pull request addresses a potential concurrency issue in user authentication. The previous implementation lacked safeguards against simultaneous database queries, which could lead to data corruption under heavy load. This change introduces a mutex lock to ensure data integrity and prevent race conditions. I’ve included updated unit tests to verify the fix and ensure continued stability.” The detail here – explaining why the change was made and what potential problems were avoided – significantly increases clarity for anyone reviewing her work, especially those unfamiliar with the specifics of the module.

Ultimately, mastering professional English in a technical context isn’t just about knowing the right words; it’s about confidently articulating your thought process, demonstrating your understanding, and proactively communicating potential risks. Focus on using industry-standard terminology accurately and providing clear explanations for every change you make – this builds trust and ensures effective collaboration within any development team.