[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus
Hi Tom,
> -----Original Message-----
> From: tom.petch [mailto:cfinss@dial.pipex.com]
> Sent: Tuesday, January 16, 2007 2:40 PM
> 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.
With all due respect, I disagree here. I do (and have done) a lot of
multi-platform work. Even CP/M or DOS 1.0 did qualify to the core
definition of an operting system. I think an OS is not defined by "it
must some Unix clone".
More seriously: as far as I know (a bit outdated knowledge) IBM MVS and
DOS/VSE, Unisys OS2200 and many others do not provide a syslog stack.
Does that disqualify them as operating systems? I doubt a number of
real-time OSs do not provide one. Again, not an operating system?
NetWare does not provide one, but you can rightly argue if it is a
general purpose OS.
Even if you require an OS to address the application logging need, you
will find it addressed in Windows. There is the event log system. It is
different from syslog. Some find it superior, many not ;) Anyhow, it is
there and there is a standard API.
I think we should not try to get cross-platform politics into your
discussion. You may like Windows or you may dislike it. It satisfies all
criteria to be called a full-fledged operating system. Its deployment
base would also IMHO force us to think about it EVEN if it were none. We
can not ignore real world - not even if we do not like it ;)
> You
> point out
> that it does not have an SNMP engine or a syslog engine. Other
> operating
> systems do,
just out of curiosity: which non-*nix based OSs do provide a syslog
stack at the API level? I am not just argueing, this is a honest
question. I've worked mainly on *nix and Windows the past years, so I
might have become disconnected here...
> 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).
I work well with three different ones on a single machine - but that's
quite off-topic, of course ;)
>
> 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.
... which is the same with SNMP. Who says there won't be a thrid-party
engine some day that fourth parties hook in? Maybe I write one? Maybe
open source? Maybe someone else does. Does that change the picture?
Maybe...
And what about e.g. SDSc syslog and rsyslog who have multiple syslog
receiver processes for good reason? Is *nix no longer an OS because it
does not natively support RFC 3195? (just kidding ;))
>
> 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:-)
Is it smart to call for proprietary solution if (if!) a standard one
comes at very low cost? Can we bash MS for being non-standard when at
the same time recommending them to do that ;)
Rainer
>
> 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