> -----Original Message----- > From: David Harrington [mailto:[EMAIL PROTECTED] > Sent: Friday, January 12, 2007 10:31 AM > To: [EMAIL PROTECTED] > Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus > > Hi, > > [speaking as co-chair] > > Finally, we are getting discussion of the issues of what > needs to be modeled by more than two people with opposing ideas. > > I would like to reach consensus on this question: > > Is it acceptable practice to have more than one syslog > application (sender, receiver, relay) running on a > server/host/system simultaneously?
Absolutely. Especially, sender. > At this point, based on Glenn's suggestion of having an > experimental and a production syslogd running at the same > time, and Rainer's description of syslog in a Windows > environment, I think that having more than one active syslog > application (sender/receiver/rerlay) is a reasonably common > scenario in some environments and not in others. > > The current MIB interface is designed to support multiple > syslog sender or receivers on the same server/host. I believe > this is a valid requirement. > > If you agree with this, please say so. > If you disagree with this, please say so. Agree. However, I am not clear it must be covered by a single SNMP agent with single MIB. It should probably be possible to manage multiple syslog instance with single SNMP agent per host, but we are not excluding each instance having it own SNMP agent on different port, right? I don't know if this violates anything in SNMP, but it may be easier implementation-wise no to have to integrate my syslog component with system SNMP agent. Thanks, Anton. > > The chairs will make a determination of consensus, and this > issue will be closed. > > David Harrington > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > co-chair, Syslog WG > > > > -----Original Message----- > > From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] > > Sent: Friday, January 12, 2007 3:30 AM > > To: [EMAIL PROTECTED] > > Subject: [Syslog] The SIMPLE SyslogMIB > > > > Hi, > > I will try to address David's concern about the complexity > > and utility of the MIB. > > The basic design principle has been to keep the MIB simple. > > It has gone through several iterations, each one making it > > simpler than the earlier version :-) > > At present the MIB basically allows the NMS to manage the > > syslog entity (sender, receiver, relay) by looking at its > > (a) status ( up/down/suspended/unknown) > > (b) configuration > > (c) macro statistics > > total number of messages (sent, received, relayed) > > total number of exceptions > > ( drops, discards, malforms) > > The notifications will tell the NMS about change in the > > syslog entity's status. > > That in a nutshell is what one will want to or need to do > > for basic monitoring/management. > > > > The MIB can provide information on multiple syslog entities. > > [Scenario: two syslogd's are running on a syslog server - one > > for experiments one for regular operations.] > > > > So if we want we may get a table like the following from the MIB. > > > > Syslog Status and Statistics Summary > > ==================================== > > > > +-----+-----+--------------+------+-----+-----+---------+ > > |Index|Type | Description |Status| Messages | > > | |rsR* | | |Sent | Recd| Dropped | > > +-----+-----+--------------+------+-----+-----+---------+ > > | 1 |r-- | SecuritySys | Up | - | 120| - | > > | 2 |r-- | Operations | Up | - | 1234| - | > > | 3 |r-- | Experiment-1 | Up | - | 9890| - | > > | 4 |-s- | SenderExpt-1 | Up | 99| - | 0 | > > | 4 |rsR | Experiment-2 | Down | 1200| 2345| 0 | > > +-----+-----+--------------+------+-----+-----+---------+ > > * r: Receiver , s: Sender, R: relay > > > > Note that this is a sample. Several other columns are possible. > > In a similar manner the address and port of the syslog receiver, > > the number of malformed messages received etc. can be obtained. > > > > In more advanced usage, a syslog entity can be started [on a > > specific address and port, if it is receiver] or an existing > > syslog entity can be stopped or suspended. [I will not try to > > explain how that can be done.] > > > > I think that is simple as it can be. Let me know if > > a. it can be made simpler. > > b. it is too simple and more detailed information is necessary. > > e.g. facility wise statistics as follows. > > > > Facility-wise Syslog Statistics Summary > > ======================================= > > +-----+--------+-----+--------------+------+-----+-----+---------+ > > |Index|Facility|Type | Description |Status| Messages | > > | | |rsR* | | |Sent | Recd| malformd| > > +-----+--------+-----+--------------+------+-----+-----+---------+ > > | 1 | 51 |r-- | SecuritySys | Up | - | 123| - | > > | 1 | 52 |r-- | SecuritySys | Up | - | 45| 45 | > > | 1 | 53 |r-- | SecuritySys | Up | - | 6| - | > > | 2 | 51 |r-- | Operations | Up | - | 789| - | > > | 2 | 52 |r-- | Operations | Up | - | 10| 10 | > > +-----+--------+-----+--------------+------+-----+-----+---------+ > > > > * r: Receiver , s: Sender, R: relay > > > > I will not recommend tables for > > - facility-wise and severity-wise statistics > > - facility-wise, severity-wise and host-wise statistics. > > for details like that one should probably use custom applications. > > > > Now, talking of MIB complexity. The present MIB is simple and its > > implementation is simple. ( Yes. I have implemented it.) We need to > > hear - something like "I want to do 'XYZ' - how do I do it with > > the MIB?". > > > > Glenn > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
