[logs] ugliest application logs ever?
Matt Cuttler
mcuttler at bnl.gov
Thu Jan 24 18:50:44 PST 2008
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.
More information about the LogAnalysis
mailing list