I would like to graph a SNMP string value. Using the SNMP Custom String sensor, I see that the string value is displayed:

• in the "message" column when I view the all sensors on the device
• in the "message" column of the Log tab of the specific sensor.
• it's not displayed in graph

Monitoring strings with PRTG

PRTG cannot graph strings, but it offers a lot of other approaches and one of them will usually fit your requirements.

Working with strings in PRTG can be somewhat tricky; however, there are several possibilities.

Regular string monitoring

The SNMP Custom String sensor allows you to poll any string. However, the respective channels will only display the Response Time because only numerical values (1, 2, 3, -5, 4.56, 0, ...) can be assigned to channels.

This sensor will only generate alerts by default if the string or OID becomes unreachable or unavailable. Otherwise, the sensor allows you to check the result against an expected string or get notifications via Change Triggers if the value changes. Note that a matching string will set the sensor to a Down status. However, it will not modify existing channels or create additional channels.

Regular string monitoring with regex

With the SNMP Custom String sensor, you can also modify the sensor's settings to use regular expressions to extract values from within these strings. For instance, you can obtain CPU load from a Linux system via SNMP, which will look like the following:

This is obviously not one numerical value, it contains a couple of values. In this case, the following regular expression can be used to extract any of the three relevant values:

The Index of Capturing Group controls which of the matches will go into the newly created Extracted Value channel of the sensor. You can read more about it here:

• PRTG Manual: Example: Number Extraction with Regular Expression
• Value extraction using Regular Expression: Custom String Sensor
• Graph Last Message?

String via lookup

The SNMP Custom String Lookup sensor will be very handy if the OID that you are monitoring provides well-known responses or strings, for example, "active" or "inactive" (for a cluster or node status). The lookup has to be created using a text editor (as it is an XML-like file). It will tell the sensor:

• which string(s) to expect,
• which sensor status will correspond to which string (active = ok, inactive = warning), and
• the desired value.
  In other words, this sensor turns the string into something that PRTG can easily parse and use, that will generate alerts, and display the received string as well. The Value channel will display the received string mapped to a state. For an example, see the article Monitor and "Lookup" a SNMP String value.

The issue with status averages

In a lookup file, the desiredValue attribute is sometimes underrated but it is useful when it comes to the representation of averages. Keep in mind that PRTG is designed to work with numerical values (response time, traffic, disk use, and others). In this case, however, we are talking about a status. Have a look at the following scenario:

The sensor is polled every 60 seconds. The Live Data tab of the sensor is displaying the following:

On the 2 days, 30 days, and 365 days tabs, PRTG always displays average values. If this average was an ordinary number, this would be very easy. The average (from 07:58:22 to 08:02:22) is 1,4. However, we are talking about a status and not a value. So what is the status average of 3x active and 2x inactive?
Because there is no real answer, PRTG uses the desiredValue attribute from the lookup file to calculate this. In this particular case, if the desired value was active, PRTG would tell you that during that period, the value was the desired value 60% of the time.

To sum it all up, make sure that your desired value is correctly set and that PRTG can generate a meaningful value from it. For more information on lookups, see section Define Lookups in the PRTG Manual.

Custom approach

As PRTG is highly customizable, it should not be too hard to put together a script/exe file that:

• is run by PRTG with every sensor scan (this means every scanning interval),
• reads the parameters forwarded by the sensor (%host, %snmpcommunity),
• performs the query using NET-SNMP's binaries (snmpwalk.exe or snmpget.exe) or other binary/dll of your choice,
• parses the result according to your wishes (you can use a case statement to match strings to values),
• formats the output in a single or multi-channels PRTG API-compliant format (XML/JSON), and
• lets PRTG read and display the values provided by the script.

Here are some examples of PowerShell/NET-SNMP-based custom sensors:

• Problem with a Synology UPS OID
• Sensor for BGP status

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.