Scott Mattocks has started off his series about the LUCID development methodology (one he recently proposed) with the first article covering "L" for Logging.

Communication is the only way you can tell if an application is feeling well or is about to fall apart. If your application can't talk to you, you have no way of helping it to feel better. The L in LUCID is for logging. Logs are how applications speak. They capture information that allows us to pick up on those little signs and act early enough to make sure the application doesn't come down with the flu. If you don't have good logging throughout your system, the best you can do is react to your application falling over. A silent application is an application destined to cause midnight surprises for you and your operations team.

He talks about the difference between "just logging" and "correct logging" as well as a recommendation for the different levels: trace, debug, info, warn and error.

Letting you know that something went wrong is really only half of a log messages job. The other responsibilities of a log message are to allow you to accurately reproduce the conditions under which the event occurred, and to allow you to fix any data inconsistencies.