This article presents a summary of my use of logs in Java projects, from the role of logging, log selection, log level introduction, and some best practices for logging.
Functions of Logs
The main functions include:
1. Locate the problem after the problem
2. Display the current running status of the program
Selection of log
There are many open source Logging frameworks in Java: SLf4J, LogBack, Log4j, JCL(Apache Common Logging), JUL(java.util.logging), etc. Slf4j is part of a compact set of logging apis that does not include logging implementations (it is not responsible for logging output, etc. JCL also includes apis).
Slf4j provides a number of adapters that can be adapted to all other open source logging frameworks, allowing us to simply face slF4J’s API in our code and then switch logging implementations at will. You may say that we do not need to switch the function of logging framework, but we need to use a large number of third-party libraries in our project, and these third-party libraries use different logging frameworks. Different logging frameworks require different configurations, and different configurations will result in different log output locations.
An application must have log levels, log output, and other unified management. In this case, we can use the slF4J adapter to take over the implementation of the various logging in the third-party library, and then configure the logging used in these third-party libraries uniformly.
Among these logging implementation frameworks, logback performs best, so it is recommended to use logback when choosing a logging implementation.
Log Levels
Level definition is an art, and a good definition should follow the following principles:
Debug: Records the critical path of a complete and detailed flow. It should be used for tracing and debugging information that is of interest to the developer. The DEBUG state is normally not enabled in production environments
Info: It should be concise and clear for the administrator to confirm the status. Log messages that are significant and meaningful to end users and system administrators. The INFO level is used to display key system parameters, initialize background services, and confirm key information
Warn: Will clearly inform everyone of what is happening. Can be an indication of a potential problem, but not necessarily one that needs to be addressed.
Error: An exception or an unexpected problem occurs in the system and needs to be handled in a timely manner. One thing to note is that not all exceptions need to be logged as errors.
Some best practices for logging
The following can be used as specifications according to the actual situation of the project:
1. Tomcat Configure access logs to record information about each HTTP request
2. Dubbo configure access logs to record each call and processing of dubbo Consumer and Provider requests
3, in the system to call the external place, record the request interface, parameters, return results, take time, encountered exceptions, etc
4, in the system abnormal place, record the abnormal stack, if possible, as far as possible through the abnormal log can restore the situation at that time, such as the affected by which user, what variables are passed in, which core data caused by the exception and so on
5. Core logging is required for code that is written knowing that it is difficult to execute or not expected to execute, and else blocks that rarely walk
6. Do not use system. out or system. error
7. Disable Apache Commons Logging, Java Util Logging, slf4J is recommended, Logback is recommended, and SLF4J is used for Logging in code
8. Service logs are configured independently and cannot be className. For example, in my previous project in Qunar, I connected with many third-party management systems, and the interaction logs with each third party were stored in a separate log file
9. The system logs of INFO and above are output to the Console. In the production environment, if the system log is divided into multiple files, it is not conducive to troubleshooting. Not only do you have to go after multiple files at the same time, but you also have to match the time of the problem. Most importantly, some exceptions are printed to the console.
10. Log configuration Rolling, you can configure the rotation by day or by hour according to the actual situation to generate new log files
11. Record the status of the application, including the time of occurrence (usually included in the framework), the progress of large data updates, key variables, and what important things are being done.
12. Different log files should be output in the same format (logback is configured with the same pattern) to facilitate script generalization and third-party parsing
At the end
Keeping a good journal on a project is an art as well as a science. Here is a summary of their current thinking, welcome to correct, but also welcome to share more best practices.