Proper use of slf4j

The first two days leading distribution task is to put the project in all try catch exception handling collected elk, due to prior treatment varied, to focus on the next, and afterwards was also criticized.

 

Not all exception information needs to be recorded in the log

 

Use SLF4J

1. Logging framework using the facade pattern is conducive to maintaining a unified log handling of each class.
2. Implementation of consistent use, use logback framework.

 

When you should hit the log?

1. When you encounter a problem, the problem can only be determined by the debug function, you should consider playing log, a good system, you can locate the problem by logging.
2. When you have something like a branch if..else or switch, you can print the log in the first line, is used to determine into that branch.
3. When often function as the core of development, you can be submitted before the code by logging see the whole process.

The basic format

You must use parametric information:

“ logger.debug("Processing trade with id:[{}] and symbol : [{}] ", id, symbol); ”

 

For debug logs, you must determine whether the debug level before use.

But this is not recommended. Because the above code related to the string concatenation, will have a lot of String objects, space, affecting application performance.

 

You can use [{}] isolation parameters

If there are parameter variables can be written as follows:

This format written more helpful for troubleshooting problems.

 

Different levels of use

ERROR

Definition: affect the normal operation of the program, the current request exceptions normal operation:

1. Open the configuration file failed
2. Docking third party abnormalities (including third-party returns an error code)
3. All affect the function of the use of exceptions. Including sqlException and in addition to the business exception of all exceptions (runtimeException, Ecxception)

If an exception is thrown, do not record error log, there is the ultimate treatment for processing.

As shown below:

 

WARN

Definition: it should not happen but it does not affect the current request exceptions normal operation:

1. Error occurs when there fault tolerance
2. Can not find the configuration file, but the program can automatically create or to continue to carry down
3. Buffer pool occupancy close to the threshold of time
4. Interface throws an exception when business

INFO

Definition: information on system operation, the external interface

1. service for the change in the system / service status
2. The main logic step by step
3. The client request parameters
4. Call call call parameters and results of third party

Here is also the choice to make a difference, ordinary service simply does not make sense. Not all do it for each business,

Here for complex business logic, business logic such as ordering systems, industrial systems stop transmission logic, etc.

DEBUG

Definition: fill in the relevant information may want to know, the best parameters, production environment needs to close debug, if you need to open the case, you need to use a switch to manage, not always on

 

TRACE

Definition: especially detailed information on system operation. Business code, do not use (unless there is a special intention, or replaced with debug)

 

Trace levels even lower than the number of debug, and will automatically check the level, if higher than skip trace.

The debug statement is the first production to be printed, and then check the level. If the above is not output debug

So to debug judge, otherwise it will generate unwanted objects.