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.
> 
> Tom Petch

Glenn
> 
> ----- Original Message -----
> From: "David Harrington" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> 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
>> [EMAIL PROTECTED]
>> [EMAIL PROTECTED]
>> [EMAIL PROTECTED]
>> co-chair, Syslog WG
>>
>>
>>> -----Original Message-----
>>> From: Glenn M. Keeni [mailto:[EMAIL PROTECTED]
>>> Sent: Friday, January 12, 2007 3:30 AM
>>> To: [EMAIL PROTECTED]
>>> 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

Reply via email to