Hello Trung,
thank you for your question and no worries.
PRTG cannot graph strings, but it offers a lot of other approaches and one of them will usually fit your requirements.
Monitoring strings with PRTG
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 only display the Response Time because only numeric values (1, 2, 3, -5, 4.56, 0, ...) can be assigned to channels.
This sensor only generates 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 sets the sensor to the Down status. However, it does 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 looks like the following:
| 5 Sec (3.49%), 1 Min (3.555%), 5 Min (3.90%) |
This is obviously not one numeric 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:
| (\d+\.\d+).*?(\d+\.\d+).*?(\d+\.\d+) |
The Index of Capturing Group controls which of the matches go into the newly created Extracted Value channel of the sensor. You can read more about it here:
String via lookup
The SNMP Custom String Lookup sensor is 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 must be created using a text editor (as it is an XML-like file). It tells the sensor:
- which string(s) to expect,
- which sensor status corresponds 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 generates alerts, and displays the received string as well. The Value channel displays the received string mapped to a state. For an example, see the article Monitor and "lookup" an 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 numeric 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 displays the following:
| Date Time | Value |
|---|
| 08.02.2017 08:02:22 | 1(Active) |
| 08.02.2017 08:01:22 | 1(Active) |
| 08.02.2017 08:00:22 | 1(Active) |
| 08.02.2017 07:59:22 | 2(Inactive) |
| 08.02.2017 07:58:22 | 2(Inactive) |
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 PRTG Manual: Define Lookups.
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:
Best Regards,
Luciano Lingnau [Paessler Support]
Add comment