PRTG SNMP Table sensor

Hello Søren,
thank you for your KB-Post.

What OID's did you use? Please beware that you won't be able to see the Table's OID in our MIB Importer. For instance, when importing the IF-MIB (the MIB from the example in the tutorial), the OID's visible in the tester will be for instance:

• 1.3.6.1.2.1.2.2.1.8 Please beware that this isn't the Table's OID. Since the MIB Importer doesn't fully support tables (since oidlib sensors never deploy tables) it is somewhat tricky to find the correct OID. In the case above, the correct OID for the table is 1.3.6.1.2.1.2.2. The actual MIB looks like this:

• 1.3.6.1.2.1.2.2 (ifTable)
  • 1.3.6.1.2.1.2.2.1 (ifEntry)
    • 1.3.6.1.2.1.2.2.1.1 (ifIndex)
    • 1.3.6.1.2.1.2.2.1.2 (ifDescr)
    • 1.3.6.1.2.1.2.2.1.8 (ifOperStatus)

Most common MIB implementations will follow this pattern. You have to "leave out" everything (inclusive) the latest .1. in the OID to get the OID of the Table. For instance, since you mentioned Compellent SANs:

To monitor the scServerStatus from the scServerTable: The MIB Importer will display the following OID for the scServerStatus: 1.3.6.1.4.1.16139.2.27.1.3 - But this is the OID of the column. To figure the OID of the table, leave out everything after the last .1 (including the .1). Which leaves you with:

• 1.3.6.1.4.1.16139.2.27 (scServerTable)

Keep in mind that the best way to generate the required lookups is to deploy the library sensor first, it will automatically create the appropriate lookups, which you can use with the Table Sensor later on. Remember to adjust the lookup to actually modify the sensor's status based on the response. More details are available here:

• Value interpretation (aka Lookups)

And lastly. If you continue getting errors trying to deploy the Table Sensor, use the OID of the table in our SNMP Tester and confirm whenever you get any reply when you do a walk of the OID.

Best Regards,
Luciano Lingnau [Paessler Support]

Thanks for the answer.

I think i got the OID correct, I tried .1.3.6.1.4.1.37447.1.2 as you can see below.

• .1.3.6.1.4.1.37447.1.2 - VolTable
  • .1.3.6.1.4.1.37447.1.2.1 - VolEntry
    • .1.3.6.1.4.1.37447.1.2.1.3 - VolName
    • and so on.

When i try to do a walk on the table .1.3.6.1.4.1.37447.1.2 nothin happens it just writes.

Paessler SNMP Tester 5.2.3 Computername: ServerName Interface: (xxx.xxx.xxx.xxx)
16-02-2017 14:42:24 (3 ms) : Device: xxx.xxx.xxx.xxx
16-02-2017 14:42:24 (5 ms) : SNMP V2c
16-02-2017 14:42:24 (6 ms) : Walk .1.3.6.1.4.1.37447.1

Should I get some kind of response in the SNMP Tester when i walk the Table OID?

Yes, the output would look similar to the following:

----------------------- New Test -----------------------
Paessler SNMP Tester 5.2.3 Computername: ServerName Interface: XXX.XXX.XXX.XXX
16/02/2017 15:18:44 (1 ms) : Device: XXX.XXX.XXX.XXX
16/02/2017 15:18:44 (2 ms) : SNMP V2c
16/02/2017 15:18:44 (3 ms) : Walk 1.3.6.1.2.1.25.3.3
16/02/2017 15:18:44 (4 ms) : 1.3.6.1.2.1.25.3.3.1.1.14 = "0.0" [ASN_OBJECT_ID]
16/02/2017 15:18:44 (5 ms) : 1.3.6.1.2.1.25.3.3.1.1.15 = "0.0" [ASN_OBJECT_ID]
16/02/2017 15:18:44 (6 ms) : 1.3.6.1.2.1.25.3.3.1.1.16 = "0.0" [ASN_OBJECT_ID]
16/02/2017 15:18:44 (7 ms) : 1.3.6.1.2.1.25.3.3.1.1.17 = "0.0" [ASN_OBJECT_ID]
16/02/2017 15:18:44 (8 ms) : 1.3.6.1.2.1.25.3.3.1.1.18 = "0.0" [ASN_OBJECT_ID]
16/02/2017 15:18:44 (9 ms) : 1.3.6.1.2.1.25.3.3.1.1.19 = "0.0" [ASN_OBJECT_ID]
16/02/2017 15:18:44 (10 ms) : 1.3.6.1.2.1.25.3.3.1.1.20 = "0.0" [ASN_OBJECT_ID]
16/02/2017 15:18:44 (12 ms) : 1.3.6.1.2.1.25.3.3.1.1.21 = "0.0" [ASN_OBJECT_ID]
16/02/2017 15:18:44 (13 ms) : 1.3.6.1.2.1.25.3.3.1.2.14 = "24" [ASN_INTEGER]
16/02/2017 15:18:44 (15 ms) : 1.3.6.1.2.1.25.3.3.1.2.15 = "7" [ASN_INTEGER]
16/02/2017 15:18:44 (17 ms) : 1.3.6.1.2.1.25.3.3.1.2.16 = "18" [ASN_INTEGER]
16/02/2017 15:18:44 (19 ms) : 1.3.6.1.2.1.25.3.3.1.2.17 = "8" [ASN_INTEGER]
16/02/2017 15:18:44 (21 ms) : 1.3.6.1.2.1.25.3.3.1.2.18 = "10" [ASN_INTEGER]
16/02/2017 15:18:44 (22 ms) : 1.3.6.1.2.1.25.3.3.1.2.19 = "39" [ASN_INTEGER]
16/02/2017 15:18:44 (24 ms) : 1.3.6.1.2.1.25.3.3.1.2.20 = "22" [ASN_INTEGER]
16/02/2017 15:18:44 (25 ms) : 1.3.6.1.2.1.25.3.3.1.2.21 = "18" [ASN_INTEGER]

