🦀/⚙️/Logging and Tracing Ecosystem

Logging and Tracing: syslog/printf → log + tracing

What you'll learn: Rust's two-layer logging architecture (facade + backend), the log and tracing crates, structured logging with spans, and how this replaces printf/syslog debugging.

C++ diagnostic code typically uses printf, syslog, or custom logging frameworks. Rust has a standardized two-layer logging architecture: a facade crate (log or tracing) and a backend (the actual logger implementation).

The log facade — Rust's universal logging API

The log crate provides macros that mirror syslog severity levels. Libraries use log macros; binaries choose a backend:

// Cargo.toml
// [dependencies]
// log = "0.4"
// env_logger = "0.11"    # One of many backends

use log::{info, warn, error, debug, trace};

fn check_sensor(id: u32, temp: f64) {
    trace!("Reading sensor {id}");           // Finest granularity
    debug!("Sensor {id} raw value: {temp}"); // Development-time detail

    if temp > 85.0 {
        warn!("Sensor {id} high temperature: {temp}°C");
    }
    if temp > 95.0 {
        error!("Sensor {id} CRITICAL: {temp}°C — initiating shutdown");
    }
    info!("Sensor {id} check complete");     // Normal operation
}

fn main() {
    // Initialize the backend — typically done once in main()
    env_logger::init();  // Controlled by RUST_LOG env var

    check_sensor(0, 72.5);
    check_sensor(1, 91.0);
}
# Control log level via environment variable
RUST_LOG=debug cargo run          # Show debug and above
RUST_LOG=warn cargo run           # Show only warn and error
RUST_LOG=my_crate=trace cargo run # Per-module filtering
RUST_LOG=my_crate::gpu=debug,warn cargo run  # Mix levels

C++ comparison

C++Rust (log)Notes
printf("DEBUG: %s\n", msg)debug!("{msg}")Format checked at compile time
syslog(LOG_ERR, "...")error!("...")Backend decides where output goes
#ifdef DEBUG around log callstrace! / debug! compiled out at max_levelZero-cost when disabled
Custom Logger::log(level, msg)log::info!("...") — all crates use same APIUniversal facade, swappable backend
Per-file log verbosityRUST_LOG=crate::module=levelEnvironment-based, no recompile

The tracing crate — structured logging with spans

tracing extends log with structured fields and spans (timed scopes). This is especially useful for diagnostics code where you want to track context:

// Cargo.toml
// [dependencies]
// tracing = "0.1"
// tracing-subscriber = { version = "0.3", features = ["env-filter"] }

use tracing::{info, warn, error, instrument, info_span};

#[instrument(skip(data), fields(gpu_id = gpu_id, data_len = data.len()))]
fn run_gpu_test(gpu_id: u32, data: &[u8]) -> Result<(), String> {
    info!("Starting GPU test");

    let span = info_span!("ecc_check", gpu_id);
    let _guard = span.enter();  // All logs inside this scope include gpu_id

    if data.is_empty() {
        error!(gpu_id, "No test data provided");
        return Err("empty data".to_string());
    }

    // Structured fields — machine-parseable, not just string interpolation
    info!(
        gpu_id,
        temp_celsius = 72.5,
        ecc_errors = 0,
        "ECC check passed"
    );

    Ok(())
}

fn main() {
    // Initialize tracing subscriber
    tracing_subscriber::fmt()
        .with_env_filter("debug")  // Or use RUST_LOG env var
        .with_target(true)          // Show module path
        .with_thread_ids(true)      // Show thread IDs
        .init();

    let _ = run_gpu_test(0, &[1, 2, 3]);
}

Output with tracing-subscriber:

2026-02-15T10:30:00.123Z DEBUG ThreadId(01) run_gpu_test{gpu_id=0 data_len=3}: my_crate: Starting GPU test
2026-02-15T10:30:00.124Z  INFO ThreadId(01) run_gpu_test{gpu_id=0 data_len=3}:ecc_check{gpu_id=0}: my_crate: ECC check passed gpu_id=0 temp_celsius=72.5 ecc_errors=0

#[instrument] — automatic span creation

The #[instrument] attribute automatically creates a span with the function name and its arguments:

use tracing::instrument;

#[instrument]
fn parse_sel_record(record_id: u16, sensor_type: u8, data: &[u8]) -> Result<(), String> {
    // Every log inside this function automatically includes:
    // record_id, sensor_type, and data (if Debug)
    tracing::debug!("Parsing SEL record");
    Ok(())
}

// skip: exclude large/sensitive args from the span
// fields: add computed fields
#[instrument(skip(raw_buffer), fields(buf_len = raw_buffer.len()))]
fn decode_ipmi_response(raw_buffer: &[u8]) -> Result<Vec<u8>, String> {
    tracing::trace!("Decoding {} bytes", raw_buffer.len());
    Ok(raw_buffer.to_vec())
}

log vs tracing — which to use

Aspectlogtracing
ComplexitySimple — 5 macrosRicher — spans, fields, instruments
Structured dataString interpolation onlyKey-value fields: info!(gpu_id = 0, "msg")
Timing / spansNoYes — #[instrument], span.enter()
Async supportBasicFirst-class — spans propagate across .await
CompatibilityUniversal facadeCompatible with log (has a log bridge)
When to useSimple applications, librariesDiagnostic tools, async code, observability

Recommendation: Use tracing for production diagnostic-style projects (diagnostic tools with structured output). Use log for simple libraries where you want minimal dependencies. tracing includes a compatibility layer so libraries using log macros still work with a tracing subscriber.

Backend options

Backend CrateOutputUse Case
env_loggerstderr, coloredDevelopment, simple CLI tools
tracing-subscriberstderr, formattedProduction with tracing
syslogSystem syslogLinux system services
tracing-journaldsystemd journalsystemd-managed services
tracing-appenderRotating log filesLong-running daemons
tracing-opentelemetryOpenTelemetry collectorDistributed tracing