35 releases (breaking)

0.27.0 Nov 12, 2024
0.25.0 Sep 9, 2024
0.24.0 Jul 15, 2024
0.22.0 Feb 25, 2024
0.1.5 Nov 26, 2019

#7 in Debugging

Download history 810216/week @ 2024-07-31 880632/week @ 2024-08-07 858496/week @ 2024-08-14 965391/week @ 2024-08-21 813117/week @ 2024-08-28 983807/week @ 2024-09-04 987848/week @ 2024-09-11 1056332/week @ 2024-09-18 1141079/week @ 2024-09-25 1185321/week @ 2024-10-02 1177486/week @ 2024-10-09 1262935/week @ 2024-10-16 1323021/week @ 2024-10-23 1181448/week @ 2024-10-30 930648/week @ 2024-11-06 1089962/week @ 2024-11-13

4,794,857 downloads per month
Used in 978 crates (323 directly)

Apache-2.0

255KB
4K SLoC

OpenTelemetry Rust API

OpenTelemetry — An observability framework for cloud-native software.

This crate contains the OpenTelemetry API for Rust.

Crates.io: opentelemetry Documentation LICENSE GitHub Actions CI codecov Slack

Overview

OpenTelemetry is an Observability framework and toolkit designed to create and manage telemetry data such as traces, metrics, and logs. OpenTelemetry is vendor- and tool-agnostic, meaning that it can be used with a broad variety of Observability backends, including open source tools like Jaeger and Prometheus, as well as commercial offerings.

OpenTelemetry is not an observability backend like Jaeger, Prometheus, or other commercial vendors. OpenTelemetry is focused on the generation, collection, management, and export of telemetry. A major goal of OpenTelemetry is that you can easily instrument your applications or systems, no matter their language, infrastructure, or runtime environment. Crucially, the storage and visualization of telemetry is intentionally left to other tools.

Compiler support: requires rustc 1.70+

What does this crate contain?

This crate is basic foundation for integrating OpenTelemetry into libraries and applications, encompassing several aspects of OpenTelemetry, such as context management and propagation, baggage, logging, tracing, and metrics. It follows the OpenTelemetry specification. Here's a breakdown of its components:

  • Context API: Provides a way to manage and propagate context, which is essential for keeping track of trace execution across asynchronous tasks.
  • Propagators API: Defines how context can be shared across process boundaries, ensuring continuity across microservices or distributed systems.
  • Baggage API: Allows for the attachment of metadata (baggage) to telemetry, which can be used for sharing application-specific information across service boundaries.
  • Logs Bridge API: Allows to bridge existing logging mechanisms with OpenTelemetry logging. This is NOT meant for end users to call, instead it is meant to enable writing bridges/appenders for existing logging mechanisms such as log or tracing.
  • Tracing API: Offers a set of primitives to produce distributed traces to understand the flow of a request across system boundaries.
  • Metrics API: Offers a set of primitives to produce measurements of operational metrics like latency, throughput, or error rates.

This crate serves as a facade or no-op implementation, meaning it defines the traits for instrumentation but does not itself implement the processing or exporting of telemetry data. This separation of concerns allows library authors to depend on the API crate without tying themselves to a specific implementation.

Actual implementation and the heavy lifting of telemetry data collection, processing, and exporting are delegated to the opentelemetry-sdk crate and various exporter crates such as opentelemetry-otlp. This architecture ensures that the final application can light up the instrumentation by integrating an SDK implementation.

Library authors are recommended to depend on this crate only. This approach is also aligned with the design philosophy of existing telemetry solutions in the Rust ecosystem, like tracing or log, where these crates only offer a facade and the actual functionality is enabled through additional crates.

Unless you are a library author, you will almost always need to use additional crates along with this. Given this crate has no-op implementation only, an OpenTelemetry SDK is always required. opentelemetry-sdk is the official SDK implemented by OpenTelemetry itself, though it is possible to use a different sdk.

Additionally one or more exporters are also required to export telemetry to a destination. OpenTelemetry provides the following exporters:

OpenTelemetry Rust also has a contrib repo, where additional exporters could be found. Check OpenTelemetry Registry for additional exporters and other related components as well.

Getting started

See docs.

Supported Rust Versions

OpenTelemetry is built against the latest stable release. The minimum supported version is 1.65. 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.

Dependencies

~0.3–1MB
~21K SLoC