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

This article is about how the average programmer in python understands the logging system. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

When we are doing system development, logging system is an unavoidable topic. As end users of logging systems, we will come into contact with different logging systems, such as log4j, logback, slf4j and so on, as well as various concepts of logging systems, such as Formatter, Appender, Priority and so on. What is the difference between these logging systems and how to understand these concepts?

Today we will talk about how we ordinary programmers, the end users of the logging system, can understand the logging system.

The prototype of Logging system

Let's go back to the ancient days of the computer world or when we were new to the computer world, when we had two ways to debug programs: 1) step by step, step by step, and look at the values of variables in the code. 2) printf Dafa-print the log in a specific place, through the output of the log, to help quickly locate.

The single-step debugging method is time-consuming and laborious, but it can locate the problem accurately. The printf method is simple and rough, you need to try, and in most cases you can find the problem quickly. Single-step debugging and printf method are used together to complement each other. But single-step debugging stops at debugging tools such as gdb, and printf finally develops a series of logging systems. The reason is that single-step debugging can only be used by programmers, while printf can be used in both debugging and production lines, and the output logs are used and interpreted by people from all walks of life.

When to print the log is a problem-- Level

The printf Dafa is very crude. In the process of debugging, it is possible for logs to be very fine-grained, such as what the third field of each piece of data is printed out, but the actual operation is to delete these fine-grained logs. The next time we debug, we will know what the third field of each piece of data is. To this end, we hope that log printing is smart: when debugging or online problems, all kinds of fine-grained logs are printed out, and some of the simplest information is output during normal operation.

To solve this problem, the log system introduces log level (Level) to solve the problem. After introducing the concept of log level, we print the log when programming, and we need to specify the level of the log. Because the log level is the most important parameter, today's logging systems specify the level directly by using different functions, including logger.TRACE, logger.DEGUB, logger.INFO, logger.WARN, logger.ERROR, and logger.FATAL. The comparison of levels is TRACE < DEBUG < INFO logging.INFO and not hasattr (record, 'is_custom'): record.msg = "[% s,% s,% s]% s"% (record.filename, record.lineno, record.funcName, record.msg) record.is_custom = True return super (AltCustomFormatter, self) .format (record)

With the introduction of the concepts of Level, Formater, and Appender, the entire logging system is set up, as shown in the following figure. As an ordinary programmer, you can safely use this logging system.

Printing logs efficiently is another problem-- Efficient

But as an ordinary program with pursuit, we want to know whether the logging system can hold up in the extreme environment of large-scale systems. The answer is that the log system designed according to the above is not sustainable. Because of the extreme environment of large-scale systems, real-time requirements are high, and the delay of writing files or networks can not be tolerated. What should I do? Please deal with IO delay weapon-Buffer. Based on Buffer and considering the problem of thread synchronization caused by Buffer, the following scheme is designed. In this scenario, each thread generates a Buffer, and then the writer thread polls for reading information from the Buffer and writes to the destination. In this scenario, logging does not cause service delay.

In addition to the architectural design, there are some small trick to improve performance. For example, we found ugly INFO functions on log4j's official API. When the Java language does not support variable length parameters, log4j forces an INFO function that supports variable length, so it can only be overloaded by writing different functions, and only 9 parameters are supported in the end.

But these ugly INFO make sense. These ugly INFO are designed to implement the variable-length parameters in the following table. What is the difference between this variable length parameter method and the string concatenation method? When the current level is ERROR, the INFO level information does not need to be output, the string stitching method still needs to spell the string, while the variable length parameter method does not need to concatenate the string.

Thank you for reading! This is the end of the article on "how ordinary programmers understand the log system in python". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it out for more people to see!

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.