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
