opentelemetry-rust: the Rust OpenTelemetry SDK, its crates and its gaps

What opentelemetry-rust is for, and who should reach for it

This repository is the Rust implementation of OpenTelemetry, the vendor-neutral telemetry standard. Its job is to let a Rust service emit traces, metrics and logs through one API and then hand that data to whatever backend you already run. The README lists Prometheus and Jaeger as examples of analysis tools, and the OTLP exporter page points at the OTel Collector, Jaeger, Prometheus and vendor endpoints as destinations.

The audience is narrower than the topic list suggests. If you maintain a Rust library, you depend on the opentelemetry API crate alone and stay out of the SDK. If you maintain a service, you add opentelemetry-sdk and an exporter. If you are starting fresh and want logging, the README is explicit that OpenTelemetry Rust is not introducing a new end user callable Logging API; it recommends tracing as the logging API and offers appenders that bridge tracing and log records into the OpenTelemetry data model. That recommendation is the single most useful sentence in the README, because it tells you the project does not intend to compete with the logging crates you already use.

The crate split: API, SDK, exporters and appenders

The workspace is organised so that instrumentation and configuration are separate dependencies. The opentelemetry crate holds the API surface: Context, Baggage, Propagators, the Logging Bridge API, Metrics API and Tracing API. The opentelemetry-sdk crate holds the SDK implementation, including the Logging SDK, Metrics SDK and Tracing SDK, plus propagator implementations.

Around those two sit the pieces that move data. opentelemetry-otlp sends logs, metrics and traces in OTLP format. opentelemetry-stdout writes to stdout, and the README describes it as being for learning and debugging. opentelemetry-http holds utility functions for exporting and propagating over http. opentelemetry-prometheus provides a pipeline and exporter for metrics. opentelemetry-appender-log and opentelemetry-appender-tracing bridge the log and tracing crates into OpenTelemetry. opentelemetry-propagator-b3 carries B3 propagation, and opentelemetry-semantic-conventions carries the attribute names.

One entry in the repository root deserves attention before you copy any dependency list from an older tutorial: opentelemetry-zipkin still exists as a directory, but the workspace members list does not include it, and a comment in the root Cargo.toml says the exclusion is to retain migration documentation for the removed crate. The Zipkin topic tag on the repository is therefore historical, not a statement that the Zipkin exporter is maintained here.

Installing opentelemetry-rust and a first OTLP export

The project is distributed as crates. The README's Getting Started section points newcomers at the examples directory: logs-basic, metrics-basic and tracing-grpc, plus dedicated OTLP examples for HTTP and gRPC under opentelemetry-otlp/examples. Those examples are the install instructions; there is no separate installer.

Start by adding the API and SDK crates. The repository does not pin a single version string in the README, so take the current release line from the releases list (opentelemetry 0.33.0) and keep the API and SDK on the same line:

cargo add opentelemetry opentelemetry-sdk

For a service that reports over OTLP, add the exporter crate. The README's OTLP examples are the reference for feature flags and pipeline configuration, and the exporter crate is where those live:

cargo add opentelemetry-otlp

If you only want to see telemetry on your terminal while wiring things up, the stdout exporter is the one the README describes as being for learning and debugging:

cargo add opentelemetry-stdout

After that, the shape of a first run is: build a tracer or meter provider from opentelemetry-sdk, attach the exporter, install the provider globally, then emit spans or instruments through the opentelemetry API. The runnable versions of that sequence are the examples in examples/tracing-grpc, examples/metrics-basic and examples/logs-basic; copy from there rather than from blog posts, because the API has moved across 0.x releases and the examples track the current one. For log records, the README's guidance is to keep using tracing or log and add opentelemetry-appender-tracing or opentelemetry-appender-log rather than calling an OpenTelemetry logging API directly.

Stability is per component, and traces are the weakest link

The README carries a status table, and it is worth reading as a risk register rather than a feature list. Metrics-API and Metrics-SDK are Stable. Logs-API, Logs-SDK and Logs-Appender-Tracing are Stable. Baggage is RC, and the OTLP exporters for logs and metrics are RC. Then come the entries that matter for most adopters: Traces-API and Traces-SDK are both Beta, and the Traces-OTLP Exporter is Beta. Context and Propagators are Beta as well, and the Prometheus exporter is Beta.

That ordering is unusual. Distributed tracing is the signal most teams adopt OpenTelemetry for, and in this repository it is the least settled of the three. The README notes that some components include unstable features documented in their respective crate documentation, so the table is a floor, not a ceiling. Practically, this means a tracing setup built on 0.33.0 can change shape in a later 0.x release, and the VERSIONING.md file at the repository root is where the project states its guarantees. Read it before you decide how tightly to couple your application code to the SDK types.

There is a second, quieter limitation. The README does not document rollback, deprecation windows or a migration path for removed crates beyond the Zipkin case, where the workspace keeps the directory only for migration documentation. If you are on an older exporter that has since been dropped, the repository tells you it is gone but does not tell you what replaces it in that same file.

opentelemetry-prometheus versus the OTLP path

The two realistic export strategies in this repository pull in opposite directions. The OTLP route uses opentelemetry-otlp and pushes telemetry to a collector or a backend that accepts OTLP. The Prometheus route uses opentelemetry-prometheus, which the README describes as a pipeline and exporter for sending metrics to Prometheus; the metrics are exposed for Prometheus to scrape rather than pushed.

The difference is not cosmetic. Push export means your process decides when data leaves and needs a reachable endpoint; if the endpoint is down, the exporter is the thing that has to cope. Scrape export means the data sits in the process until Prometheus asks for it, which fits environments where Prometheus already discovers targets and where you do not want an outbound dependency from every service. The trade-off is that opentelemetry-prometheus is Beta and covers metrics only, so a service that also wants traces still needs a second exporter. Teams that already run Prometheus and only care about metrics can stop there; teams that want one pipeline for all three signals are on the OTLP path, with the Beta label that comes with it.

Maintenance, versions and what Apache-2.0 means here

The repository is not archived, and the last push was on 2026-09-24. The most recent releases are opentelemetry-propagator-b3 0.33.0 on 2026-09-22 and opentelemetry 0.33.0 on 2026-09-18, with opentelemetry-semantic-conventions 0.32.1 on 2026-06-26. Release cadence is therefore current, but the version numbers themselves are the upgrade cost: the whole family sits on 0.x, and the API and SDK crates are released in lockstep, so a bump is a coordinated bump across every opentelemetry crate in your dependency graph.

The licence is Apache-2.0, which is a permissive licence and is the same licence the wider OpenTelemetry project uses; the repository carries a FOSSA licence and security badge and an OpenSSF Best Practices badge. Nothing in the README adds a contributor licence agreement, a commercial tier or a usage restriction. This is a description of what the repository states, not legal advice; if your organisation has rules about permissive licences, run the dependency through your own review rather than treating the badge as a substitute.

Editorial conclusion

Adopt opentelemetry-rust if you are instrumenting Rust services that already report to an OTLP endpoint or a Prometheus scrape target, and if you can live with Traces-API and Traces-SDK still marked Beta in the project's own status table. Do not adopt it expecting a new end-user logging API: the project deliberately provides only a Logs Bridge API and points new code at tracing. Before you commit, verify three things in the repository itself: which crate versions you will pin, whether opentelemetry-zipkin is still in your dependency tree (the workspace Cargo.toml excludes it and keeps only migration documentation), and what the VERSIONING.md file says about the stability guarantees behind the 0.33.0 release line.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. open-telemetry/opentelemetry-rust on GitHub
3. Project website
4. README
5. Releases