DEV.co
Open-Source Observability · go-logr

logr

logr is a lightweight logging interface for Go that decouples application code from specific logging implementations. Libraries and applications write logs against a simple Logger API, while actual log output is handled by pluggable LogSink implementations, enabling teams to switch logging backends without changing application code.

Source: GitHub — github.com/go-logr/logr
1.4k
GitHub stars
86
Forks
Go
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
Repositorygo-logr/logr
Ownergo-logr
Primary languageGo
LicenseApache-2.0 — OSI-approved
Stars1.4k
Forks86
Open issues14
Latest releasev1.4.3 (2025-05-28)
Last updated2026-07-05
Sourcehttps://github.com/go-logr/logr

What logr is

logr provides a minimal two-type logging API (Info and Error) with verbosity levels, structured key-value pairs, and helper-function call-depth tracking. It defines Logger (high-level) and LogSink (low-level) interfaces, supports interoperability with Go 1.21+ slog via FromSlogHandler/ToSlogHandler, and includes built-in adapters (funcr, testr) plus community implementations for zap, logrus, zerolog, and others.

Quickstart

Get the logr source

Clone the repository and explore it locally.

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

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

Best use cases

Library and SDK Development

Use logr in libraries to emit diagnostics without forcing consumers to adopt a specific logging framework. Libraries pass a logr.Logger and let the application owner configure the backend.

Kubernetes and Cloud-Native Ecosystems

logr is designed for and widely adopted in Kubernetes projects (klogr integration). Ideal for cloud operators and microservices teams that standardize on structured logging with context passing.

Microservices with Multiple Logging Backends

Centralize logging architecture in main() or a bootstrap package; swap implementations (zap, logrus, zerolog) per environment without touching business logic. Reduces coupling across services.

Implementation considerations

  • Choose a LogSink implementation early (zap/zapr for performance, logrus/logrusr for familiarity, stdr for stdlib simplicity). Document the choice for team consistency.
  • Pass logr.Logger through constructors or struct fields; avoid package-global loggers unless unavoidable. Use logr.WithName() and logr.WithValues() to add context without callback chains.
  • Leverage logr.NewContext() and logr.FromContext() for context-aware logging in middleware or handlers; ensure structured key-value pairs are stable across call chains.
  • If integrating with slog-based code, use FromSlogHandler/ToSlogHandler; note that slog.Handler and logr.Sink cannot be implemented by the same type due to parameter conflicts.
  • Test logging via testr (JSON output) or funcr (function-based) adapters; avoid asserting on log output in unit tests unless integration-level validation is required.

When to avoid it — and what to weigh

  • Simple stdout/stderr Suffices — If your application needs only basic print-to-console logging with no structure, slog (Go stdlib) or even fmt.Printf may be simpler. logr adds abstraction overhead for trivial use cases.
  • Heavyweight Log Aggregation Required Early — logr is an interface, not an aggregation platform. If you need built-in correlation IDs, sampling, or real-time alerting in the core library, use a full logging framework directly.
  • Very High-Volume, Ultra-Low-Latency Logging — logr's abstraction and interface indirection may introduce measurable overhead in microsecond-level latency-critical paths. For extremely high throughput, benchmark against direct implementations.
  • Static Typing of Log Levels Required — logr uses numeric verbosity (V method) and only Info/Error variants. If your team mandates named levels (DEBUG, WARN, TRACE) with compile-time guarantees, slog or a dedicated framework may fit better.

License & commercial use

logr is licensed under Apache License 2.0 (Apache-2.0), a permissive OSI-approved license. Commercial use, modification, and distribution are allowed under the standard Apache 2.0 terms.

Apache-2.0 explicitly permits commercial use without additional licensing. No trademark or patent clauses restrict business deployment. However, standard Apache indemnification clauses apply; review your internal IP policy if bundling with proprietary code.

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

logr is a thin abstraction layer with minimal attack surface. No authentication, encryption, or network I/O in the core library. Security posture depends entirely on the LogSink implementation chosen (e.g., ensure your zap/logrus adapter does not leak secrets in structured fields). Validate that sensitive data is not logged in production or is redacted at the sink level.

Alternatives to consider

slog (Go 1.21+ stdlib)

Native Go logging interface; no third-party dependency. Lacks logr features (Marshaler, WithName, context passing, V-based verbosity), but simpler if you don't need library abstraction or are greenfield-only.

hashicorp/hclog

Full-featured structured logging library with built-in implementations. Less abstraction overhead, but couples libraries to hclog if used directly. Better if you control all logging code.

go.uber.org/zap

High-performance structured logging with typed fields. Can be used directly (no interface layer) or wrapped via zapr. Better for latency-critical or extremely high-volume applications.

Software development agency

Build on logr with DEV.co software developers

logr is production-ready and widely adopted in Kubernetes ecosystems. Review our implementation guide and choose your LogSink backend.

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.

logr FAQ

Should I use logr in a new Go project?
If you are building a library, yes—it prevents coupling consumers to your logging choice. If you are building a monolithic app, slog (stdlib) is simpler unless you plan heavy multi-backend switching or need logr's Marshaler/WithName features.
Can I mix logr and slog in the same codebase?
Yes. Use FromSlogHandler to convert slog.Handler to logr.Logger, or ToSlogHandler to convert logr.LogSink to slog.Handler. Note: slog.Handler and logr.LogSink cannot be implemented by the same type due to Enabled() parameter conflicts.
What is V() and how do I use verbosity levels?
V(N) returns a Logger with increased verbosity. Higher N means less important logs. Use logger.V(1).Info(…) for debug-like logs and logger.Info(…) for standard info. Sink implementation decides whether to filter based on numeric level.
Which LogSink should I pick for my app?
zapr (zap) for performance; logrusr (logrus) for familiar API; stdr (stdlib) for zero extra deps; klogr (Kubernetes) if on k8s. Benchmark latency and throughput against your logging volume.

Work with a software development agency

Adopting logr is usually one piece of a larger software development effort. As a software development agency, DEV.co provides software development services and web development expertise — pairing senior software developers and web developers with your team to design, build, and operate open-source observability software in production.

Ready to decouple your logging?

logr is production-ready and widely adopted in Kubernetes ecosystems. Review our implementation guide and choose your LogSink backend.