[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus
Being not MIB-literate, I tend to agree that it does not add much
complexity if there is a table which most often includes just a single
element.
What is used in practice. It depends on your point of view. If you look
at deployments, a single engine is the vast majority. If you look at
number of different implementations, I am not so sure. In any case, I
would vote for extensibility IF that does NOT add considerable
complexity. I can not make an informed judgement on the later.
Rainer
> -----Original Message-----
> From: Glenn M. Keeni [mailto:glenn@cysols.com]
> Sent: Tuesday, January 16, 2007 12:21 PM
> To: syslog@ietf.org
> Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking
consensus
>
> Tom,
> > Which technique is best depends on whether the occurrence of
> > multiple instances is the norm, which should be modelled and
> > supported. I think that this is not the case for syslog and
> > so the additional complexity is not justified. I imagine you
> > think otherwise.
> The syslogMIB leaves it to the users to choose how they want to
> manage their syslog entities. I do not see the problem with that.
> About complexity- there is hardly any added complexity worth
> mention in the MIB design, implementation, and corresponding NMS
> development.
>
> Glenn
> >
> tom.petch wrote:
> > ----- Original Message -----
> > From: "Glenn M. Keeni" <glenn@cysols.com>
> > To: "tom.petch" <cfinss@dial.pipex.com>
> > Cc: "David Harrington" <ietfdbh@comcast.net>; <syslog@ietf.org>
> > Sent: Sunday, January 14, 2007 5:12 PM
> > Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking
> consensus
> >
> >
> >> tom.petch wrote:
> >>> I do not believe that the MIB should be modelled to support
> multiple
> > instances
> >>> of a syslog device as an SNMP table.
> >>>
> >>> Where multiple instances do exist in a single machine, and there
is
> a
> >>> requirement to manage more than one with SNMP, then I believe that
> the usual
> >>> SNMP techniques are adequate to support this and each can be
> modelled within
> > the
> >>> MIB module with scalar objects, thereby simplifying the MIB module
> and
> > making
> >>> more likely to be implemented.
> >
> >> Using Tables is the standard SNMP technique for managing multiple
> >> instances. That is exactly what is done in the current MIB.
> >
> > Glenn
> >
> > Well, no. If you have two routers within a single box, served by a
> single
> > agent, there is no table in any MIB module that has ever existed
that
> allows you
> > to have both router FIBs etc as part of a single object tree
starting
> at
> > 1.3.6.1.2.1.
> >
> > Some specific MIB modules have taken the view that multiple
instances
> should be
> > so supported and so have made tables of (almost) every object
> pertaining to the
> > instance, as you have chosen to do with syslog. Most creators of
MIB
> modules
> > have not done this and have relied on other standard SNMP techniques
> to allow
> > for the support of multiple instances of the router, hub, bridge,
> host etc etc
> > etc by SNMP.
> >
> > Which technique is best depends on whether the occurrence of
multiple
> instances
> > is the norm, which should be modelled and supported. I think that
> this is not
> > the case for syslog and so the additional complexity is not
> justified. I
> > imagine you think otherwise.
> >
> > Tom Petch
> >
> >
> >> Glenn
> >>> ----- Original Message -----
> >>> From: "David Harrington" <ietfdbh@comcast.net>
> >>> To: <syslog@ietf.org>
> >>> Sent: Friday, January 12, 2007 7:31 PM
> >>> 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
> >>
> >
>
>
>
> _______________________________________________
> 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