Contribute to help us improve!

Are there edge cases or problems that we didn't consider? Is there a technical pitfall that we should add? Did we miss a comma in a sentence?

If you have any input for us, we would love to hear from you and appreciate every contribution. Our goal is to learn from projects for projects such that nobody has to reinvent the wheel.

Let's collect our experiences together to make room to explore the novel!

To contribute click on Contribute to this page on the toolbar.

Logging

To monitor and understand what the running application is doing it is essential to write logs. This article gives advice on how to do proper logging in an application.

General conventions

SLF4J

  • Use SLF4J, because it has become a de facto standard in Java

    • Use the 'typical usage pattern' and not the fluent API.

    • Consider Logback as implementation in Spring

    • Consider JBoss Log Manager and the JBoss Logging facade as implementation in Quarkus

Naming conventions

  • The private static final member storing the logger instance should be called log.

Use a separate configuration per environment

When the configuration of the logger is environment specific the configuration should be stored in a separate file.

Use standard log levels

To make it possible to filter the log messages, there are different log levels to express the nature of the logged message. There is a common understanding how this log levels should be used and which messages should be logged with which log level:

Log levels
Log-level logger function Description Impact

FATAL

error with a marker

Only used for fatal errors that prevent the application to work at all (e.g. startup fails or shutdown/restart required)

Operator has to react immediately

ERROR

error

An abnormal error indicating that the processing failed due to technical problems.

Operator should check for known issue and otherwise inform development

WARNING

warn

A situation where something worked not as expected. E.g. a business exception or user validation failure occurred.

No direct reaction required. Used for problem analysis.

INFO

info

Important information such as context, duration, success/failure of request or process

No direct reaction required. Used for analysis.

DEBUG

debug

Development information that provides additional context for debugging problems.

No direct reaction required. Used for analysis.

TRACE

trace

Like DEBUG but exhaustive information and for code that is run very frequently. Will typically cause large log-files.

No direct reaction required. Used for problem analysis.

Exceptions (with their stack trace) should only be logged on FATAL or ERROR level. For business exceptions typically a WARNING including the message of the exception is sufficient.

Configure the active log levels per environment

When the application is executed on different environments it is a best practice to activate certain log levels depending on the type of the environment:

Log levels in different environments
Log-level Active Environments

FATAL

all

ERROR

all

WARNING

all

INFO

all

DEBUG

development and testing

TRACE

none (turned off by default)

Use rolling log files

To prevent log file from getting to big it is a best practice to use rolling log files. This means that following a list of rules the logger will start logging to a new file. The frequency of the rolling depends on the amount of log message and on the file size the file system and the applications, used to view the logs, can handle.