In fact, in the actual development, each software has its own logging system, each language has its own logging framework/module, with the booming development of the Internet and big data, distributed logging system, as well as logging analysis system is also more and more widely used, more and more mature.

From the following aspects of in-depth logging design

First, who is using the log

There is a question that many developers may not have seriously thought about, that is, logging in the end is for whom? Users, Ops, developers, software learning enthusiasts? Of course, the answer is all of them.

Second, different roles, have different perspectives, in different stages, have different needs, then the log should provide different help. In doing the content design of the log module, should also stand in different perspectives to consider, to think clearly, which information to the user to see, which to the operation and maintenance personnel to see, which to the programmer to see. To pay attention to the priority, not that detailed is necessarily good.

Third, the level of logs

Developed a number of systems, the general feeling is this: in the beginning, we are relatively more concerned about the level of logs, content, location will go to think, choose. But as time continues to extend, the function continues to expand, the log gradually become chaotic, and ultimately degenerate into a mess!

The log usually has more than one level, the level does not only refer to the "level of detail", but also relates to the application of the scene, the service object, the purpose of the function.

Fourth, the use of logs of several scenarios

1) development process:

Log is a friendly, powerful record of the internal structure of the software runtime and the state of the tool is a debugging tool, of course, each language will provide specialized debugging tools, such as c/c++gdb, java's jdb and so on. But when it comes to business logic, concurrency, interaction, etc., or logging is lighter and more convenient! I usually use gdb and other debugging tools when learning "unfamiliar" code (such as open source software), which is powerful but bulky, and better suited to sorting out the structure of the code rather than the functional or business structure!

2) During testing:

When performing functional testing, debug or trace information, just like watching a surveillance replay, so that criminals have nowhere to hide!

3) software learning:

Learning software, including software architecture design, business functions, code logic, logs can always provide many clues, a lot of help. I remember a long time ago, look at the code of an open source system, after deployment, directly open trace run side by side, the overall structure and content of the system, at a glance, combined with the design documents, soon did not understand! At that moment, let me y remember, a good logging system, the original is so magical ah!

4) Normal operation:

Be sure not to open the debug run system, there is no point! The premise is that the ERROR information should be accurate and standardized, the customer is only related to life and death issues, and then more information is meaningless to them!