OpenTelemetry

Overview

OpenTelemetry is an instrumentation standard and a collector, and the single most important fact about it is what it is not. Its own documentation says plainly that it is not an observability backend, and that storage and visualisation are intentionally left to other tools.

What it actually produces is a specification, a wire protocol, semantic conventions for naming things consistently, language APIs and SDKs, automatic instrumentation, and a collector with a Kubernetes operator.

The protocol is the consequential part. Because everything speaks it, you can instrument once and change backend without re-instrumenting, which is the entire value proposition.

The collector receives, processes and exports, built from receivers, processors, exporters and connectors, deployable beside a service or as a central gateway, and it natively speaks Jaeger and Prometheus formats too.

Stability has two layers that are constantly conflated, and getting this right matters more than any feature list. The specification has its own status per signal, and each language SDK has its own status separately.

At specification level, tracing is fully stable and under long-term support, logging's bridge API and protocol are stable, and metrics are stable in the data model while collector metric pipelines remain experimental.

Per language it is rougher. Traces are stable almost everywhere, metrics are stable in the eight major languages but not in Ruby, Swift or Erlang, and logs are the ragged edge, still in development in Python, JavaScript and several others.

Profiles effectively does not exist yet: a protocol in development, and development status in Java alone, so anyone planning on it should plan for a wait.

Its stability promise is worth quoting when you assess risk: existing API calls must continue to compile and function against all future minor versions, with a minimum of three years of support for major API versions.

Key features and capabilities

The same headings are used for every pipeline & infrastructure monitoring entry, so two tools can be read side by side.

What it collects

• Traces, metrics and logs are the three mature signals, with profiles emerging as a fourth
• Baggage carries context rather than telemetry, attaching keys and values to a transaction
• Events are handled as a semantic convention over log records, with experimental API support
• Real user monitoring and synthetics are not signals here; they are product concepts elsewhere
• Everything rests on context propagation, the mechanism that correlates data across services

How data gets in

• The OpenTelemetry protocol is the standard wire format and the most consequential piece for interoperability
• Language SDKs with manual instrumentation, plus automatic instrumentation components
• Instrumentation libraries for common frameworks, contributed across the ecosystem
• The collector receives, processes and exports, and ingests Jaeger and Prometheus formats natively
• A Kubernetes operator and Helm charts, the operator itself at mixed stability

Storage and retention

• None at all, by design, which is the most important fact in this entry
• Retention, cardinality and long-term storage are properties of whichever backend you choose
• The collector buffers and batches in flight but is not a store
• Choosing OpenTelemetry therefore means choosing a backend separately

Querying and dashboards

• None; no query language, dashboards or exploration interface, all intentionally out of scope
• Correlation is enabled through context propagation, trace identifiers and exemplars, but performed elsewhere
• Semantic conventions are what make cross-tool correlation possible, by naming things identically
• Anything that queries your telemetry is a separate product decision

Alerting and incident response

• None; no alert rules, evaluation, routing, on-call or service level objectives exist in the project
• Alerting is entirely a backend responsibility
• This is a deliberate scope boundary rather than a gap to be filled later

Ecosystem and standards

• A collector registry lists every component, each documenting its own stability in its readme
• Jaeger and Prometheus format support is built in, with Prometheus interoperability under joint development
• Datadog ingests the protocol three ways and ships its own collector distribution
• Grafana ships a permissively licensed collector and staffs code owners on the project
• Microsoft describes Application Insights as an OpenTelemetry feature of Azure Monitor

Where it runs and what it costs

• Self-hosted only, and there will never be an OpenTelemetry cloud service by design
• The collector runs beside a service as an agent, or centrally as a gateway
• Core and contrib distributions differ in which components are included
• A Kubernetes operator at mixed stability, spanning alpha and beta component versions
• No unit of pricing, since there is nothing to sell

Pricing

Open sourceFree, Apache 2.0

Free under Apache 2.0, with no paid tier, free-tier limits or trial, because the project has nothing to sell. The cost of adopting it is entirely the backend you send data to, plus the engineering work of instrumenting. The financial argument for it is indirect but real: because the protocol is standard, changing backend later does not mean re-instrumenting your estate, which is leverage in a renewal negotiation with any of the commercial platforms in this category.

Vendor pricing page →

Demos and videos

• Practical guide to manual instrumentation Tutorial · YouTube
• OpenTelemetry channel Channel or playlist · YouTube

About Cloud Native Computing Foundation

OpenTelemetry was accepted into the Cloud Native Computing Foundation in May 2019, became incubating in 2021 and graduated in May 2026, so anything calling it incubating is now out of date. Everything is Apache 2.0 under the foundation's intellectual property policy. Governance splits in two, a governance committee for organisational matters and a technical committee that arbitrates when working groups cannot agree, with around forty special interest groups doing the actual work. Its own mission page is candid that many maintainers are employed by companies with commercial interests in it, and sets out duties to disclose conflicts.

Founded 2019 · opentelemetry.io