slog is an ecosystem of reusable components for structured, contextual, extensible and composable logging in Rust, built for Rust developers and teams who need more than the standard log crate provides.

What it is

slog is the core of a logging ecosystem rather than a single library. The core crate defines structured logging with contextual data attached to every event, and the real output functionality lives in separate feature crates such as slog-term for terminal output, slog-async for asynchronous logging, slog-json for JSON output and slog-syslog for syslog. It is hosted under the slog-rs GitHub organization, maintained by original author Dawid Ciężarkiewicz, carries the slog-rs and structured-logging topics, and is published under the Apache-2.0 licence with documentation generated on docs.rs.

The concrete problem it solves is the ceiling of the standard Rust log crate. slog's stated ambition is that if a feature is missing from log, slog should have it, which means structured rather than flat records, contextual and hierarchical loggers, and composable output back ends instead of one fixed destination. The README is explicit that this power comes with a steeper learning curve, and that new feature crates are easy to write and publish, so the ecosystem grows with the requirements of its users.

Key capabilities

• Core structured logging API with the ecosystem's functionality split into feature crates such as slog-term, slog-async, slog-json and slog-syslog.
• slog-term terminal output with automatic TTY detection, colors, and both compact and full output modes.
• slog-async for asynchronous logging, so formatting and output do not block the calling thread.
• slog-json for JSON log output and slog-syslog for logging to syslog.
• sloggers, a third-party wrapper library providing convenience methods for quicker setup.
• Hierarchical and contextual logging, with structured key-value context carried through log records.
• Auto-generated feature and API documentation hosted at docs.rs/slog, with a full overview in examples/features.rs.

Who uses it and how

• Rust projects whose workloads do not use async, where slog's synchronous model is a natural fit.
• Teams that consider a mature, stable and battle-tested code base and API a plus over newer alternatives.
• Applications that need capabilities the competing tracing ecosystem is missing.
• Projects that want contextual and hierarchical logging, where context is attached once and carried through nested loggers.
• Crate authors who publish their own slog feature crates on crates.io, including third-party efforts such as sloggers.

Getting started

Add the slog core crate from crates.io together with the feature crates needed for the chosen output, such as slog-term or slog-json. Full code overview is in examples/features.rs, API details are at docs.rs/slog, and help is available through the slog-rs Gitter channel.

How it compares

Among similar tools, the README names the standard log crate as the library slog extends beyond, and tracing as the competing Rust ecosystem that is already a go-to solution and has better async debugging support plus a larger dev team and community. The README itself recommends considering tracing first, listing cases where slog still fits better: no async benefit, preference for mature and stable code and API, features tracing lacks, and strong performance.

When to use it — and when not to

slog is a library rather than a service, so nothing like a database, object storage or SMTP server has to be operated, but adopters do take on the steeper learning curve and an ecosystem split across many feature crates. Because the README states that the code is reliable while the documentation sometimes could use improvement, expect to read docs.rs pages and ask in the Gitter channel rather than rely on prose guides. Developers working in async-heavy code should not pick slog, since the project's own README points them to tracing.