David: > > I am really struggling with that restriction not to > standardize syslog > > storage in IETF. It diminishes the value of the syslog protocol as > > people can't write a standard syslog parser. > > I'm not sure I understand why you feel this. Assuming you are > parsing what was sent on the wire, that should be standard > (to the degree that we standardize it).
Well, I am parsing a log file. If I am parsing a syslog log file, regardless of what we send, it does not match what is stored unless it is standardized. The state of the art today is very sad and for no good reason. Consider two examples. First, I send a well formed message: <183>Oct 11 22:14:15 aokmians3-w2k su: Simple message 8 On Solaris, I have in the log file: Oct 11 22:14:15 aokmians3-w2k aokmians3-w2k su: Simple message 8 On Linux -- same (only I assume hostname was not resolvable): Oct 11 22:14:15 161.44.64.125 aokmians3-w2k su: Simple message 8 Why duplicate hostname or IP was added if it was a well-formed message? Then consider platform implementation variations. For example, Solaris logs TLI endpoint identifier (IP + port) for forwarded messages if FQDN can't be resolved: Example of what's logged on server A: Jun 20 11:26:57 bacdev1-cmts-1.cisco.com 715: My message Same messages relayed to host B as stored: Jun 20 11:26:57 [10.86.149.160.134.68] 715: My message Great! And guess what the 10.86.149.160 is? The IP of the relay A, not of message originator "bacdev1-cmts-1.cisco.com"! For one, this loses the identity of message originator (which could be addressed in -protocol), but it is also a new log format to parse (TLIs). Solaris has also a features where it can add other stuff to the stored message like message id. Example: Sep 29 21:41:18 cathy ufs: [ID 845546 kern.notice] alloc /: file system full I agree the -protocol and -transport are definitely higher priorities and -storage is a separate topic. But without some agreed upon storage format, writing a portable log parser is a challenge. In the above example, Sun had to invent a proprietary mechanism to store severity and facility in the message, for example. Whichever is the appropriate way to solve this, I don't think anyone benefits from the existing state of the art, which will definitely continue if nothing is done about it. Thanks, Anton.
