santh-tracing

What it does

A consistent tracing setup for Santh CLI tools. One init call (or an InitConfig builder for JSON, compact, file-sink, or deny-by-default modes) installs a subscriber that logs to stderr by default, keeping machine-readable findings on stdout uncorrupted. It adds operation spans through with_op, an optional RedactingWriter that masks secrets line-by-line, and a metrics facade that is a no-op until the prometheus feature is enabled.

Quick start

use santh_tracing::{init, LogLevel};

let _guard = init("mytool", LogLevel::Info);
santh_tracing::tracing::info!("ready");

When to use / When not

Use it as the single tracing entry point for any Santh CLI, so every tool shares the same span shape, stderr discipline, and redaction story.

Do not use it inside a library crate that should stay subscriber-agnostic, and do not reach past it to tracing_subscriber directly; extend InitConfig instead so every tool gains the improvement at once.

Compared to alternatives

Calling tracing_subscriber directly in every binary works but drifts: each tool re-derives filtering, output format, and the stdout/stderr split slightly differently. tracing-bunyan-formatter gives JSON but takes no position on redaction or the findings/logs split. santh-tracing centralises those decisions: stderr by default, a RUST_LOG-or-level filter, a shared secret redactor, and one builder every tool configures the same way.

How it fits in Santh

santh-tracing sits in the libs/general layer, just above santh-error, whose redactor it reuses. CLI crates depend on it (often through santh-cli) for logging and metrics. It depends on no higher layer.

Contributing

Add new output shapes as InitConfig builder methods, not as direct tracing_subscriber calls in tools. Cover each mode with an integration test in tests/ and keep the stderr-by-default and redaction guarantees intact.

License

Licensed under either MIT or Apache-2.0.