[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus
Nothing we do here should prevent you from using multiple snmp agents
running on different ports if desired.
dbh
> -----Original Message-----
> From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com]
> Sent: Friday, January 12, 2007 1:53 PM
> To: David Harrington; syslog@ietf.org
> Subject: RE: [Syslog] MIB Issue #1 - one or multiple? Seeking
> consensus
>
>
>
> > -----Original Message-----
> > From: David Harrington [mailto:ietfdbh@comcast.net]
> > Sent: Friday, January 12, 2007 10:31 AM
> > To: syslog@ietf.org
> > 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
> > dharrington@huawei.com
> > dbharrington@comcast.net
> > ietfdbh@comcast.net
> > co-chair, Syslog WG
> >
> >
> > > -----Original Message-----
> > > From: Glenn M. Keeni [mailto:glenn@cysols.com]
> > > Sent: Friday, January 12, 2007 3:30 AM
> > > To: syslog@ietf.org
> > > 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