On Fri Oct 22 16:45 1999 -0700, Roger Marquis wrote: > How else would you differentiate logs from various facilities? The > original engineer(s) did a good job with these features (facilities and > priorities) and there doesn't seem to be a compelling reason to remove > either. I think I should have been a little more clear about this. I do not think that we should get rid of the basic concept of categorizing log messages. I just think that the current facility concept is far too weak to be useful in this area and needs to be replaced. I think that we need to decide, at the fundamental level, how we want to be able to filter log messages. IMHO, there are two main "kinds" of filtering. One is to collect all traffic from a specific daemon, such as gathering all messages from sshd, regardless of whether they're about a user connecting or a key being regenerated. The other approach, which I'll call "category filtering", is to filter for a specific kind of event, such as recording all remote connections, regardless of whether they were logged by sshd or telnetd. The current facility mechanism is an attempt to do category filtering, but it suffers from lack of granularity or standardization. And it does not provide any way to filter by daemon. > If 24 facilities are not granular enough how many would be? Most Unix > servers don't have half this many processes writing logs in the first I don't see any reason to set a limit on the number of filtering categories. It should be extensible enough that when the next unforseen technology comes along, new categories can easily be created for it. Also, just because most processes don't usually use syslog doesn't mean they don't have the capability. IMHO, we should make as few assumptions as practical about what will use this protocol. > place. While DAEMON might not be specific AUTH, LPR, USER, NEWS, FTP, > NTP, MAIL, and KERN all seem pretty specific and granular. To those > I'd add STAT for `df`, `uptime`, `loadavg`, `etherstat`, `iostat`, > `nfsstat`, `vmstat` and other SNMP-like info and CRIT for critical > alerts. You're probably right about LPR, FTP, NTP, and KERN; they're about as specific as I can personally imagine needing them. I can easily imagine needing more granularity in NEWS and MAIL; for example, to seperate out IMAP/POP connections from SMTP connections. USER is incredibly vague and usually winds up being used as a "anything that doesn't go somewhere else" category. AUTH is almost never used right, in my experience. Many things which should log there use DAEMON instead, and many things which log to AUTH really belong somewhere else. > See above, this is good point however, and a good reason to add > facilities to the current set. The existing standard is clear enough > 90% of the time and functional enough to at least be maintained for > backwards compatibility. You can argue against compatibility but I > don't think you'll find much support here. I know I wouldn't be > interested in an incompatible syslog daemon. IMHO, if we're going to make any progress in fixing syslog, we're going to need to define a new protocol. However, I have a huge number of machines using the current syslog, and I'm no more in favor of simply breaking compatibility than anyone else. I just don't see any reason that the old and new protocols can't co-exist, possibly even handled by the same daemon. > Filtering is one thing but there are good reasons to write separate > channels before filters. For one it's useful to be able to send > different facilities (and priorities) to different destinations: > /dev/console, loghostA, loghostB, etc. High volume logs may also need > to be handled differently than low-volume logs. This functionality > should continue to be supported by the daemon directly and not require > sysadmins to roll their own. I agree, it's very useful to be able to handle these things differently. I just don't see why category filtering necessarily needs to be handled before any other kind of filtering. You have the most flexibility if you simply extract many different pieces of information from the log message, and then filter on any arbitrary part of it. To use an analogy, it's like using procmail to filter your email. You write a set of rules which can match any information about the message. You might select a few messages based on the sender at the beginning, but anything that makes it through those rules can be filtered by subject. Anyway, I think we're basicly agreeing that we need to be able to filter, it's just a question of how. The more we discuss this, the more I'm convincing myself that metatags are our best bet, as long as they're structured properly. -- Mark D. Roth <[EMAIL PROTECTED]> http://www.feep.net/~roth/
