[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus
Hi,
[speaking as co-chair]
MIB Issue#1 is not about whether Windows is a real operating system.
If you want to have that discussion feel free, but please do it
elsewhere - it is inappropriate for the syslog WG, and it is certainly
off-topic for MIB Issue#1.
David Harrington
dharrington@huawei.com
dbharrington@comcast.net
ietfdbh@comcast.net
co-chair, Syslog WG
> -----Original Message-----
> From: tom.petch [mailto:cfinss@dial.pipex.com]
> Sent: Tuesday, January 16, 2007 8:40 AM
> To: Rainer Gerhards; syslog@ietf.org
> Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking
> consensus
>
> Rainer
>
> Using this as a convenient peg on which to hang an answer.
>
> You asked about software architecture. I think that for all
> its commercial
> success, Windows is not, in some key respects, an operating
> system in that it
> does not provide the infrastructure that applications
> deserve. You point out
> that it does not have an SNMP engine or a syslog engine.
> Other operating
> systems do, so that an application wishing to use those
> services can invoke them
> (API, inter-process call, 127.0.0.n via a socket ....) at a
> level that is
> suitable for the application.
>
> Windows does have a number of excellent third-party SNMP
> engines, so I expect to
> see one of those installed - but only one - with a load of
> fourth party
> applications hooking into the services that the snmp-engine
provides.
>
> For the other software you mention, I do not see them as
> providing a service for
> multiple other software to use ie I only have the one web
> browser, e-mail
> server/client etc and often that limitaton is hard-coded into
> proper operating
> systems as well (Windows purports to support multiple web
> browsers - 'do you
> want this to be your default?' - but my attempts to run them
> have been a
> disaster).
>
> You comment that Windows has no syslog engine to serve
> multiple applications, so
> each application does it itself, with the consequences we are
> now discussing.
>
> As to how much gets modelled in a MIB module, there is a
> standards based Host
> Resources MIB module (RFC2790) which models processes and
> expects all of them to
> have certain common attributes - I have used this on Linux
> but have not seen it
> on Windows.
>
> On the other hand, most operating system vendors do have
> large quantities of
> proprietary MIB modules that do model the software
> architecture of their
> particular operating system so my bias is towards, if
> Microsoft want to model
> this, let them do it themselves:-)
>
> Tom Petch
>
> ----- Original Message -----
> From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
> To: <syslog@ietf.org>
> Sent: Tuesday, January 16, 2007 12:30 PM
> Subject: 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
>
>
> _______________________________________________
> 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