Atitit. log system principles and design and best practices (1) ----- Theoretical Summary of principles.

Atitit. log system principles and design and best practices.

 

1. log system is an indispensable unit test, tracking debugging tool 1

2. The log system framework should generally include the following basic features 1

1. The output log has its own category. 2

2. logs are divided into different levels according to certain standards. 2

3. multithreading is supported. 2

4. Stability. 2

3. An Ideal log Mode 2

4. Determine whether the specified method has been called 3

5. Add logs to the input and output of the method through AOP 3

6. logs are easy to read and easy to parse. There are two types of logs that interest you: 3.

7. Performance of log output 3

8. The log level debug is too detailed and may affect the performance. The info is not enough. It is troublesome to switch dynamically. What should I do ??? 4

9. Magic log ". 4

10. Use the correct log output level 4

11. The log data includes the description and context, for example, the following log: 4

12. What should I do if I cannot query a text file in the log ?? 5

13. dynamically switch log output 5

14. Output collection in logs, 5

15. The operation data ID is used as the index to facilitate query 6

16. Important modules use their own log files. Module logs 6

17. GET request or Session Object Data by writing the filter (resfilter. Java) MDC 6

18. Refer to 7

 

1. The log system is an indispensable unit test and tracking debugging tool.

Especially in any unattended background programs and systems that do not track debugging environments. For a long time, the log system, as an application service, is of great practical significance for tracking debugging, program status record, and crash data recovery.

 

The log can be viewed as a unit test. The output log will overwrite the execution process of the entire method like unit test.

 

 

Author: old wow's paw attilax iron, email: [email protected]

Reprinted please indicate Source: http://blog.csdn.net/attilax

 

2. The log system framework should generally include the following basic features:

 

 

1. The output log has its own category.

In this way, it is easy to query different modules of different systems during debugging, so as to quickly locate the code in which a log event occurs.

 

2. logs are divided into different levels according to certain standards.

Logs after classification can be used to filter logs under the same category.

 

3. multithreading is supported.

Log systems are usually used in multi-threaded environments, especially in Java systems. Therefore, as a system resource, the log system should ensure thread security.

 

Supports different recording media.

Different engineering projects often have different requirements on the recording media of the log system. Therefore, the log system must provide necessary development interfaces to ensure easy replacement of the recording media.

 

High performance.

Log systems usually provide high-speed logging to cope with the normal operation of systems with large request traffic.

 

4. Stability.

The log system must maintain high stability and cannot crash the main business code due to internal errors in the log system.

 

 

3. An Ideal log Mode

It will contain the following information:

· Current Time (no logs need to be included, accurate to milliseconds)

· Log level (if you care about this)

· Thread name

· Simple log name (not fully qualified)

· Log description

Including the following content may cause performance problems:

· File name

· Class Name (I think this should be a fully qualified name)

· Code line number

4. Determine whether the specified method has been called

 

Log.info ("");

Because you know that the row number is specified in log mode, you can determine whether the specified method is called Based on the row number of the log.

5. Add logs to the input and output of the method through AOP

If you can output the input and output (parameters and return values) of each method according to some simple rules, you can basically discard the debugger.

For such logs, the debug/trace level is generally used. When some methods are called frequently,

However, we recommend that you output more logs. in addition, logs can be viewed as a unit test. the output log will overwrite the execution process of the entire method like unit test. systems without logs are unimaginable. therefore, observing the log output will be the only way for us to understand whether the system is running correctly or fails.

 

6. Easy to read and parse logs

There are two types of logs that interest you:

· People (such as programmers)

· Machine (shell script written by the system administrator)

 

 

7. Performance of output logs

In general, 5% of the usage is acceptable...

If the system is important... 30% can all be...

8. The log level debug is too detailed and may affect the performance. The info is not enough. It is troublesome to switch dynamically. What should I do ???

