Modern applications rarely run as one thing. A single user request might touch a dozen services, written in different languages, deployed on different infrastructure, owned by different teams. When something breaks, the hard part usually isn’t fixing it. It’s finding out where the problem started. OpenTelemetry exists to solve that visibility problem: a single, vendor-neutral way to generate, collect, and export the telemetry data you need to understand what’s actually happening inside a distributed system.
This page covers the fundamentals: what OpenTelemetry is, how it works, and what it’s used for. For the practices that keep OpenTelemetry data useful and affordable once you’ve adopted it (sampling, cost control, semantic conventions, and more), see our OpenTelemetry Best Practices for 2026 guide.
What is OpenTelemetry?
OpenTelemetry (OTel) is an open-source, vendor-neutral framework for generating, collecting, and exporting telemetry data, traces, metrics, logs, and now continuous profiles, from applications and infrastructure. It began in 2019 as a merger of two earlier projects, OpenTracing and OpenCensus, and has grown into the default observability standard for cloud-native applications. In May 2026, the Cloud Native Computing Foundation (CNCF) graduated OpenTelemetry to Graduated status, the same tier held by Kubernetes and Prometheus. The project now counts more than 12,000 contributors across 2,800+ companies.
What is telemetry data?
Telemetry data is the information a system emits about its own behavior and performance: response times, throughput, error rates, resource utilization, and the events that produced them. It’s what you actually read when you need to answer why a request was slow, or why a service started returning errors at 3am.
Two things make telemetry harder to work with now than it was a decade ago. Distributed architectures spread a single request across many services, so no one machine holds the whole story. And containerized, autoscaled infrastructure means the specific instance that served a request may not exist by the time anyone investigates. OpenTelemetry addresses both by giving every service a consistent way to emit telemetry, in a consistent format, so the pieces can be reassembled into one coherent picture after the fact.
The four signals
OpenTelemetry organizes telemetry data into four signal types:
- Traces follow a single request as it moves across services, showing where time is spent and where failures occur.
- Metrics are numeric measurements over time: request rates, error counts, latency percentiles, and anything else you’d want to graph or alert on.
- Logs are timestamped records of discrete events, structured or unstructured.
- Profiles are OpenTelemetry’s newest signal, capturing continuous CPU and memory usage at the code level. Profiling entered public Alpha in March 2026 and is still maturing. For when to reach for profiling instead of tracing, see Profiling vs Tracing in OpenTelemetry.
All four signals share a common data model, so a trace, a metric, and a log about the same request can be correlated instead of living in separate, disconnected tools.
How does OpenTelemetry work?
OpenTelemetry separates the job of generating telemetry from the job of storing and analyzing it. That separation happens through a few core pieces:
- APIs define how your code creates traces, metrics, and logs, independent of any particular backend.
- SDKs implement those APIs for a given language (Python, Java, Go, JavaScript, .NET, and more) and handle sampling, batching, and export.
- The Collector is a standalone service that receives telemetry from your applications, processes it (filtering, batching, adding metadata), and exports it to one or more backends.
- Receivers, processors, and exporters are the Collector’s building blocks. Receivers accept incoming data in a given format, processors transform or filter it in flight, and exporters send it on to its destination.
Because the API layer doesn’t depend on any specific backend, you can send the same telemetry to different tools (an open-source stack, a commercial platform, or both at once) by changing configuration, not code.
What is OTLP?
OpenTelemetry Protocol (OTLP) is the project’s own wire protocol, and it’s the default way OpenTelemetry data moves from one place to another. It’s vendor and tool agnostic, and it carries traces, metrics, and logs, with profiles being added as that signal matures.
OTLP covers two hops: from the SDK inside your application to the Collector, and from the Collector on to whatever backend you’ve chosen. Because it specifies the encoding, transport, and delivery mechanism rather than leaving those details to each vendor, changing where your telemetry lands is a Collector configuration change instead of a re-instrumentation project.
If you already run tools that emit other formats, Zipkin and Jaeger among them, you don’t have to convert anything first. The Collector has receivers for those formats and can ingest them alongside OTLP data.
OpenTelemetry vs observability: what’s the difference?
The two terms get used interchangeably, and they aren’t the same thing. OpenTelemetry is a tool for producing data. Observability is the outcome you’re trying to reach with it.
| OpenTelemetry | Observability | |
|---|---|---|
| Focus | Collecting telemetry from many sources and exporting it to a target system | Understanding how a system behaves by analyzing that telemetry in context |
| Scope | A standard for collecting and formatting telemetry across languages and platforms | A broader practice covering a system’s interactions, dependencies, and failure modes |
| Approach | Instrumentation plus a standardized data format and API, so different tools interoperate | Telemetry combined with correlation, analysis, and human judgment to find root causes |
OpenTelemetry gives you the raw material. Observability is what you build with it, and that additionally requires storage, querying, correlation, and someone asking the right questions.
Why teams adopt OpenTelemetry
Four reasons OpenTelemetry has become the default choice for new instrumentation work:
- Vendor neutrality. Because OpenTelemetry is a CNCF-governed, open standard, you’re not locked into a single vendor’s proprietary agent or data format. Switching backends is a configuration change, not a re-instrumentation project.
- Broad framework support. Auto-instrumentation exists for popular frameworks including Spring, ASP.NET Core, Express, and Quarkus, so teams get working traces and metrics with minimal code changes before writing any manual instrumentation.
- A common data model. Semantic conventions give telemetry from different services and languages a consistent shape, the same field names for service name, operation name, and more, which is what makes correlation across signals possible in the first place.
- Faster incident resolution. Finding the cause of an incident in a distributed system can take hours when logs are all you have, because each service tells only its own part of the story. OpenTelemetry correlates traces, metrics, and logs across service boundaries, which shortens the distance between noticing a symptom and locating its cause.
What is OpenTelemetry used for?
Tracing requests across microservices
In a distributed system, a single user action can trigger calls across dozens of services. OpenTelemetry’s context propagation carries a request’s identity across those service boundaries, so you can reconstruct the full path a request took and see exactly where it slowed down or failed.
Standardizing telemetry across a mixed stack
Most organizations run more than one language and more than one framework. OpenTelemetry’s cross-language, cross-framework support means teams can instrument Python, Java, Go, and Node.js services the same way, instead of maintaining a different logging and tracing approach per team.
Language-specific instrumentation
Python
OpenTelemetry’s Python SDK supports auto-instrumentation for popular frameworks like Flask, Django, and FastAPI with minimal code changes. Its ecosystem includes instrumentation packages for databases (SQLAlchemy, PostgreSQL), messaging systems (Redis, Kafka), and HTTP clients (requests, aiohttp), with built-in support for context propagation across async operations and configurable sampling strategies.
Java
The OpenTelemetry Java agent provides automatic instrumentation for Spring Boot and Spring MVC applications with no code changes, plus built-in support for servlet containers (Tomcat, Jetty), JDBC database drivers, and integrations with Hibernate, gRPC, and common HTTP clients. Manual instrumentation is available for custom business logic when finer control over span attributes and events is needed.
OpenTelemetry and Apica
OpenTelemetry standardizes how you generate telemetry. It doesn’t decide where that data lives, what it costs to keep, or how you make sense of it once traces, metrics, logs, and profiles are arriving from every service you own. That’s where Apica fits in:
- Apica Flow is OpenTelemetry-native. It ingests OTel data directly, then transforms, normalizes, enriches, and routes it in-stream, through more than 200 pre-built connectors, before it reaches your backend.
- Apica Fleet manages the agents doing the instrumenting: a single control point for OTel Collectors, Fluentd, and Vector across hybrid environments, so agent versions and configs don’t need managing service by service.
- Apica Lake and InstaStore give OTel traces, metrics, and logs long-term, compliant retention with on-demand retrieval, instead of forcing a choice between cost and history.
- Apica Observe correlates OTel traces, metrics, and logs into a single operational view, and Apica Forge stores the resulting high-cardinality metrics without per-metric pricing or cardinality limits.
If you’re instrumenting LLM or agentic workloads with OpenTelemetry’s emerging gen_ai conventions, see Apica’s AI & LLM Observability solution. And for the practices that keep this data useful as it scales, see OpenTelemetry Best Practices for 2026.
Wrapping up
OpenTelemetry has gone from a promising CNCF project to the graduated, de facto standard for observability data in just a few years. The fundamentals stay the same at any scale: a vendor-neutral API, language-specific SDKs, and a Collector that decouples how you generate data from where it ends up.
In a glimpse
- OpenTelemetry is an open-source, vendor-neutral framework for generating and exporting traces, metrics, logs, and profiles.
- It graduated the CNCF in May 2026, the same status held by Kubernetes and Prometheus, with 12,000+ contributors across 2,800+ companies.
- Its architecture separates APIs and SDKs (how you generate data) from the Collector (how you process and route it), and OTLP moves data between them, so backends can change through configuration, not code.
- OpenTelemetry is not the same thing as observability. It produces and standardizes the data; observability is what you build once that data is stored, queried, and correlated.
- Auto-instrumentation is available for major frameworks across Python, Java, and more, giving teams working telemetry before any manual instrumentation.
- Apica pairs OpenTelemetry with agent management (Fleet), pipeline routing (Flow), long-term retention (Lake and InstaStore), correlation (Observe), and metrics storage (Forge) to make that data useful at scale.
