The indirect-indexes and indirect-references available on several SNMP tables, make hard the configuration of several SNMP Tables where some relevant information exist on other tables indexed by different indices.
On even more complex scenarios like Cisco QoS, where the tables have a very complex hierarchical nature, drastically reduce the change to collect data just because of this limitation.
Here is a simple example:
Let's say I want to collect data from bsnAPIfLoadParametersTable, defined on AIRSPACE-WIRELESS-MIB. This table is indexed by a composed index integrated by the bsnAPDot3MacAddress and bsnAPIfSlotId.
This table doesn't have information about the access point. But, the table bsnAPTable which is indexed by the bsnAPDot3MacAddress, has a field called bsnAPName with the information we need.
Unfortunately, as you can see, both tables have different indexes so we cannot define MibObjs that belongs to the same resource-type with all the information we need. By design, a resource-type is associated with a single SNMP Index.
Consider the following example:
The first group will trigger the collection of all the required string resources from the bsnAPTable table.
On the second group, we specify a new tag called "property", which requires:
a) The instance (should be the same instance or resource type used for the resource of the MibObjs in the group).
b) The name of the source resource type
c) The name of the source alias
d) The pattern to apply on the indices to figure out the index on the source group.
e) An optional name (it defaults to the source-alias if it is not specified).
r) An optional handler class (it defaults to the RegularExpressionHandler which uses the pattern to apply the logic, more on this later).
Let's analyze the pattern:
For the default handler, it means, the current index (in the above example, the index of a row from bsnAPIfLoadParametersTable) starts with the source index to be extracted, followed by the period character and a number (because that's how the MIB defines this composed index). The extracted source index (which is in fact the index of bsnAPTable) is used with the source-type and source-alias to obtain the attribute in question. If it is found, a new string property will be injected into the target resource.
My idea is to update the SnmpCollectionSet.collect() method to process the data from the new tags added.
What about complex indexes like Cisco QoS?
In this case, we can make the index-pattern optional (but required if you're using the default handler), and explicitly define the handler class, for example:
That way, this custom handler can retrieve the data from other resource types defined on the data collection configuration, and figure out the policyName associated with an entry from the cbQosCMStatsTable table.