Setting logging levels

4.1 List of logging levels

You wrote your program, uploaded it to the server, and then you immediately start to have questions:

• How to make sure that debug()the method does not work while working in production?
• There is too much information in the logs, would you like to leave only error messages?
• How to see a detailed log for one part of the application?

Of course, the creators of the logs faced the same thing decades ago. I will not tell you how this problem was solved in the C language, but in the Java language it was solved very beautifully.

The log filters the data before writing the information to the . You can very quickly reduce / increase the detail of the log by setting the logging level. These levels are described in the table below:

These levels are used when filtering messages. If you set the logging level to WARN, then all messages less important than WARNwill be discarded: TRACE, DEBUG, INFO. If you set the filtering level to FATAL, then even ERROR.

There are two more severity levels that are used in filtering - this OFF(discard all messages) and ALL- write all messages (discard nothing).

4.2 Log setup example

Let's look at a simple log setup example. To do this, we need the log4j.properties file, which can be placed in the resources folder. Let's add the following content to it:

# Root logger option
log4j.rootLogger=WARN, stdout

# Direct log messages to stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.Target=System.out
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss}

Here in the very first line we set the logging level - WARN. And this means that messages that are written to the logger with status DEBUGwill INFObe ignored.

• Specify what type of appender we will use -ConsoleAppender
• Specify where we will write the log -System.out
• We set the class that will control the recording format -PatternLayout
• Set the recording format for all messages - date and time

4.3 Popular logging mistakes

And one more important point - popular errors in logging. There are not so many options to do something, but several common mistakes can be identified:

1. Too much logging . You should not log every step, which theoretically can be important. There is a rule: logs can load the performance by no more than 10% . Otherwise there will be performance issues.
2. Logging all data into one file . This will cause it to be very difficult to read/write to at some point, not to mention that there are file size limits on certain systems.
3. Using the wrong logging levels . Each level of logging has clear boundaries, and they should be respected. If the boundary is vague, you can agree on which level to use.