When dealing with logs, it's difficult to understand what led up to the error that has just occurred. You know that something definitely happened, but to understand the problem it’s extremely important to find out what started the issue in the first place.

For the most part, your application runs logs in a reasonable way--logs tagged INFO and even DEBUG can overwhelm you with irrelevant details and TRACE can show you a bit more. However, ERROR level logs will jump into view with even the most restricted view settings. 

Ok, now you see there's an ERROR--but you've been running the system with INFO level logs only and everything important is swallowed. There are a couple options here: log more, or log smarter. Often, more logging occurs by adding more INFO level logs, or by running the system with DEBUG enabled for a period of time after a new release.

But if you want to log smarter, you can try setting up what could be called “opportunistic log handling”, an approach that can get you the logs you need, when you need them, while keeping out of your hair when you don't. In this article, we don't claim to solve anything--we show some examples and advantages to this idea, how to set it up in Java, optimize performance and leave you with some open questions that we ask ourselves sometimes here at RebelLabs.

The full article: http://zeroturnaround.com/rebellabs/attack-of-the-logs-consider-building-a-smarter-log-handler/