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

FeedWhat can I monitor with the SNMP Custom Table sensor?

Votes:

0

PRTG has a so-called SNMP Custom Table sensor. I have a few questions about this SNMP sensor:

  • What can I do with it?
  • What are the differences to the SNMP Custom sensor or the SNMP Custom Advanced sensor?
  • How can I set up this sensor?

custom prtg sensors snmp snmp-custom-table table

Created on Feb 23, 2016 9:54:42 AM by Luciano Lingnau [Paessler]

Last change on Jan 4, 2023 2:28:55 PM by Brandy Greger [Paessler Support]



2 Replies

Accepted Answer

Votes:

7

This article applies as of PRTG 22

Introduction to the SNMP Custom Table sensor

The SNMP Custom Table sensor was specifically designed to monitor structures known as Tables. These are usually implemented by the designer of the MIB (usually the vendor of the monitored device) when there are multiple instances of the same object (for example, memory, disks, interfaces).

For interfaces, for example, the table looks like this (simplified):

IndexNameBytesInBytesOut
1LAN 110002000
2LAN 234007000
3WAN20003200
[....][....][....][....]

To monitor table objects, you can use individual sensors (SNMP Custom sensor or SNMP Custom Advanced sensor), but setting up the sensors for multiple interfaces is very time-consuming.
You can also try to acquire the MIB file and import it for deployment as an SNMP Library sensor, but this will generate a large number of sensors that by themselves are very expressive.

In this case, the SNMP Custom Table sensor is a much better approach. The sensor is able to recognize the table via a meta-scan and displays it in PRTG. This allows you to configure the sensor and to select all desired indexes (interfaces) that you want to monitor. You can monitor up to 10 channels per sensor.

With MIB Importer, you can identify a Table by checking the Kind of the OID that you inspect. The screenshot below illustrates what you will see when importing the IF-MIB. The Lookup at the bottom-right will tell you how to define your lookup file for this OID.

MIB Importer
Click to enlarge.

For a detailed explanation regarding the creation and usage of lookups, see Value interpretation (aka Lookups)

Sensor setup: SNMP dataset example

We will demonstrate the usage with real data from a switch. The data was acquired using SNMP Tester. Scroll down or see What can I monitor with the SNMP Custom Table Sensor? to view the data.

Creating the sensor

1. In PRTG, open the target device, select Add Sensor, look for the SNMP Custom Table sensor, and enter the table's OID. In this case, use 1.3.6.1.2.1.2.2, which is the OID for the ifTable.
Note: Do not enter the leading dot from the OID (this will cause issues).

2. Enter the sensor name. You can enter any text here. Use the default [tablename] and [rowidentifier] placeholders or any other table OID that has the same index as the entries from the current table. For example, in this case, you will create a sensor for the ifTable but you can query the ifName from the ifXTable as well. To do this, add [1.3.6.1.2.1.31.1.1.1.1] to the name. Do not enter an index because it will be automatically appended. Be aware, however, that while the [rowidentifier] can be dynamically updated, any other OID entered here will only be updated once at sensor creation.
Use the following name in this example:

Table: [tablename] / [rowidentifier]/ [1.3.6.1.2.1.31.1.1.1.1]

Sensor settings
Click to enlarge.

3. In the Table Specific\Table section, you can view the current data in the table. You need to select the appropriate indexes for which you want to deploy sensors. You can also review the sensor's data to help you with the setup.

Table view
Click to enlarge.

  • To view translated OID names here, you have to place the MIB file in the \MIB subfolder of the PRTG program directory. Use MIB Importer to check for common syntax errors first. A PRTG core server restart is required after uploading the MIB there.

4. The identification column will be used to keep track of the monitored table row if the indexes within the table change. It will also replace the previously configured [rowidentifier] placeholder in the sensor's name. Use a column that provides static unique entries whenever possible, as this column will be used to track the appropriate row when the table's indexes change. For this example, we will select ifDescr.

Note: Changing or duplicating values in this column can affect the sensor's operation.

5. Now you can start configuring and selecting the sensor channels. Start with the Sensor Channel #1 Name, because you will use this channel (the primary channel) to monitor the interface's status (the so-called State). For the Sensor Channel #1 Column, select ifOperStatus because we look for the state. This requires a lookup that you need to create in advance. To use the lookup, set the Unit to Value lookup and under Sensor Channel #1 Value Lookup, select the desired lookup file, here, prtg.custom.ifoperstatus.

