Logging in Spring Boot

Logging is an absolutely critical component of enterprise backend development. It serves as the primary diagnostic tool for monitoring, debugging, troubleshooting, and auditing an application's behavior in production.

Without logging, an application is a black box. If an API crashes, you have no idea why. With robust logging, you simply check the log aggregation system (like Splunk or ELK), pinpoint the exact line of code that failed, and deploy a fix.

---

1. The Spring Boot Logging Architecture

The Default Logging Stack

Question: Which logging framework does Spring Boot use by default?

Answer: Spring Boot uses Logback for routing and formatting logs, operating behind the SLF4J API abstraction layer. This stack is automatically included within spring-boot-starter-logging.

Understanding SLF4J vs. Logback

Feature	SLF4J (Simple Logging Facade for Java)	Logback
Definition	An Abstraction Layer / API. It is NOT a logging framework.	The actual Logging Implementation.
Purpose	Defines the logging contract and interfaces.	Physically formats and writes the logs to files/consoles.
Advantage	If you switch from Logback to Log4j2 in the future, your application code remains completely unchanged.	Highly optimized execution speed and powerful configuration options via logback-spring.xml.

[ Application Code ] | [ SLF4J Interface ] | [ Logback Implementation ] | [ Console Output / application.log ] | [ External Monitoring (ELK / Splunk) ]

---

2. The Log Levels Hierarchy

Every log message is assigned a severity level. When you set a root logging level, Spring Boot displays that level and all levels above it in severity.

Level	Purpose & Production Usage	Example Output
TRACE	Lowest level. Extremely detailed step-by-step execution flows (e.g., method entry/exit). Rarely enabled in production.	TRACE Entering payment gateway method
DEBUG	Developer debugging information (variable states, intermediate results). Usually OFF in production.	DEBUG Found user id = 101
INFO	The default level. Represents standard business events (logins, order creations). Common in production.	INFO User logged in successfully
WARN	Indicates a potential problem or deprecated API usage, but the application hasn't failed yet. Enabled in production.	WARN Disk space is running low
ERROR	Serious failures, database crashes, or unhandled exceptions. Always includes a stack trace. Always enabled.	ERROR Database connection timeout

---

3. Configuring Logs in Spring Boot

Spring Boot allows you to configure logging dynamically via application.properties.

Root Logger

# Sets the global baseline logging level logging.level.root=INFO

With this setting, Spring will log INFO, WARN, and ERROR. It will ignore DEBUG and TRACE to save disk space and CPU cycles.

Package-Level Logging

You can override the root logger for specific packages. For example, if you want to see the raw SQL queries Hibernate is generating:

logging.level.org.hibernate.SQL=DEBUG logging.level.com.yourcompany.service=DEBUG

Logging to Files

By default, Spring Boot only logs to the console. To write logs to a file, configure the file name or path:

logging.file.name=application.log # Or specify a directory and let Spring handle rolling: logging.file.path=/var/logs/myapp

---

4. Writing Logs Using @Slf4j

In older Java codebases, initializing a logger required massive boilerplate in every single class:

private static final Logger logger = LoggerFactory.getLogger(UserService.class);

Modern Spring Boot applications use Lombok to eliminate this. Adding the @Slf4j annotation automatically generates the log variable at compile time.

@Slf4j @Service public class UserService { public void saveUser(User user) { log.info("Saving new user to the database"); } }

---

5. Logging Best Practices (Interview Favorites)

1. Always Use Parameterized Logging

The Concatenation Trap

Bad: log.debug("User Id = " + userId);

Reason: String concatenation executes immediately, wasting CPU cycles and memory creating the String, even if the DEBUG log level is currently turned off!

Good: Use curly braces {} for lazy evaluation.

// Logback injects the variable ONLY if DEBUG is enabled log.debug("User Id = {}", userId); // Handling multiple parameters log.info("User {} logged in from IP {}", userName, ipAddress);

2. How to Log Exceptions Correctly

Bad: log.error(e.getMessage());
This strips away the vital Stack Trace, leaving you blind in production.

Good: Pass the exception object as the final parameter. Logback will automatically extract the message, root cause, and full stack trace.

try { paymentGateway.charge(); } catch (Exception e) { log.error("Payment processing failed for user {}", userId, e); throw e; }

---

6. Advanced Setup: logback-spring.xml

While application.properties is great for basic setups, enterprise applications require complex configurations like rolling log files every 24 hours, keeping a max history of 30 days, or streaming logs directly to ElasticSearch.

Spring Boot automatically detects a file named logback-spring.xml in your src/main/resources folder. If found, it completely hands over logging orchestration to this file.

<configuration> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <!-- Enterprise rolling logic here --> </appender> <root level="INFO"> <appender-ref ref="FILE"/> </root> </configuration>

---

7. Interview Summary Checklist

Quick Memory Refresher

• Default Framework: Logback
• Facade/API: SLF4J
• Lombok Annotation: @Slf4j
• Config Property: logging.level.root=INFO

Top Interview Q&A

Q1: What is the difference between SLF4J and Logback?
A: SLF4J is merely an interface (a facade) defining the logging contract. Logback is the underlying engine that physically executes the logging and writes the files. Using SLF4J allows you to swap underlying engines (like moving to Log4j2) without rewriting application code.

Q2: What is @Slf4j?
A: A Lombok annotation that automatically synthesizes a Logger instance at compile time, removing the need for boilerplate instantiation code.

Q3: Why must we use parameterized logging?
A: Using string concatenation (e.g., "User " + id) evaluates immediately, wasting memory and CPU cycles even if the target log level is disabled. Parameterized logging ("User {}", id) defers evaluation until the framework confirms the log level is active.

Q4: How do you properly log an exception?
A: Provide a descriptive string message as the first parameter, and pass the raw Exception object as the final parameter. This ensures the logging framework prints the entire stack trace alongside your custom context message.