Re: ugliest application logs ever?

Mark Poepping wrote:
> Maybe distinguish 'ugly' from 'useless'?  There are a great many ugly log
> entries that certainly could not be called useless.
>
> Musing...
>  . a log entry is useless when those who could benefit from it don't know it
> exists or can't get to it;
>  . a log entry is less than useless when it has tokens but no information
>  . a log entry is ugly when it has redundant information, uses big words for
> small ideas, or can't be parsed easily;
>  . a log entry is stupid when it tries to tell someone who doesn't care,
> something they can't possibly understand or do anything about.
>   

Agreed. I think we've seen two main sorts of submissions [1] thus far: 
Logs which are (IMO) useless because they either:
-Do _not_ contain relevant information (or not easily parsed)
or
-Contain Too Much Information (as was the case (IMO) with the Linux 
Auditing Framework)).

Which brings me to a general (in my humble) opinionated statement:
Multi-line logs are not necessarily bad IF they contain some sort of ID 
number or other glue to re-assemble the lines. This is especially 
important when you're collecting logs from a number of similar sources 
and/or can't safely assume that the next line is a continuation of the 
previous line -- as logs from other sources might get interspersed.

Multi-line logs which are O.K. include those from some Cisco devices 
(i.e. ASA VPN where you can *usually* match traffic setup/teardown to a 
particular user) and BRO IDS connection logs (where the IDS logs 
"sessions" with session ID numbers).

A multi-line log such as the Linux Auditing Framework (example provided 
by David Corlette) is near useless to me (and probably most SIM/SEM/SIEM 
setups too). And I would imagine that it'd also be near useless in most 
environments for that matter.

Like I've said, just my humble opinion..

-Matt Cuttler


1: Well, really 3 types; the third type being just plain 
funny/silly/outright dumb.