Spring Boot Logging: SLF4J, Logback, Structured Logging

Logging is one of those things developers tend to overlook until production breaks and nobody can figure out what happened. Spring Boot comes with sensible defaults, but getting them right for production takes some doing.

This post walks through Spring Boot logging from the SLF4J API through Logback configuration, structured JSON output, and log groups. By the end you’ll have a production-ready setup.

Introduction to Spring Boot Logging

Spring Boot uses Apache Logback as its default logging implementation. Drop in spring-boot-starter and everything wires up automatically.

The logging chain looks like this:

graph LR
    A["Your Code<br/>Logger.info()"] --> B["SLF4J API<br/>org.slf4j"]
    B --> C["Logback<br/>ch.qos.logback"]
    C --> D["Appenders<br/>Console/File/JSON"]

Spring Boot’s ApplicationRunner auto-configures logging from properties in application.properties or application.yml. It also handles bridge libraries from other frameworks (JCL, JUL, Log4j) redirecting everything to SLF4J.

Default Behavior

By default, Spring Boot logs:

• Pattern output to the console
• INFO level and above
• No file rotation by default
• Stack traces for exceptions

You can tweak these with properties, but anything beyond basic changes means writing Logback XML.

SLF4J API and Why It’s the Standard

SLF4J is an abstraction layer over logging implementations. Instead of coupling your code to Logback, Log4j2, or JUL, you write against the SLF4J interface and let the runtime sort out which implementation to use.

Why SLF4J Dominates

Implementation Independence

Your application code depends only on the SLF4J API. Switching from Logback to Log4j2 requires zero code changes.

Unified Bridge Mechanism

Legacy code using JCL (commons-logging), JUL (java.util.logging), or Log4j 1.x gets redirected to SLF4J automatically through the jul-to-slf4j and log4j-over-slf4j bridges.

Parameterized Logging

SLF4J’s parameterized logging skips the string concatenation overhead:

// Avoid this - string concatenation happens even when INFO is disabled
logger.info("User " + username + " logged in from " + ipAddress);

// Do this - only constructs the message if INFO is enabled
logger.info("User {} logged in from {}", username, ipAddress);

Logger Declaration

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

@RestController
public class UserController {

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

    // Or using modern Lombok (recommended)
    @Slf4j
    @RestController
    public class UserControllerV2 {
        // log field is automatically generated
    }
}

Log Levels Hierarchy

Levels from highest to lowest: ERROR, WARN, INFO, DEBUG, TRACE. Spring Boot defaults to INFO, so DEBUG and TRACE stay quiet unless you dial them down.

Logback Configuration and Appenders

When properties stop being enough, you write XML. Spring Boot auto-detects logback-spring.xml on the classpath and uses it instead of its defaults.

Basic Logback Structure

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <include resource="org/springframework/boot/logging/logback/defaults.xml"/>

    <property name="LOG_FILE" value="${LOG_FILE:-${LOG_PATH:-${LOG_TEMP:-${java.io.tmpdir:-/tmp}}}/spring.log}"/>
    <property name="CONSOLE_LOG_PATTERN" value="%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n"/>

    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>${CONSOLE_LOG_PATTERN}</pattern>
        </encoder>
    </appender>

    <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${LOG_FILE}</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
            <fileNamePattern>${LOG_FILE}.%d{yyyy-MM-dd}.%i.gz</fileNamePattern>
            <maxFileSize>10MB</maxFileSize>
            <maxHistory>30</maxHistory>
            <totalSizeCap>1GB</totalSizeCap>
        </rollingPolicy>
        <encoder>
            <pattern>${CONSOLE_LOG_PATTERN}</pattern>
        </encoder>
    </appender>

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

Understanding Appenders

An appender represents a logging destination. Logback ships with several built-in types:

ConsoleAppender - Outputs to System.out or System.err. Production systems typically write to stdout so container orchestrators can capture logs centrally.

FileAppender - Writes to a single file. Never use this alone in production; you need rotation.

RollingFileAppender - The production workhorse. Rotates files based on size, time, or both. The configuration above uses SizeAndTimeBasedRollingPolicy which creates daily files up to 10MB, compresses them, keeps 30 days, and caps total size at 1GB.

