Re: [Syslog] The SIMPLE SyslogMIB
Rainer, There is no standard for configuration and operation for syslog. Do there is not much of configuration supported by the MIB. The earlier versions of the MIB had some configuration which was based on the unix-syslog. This has been dropped in the later versions because of its complexity and non-universality. However the configuration that you are suggesting is there - the listening address/port for a syslog receiver, the transport type, and the configuration file. This is probably the common configuration for syslog entities that we can talk of in the absence of any document. Glenn thanks for the description in plain words. At least for me, this is very useful. If you think about things that are common to a sufficiently large number of syslog applications, you can not standardize on many more properties. What syslog applications do with the messages is very different, as are the filtering capabilities. One thing I could think of is a MIB/special table (whatever in SNMP terms) *just* for *simple syslog *senders**. It is common for devices like routers, switches and firewalls to provide a limited syslog reporting capability. What needs to be configured here is TARGET :== [the receiver of the syslog message] - IP address or hostname - port on traget system - transport (UDP, plain tcp [not standardized], -tls, 3195, ...) - facility to be used for messages - eventually severity *level* as a filter (e.g. send only emergency message or send all except debug) - opionaly pointer to local config file Some devices support multiple TARGETs, some only a single one. I might have forgotten some properties, but the above description should be usable with a very large number of devices. It may also be that you can model this with the existing MIB ;) I hope my comment is useful. Rainer -Original Message- From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] Sent: Friday, January 12, 2007 9: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
[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
Re: [Syslog] The SIMPLE SyslogMIB
On Fri, Jan 12, 2007 at 11:19:50AM +0100, Rainer Gerhards wrote:
Glenn,
thanks for the description in plain words. At least for me, this is
very useful.
If you think about things that are common to a sufficiently large number
of syslog applications, you can not standardize on many more properties.
What syslog applications do with the messages is very different, as are
the filtering capabilities.
One thing I could think of is a MIB/special table (whatever in SNMP
terms) *just* for *simple syslog *senders**. It is common for devices
like routers, switches and firewalls to provide a limited syslog
reporting capability. What needs to be configured here is
[...]
Some devices support multiple TARGETs, some only a single one.
The question really is who is interested to configure syslog
originators typically found on network elements via SNMP. If there are
people interested in this, they better speak up now and tell us what
information they need to get the syslogs on their products configured.
If nobody speaks up with concrete input and implementation plans, we
should perhaps drop syslog configuration via SNMP and just focus on
monitoring (and leave syslog configuration to future MIB work or leave
this to NETCONF once they have figured out to write data models).
I personally would vote for a very basic syslog monitoring MIB which
allows me to track syslog activities and to identify discrepancies
between originated syslog messages and actually received syslog
messages. Ideally, an implementation of such a MIB would hook into an
SNMP master agent via AgentX (of a similar mechanism) so I can
transparently access the MIB by talking to the main SNMP agent on the
device.
/js
--
Juergen Schoenwaelder{International|Jacobs} University Bremen
http://www.eecs.iu-bremen.de/ P.O. Box 750 561, 28725 Bremen, Germany
___
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
