mjr wrote: > 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. Agreed. > 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. Several attempts along these lines have been made - proposals for a semi-structured format can be found in http://www.hsc.fr/gulp/ http://nob.cs.ucdavis.edu/%7Ebishop/papers/Ps/stdaudfmt.fm.ps and I have an implementation which also uses a label=value variant at http://jade.cs.uct.ac.za/idsa/download/ As for the meaning of the logged elements: Personally I am not quite sure if an overarching ontology is (currently) achievable, though such suggestions exist: For example, the XDAS specification names 45 generic events, while (from an outside perspective) the IDWG also appears to working on this. My position is that it might be better to let things evolve along several lines before standardising - Allowing particular application classes come up with something which describes their domain (eg CLF -> syslog2 for web servers) and using that for detailed analysis. - Finding interesting mappings to higher levels of abstraction - such as risk, access, interface complexity or control flow. At the moment I am busy writing something on this topic, if anybody is interested, I can make it available once it is finished. An older, experimental and naive service model is implemented in http://jade.cs.uct.ac.za/linetd/ My 2 cents of course (which, at the current exchange rate, buy 0.2 of yours ;) regards marc _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Thu Dec 12 2002 - 09:23:41 PST