What level of logging when print program

Print Log essential in the software development process, generally divided into two categories:

  • Operation Log
  • System Log

Operation log, mainly targeted at users, such as in Photoshop software will record the steps of their own operations, to facilitate the user's own view.

System logs, mainly targeted at software developers (including testing, maintenance personnel), which means that this part of the log user can not see, is what we usually refer to the debug log.

In the practice of so-called university or teacher assigned the role of project, usually do not care about the log, unless there is a special need in the job, often console print statements directly in the development process to debug the program, it is extremely unprofessional debugging development process. So this will cause a problem, convergence is not the biggest problem is not the technical difficulty of college and graduate work, but the problem log printing. This seemingly insignificant problem for graduating students, who tend to be "a nightmare", the operation log is relatively easy to understand, what the user did what is recorded; and no printing system log from the start, often have the following general areas - 3W:

  • Where: I do not know where to print the log
  • Who: What level of logging is not clear print
  • What: log should contain clear what

Benpian that focused on system logs, so the following "Logs" are "system log" for short. I will focus on these areas to make a brief summary of the printing system log. To make a further exemplary Java commonly used in logging print frame (log4j) used in several ways.

WHERE

1. Program Entry

  At the entrance of the print log because the argument this time passed in without any treatment, print it in the log file can know at a glance whether the original data of the program in line with our expectations, was not passed in the raw data on emerging issues.

2. The exception caught

  When abnormal print a detailed error log allows you to quickly locate where an exception is thrown in a program such as capture, in peacetime, we often is printed directly on the console stack information e.printStackTrace (), but in the actual production environment more difficult, let alone IDE to let you view the console information, then we need to stack information recorded in the log, so that we can accurately locate the program where the error occurred when an exception occurs.

 3. Important Information

  This may be very broad, because the different business focus of logic may not be the same as, for example, in some important parameters can not be null, then you need to determine whether it is empty, if empty then logged; there are, for example, transfer came after a series of parameters through the algorithm processing, this time also need to print the log to see if calculated correctly. But remember, try not to print the log directly in a for loop, especially for particularly large circulation, so your log may be washed every minute was not a trace, and even impact on performance.

WHO

         There are four levels usually log printing, from high in the end are: ERROR, WARN, INFO, DEBUG. What level is a very important question should be used.

         First clear the log level of priority What does it mean, after your system is turned on if a certain level of logging, it will not print the log lower than its level. For example, if the program opens the INFO level logs, DEBUG will not print the log, but does not print does not mean no, this will be mentioned later. INFO log is usually open in a production environment.

         So what level of logging should print it? First of all we should be clear who is looking at the log.

Generally speaking, the system is a problem the customer does not enter into the system against the pitch-black console to view the log output, so the principal object log must be faced by software developers (including testing testing, maintenance personnel).

   Here we assume several scenarios to help us understand the log level.

         First, after the end of program development handed over for testing to the test, testers found a use case does not match the expected output and according to test cases, this time his first reaction should be to view the log. At this time, the log level is INFO log does not appear DEBUG level logging, and now need to log print two cases decided his next step:

  1. INFO log is found by looking at because of their operational errors, resulting in the program and the results do not meet expectations, this is not a procedural error, it is not a bug, developers do not need to be present.
  2. Found their correct operation, not the view according to operational errors caused by viewing the log INFO INFO log, this time on the need to develop personnel to the scene to confirm.
  3. In both cases the ideal situation, according to testers only INFO level logging able to determine the output of a program is not as expected because of their operational errors or program bug. More realistic situation is actually testers do not own mistakes or program bug in accordance with INFO-level log to determine whether yes.

  In summary, INFO -level log should be able to help testers to determine whether this is a real bug , rather than their own operational errors caused.

Assuming that testers now have preliminary judgment this is a bug, and the bug is not so obvious, then it needs to develop personnel to the scene to confirm.

  Developers arrived at the scene, the first step should be to see the log INFO preliminary opinion as to determine the initial verification tester, and then if you can not determine where the problem lies should be to adjust the log level to DEBUG level, print out the DEBUG level logging, by DEBUG logs to analyze where to locate the bug.

  So, DEBUG level logging should be able to help developers analyze positioning bug is located.

