"Mark D. Roth" wrote: > On Thu Oct 21 17:10 1999 -0400, Chris Calabrese wrote: > > I suggest the following roadmap: > > For whatever my vote is worth, I think this plan of attack makes a lot > of sense. We need to define our requirements before we can design a > system which meets those requirements. > > > 1. Decide on fundamental services/information > > o Possibilities I can think of include facility, level, > > message-text, originating host, originating timestamp > > Actually, I'm not sure that the facility is relevent. If you think > about it, it's really just an arbitrary tag attached to each message > in the current syslog scheme, and the categories are laid out in a > completely useless manner. Personally, I'd prefer to filter my logs > by regular expression (although there are problems with that, as > well). I guess I agree here. Facility is not fundamental. On the other hand, that doesn't mean it has to be in the message text. The protocol can support meta-tags a-la unalog or ulm (read docs on both these yesterday). > I think we should get back to the basics, which are the originating > host, originating timestamp, message text, and priority code. The > priority code is valuable because an easy-to-extract priority code > would make it practical for the log server to perform certain > notification actions when it receives messages of a preset priority > threshold. In order to make this useful, the priority should be > something other than the current LOG_DEBUG through LOG_EMERG scheme. > One possibility might be an integer between 0 and 256, where higher > numbers indicate higher priorities. If we're going to give up the current syslog priorities, I'd go with the 0..256, but with documented/standard mappings between this and the existing syslog (debug,info,notice,warning,err,crit,alert,emerg) and SNMP (normal,warning,minor,major,critical) priorities. > > 2. Decide on standard optional information > > o Possibilities I can think of include program name, > > process id, timezones, etc. > > IMHO, the program name and the process ID aren't really useful to > anything but a human, so they should probably simply be part of the > message text field. Program names are only needed by humans, but process ID's can be used programmatically to pull out one thread of execution from the logs and need to be a stand-alone data element to do this usefully. For example, we've got a heavily used FTP server, and sometimes want to pull out one FTP "session" from the logs when we suspect something fishy or to help debug problems people are having. We currently rely on the 'ftpd[<PID>]' format that's in the logs, but it would be nice if this were standardized. If you go with a meta-tagging approach, then you can get the program name for free too. Something like auth="jafkdsjf7df8743j" orig=ftp.somewhere.com \ ts=19991022093222 tz=EDT5EST pri=27 fac=net/ftp pid="xxx" \ pn="ftpd" src=127.0.0.1 dst=127.0.0.1 msg="CWD /pub" > [...] > A closely related issue is that of guarunteed, in-order message > delivery. One of the problems with a best-effort mechanism like the > current syslog is that if you're gathering performance data, the one > time you want to see it the most is when the system load goes to hell, > but that's exactly when you'll probably drop messages. If we had a > protocol which acknowledged each message once it was safely written to > non-volatile storage on the server, the client would always know when > to resend a message (or at least when to inform the originating > process or log source that the log attempt failed). Oops, left that out. I meant to include guaranteed delivery as one of the optional services. Yes, this is closely related to QOS, however, as you may decide that you need guaranteed delivery for pri>=128, but not for lower, or some such. I'm thinking back to my grad school days when working on real-time stuff here. -- Chris Calabrese Internet Infrastructure and Security Merck-Medco Managed Care, L.L.C. [EMAIL PROTECTED] .
