tom.petch wrote:
> Chris
>
> I am fine with the layer diagram given below but I am less clear about the
> consequences for the MIB.
>
> Currently, there is a table with an arbitrary integer index which contains
> application name, application control file name, receive address and
> statistics.
> I have never been too clear on what an entry in this table represents, as I
> have
> queried before.
There are two tables. I presume that you are referring to
syslogControlTable. The DESCRIPTION for syslogControlEntry
should answer your question
DESCRIPTION
"The configuration parameters pertaining to a syslog
application.
"
Let me know which part is unclear, I will try to clarify.
>
> The details below suggest that messages sent and received at the transport
> level
> become scalars (digression: need to be clear what a message is when this is
> TLS
> over TCP) with a table with an entry per relay destination (per application?).
>
> Doubt one: we currently do not have any destination information in the table,
> only a receive address to bind to; will this be added?
The answer is yes.
You may refer to my earlier mail -
(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.
>
> Doubt two; should we be - we should be! - providing a similar table for
> originators since they too can send to multiple destinations.
In the table for relay destinations- we have a destination-priority
pair. Application A1 will relay Priority P1 to destination D1 etc.
I am not clear about what exactly you want in a similar table for
originators. Could you explain that?
>
> Doubt three; should we have a table for different origins, else balancing
> counters will be difficult? If a collector receives 30 messages when the
> various relay and originator not relayed counters add up to 25, how do you
> know
> which stream has gone missing? or do you parse the message and expect there
> to
> be helpful data in the SDE?
If we ignore the errors we basically have three counters
syslogOperationsMsgsReceived,
syslogOperationsMsgsTransmitted, ( this include relayed messages)
syslogOperationsMsgsRelayed
I am not clear what is meant by "various relay and originator not
relayed counters".
If it means syslogOperationsMsgsTransmitted, there is no problem at all
with
syslogOperationsMsgsReceived = 30 and,
syslogOperationsMsgsTransmitted = 25
If it does not mean syslogOperationsMsgsTransmitted then please tell me
what it means.
Honestly, I do not see anyway in which the three counters can be
balanced. [Why do we need to balance these ?]
There will be an additional set of destination-wise counters for relayed
messages
syslogOperationsMsgsTransmittedToRelay
[ messages transmitted to a relay]
As far as I can tell there is only one generic equation
SUM (syslogOperationsMsgTransmittedToRelay) =
syslogOperationsMsgsRelayed
There is just one more generic relationship
syslogOperationsMsgsTransmitted >= syslogOperationsMsgsRelayed
> This is all getting complicated and I am unclear about the benefits of going
> down this road.
I do not believe that it is complicated. It is as simple as that -
there are just two operations "receive" and "send". And "send" has two
sub-types- relay, non-relay. It cannot be complicated :-)
>
> Tom Petch
Glenn
>
> ----- Original Message -----
> From: "Chris Lonvick" <[EMAIL PROTECTED]>
> To: "tom.petch" <[EMAIL PROTECTED]>
> Cc: "David Harrington" <[EMAIL PROTECTED]>; "'Sam Hartman'"
> <[EMAIL PROTECTED]>; "syslog" <[EMAIL PROTECTED]>
> Sent: Tuesday, May 22, 2007 7:22 PM
> Subject: Layer diagram & mib counters - was:Re: [Syslog] Comments on
> draft-ietf-syslog-protocol-20
>
>
>> 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
> [email protected]
> https://www1.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/syslog
