Spring Boot uses Commons Logging for all internal logging, but leaves the underlying log implementation open. Default configurations are provided for Java Util Logging, Log4J2 and Logback. In each case loggers are pre-configured to use console output with optional file output also available.
By default, If you use the ‘Starters’, Logback will be used for logging. Appropriate Logback routing is also included to ensure that dependent libraries that use Java Util Logging, Commons Logging, Log4J or SLF4J will all work correctly.
Tip | |
---|---|
There are a lot of logging frameworks available for Java. Don’t worry if the above list seems confusing. Generally you won’t need to change your logging dependencies and the Spring Boot defaults will work just fine. |
The default log output from Spring Boot looks like this:
2014-03-05 10:57:51.112 INFO 45469 --- [ main] org.apache.catalina.core.StandardEngine : Starting Servlet Engine: Apache Tomcat/7.0.52 2014-03-05 10:57:51.253 INFO 45469 --- [ost-startStop-1] o.a.c.c.C.[Tomcat].[localhost].[/] : Initializing Spring embedded WebApplicationContext 2014-03-05 10:57:51.253 INFO 45469 --- [ost-startStop-1] o.s.web.context.ContextLoader : Root WebApplicationContext: initialization completed in 1358 ms 2014-03-05 10:57:51.698 INFO 45469 --- [ost-startStop-1] o.s.b.c.e.ServletRegistrationBean : Mapping servlet: 'dispatcherServlet' to [/] 2014-03-05 10:57:51.702 INFO 45469 --- [ost-startStop-1] o.s.b.c.embedded.FilterRegistrationBean : Mapping filter: 'hiddenHttpMethodFilter' to: [/*]
The following items are output:
ERROR
, WARN
, INFO
, DEBUG
or TRACE
.---
separator to distinguish the start of actual log messages.Note | |
---|---|
Logback does not have a |
The default log configuration will echo messages to the console as they are written. By
default ERROR
, WARN
and INFO
level messages are logged. You can also enable a
“debug” mode by starting your application with a --debug
flag.
$ java -jar myapp.jar --debug
Note | |
---|---|
you can also specify |
When the debug mode is enabled, a selection of core loggers (embedded container, Hibernate
and Spring Boot) are configured to output more information. Enabling the debug mode does
not configure your application to log all messages with DEBUG
level.
Alternatively, you can enable a “trace” mode by starting your application with a
--trace
flag (or trace=true
in your application.properties
). This will enable trace
logging for a selection of core loggers (embedded container, Hibernate schema generation
and the whole Spring portfolio).
If your terminal supports ANSI, color output will be used to aid readability. You can set
spring.output.ansi.enabled
to a
supported value to override the auto
detection.
Color coding is configured using the %clr
conversion word. In its simplest form the
converter will color the output according to the log level, for example:
%clr(%5p)
The mapping of log level to a color is as follows:
Level | Color |
---|---|
| Red |
| Red |
| Yellow |
| Green |
| Green |
| Green |
Alternatively, you can specify the color or style that should be used by providing it as an option to the conversion. For example, to make the text yellow:
%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){yellow}
The following colors and styles are supported:
blue
cyan
faint
green
magenta
red
yellow
By default, Spring Boot will only log to the console and will not write log files. If you
want to write log files in addition to the console output you need to set a
logging.file
or logging.path
property (for example in your application.properties
).
The following table shows how the logging.*
properties can be used together:
Table 26.1. Logging properties
logging.file | logging.path | Example | Description |
---|---|---|---|
(none) | (none) | Console only logging. | |
Specific file | (none) |
| Writes to the specified log file. Names can be an exact location or relative to the current directory. |
(none) | Specific directory |
| Writes |
Log files will rotate when they reach 10 MB and as with console output, ERROR
, WARN
and INFO
level messages are logged by default.
Note | |
---|---|
The logging system is initialized early in the application lifecycle and as such
logging properties will not be found in property files loaded via |
Tip | |
---|---|
Logging properties are independent of the actual logging infrastructure. As a
result, specific configuration keys (such as |
All the supported logging systems can have the logger levels set in the Spring
Environment
(so for example in application.properties
) using
‘logging.level.*=LEVEL’ where ‘LEVEL’ is one of TRACE, DEBUG, INFO, WARN, ERROR,
FATAL, OFF. The root
logger can be configured using logging.level.root
.
Example application.properties
:
logging.level.root=WARN logging.level.org.springframework.web=DEBUG logging.level.org.hibernate=ERROR
Note | |
---|---|
By default Spring Boot remaps Thymeleaf |
The various logging systems can be activated by including the appropriate libraries on
the classpath, and further customized by providing a suitable configuration file in the
root of the classpath, or in a location specified by the Spring Environment
property
logging.config
.
You can force Spring Boot to use a particular logging system using the
org.springframework.boot.logging.LoggingSystem
system property. The value should be
the fully-qualified class name of a LoggingSystem
implementation. You can also disable
Spring Boot’s logging configuration entirely by using a value of none
.
Note | |
---|---|
Since logging is initialized before the |
Depending on your logging system, the following files will be loaded:
Logging System | Customization |
---|---|
Logback |
|
Log4j2 |
|
JDK (Java Util Logging) |
|
Note | |
---|---|
When possible we recommend that you use the |
Warning | |
---|---|
There are known classloading issues with Java Util Logging that cause problems when running from an ‘executable jar’. We recommend that you avoid it if at all possible. |
To help with the customization some other properties are transferred from the Spring
Environment
to System properties:
Spring Environment | System Property | Comments |
---|---|---|
|
| The conversion word that’s used when logging exceptions. |
|
| Used in default log configuration if defined. |
|
| Used in default log configuration if defined. |
|
| The log pattern to use on the console (stdout). (Only supported with the default logback setup.) |
|
| The log pattern to use in a file (if LOG_FILE enabled). (Only supported with the default logback setup.) |
|
| The format to use to render the log level (default |
|
| The current process ID (discovered if possible and when not already defined as an OS environment variable). |
All the logging systems supported can consult System properties when parsing their
configuration files. See the default configurations in spring-boot.jar
for examples.
Tip | |
---|---|
If you want to use a placeholder in a logging property, you should use
Spring Boot’s syntax and not
the syntax of the underlying framework. Notably, if you’re using Logback, you should use
|
Tip | |
---|---|
You can add MDC and other ad-hoc content to log lines by overriding
only the 2015-09-30 12:30:04.031 user:juergen INFO 22174 --- [ nio-8080-exec-0] demo.Controller Handling authenticated request |
Spring Boot includes a number of extensions to Logback which can help with advanced
configuration. You can use these extensions in your logback-spring.xml
configuration
file.
Note | |
---|---|
You cannot use extensions in the standard |
Warning | |
---|---|
The extensions cannot be used with Logback’s configuration scanning. If you attempt to do so, making changes to the configuration file will result in an error similar to one of the following being logged: |
ERROR in ch.qos.logback.core.joran.spi.Interpreter@4:71 - no applicable action for [springProperty], current ElementPath is [[configuration][springProperty]] ERROR in ch.qos.logback.core.joran.spi.Interpreter@4:71 - no applicable action for [springProfile], current ElementPath is [[configuration][springProfile]]
The <springProfile>
tag allows you to optionally include or exclude sections of
configuration based on the active Spring profiles. Profile sections are supported anywhere
within the <configuration>
element. Use the name
attribute to specify which profile
accepts the configuration. Multiple profiles can be specified using a comma-separated
list.
<springProfile name="staging"> <!-- configuration to be enabled when the "staging" profile is active --> </springProfile> <springProfile name="dev, staging"> <!-- configuration to be enabled when the "dev" or "staging" profiles are active --> </springProfile> <springProfile name="!production"> <!-- configuration to be enabled when the "production" profile is not active --> </springProfile>
The <springProperty>
tag allows you to surface properties from the Spring Environment
for use within Logback. This can be useful if you want to access values from your
application.properties
file in your logback configuration. The tag works in a similar
way to Logback’s standard <property>
tag, but rather than specifying a direct value
you specify the source
of the property (from the Environment
). You can use the scope
attribute if you need to store the property somewhere other than in local
scope. If
you need a fallback value in case the property is not set in the Environment
, you can
use the defaultValue
attribute.
<springProperty scope="context" name="fluentHost" source="myapp.fluentd.host" defaultValue="localhost"/> <appender name="FLUENT" class="ch.qos.logback.more.appenders.DataFluentAppender"> <remoteHost>${fluentHost}</remoteHost> ... </appender>
Tip | |
---|---|
The |