Thursday, October 23, 2008

Logging tips

I have found more and more that I rely on logging data, and capabilities to help me diagnose a problem. I'd rather have a ton of information to sift through and find the problem than just an an error message. Here are some tips to help you with what to log and when in order to find problems.

Logging needs to be configurable.
You must have the ability to change the level of logging being used easily in order to produce a lot of output when necessary, and minimal output the rest of the time. You don't want your servers or desktops to run out of space because of your logs.


Logs need to be disposable.
Logs are good for a specific problem that is occurring now. You do not need to keep logs from 3 weeks ago to find information. Even if you do need to keep some logs for a longer period of time for reference, it is easier to manage them when they are in daily files.

Logging needs to exist in Code.
Logging needs to be everywhere in code. The more important a piece of code is, the more logging that it needs to have. Log entry and exit points to functions, with some unique identifier, account or user, or account/user. With the exit include the time that the function took to complete. Log all errors.

Use Different levels of logging.
Logging needs to be able to be turned on when it's needed, but turned down to almost nothing when it's not needed. Use debug level for deep details of objects. Use Info level for certain details at key points. Use Warning for situations that may be indicative of a problem or boundary condition that could cause problems. Use Error when errors occur that you do not handle. Do not log as an error things that you handle and do not consider a true error. You only want something showing up at the level of ERROR if it's really an ERROR that you need to possibly fix your code to handle.

Logging tips.
With objects you can override the toString method and simplify your logging statements to get data. Since multiple threads may be writing to the log at the same time, you want to write some unique piece of information to the log for each entry, so you can easily track what a single path is doing. Even though I completely embrace logging, I know that too much of a good thing, can be bad. Too much logging can slow a process down dramatically while it waits for file locks to release. Take advantage of different logging levels, and possibly checking the logging level with if statements prior to using the log statement. Using more efficient methods of logging, such as a message queue can insulate your code from some of the locking issues.

No comments: