Logginge Wows and Voes

September 22, 2006

Those old enough will recogonize the two mehods ( PrintError and PrintDebug) which we would have in each application we would write, which in turn will have something like

If(debugEnabled) printf(message).

In production, we would only have error logs as the synchronous

Then we discovered loggers – like Log4J. With these you could practically turn debug on or off at an individual application level. These gave to 5 log levels, not one. These gave you choice of destinations where the logs went – file, DB, eventlog, email etc.

So If you were unsure if one particular piece of code worked well, we could chose to enable debug logs only for that.


But wait, when we deploy the application into production, and multiple user hit them – then what ?

Loggers gave us an option to log Thread ID and optionally specify “Nested Diagnostic Context” -so, if you identified one line belonging to the client, you could do “grep” and find the prevoius/next lines as well.


But wait, the applications are distributed! The world is sold on multi-tier application. The web layer invokes an app layer on a different machine which in turn invokes a service possibly on third machine. Now what ?

Sorry, the todays loggers dont give you any answers.

What if an application is stable? we will have the logs enabled at only info/warn or error level for them, not at debug level. But the log severity is given at each log item level.

What that means is that, if you get a log deep down into the flow, you have missed out all the lines of log which were set at debug level earlier.

So the logs havent exactly eliminated the issue they were meant to eliminate – i.e. a developer asking the user : Can you please give me steps to recreate the problem.

The first time I used a logger was in early 2000. The last time I saw an application which didnt use a logger was 2003. You would think that the loggers have come of age. They understand production problems – but it doesnt seem to be the case.

So, I bounced this with a group of people I knew and respected, and Logbag was Born. The alpha release is due late October, though further roadmap isnt published yet.

It appears that the founder of log4j, has been working on the next gen logger logback for also an year now. However, it seems to be focussed more on efficiency than on features.

The ideas behind grouping the logs for LogBag are not patented and not copyrighted. This is in best interest of development community – as even if LogBag doesnt get adopted, someone else could implement the same idea and the developers

Similarly, LogBag will be released under multiple Open Source licences, so that the users could choose the approprite license to protect their work and the enhancements they make.

Any other ideas you want to be implemented in a logger let me know ( pranshujain at gmail dot com) or let Ceki Gülcü ( the founder of Log4J and of logback) know the home page is http://logback.qos.ch/index.html and since I dont see an email id there, I wont tell you the same.


One Response to “Logginge Wows and Voes”

  1. One way, I have overcome the problem is to use the MDB’s. Let all the messages be send across to a filtering application via MDB’s from the logger’s running on each of the nodes on the cluster. The filtering application can segregate the messages and process them as required. So, if we want to track an individual thread, then we can just track the messages based on the thread id and log them to be analysed further. Although, such a approach can work only with a messaging server.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: