Anton Okmianski (aokmians) wrote: >> 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.
With the present MIB it is possible to have a. A single snmp agent per host manage multiple Syslog entities b. multiple snmp agents per host manage each managing a separate syslog entity, [if someone wants to do that] and there will no problem of interoperability between systems of type (a) and configuration (b). Glenn > > >> -----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 > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
