OpenTelemetry Vocabulary: Tracing, Metrics, and Logs Explained

OpenTelemetry (often abbreviated OTel) has become the industry standard for instrumenting distributed systems. If your team is migrating from vendor-specific SDKs to OTel, writing runbooks for observability, or reviewing instrumentation PRs, you need precise vocabulary. Understanding the terms also helps you communicate clearly with SREs and platform teams.

Signal Types

Traces — End-to-end records of a single request as it propagates through a distributed system. A trace is composed of spans. Traces answer: “Where did this request go and how long did each step take?”

Metrics — Numeric measurements aggregated over time. OTel supports four metric instrument types: Counter (monotonically increasing), Gauge (point-in-time value), Histogram (distribution of values), and UpDownCounter (can increase or decrease).

Logs — Timestamped records of discrete events. OTel Logs are being standardised to integrate with traces and metrics through a shared context. Phrase: “OTel’s goal is a unified signal: logs, metrics, and traces all correlated by trace ID.”

Traces and Spans

Span — A single unit of work within a trace: a database query, an HTTP call, a function execution. Each span has a name, start time, duration, status, and optional attributes. Phrase: “The span for the database query shows 450ms — that’s the latency bottleneck.”

Trace ID — A globally unique identifier shared by all spans in a single trace. The trace ID is what allows you to see the full journey of a request across services.

Span ID — A unique identifier for a single span within a trace.

Parent span — The span that caused the current span to be created. Every span except the root has a parent.

Root span — The first span in a trace, typically created at the entry point of a request (e.g. the HTTP handler in the frontend service).

Context propagation — The mechanism by which trace context (trace ID, span ID, sampling decision) is passed between services, typically via HTTP headers (e.g. traceparent and tracestate from the W3C Trace Context spec). Phrase: “Without context propagation, each service creates an isolated trace — you can’t correlate them.”

Baggage — Key-value pairs attached to a trace context and propagated across service boundaries. Useful for passing request-level metadata (e.g. user ID, region) without modifying function signatures. Phrase: “We pass the tenant ID as OTel baggage so downstream services can tag their spans without reading the JWT again.”

Instrumentation and Export

Instrumentation library — A library that automatically adds OTel instrumentation to a framework or third-party component (e.g. auto-instrumentation for Express, Django, JDBC). Phrase: “The OTel instrumentation library for Express auto-creates spans for every incoming HTTP request.”

Auto-instrumentation — Instrumenting a service without modifying application code, by attaching an OTel agent or SDK that hooks into framework internals. Phrase: “We use Java auto-instrumentation via the OTel agent — zero code changes required.”

Manual instrumentation — Adding OTel API calls directly in application code to create custom spans or add attributes to existing spans. Phrase: “We added manual instrumentation around the payment processing logic to capture the payment provider’s response time as a span attribute.”

Exporter — The OTel component that sends telemetry data to a backend (Jaeger, Prometheus, Tempo, a vendor platform). Each signal type has its own exporter.

OTLP (OpenTelemetry Protocol) — The standard wire protocol for sending OTel data to a collector or backend. OTLP over gRPC or HTTP is the recommended approach. Phrase: “We export traces via OTLP to the OTel Collector, which fans them out to Jaeger and to our SIEM.”

OTel Collector — A vendor-agnostic proxy that receives, processes, and exports telemetry data. It can filter, sample, and transform data before forwarding it. Phrase: “Route all OTLP traffic through the Collector — it lets us change backends without touching application config.”

Resource — Metadata that describes the source of telemetry: service name, version, environment, host, Kubernetes pod name. Resources are attached to all signals from a service. Phrase: “Set the service.name resource attribute correctly — it’s how traces are grouped in the UI.”

Sampling — Deciding which traces to record and export. Head-based sampling decides at the root span; tail-based sampling decides after seeing the full trace. Phrase: “We use a 10% head-based sampling rate in production — tail-based sampling is on the roadmap once we upgrade the Collector.”

How Engineers Talk About OTel in PRs

• “Add a span around the external HTTP call so we can see its latency separately.”
• “The trace shows the bottleneck is in the enrichment service, not the database.”
• “Context propagation is missing — the child service creates a new root span instead of continuing the trace.”
• “Set the span status to ERROR and record the exception as a span event.”

Practice: Instrument a small function in your language of choice using the OTel SDK, then write a two-paragraph PR description explaining what you instrumented, why, and what observability benefit it provides. Use at least eight terms from this post.

In Practice: Navigating Conversations Around Observability

Let’s be honest – sometimes the terminology around observability feels… dense. When working with teams where everyone isn’t fluent in technical jargon, or when communicating across different cultures, it can easily lead to misunderstandings. A phrase that seems perfectly clear to you might sound completely confusing to someone else, especially if they’re still developing their professional English skills. It’s not just about knowing the definitions of “tracing,” “metrics,” and “logs”; it’s about how you articulate those concepts, and how clearly you can ask for clarification when needed.

For example, imagine you’re reviewing a Pull Request (PR) that uses OpenTelemetry. A comment from one of your colleagues might read: “Can we add more sampling to this trace? The volume is quite high.” While technically correct – suggesting reducing the number of traces collected – it doesn’t immediately convey why that’s important. A non-native English speaker, unfamiliar with the concept of “trace volume” and its implications for system performance, might simply ask: “What does ‘sampling’ mean here? And why is it a problem?” It’s crucial to translate the technical recommendation into something more accessible – perhaps: “Reducing sampling will help us focus on the most critical paths in this trace, which should give us better insights into potential bottlenecks and reduce the load on our tracing infrastructure.”

Another scenario might involve a Slack discussion about adding metrics to a new service. Someone could say, “Let’s expose all the database query times as metrics.” This assumes everyone understands what “exposing” means in this context – making that data available for monitoring. A colleague from Spain, perhaps newer to the team, might respond with: “But shouldn’t we only track important queries? Are there any specific metrics we should prioritize?” This highlights the need for clarifying which metrics are truly valuable and how they relate to overall system health. It’s about moving beyond just collecting data and focusing on what that data actually means.

Finally, consider a PR description: “Implement OpenTelemetry context propagation across all microservices.” A developer unfamiliar with the nuances of context propagation might be unsure why it’s necessary. Explaining it as “ensuring that information about a request travels with the service as it moves between different components” – using simpler language – can dramatically improve understanding and collaboration.

# Example OpenTelemetry Python SDK trace creation
import opentelemetry.trace as trace

tracer = trace.get_tracer(__name__)

span = tracer.start_span("my-service-function")
try:
    result = 10 / 2
    print(f"Result: {result}")
finally:
    span.end()

This simple example demonstrates the core concept of a span – a unit of work within a trace. Understanding spans, and how they relate to traces and contexts, is fundamental to using OpenTelemetry effectively. Don’t be afraid to break down complex ideas into smaller, more digestible components when communicating with others. It’s about building shared understanding, not just reciting technical terms.