Recent research logs in search of things, see good articles on the record.

Original address: http://www.infoq.com/cn/articles/why-and-how-log

Logging in programs generally has two purposes: Troubleshooting and displaying the running state of programs. A good way of logging can provide us with enough evidence to locate problems. Logging is considered simple, but how to effectively locate problems through logging is not a simple matter. Here are the following three aspects, supplemented by code examples, to summarize how to write a good log, hoping to inspire and help others:

• How to log to facilitate Troubleshooting
• What can you remember about the running state of a program?
• What logging methods should be avoided

How can logging facilitate Troubleshooting?

1. Encapsulation of external calls

In the program, the dependency of external system and module is logged before and after calling, which is convenient for interface debugging. When something goes wrong, you can quickly sort it out.

LOG.debug("Calling external system:" + parameters);  
Object result = null;  
try {  
     result = callRemoteSystem(params);  
     LOG.debug("Called successfully. result is " + result);  
} catch (Exception e) {  
     LOG.warn("Failed at calling xxx system . exception : " + e);  
}  

2. State change

Changes in important state information in the program should be recorded to facilitate the restoration of the scene and inference of the running process of the program.

boolean isRunning;    
isRunning = true;  
LOG.info("System is running");     
//...    
isRunning = false;  
LOG.info("System was interrupted by " + Thread.currentThread().getName());

3. System entrance and exit:

This granularity can be at the important method or module level. Record its input and output to facilitate positioning

void execute(Object input) {  
   LOG.debug("Invoke parames : " + input);  
   Object result = null;  
      
   //business logic
      
    LOG.debug("Method result : " + result);  
} 

4. Business anomalies:

Any business anomalies should be noted:

try {  
    //business logical  

} catch (IOException e) {  
    LOG.warn("Description xxx" , e);  
} catch (BusinessException e) {  
    LOG.warn("Let me know anything");  
} catch (Exception e) {  
    LOG.error("Description xxx", e);  
}

5. Unexpected implementation:

Print logs for programs where they are "likely" to execute. If I want to delete a file, the result returns successfully. But in fact, that file didn't exist before you wanted to delete it. The end result is the same, but the program has to let us know why the file did not exist before it was deleted.

int myValue = xxxx;  
int absResult = Math.abs(myValue);  
if (absResult < 0) {  
    LOG.info("Original int " + myValue + "has nagetive abs " + absResult);  
  }

LOG.debug("current progress: " + (currentPos * 100 / totalAmount) + "%");

3. Key variables and what important things are being done:

Perform critical logic, do IO operations, etc.

String getJVMPid() {  
  String pid = "";  
  // Obtains JVM process ID  
  LOG.info("JVM pid is " + pid);  
  return pid;  
}     
 void invokeRemoteMethod(Object params) {  
    LOG.info("Calling remote method : " + params);  
    //Calling remote server  
 }

What logging methods should be avoided?

1. Log of confusing information

Logs should be clear and accurate: when you see logs, do you know that the problem is caused by the connection pool not being able to access the connection?

Connection connection = ConnectionFactory.getConnection();  
if (connection == null) {  
    LOG.warn("System initialized unsuccessfully");  
}

2. Wrong Location

In the product code, console is used to log, resulting in no log found.

} catch (ConfigurationException e) {
   e.printStackTrace();
}

3. Error Level

Error levels often occur, such as confusing code errors and user errors, such as login system, if malicious login, the system will appear too many WARN s, so that administrators mistake code errors. Users can be fed back with errors, but don't record user errors unless you want to control them.

LOG.warn("Failed to login by "+username+");

4. Missing information

There may be two situations: (1) users write less information themselves, which leads to no reference value; (2) users call log s in a way that leads to loss of information, such as no stack trace.

} catch (Exception ex) {
   log.error(ex);
}

Summary:

Logging is something that programmers have to face in their daily programming practice. This article talks about my own experience on this topic, hoping readers can benefit from it. There are many shortcomings, please forgive me.