AsyncAppender - Wraps another appender and logs asynchronously. Cuts performance overhead but risks losing events if the queue fills.

Console Appender for Production

<appender name="CONSOLE_JSON" class="ch.qos.logback.core.ConsoleAppender">
    <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
        <pattern>{"timestamp":"%d{ISO8601}","level":"%level","thread":"%thread","logger":"%logger{36}","message":"%msg","mdc":%mdc}%n</pattern>
    </encoder>
</appender>

Structured Logging with JSON Format

Text logs work fine locally but become a mess at scale. Structured logging outputs machine-parseable JSON that log aggregation tools (ELK, Splunk, Datadog) can actually query.

logstash-logback-encoder

Add the dependency:

// build.gradle
implementation 'net.logstash.logback:logstash-logback-encoder:7.4'

JSON Appender Configuration

<appender name="JSON_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>${LOG_FILE}</file>
    <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
        <fileNamePattern>${LOG_FILE}.%d{yyyy-MM-dd}.%i.gz</fileNamePattern>
        <maxFileSize>10MB</maxFileSize>
        <maxHistory>30</maxHistory>
    </rollingPolicy>
    <encoder class="net.logstash.logback.encoder.LogstashEncoder">
        <includeMdc>true</includeMdc>
        <includeContext>true</includeContext>
        <includeTags>true</includeTags>
        <customFields>{"service":"user-service","version":"1.0.0"}</customFields>
    </encoder>
</appender>

Adding MDC Context

The Mapped Diagnostic Context (MDC) lets you attach request-scoped metadata:

import org.slf4j.MDC;

@RestController
public class RequestLoggingController {

    @GetMapping("/api/users/{id}")
    public User getUser(@PathVariable String id) {
        MDC.put("requestId", UUID.randomUUID().toString());
        MDC.put("userId", id);

        try {
            log.info("Fetching user");
            return userService.findById(id);
        } finally {
            MDC.clear(); // Always clean up
        }
    }
}

Output looks like:

{
  "timestamp": "2026-06-20T10:15:30.123Z",
  "level": "INFO",
  "thread": "http-nio-8080-exec-1",
  "logger": "c.g.s.c.UserController",
  "message": "Fetching user",
  "requestId": "a1b2c3d4-e5f6-7890",
  "userId": "42",
  "service": "user-service",
  "version": "1.0.0"
}

Spring Boot’s Built-in JSON Support

Spring Boot 3.x can output JSON without third-party libraries using spring-boot-starter-json:

# application.yml
logging:
  pattern:
    console: '{"timestamp":"%d{ISO8601}","level":"%level","logger":"%logger{36}","message":"%msg"}%n'

For production, stick with logstash-logback-encoder for the richer feature set.

Log Groups for Grouped Logger Configuration

Log groups solve a common problem: you want DEBUG for your app classes but WARN for Hibernate. Groups let you bundle loggers together.

Defining Groups

# application.yml
logging:
  group:
    spring: org.springframework, org.springframework.boot
    hibernate: org.hibernate, org.hibernate.validator
    networking: io.netty, org.apache.http, org.springframework.web.client
    myapp: com.geekworkbench, com.mycompany

Using Groups

logging:
  level:
    root: INFO
    spring: WARN
    hibernate: WARN
    networking: DEBUG
    myapp: DEBUG

Instead of configuring each package individually, you flip entire domains with one setting.

Custom Groups in Logback

<configuration>
    <logger name="com.geekworkbench" level="DEBUG"/>
    <logger name="io.netty" level="INFO"/>
    <logger name="org.springframework" level="WARN"/>

    <group name="services">
        <logger name="com.geekworkbench.service"/>
        <logger name="com.geekworkbench.usecase"/>
    </group>

    <group name="data">
        <logger name="com.geekworkbench.repository"/>
        <logger name="org.hibernate.SQL" level="DEBUG"/>
    </group>
</configuration>

Log Levels and Dynamic Adjustment

Static Configuration

The common approach uses application.yml:

