We need the ability to be able to properly handle tables, so if I have a table that has more than two columns,
as is often the case for things being monitored that have more than 1 metric to measure, then it can be handled properly by the UnDP.
Currently, I am limited to collecting data for one specific column only. If the OID ends in 4.3.2.1.1 for the single value, there are also OID's ending
in 4.3.2.1.2, .1.3, .1.4 ... .1.27..
<<EDITED FOR CLARITY>>
I want to be able to pull that entire table. Secondly, I want to be able to specify the key so all the data comes in under the right label.
The label table might be 4.3.2.1, and it has two columns, index and label. Every other table has two columns, index and <data>.
I need to be able to pull the entire set as one big table, correlating all the value tables with the labels based on the index match. This in the SQL world would amount to something like a view where I'd pull columns 1 and 2 from the label table and pull column 2 from all subsequent tables, matching all the data values against the index, so it would something like this:
Index,Name,Column2ValueForIndex=$Indexfrom4.3.2.2,Column2ValueForIndex=$IndexFrom4.3.2.3, ... and so on.
Not sure how much clarity that brings, but hopefully we can narrow down on it
<</EDIT>>
This is a fairly common SNMP construct for Cisco, Juniper, and various telephony vendors.
I'd love to see if there's traction for this or not, it's been a significant source of pain to not be able to handle this properly for a long time (4-5 years).
I'm very convinced it would be of huge value to anyone with 100 or more devices.
Peter