Spring Boot Logging — Logback Configuration, Log Levels, and Structured Logs
Fast recall
Quick revision
Core answer
logging.level.* properties per package — logging.level.root=WARN plus logging.level.com.example=DEBUG is the typical pattern. For production, structured JSON logging through logback-spring.xml with the Logstash encoder enables log aggregation in ELK, Loki, and Splunk. Spring profiles (logback-spring.xml (not logback.xml) so Spring Boot manages loading and profile support is available.Whether the candidate can configure logging beyond the defaults and understands per-package log levels
Using `logback.xml` instead of `logback-spring.xml`, losing Spring profile support and property placeholders in the logging config
Mention structured JSON logging with Logstash encoder for production, MDC for correlation IDs, and the requirement to clear MDC in a `finally` block to avoid leaking context across pooled threads
Interview-ready guide
Interview answer
Spring Boot uses Logback by default and configures it with sensible defaults — console output at INFO level, pattern-based formatting. Production applications need more: profile-specific levels, structured JSON output, and correlation IDs.
`logback-spring.xml` over `logback.xml`
logback-spring.xmlloads through Spring Boot's logging system — you getapplication.propertieslogback.xmlis loaded by Logback directly before Spring initializes — no profile support, no property access
Property overrides
logging.level.com.example=DEBUGinapplication.propertiesadds debug logging for your packages without touching XML- Combine with profiles:
application-dev.ymlsets DEBUG;application-prod.ymlsets WARN
Production patterns
- Log to stdout in containers — Kubernetes collects it and forwards to your log aggregation system; file logs are lost when pods restart
- Use
logstash-logback-encoderfor JSON output — one JSON object per line, parseable by Elasticsearch and Loki without custom regex - Add MDC fields for distributed tracing:
traceId,spanId,userIdon every log line allow filtering across services - Always clear MDC in a
finallyblock — pooled threads carry stale values otherwise
Runtime debugging
/actuator/loggersPOST flips a package to DEBUG without redeploying — protect with authAsyncAppenderkeeps logging off the critical request path for high-throughput services
Spring Boot Logging — Logback Configuration, Log Levels, and Structured Logs
Direct Answer
Spring Boot uses Logback by default with sensible console output. Log levels are set via logging.level.* properties per package — logging.level.root=WARN plus logging.level.com.example=DEBUG is the typical pattern. For production, structured JSON logging through logback-spring.xml with the Logstash encoder enables log aggregation in ELK, Loki, and Splunk. Spring profiles (<springProfile> blocks) control which configuration applies per environment. Use logback-spring.xml (not logback.xml) so Spring Boot manages loading and profile support is available.
Common Mistakes & Pitfalls
Using logback.xml instead of logback-spring.xml, losing Spring profile support and property placeholders in the logging config
Check your understanding
Answer these without looking back at the article.
- How would you change the log level for a specific package at runtime without redeploying?
- What are the trade-offs between `AsyncAppender` and synchronous appenders?
- How do you avoid logging sensitive data like passwords or PII?
- How does Micrometer Tracing (or Sleuth) populate `traceId` and `spanId` in MDC automatically?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.