Here is an anecdote from a recent interaction with an enterprise application in the electric power industry:
1. Dave the developer logs all kinds of events. Since he is the primary consumer of the log, the format is optimized for human-readability. For example:
02-APR-2012 01:34:03 USER49 CMD MOD0053: ERROR RETURN FROM MOD0052 RETCODE 59
Apparently this makes perfect sense to Dave: each line includes a timestamp and some text.
2. Sam from the Security team needs to determine the number of daily unique users. Dave quickly writes a parser script for the log and schedules it. He also builds a little Web interface so that Sam can query the parsed data on his own. Peace reigns.
3. A few weeks later, Sam complains that the web interface is broken. Dave takes a look at the logs, only to realize that someone else has added an extra field in each line, breaking his custom parser. He pushes the change and tells Sam that everything is okay again. Instead of writing a new feature, Dave has to go back and fill in the missing data.
4. Every 3 weeks or so, repeat Step 3 as others add logs.
In 2012, is it really necessary to have a unique parser hostile format for log descriptions?
Silly rabbit logs are for parsing.