Blogging from the Server Side

Coding Horror blogger Jeff Atwood wrote a good sized post last week offering up a criticism of abusive application logging. He gives several reasons for resisting the temptation to log everything that is happening, including code bloat, performance hits, developer inconsistency, and information overload.

Something tells me he'd look at our logging infrastructure and then take on a facial expression not much unlike the image on his blog's header. Our logging policy isn't as hard core as the one Atwood cited at the beginning of his post, but it does generate a mountain of data if you turn it on full strength.

I think Atwood errs by focusing too much on the use of the logging interface and not enough on the configuration of the logging system's implementation. There are several ways you can deal with the issues he brings up:

At the lowest level, support a wide variety of destinations for logging data, for example a flat file, the system log, or even an asynchronous log the cloud. Moreover, it should be able to write to different destinations depending on the message type.
From the application configuration level, make sure that you can customize the logging for different environments. In a development environment, for example, have everything go to a file. In production, log only messages meeting a certain severity threshold or higher.
Design the logger API so that you can write a log entry with a single line of code. If you have to instantiate one or two objects, e.g. a logger and a logging message, not only will the code bloat, but developers won't be inclined to use it.
Set up a simple policy for logging that will be followed by developers in new code and be easy to retrofit onto existing code.
Create an easy-to-use interface for browsing production logs so that developers can take a look at what's being recorded for both diagnostic and proactive situations. There should be a way to filter by severity, date, and even the class where the logging message was triggered.
Introduce specialized log message types for tracking key performance indicators, like page rendering time and set up monitoring for these things to see how your application is responding to demand.

We've managed to make good use of the logging, and while we did have to do some tuning after we rolled it out, we didn't seen any of the catastropic deadlock situations that Atwood says happened within his own application.