I think it's important to give a concrete example whenever possible. I am using PRTG to monitor 15,000 wireless access points across a School District in the US. For each school, I want to be able to graph the number of Access Points that are out of service over time. The best way is to track the state of associated PING sensors and count any sensor that is not in one of Unknown, Collecting or Up as indicating an Out of Service device.

I am using the RESTclient extension of Firefox for testing and my REST API URL looks as follows:

https://prtgaero.palmbeach.k12.fl.us/api/table.xml?content=sensors
&output=xml
&columns=objid,group,device,sensor,status
&id=6436
&filter_status=4&filter_status=5&filter_status=6&filter_status=7&filter_status=8&filter_status=9&filter_status=10&filter_status=11&filter_status=12&filter_status=13&filter_status=14
&filter_type=ping
&username=*****&passhash=*****

The XML returned is something like:

<?xml version="1.0" encoding="UTF-8"?>
<sensors totalcount="1" listend="1">
  <prtg-version>18.4.46.1754</prtg-version>
  <item>
    <objid>28439</objid>
    <group>BocaRatonCHS 0961</group>
    <device>04-107::AH-CC1A40</device>
    <sensor>Ping</sensor>
    <status>Down </status>
    <status_raw>5</status_raw>
  </item>
</sensors>

I am going to eliminate all of the returned fields except "objid" in my Sensor definition.

I created a self referential "Device", that is a Device with the PRTG servers own hostname so that it can call its own API.

I then created the HTTP XML/REST sensor. Since this is a REST sensor, the Authentication values go in the URL not in the Username and Password fields.

In the XML Node field I entered "sensors totalcount" because I want the value of the "totalcount" attribute under the "sensors" node.

The limitation I see here is that the ID of the group for which I want to count sensors is embedded in the URL ( "&id=6436" line ). I want to be able to programmatically clone this sensor and manipulate that group ID using a script. I have 180 schools to create these sensors for so this will take all day if I do it manually.

Dear GwigstaNummerEin,

in principle, you could try to script the sensor creation. It is possible to list all devices under a node, a script could then process that list and create all those URLs.

However, writing, testing and employing such script would probably take more time than doing it manually. I strongly advice against applying a script – which has not been thoroughly tested – to a production server. This means, a migration to a PRTG copy is in order, which needs another machine and involves extra work.

An option could be the approach to perform the API call with powershell, parse the result and return it. The PS1 file can be added to PRTG as custom Exe/Script sensor. This allows you to provide the ID as sensor parameter. Normally, this does not scale well, as only so many processes can be started without running into stability issues. But the XML/Rest sensor is actually an Exe sensor as well.

Either if you use XML/Rest, or a custom sensor, please use long scanning intervals, of at least 5 minutes.

There is another option: Clone the sensor, use the PRTG API to change its properties. These examples are for a sensor id 2123. The URL setting can be changed with

/api/setobjectproperty.htm?id=2123&name=xmlurl&value=http://my-new-url

The node to read can be changed with

/api/setobjectproperty.htm?id=2123&name=xmlnode&value=my-new-node

API calls can be performed through scripts as well, but please don't to bulk changes with an untested script on a production server.

I did use the method of cloning a sensor and modifying the "xmlurl" property and I did script it. I potentially have 180 of these sensors to create so scripting it and creating a reusable python module that wraps the PRTG API is a worthwhile investment for me.

I tend to run these scripts through a debugger with break points so that I can track progress and abort if things don't look right. I haven't had any issues so far and I am in the process of getting this server ready for production so the risk is worth it. I just need to insert pauses between object creation calls because the server gets overloaded if I don't.

I did forget to drop the scanning interval and that is important so thanks for the reminder. I want this primarily for long term trend monitoring so I could maybe drop this to 15 minutes.

My plan is to build out a multiple probe environment so I might end up dedicating a probe to doing these computationally "expensive" calls.

Dear GwigstaNummerEin,

yes, using pauses between API calls is a good idea to prevent system overload. A PRTG API call is always done on the core server, meaning a multi-probe setup cannot be used to distribute API call system load, even if the sensors you change run on a remote probe.

Once you changed the sensor through the API, the core server updates the sensor configuration on that probe. (The sensor configuration for all sensors is stored on the core server.)