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. 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? Doubt two; should we be - we should be! - providing a similar table for originators since they too can send to multiple destinations. 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? This is all getting complicated and I am unclear about the benefits of going down this road. Tom Petch ----- 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
