Hi Glenn, That system looks good. Something to map syslog messages into SNMP traps and another one for notifications.
Let's make the timestamp high resolution like the new proposed syslog RFC that Rainer is working on. Leave a string binding in the notification trap for error message descriptions that we can't plan for. Maybe set a binding in the syslogCtlSnmpTrapActionTable that indicates a multi part message. Or just constrain the length to 1024 again?? Regards Andrew PS. More comments on your other 6 points will follow when I get my act together. :-) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Mansfield Keeni Sent: Monday, 26 January 2004 3:05 a.m. To: Harrington, David Cc: [EMAIL PROTECTED] Subject: Re: SyslogMIB Issue-#4 Hi Dave, Thanks for the comments. I agree with you. Traps are useful. They provide a uniform mechanism/console for the network manager to manage the network, related devices and processes. There are two levels at which we may want SNMP traps in the Syslog Messaging context. a. To provide another option of how a message will be processed. Presently we have - log (syslogCtlLogActionTable) - display on users console (syslogCtlUserActionTable) - relay/forward (syslogCtlFwdActionTable) - pipe (syslogCtlPipeActionTable) We can add snmp trap to this with relative ease. It is just a matter of adding another table e.g. syslogCtlSnmpTrapActionTable I would propose that the contents of the trap would be o the syslog message itself. Perhaps the length will need to be constrained. o SyslogSeverity, o syslogFacility, o message source o timestamp. b. To notify the syslog/System administrator of notable events e.g. o failure to process a message relay, log, display etc o too many rejected messages o anything else ? Any comments, suggestions ? Cheers Glenn Harrington, David wrote: > Hi Glenn, > > The benefit of having an SNMP trap is that there becomes some > coordination between the syslog messaging and SNMP trap manager > applications. > > Operators often use trap management tools to alert them to problems, and > these applications often have the ability to filter out uninteresting > traps, to sort by priority, to do fault isolation, and so on. Trap > management utilities can also feed into SNMP-based topology mapping > tools (like HPOV) which can use colored icons to represent serious > problems, and so on. > > The problem with a syslog notification is - what would it contain? You > could write one syslog notification for reporting all syslog events by > simply having a varbind with the complete syslog message. That means > that an SNMP trap application cannot do much in terms of sorting by > priority. You could create a notification that ocntains some > standardized values common to syslog messages, such as severity, related > subsystem, vendor, and then include the human-readable string in an > octet string. This might be useful, but it might be less useful than > notifications specific to a technology. > > I think the WG needs to discuss the nature of potential notification > designs. > > Personally I think such a generalized trap might be a good thing for > improving coordination between syslog and SNMP, but it will depend a > great deal on the actual design and how easily that design can be > utilized by applications. > > dbh > > >>-----Original Message----- >>From: Glenn Mansfield Keeni [mailto:[EMAIL PROTECTED] >>Sent: Friday, January 16, 2004 4:48 AM >>To: [EMAIL PROTECTED] >>Subject: SyslogMIB Issue-#4 >> >> >>Issue #4. Snmp Notifications ? Do we need any ? >> >> >>Action: Do we need any? >> Note- Syslog itself is a notification. >> If there a clear requirement for a notification >> that can added. >> >>Status: Waiting on community input >> >> >> >> >> >> >> >> >> >> >> > >