logging:
  level:
    root: INFO
    com.geekworkbench: DEBUG
    org.springframework.web: WARN
    org.hibernate: WARN

Per-Environment Configuration

# application-dev.yml
logging:
  level:
    root: DEBUG
    com.geekworkbench: TRACE

# application-prod.yml
logging:
  level:
    root: INFO
    com.geekworkbench: INFO
    org.hibernate.SQL: WARN

Dynamic Level Changes at Runtime

Spring Boot Actuator exposes endpoints for changing log levels at runtime:

management:
  endpoints:
    web.exposure.include: health,info,loggers
  endpoint:
    loggers:
      enabled: true

Query current levels:

curl http://localhost:8080/actuator/loggers/com.geekworkbench

Set a new level:

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

Reset to default:

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

Log Level Change Events

Spring publishes LogLevelChangedEvent when levels change. You can listen for these to trigger notifications or reconfigure external logging systems.

When to Use / When NOT to Use

When to Use Structured Logging

• Production services with log aggregation
• Microservices that need correlation IDs across requests
• Audit logging requirements
• Performance-sensitive paths where string concatenation matters

When NOT to Use Structured Logging

• Simple applications with no aggregation strategy
• Quick prototyping where readability trumps searchability
• When JSON parsing overhead genuinely matters (high-frequency trading systems)

When to Use Async Logging

• Performance-sensitive applications where I/O blocking hurts throughput
• High-volume logging scenarios
• When some log loss is acceptable

When NOT to Use Async Logging

• Financial or compliance systems where every log event must be preserved
• Debugging intermittent failures where dropped logs could lose crucial evidence
• When latency insensitivity makes the complexity not worth it

Common Pitfalls

Pitfall 1: Sensitive Data in Logs

Never log passwords, tokens, credit card numbers, or PII:

// WRONG - credentials end up in logs
log.info("Authenticating user {} with password {}", username, password);

// CORRECT
log.info("Authenticating user {}", username);

Use a MaskingConverter in Logback to automatically redact patterns:

<conversionRule conversionWord="masked" converterClass="com.geekworkbench.logging.MaskingConverter"/>

<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
        <pattern>%d [%thread] %-5level %logger{36} - %masked(%msg)%n</pattern>
    </encoder>
</appender>

Pitfall 2: Logger Name Mistakes

// Common mistake - wrong class reference
public class UserService {
    private static final Logger log = LoggerFactory.getLogger(OtherClass.class);
}

// Correct - logger matches the actual class
public class UserService {
    private static final Logger log = LoggerFactory.getLogger(UserService.class);
}

Pitfall 3: Missing Stack Traces

// WRONG - only prints the message, not the exception
log.error("Database error: " + e.getMessage());

// CORRECT - full stack trace preserved
log.error("Database error", e);

Pitfall 4: Verbose Logging in Hot Paths

// WRONG - string building happens every time
if (log.isDebugEnabled()) {
    log.debug("Processing item {} with params {} and {}", item, params, other);
}

// CORRECT - parameterized logging defers string building
log.debug("Processing item {} with params {} and {}", item, params, other);

Modern SLF4J implementations evaluate parameters lazily, but checking isDebugEnabled() first is still good practice for expensive operations.

Pitfall 5: Forgetting MDC Cleanup

// WRONG - MDC leaks across threads
public void asyncOperation() {
    MDC.put("requestId", requestId);
    doSomethingAsync(); // If this spawns threads, MDC is lost
}

// CORRECT - cleanup in finally or use try-with-resources
public void asyncOperation() {
    try {
        MDC.put("requestId", requestId);
        doSomethingAsync();
    } finally {
        MDC.remove("requestId");
    }
}

Security Notes

Data That Should Never Appear in Logs

Category	Examples	Compliance
Credentials	Passwords, API keys, tokens	PCI-DSS, SOC2
Personal Data	SSN, credit card, health info	GDPR, HIPAA
Session Data	Session IDs (if sensitive)	OWASP
Internal System Details	File paths, internal IPs	Security through obscurity

Log Masking Implementation

public class SecurityMaskingConverter extends ClassicConverter {

