New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

 

Top Tags


View all Tags


What can I monitor with the SNMP Custom Table Sensor?

Votes:

0

Your Vote:

Up

Down

PRTG comes with a so-called SNMP Custom Table sensor. I have a few questions about the capabilities and usage of this SNMP sensor:

custom prtg sensors snmp snmp-custom-table table

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

Last change on Mar 16, 2016 10:12:06 AM by  Gerald Schoch [Paessler Support]



2 Replies

Accepted Answer

Votes:

7

Your Vote:

Up

Down

This article applies to PRTG Network Monitor 16 or later

Introduction to the SNMP Custom Table Sensor

The SNMP Custom Table sensor (available as of PRTG version 15.3.18) 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) for objects when there are multiple instances of the same thing (for example, memory, disks, interfaces).

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

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

To monitor table objects, you could use individual sensors (SNMP Custom sensor or SNMP Custom Advanced sensor), but setting up the sensors for multiple interfaces would be very time-consuming. Or you could try to acquire the MIB file and import it for deployment as a SNMP Library sensor, but this would generate a large number of sensors which by themselves would not be 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 within PRTG. It allows you to configure the sensor and to select all desired indexes (interfaces) which you want to monitor. It is capable of monitoring up to 10 channels per sensor.

Within our MIB Importer, you can identify a Table by checking the Kind of the OID which you inspect. The screenshot below illustrates what you would see when importing the IF-MIB. Please notice the Kind "Table". Also important, the Lookup on the bottom-right will tell you how to define your lookup file for this OID.

MIB Importer

Click for Full Size

There's an extended explanation regarding the creation/usage of lookups here:


Sensor Setup

Example SNMP Dataset

We demonstrate the usage with real data from a switch. The data is as follows. The data was acquired using our SNMP Tester. Please scroll down or click this link to view the data.

Creating the Sensor

1. In PRTG open the target device, select Add Sensor, look for SNMP Custom Table, and enter the table's OID. In this case we 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 which has the same index as the entries from the current table. For example, in this case we'll create a sensor for the ifTable but we can query the ifName from the ifXTable as well. To do this, add the following to the name [1.3.6.1.2.1.31.1.1.1.1]. Do not enter an index as it will be appended automatically. Be aware, however, that while the [rowidentifier] can be updated dynamically, any other OID entered here will only be updated once, during the sensor creation.

We'll use the following name in this example:

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

Sensor's Name

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

Table View

3.1 (Optional) To view translated OID names here, you have to place the MIB file in the \MIB subfolder of your PRTG installation directory. Use the MIB Importer to check for common syntax errors first. A PRTG core server restart is required after placing 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. You should 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'll select ifDescr. Note: Changing or duplicate values in this column can affect the sensor's operation!

5. Now we begin configuring and selecting our channels. Start with the Sensor Channel #1 Name, because we'll use this channel (the primary channel) to monitor the interface's status (we call this State). For the Sensor Channel #1 Column, because we look for the state, select ifOperStatus. Now, this will require a lookup which you need to create in advance. To use the lookup set the Unit to Value lookup and in the Sensor Channel #1 Value Lookup select the desired lookup. We use prtg.custom.ifoperstatus.

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

Channel 1 and Index

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

Channel 2 and 3

5.2 Our last channel in this example will be to measure the interface's speed, so we call the channel Speed. The column is ifSpeed. The Value is the default Gauge. Now for the Unit we can either use Count or create a lookup file for this as well. We use Count in our example.

Channel 4

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


Conclusion

Screenshots

This is what the created sensor looks like. Please note that the sensor is named accordingly to the entered placeholders/OIDs.

Sensor's Overview

Click for Full Size


When Should I Use the SNMP Custom Table Sensor?

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

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 223 (no such instance) or start displaying inaccurate data.
  • It is fully compatible with device templates and 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 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.

Further Reading and Use Cases

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

Last change on Jun 13, 2017 5:04:12 PM by  Martina Wittmann [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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 Support]



Please log in or register to enter your reply.


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.