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 | - | 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
