OpenTelemetry (OTel)

OpenTelemetry is a "vendor- and tool-agnostic" open-source observability framework for "generation, export, and collection of telemetry data such as traces, metrics, and logs." It is the off-the-shelf answer to the "build vs. buy the topology" open question — the standardized instrumentation layer a team adopts instead of building bespoke telemetry plumbing like Netflix's. Source: official OTel docs.

What it is (and isn't)

• Components: language APIs/SDKs, semantic conventions (standard naming), the OTLP wire protocol, instrumentation libraries (incl. automatic instrumentation), and the Collector (a receive/process/export proxy).
• Not a backend: "OpenTelemetry is not an observability backend itself" — it deliberately hands storage/visualization to tools like prometheus, Jaeger, or commercial vendors.
• Signals are still three. Re-verified against the same page 2026-08-12: traces, metrics and logs, unchanged since the 2026-06-09 ingest. Profiles are not named on this page — worth stating because a fourth signal has been in progress upstream for some time, and this doc is where it would show up first. Nothing else on the page moved.

Why it matters here

Two principles: "You own the data that you generate. There's no vendor lock-in" and "you only have to learn a single set of APIs and conventions." Born of the OpenTracing + OpenCensus merger, it's a CNCF project now ubiquitous — the standard that lets the integration-tax seams between telemetry tools actually line up. Distinct from prometheus: OTel produces/ships signals; Prometheus stores/queries metrics.

Semantic conventions line up implementations — eventually

The "line up" promise above rests on semantic-conventions. A 2026-09-25 project post (T3 — the project measuring itself, see that page) puts a number on the lag: a convention reaching stable status is "more of a starting point rather than a finish line," and its own cross-language audit found HTTP's required attributes present almost everywhere but recommended attributes present far less often, years after HTTP itself went stable. This doesn't undo the standard's value; it says the standardized layer is unevenly implemented under the surface, which is exactly the kind of seam this spoke tracks one level up (Kubernetes/CNCF integration). The project's own Ecosystem Explorer now measures that gap instead of leaving it assumed.

Freshness

Re-read against the same page 2026-09-16: definition, three signals (traces, metrics, logs — no profiles on this page), the OpenTracing + OpenCensus merger, "not an observability backend", and the no-lock-in line all hold. No version or date on the page.

Related

observability · service-topology · prometheus · platform-engineering · netflix-service-topology · platform-ops · semantic-conventions · otel-ecosystem-explorer · exploring-instrumentation-ecosystem