DEV Community: Hermosilla

Rust Observability in 2026: OTLP Logs and Metrics Are Stable—What About Traces?

Hermosilla — Thu, 05 Nov 2026 13:37:39 +0000

Rust has a strong observability ecosystem built around tracing, but getting its events into an observability backend involves a few distinct pieces: spans, log records, metrics, and exporters.

There is a useful milestone in the current OpenTelemetry Rust release that makes this setup more interesting: as of OpenTelemetry Rust 0.33.1, the OTLP exporters for logs and metrics are stable, while the OTLP exporter for traces remains in beta.

That distinction is easy to miss if we just say “OpenTelemetry is stable.” Let’s look at what changed and how it maps to a real Rust service.

What became stable?

The OpenTelemetry Rust 0.33.1 release, published on October 8, 2026, declared the OTLP exporters for Logs and Metrics stable after a release-candidate period. The Traces exporter remains beta.

Signal	OTLP exporter status in 0.33.1
Logs	Stable
Metrics	Stable
Traces	Beta

This is specifically about the OTLP exporters in the Rust implementation—not a blanket statement that every OpenTelemetry crate or API has the same stability guarantee. The release notes also describe the Logs and Metrics APIs and SDK as stable, while Distributed Tracing remains pre-stable.

There is another useful reliability improvement: starting in 0.33.0, OTLP retries are enabled by default for HTTP and gRPC exporters. The default policy uses exponential backoff and jitter, with up to three retries after the first attempt. In other words, a temporary collector hiccup no longer necessarily means an export is immediately lost.

`tracing` events can become either logs or trace data

One source of confusion is that two similarly named integrations do different jobs:

tracing-opentelemetry connects Rust tracing spans and events to OpenTelemetry traces.
opentelemetry-appender-tracing forwards tracing events to the OpenTelemetry Logs pipeline.

Both can be installed as layers on a tracing_subscriber. A log record and a span event are related, but they are not the same telemetry signal; the bridge you choose determines where the event goes.

In our service setup, the key pieces look like this:

let trace_layer = tracing_opentelemetry::layer().with_tracer(tracer);
let log_layer = OpenTelemetryTracingBridge::new(&logger_provider);

The trace provider and logger provider each receive exporters. The metrics provider is separate again: it creates instruments and collects measurements on its configured interval. All three can share the same OpenTelemetry Resource, so telemetry is attributed to the same service name and version.

A small configuration example

The AICC crate wraps provider and subscriber setup behind a builder-style API. With a local OpenTelemetry Collector listening on gRPC port 4317, initialization is just a few lines:

use aicc::o11y::prelude::*;
use tracing::info;

let options = TracingOptions::default()
    .with_service("orders-api", "1.2.0")
    .with_otlp_exporter(OtlpExporterOptions::new("http://localhost:4317"));

let _guard = init_tracing(&options)?;

info!(order_id = 42, "Order accepted");

The exporter options enable all three signals by default. In the implementation, separate builders create the OTLP span, metric, and log exporters, and the resulting providers are attached to the subscriber or registered as global providers where needed.

The returned guard matters. Keep it alive for the lifetime of the application: when it is dropped, it shuts down the providers and flushes pending telemetry. If you create a provider manually, make sure your shutdown path does the equivalent.

A practical detail: exporters can produce telemetry too

The OTLP exporter and its transport stack can emit tracing events of their own. If those events are sent through the log bridge, exporting a log could produce another log, which could trigger another export, and so on.

The service code avoids that feedback loop by filtering infrastructure targets out of the OpenTelemetry log layer. It still allows warnings and errors from that infrastructure to appear in the console layer, which is useful when the collector is unavailable.

This is a small implementation detail, but it is exactly the sort of thing that turns a “hello, telemetry” demo into a setup you can operate.

Metrics are collected when requested

OpenTelemetry observable instruments use callbacks that run during collection. They are a good fit for values such as current CPU or memory usage: the application registers how to read the value, and the SDK asks for it when a metrics reader collects data.

In this project, the server registers observable system metrics using sysinfo. The callbacks refresh and read the relevant values; there is no separate polling task that wakes up just to update gauges. If you adapt the example for your own service, you can add application counters or histograms alongside those system metrics.

One caveat for a demo: the OTLP example initializes all three pipelines and emits spans and log records, but it does not record a custom metric. To demonstrate all three signals end to end, add a metric instrument or run the server path that registers the system metrics.

What should you take away?

OpenTelemetry Rust 0.33.1 is a meaningful point to revisit your observability setup:

