----- Original Message ----- From: "Juergen Schoenwaelder" <[email protected]> To: "Tom Taylor" <[email protected]> Cc: <[email protected]> Sent: Monday, April 07, 2014 2:27 PM > Tom, > > I believe the problem here is that syslog configurations tend to be > rather implementation specific and finding a common core will be a > non-trivial exercise. Sure, some of the complexity is on relays and > collectors that filter / store / fowards syslog messages based on a > number of rules, so probably there is a more well scoped problem for > implementations that essentially are only syslog originators. > > There was some MIB work [1] in the syslog working group but as far as > I can tell this work did not get much traction - only some common type > definitions have been published as RFC 5427.
Tom The syslog WG was chartered to produce a MIB module and that stayed in the charter until 2008 but then got dropped - as Juergen says, there was not much enthusiasm for it. The WG was closed in 2010. Tom Petch > > /js > > [1] http://tools.ietf.org/html/draft-ietf-syslog-device-mib-17 > > > On Mon, Apr 07, 2014 at 08:58:00AM -0400, Tom Taylor wrote: > > My proposal for a Yang module for SYSLOG control (at the end of this > > message) drew no replies. Would people at least be interested in an > > SNMP MIB that allowed monitoring of the controls? What I have in > > mind is two tables, a basic SYSLOG control table and a rate-limited > > event report table. The contents of the tables would be as follows. > > The field names are taken from RFC 5424. > > > > Basic SYSLOG Control Table: > > -------------------------- > > > > Key: combination of APP-NAME (general class of logs) and MSGID > > (specific event type). > > > > Assigned PRI value > > > > Index into rate-limited table, or nil if not rate-limited > > > > Suppressed (TRUE/FALSE) > > > > If an event type is suppressed, the associated events are totally > > ignored by the log system, so the assigned PRI value is not > > meaningful and rate-limit value should be nil. > > > > Rate Limited Log Control Table: > > ------------------------------ > > > > Key: table index > > > > APP-NAME > > > > MSGID > > > > Reporting interval time units: seconds, hours, days, busy period. > > > > Reporting interval value: integer > > > > Maximum reports per reporting interval: integer > > > > Count of observed events > > > > Count of reported events > > > > Comments? > > > > Tom Taylor > > > > > > > > Message previously sent (28 March) > > ================================== > > > > While working on draft-ietf-behave-syslog-nat-logging, I noted a > > number of management requirements for SYSLOG that are really > > independent of the particular application being logged. These > > include, for example, a list of events for which the operator wants > > logging suppressed, or specifications for rate-limiting specific > > event reports. For more details see Section 6, particularly > > sub-section 6.1.3 of the draft cited above. > > > > Would there be any interest in implementing or deploying a YANG > > module to provide the necessary controls if I created one? > > > > Tom Taylor > > > > _______________________________________________ > > OPSAWG mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/opsawg > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
