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