To my mind, logwatch is best. It comes by default with many distros, and although it's a pig to get the hang of the config syntax, once the work's put in it becomes very much a sit-back-and-relax job. It works in batch mode, running every so often to digest recent logfiles, and sort and summarise the entries.
If you don't want to work that hard, swatch is less bang for much less buck. It also runs interactively, eating each new line of a logfile as it appears, and alerting you as requested if it matches certain conditions.
Whatever approach you take, I'd personally recommend against a "sort through the logfiles when things go wrong" approach , in favour of "sort through the logfiles all the time, so I can get the hang of my system".
Firstly, the logs of the observed failure may not be the logs of the root of the failure. Your web server can scream that the data from the cookie cache file is in the wrong format (assertion failure!) until it's blue in the face, but if you're not looking at the system log that says
/cache is 100% full and infer from that that no cookie data can be written to the cache, you won't really know what's gone wrong, by way of example.
Secondly, to my mind it's unreasonable to expect an application to know what sort of logs your system produces, either in normal or pathological operation. Knowing the intricacies of your system is your job as a sysadmin; most sysadmins will go a step further and automate the exclusion of all normal behaviours and the notification of all pathological ones, using regular tools (such as those above) customised for their system, or by writing their own.