Articles‎ > ‎

Quality of Logging

posted Jan 29, 2011, 2:23 AM by Michael Schollmeyer
Using a logging framework in your application is not enough. You need quality logging to ensure that the log files really help you out of a critical situation. 

I just asked a client to send us the server log files because they reported a bug that we could not reproduce. I was able to trace the transaction in question back and at the critical point the log file read: 

2008-05-08 18:23:11,904 DEBUG [Scheduler-23]: l=45 
2008-05-08 18:23:11,924 DEBUG [Scheduler-23]: *** 
2008-05-08 18:23:11,925 DEBUG [Scheduler-23]: skip 
2008-05-08 18:23:12,187 DEBUG [Scheduler-23]: end 

This might have been useful to the developer who was originally writing the piece of code. To me, it was white noise. I was wondering how the quality of the log file could drop to this level? 

Quality is compliance. For the log file, this means we need to state some requirements and someone need to check if the log statements fulfill these requirements. 

You will have specific requirements for the logging in your project. Here are some more general notes you might stick to: 
  • Avoid logging every method entry and exit, unless you have a special reason for this. 
  • The log output should make sense for someone not familiar with the exact sources. Let somebody review the log file who didn't write the corresponding code. 
  • Do not dumb dump variables. 
  • Add parameters to your logging output. 
  • Review the logs. If they are bad, improve them.