Re: Layer diagram mib counters - was:Re: [Syslog] Comments on draft-ietf-syslog-protocol-20
David I see the problem slightly differently. I think that there is adequate expertise on this list to turn a data model into suitable SMI and that what is lacking is the data model for syslog; from the MIB doctor reports I have read, that is one thing they rarely bring to the party. Rather they focus on the SMI and on asking pointed questions about the meaning and representation of objects in the model. We have progessed, producing a better defined syslog stack, what I think is needed now is to take that a stage further - no SNMP expertise needed - in defining what management data users would like to know or what implementers are prepared to offer. The existing MIB module is obviously an example of this; my problem with it is in not understanding it as well as I think I need to in order to use it. And of course the lack of others saying 'it's obvious what it means' (or not) or whatever so that a consensus may form. Tom Petch - Original Message - From: David Harrington [EMAIL PROTECTED] To: 'tom.petch' [EMAIL PROTECTED]; 'Chris Lonvick' [EMAIL PROTECTED] Cc: 'Sam Hartman' [EMAIL PROTECTED]; 'syslog' [EMAIL PROTECTED] Sent: Friday, June 01, 2007 8:46 PM Subject: RE: Layer diagram mib counters - was:Re: [Syslog] Comments on draft-ietf-syslog-protocol-20 Hi, [speaking as co-chair] I would like to recommend that the WG ask the OPS ADs for a MIB Doctor to work as a Technical Advisor to the WG. I think a MIB Advisor can help guide the WG about designing the MIB. Obviously I am a MIB Doctor, but it makes it difficult to keep the functions separate when I work as contributor, as co-chair and as MIB Advisor. I would like to have an independent MIB Advisor providing guidance on the MIB design. David Harrington co-chair, syslog wg -Original Message- From: tom.petch [mailto:[EMAIL PROTECTED] Sent: Friday, June 01, 2007 6:19 AM To: Chris Lonvick Cc: David Harrington; 'Sam Hartman'; syslog Subject: Re: Layer diagram mib counters - was:Re: [Syslog] Comments on draft-ietf-syslog-protocol-20 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
Re: Layer diagram mib counters - was:Re: [Syslog] Comments on draft-ietf-syslog-protocol-20
Hi Tom, I appreciate the thoughts. I see consensus in the WG on the layering diagram. I've asked Rainer to update -protocol with that diagram and definitions. Let's get that out the door at this time. I see that we are unclear on what we should be counting and the benefit of counting it. Glenn has separated the mib into textual conventions and the counters. The TC is now here: http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-00.txt Would everyone please review this? I would like for us to establish this as our base and then we can have discussions on counting messages. Thanks, Chris On Fri, 1 Jun 2007, 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. 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
Re: Layer diagram mib counters - was:Re: [Syslog] Comments on draft-ietf-syslog-protocol-20
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
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