ERROR WARN level and higher than INFO, so set the log level at INFO when both the log will be printed. According to the above INFO and DEBUG level and the application can know the difference, ERROR, and WARN is at the same time to observe the testing and development.

  WARN level called "warning", the "warning" is actually a bit vague, it is not wrong, you can choose to ignore it, but can also choose to pay attention to it. For example, now play such a WARN log a log "system at risk of collapse", this time on the need to attract enough attention, it stands now does not crash, but it has the risk of collapse. Or there is "a user password output in a short time after so many times before entering the system," this is not the time system is brute force of it? And so on, this log level as its literal meaning, to give you a warning, you can choose to ignore, you can also pay attention to, but now it will not bring influence to other systems at least.

  ERROR level called "error", the meaning is even more obvious, is that the system error has occurred, need to be addressed. The most common is the log when capturing abnormal printed.

  Above us the difference between four kinds of log levels, in particular important to note that the level of INFO and DEBUG level applicable personnel. So how do we choose which level of logging output it?

  The following is my personal understanding:

INFO

  1. Program entry, which allows developers to confirm whether the parameter for themselves should do.
  2. The results, test procedures concern of whether the output in line with expectations, then for the calculation should not be concerned, given the results can only determine whether line with expectations.

DEBUG  

For the DEBUG level, I think it is more concerned about the process, as well as more specific information as to help its positioning is to help developers locate bug, bug you need to locate more detailed parameter information to locate. For example, a specific process algorithm, can use DEBUG print, developers not only care about the result, but should be able to whether the deviation occurs when the result of an incorrect calculation based on query log DEBUG

WARN

  A rarely come to the branch for normal operations should not be printed WARN log, only if they meet certain conditions in order to come to the branch, and the branch caused the "vigilance", then you should print WARN log.

ERROR

  There is no doubt that an error occurs, the program can not continue to run down ERROR should print the log, this error is not an error on the business. For example, to add a user found that already exists, although at this new failure, but can not say the program will print an error ERROR log; When you delete a user finds the user has been blocked, and we can not say because the program can not According to the tombstone should continue to run down the print ERROR log.

WHAT

  What content should print? Anything printed must proceed from reality. This means that if the actual production environment, you have a lot of subscribers, log in constantly refreshed, how to locate a user's entire login and subsequent operation of it? Of course, it is based on the user name to the track. So the first element is to be able to print the contents easy to locate; after positioning the user may operate, or positioned in several template, this time was a set of modules; there is of course that the specific parameters of a user operation; and finally that is what the user did.

  Conclusion is that, [id, module, params, content] (keyword, modules, parameters, content).

  These are a few suggestions for log printing, said not comprehensive, start a discussion. The following is a non-print framework of best practices for logging (log4j) of.

The resources (resources in IDEA path is classpath) Create a new log4j.properties file, as follows:

log4j.rootLogger = INFO, stdout, logfile
# Log output to the console
log4j.appender.stdout = org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout = org.apache.log4j.PatternLayout
log4j.appender.stdout.ConversionLayout = %d [%t] %-5p %c - %m%n
# Log output to a file
log4j.appender.logfile = org.apache.log4j.DailyRollingFileAppender
log4j.appender.logfile.File = /Users/yulinfeng/Log/log
log4j.appender.logfile.maxFileSize = 10240KB # log a maximum capacity of 10M
log4j.appender.logfile.Append = to true     # if additional written documents
log4j.appender.logfile.Threshold = DEBUG # DEBUG level log output to a file
log4j.appender.logfile.layout = org.apache.log4j.PatternLayout
log4j.appender.logfile.layout.ConversionPattern = %d [%t] %-5p %c - %m%n

 Line 1, log4j.rootLogger = INFO, stdout, logfile. This is the root configuration log4j, the first parameter indicates what level of log output, the latter parameter represents the output position, the position of the console may be, it can be a file, the syntax is log4j.rootLogger = [level], appendername ...... here defines two output positions, taking the name does not matter what setting, can be meaningful. Log level from high to low are: OFF, FATAL, ERROR, WARN, INFO, DEBUG, ALL, log4j is recommended that only ERROR, WARN, INFO, DEBUG four levels, that is, that is, in the above mentioned.

  3,7 to specify an output line positions and stdout logfile logs, log4j provided a total of five.

  org.apache.log4j.ConsoleAppender (console)

  org.apache.log4j.FileAppender (file)

  org.apache.log4j.DailyRollingFileAppender (produce a daily log file)

  org.apache.log4j.RollingFileAppender (create a new file after file size reaches a certain size)

  Org.apache.log4j.WriterAppender (log stream format information is sent to any position)

       Line 4 shows the format of the log information, a total of several.

       org.apache.log4j.HTMLLayout (in HTML output tables)

       Org.apache.log4j.PatternLayout (flexible custom output format)

       Org.apache.log4j.SimpleLayout (simple format output including only the character string of the log level and log information)

       org.apache.log4j.TTCCLayout (includes thread, string log level, log classes are located and log information)

       Usually more flexible in order to print the log, we will choose to log PatternLayout layout, as well as by ConversionPattern customize the output format.

  According to the above configuration, we can output the log in the code. Because it is used in the Spring Framework log4j, it is necessary to use the Spring log4j initialized to initialize log4j in web.xml.

