Configuring Logging

1. Understanding Spring Boot's Default Logging

Before we customize anything, let's understand the default setup. Spring Boot provides a "batteries-included" logging experience that works out of the box.

• Logging Abstraction (SLF4J): Spring Boot uses SLF4J (Simple Logging Facade for Java). Think of this as an "interface" for logging. It allows you as a developer to write log statements without being tied to a specific logging library.
• Default Implementation (Logback): Behind the SLF4J facade, Spring Boot uses Logback by default. Logback is a powerful and popular logging framework that is the successor to the widely-used Log4j.

When you run a Spring Boot application, you see log messages printed to the console. Let's break down what a typical log line means.

As you read, the default log output contains several key pieces of information:

• Date and Time: 2025-12-18T16:09:51.374Z
• Log Level: INFO
• Process ID (PID): 117422
• Separator: ---
• Application Name: [myapp] (if spring.application.name is set)
• Thread Name: [main]
• Logger Name: o.s.b.d.f.logexample.MyApplication (usually the abbreviated class name that produced the log)
• The Log Message: Starting MyApplication...

By default, Spring Boot only displays messages at the INFO level and higher (WARN, ERROR). This means DEBUG and TRACE messages are hidden. Let's learn how to change that.

2. Configuring Logging Levels

Controlling log verbosity is crucial. You might want detailed DEBUG logs from your own code while keeping noisy framework logs at the INFO or WARN level. You can do this easily in your application.properties file.

The syntax is logging.level.<logger-name>=<level>. The <logger-name> is typically a Java package or a fully qualified class name.

Here are the most common ways to use this property:

• Set the root log level: This applies to the entire application. It's a good baseline.

  # Set the default log level for all loggers to WARN
  logging.level.root=WARN
  

• Set the level for a specific package: This is very useful for getting more detail from a particular part of your application or a framework.

  # Set Spring's web-related loggers to DEBUG to see more request details
  logging.level.org.springframework.web=DEBUG
  

• Set the level for your application's code:

  # Assuming your application code is in the 'com.myapp' package
  logging.level.com.myapp=TRACE
  

Spring will apply the most specific rule that matches. If you set logging.level.com.myapp=TRACE and logging.level.com.myapp.services.MyService=INFO, then MyService will log at INFO, while other classes in com.myapp will log at TRACE.

The available levels are: TRACE, DEBUG, INFO, WARN, ERROR, FATAL, and OFF (to disable logging completely).

# Set the base level for everything to INFO
logging.level.root=INFO

# Set a more verbose level for the specific service
logging.level.com.example.payment.PaymentService=TRACE

# Reduce noise from Hibernate
logging.level.org.hibernate=ERROR

3. Customizing the Logging Pattern

Now that we can control what gets logged, let's customize how it looks. You can change the log format, add or remove information, and even add colors to make the output more readable.

3.1. Simple Pattern Customization in application.properties

The easiest way to change the log pattern is by using the logging.pattern.console property.

The pattern is defined using placeholders:

• %d{yyyy-MM-dd HH:mm:ss.SSS} - Date and time with a specific format.
• %-5level - The log level, left-justified in a 5-character space.
• [%15.15t] - The thread name, truncated or padded to 15 characters.
• %logger{36} - The logger name, abbreviated to 36 characters.
• %msg - The log message.
• %n - A new line character.

A very useful feature is color-coding, which you can add using the %clr() converter.

Let's create a custom pattern that's a bit more compact and colorful than the default:

# Example of a custom log pattern for the console
logging.pattern.console=%d{HH:mm:ss.SSS} %clr(%-5level) --- [%15.15t] %cyan(%logger{15}): %msg%n

This pattern would produce output like this:

14:30:15.123 INFO  --- [     main] c.e.MyApplication: Starting application...
14:30:17.456 DEBUG --- [nio-8080-exec-1] c.e.p.PaymentSvc: Processing payment...

(Color formatting won't show here, but INFO would be green, PaymentSvc would be cyan, etc., in a supported terminal).

3.2. Advanced Configuration with logback-spring.xml

For complete control over your logging configuration—such as setting up different log formats for console vs. file, configuring log file rotation policies, or filtering logs based on complex criteria—you need to provide your own Logback configuration file.

Spring Boot will automatically detect and use a file named logback-spring.xml if you place it in your src/main/resources directory.

Let's break down the key parts of the logback-spring.xml from the article:

1. <springProperty>: A powerful feature that lets you import values from your application.properties file directly into your Logback configuration. For example, you can define a log file path in application.properties and use it here.

2. <appender>: An appender is a destination for log messages. The two most common types are:

   • ConsoleAppender: Writes logs to the console.
   • RollingFileAppender: Writes logs to a file, with a policy to "roll over" to a new file when the current one gets too big or old.

3. <encoder> and <pattern>: Inside an appender, the encoder specifies how to format the log messages. This is where you define your log pattern, just like you did with logging.pattern.console.

4. <logger>: This tag allows you to configure the log level for a specific package or class, just like logging.level.<name> in properties. You can also specify that this logger should not inherit appenders from the root logger by setting additivity="false".

5. <root>: This is the root logger that applies to the entire application. You set its default log level here and attach one or more appenders to it. In the example, the root logger is configured to send INFO level logs to both the console and a file appender.

Using a logback-spring.xml file gives you ultimate control but is more verbose. For most common use cases, configuring levels and patterns in application.properties is sufficient.

4. Logging to a File

In a production environment, you almost always want to write logs to a file, not just the console. Spring Boot makes this incredibly simple. You only need to set one of two properties in application.properties:

• logging.file.name: Specifies the full path and name of the log file.

  # Log to a file named 'app.log' in the application's root directory
  logging.file.name=app.log
  

• logging.file.path: Specifies a directory where a log file named spring.log will be created.

  # Log to /var/log/my-app/spring.log
  logging.file.path=/var/log/my-app
  

If you set logging.file.name, logging.file.path is ignored. By default, log files will rotate when they reach 10 MB.

Conclusion

In this lesson, you've learned how to take full control of your Spring Boot application's logging. This is a fundamental skill for any backend developer, enabling you to build observable and maintainable systems.

Key Takeaways:

• Spring Boot uses SLF4J with Logback by default.
• You can easily configure logging levels in application.properties using logging.level.<logger-name>=<level>.
• You can customize the console log format with logging.pattern.console and add colors with %clr().
• For complex scenarios, you can provide a logback-spring.xml file for full control over appenders, encoders, and policies.
• Writing to a log file is as simple as setting logging.file.name or logging.file.path.

What's Next?

Now that we can generate detailed, structured logs, the next logical step is to monitor our application's health and behavior in real-time. In our next lesson, we will explore Spring Boot Actuator, which exposes a set of production-ready endpoints to monitor your application. Your well-configured logs will be an invaluable companion to the metrics and health information provided by Actuator.