[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus
Hi Rohit,
Thanks for the review. All the points are well noted.
I have got these fixes in the next version.
Cheers
Glenn
Rohit M (rrohit) wrote:
> Hi,
>
> I tend to agree that MIB should support
> multiple syslog sender or receivers on the same server/host.
>
> If the device just has one; then they can only instantiate one entry
> for the same.
>
> I have few other comments related to the MIB:
>
> syslogDefaultSeverity OBJECT-TYPE
> SYNTAX SyslogSeverity
> MAX-ACCESS read-write
> STATUS current
> DESCRIPTION
> "The default syslog severity will be used to
> compute the syslog priority that will be added
> to syslog messages when the message needs to be
> relayed and does not have priority specified.
>
> The value of this object SHOULD remain unchanged
> across reboots of the managed entity.
>
> [ROHIT] I am getting confused with the usage of word priority and
> severity here. May be I am missing something here; in that
> case, please add any REF if applicable.
>
>
>
> [ROHIT] I see the usage of "The local time" at so many places; I guess
> this should be
> "The value of sysUpTime".
>
> syslogEntityStatusChanged NOTIFICATION-TYPE
> OBJECTS {
> syslogEntityControlStatus,
> syslogEntityControlDescr,
> syslogEntityControlBindAddrType,
> syslogEntityControlBindAddr,
> syslogEntityControlTransportDomain,
> syslogEntityControlService,
> syslogEntityControlConfFileName
> }
>
> [ROHIT] IMHO, The notification definition should clarify that
> syslogEntityControlStatus
> is the new status value after change.
>
> Thanks
> Rohit
>
>
> -----Original Message-----
> From: Glenn M. Keeni [mailto:glenn@cysols.com]
> Sent: Friday, January 12, 2007 4:17 PM
> To: syslog@ietf.org
> Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus
>
> Anton Okmianski (aokmians) wrote:
>>> 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.
>> Agree.
>> However, I am not clear it must be covered by a single SNMP agent with
>
>> single MIB. It should probably be possible to manage multiple syslog
>> instance with single SNMP agent per host, but we are not excluding
>> each instance having it own SNMP agent on different port, right?
>>
>> I don't know if this violates anything in SNMP, but it may be easier
>> implementation-wise no to have to integrate my syslog component with
>> system SNMP agent.
>
> With the present MIB it is possible to have a. A single snmp agent per
> host manage multiple Syslog entities b. multiple snmp agents per host
> manage each managing a separate
> syslog entity, [if someone wants to do that] and there will no
> problem of interoperability between systems of type (a) and
> configuration (b).
>
> Glenn
>
>
>>
>>
>>> -----Original Message-----
>>> From: David Harrington [mailto:ietfdbh@comcast.net]
>>> Sent: Friday, January 12, 2007 10:31 AM
>>> 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?
>> Absolutely. Especially, sender.
>>
>>> 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.
>> Agree.
>>
>> However, I am not clear it must be covered by a single SNMP agent with
>
>> single MIB. It should probably be possible to manage multiple syslog
>> instance with single SNMP agent per host, but we are not excluding
>> each instance having it own SNMP agent on different port, right?
>>
>> I don't know if this violates anything in SNMP, but it may be easier
>> implementation-wise no to have to integrate my syslog component with
>> system SNMP agent.
>>
>> Thanks,
>> Anton.
>>
>>> 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