Five common rules in Java Logging

Five common rules in Java Logging

Logging is a key factor that needs to be considered during software development. When a product encounters an error, log files are usually the primary choice for error analysis. Moreover, in many cases, they are the only information we have in hand that can be used to identify the situation and root cause of the problem. Therefore, it is extremely important to correctly record the required information.

The following five log rules allow us to check and improve the method of operating log records in code.

At the same time, please note that we will neither discuss how to configure a log engine nor compare with each other.

Rule 1. logs are intended for readers

Log messages must be meaningful not only to the person who writes the book or log) code, but also to the readers of log files.

This seems to be an obvious but frequent violation rule.

ERROR: Save failure-SQLException .....

For example, let's take a look at the following log information:

ERROR: Save failure-SQLException .....

What to save? This message can be used by developers to illustrate some problems, but it is useless for poor guys who are struggling to view product problems.

RROR: Save failure-Entity = Person, Data = [id = 123 surname = "Mario"]-SQLException ....

The more appropriate information is:

RROR: Save failure-Entity = Person, Data = [id = 123 surname = "Mario"]-SQLException ....

This explains what you want to store here is a Person, a JPA entity) and the content related to this Person instance.

Please note that this word does not refer to the generic whole: we should not make the log file messy with worthless information, such as printing all entity fields completely.

Generally, an object name and its logical keywords are enough to recognize a record in a table.

Rule 2: match the Log Level and execution environment

All log management tools and engines provided in the Java System have log levels: ERROR, INFO ......) This may filter out messages with low levels.

For example, Java util logging uses the following levels: SEVERE, WARN, INFO, FINE, FINER, FINEST + CONFIG, and OFF ). On the contrary, Apache Commons Logging and SLFJ, two of the most popular log management tools, prefer the following levels: FATAL, ERROR, WARN, INFO, DEBUG, and TRACE.

The log filtering level depends on the code development stage: the finished product and the code log level that is still in the test and integration environments cannot be the same.

More specifically, the log level should also refer to the ownership of the Code.

In general, our own application code should have more detailed log records than any third-party development library in use.

For example, Apache General debugging messages appear in our log files, which makes little sense.

I usually configure logging like this:

• Finished stage: My code is INFO level, and the third-party library is WARN.

• Testing and integration phase: My code is DEBUG level, and the third-party library is WARN or INFO if needed ).

• Development Phase: any meaningful information.

Note: Personally, I do not recommend using the TRACE/FINEST level. I am not the only person who holds this point of view. refer to the example here ).

I have not found much difference between DEBUG and TRACE, but the young team members are often worried about whether to use DEBUG or TRACE.

Based on the KISS principle, we recommend that you use only the RROR, WARN, INFO, and DEBUG levels.

Rule 3: remove the encoding help log before submission

When encoding, we often use logger or System. out to add log messages to the Code to better understand the status of the application during execution and debugging.

Void aMethod (String aParam ){
LOGGER. debug ("Enter in aMethod ");
If ("no". equals (aParam )){
LOGGER. debug ("User says no ");
....

For example:

Void aMethod (String aParam ){
LOGGER. debug ("Enter in aMethod ");
If ("no". equals (aParam )){
LOGGER. debug ("User says no ");
....

These messages display called methods and back up internal variables and method parameter values, mainly to track the behavior of applications. This is quite popular in non-test-driven development.

However, once the code is released and tested, the messages are usually useless.

Therefore, this rule is simple: Once you have completed the development, the SCM system git, svn ......) Previously, all temporary and unnecessary log messages should be removed.

This rule does not require the removal of all DEBUG messages, but for messages that are meaningless after the application is completed and released, or the messages that make sense when we have reason to believe that the application can run correctly.

Rule 4: Check the log level before the log DEBUG message

According to the 2nd rules, only the ERROR, WARN, and INFO messages are displayed in the product log, but some DEBUG messages that do not affect the running of the product can be used in the code.

If (LOGGER. isDebugEnabled ((){
LOGGER. debug (.......)
}

Every time you want to log a DEBUG message, all messages left after rule 3 are used.) You need to add a check before to determine whether the DEBUG log is Enabled:

If (LOGGER. isDebugEnabled ((){
LOGGER. debug (.......)
}

This method can prevent code from creating log messages and calling logger to improve the efficiency of running programs.

Rule 5. Learn about your logger

Using the logger method may cause huge overhead:

• Create a message string

• Organize data contained in message strings

We should check the selected log management tools and engine javadoc documents to find out the most effective way to use their logger.

LOGGER.info ("Person name is" + person. getName ());

For example, we can create a message like this:

LOGGER.info ("Person name is" + person. getName ());

This creates an unnecessary string instance.

LOGGER.info ("Person name is {}", person. getName ());

When using SLF4J, the correct usage should be:

LOGGER.info ("Person name is {}", person. getName ());

The formatted string here is a constant, and the immutable message is created only when logging is allowed.