    private static final Set<String> SENSITIVE_PATTERNS = Set.of(
        "password", "passwd", "secret", "token", "api_key", "apikey",
        "authorization", "credit_card", "ssn"
    );

    @Override
    public String convert(ILoggingEvent event) {
        String message = event.getMessage();
        for (String pattern : SENSITIVE_PATTERNS) {
            message = message.replaceAll("(?i)(" + pattern + ")=[\\w@#$%^&*]+", "$1=***MASKED***");
        }
        return message;
    }
}

Log Injection Attacks

User input can forge log entries:

// VULNERABLE - attacker controls log output
String username = request.getParameter("username");
log.info("User login attempt: " + username);

// Input: "admin\nINFO Logged out\nINFO User login attempt: "
// Result: Fake log entries injected

// SAFE - sanitize newlines
log.info("User login attempt: {}", username.replaceAll("[\\r\\n]", "_"));

Implementation Snippets

Minimal Production Configuration

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <include resource="org/springframework/boot/logging/logback/defaults.xml"/>

    <property name="LOG_FILE" value="${LOG_FILE:-${LOG_PATH:-${LOG_TEMP:-${java.io.tmpdir:-/tmp}}}/app}"/>

    <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>

    <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${LOG_FILE}.log</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
            <fileNamePattern>${LOG_FILE}.%d{yyyy-MM-dd}.%i.gz</fileNamePattern>
            <maxFileSize>100MB</maxFileSize>
            <maxHistory>14</maxHistory>
            <totalSizeCap>2GB</totalSizeCap>
        </rollingPolicy>
        <encoder>
            <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
        </encoder>
    </appender>

    <springProfile name="!prod">
        <root level="DEBUG">
            <appender-ref ref="CONSOLE"/>
        </root>
    </springProfile>

    <springProfile name="prod">
        <root level="INFO">
            <appender-ref ref="CONSOLE"/>
            <appender-ref ref="FILE"/>
        </root>
    </springProfile>
</configuration>

Conditional Logging with Spring Profiles

<springProfile name="local">
    <logger name="com.geekworkbench" level="TRACE"/>
    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} %clr([%thread]){magenta} %clr(%-5level){highlight}%clr(:){faint} %msg%n</pattern>
        </encoder>
    </appender>
</springProfile>

<springProfile name="kubernetes">
    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <encoder class="net.logstash.logback.encoder.LogstashEncoder">
            <customFields>{"service":"${SERVICE_NAME:-app}","namespace":"${NAMESPACE:-default}"}</customFields>
        </encoder>
    </appender>
</springProfile>

Request Correlation Filter

@Component
@Order(Ordered.HIGHEST_PRECEDENCE)
public class CorrelationIdFilter extends OncePerRequestFilter {

    private static final String CORRELATION_ID_HEADER = "X-Correlation-ID";
    private static final String CORRELATION_ID_MDC_KEY = "correlationId";

    @Override
    protected void doFilterInternal(HttpServletRequest request,
                                    HttpServletResponse response,
                                    FilterChain filterChain) throws ServletException, IOException {
        String correlationId = request.getHeader(CORRELATION_ID_HEADER);
        if (correlationId == null || correlationId.isBlank()) {
            correlationId = UUID.randomUUID().toString();
        }

        MDC.put(CORRELATION_ID_MDC_KEY, correlationId);
        response.setHeader(CORRELATION_ID_HEADER, correlationId);

        try {
            filterChain.doFilter(request, response);
        } finally {
            MDC.remove(CORRELATION_ID_MDC_KEY);
        }
    }
}

Observability Checklist

Basic Setup

• SLF4J is used throughout the application (no direct Logback/Log4j imports in business code)
• Log levels configured per environment (dev=DEBUG, prod=INFO)
• Console appender outputs in all environments
• File appender configured for production with rotation

Structured Logging

• JSON logging enabled in production
• MDC includes requestId or correlationId
• Custom fields (service name, version, environment) included
• Log aggregation tool can parse the JSON format

Security

• Sensitive data patterns defined and masked
• No credentials or PII in log messages
• Log injection attacks prevented (newline sanitization)
• Access to log files restricted

