tracing-opentelemetry

tracing-opentelemetry bridges Rust’s tracing instrumentation framework with the OpenTelemetry ecosystem. It provides a tracing-subscriber Layer that converts tracing spans and events into OpenTelemetry spans, metrics, and context, so applications instrumented with tracing can export distributed traces to any OpenTelemetry-compatible backend (Jaeger, Zipkin, OTLP collectors).

Maintained under the tokio-rs organization alongside the core tracing crate, it’s the de facto standard way to get OpenTelemetry-compatible distributed tracing out of a tracing-instrumented Rust service without rewriting instrumentation calls.

What You Get

• OpenTelemetryLayer - a tracing-subscriber Layer that converts tracing spans into OpenTelemetry spans automatically
• OpenTelemetrySpanExt - inject/extract trace context across service boundaries, and set attributes/status/events on the current span
• Optional MetricsLayer (via the metrics feature) for exporting OpenTelemetry metrics from specifically-named tracing events
• Interop with any OpenTelemetry exporter (OTLP, Jaeger, Zipkin) since it only produces standard OpenTelemetry spans

Common Use Cases

• Adding distributed tracing to an existing tracing-instrumented Rust web service (Axum, Actix, Tonic) with minimal code changes
• Exporting traces to Jaeger or an OTLP collector for latency debugging across microservices
• Propagating trace context across async task boundaries and network calls via OpenTelemetrySpanExt
• Emitting OpenTelemetry metrics from tracing events using the optional metrics feature

Under The Hood

Architecture - The crate is a tracing_subscriber::Layer implementation (layer.rs, part of a 4,300-line src/ tree) that hooks into tracing’s span lifecycle callbacks (on_new_span, on_enter, on_close, on_event) and mirrors them into OpenTelemetry Span objects held in an internal registry extension (stack.rs, otel_context.rs); span_ext.rs implements OpenTelemetrySpanExt for cross-boundary context propagation, and metrics.rs provides the optional MetricsLayer. Tech Stack - Built directly on opentelemetry 0.32, tracing/tracing-core/tracing-subscriber 0.3, with optional tracing-log and smallvec dependencies; dev-dependencies include criterion for benchmarking and opentelemetry_sdk’s testing feature for span assertion in tests. Notably the crate’s own version numbers are intentionally decoupled from the opentelemetry crate’s versioning (documented in the README, referencing issue #170), which is an important compatibility gotcha for consumers pinning versions. Code Quality - A dedicated tests/ directory covers parent/child span relationships (parents.rs, follows_from.rs), context propagation (trace_state_propagation.rs), parallel/async spans (parallel.rs), and error handling (errors.rs); five runnable examples/ (including OTLP export and remote-context propagation) double as both documentation and integration smoke tests. API Design - The API surface is intentionally small: one Layer to install (OpenTelemetryLayer::new(tracer)), one extension trait for manual control, and feature flags to opt into metrics. This keeps day-one setup low-boilerplate, though users must independently understand tracing_subscriber’s Layer/Registry model and OpenTelemetry’s SDK setup to wire it together correctly.