DEV.co
Open-Source Observability · rust-lang

log

The `log` crate is a lightweight logging facade for Rust that provides a unified API for libraries and applications. Instead of each library choosing its own logging backend, `log` abstracts the logging interface, letting end users select their preferred implementation (env_logger, fern, log4rs, etc.). It has been maintained since 2014 and is widely adopted in the Rust ecosystem.

Source: GitHub — github.com/rust-lang/log
2.5k
GitHub stars
287
Forks
Rust
Primary language
Apache-2.0
License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

FieldValue
Repositoryrust-lang/log
Ownerrust-lang
Primary languageRust
LicenseApache-2.0 — OSI-approved
Stars2.5k
Forks287
Open issues17
Latest release0.4.33 (2026-06-20)
Last updated2026-06-24
Sourcehttps://github.com/rust-lang/log

What log is

A zero-cost abstraction facade that decouples logging APIs from concrete implementations via compile-time trait-based dispatch. Provides macros (info!, warn!, error!, etc.) for structured and unstructured logging, with optional support for key-value structured logging via the `kv` feature. Minimal dependencies and designed for both library and application use.

Quickstart

Get the log source

Clone the repository and explore it locally.

terminalbash
git clone https://github.com/rust-lang/log.gitcd log# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Library development

Libraries should use `log` macros directly instead of initializing their own logging backend, allowing consuming applications to control output format and filtering.

Multi-backend logging strategies

Applications needing flexibility to swap or configure logging implementations (dev vs. production, syslog vs. file vs. stderr) without code changes.

Structured logging integration

Projects requiring key-value structured logging can enable the `kv` feature to capture serde-serializable or Debug/Display context alongside log messages.

Implementation considerations

  • Executables must initialize a concrete logger implementation (e.g., env_logger::init()) early in main(); log output before initialization is silently discarded.
  • Libraries should depend only on `log`, never on a specific backend, to avoid forcing users' logging strategies.
  • Minimum supported Rust version (MSRV) is defined in Cargo.toml and explicitly tested in CI; check compatibility before upgrading.
  • Structured logging via `kv` feature requires serde or custom serialization; evaluate performance and dependency footprint for your use case.
  • Logger implementations vary widely in configuration, output format, and performance; select based on application requirements (simplicity, configurability, async support, etc.).

When to avoid it — and what to weigh

  • Single monolithic application with fixed logging needs — If you control the entire application stack and have no library dependencies, using a logging backend directly (env_logger, log4rs) may be simpler than adding a facade layer.
  • Async/high-throughput logging performance critical — While `log` is lightweight, some implementations it delegates to may not support the throughput or latency guarantees required by very high-frequency logging scenarios; benchmark specific backends.
  • Compile-time initialization requirements — The facade design assumes runtime initialization of a concrete logger; systems requiring static or const initialization may need custom approaches.
  • No-std/embedded without backend support — The `log` crate itself can be no-std, but you still need a compatible backend implementation; not all standard backends support restricted environments.

License & commercial use

Licensed under Apache License 2.0 (Apache-2.0), a permissive OSI-approved license that permits commercial use, modification, and distribution with attribution and limited liability.

Apache-2.0 is a permissive license explicitly allowing commercial use. No additional licensing review or royalties required for proprietary applications. Redistribution or modification must include a copy of the license and statement of changes.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

SignalAssessment
MaintenanceActive
DocumentationStrong
License clarityClear
Deployment complexityLow
DEV.co fitStrong
Assessment confidenceHigh
Security considerations

The `log` facade itself is minimal and does not process untrusted data; security depends on the chosen backend implementation. Ensure the selected logger does not inadvertently log sensitive data (passwords, tokens) and validates any configuration inputs. No known CVEs reported; long maintenance history suggests thorough community review.

Alternatives to consider

slog (Structured Logging)

More complex but powerful; provides built-in structured logging without a separate `kv` feature, and supports more advanced composable logger chains. Use if you need sophisticated filtering, async sinks, or advanced composition out of the box.

tracing

Modern alternative focused on async/span-based tracing and observability; integrates with Tokio and async Rust better than `log`. Use if your application is async-heavy and requires detailed span and event tracking.

Direct backend use (env_logger, log4rs, fern)

Skip the facade entirely if you control the entire codebase and have no library dependencies. Simpler dependency tree but loses the flexibility to swap backends later.

Software development agency

Build on log with DEV.co software developers

The `log` crate is a battle-tested foundation for logging. Contact Devco to assess backend implementations (env_logger, log4rs, fern) and design a logging strategy that scales with your application.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

Related on DEV.co

Explore the category and the services that help you build with it.

log FAQ

Does `log` produce any output by itself?
No. `log` is a facade; it defines macros and traits but does not implement logging. You must initialize a concrete backend (env_logger, log4rs, etc.) for output to appear. Messages logged before backend initialization are discarded silently.
Can I use `log` in a library?
Yes, and it is the recommended approach. Libraries should depend only on `log` and use its macros. The consuming application then chooses and initializes a concrete backend, giving end users control over logging behavior.
What is the MSRV (minimum supported Rust version)?
Check the `rust-version` field in Cargo.toml of the specific release you plan to use. The MSRV is explicitly tested in CI and may change; any bump is documented in release notes. Current long-term compatibility is a stated priority.
Does `log` support structured logging?
Yes, via the optional `kv` feature. When enabled, you can attach key-value context to log records using serde serialization, Debug, or Display. Not all backends support structured output; verify your chosen implementation.

Work with a software development agency

DEV.co is a software development agency delivering custom software development services to companies building on open source. Our software developers and web developers design, integrate, and ship production systems — spanning web development, APIs, AI, data, and cloud. If log is part of your open-source observability roadmap, our team can implement, customize, migrate, and maintain it.

Ready to integrate structured logging into your Rust project?

The `log` crate is a battle-tested foundation for logging. Contact Devco to assess backend implementations (env_logger, log4rs, fern) and design a logging strategy that scales with your application.