Shulou(Shulou.com)06/01 Report--

This article mainly introduces "how to understand java logs". In daily operation, I believe many people have doubts about how to understand java logs. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful for you to answer the doubts about "how to understand java logs". Next, please follow the editor to study!

Importance

"No log, no operation and maintenance". Important index: the highest.

Have the characteristics

Can quickly and accurately locate the problem, the log should be able to show the cause of the error. This sentence is very important, which is the guiding ideology of log printing.

classification

Classification is very important, different functions, different businesses need different logs. The more detailed the classification, the easier it is to locate the problem.

Type of log

According to the type of printed log, it can be divided into console log, file log, database log and kafka+elk log. These are the ones I've been in contact with so far.

Console log: for testing of simple code

File log, database log: I do not recommend it, it is already out

Kafka+elk logs: I have access to the best logs so far

@ timestamp: is the time when the log is printed

Level: is the level of log

LoggerName: the class parameter passed when the logger is created

Message: is a printed log

ProjectMarker: I added it to distinguish between project and environment. As you can see from this screenshot, this log is the official environment log for the seal project. If it is "seal.test", it means the test environment of seal. This feature is available only in the framework "treasure pot" that I developed.

Source.class: is the full name of the class that prints the log

Source.line: is the line number of the printed log in the class

Source.method: is the name of the method that prints the log

Level

The priority of log output: debug < info < warn < error < fatal,info, warn, error are required.

Info: print normal information for easy debugging and debugging.

Warn: errors that can be ignored. For example, incorrect password, expired session and so on.

Error: a disallowed error. This error will lead to normal business.

Hierarchy

Personally, I think the log should be divided into framework level, business level and plug-in level.

Frame level: a log printed by the frame used by the project. This type of log is used to troubleshoot problems from the underlying layer (if the business layer cannot). It is usually built by architects. The log at this level is very important because the log at the framework level has the characteristics of universality and versatility. If the framework prints the log, the business layer does not need to write the log, which reduces the workload of business development. Some problems need to be located in the underlying log.

Business level: mainly print business-related logs

Plug-in level: due to docking with a third party, it is necessary to introduce a third-party jar to capture the log of the plug-in.

Return code, description, standardization

Return code: usually three digits, can only represent a range, can not accurately locate the problem

Description: is the returned description information, which can accurately locate the problem. But now there is a misuse. This description is originally intended to facilitate the back-end engineer to locate the problem. The front-end engineer uses it directly when making the problem presentation. Because the description of troubleshooting the problem is different from the description presented to the customer, this description can not accurately locate the problem. If you need to use the backend information for presentation, it is recommended to create another field.

Standardization: this is very important, and if you standardize it, you can tell at a glance what the problem is.

The following code is the standard attribute returned by the "treasure basin" framework, which can be used for reference

@ ApiModelProperty (value= "error code, 200success, the rest is failure. The page handles different businesses through the error code") private int returnCode = 200 private String returnDesc ApiModelProperty (value= "error message, this information can only be used for interface docking, troubleshooting, not for page display") private String returnDesc = "success"; @ ApiModelProperty ("message displayed at the front end") private String returnShow; runtime

Run-time printing is a very important log for performance tuning. Because it is too important, I list a single title.

The record of the log

If you can understand the guiding ideology of log printing, I believe log printing is not a difficult task for you.

Logs that must be printed

The entrance and return of the interface: the input parameters need to be printed at the entrance and the returned information needs to be printed at the return.

Before and after calling the API: print the requested parameters before calling the API, print the requested parameters and returned values, and print the running time of the API after calling the API.

Wrong branch: for each abnormal branch, the log must be printed. If must have slse,switch. Must have default. See the figure below

/ example 1/if () {/ / normal business logic} else {/ / exception, there must be a log} / example 2/if () {/ / exception There must be a log} / / normal business logic / example 3/switch (key) {case value: / / normal business logic break . / / normal business logic default: / / exception. There must be a log break;}.

Catch: if the program is abnormal, you must capture and print the log

Database: logs for operating the database must be printed, including executed statements and passed-in parameters

Before the statement that may make an error: if the statement executed has the probability of reporting an error, be sure to print parameters in front of it to facilitate troubleshooting.

Optional log

Personally, I think that if all the logs that must be printed are printed, it can fully meet the needs of debugging.

At this point, the study on "how to understand the java log" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.