A highly configurable logging framework for Rust, modeled after Java's Logback and log4j.
log4rs is a highly configurable logging framework for Rust applications, modeled after Java's Logback and log4j. It provides fine-grained control over log output through external configuration files, allowing developers to manage logging behavior without recompiling their code. The framework supports logging to multiple destinations, hierarchical loggers, file rotation, and compression.
Rust developers who need enterprise-grade, runtime-configurable logging for applications such as servers, long-running services, or WebAssembly projects. It is particularly suited for those familiar with Java logging ecosystems like Logback or log4j.
Developers choose log4rs for its familiar configuration patterns from Java logging libraries, its powerful runtime configurability via YAML/JSON files, and its comprehensive feature set including file rotation, compression, and WASM compatibility. It offers a structured alternative to Rust's simpler logging crates.
A highly configurable logging framework for Rust
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Allows logging behavior to be adjusted via external YAML/JSON files without recompiling, as demonstrated in the quick start example with init_file.
Supports setting different log levels for specific modules, enabling fine-grained debugging, as shown in the YAML configuration with loggers for app::backend::db.
Includes automatic file rotation based on size or time and optional compression with gzip or zstd, helping manage disk space, though with performance caveats.
Compatible with WebAssembly targets for logging in browser or edge applications, making it versatile for modern Rust deployments.
The README admits that enabling gzip or zstd features can cause substantial performance hits during file rotation, requiring workarounds like background_rotation or avoiding compression.
For WASM targets with the time_trigger feature, specific compiler flags (--cfg getrandom_backend='wasm_js') are needed, adding complexity and potential tooling issues.
Relies on external configuration files, which can introduce deployment and management challenges compared to code-based logging setups, especially in containerized environments.