[Syslog] MIB Issue #1 - one or multiple? Seeking consensus

["David Harrington" <ietfdbh@comcast.net>]

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