Cloud Parts

OpenTelemetry

The vendor-neutral standard for producing and shipping traces, metrics and logs, with SDKs for most languages and a Collector to route the data.

What it is
Observability
Used for
Distributed tracing,Metrics,Logs
Type
Open source
Made by
Cloud Native Computing Foundation
License
Apache 2.0
Facts checked
5 October 2026
Website Source code

What it is

OpenTelemetry (OTel) is not a backend: it stores nothing and draws no dashboards. It is the plumbing in front of one. Language SDKs and auto-instrumentation libraries create spans, metrics and log records inside your code, named according to shared semantic conventions (http.request.method, db.system.name), and send them over OTLP, its wire protocol for gRPC and HTTP.

The OpenTelemetry Collector is a separate process that sits between your apps and your backends. Each pipeline chains receivers (OTLP, Prometheus scraping, Kafka and more), processors (batching, filtering, adding Kubernetes pod labels) and exporters (Prometheus, a tracing backend, a commercial vendor). Because the instrumentation is standard, switching backend means changing the Collector’s config, not re-instrumenting every service. OTel was formed in 2019 by merging OpenTracing and OpenCensus, and became a CNCF graduated project in May 2026.

Why teams pick it

  • Instrument once and switch backends freely; many vendors, and Prometheus itself, accept OTLP directly
  • One SDK and one set of conventions for traces, metrics and logs, so a log line can carry the trace ID of its request
  • The Collector can batch, sample, redact and fan out telemetry without touching application code
  • Auto-instrumentation for common frameworks in Java, Python, .NET, JavaScript and others gives traces with little or no code

Watch out for

  • Maturity varies by language and signal: traces and metrics are stable in most SDKs, logs are still in development in several, and profiles are early
  • You still need somewhere to store and query the data; OTel only produces and moves it
  • The Collector has a long list of components and a large config surface; many contrib components are beta or alpha
  • Component names change between Collector releases (for example otlphttp is now otlp_http), so upgrades need care

Alternatives

What all observability have in common →
Amazon CloudWatchAWSAWS’s built-in monitoring service: metrics from every AWS service, logs, alarms and dashboards, and now traces, OpenTelemetry and PromQL, billed per metric, per GB and per alarm.Better StackCommercialUptime checks, on-call paging and status pages, plus logs, traces, metrics and errors in a ClickHouse-based store, sold as one SaaS billed per responder and per GB.ClickStackOpen sourceClickHouse’s open-source observability stack: an OpenTelemetry collector, ClickHouse for storage and the HyperDX UI for search, dashboards and alerts on logs, traces, metrics and session replays.DatadogCommercialA hosted monitoring platform: an agent on every host ships metrics, logs and traces to Datadog’s SaaS, which bills per host, per GB and per metric.GrafanaOpen sourceDashboards and alerts over data that stays where it is: Prometheus, SQL databases, cloud monitoring and more.

How it fits with other technologies

What uses OpenTelemetry

A Collector that receives OTLP and pushes metrics to Prometheus · yaml

receivers:
  otlp:
    protocols:
      grpc: { endpoint: 0.0.0.0:4317 }
      http: { endpoint: 0.0.0.0:4318 }
processors:
  batch:
exporters:
  otlp_http/prometheus:   # Prometheus 3 started with --web.enable-otlp-receiver
    metrics_endpoint: http://prometheus:9090/api/v1/otlp/v1/metrics
service:
  pipelines:
    metrics: { receivers: [otlp], processors: [batch], exporters: [otlp_http/prometheus] }

See it in a real stack

No architecture uses OpenTelemetry yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2010–2026

Google’s 2010 Dapper paper showed how to follow a single request across thousands of machines. In the years after, tracing and monitoring vendors each shipped their own agents and libraries, so instrumenting code meant committing to one vendor, and open-source libraries had no neutral way to add tracing. Two projects set out to fix that. OpenTracing, co-created by Dapper co-author Ben Sigelman, joined the CNCF in October 2016 as a vendor-neutral tracing API. In January 2018 Google open-sourced OpenCensus, a version of its internal Census library that collected both traces and metrics.

They solved the same problem in incompatible ways. As Sigelman and Google’s Morgan McLean wrote: “The biggest problem with either project has been the fact that there were two of them.” In May 2019 the two announced they were merging into OpenTelemetry, a new CNCF sandbox project with governance from Google, LightStep, Microsoft and Uber, and bridges so existing OpenTracing and OpenCensus code would keep working.

Logs joined traces and metrics, its OTLP protocol became a common wire format, and many observability vendors, and Prometheus itself, now accept it directly. OpenTelemetry became the CNCF’s highest-velocity project after Kubernetes and graduated in May 2026.

Why it’s built this way

Separate the API from the SDK
Libraries and frameworks depend only on the small API, which does nothing if no SDK is installed. The application owner then picks the SDK and exporters, so instrumented libraries never force a vendor on anyone.
Not a backend
Storage and visualisation are deliberately left to other tools. The project describes the goal plainly: you own the data you generate, with no vendor lock-in, so you can change backends without re-instrumenting your code.
Merge, with backward-compatible bridges
Rather than start a third standard, the founders combined the two existing ones and promised software bridges, so code already written against either API could move over gradually.

Timeline

  1. 2010

    Google publishes the Dapper paper on distributed tracing

  2. 2016

    OpenTracing joins the CNCF in October

  3. 2018

    Google open-sources OpenCensus in January

  4. 2019

    OpenTracing and OpenCensus merge into OpenTelemetry, a CNCF sandbox project

  5. 2021

    Moves to CNCF incubation in August

  6. 2026

    Graduates from the CNCF in May

Sources13 · facts checked 5 October 2026

Improve this page on GitHub