What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags

View all Tags

Custom SNMP Table with multiple indexes



Hello, Friends!

I noticed that PRTG doesn`t ready to situation when TABLE_Index column not contains unique values. It`s commonly happens in F5 LTM MIBs, for example in ltmPoolMbrStatusTable where all possible index columns doesn`t contain a unique values(cause normal Pool contains more than one Member in it).

As result PRTG just create duplicated Sensors instead of combine it based on similar row entries in Index columns

Is it possible to workaround it? Maybe it`s in a roadmap..

Unfortunately PRTG is totally poor in terms of F5 supporting. Why is it happened? PRTG even can`t to check basic snmp parameters for System Information tables for F5 appliances.

Thanx in advance

f5 identification-column index ltm prtg17 snmp-custom-table

Created on Apr 5, 2018 2:57:23 PM

Last change on Apr 17, 2018 6:07:17 AM by  Luciano Lingnau [Paessler]

1 Reply

Accepted Answer



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
        "Columns in the ltmPoolMember Table"
    INDEX {

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.


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 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: [] [] []

Best Regards,
Luciano Lingnau [Paessler Support]

Created on Apr 16, 2018 1:52:15 PM by  Luciano Lingnau [Paessler]

Last change on Apr 17, 2018 6:07:49 AM by  Luciano Lingnau [Paessler]

Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.