<web-app>
    <display-name>log web</display-name>

    <context-param>
        <param-name>log4jConfigurationLocation</param-name>
        <param-value>classpath*:log4j.properties</param-value>
    </context-param>

    <! - scanning every 60s log4j configuration file, log4jRefreshInterval parameter configuration is represented here can not restart the web server will be able to dynamically change the log4j log level, and this is a big advantage of the integration of Spring ->
    <context-param>
        <param-name>log4jRefreshInterval</param-name>
        <param-value>60000</param-value>
    </context-param>
    <listener>
        <! - from spring4 2 starts .1 Log4jConfigListener has been abandoned, corresponding org.apache.logging.log4j.web.Log4jServletContextListener preferably used log4j2
.Log4jServletContextListener-->
        <listener-class>org.springframework.web.util.Log4jConfigListener</listener-class>
    </listener>
</web-app>
private Logger log = Logger.getLogger(Test.class);
log.info(“test info”);

The above is all the log files are output to a file of the case, we are likely in practice for different output modules to different log files.

       Modify log4j.properties:

= log4jrootLogger INFO The, module1, module2
# Output to the console
log4j.appender.stdout = org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout = org.apache.log4j.PatternLayout
log4j.appender.stdout.ConversionLayout = %d [%t] %-5p %c - %m%n
# 1 module output log file
log4j.appender.module1 = org.apache.log4j.DailyRollingFileAppender
log4j.appender.module1.File = /Users/yulinfeng/Log/module1
log4j.appender.module1.maxFileSize = 10240KB # log a maximum capacity of 10M
log4j.appender.module1.Append = to true     # if additional written documents
log4j.appender.module1.Threshold = DEBUG # DEBUG level log output to a file
log4j.appender.module1.layout = org.apache.log4j.PatternLayout
log4j.appender.module1.layout.ConversionPattern = %d [%t] %-5p %c - %m%n
2 log file output module #
log4j.appender.module2 = org.apache.log4j.DailyRollingFileAppender
log4j.appender.module2.File = /Users/yulinfeng/Log/module2
log4j.appender.module2.maxFileSize = 10240KB # log a maximum capacity of 10M
log4j.appender.module2.Append = to true     # if additional written documents
log4j.appender.module2.Threshold = DEBUG # DEBUG level log output to a file
log4j.appender.module2.layout = org.apache.log4j.PatternLayout
log4j.appender.module2.layout.ConversionPattern = %d [%t] %-5p %c - %m%n

When the module output log file is actually just different parameters:

private Logger log = Logger.getLogger(“module1”);
log.info ( "test info"); 
2 modules:
private Logger log = Logger.getLogger(“module2”);
log.info(“test info”);

These are the use log4j logging framework of best practices in non-Spring.

  Finally, also describes another way to print the log, the above manner will define a Logger object in each class, so with respect to the business logic code, it actually does not want control, then you can use the Spring the AOP Aspect oriented programming print log. There may not all people can access to use AOP to print the log, temporarily does not describe in detail here.

Guess you like

Origin www.cnblogs.com/kisshappyboy/p/11694094.html