Florian Forster wrote: > Hi David, > > On Tue, Nov 24, 2009 at 08:05:31AM -0700, David Mitchell wrote: >>> The Cisco AP's I have use a fairly long instance in this table which >>> includes the MAC address. > > not sure I understand this correctly: Is the MAC address part of the > OID? > > Anyways, collectd is using only the last number of the OID because > that's how it's supposed to be. Unfortunately, many manufacturers don't > understand SNMP (or let some intern write the MIB or something) and use > multiple parts there. Using every part that's not specified as the > "Values" option would probably simplify the case in which the instance > is to be determined from the OID. > >>> Collectd only seems to use the last single OID from the instance in >>> the name of the value. > > If no separate instance-OID is specified, yes. > >>> In my case, this ends up being the last octet of the clients MAC >>> address. > > Oh, good $deity! Cisco is doing this, too? One does not encode > information in the OID! > >>> I quick perusal of the code seems to show that the single-value >>> suboid seems fairly hard-coded in. Is there any workaround for this? >>> Have others hit this issue? A search in the bug tracker didn't turn >>> anything up. > > Yeah, it's hard coded in. I could picture changing this like this: Image > the user specifies the OID ".1.2.3.4". The GETNEXT request returns the > OID ".1.2.3.4.5.6.127". Instead of using the last part of the OID, we > use the difference: (5, 6, 127). The next problem is how to convert this > to a string. For MAC addresses you'd want the "%02x" format for each > value, but I've seen IPv4 addresses being encoded in the OID, too. > > Letting the user specify a format string is a bit tricky because the > number of values cannot be determined a priori. So maybe something like > this would be in order: > InstanceOIDFormat "%02x" > InstanceOIDSeparator ":" > This would format each value of the OID using "%02x" and concatenate > them together using ":" as the separator. So the above (5, 6, 127) would > become "05:06:7f".
That might be a workable config. It should be possible to make it work either with or without the Instance mapping. To be honest, I'm less particular about the exact formatting than I am in just having it be unique per instance. >> I've been looking into this more. I found a similar issue when using >> the Instance option. Our AP's do include an IP address for each client >> which I can use to map the Instance. But it's returned in a raw format >> of four octets. Collectd prints this to the value name as though it >> was a string, resulting in unprintable characters in the filename. > > Uh, yeah, that binary data in SNMP is a bit tricky to handle. > >> I think both of these issues can be rectified by calling back into >> net-snmp to let it do the formatting needed for the values. > > Yeah, in case of the instance option this would probably be a good > thing. > >> I've begun trying to patch up a version which does this. Is this a >> patch which is likely to be accepted? > > Yes, definitely :) Sounds good. I'll try to see what I can come up with. > >> I imagine that in some instances it will cause changes in the >> resulting value name. Is such a patch likely to be accepted? Do I need >> to perhaps include some non-default configuration option to active it? > > Yeah, backwards compatibility should remain, so introducing a config > option for this is probably a very good idea. OK. I'll need to dig into how the config is parsed. > > Sorry if I sound a bit annoyed - it's not you, it's manufacturers who > didn't understand SNMP.. And especially Cisco should know better.. Well, since RFC 1157 does exactly that in section 4.1.3.1 'Example of Table Traversal', their confusion is perhaps understandable ;-) -David Mitchell > > Regards, > -octo _______________________________________________ collectd mailing list [email protected] http://mailman.verplant.org/listinfo/collectd
