> First, I have to ask just how common are messages approaching 64K? A > backwards compatible XML wrapper is going to add a few > hundred bytes of > overhead, not tens of KB. Since a backwards compatible syslogd would > merely be wrapping the message, it's not going to include any of the > extensions - the whole purpose is simply to avoid having to do all of > the parsing and reformatting later on the analysis side: ... > Increasing from 135 characters to 172 does not seem like an > unworkable > increase. I imagine that this is what Microsoft believes to be true too every time they put out the next version of software. The point is that your still adding 21% overhead. As for the 64k, who knows, don't you remember when the average mail message was less than 10KB? But in reality, I really don't want my UDP messages going over 1500 bytes to keep them from fragmenting on the Ether and taking up extra time on a busy network (not all of us have gigabit ether yet). > > XML is good for supporting a large variation in data types > with varying > > structure. Logs are very structured with little or no > variation in data > > types. The log content could be varied, but again it is still well > > I have to disagree here. Syslog is not very structured at all > - you get > facility, priority and a blob of text. There is no standard > format for > that text and you need custom parsers to handle every programs's > messages. Consider OpenSSH and the commercial SSH - by nature they're > extremely similar but they don't exactly log the same thing. > That Cisco > PIX in the example above logs in a completely different fashion than > ipfw or iptables - if I want to keep track of hosts which are being > accessed, I have to write some code to parse and reformat, which is a > huge pain. Who says that everything has to look alike? I know that my sendmail logs are very well defined, and my firewall logs, and my dns logs, and my OS error messages, and my web logs, and my ... This doesn't mean that my sendmail logs look like my firewall logs nor do they have very much in common and none of the data is free style format. What would be wrong with defining 100s or even 1000s of event formats with each format being well defined and concise? A person/company/organization can register an event with the well defined format for their applications/ services. This event format can be used on the backend log server to parse the logs as you've programmed it to do. The log server can handle this with ease. You know computers are very good with taking data sets and parsing them. It doesn't even require XML. Granted, application developers in the same domain should try to create common formats. The web's done a pretty good job of that. Remember, the machines where logs are coming from are not there to process logs. They have other jobs to do such as routing, web serving, mail serving, firewalling, file serving, database serving, ... We want to get the log and transfer it off the system as soon as possible intact with the least amount of resources used. I don't know about you, but every time we want logs, we always get asked about how much CPU, memory, disk space, and network will be used. Logging does cost something in resources. No free lunch here. Bottom line XML is a waste of time on the clients. Ron Ogle Rennes, France _______________________________________________ LogAnalysis mailing list LogAnalysisat_private https://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Thu Aug 22 2002 - 14:36:08 PDT