Stephan Schmidt writes about logging in his latest article. I think he has 7 mostly valid points and even 7 more in an older post, but there is one advice that is missing, which also invalidates one of his points:

Use different logging hierarchies

Why? Well Stephan writes in the first article:

Logging in web applications is important - to know what’s going on, for performance tuning and incident analyis.

So what do you do if you have performance issues in your system? You change your log level from WARNING or ERROR to INFO. So you get more detailed information. But now you get tons of logging that you are not interested in. In most logging approaches I have seen there is only one logging hierarchy. Normaly based on the full class name. But which class is responsible for performance related logging? Most of the time there is none. But one could easily use a prefix to differentiate between various aspects of logging. I'd like to propose these logging hierarchies:

no prefix: the normal technical logging used for debugging and exception logging

TIMING: logging of performance relevant information, i.e. time elapsed between start and end of method calls. On DEBUG level this is reported for every method, on INFO this is reported on all public methods, on WARN on all calls that go between packages and on ERROR only on calls from outside the controlled code and to remote resources (database, webservices and so on). Once the application runs stable you should get a baseline from this.

SECURE: logging of security relevant information: failed logins, creation of users, access of invalid urls, input values that look like some kind of XXX-injection, spikes in the number of requests. In this case the log level should control the thresholds on which logging appears.

AUDIT: logging information about completed (or failed) business transactions. This might be overkill for applications that work on a single database. But the application I am working on right now consists of about 50 pieces of hardware and a similar amount of various software pieces. It would be awesome if we could have a logging that basically says: Node A thought it completed a transaction but the transaction never apeared on Node C so we probably have a problem in Node B between A and B.

USER: logging information about user behavior. Invalid Data entered. Actions used. This should be an awesome source of information about which features work, which don't and what pieces are really confusing for the user. With this I obviously do not agree with

Only log technical exceptions not user exceptions

For implementing these different loggers AOP comes in handy and you absolutely should look at MDC. Go figure

Any other logging hierarchies one should consider? Leave a comment.