On Wed, 11 Dec 2002, Marcus J. Ranum wrote: > If we want to achieve "bang for the buck" in syslogging, > we'd worry less about the transport and more about the > contents of what is initially logged. Back a few months ago > I posted a token dictionary that Paul Robertson and I worked > up as part of the now-defunct Fargo project. Basically, the > idea was to tag components of messages with significance and some > rudimentary information intended to make them easier to parse > on the backend. Nothing fancy, but more along the lines of: > [GMT date/time][GMToffset] RAWMSG=string, IPSRC=blah, SEVERITY=foo, > PATHNAME=blah, APPLICATION=sendmail > etc. The dictionary used need not be large, complex, or complete, > but it'd make huge strides in the right direction because the > rest of the parse rule could be MUCH more accurately matched based > on the presence and content of the various tokens. > Hear, hear! Marcus has revived the conversation I started back in, oh, August, about what conditions we'd like to have logged in the first place. Although changing every bit of app code out there is an overwhelming prospect, I have it on Good Authority that at least a couple of my buddies in the open source community are implementing a few of my ideas about things that Should Be Logged. I'm trying to write up a summary of where the list left the conversation so we can publish something. > But to do this would entail visiting the source for EVERY APPLICATION > that logs, and changing every line of code that generates logs. > I just can't see that happening any time soon. :( Hell, it might not happen soon, but it is happening >now< for a couple of apps that shall remain nameless. And once we've got a consensus on the state changes that ought to be recorded, and a couple of applications we can point to to say "look, here's how it's done" -- surely that's a vast help in the never-ending battle! > However, I don't think people care enough about getting logging > right to pay the cost in time to implement client-code changes. > They'd rather pay the cost in gigantic kludgy post-processing > based on string tokenization - which means having a _duplicate_ > syslog knowledge-base to unparse the arbitrary strings. If you > think about it for a second, it'd be harder to imagine a stupider > way to go about doing logging - but that's where we're headed. Well, I might end up with an even larger bruise on my forehead from fighting this fight, but so it goes.... tbird _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Wed Dec 11 2002 - 14:25:14 PST