Jakub is a Java EE developer since 2005 and occasionally a project manager, working currently with Iterate AS. He's highly interested in developer productivity (and tools like Maven and AOP/AspectJ), web frameworks, Java portals, testing and performance and works a lot with IBM technologies. A native to Czech Republic, he lives now in Oslo, Norway. Jakub is a DZone MVB and is not an employee of DZone and has posted 155 posts at DZone. You can read more from them at their website. View Full User Profile

The Art of Logging (review)

06.11.2010
| 7660 views |
  • submit to reddit

Colin Eberhardt, the co-author of the Simple Logging Facade, has written a very good article The Art of Logging, which should be a compulsory reading for every developer especially in the server side development domain. It’s good both as an introduction as it covers all the important aspects and also for experienced developers because it has some very valuable insights.

Few ideas and sentences that really should be stressed:

  • "Logging is the process of recording application actions and state to a secondary interface." Developers should really realize that a log is indeed an alternative interface to their application and may be the only one they’ll have access to in a production environment.
  • "Considering the importance of log levels, when embarking on a project, the development team should agree on exactly how these levels are used in order to ensure consistency between developers." I saw some projects where consistency was crouched and crying in the corner :-) With consistency it’s easier to understand a log, to know what to look for and how to search for it.
  • Regarding exceptions, you should be aware that not all exceptions are actually errors and you should always consider what level is appropriate for reporting a particular exception.
  • What to log:
    • The level of detail needed in a log depends on the presence or absence of other monitoring tools for the application.
    • On the importance of context: "In summary, a log message without context information is often as useful as no log message at all!." This sentence shall be in gold and also burnt to the skin of each developer who fails to apply it. How many times have I been desperate troubleshooting a problem for hours and days that wouldn’t take more than 5 minutes to diagnose and solve if proper context information was provided in the exception and/or log!
  • "… it is worth thinking about applying a standard format to your logged messages. This can prove very valuable if you need to analyse large log files (where tools like grep are indispensible)." I can sign this, trust the guy, he knows what he’s talking about!
  • "good messages are brief and provide the most important context information"

Logging to little is terrible if not outright evil but logging too much isn’t good either and brings numerous problems, for example it unnecessarily complicates the code, too detailed logs are hard to analyze, and, from my experience, large logs in production environments are cleared more often for space reasons and thus you’re more likely to have no log at all when you need it.

There is also a good point about unit testing your logging code to verify that important exceptions are indeed logged at the appropriate level and including the exception itself (not actually testing the message as that would be unnecessarily complicated to do and to maintain). I actually got recently the idea that while running unit tests you should always also review the log produced and verify that it communicates everything necessary for troubleshooting the tested cases and this at both the usually encountered log levels, i.e. info and debug.

Summary: Make sure to read the article and apply it in your day to day coding! And if you know about other sources regarding logging best practices, I’d be glad to learn about them too!

From http://theholyjava.wordpress.com/2010/02/10/the-art-of-logging-review/

Published at DZone with permission of Jakub Holý, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)