opentelemetry-rust: three OTLP exporters at three maturity levels, and a zipkin crate kept only for its migration notes

The three OTLP exporters are at RC, RC and Beta

The status table at the top of the README grades fourteen components, and the exporter rows do not agree with each other. The Logs-OTLP Exporter is RC. The Metrics-OTLP Exporter is RC. The Traces-OTLP Exporter is Beta. So the transport recommended for production is finished for two signals and unfinished for the third, and nothing in the file explains how that distinction should change a deployment decision. The one row further out is the Metrics-Prometheus Exporter at Beta, which is the path taken when the target is Prometheus rather than a collector. The table also notes that some components include unstable features documented in their own crate documentation, so a component marked Stable is not the same as a component without caveats.

Metrics is the only signal with both an API and an SDK at Stable

Reading the table by signal rather than by row gives a clearer shape. Metrics-API and Metrics-SDK are both Stable, which makes metrics the only signal where the whole chain from instrumentation to implementation is settled. Traces, the signal most applications reach for first, sits at Beta in all three of its rows: Traces-API, Traces-SDK and Traces-OTLP Exporter. Logs is the most fragmented case. Logs-API and Logs-SDK are Stable, Logs-Appender-Tracing is Stable, and Logs-OTLP Exporter is RC, so a logs pipeline is stable right up to the point where it leaves the process. Context and Propagators are Beta and Baggage is RC, which are the pieces that carry values across process boundaries.

opentelemetry-zipkin is still in the tree and deliberately kept out of the workspace

The root of the repository still contains a directory for a crate that no longer builds, and the workspace file says so explicitly:

# Retain migration documentation for the removed crate.
exclude = ["opentelemetry-zipkin"]

That is an unusual thing to find and an easy thing to misread. The exclusion means the directory is not a workspace member, so it is not compiled and its code is not part of any release, but the directory is not deleted either, because it holds the migration notes for people moving off it. The member list is written with globs rather than by name, which is why the removal needs an explicit exclusion to stick: the members are the `opentelemetry` crate, a glob for `opentelemetry-*`, globs for examples and for the otlp tests, the top level examples and the stress directory. A directory matching those globs would otherwise be swept in automatically.

propagator-b3 and proto ship releases but are missing from the crate overview

The overview of crates maintained in the repository names nine: the API crate `opentelemetry`, the SDK crate, the OTLP exporter, stdout, http, the log appender, the tracing appender, the Prometheus exporter and the semantic conventions crate. The top level listing holds two more directories that fit the same pattern and are not in that list. `opentelemetry-propagator-b3` is the more consequential omission, because it is the source of the most recent release in the repository at the time of writing, version 0.33.0 published on 2026-09-22. `opentelemetry-proto` is present as well. Both are inside the workspace by way of the glob, so they are built and released; they are simply not described in the section that tells you what the repository contains.

Two dependencies carry open ended lower bounds because a version was yanked

Most entries in the workspace dependency table are caret ranges written as plain strings, but two use a lower bound with no upper limit at all, and the file explains why:

# Using `tracing 0.1.40` because 0.1.39 (which is yanked) introduces the ability to set event names in macros,
# required for OpenTelemetry's internal logging macros.
tracing = { version = ">=0.1.40", default-features = false }
# `tracing-core >=0.1.33` is required for compatibility with `tracing >=0.1.40`.
tracing-core = { version = ">=0.1.33", default-features = false }

The cause is a single feature, the ability to set event names inside tracing macros, which the project needs for its own internal logging. The cost is that these two dependencies can resolve to any future release on the 0.1 line, so a build is not reproducible from the workspace table alone for them, unlike the entries written as 0.1 or 1. The dependency list otherwise mixes three styles, plain versions, tables that turn off default features, and one entry that turns features on, which is worth knowing when you read a resolved lockfile.

The benchmark profile is line-tables-only, and the file argues for it in three lines

One profile is configured in the workspace file and it is about what ends up in profiling output:

[profile.bench]
# https://doc.rust-lang.org/cargo/reference/profiles.html#debug
# See function names in profiling reports.
# 2/true is too much, 0 is not enough, line-tables-only is just right for back traces
debug = "line-tables-only"

The reasoning is stated directly: full debug information produces too much, no debug information produces too little, and line tables alone are what a backtrace needs to name functions. That matters because this project exports traces, so the benchmark numbers it produces and the traces users produce come from the same compiler with the same profile choices. The repository root also carries a rust-toolchain.toml and a rustfmt.toml, so the toolchain and the formatting rules are pinned in files rather than left to the contributor's machine.

The prose names two log appenders and the status table grades one

The logs footnote says the project is not introducing a new end user callable Logging API and instead provides a Logs Bridge API, so that existing logging libraries can be bridged into the OpenTelemetry log data model. Two appenders are then offered for that job: `opentelemetry-appender-log` for the log crate and `opentelemetry-appender-tracing` for the tracing crate. The status table above it grades Logs-Appender-Tracing as Stable and has no row at all for Logs-Appender-Log, even though both directories sit at the top level of the repository. So the table tracks one of the two bridges the footnote describes. The footnote also makes a recommendation, to use tracing as the logging API if you are starting fresh, and notes that this project uses tracing for its own internal logging.

Getting started links three examples and then refers to one

The getting started section sends a newcomer to a logs example, a metrics example or a traces example, one link each, and then says this example demonstrates how to use OpenTelemetry for logs, metrics and traces and display telemetry data on the console. Three separate links are followed by a sentence in the singular, which reads as if one of them covers all three signals. The examples directory holds both basic and advanced variants for logs and metrics, a gRPC tracing example and a tracing example with an HTTP propagator. For anything on the wire, the file points at two OTLP examples, one HTTP and one gRPC, and calls OTLP the recommended exporter for production scenarios, naming the OTel Collector, Jaeger, Prometheus with its OTLP receiver and vendor endpoints as targets.

Editorial conclusion

Adopt this when you are writing Rust and want the OpenTelemetry API with an SDK behind it, and choose your signal by its row in the status table rather than by its popularity. Metrics is the one area with both API and SDK at Stable, so a metrics-only deployment is on firmer ground than a tracing one. Before you commit to an exporter, note that the three OTLP exporters are not at the same level, and that the README recommends tracing as the logging API while this project itself uses tracing for its internal logging. Anything outside the listed crates lives in a separate contrib repository and a registry, not here.

Frequently asked questions

Official sources

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