[collectd] SNMP Sub-OID Question

[Florian Forster]

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

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

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

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

Regards,
-octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20091128/69b647bf/attachment.pgp