rust-observability

Rust Observability

A log line is a structured event with named fields, and a library never installs a subscriber. This skill governs how Rust code reports what it is doing; what an error type contains is /rust-errors, and span behaviour across cancellation is /async-rust.

A log line is an event, not a sentence

The core move: fields stay fields. error!(user_id, %path, "config load failed") is queryable — user_id and path are named columns. The interpolated form, error!("config load failed for user {user_id} at {path}"), is a string someone will later write a regex against. The difference shows up the first time somebody needs "all failures for one user" — the moment logging either pays for itself or does not.

The three layers, and which to use

println! writes to stdout with no level, no filter, and no structure; it belongs in a CLI producing output the user asked for, never in a library. log is the older facade, right when the dependency budget is tight. tracing is the default here: spans carry context across .await points, which is the problem async code actually has.

Naming events

component.operation.state — config.load.failed, pool.connection.acquired. A consistent scheme is what makes a dashboard possible; ad-hoc English messages are what make it impossible. Message templates with placeholder syntax are one implementation of the field idea, not the idea itself — a codebase already on templates is fine.

Spans

#[tracing::instrument] on a function makes every event inside it inherit the request context; skip keeps large or secret arguments out of the fields. The rule: a span is a unit of work with a beginning and an end; an event is a point in time.

Levels and filtering

• error! — someone should look at this.
• warn! — something went wrong and the code handled it.
• info! — lifecycle events a reader wants without a bug.
• debug! / trace! — developer detail, off in production.

The boundary that matters is error!: because it means someone should look, a handled and expected failure is warn! or debug! at most. EnvFilter gives per-module control, and in a library, filtering is the whole story: