[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Fwd: RE: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus]
Hi,
The attached mail from Rohit M (rrohit) <rrohit@cisco.com>
did not make it to the mailing-list. There was a typo
in the address.
Glenn
-------- Original Message --------
Subject: RE: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus
Date: Mon, 15 Jan 2007 11:39:42 +0530
From: Rohit M (rrohit) <rrohit@cisco.com>
To: <sysllog@ietf.org>, <glenn@cysols.com>
Hi,
I tend to agree that MIB should support
multiple syslog sender or receivers on the same server/host.
If the device just has one; then they can only instantiate one entry
for the same.
I have few other comments related to the MIB:
syslogDefaultSeverity OBJECT-TYPE
SYNTAX SyslogSeverity
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The default syslog severity will be used to
compute the syslog priority that will be added
to syslog messages when the message needs to be
relayed and does not have priority specified.
The value of this object SHOULD remain unchanged
across reboots of the managed entity.
[ROHIT] I am getting confused with the usage of word priority and
severity here. May be I am missing something here; in that
case, please add any REF if applicable.
[ROHIT] I see the usage of "The local time" at so many places; I guess
this should be
"The value of sysUpTime".
syslogEntityStatusChanged NOTIFICATION-TYPE
OBJECTS {
syslogEntityControlStatus,
syslogEntityControlDescr,
syslogEntityControlBindAddrType,
syslogEntityControlBindAddr,
syslogEntityControlTransportDomain,
syslogEntityControlService,
syslogEntityControlConfFileName
}
[ROHIT] IMHO, The notification definition should clarify that
syslogEntityControlStatus
is the new status value after change.
Thanks
Rohit
-----Original Message-----
From: Glenn M. Keeni [mailto:glenn@cysols.com]
Sent: Friday, January 12, 2007 4:17 PM
To: syslog@ietf.org
Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus
Anton Okmianski (aokmians) wrote:
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.
Agree.
>
However, I am not clear it must be covered by a single SNMP agent with
single MIB. It should probably be possible to manage multiple syslog
instance with single SNMP agent per host, but we are not excluding
each instance having it own SNMP agent on different port, right?
I don't know if this violates anything in SNMP, but it may be easier
implementation-wise no to have to integrate my syslog component with
system SNMP agent.
With the present MIB it is possible to have a. A single snmp agent per
host manage multiple Syslog entities b. multiple snmp agents per host
manage each managing a separate
syslog entity, [if someone wants to do that] and there will no
problem of interoperability between systems of type (a) and
configuration (b).
Glenn
-----Original Message-----
From: David Harrington [mailto:ietfdbh@comcast.net]
Sent: Friday, January 12, 2007 10:31 AM
To: syslog@ietf.org
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?
Absolutely. Especially, sender.
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.
Agree.
However, I am not clear it must be covered by a single SNMP agent with
single MIB. It should probably be possible to manage multiple syslog
instance with single SNMP agent per host, but we are not excluding
each instance having it own SNMP agent on different port, right?
I don't know if this violates anything in SNMP, but it may be easier
implementation-wise no to have to integrate my syslog component with
system SNMP agent.
Thanks,
Anton.
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
_______________________________________________
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