Master Java Logging: Levels, Best Practices, and Custom Logback Appender

Java commonly uses four log levels—DEBUG, INFO, WARN, and ERROR. Development environments usually enable DEBUG, while production enables INFO, using popular logging frameworks such as Log4j and Logback.

Effective logging aims to help quickly locate and resolve issues. The article outlines best‑practice guidelines for each level.

1. Basic Logging Standards

DEBUG : Record detailed debugging information, such as request/response payloads, input and output of core methods, and execution flow of loops or branches, enabling issue diagnosis without a debugger.

INFO : Capture overall system or component status, startup processes, and state changes with comprehensive details; performance impact is minimal because modern Logback logging is asynchronous.

WARN : Indicate predictable but undesirable situations, like validation failures, insufficient permissions, or business‑level exceptions that do not require immediate human intervention.

ERROR : Log system‑level failures that need human response; include stack traces and contextual data (e.g., method parameters) to facilitate rapid pinpointing of the problematic code.

2. Advanced Logging for Distributed Systems

In distributed architectures, locating logs across many machines becomes challenging. The classic ELK stack (Elasticsearch, Logstash, Kibana) centralizes logs, often by sending log events to Kafka via a custom Logback appender, then pulling them into Logstash and indexing in Elasticsearch for searchable visualization.

To correlate logs, each entry should contain a unique request identifier. Rather than manually adding this ID everywhere, a custom appender can automatically enrich log events.

2.1 Adding a Request ID to Every Log

Implement a custom Logback appender by extending AppenderBase and overriding its append method. In start(), initialize a Kafka producer. In append(), retrieve the original log event, inject the request ID (often stored in a ThreadLocal or TransmittableThreadLocal set by an HTTP filter), and forward the enriched message to Kafka.

Images illustrating the ELK architecture, log query UI, and the custom appender implementation are shown below: