OpenTelemetry Vocabulary: Tracing, Metrics, and Logs Explained

Traces, spans, OTLP, context propagation, sampling — the OpenTelemetry vocabulary you need for observability discussions, PR reviews, and architecture documentation in English.

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.