What is OpenTelemetry?
OpenTelemetry is an open-source observability framework that provides a unified set of APIs, SDKs, and tools for generating, collecting, and exporting telemetry data—traces, metrics, and logs—from distributed systems to help developers monitor and troubleshoot applications.
Quick Facts
| Full Name | OpenTelemetry (OTel) |
|---|---|
| Created | OpenTelemetry formed in 2019 from the merger of OpenTracing and OpenCensus projects |
| Specification | Official Specification |
How It Works
OpenTelemetry (OTel) is a vendor-neutral CNCF observability framework for instrumenting and transporting traces, metrics, and logs. APIs and SDKs create telemetry, context propagation links work across services, and the Collector receives, filters, batches, redacts, and exports signals to one or more backends. OpenTelemetry does not define application quality or authorization: teams still need business events, service objectives, privacy classification, and evaluation contracts. GenAI semantic conventions live in a standalone repository and remain under Development, so Agent, model, tool, retrieval, and MCP attributes should be version-pinned and treated as evolving. See the <a href="https://qubittool.com/blog/agent-observability-engineering">Agent observability engineering guide</a> for signal boundaries and privacy controls.
Key Characteristics
- Vendor-neutral standard for telemetry data collection and export
- Supports three observability pillars: traces, metrics, and logs
- Provides both automatic and manual instrumentation options
- Language SDKs available for Go, Java, Python, JavaScript, .NET, and more
- Collector component acts as a proxy for receiving, processing, and routing data
- Context propagation enables distributed tracing across service boundaries
Common Use Cases
- Distributed tracing: Track requests across microservices to identify latency bottlenecks
- Application performance monitoring: Collect metrics on response times, error rates, and throughput
- Log correlation: Associate logs with specific traces and spans for contextual debugging
- Infrastructure monitoring: Gather system-level metrics from containers, hosts, and cloud services
- SLO tracking: Define and monitor Service Level Objectives using standardized telemetry
- Migration flexibility: Switch observability backends without re-instrumenting code
Example
Loading code...Frequently Asked Questions
What is the difference between OpenTelemetry and OpenTracing?
OpenTelemetry is the successor to OpenTracing (and OpenCensus). While OpenTracing only provided a tracing API specification, OpenTelemetry offers a complete observability framework covering traces, metrics, and logs with full SDKs, auto-instrumentation, and a collector component. OpenTracing is now archived and all development has moved to OpenTelemetry.
What are the three pillars of observability in OpenTelemetry?
The three pillars are traces (recording the path of requests through distributed systems), metrics (numerical measurements of system behavior over time like latency, error rates, and throughput), and logs (timestamped text records of discrete events). OpenTelemetry provides unified APIs for all three, with context propagation linking them together.
Do I need to change my code to use OpenTelemetry?
Not necessarily. OpenTelemetry provides automatic instrumentation for many popular frameworks and libraries (Express, Spring, Django, etc.) that requires minimal code changes—often just adding a setup file. For custom business logic instrumentation, you would use the manual API to create spans and record metrics at specific points in your code.
What is the OpenTelemetry Collector?
The Collector is a vendor-agnostic proxy that receives telemetry data, processes it (filtering, batching, enriching), and exports it to one or more backends. It decouples instrumentation from backend choice, allowing you to switch observability platforms without modifying application code. It can run as a sidecar, daemon, or standalone service.
Is OpenTelemetry production-ready?
Production readiness is signal-, language-, and component-specific. Check the current OpenTelemetry specification and implementation status for your SDK and Collector components. Core signals may be stable while GenAI and Agent semantic attributes continue to evolve, so pin versions and test schema changes.