Crate opentelemetry[][src]

The Rust OpenTelemetry implementation.

OpenTelemetry provides a single set of APIs, libraries, agents, and collector services to capture distributed traces and metrics from your application. You can analyze them using Prometheus, Jaeger, and other observability tools.

Compiler support: requires rustc 1.46+

Getting Started

use opentelemetry::{sdk::export::trace::stdout, trace::Tracer, global};

fn main() -> Result<(), Box<dyn std::error::Error + Send + Sync + 'static>> {
    // Create a new instrumentation pipeline
    let tracer = stdout::new_pipeline().install_simple();

    tracer.in_span("doing_work", |cx| {
        // Traced app logic here...

    global::shutdown_tracer_provider(); // sending remaining spans


See the examples directory for different integration patterns.

Crate Feature Flags

The following core crate feature flags are available:

  • trace: Includes the trace API and SDK (enabled by default).
  • metrics: Includes the unstable metrics API and SDK.
  • serialize: Adds serde serializers for common types.

Support for recording and exporting telemetry asynchronously can be added via the following flags:

  • rt-tokio: Spawn telemetry tasks using tokio’s multi-thread runtime.
  • rt-tokio-current-thread: Spawn telemetry tasks on a separate runtime so that the main runtime won’t be blocked.
  • rt-async-std: Spawn telemetry tasks using async-std’s runtime.

Working with runtimes

Opentelemetry API & SDK supports different runtimes. When working with async runtime, we recommend to use batch span processors where the spans will be sent in batch, reducing the number of requests and resource needed.

Batch span processors need to run a background task to collect and send spans. Different runtime needs different ways to handle the background task.


Tokio currently offers two different schedulers. One is current_thread_scheduler, the other is multiple_thread_scheduler. Both of them default to use batch span processors to install span exporters.

But for current_thread_scheduler. It can cause the program to hang forever if we schedule the backgroud task with other tasks in the same runtime. Thus, users should enable rt-tokio-current-thread feature to ask the background task be scheduled on a different runtime on a different thread.

In addition to opentelemetry, the open-telemetry/opentelemetry-rust repository contains several additional crates designed to be used with the opentelemetry ecosystem. This includes a collection of trace SpanExporter and metrics pull and push controller implementations, as well as utility and adapter crates to assist in propagating state and instrumenting applications.

In particular, the following crates are likely to be of interest:

Additionally, there are also several third-party crates which are not maintained by the opentelemetry project. These include:

If you’re the maintainer of an opentelemetry ecosystem crate not listed above, please let us know! We’d love to add your project to the list!

Supported Rust Versions

OpenTelemetry is built against the latest stable release. The minimum supported version is 1.46. The current OpenTelemetry version is not guaranteed to build on Rust versions earlier than the minimum supported version.

The current stable Rust compiler and the three most recent minor versions before it will always be supported. For example, if the current stable compiler version is 1.49, the minimum supported version will not be increased past 1.46, three minor versions prior. Increasing the minimum supported compiler version is not considered a semver breaking change as long as doing so complies with this policy.



Primitives for sending name-value data across system boundaries.


Utilities for working with global telemetry primitives


OpenTelemetry Labels


OpenTelemetry Metrics API


OpenTelemetry Propagator interface


Provides an abstraction of several async runtimes


OpenTelemetry SDK


OpenTelemetry Tracing API.


Internal utilities



An execution-scoped collection of values.


A guard that resets the current context to the prior context when dropped.


Key used for metric LabelSets and trace Span attributes.


KeyValue pairs are used by LabelSets and Span attributes.


Units denote underlying data units tracked by Meters.



Array of homogeneous values


Value types for use in KeyValue pairs.