What is OpenTelemetry?

OpenTelemetry is an open-source observability framework hosted by the Cloud Native Computing Foundation. It is a merger of the OpenCensus and OpenTracing projects.

OpenTelemetry aims to provide a single standard across all types of observability signals, including traces, metrics, and logs.

OpenTelemetry specifies how to collect and send telemetry data to backend platforms. By providing a common data format and API, OpenTelemetry makes it easier for organizations to share and reuse telemetry data and to integrate with a variety of observability tools and platforms.

The OpenTelemetry architecture promotes flexibility, interoperability, and extensibility, enabling developers to adopt observability practices that meet their specific needs and environments.

Telemetry Data Types

OpenTelemetry supports three primary telemetry data types:

• OpenTelemetry Traces represent the execution path of a request or operation across multiple components and services. They provide detailed timing and context information, allowing developers to understand the flow of requests and identify performance bottlenecks.
• OpenTelemetry Metrics are quantitative measurements of system behavior or resource utilization. They help monitor and analyze performance over time and can be used for alerting, capacity planning, and trend analysis.
• OpenTelemetry Logs contain structured or unstructured textual information about events, errors, and activities that occur within an application. They are useful for debugging, auditing, and troubleshooting.

How to Use OpenTelemetry

The easiest way to get started with OpenTelemetry is to choose a distributed tracing tool (vendor) and follow their documentation. Most vendors provide pre-configured OpenTelemetry distributions that allow you to skip some steps and can significantly improve your experience.

If you are looking for an open-source solution, Jaeger has historically been the default option, but Uptrace provides a more comprehensive UI and may be a better choice for many use cases.

Uptrace is an OpenTelemetry APM that uses the ClickHouse database to store traces, metrics, and logs. You can use it to monitor applications and set up automatic alerts to receive notifications via email, Slack, Telegram, and other channels.

Language Support

OpenTelemetry provides official SDKs for the following programming languages:

Stable SDKs

• Java: Full support for traces, metrics, and logs with auto-instrumentation
• Python: Comprehensive SDK with extensive library instrumentations
• JavaScript/Node.js: Support for both browser and server-side applications
• .NET/C#: Native integration with ASP.NET Core and other .NET frameworks
• Go: Lightweight SDK optimized for performance
• Ruby: Full-featured SDK with Rails and Sinatra support
• PHP: Production-ready with support for popular frameworks
• Swift: Native SDK for iOS and macOS applications
• Rust: Memory-safe implementation with minimal overhead
• C++: Low-level SDK for system programming and embedded applications
• Erlang/Elixir: Designed for distributed, fault-tolerant applications

Experimental/Beta SDKs

• Kotlin: Native support beyond Java interoperability
• Scala: Functional programming support with Akka integration
• Perl: Community-maintained implementation

Each SDK follows the same OpenTelemetry specification, ensuring consistent behavior across languages. Most SDKs include:

• Core API and SDK packages
• OTLP exporters for sending data to backends
• Auto-instrumentation libraries for popular frameworks
• Manual instrumentation APIs for custom telemetry

For language-specific installation and usage instructions, visit the OpenTelemetry Registry.

Migration Guide

If you're currently using OpenCensus or OpenTracing, migrating to OpenTelemetry is straightforward since OpenTelemetry was designed as their successor:

Migrating from OpenTracing

• Compatibility: OpenTelemetry provides backward compatibility through the OpenTracing Shim, allowing gradual migration
• API Changes: Most OpenTracing concepts map directly to OpenTelemetry (Spans, Tracers, SpanContext)
• Migration Path:
  1. Install the OpenTelemetry SDK and OpenTracing Shim
  2. Replace OpenTracing imports with the shim
  3. Gradually refactor to native OpenTelemetry APIs
  4. Update your backend to support OTLP protocol

Migrating from OpenCensus

• Direct Support: OpenTelemetry SDKs include OpenCensus compatibility libraries
• Concept Mapping: OpenCensus Stats → OpenTelemetry Metrics, OpenCensus Trace → OpenTelemetry Trace
• Migration Path:
  1. Install OpenTelemetry SDK with OpenCensus bridge
  2. Configure the bridge to forward OpenCensus telemetry to OpenTelemetry
  3. Incrementally replace OpenCensus instrumentation with OpenTelemetry
  4. Remove OpenCensus dependencies once migration is complete

For detailed migration instructions specific to your language and framework, consult the official OpenTelemetry documentation.

Performance Considerations

Instrumenting your applications adds a small performance overhead:

• CPU overhead: Typically less than 1% for normal instrumentation levels
• Memory usage: Spans and metrics are buffered in memory before transmission
• Network traffic: Depends on sampling rate and data volume; batching is used to minimize impact

Glossary

• OpenTelemetry API: A programming interface that you can use to instrument code to collect telemetry data such as traces, metrics, and logs.
• OpenTelemetry SDK: The official implementation of the OpenTelemetry API that processes and exports collected telemetry to backends.
• OpenTelemetry Instrumentations: Plugins for popular frameworks and libraries that use the OpenTelemetry API to record important operations, such as HTTP requests, database queries, logs, and errors.
• OpenTelemetry Collector: A proxy between your application and a backend. It receives telemetry data, transforms it, and then exports data to backends that can store it permanently. The Collector can also act as an agent that pulls telemetry data from monitored systems, such as OpenTelemetry Redis or filesystem metrics.
• OTLP: The OpenTelemetry Protocol used by the SDK and Collector to export data to backends or other collectors. As a transport, OTLP can use gRPC (OTLP/gRPC) or HTTP (OTLP/HTTP).
• OpenTelemetry Backend: The component responsible for receiving, storing, and analyzing the telemetry data collected by OpenTelemetry. It acts as a central repository or processing pipeline for the data, allowing you to aggregate, query, visualize, and gain insights from the telemetry data generated by your applications.
• OpenTelemetry Jaeger: A project within the OpenTelemetry ecosystem that is often used as a default OpenTelemetry backend for storing, analyzing, and visualizing telemetry data.