This is the output of a walk against the hrProcessorTable(1.3.6.1.2.1.25.3.3 ) from the HOST-RESOURCES-MIB. Essentially the result that you've received either means that the device doesn't implement this table or that you have a general SNMP problem. Try walking 1.3.6, do you get a valid reply?

Ok, when I do a walk of .1.3.6 i can see that .1.3.6.1.4.1.37447.1.2 doesnt show, it jumps directly to the table data.

16-02-2017 15:22:06 (1659 ms) : 1.3.6.1.4.1.2021.13.14.2.1.3.1 = "/nimble/lib/nimble_snmp.so" [ASN_OCTET_STR]
16-02-2017 15:22:06 (1666 ms) : 1.3.6.1.4.1.2021.13.14.2.1.4.1 = "" [ASN_OCTET_STR]
16-02-2017 15:22:06 (1675 ms) : 1.3.6.1.4.1.2021.13.14.2.1.5.1 = "1" [ASN_INTEGER]
16-02-2017 15:22:06 (1683 ms) : 1.3.6.1.4.1.37447.1.2.1.2.0 = "0" [ASN_UNSIGNED]
16-02-2017 15:22:06 (1693 ms) : 1.3.6.1.4.1.37447.1.2.1.2.1 = "1" [ASN_UNSIGNED]
16-02-2017 15:22:06 (1704 ms) : 1.3.6.1.4.1.37447.1.2.1.2.2 = "2" [ASN_UNSIGNED]
16-02-2017 15:22:06 (1712 ms) : 1.3.6.1.4.1.37447.1.2.1.2.3 = "3" [ASN_UNSIGNED]

Is this a problem with the Nimble SNMP implementation or something else?

Hello Søren,

Well, this is only a partial walk but the following looks like the beginning of the VolTable at 1.3.6.1.4.1.37447.1.2:

• 16-02-2017 15:22:06 (1683 ms) : 1.3.6.1.4.1.37447.1.2.1.2.0 = "0" [ASN_UNSIGNED]
• 16-02-2017 15:22:06 (1693 ms) : 1.3.6.1.4.1.37447.1.2.1.2.1 = "1" [ASN_UNSIGNED]
• 16-02-2017 15:22:06 (1704 ms) : 1.3.6.1.4.1.37447.1.2.1.2.2 = "2" [ASN_UNSIGNED]
• 16-02-2017 15:22:06 (1712 ms) : 1.3.6.1.4.1.37447.1.2.1.2.3 = "3" [ASN_UNSIGNED]

I've highlighted the Table in the OID in bold and the Index in the OID in italics. It looks like it's all there. Please perform the following:

1. In PRTG, deploy an SNMP Custom sensor on 1.3.6.1.4.1.37447.1.2.1.2.1 - Do you get a Value of 1?
2. Troubleshoot the sensor until it comes up (essentially, the SNMP Credentials in PRTG)
3. Try deploying the Custom Table sensor on 1.3.6.1.4.1.37447.1.2 again.

Best Regards,
Luciano Lingnau [Paessler Support]

Now it works :D

Do you know why it is working now, because i have already tried 1.3.6.1.4.1.37447.1.2 alot of times? Is it the custom sensor on 1.3.6.1.4.1.37447.1.2.1.2.1 the cause?

Dooh, it was the leading . that was the problem...

Thanks for your help, I have learned alot :)