[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus
I agree for the reasons outlined in mails before.
Rainer
> -----Original Message-----
> From: David Harrington [mailto:ietfdbh@comcast.net]
> Sent: Friday, January 12, 2007 7:31 PM
> 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?
>
> 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.
>
> 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