Rainer Gerhards wrote: >Do they see any chance for a "SSYSLOG" protocol - meaning a "simple" >syslog protocol based on TCP but the focus being on simple, that is no >beep and the like. Server syslog is, unfortunately, not the problem. :( It's easy to roll-out arbitrarily goofy and complicated stuff in the servers - let the standards guys worry about that - the True Hell of Syslog is going to be in the client apps. Right now, everything logs arbitrary strings. At the time, it probably seemed like a good idea, and the most flexible approach. Unfortunately, the ability to write arbitrary untagged data has made syslog nearly useless and spawned an industry of application-specific log parsing. 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. 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. :( There are ways it could be made evolutionary: stick the raw syslog message string into field RAWMSG add APIs that let you cluster better info along with the syslog() function call and write a new wrapper, then try to get people to use it. 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. mjr. --- Marcus J. Ranum http://www.ranum.com Computer and Communications Security mjrat_private _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Wed Dec 11 2002 - 13:49:55 PST