What is OpenTelemetry?
OpenTelemetry is an open-source observability framework. It defines how applications produce telemetry — traces, metrics, logs, and profiles — and how that data travels to any backend that understands the OpenTelemetry Protocol (OTLP).
It exists because instrumentation used to be vendor-specific. Switching monitoring vendors meant re-instrumenting every service. OpenTelemetry separates the two: your code emits telemetry through a standard API, and where it goes is a configuration change.
The project is the result of merging OpenCensus and OpenTracing, and it graduated from the Cloud Native Computing Foundation in May 2026 — the CNCF's highest maturity level, indicating a stable governance model and broad production use.
Where to start
The right entry point depends on what you are trying to do.
| Your situation | Start here |
|---|---|
| I have an application and want it instrumented | Get started with your language — SDK setup for Go, Python, Java, JavaScript, .NET, Ruby, PHP, Rust, and others |
| I need to collect data from infrastructure or existing agents | Data ingestion methods — Collector, Prometheus, CloudWatch, Vector, eBPF, and more |
| I use a specific framework or library | Integration guides — framework-level instrumentation |
| I want to understand how it works first | Continue on this page, then architecture |
| I have it running in Kubernetes | OpenTelemetry Operator — Collectors and auto-instrumentation as custom resources |
| I need to configure the SDK | Environment variables — endpoint, sampler, propagators, batching |
| Nothing is arriving in my backend | Troubleshooting — find which stage drops the data |
The four signals
OpenTelemetry started with three signals and added a fourth. They answer different questions about the same system.
| Signal | What it tells you | Maturity |
|---|---|---|
| Traces | The path of a request across services, and where time went | Stable |
| Metrics | Aggregated numbers over time: rates, durations, resource use | Stable |
| Logs | What the code reported while handling a request | Spec stable, SDK maturity varies by language |
| Profiles | Which functions were consuming CPU or memory | Public alpha |
Traces, metrics, and logs share the same resource and attribute model, which is what makes correlation possible: a log line carries the trace_id of the request that produced it, and a profile sample carries the span_id that was active when it was taken.
Signal maturity differs per language. Check the official status page before adopting one in production — logs in particular are Stable in Java and .NET while still in development in Python and JavaScript.
Core components
| Component | Role |
|---|---|
| API | What your code calls to create spans, record measurements, and emit logs. Ships with no-op implementations, so a library can depend on it without forcing an SDK on its users. |
| SDK | The implementation behind the API: sampling, batching, resource detection, export. |
| Instrumentation libraries | Ready-made instrumentation for frameworks and clients — HTTP servers, database drivers, message queues. Most of your telemetry comes from these, not from code you write. |
| Collector | A standalone process that receives, transforms, and exports telemetry. Used as an agent next to your services or as a gateway in front of a backend. |
| OTLP | The wire protocol, over gRPC or HTTP. |
Backends are deliberately outside the project: OpenTelemetry produces and delivers the data, and storage and querying belong to whatever you point it at. See top OpenTelemetry backends.
Language support
Every SDK implements the same specification, so concepts and configuration transfer between languages. Each provides the API and SDK packages, OTLP exporters, instrumentation libraries for common frameworks, and manual instrumentation APIs.
Migrating from OpenTracing or OpenCensus
OpenTelemetry is the successor to both projects, and both are archived. Neither receives fixes.
From OpenTracing
Concepts map almost directly — spans stay spans, tracers stay tracers, SpanContext stays SpanContext. The main differences are that OpenTelemetry adds metrics and logs, and that context propagation is standardized on W3C Trace Context rather than being per-vendor. For a feature-by-feature breakdown, see OpenTelemetry vs OpenTracing.
A shim lets both coexist during migration:
- Add the OpenTelemetry SDK and the OpenTracing shim
- Point existing OpenTracing calls at the shim, so they produce OpenTelemetry spans
- Replace call sites with the native API as you touch them
- Remove the shim once nothing uses OpenTracing directly
Traces stay connected throughout, because the shim emits real OpenTelemetry spans.
From OpenCensus
OpenCensus Stats become OpenTelemetry Metrics and OpenCensus Trace becomes OpenTelemetry Trace. Bridge packages forward OpenCensus telemetry into an OpenTelemetry pipeline, so you can switch the export path first and rewrite instrumentation later.
The one thing to plan for is metric semantics: OpenCensus views and OpenTelemetry views differ enough that aggregations should be verified rather than assumed equivalent.
Performance overhead
Instrumentation is not free, but for most applications the cost is small relative to the work being measured:
- CPU — typically under a few percent with default instrumentation. Auto-instrumentation of very hot paths, such as a per-row database callback, is where it becomes measurable.
- Memory — spans and metrics are buffered before export. The batch processor's queue size sets the ceiling.
- Network — proportional to span volume, which sampling controls directly. Batching amortizes request overhead.
If overhead matters, measure it on your own workload: figures depend far more on how much you instrument than on which SDK you use.
Glossary
- API — the interface your code calls to create telemetry. Separate from the SDK so libraries can be instrumented without dictating a runtime.
- SDK — the implementation of the API that processes and exports telemetry.
- Instrumentation — code that records operations such as HTTP requests, database queries, and errors. Either automatic (an agent or wrapper) or manual (calls you write).
- Collector — a proxy between applications and a backend. Receives, transforms, and exports telemetry, and can also pull data from monitored systems.
- OTLP — the OpenTelemetry Protocol, used to export data over gRPC or HTTP.
- Semantic conventions — standard attribute names, such as
http.request.method, that make telemetry portable across languages and tools. - Resource — attributes describing what produced the telemetry:
service.name,service.version,host.name. - Context propagation — passing trace identifiers across service boundaries so separate spans form one trace.
- Sampling — recording a subset of traces to control cost.
- Backend — the system that stores and queries telemetry. Not part of OpenTelemetry.
What's next?
- Get started with OpenTelemetry — instrument an application
- OpenTelemetry architecture — how the pieces fit together
- OpenTelemetry distributed tracing — the most-used signal, in depth
- OpenTelemetry APM — using the collected data
- OpenTelemetry Collector — configuration, exporters, Prometheus, and host metrics