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.
Related
observability · service-topology · prometheus · platform-engineering · netflix-service-topology · platform-ops