Hello Tommy,
thank you for your KB-Post.
We had contacted you by e-mail, but I want to openly acknowledge the current limitations regarding how multi-index tables are handled in case anyone runs into similar issues. I can confirm that you're right. Based on the MIB's implementation for the ltmPoolMemberTable (part of F5-BIGIP-LOCAL-MIB) for example, there are three indexes for entries in this table:
ltmPoolMemberEntry OBJECT-TYPE
SYNTAX LtmPoolMemberEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Columns in the ltmPoolMember Table"
INDEX {
ltmPoolMemberPoolName,
ltmPoolMemberNodeName,
ltmPoolMemberPort
}
Unfortunately, I can also confirm that at the present time PRTG does not support this. In PRTG's implementation for the SNMP Custom Table there can only be one index (the identification column as we call it in PRTG) and it must be from the same table. These are the two constrains that the sensor currently follow. I can also tell you that there are no concrete plans to change this anytime soon because it is not a trivial change but also because fixing it will also make the sensor more complex to setup (and require more input fields).
In many cases you can get away with it if any entry of the table is unique.
Update:
Upon further investigation, we've realized that the data made available in the ltmPoolMemberTable is encoded in a very smart fashion, were instead of arbitrary OID's F5 used the ltmPoolMemberPoolName, ltmPoolMemberNodeName and ltmPoolMemberPort (OID-encoded).
This means that it should be safe to use table_index as "Identification Column" for monitoring the 1.3.6.1.4.1.3375.2.2.5.3.2 table and this should work just fine, since the indexes won't change on it's own. However, this makes the [rowidentifier] name-variable unusable and as such, different variables have to be used in the sensor's name. For example, the following should result in a reasonable sensor name:
Pool member: [1.3.6.1.4.1.3375.2.2.5.3.2.1.1] [1.3.6.1.4.1.3375.2.2.5.3.2.1.19] [1.3.6.1.4.1.3375.2.2.5.3.2.1.4]
Best Regards,
Luciano Lingnau [Paessler Support]
Add comment