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 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. > 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. However, the timezone and message hop information may be useful in determining where a bottleneck or break is in a chain of log forwarders, and should be addressed by the protocol as a reliability and self-monitoring mechanism. > 3. Decide on standard optional services > o Possibilities I can think of include signing of > messages, encryption, hop-by-hop authentication, and > quality-of-service stuff (like putting high-severity > messages in the queue first so they don't get dropped > or wait when there's congestion) 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). Comments...? -- Mark D. Roth <[EMAIL PROTECTED]> http://www.feep.net/~roth/
