DEV.co
Open-Source Observability · google

flogger

Flogger is Google's fluent logging API for Java, designed to unify logging across large codebases. It provides a cleaner, method-chaining syntax with performance benefits for disabled log levels and extensible features for managing complex logging scenarios.

Source: GitHub — github.com/google/flogger
1.5k
GitHub stars
127
Forks
Java
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
Repositorygoogle/flogger
Ownergoogle
Primary languageJava
LicenseApache-2.0 — OSI-approved
Stars1.5k
Forks127
Open issues53
Latest releaseflogger-0.9 (2025-05-16)
Last updated2026-07-06
Sourcehttps://github.com/google/flogger

What flogger is

Flogger is a fluent-interface logging facade for Java that decouples the logging API from backend implementations via pluggable LoggerBackend. It optimizes disabled-level logging to near-zero overhead and supports lazy evaluation, rate limiting, and structured metadata through a chainable method API.

Quickstart

Get the flogger source

Clone the repository and explore it locally.

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

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

Best use cases

Large, multi-team Java codebases

Organizations standardizing on a single logging API across many services to reduce developer cognitive load and unify log format/configuration.

Performance-critical applications with fine-grained debug logging

Systems where disabled log statements must have minimal CPU/memory cost, enabling aggressive use of debug-level logging without performance penalty.

Extensible logging pipelines requiring custom backends

Applications needing to route logs to multiple backends (JSON, structured, cloud platforms) without rewriting application code.

Implementation considerations

  • Requires `com.google.flogger:flogger` and `com.google.flogger:flogger-system-backend` dependencies; backend can be runtime-scoped in modular builds.
  • Logging statements use method chaining (e.g., `logger.atInfo().withCause(exception).log()`), requiring code style updates from existing Log4j/SLF4J patterns.
  • Lazy evaluation via lambdas (e.g., `lazy(() -> expensiveCall())`) must be adopted to realize zero-cost disabled-level logging.
  • Custom backends require implementing `LoggerBackend` interface; standard system backend available but non-trivial for advanced routing (e.g., async, cloud).
  • Rate limiting (`atMostEvery()`) is built-in; verify interaction with existing log aggregation/alerting if duplicate suppression is critical.

When to avoid it — and what to weigh

  • Established codebase heavily invested in Log4j/SLF4J — Migration cost and fragmentation risk if existing code uses another logging facade; Flogger does not provide drop-in compatibility adapters.
  • Non-Java or polyglot environments — Flogger is Java-only; teams with mixed language stacks should consider language-agnostic logging (e.g., structured logging via syslog, CloudLogging).
  • Minimal logging requirements or simple deployments — Projects with basic logging needs may find Flogger's fluent API overhead unnecessary; java.util.logging or simple stdout-only approaches suffice.
  • Strict backward-compatibility requirements — Projects requiring guaranteed API stability across major versions should verify Flogger's versioning policy; v0.9 suggests pre-1.0 status.

License & commercial use

Flogger is licensed under Apache License 2.0, a permissive OSI-approved license allowing commercial use, modification, and distribution with attribution and liability disclaimer.

Apache 2.0 permits commercial use in proprietary software. No patent grants are provided; review Apache 2.0 terms if your product involves patented logging techniques. Google's sponsorship suggests reasonable community governance, but conduct independent legal review for mission-critical deployments.

DEV.co evaluation signals

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

SignalAssessment
MaintenanceActive
DocumentationAdequate
License clarityClear
Deployment complexityLow
DEV.co fitGood
Assessment confidenceHigh
Security considerations

No explicit security audit or vulnerability disclosure policy stated. Logging APIs can leak sensitive data (PII, secrets) if not carefully configured; code review logging statements and use structured fields cautiously. No known CVEs provided in data. Standard Java dependency scanning recommended. Backend implementations must sanitize/filter sensitive output if required.

Alternatives to consider

SLF4J + Logback/Log4j2

Industry standard, mature ecosystem, extensive backend support, widespread team familiarity. Requires adapter code if migrating from Flogger; no lazy-evaluation optimization at API level.

java.util.logging (JUL)

Built-in JDK API, no external dependencies, suitable for libraries. Limited fluent API, fewer features; lower overhead for minimal logging needs but less extensible.

Structured logging libraries (e.g., Timber, Logstash-logback-encoder)

Better support for structured JSON/key-value logging in cloud/observability workflows. More opinionated on output format; may require more configuration for multi-backend scenarios.

Software development agency

Build on flogger with DEV.co software developers

Flogger offers a unified, high-performance logging API with Google's engineering practices built-in. Evaluate it for new projects or large-scale modernization efforts requiring consistent logging.

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.

flogger FAQ

Is Flogger a replacement for SLF4J or Log4j?
Flogger is an independent API facade, not a drop-in replacement for SLF4J. Code using SLF4J must be rewritten to use FluentLogger; there is no bidirectional adapter. Choose Flogger for new projects or those standardizing on a unified API.
What is the performance benefit of disabled-level logging?
Disabled log statements compile to near-zero overhead (constant-time guard checks). This allows aggressive use of fine-grained debug logging without performance penalty, unlike SLF4J which still evaluates arguments unless guard clauses (if logger.isDebugEnabled()) are used.
Can I use Flogger with my existing Log4j2 backend?
Not directly. Flogger requires a LoggerBackend implementation; the standard system backend integrates with JUL, not Log4j2. You would need to implement a custom Log4j2 backend or use the system backend. Verify compatibility requirements before adoption.
Is Flogger production-ready at v0.9?
Pre-1.0 versioning indicates ongoing refinement, but active maintenance and Google's internal use suggest stability for core features. Conduct compatibility testing in your environment; monitor GitHub for breaking changes before upgrading.

Work with a software development agency

Adopting flogger 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.

Standardize Java logging across your team

Flogger offers a unified, high-performance logging API with Google's engineering practices built-in. Evaluate it for new projects or large-scale modernization efforts requiring consistent logging.