Logs and metrics have stable OTLP exporters. That is useful if you want to standardize your output format and backend integration.
Tracing is still beta. Treat its API stability separately rather than assuming every signal has the same guarantee.
Retries are now on by default for OTLP exporters. That improves resilience to transient failures, but it is still worth monitoring exporter errors and having a clear shutdown path.
tracing can feed more than one signal. Use the trace bridge for spans and the appender for OpenTelemetry log records, and filter exporter-generated events to prevent feedback loops.

The interesting question is no longer just “Can Rust send telemetry to OpenTelemetry?” It can. The more useful question is: which signals are stable in the versions you deploy, and what does your application do when the collector is slow or unavailable?

References

What Cargo Generates When You Build a Small Rust Project

Hermosilla — Thu, 05 Nov 2026 13:15:05 +0000

When I first started using Rust, I ran cargo build, saw an executable appear in target/, and moved on. But Cargo creates more than just a binary: it also keeps metadata and intermediate artifacts that help it decide what needs to be rebuilt.

Let's create a tiny project, inspect its build output, and compare a clean build with a repeat build.

1. Create a project

You'll need Rust and Cargo installed. Check with:

rustc --version
cargo --version

Create a binary project and move into its directory:

cargo new cargo-lab
cd cargo-lab

Cargo creates a small project structure:

cargo-lab/
├── Cargo.toml
└── src/
    └── main.rs

Replace the contents of src/main.rs with:

fn main() {
    let message = "Hello";
    println!("{message}, Cargo!");
}

2. Build the project

Run:

cargo build -v

The -v (verbose) option shows more detail, including compiler commands when Cargo runs them. The first build may also create a Cargo.lock file and a target/ directory. The exact output depends on your operating system and Rust toolchain, but the project will look roughly like this:

cargo-lab/
├── Cargo.lock
├── Cargo.toml
├── src/
│   └── main.rs
└── target/
    └── debug/
        └── cargo-lab

The executable is at target/debug/cargo-lab (on Windows, it has an .exe extension). You can build and run the program with one command:

cargo run

3. Look inside `target/debug`

List some of the generated files with:

find target/debug -maxdepth 2 -type f

The exact contents vary by platform, toolchain, and project. You may see:

The executable, such as target/debug/cargo-lab.
deps/, which can contain compiled dependencies and other build artifacts.
.fingerprint/, with metadata Cargo uses to determine whether a package needs rebuilding.
incremental/, when incremental compilation is enabled for the build.
build/, when a dependency or package uses a build script.

Not every project has every directory. This example has no third-party dependencies, so its output is relatively small. Rust's standard library is generally supplied by the installed toolchain; Cargo does not rebuild the standard library from source for every ordinary project build.

4. Why is the second build usually faster?

Without changing any files, run the build again:

cargo build -v

Cargo will usually report that the package is fresh instead of compiling it again. It tracks the inputs and previous build results so it can skip work when nothing relevant has changed.

Now change the message in src/main.rs and build again:

fn main() {
    let message = "Hello from Rust";
    println!("{message}, Cargo!");
}

cargo build -v

Cargo needs to recompile the changed program. In a project with dependencies, changing your own source does not necessarily mean that every dependency must be rebuilt.

5. Measure it on your machine

Build times depend on your machine, Rust version, and previous build artifacts. For a simple comparison, run:

cargo clean
time cargo build
time cargo build

cargo clean removes generated build artifacts from target/; it does not delete your source files. The first timing is for a clean build. The second is for a build with no source changes.

Record your own results:

Run	Time
First build	cargo build 0.17s user 0.12s system 49% cpu 0.581 total
Build with no changes	cargo build 0.02s user 0.02s system 67% cpu 0.049 total

Don't compare these numbers directly with someone else's machine. The useful comparison is between the two runs in the same environment.

You can also ask Cargo for a visual report of build timings:

cargo build --timings

Cargo writes an HTML report under target/cargo-timings/.

6. What changes with `--release`?

Try a release build:

cargo build --release

Its output goes into target/release/, separate from target/debug/. Cargo uses different build profiles for development and release builds. The release profile applies optimizations, which can make compilation take longer while producing a program intended for distribution.

Takeaways

Cargo.toml describes the package and its dependencies; Cargo.lock records the resolved dependency versions.
target/ contains generated outputs: executables, intermediate artifacts, and metadata.
Cargo checks whether previous outputs can be reused, so a build with no changes usually does much less work.
Debug and release builds use separate output directories and profiles.

You generally don't need to commit target/ to Git because Cargo can regenerate it. Projects created with cargo new normally include it in .gitignore.

Your turn: How long does a clean build take on your machine, and how long does the second build take? What does cargo build -v report after you change only main.rs?