Level Korean-style configuration into a debug... the log itself takes the ten Extension Test... detailed not afraid

 

9. Magic log ".

It will be randomly typed in the log "&&&! # "This string is used to help them locate the issue. We recommend that you use the ATI short-time format.

10. Use the correct log output level

Info: Important business logic processing is completed. under ideal conditions, the log information of info should be understood by senior users and system administrators, and the current running status of the system should be known from the log information. for example, for a ticket reservation system, after a user completes a ticket reservation, the reminder should be "who has booked the ticket from A to B ". another place to output info information is that a system operation has caused significant changes in the system status (such as database updates and excessive system requests ).

 

11. The log data includes the description and context, for example, the following log:

Log. debug ("message processed"); log. debug (message. getjmsmessageid (); log. debug ("message with ID '{}' processed", message. getjmsmessageid ());

The first is a description, the second is a context, and the third is a complete log.

 

12. What should I do if I cannot query a text file in the log ??

Although there is a grep tool to query... But Korean troubles... if the large file is difficult to open...

It is better not to insert logs into the database at the same time... powerful SQL can be used in the middle... easy to query... a tile tool can be used...

No files are used as historical documents... because the database may be cleaned by a timer...

 

 

13. dynamically switch log output

 

Log tool, scripted.

 

 

----> Log4cpp

 

A c ++ function library used for logging can record content to different destinations in a customized manner, such as files and console syslog, some irrelevant records can also be blocked by controlling the record level. You can find details about log4cpp from the http://log4cpp.sourceforge.net.

 

 

 

14. Output collection in logs ),

Sometimes the content of the set we output may be obtained from the database by hibernate, such as the following log information:

Log. debug ("returning users :{}", users );

The best processing method here is to output only the domain object ID or the size of the Set (size). For Java, you have to say a few words, the GETID Method for Traversing each element in an access set is cumbersome. this groovy is very simple (users *. but we can use the commons beanutils toolkit to simplify the process:

Log. debug ("returning user IDs :{}", collect (users, "ID "));

The collect method is implemented as follows:

Public static collection collect (Collection collection, string propertyname) {return collectionutils. Collect (collection, new beantopropertyvaluetransformer (propertyname ));}

 

Followed by the tostring () method. to make logs easier to understand, it is best to provide a suitable tostring () method for each class. the tostringbuilder tool class can be used here. the other is about arrays and some Collection types. because the array uses the default tostring method. some collections do not have a good tostring method. for arrays, we can use JDK arrays. deeptostring () method

 

15. The operation data ID is used as an index to facilitate query.

The operation process for this data is not clarified ..

 

16. Important modules use their own log files. Module logs 17. GET request or Session Object Data by writing the filter (resfilter. Java) MDC

Advanced functions in the log framework: mapped diagnostic context. MDC is mainly used to simplify the management of map Parameters Based on thread-local. you can add any key-value content to this map, and then output it together with the current thread as part of the mode in subsequent log output.

Log4j provides MDC (MDC is a very useful class of log4j, which is used to store context infomation of an application, so that the context information can be used in log. MDC uses a map-like mechanism internally to store information. The context information is also stored independently by each thread. what is different is that the information is stored in "map" based on their key values. Corresponding method,

MDC. Put (Key, value); MDC. Remove (key); MDC. Get (key );

When configuring patternlayout, use: % x {key} to output the corresponding value ). With MDC, We can first obtain user information in the filter, and then use MDC. put ("key") method. When the log executes the SQL statement, It outputs the corresponding value through % x {key.

 

18. Reference

Java log system: an indispensable tracing and debugging tool _ database-developer _ Bi Internet

10 tips for accurately using logs-Programming

Detailed description of log4j database writing-ziruobing column-blog channel-csdn.net.htm

Understand the design and implementation of the Java log system framework (1)-51cto.com.htm

 

Atitit. log system principles and design and best practices (1) ----- Theoretical Summary of principles.