Chris,
I think that there are two separate issues that we are talking of here;
- the layered model for syslog
- the objects which we monitor
I will send my comments on the layered model in a separate mail.
As far as the Objects [MIB counters] are concerned I am reading 2
points
(1) monitoring the relay activity. We want to have
- a list of the relays
- for every relay
o the priority(ies) of the message that will be relayed to
this relay
o the number of messages transmitted to this relay
(messagesTransmittedToRelay)
- etc.
(2) we do not need to monitor message received at the message-source
level of granularity.
The points are well taken. I could certainly use the features
built using (1). Regarding (2)- monitoring messages at the
message-source level of granularity is not difficult to implement.
But there may be practical problems as there may be there may be a
very large number of message sources - tracking the counters for
each of the sources will be expensive etc. So I will agree with (2).
I will add the new table definitions for (1) in the next version of
the draft.
Glenn
> 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
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
