OpenTelemetry Rust

opentelemetry-rust is the Rust implementation of the OpenTelemetry observability standard, published as a family of crates rather than a single package: opentelemetry provides the vendor-neutral API surface (spans, metrics instruments, log records, context propagation), opentelemetry_sdk implements the actual collection/export pipeline behind that API, and separate crates handle exporters (opentelemetry-otlp, opentelemetry-zipkin, opentelemetry-prometheus, opentelemetry-stdout) and framework integrations (opentelemetry-appender-tracing, opentelemetry-appender-log, opentelemetry-http).

This workspace structure mirrors OpenTelemetry’s design across every language: application and library authors depend only on the thin opentelemetry API crate to instrument their code, while the actual telemetry backend (OTLP to a collector, direct export to Jaeger/Zipkin, or console output for debugging) is wired up separately at the application’s entry point via the SDK and exporter crates — so instrumented libraries never need to know which observability backend the final application will use.

What You Get

• A vendor-neutral tracing, metrics, and logging API crate (opentelemetry) for instrumenting Rust libraries and applications
• An SDK crate (opentelemetry_sdk) implementing the actual span/metric/log processing and batching pipeline
• OTLP exporter (opentelemetry-otlp) for sending telemetry to any OTLP-compatible collector or backend
• Zipkin and Prometheus exporters, plus a stdout exporter for local debugging
• A tracing-crate appender (opentelemetry-appender-tracing) bridging Rust’s popular tracing ecosystem into OpenTelemetry spans/logs
• W3C Trace Context propagation helpers (opentelemetry-http) for passing trace context across HTTP service boundaries

Common Use Cases

• Instrumenting Rust web services and libraries with vendor-neutral traces, metrics, and structured logs
• Exporting telemetry via OTLP to an OpenTelemetry Collector, Jaeger, Grafana Tempo, or other OTLP-compatible backends
• Bridging existing tracing-crate instrumentation into OpenTelemetry spans without rewriting instrumentation code
• Propagating W3C trace context across HTTP calls between Rust microservices for distributed tracing
• Exporting metrics to Prometheus for scraping alongside existing Prometheus-based monitoring

Under The Hood

Architecture - The repository is a Cargo workspace of 21 top-level crate directories, cleanly separating the API (opentelemetry/src/{trace,metrics,logs,baggage,context,propagation}) from its implementation (opentelemetry-sdk), from transport-specific exporters (opentelemetry-otlp, opentelemetry-zipkin, opentelemetry-prometheus, opentelemetry-stdout), from ecosystem bridges (opentelemetry-appender-tracing, opentelemetry-appender-log, opentelemetry-http). This API/SDK split is the core OpenTelemetry architectural pattern applied consistently across every language SDK, letting library authors depend on the thin API crate without pulling in a specific backend’s export logic.

Tech Stack - Rust, edition 2021, minimum Rust version 1.75.0 per the opentelemetry crate’s Cargo.toml. The workspace uses deny.toml (cargo-deny) for dependency/license auditing and FOSSA for automated license and security scanning per the README’s badges, on top of a GitHub Actions CI pipeline. A stress/ directory holds dedicated stress-testing binaries, and the repo carries both an AGENTS.md and CLAUDE.md, indicating the project has explicitly documented conventions for AI-assisted contributions.

Code Quality - Across the workspace there are 35 Rust source/test files directly under the opentelemetry crate’s src/tests, with additional per-crate test suites in each of the other 20 workspace members; the CNCF-governed OpenTelemetry project mandates rigorous cross-language spec compliance, and this repo’s VERSIONING.md documents its stability guarantees per crate. With 2,600+ stars and very active, consistent commit activity per GitHub health metrics, the project is maintained to CNCF graduated-project standards rather than as an informal community effort.

API Design - The API centers on global::tracer()/global::meter() accessors returning implementations of vendor-neutral Tracer/Meter traits, so instrumented code never directly references OTLP, Zipkin, or any specific backend — only the application’s main() wires a concrete SdkTracerProvider/exporter pair via opentelemetry_sdk. This indirection is the defining trade-off of the OpenTelemetry API: instrumentation code is backend-agnostic and portable, at the cost of an extra initialization/wiring step every application must perform once at startup.