Note: You may set the unit to Count if you wish to create the sensor without using a lookup. If you do so, your result will not match the screenshots of this article.

Channel 1
Click to enlarge.

  • For the second and third channel, measure the numbers of Bytes IN and Bytes OUT for the interface. Because this is a COUNTER datatype, set the Value Type to Delta and configure the Unit as BytesBandwidth. The fields are ifInOctets and ifOutOctets respectively.

Channel 2, 3
Click to enlarge.

  • The last channel in this example will measure the interface's speed, so call the channel Speed. The column is ifSpeed. The Value is the default Gauge. For the Unit, you can either use Count (see below) or create a lookup file for this as well.

Channel 4
Cick to enlarge.

6. Click Continue to create the sensors. One sensor will be created for each row selected for the Table.

This is what the created sensor looks like. Note that the sensor is named according to the entered placeholders or OIDs.

Sensor's overview
Click to enlarge.

When do I use the SNMP Custom Table sensor?

How does the SNMP Custom Table sensor compare to the SNMP Custom sensor, the SNMP Custom Advanced sensor, and the SNMP Custom String sensor?

Advantages

  • The sensor can track unique data in the table when uniquely identified by the Identification Column. This means that the sensor may be able to continue working when a regular SNMP sensor may fail with error No metrics found (PE223) or start displaying inaccurate data.
  • It is fully compatible with device templates and the auto-discovery.
  • It supports dynamic names in templates.
  • The initial setup may cause more effort, but if you intend to deploy it multiple times on the same devices or on multiple devices, it will save time.
  • The Identification Column can be used to keep track of changing SNMP indexes (for this to work, the selected column should be unique).

Downsides and limitations

  • It can only query numeric values, does not work for String values, and cannot perform regex.
  • It can only query data stored in SNMP tables.
  • You need to understand the MIB you want to monitor and know the OIDs for its tables.

More

Created on Feb 23, 2016 2:44:02 PM by Luciano Lingnau [Paessler]

Last change on Jan 4, 2023 2:32:18 PM by Brandy Greger [Paessler Support]



Votes:

0

Complete SNMP WALK used for this example.

