Best Practices for Log Printing

Best Practices for Log Printing

Why should the title be logged?

Print debugging : use logs to record variables or a certain piece of logic, and record the process of program operation, that is, which codes the program runs, so as to facilitate troubleshooting of logic problems.

Problem location : Quickly locate the problem when the program is abnormal or fails, so that it is convenient to solve the problem later. Because the online production environment cannot be debugged, it takes time and effort to simulate a production environment in the test environment. Therefore, it is very important to rely on the information recorded in the log to locate the problem.

Monitoring alarm & user behavior audit : after formatting, the log can be configured with a multi-dimensional monitoring view through the relevant monitoring system (AntMonitor), so that we can grasp the system operation status or record the user's operation behavior and collect and analyze the log for building a business market use

When are logs recorded?

When the code is initialized or when entering the logic entry : the startup parameters of the system or service. The core module or component initialization process often relies on some key configurations, and different services will be provided according to different parameters. Be sure to record the INFO log here, print out the parameters and the service description of the startup completion state.

Programming language exceptions : This type of caught exception is what the system informs the developer to pay attention to, and it is a very high-quality error report. The logs should be properly recorded, and the WARN or ERROR level should be used according to the actual business situation.

Business process expectations do not match : When the results in the project code do not match expectations, it is also one of the log scenarios. Simply put, all process branches can be considered. It is up to the developer to judge whether the situation can be tolerated. Common suitable scenarios include incorrect external parameters, data processing problems that result in return codes that are not within a reasonable range, and so on.

Key actions of system/business core logic : Business actions triggered by core roles in the system need more attention, and are important indicators for measuring the normal operation of the system. It is recommended to record INFO level logs.

Third-party service remote call : An important point in the microservice architecture system is that the third party can never be trusted. For third-party service remote call, it is recommended to print the parameters of the request and response, which is convenient for locating problems with each terminal, and will not be caused by the third party. The absence of service logs becomes overwhelming.

日志格式一般需包含以下几类关键信息：


调用时间
日志链路id(traceId、rpcId)
线程名
接口名
方法名
调用耗时
调用是否成功(Y/N)
错误码
系统上下文信息(调用系统名、调用系统ip、调用时间戳、是否压测(Y/N))

2022-12-12 06:05:05,129 [0b26053315407142451016402xxxxx 0.3 - /// - ] INFO [SofaBizProcessor-4-thread-333] - [(interfaceName,methodName,1ms,Y,SUCCESS)(appName,ip地址,时间戳,Y)

详细日志

详细日志是用于补充摘要日志中的一些业务参数的日志文件，用于问题排查。详细日志一般包含以下几类信息：

调用时间
日志链路id(traceId、rpcId)
线程名
接口名
方法名
调用耗时
调用是否成功(Y/N)
系统上下文信息(调用系统名、调用系统ip、调用时间戳、是否压测(Y/N))
请求入参
请求出参

2022-12-12 06:05:05,129 [0b26053315407142451016402xxxxx 0.3 - /// - ] INFO [SofaBizProcessor-4-thread-333] - [(interfaceName,methodName,1ms,Y,SUCCESS)(appName,ip地址,时间戳,Y)(参数1,参数2)(xxxx)

日志记录原则

隔离性：日志输出不能影响系统正常运行；

安全性：日志打印本身不能存在逻辑异常或漏洞，导致产生安全问题；

数据安全：不允许输出机密、敏感信息，如用户联系方式、身份证号码、token等；

可监控分析：日志可以提供给监控进行监控，分析系统进行分析；

可定位排查：日志信息输出需有意义，需具有可读性，可供日常开发同学排查线上问题。

print log highlights

1. Prevent NPE

2. It is forbidden to use System.out.println() to output logs.
Reason: This print log is a console log, and it is a synchronous method. High concurrency will affect performance, and the logs cannot be collected uniformly.

3. The application cannot directly use the API in the log system (Log4j, Logback), but should rely on the API in the log framework (SLF4J, JCL–Jakarta Commons Logging).
Reason: The logging system needs to be decoupled from the code

4. Declare the log tool object Logger should be declared as private static final
Reasons: private prevents the log object from being illegally used by other classes
static prevents duplication of new log objects, prevents them from being serialized, and reduces security risks
final In the life cycle of the class, there is no need to change the logger to avoid The logger is modified during program runtime.

5. Do not use e.printStackTrace() to print logs after catching an exception.
Reason: The string generated by the e.printStackTrace() statement records stack information. If the information is too long, the memory block where the string constant pool is located has no space. , that is, the memory is full, and the system request will be blocked.

6. Do not print meaningless (no business context, no associated log link id) logs

7. It is forbidden to use JSON to print objects in log printing, you should use the toString() method or apache's ToStringBulider

8. Prohibition of printing sensitive information

9. Use English as much as possible for log printing.
Reason: Try to output English when printing logs to prevent garbled characters in printing due to inconsistencies between Chinese codes and terminals, which will interfere with fault location and troubleshooting.

10. To call a third-party interface, you must print the input and output parameters