OpenTelemetry glossary

The canonical vocabulary for this course. Every lesson uses these terms exactly as defined here. Coloured tags show which layer a term lives in: ■ produce · ■ ship · ■ backend · ■ Spring.

Telemetry: Greek tele (far off) + metron (measure) — “measurement at a distance.” Data a system emits about its own behaviour, shipped elsewhere to be examined, because you cannot stand inside a running process and look. Distinct from business data: an order row is what the system is for; a span saying POST /orders took 45 ms is telemetry about it.
Signal: A category of telemetry. OpenTelemetry's docs list four — traces, metrics, logs and baggage — but only the first three are telemetry that is exported and stored. [src]
Trace: The path of one request through the system: a tree of spans that all share one trace ID. [src]
Span: One unit of work / one operation, with a name, start time and duration. A service emits many spans per request. Building block of a trace.
Trace ID: Identifier constant across every span in one request. This is what ties spans across services into a single trace.
Span ID / Parent span ID: Span ID identifies one span; parent span ID points at the span that caused it. Root spans have no parent. Parent links build the tree.
Span Context: Immutable identity carried by every span: trace ID, span ID, trace flags, trace state. This is the part that gets propagated. [src]
Span Kind: Role of a span: SERVER (incoming sync call), CLIENT (outgoing sync call), INTERNAL (no boundary crossed), PRODUCER / CONSUMER (async messaging).
Span Status: One of Unset (default), Error, Ok (set explicitly by the developer).
Attributes · Events · Links: Attributes = key/value metadata on a span. Events = a timestamped annotation within a span. Links = a causal reference to spans in another trace (async/fan-out).
API produce: Vendor-neutral interface for generating & correlating telemetry. Stable contract that library/app code compiles against. No-ops if no SDK is present. [src]
SDK produce: The concrete implementation of the API. Owns configuration, processing, sampling, batching, and export. The swappable engine behind the API.
Instrumentation library produce: Code that auto-generates telemetry from popular frameworks (HTTP, JDBC, etc.) so you don't hand-write spans.
Resource · service.name produce: Attributes describing the entity producing telemetry (service, host, pod). service.name is the key one; defaults to unknown_service if unset. [src]
Exporter ship: Serialises telemetry and sends it onward — to a Collector or straight to a backend. OTLP exporters emit with no loss of information.
OTLP ship: OpenTelemetry Protocol — the wire format. Transports: gRPC (:4317), HTTP/protobuf and HTTP/JSON (:4318). Traces POST to /v1/traces. [src]
gRPC ship: A language-agnostic RPC framework: your code calls a method that runs on another machine “as if it were a local object.” Runs over HTTP/2, serialises with Protocol Buffers (binary, schema-first). One of OTLP's two transports — :4317; the alternative is plain HTTP on :4318. Same OTLP messages either way, different envelope. [src]
Context propagation ship: Moving span context across service/process boundaries. A propagator serialises it; the default is W3C Trace Context. [src]
traceparent (W3C header) ship: HTTP header carrying context between services: version-traceid-parentid-flags, e.g. 00-a0892f35…-f03067aa…-01. [src]
Baggage ship: Arbitrary key/values propagated alongside context to correlate signals. OTel's docs do list it beside traces/metrics/logs, but it is the odd one out: it carries no telemetry and is never exported to a backend. Never put secrets/PII in it. [src]
Collector ship: Vendor-agnostic proxy that receives → processes → exports telemetry. Optional. Pipeline parts: receivers, processors, exporters, connectors, extensions. [src]
Agent vs Gateway (Collector deployment) ship: Agent = Collector next to each app (sidecar/host). Gateway = a shared standalone Collector service apps send to. Gateway is required for tail sampling. [src]
Head vs Tail sampling ship: Head = decide up front (fast, can't inspect whole trace). Tail = decide after seeing the whole trace (can always keep errors; needs stateful infra). [src]
Backend backend: The system that stores and displays telemetry. Not part of OpenTelemetry. Here: Jaeger, Dynatrace.
Jaeger backend: Open-source trace backend. v2 is built on the OTel Collector; ingests OTLP natively. Parts: collector, query (UI on :16686), ingester, all-in-one. [src]
Dynatrace backend: Commercial observability backend. Ingests OTel three ways: direct OTLP (/api/v2/otlp), OneAgent, or the Dynatrace OTel Collector. [src]
Observation API Spring: Micrometer's abstraction your Spring code emits. Each Observation, via a tracing ObservationHandler, becomes a span. [src]
Micrometer Tracing + bridge Spring: Vendor-neutral tracing facade. The micrometer-tracing-bridge-otel bridge routes spans to the OpenTelemetry tracer (alternative: -brave for Zipkin). [src]
Actuator (tracing auto-config) Spring: Spring Boot module that auto-wires the observation registry, tracer, bridge and OTLP exporter from management.* config. [src]
JMX (Java Management Extensions) Spring: “A standard API for management and monitoring of resources such as applications, devices, services, and the Java virtual machine” — Java-only (JSR 3 / JSR 160). Your JVM exposes MBeans (readable attributes, invocable operations) and a tool such as JConsole connects in to read heap, threads or config. Not a transport and not comparable to gRPC: JMX is a door into the JVM that a tool pulls from; gRPC is how your app calls out. The two meet in the Collector's JMX receiver, which scrapes MBeans and re-exports them as OTLP metrics. [src] · [otel jmx]
Spring Cloud Sleuth Spring: Legacy. Boot 2.x tracing library; not supported on Boot 3.x. Its role moved into Micrometer Tracing + Observation. Mentioned only to contrast.

Reference · Glossary ← Lesson 01 · Lesson 02 · Lesson 03