[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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