0

Developing a (in PRTG-speek) "custom advanced REST sensor" providing XML, I'm facing some problems that the documentation does not really answer.

First let's have a look what one of my sensors (in "alpha" development state) actually outputs (XML comments removed for brevity):

<?xml version="1.0" encoding="UTF-8"?>
<Prtg>
  <Text>meminfo OK</Text>
  <Result>
    <Channel>Active</Channel>
    <Value>374688</Value>
  </Result>
  <Result>
    <Channel>Writeback</Channel>
    <Value>0</Value>
  </Result>
  <Result>
    <Channel>Inactive</Channel>
    <Value>539368</Value>
  </Result>
  <Result>
    <Channel>Buffers</Channel>
    <Value>237668</Value>
  </Result>
  <Result>
    <Channel>Free</Channel>
    <Value>376916</Value>
  </Result>
  <Result>
    <Channel>Cached</Channel>
    <Value>571884</Value>
  </Result>
  <Result>
    <Channel>Dirty</Channel>
    <Value>36</Value>
  </Result>
</Prtg>

So there are seven "channels" for this particular sensor I call PFS_mem1 (obviously some memory statistics). The output is returned from my small HTTP REST server as Content-Type: application/xml.

The PRTG configuration's "REST Configuration" is set to "channelDiscovery", because I had assumed that the "Channel"s from the XML "Result"s would be detected automatically (as opposed to providing a "REST configuration file").

However after having configured the sensor, the labels for the channels (e.g. "Buffers") are not "detected" (as I had expected); instead there are expressions like $["Prtg"]["Result"]["0"]["Value"] being displayed where a label should be. In contrast the "Value"s are extracted correctly.

Wouldn't $["Prtg"]["Result"]["0"]["Channel"] extract the corresponding "Channel" name?

Another problem apart from the labels is assigning the "Result"s to the "Channel"s: It seems that the channels are not identified by their names, but by "Result" position, so when the order of the "Result" elements (thus the "Channel"s) change, PRTG seems to mix the different channels in the graph.

Live Data Graph of PRTG for REST XML Custom Sensor

The expression displayed seems to indicate that PRTG does not use XPath, but their own syntax, and their interpretation of XML (that I will encode in double-quotes) seems to use XML-like syntax, but actually is not XML. Instead they seem to assume that all "XML" is created by replacing some placeholders in some template.

The (seemingly useless) requirement to provide a "REST configuration file" may support my impression that PRTG cannot really process XML, the help text for the REST custom sensor says:

The sensor requires that you store the REST configuration file that contains the mapping rules on the probe system. In a cluster, copy the file to every cluster node.

However my sensor actually creates an object tree on the fly, storing the individual channels in a hash table, and finally transform that data structure to XML.

So what is "Channel Discovery" in PRTG all about?

Documentation

I found this "documentation", being of little help:

The default REST configuration file is channelDiscovery. If you select this file, the sensor parses the returned JSON or XML and automatically creates channels based on available values: one channel for each number and boolean for strings if they are convertible into numbers.

1
  • I also played with "HTTP XML/REST" sensors for which the manual says: "You can try to use XPath syntax here but it does not work in all cases and we do not provide any technical support for XPath issues.". I found out that Prtg/Result[1]/Channel/../Value works, but Prtg/Result/Channel[text() = 'Active']/../Valueis rejected with "'//Prtg/Result/Channel[text()' has an invalid token.". Looks very much like "broken by design" to me...
    – U. Windl
    Commented Oct 16, 2023 at 9:35

0

You must log in to answer this question.

Browse other questions tagged .