Hi All,
What I'm seeing is that our effort to add granularity for mib accounting
has made the document less clear. My apologies for that.
Does the following make more sense:
+---------------------+ +---------------------+
| content | | content |
|---------------------| |---------------------|
| syslog application | | syslog application | (originator,
| | | | collector, relay)
|---------------------| |---------------------|
| syslog transport | | syslog transport | (transport sender,
| | | | (transport receiver)
+---------------------+ +---------------------+
^ ^
| |
--------------------------
In this, the "content" will be developed by some application and handed to
syslogd (using *nix as an example device). syslogd will format the
message adding in the PRI, timestamp, etc., and will hand it to the
transport.
- For udp transport, the "transport sender" will encapsulte it within udp
and put it onto the wire.
- For the case of tls, the "transport sender" will establish a new, or use
an existing session with the "transport receiver".
For discrepancies (if any) between the IP address of the "originator" and
the "transport sender", the originator can use the [origin ip=...] SDE
(Section 7.2).
If this makes sense, then the mib counters can be:
- the number of messages sent and received by the "syslog application"
(syslogd)
- the number of messages sent and received by the "transport sender" and
"transport receiver".
The tricky part here is that the counters of the "transport sender" and
"transport receiver" are not going to be useful to counting messages that
are relayed. Only the counters of the "syslog application" are going to
be useful for that. To deal with that, I'll propose that that a table be
set up to associate the messages sent to each relay destination.
As an example from syslog.conf:
kern.crit @loghost
kern.info @loghost2.example.com
The relay destinations will have to be enumerated.
get "numOfRelayDests" would return "2"
get "relayDest(1)" would return "loghost"
get "relayDest(2)" would return "loghost2.example.com"
What is to be sent to those destinations would have to be quantified.
get "priOfRelayDest(1)" would return "2" (from kern.crit as the filter)
get "priOfRelayDest(2)" would return "6" (or "kern.info")
When the device receives a "<2>..." syslog message (PRI=2, kern.crit), it
will relay it to the two relay destinations.
Then
syslogOperationsMsgsReceived will be incremented by 1
syslogOperationsMsgsRelayed(0) will be incremented by 2
(the message went to two destinations)
syslogOperationsMsgsRelayed(1) will be incremented by 1
(it sent one copy to "relayDest(1)" which is loghost)
syslogOperationsMsgsRelayed(2) will be incremented by 1
(it sent another to ""relayDest(2)")
syslogOperationsMsgsTransmitted will be incremented by 2
(it transmitted both)
Also, on loghost, syslogOperationsMsgsReceived will be incremented by 1
and on loghost2.example.com syslogOperationsMsgsReceived will also be
incremented by 1.
This gives an administrator a way to balance out messages sent and
received.
- If our device shows 3 messages relayed to loghost, and loghost shows 3
messages received, then we have a balance, even if MsgsTransmitted from
our device is 482.
- If our device shows 3 messages relayed but loghost shows 2 messages
received, then we might have a discard on our device, or the message may
have been dropped by some intermediary.
- If our device shows 3 messages relayed but loghost shows 46 receieved
then we likely have another device sending messages to loghost.
To be clear on this, the counters for "transport sender" and "transport
receiver" will NOT be associated with a peer - they will just count the
number of messages sent and received. It will be up to the counters
associated with the "syslog application" to associate the messages with
peers so that the count of messages relayed will have some meaning.
Does this make sense? As David said, we're not doing our job unless we're
clear on the concepts, terminology and have a way to manage the devices.
Thanks,
Chris
On Fri, 18 May 2007, tom.petch wrote:
Not sure where this draft is heading, but as a WG member, comments <inline>
Tom Petch
---remainder elided for brevity---
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
