Saturday, October 30, 2010

web application logging dilemma

By exploring languages like lisp, scheme, scala etc I've come to disliking "verbose code" and I try to write less code as much possible(I still follow the KISS principle though, so no clever tricks unless really necessary). But industry(and day to day) reality is Java, and "verbosity" manifests itself in java no matter what you do.
Typically, Writing a debug log in a java application takes *at least* 2 lines..
log.debug("your error message" + usually_a_concatenation)

As a result, My less verbose code instinct makes me write fewer and fewer debug logs and lets me write only the necessary error logs because number of lines just explode when you write too many logs and doesn't look good. And also, more logs hamper performance.

I am writing this post because last night I spent 2 hours figuring out an issue in staging servers. It took so much time because there were not enough log statements(so I had to do a lot of looking into the code, guess work and trials to figure out where the problem might be) and in an enterprise setup it becomes a very slow process to try stuff at stage/production servers.

The lesson learned is that, there should be enough(infact alot of) logs for the whole initialization process. So that you don't have to waste time guessing. Since they will get printed only on server startup so they wouldn't hamper the performance of the over all system. And enough debug logs per request, so that issues can be tracked down easily by printing debug logs. Though it will increase the number of lines, will not look good but it is probably worth it :(.


  1. Probably silly, but did you consider moving the decision to check `log.isDebugEnabled()` to *inside* the `log` class?

    Then you could merely write: `log.debug("your error message" + usually_a_concatenation)` everywhere.

  2. No, because in our case(and usually) log is not an instance of any custom written class. It is an instance of log4j framework class org.apache.log4j.Logger.

    And, even if we create a custom class to handle the check inside it.. that will defeat the purpose of check as it is mainly put to save unnecessary evaluation(when you're not printing debug logs) of expression passed as argument to the debug method(in this case one string concatenation). It can be saved without the check in a language that supports "lazy evaluation" of method arguments.