Operations

• Log rotation configured with appropriate retention
• Total size cap prevents disk exhaustion
• Actuator loggers endpoint exposed (internal network only)
• Log level changes trigger alerts or audit events

Performance

• Async appenders considered for high-volume services
• Parameterized logging used (no string concatenation in log statements)
• Expensive objects not logged in hot paths
• Log volume tested under load

Trade-off Table

Decision	Pros	Cons
Text vs JSON logs	Human readable, no parsing overhead	Harder to query at scale
Sync vs Async appenders	No log loss, simpler debugging	Blocks threads during I/O
DEBUG in production	More visibility for troubleshooting	Higher storage costs, potential performance hit
Coarse vs Fine-grained levels	Simpler configuration	Less precise control
File vs Cloud logging	Full control, no vendor lock-in	Infrastructure management burden
Keep vs Rotate logs	Complete history available	Disk usage growth risk

Failure Scenarios

Scenario 1: Disk Full Due to Unbounded Logging

A buggy loop logs every item at DEBUG level. Production has DEBUG enabled. Within hours, disk fills and the application crashes.

Prevention: Set totalSizeCap on rolling policy. Monitor disk usage. Consider async appenders with bounded queues.

Scenario 2: Lost Logs During Rolling

RollingFileAppender holds files open. If the app crashes mid-write during rotation, events in the buffer get lost.

Prevention: Use prudent=“true” mode (slightly slower but safer). Or use an async appender with includeCallerData enabled.

Scenario 3: Sensitive Data Breach via Logs

A developer logs the entire request object including a password field. It ends up in Elasticsearch, indexed and searchable. The password sits in plaintext in log searches.

Prevention: Never log request objects directly. Use SecurityMaskingConverter. Audit log content regularly.

Scenario 4: Log Injection Obscures Attacks

An attacker sends usernames with newlines and fake log markers. The injected content makes it look like the system logged out legitimate users.

Prevention: Sanitize user input before logging. Strip \r, \n, and other control characters.

Scenario 5: MDC Leak Between Requests

A thread pool handles async operations. MDC gets set for one request but never cleaned up. Subsequent requests on the same thread see the wrong correlation ID.

Prevention: Use try-finally to always clear MDC. Consider MappedDiagnosticContextAdapter for automatic cleanup in CompletableFuture chains.

Quick Recap Checklist

• Use SLF4J API exclusively, avoid direct implementation imports
• Configure logback-spring.xml for custom appenders and policies
• Enable JSON structured logging for production environments
• Always include correlation IDs in MDC for distributed tracing
• Define log groups for easier configuration management
• Use parameterized logging (logger.info(“User {}”, id))
• Set appropriate log levels per environment
• Configure log rotation with size and time-based policies
• Never log sensitive data (passwords, tokens, PII)
• Sanitize user input before logging to prevent injection
• Enable Actuator endpoints for runtime level adjustment
• Test logging under load to estimate volume and performance impact
• Review log content during security audits

Interview Questions

Further Reading

• Logback Documentation — Official Logback reference with advanced configuration details
• SLF4J Documentation — SLF4J API reference and best practices
• logstash-logback-encoder — GitHub repository for the Logstash encoder with JSON formatting examples
• Spring Boot Logging Reference — Official Spring Boot logging documentation
• Micrometer Logging Registry — Exporting metrics to logging systems

Conclusion

Spring Boot’s logging infrastructure, built on SLF4J and Logback, provides a powerful and flexible foundation for production-grade observability. The key to effective logging is balancing verbosity with performance: use structured JSON logging in production for machine-parseable output, always include correlation IDs in MDC for distributed tracing, and configure log rotation with appropriate retention policies to prevent disk exhaustion.

Parameterized logging via SLF4J’s {} syntax eliminates string concatenation overhead, and async appenders can absorb I/O spikes in high-throughput services. Never log sensitive data, and always sanitize user input to prevent log injection attacks. Combine Spring Boot’s logging with Micrometer metrics and distributed tracing for complete observability.

---

This post is part of the Spring Boot Learning Path. Next in the series: Spring Boot Testing Strategies.