Java log Design & amp; Practice (3), java log

Java log Design & Practice (3), java log

1. Select the appropriate Log Level
2. Output clear prompt text and sufficient field information
3. Output a line of content. Do not wrap it.
4. Miscellaneous

 

1. Select the appropriate Log Level

When selecting a log level, some general rules must be followed and cannot be defined at will.

Log4j log levels, sorted from low to high: all trace debug info warn error fatal off
All off is only used to enable or disable all logs in the log4j configuration file, and trace fatal is generally not used.
For developers, you only need to pay attention to the debug info warn error

Debug
Under normal circumstances, no output is required. log information must be output only when a problem occurs. Because the production environment cannot perform single-step debugging, you can think of the debug-level logs as debugging in the production environment.
Info
You may need to pay attention to or output only important information, such as user logon, logout, and background job execution duration.
Warn
Logs output when there are some potential risks, such as: the request parameter contains the attack injection script
Error
For example, an SQL exception occurs when a database is requested.

Of course, the best method is to refer to the excellent open source code.

2. Output clear prompt text and sufficient field information

Key points:
1) Clear prompt text. You can see this prompt text to know what happened and do not need to pull the source code again.
2) Adequate on-site information, such as user information, parameter values that cause exceptions, and stack information

Example:
LOG. warn ("Unknown value for includeParams parameter to URL tag:" + includeParams );
LOG. warn ("Unable to put request parameters (" + extractQueryString () + ") into parameter map.", e );
LOG. warn ("cocould not find token mapped to token name" + tokenName );

 

3. One log line.

This is to facilitate log tracking and analysis. When you use the grep command, you do not only see part of the log.

 

4. Miscellaneous

 

. Try to use a set of log interfaces. We strongly recommend slf4j

Two reasons:
1) Use the {} placeholder to avoid String concatenation

Take the three logs as an example.
LOG. warn ("Unknown value for includeParams parameter to URL tag:" + includeParams );
LOG. warn ("Unable to put request parameters (" + extractQueryString () + ") into parameter map.", e );
LOG. warn ("cocould not find token mapped to token name" + tokenName );

If slf4j is used, the statement is as follows:
Log. warn ("Unknown value for includeParams parameter to URL tag :{}", includeParams );
Log. warn ("Unable to put request parameters ({}) into parameter map.", extractQueryString (), e );
Log. warn ("cocould not find token mapped to token name {}", tokenName );

2) check whether the log is enabled before the actual log output is executed.

When using log4j + slf4j in combination, the following warn method is actually executed:
Public void warn (String format, Object arg ){
If (logger. isEnabledFor (Level. WARN )){
FormattingTuple ft = MessageFormatter. format (format, arg );
Logger. log (FQCN, Level. WARN, ft. getMessage (), ft. getThrowable ());
}
}

 

4. 2. Do not use System. out. println ()

This is not much to say. The log shows an inexplicable hello, world. What do you think ????

4. 3. Do not use e. printStackTrace ()

This type of printing can only be output to catalina. out, And the output destination file cannot be specified separately, which may cause log output confusion.

4.4.slf4j print exception stack information

Two examples:

try {     if (true) {         throw new RuntimeException("i'm ok");     } } catch (Exception e) {     log.error("Error. param:{}, param2:{}, param3:{}", param, param2, param3, e); }

Print:
ERROR 2015-01-17 15:11:51, 426 Error. param: 0, param2: 2, param3: false [cn. xxt. log. test. Slf4jTest. main (Slf4jTest. java: 36)]
Java. lang. RuntimeException: I'm OK
At cn. xxt. log. test. Slf4jTest. main (Slf4jTest. java: 33)

try {     if (true) {         throw new RuntimeException("i'm sorry");     } } catch (Exception e) {     log.error("Error. param:{}, param2:{}, param3:{}, {}", param, param2, param3, e); }

Print:
ERROR 2015-01-17 15:11:51, 429 Error. param: 0, param2: 2, param3: false, java. lang. runtimeException: I'm sorry [cn. xxt. log. test. slf4jTest. main (Slf4jTest. java: 44)]

Difference: the former outputs exception stack information, while the latter does not
Cause: the latter uses the {} placeholder to print the exception Object e, resulting in no output of the exception stack information

 

References

Why use SLF4J instead of Log4J?
Http://www.importnew.com/7450.html