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