----------------------- New Test -----------------------
Paessler SNMP Tester 5.2
01.03.2016 17:10:15 (1 ms) : Device: 10.0.255.5
01.03.2016 17:10:15 (2 ms) : SNMP V2c
01.03.2016 17:10:15 (2 ms) : Walk 1.3.6.1.2.1.2.2
01.03.2016 17:10:15 (11 ms) : 1.3.6.1.2.1.2.2.1.1.1 = "1" [ASN_INTEGER]
01.03.2016 17:10:15 (15 ms) : 1.3.6.1.2.1.2.2.1.1.2 = "2" [ASN_INTEGER]
01.03.2016 17:10:15 (26 ms) : 1.3.6.1.2.1.2.2.1.1.3 = "3" [ASN_INTEGER]
01.03.2016 17:10:15 (31 ms) : 1.3.6.1.2.1.2.2.1.1.4 = "4" [ASN_INTEGER]
01.03.2016 17:10:15 (149 ms) : 1.3.6.1.2.1.2.2.1.2.1 = "1" [ASN_OCTET_STR]
01.03.2016 17:10:15 (155 ms) : 1.3.6.1.2.1.2.2.1.2.2 = "2" [ASN_OCTET_STR]
01.03.2016 17:10:15 (163 ms) : 1.3.6.1.2.1.2.2.1.2.3 = "3" [ASN_OCTET_STR]
01.03.2016 17:10:15 (168 ms) : 1.3.6.1.2.1.2.2.1.2.4 = "4" [ASN_OCTET_STR]
01.03.2016 17:10:15 (342 ms) : 1.3.6.1.2.1.2.2.1.3.1 = "6" [ASN_INTEGER]
01.03.2016 17:10:15 (349 ms) : 1.3.6.1.2.1.2.2.1.3.2 = "6" [ASN_INTEGER]
01.03.2016 17:10:15 (358 ms) : 1.3.6.1.2.1.2.2.1.3.3 = "6" [ASN_INTEGER]
01.03.2016 17:10:15 (365 ms) : 1.3.6.1.2.1.2.2.1.3.4 = "6" [ASN_INTEGER]
01.03.2016 17:10:15 (573 ms) : 1.3.6.1.2.1.2.2.1.4.1 = "1514" [ASN_INTEGER]
01.03.2016 17:10:15 (587 ms) : 1.3.6.1.2.1.2.2.1.4.2 = "1514" [ASN_INTEGER]
01.03.2016 17:10:15 (594 ms) : 1.3.6.1.2.1.2.2.1.4.3 = "1514" [ASN_INTEGER]
01.03.2016 17:10:15 (603 ms) : 1.3.6.1.2.1.2.2.1.4.4 = "1514" [ASN_INTEGER]
01.03.2016 17:10:15 (812 ms) : 1.3.6.1.2.1.2.2.1.5.1 = "100000000" [ASN_UNSIGNED]
01.03.2016 17:10:15 (821 ms) : 1.3.6.1.2.1.2.2.1.5.2 = "100000000" [ASN_UNSIGNED]
01.03.2016 17:10:15 (830 ms) : 1.3.6.1.2.1.2.2.1.5.3 = "1000000000" [ASN_UNSIGNED]
01.03.2016 17:10:15 (839 ms) : 1.3.6.1.2.1.2.2.1.5.4 = "1000000000" [ASN_UNSIGNED]
01.03.2016 17:10:16 (1063 ms) : 1.3.6.1.2.1.2.2.1.6.1 = "      " [ASN_OCTET_STR]
01.03.2016 17:10:16 (1071 ms) : 1.3.6.1.2.1.2.2.1.6.2 = "      " [ASN_OCTET_STR]
01.03.2016 17:10:16 (1079 ms) : 1.3.6.1.2.1.2.2.1.6.3 = "      " [ASN_OCTET_STR]
01.03.2016 17:10:16 (1088 ms) : 1.3.6.1.2.1.2.2.1.6.4 = "      " [ASN_OCTET_STR]
01.03.2016 17:10:16 (1304 ms) : 1.3.6.1.2.1.2.2.1.7.1 = "1" [ASN_INTEGER]
01.03.2016 17:10:16 (1312 ms) : 1.3.6.1.2.1.2.2.1.7.2 = "1" [ASN_INTEGER]
01.03.2016 17:10:16 (1320 ms) : 1.3.6.1.2.1.2.2.1.7.3 = "1" [ASN_INTEGER]
01.03.2016 17:10:16 (1332 ms) : 1.3.6.1.2.1.2.2.1.7.4 = "1" [ASN_INTEGER]
01.03.2016 17:10:16 (1533 ms) : 1.3.6.1.2.1.2.2.1.8.1 = "1" [ASN_INTEGER]
01.03.2016 17:10:16 (1541 ms) : 1.3.6.1.2.1.2.2.1.8.2 = "1" [ASN_INTEGER]
01.03.2016 17:10:16 (1548 ms) : 1.3.6.1.2.1.2.2.1.8.3 = "2" [ASN_INTEGER]
01.03.2016 17:10:16 (1556 ms) : 1.3.6.1.2.1.2.2.1.8.4 = "1" [ASN_INTEGER]
01.03.2016 17:10:16 (1766 ms) : 1.3.6.1.2.1.2.2.1.9.1 = "3963136815" [ASN_TIMETICKS]
01.03.2016 17:10:16 (1774 ms) : 1.3.6.1.2.1.2.2.1.9.2 = "3963655365" [ASN_TIMETICKS]
01.03.2016 17:10:16 (1782 ms) : 1.3.6.1.2.1.2.2.1.9.3 = "2907961145" [ASN_TIMETICKS]
01.03.2016 17:10:16 (1790 ms) : 1.3.6.1.2.1.2.2.1.9.4 = "2926320515" [ASN_TIMETICKS]
01.03.2016 17:10:17 (1990 ms) : 1.3.6.1.2.1.2.2.1.10.1 = "2904827843" [ASN_COUNTER]
01.03.2016 17:10:17 (1998 ms) : 1.3.6.1.2.1.2.2.1.10.2 = "3010202939" [ASN_COUNTER]
01.03.2016 17:10:17 (2006 ms) : 1.3.6.1.2.1.2.2.1.10.3 = "3287047553" [ASN_COUNTER]
01.03.2016 17:10:17 (2015 ms) : 1.3.6.1.2.1.2.2.1.10.4 = "1425918265" [ASN_COUNTER]
01.03.2016 17:10:17 (2249 ms) : 1.3.6.1.2.1.2.2.1.11.1 = "24305811" [ASN_COUNTER]
01.03.2016 17:10:17 (2259 ms) : 1.3.6.1.2.1.2.2.1.11.2 = "29937234" [ASN_COUNTER]
01.03.2016 17:10:17 (2268 ms) : 1.3.6.1.2.1.2.2.1.11.3 = "1276913053" [ASN_COUNTER]
01.03.2016 17:10:17 (2276 ms) : 1.3.6.1.2.1.2.2.1.11.4 = "2406669972" [ASN_COUNTER]
01.03.2016 17:10:17 (2488 ms) : 1.3.6.1.2.1.2.2.1.12.1 = "170371" [ASN_COUNTER]
01.03.2016 17:10:17 (2497 ms) : 1.3.6.1.2.1.2.2.1.12.2 = "4219" [ASN_COUNTER]
01.03.2016 17:10:17 (2505 ms) : 1.3.6.1.2.1.2.2.1.12.3 = "165195545" [ASN_COUNTER]
01.03.2016 17:10:17 (2513 ms) : 1.3.6.1.2.1.2.2.1.12.4 = "1177092682" [ASN_COUNTER]
01.03.2016 17:10:17 (2705 ms) : 1.3.6.1.2.1.2.2.1.13.1 = "0" [ASN_COUNTER]
01.03.2016 17:10:17 (2713 ms) : 1.3.6.1.2.1.2.2.1.13.2 = "0" [ASN_COUNTER]
01.03.2016 17:10:17 (2721 ms) : 1.3.6.1.2.1.2.2.1.13.3 = "0" [ASN_COUNTER]
01.03.2016 17:10:17 (2729 ms) : 1.3.6.1.2.1.2.2.1.13.4 = "0" [ASN_COUNTER]
01.03.2016 17:10:17 (2935 ms) : 1.3.6.1.2.1.2.2.1.14.1 = "0" [ASN_COUNTER]
01.03.2016 17:10:17 (2944 ms) : 1.3.6.1.2.1.2.2.1.14.2 = "3" [ASN_COUNTER]
01.03.2016 17:10:17 (2951 ms) : 1.3.6.1.2.1.2.2.1.14.3 = "0" [ASN_COUNTER]
01.03.2016 17:10:18 (2962 ms) : 1.3.6.1.2.1.2.2.1.14.4 = "0" [ASN_COUNTER]
01.03.2016 17:10:18 (3165 ms) : 1.3.6.1.2.1.2.2.1.15.1 = "0" [ASN_COUNTER]
01.03.2016 17:10:18 (3173 ms) : 1.3.6.1.2.1.2.2.1.15.2 = "0" [ASN_COUNTER]
01.03.2016 17:10:18 (3181 ms) : 1.3.6.1.2.1.2.2.1.15.3 = "0" [ASN_COUNTER]
01.03.2016 17:10:18 (3189 ms) : 1.3.6.1.2.1.2.2.1.15.4 = "0" [ASN_COUNTER]
01.03.2016 17:10:18 (3406 ms) : 1.3.6.1.2.1.2.2.1.16.1 = "3605690178" [ASN_COUNTER]
01.03.2016 17:10:18 (3414 ms) : 1.3.6.1.2.1.2.2.1.16.2 = "1668587008" [ASN_COUNTER]
01.03.2016 17:10:18 (3422 ms) : 1.3.6.1.2.1.2.2.1.16.3 = "132309723" [ASN_COUNTER]
01.03.2016 17:10:18 (3430 ms) : 1.3.6.1.2.1.2.2.1.16.4 = "2301750642" [ASN_COUNTER]
01.03.2016 17:10:18 (3628 ms) : 1.3.6.1.2.1.2.2.1.17.1 = "28700379" [ASN_COUNTER]
01.03.2016 17:10:18 (3636 ms) : 1.3.6.1.2.1.2.2.1.17.2 = "206319742" [ASN_COUNTER]
01.03.2016 17:10:18 (3645 ms) : 1.3.6.1.2.1.2.2.1.17.3 = "2091152048" [ASN_COUNTER]
01.03.2016 17:10:18 (3653 ms) : 1.3.6.1.2.1.2.2.1.17.4 = "3310896150" [ASN_COUNTER]
01.03.2016 17:10:18 (3868 ms) : 1.3.6.1.2.1.2.2.1.18.1 = "2186394936" [ASN_COUNTER]
01.03.2016 17:10:18 (3876 ms) : 1.3.6.1.2.1.2.2.1.18.2 = "1602046103" [ASN_COUNTER]
01.03.2016 17:10:18 (3884 ms) : 1.3.6.1.2.1.2.2.1.18.3 = "718788241" [ASN_COUNTER]
01.03.2016 17:10:18 (3892 ms) : 1.3.6.1.2.1.2.2.1.18.4 = "236649840" [ASN_COUNTER]
01.03.2016 17:10:19 (4098 ms) : 1.3.6.1.2.1.2.2.1.19.1 = "6611" [ASN_COUNTER]
01.03.2016 17:10:19 (4106 ms) : 1.3.6.1.2.1.2.2.1.19.2 = "947953" [ASN_COUNTER]
01.03.2016 17:10:19 (4119 ms) : 1.3.6.1.2.1.2.2.1.19.3 = "0" [ASN_COUNTER]
01.03.2016 17:10:19 (4128 ms) : 1.3.6.1.2.1.2.2.1.19.4 = "3470398" [ASN_COUNTER]
01.03.2016 17:10:19 (4338 ms) : 1.3.6.1.2.1.2.2.1.20.1 = "0" [ASN_COUNTER]
01.03.2016 17:10:19 (4346 ms) : 1.3.6.1.2.1.2.2.1.20.2 = "0" [ASN_COUNTER]
01.03.2016 17:10:19 (4355 ms) : 1.3.6.1.2.1.2.2.1.20.3 = "0" [ASN_COUNTER]
01.03.2016 17:10:19 (4363 ms) : 1.3.6.1.2.1.2.2.1.20.4 = "0" [ASN_COUNTER]
01.03.2016 17:10:19 (4561 ms) : 1.3.6.1.2.1.2.2.1.21.1 = "0" [ASN_UNSIGNED]
01.03.2016 17:10:19 (4569 ms) : 1.3.6.1.2.1.2.2.1.21.2 = "0" [ASN_UNSIGNED]
01.03.2016 17:10:19 (4577 ms) : 1.3.6.1.2.1.2.2.1.21.3 = "0" [ASN_UNSIGNED]
01.03.2016 17:10:19 (4585 ms) : 1.3.6.1.2.1.2.2.1.21.4 = "0" [ASN_UNSIGNED]
01.03.2016 17:10:19 (4799 ms) : 1.3.6.1.2.1.2.2.1.22.1 = "0.0" [ASN_OBJECT_ID]
01.03.2016 17:10:19 (4807 ms) : 1.3.6.1.2.1.2.2.1.22.2 = "0.0" [ASN_OBJECT_ID]
01.03.2016 17:10:19 (4815 ms) : 1.3.6.1.2.1.2.2.1.22.3 = "0.0" [ASN_OBJECT_ID]
01.03.2016 17:10:19 (4823 ms) : 1.3.6.1.2.1.2.2.1.22.4 = "0.0" [ASN_OBJECT_ID]

----------------------- New Test -----------------------
Paessler SNMP Tester 5.2
01.03.2016 17:10:32 (17 ms) : Device: 10.0.255.5
01.03.2016 17:10:32 (26 ms) : SNMP V2c
01.03.2016 17:10:32 (34 ms) : Walk 1.3.6.1.2.1.31.1.1.1.1
01.03.2016 17:10:32 (46 ms) : 1.3.6.1.2.1.31.1.1.1.1.1 = "LAN Interface 0/1" [ASN_OCTET_STR]
01.03.2016 17:10:32 (59 ms) : 1.3.6.1.2.1.31.1.1.1.1.2 = "LAN Interface 0/2" [ASN_OCTET_STR]
01.03.2016 17:10:32 (72 ms) : 1.3.6.1.2.1.31.1.1.1.1.3 = "LAN Interface 0/3" [ASN_OCTET_STR]
01.03.2016 17:10:32 (84 ms) : 1.3.6.1.2.1.31.1.1.1.1.4 = "LAN Interface 0/4" [ASN_OCTET_STR]

Created on Mar 16, 2016 9:33:37 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.