I would like to monitor the sensor count in a certain group in PRTG. How can I get the number of sensors in a group of devices? How do I include the sensor count into a sensor?
This article applies to PRTG Network Monitor 15 or later
Monitoring the Number of Sensors in a Specific Group
In general you have two options to monitor the sensor count in a specific group. You can create an HTTP XML/REST Value sensor that uses the PRTG API to get the number of sensors in a specific group without sub-groups, or you can use a third party sensor by PRTG Tools Family.
For example, monitoring the sensor count can be useful for Managed Services Providers (MSP).
Monitoring Sensor Count via PRTG API
To monitor the number of sensors in a specific group without sub-groups, for example, paused or unknown sensors count, you can use an HTTP XML/REST Value Sensor in your PRTG installation.
Set up the sensor as shown below. This approach will retrieve a JSON file via the PRTG API that contains the current number of sensor states and parses it. Define the sensor states you are interested in and add sensor limits depending on your needs.
Steps to Go
- Manually add an HTTP XML/REST Value sensor to your PRTG installation.
- In the sensor settings, provide the following target URL:
- Replace https://MY_PRTG_SERVER with the address of your PRTG installation.
- Replace MYGROUP with the name of the group whose sensor count you want to monitor.
- Replace MYUSERNAME and MYPASSHASH with the credentials of your PRTG server to authenticate the HTTP request.
- Adjust the filter_status parameters to your needs. Only leave the sensor states that you want to count. Please see below for a table with sensor status IDs.
- Enter the XML Node in the sensor settings:
- Set SSLv3 Connection to Use SSLv3 if available if necessary.
- You can leave all other settings unchanged.
- Click Continue to create the sensor.
IDs of Sensor States
You can use the following internal IDs for filter_status parameters to only count sensors in a specific status:
For example, if you want to count only sensors in Up status, only provide the parameter filter_status=3
Monitoring Sensor Count with Custom Sensor
PRTG Tools Family provides a custom third party sensor for download that counts the number of sensors per status. This custom sensor counts also sensors in sub-groups.
Note: We do not offer support for third party sensors. If you encounter any issues with this sensor, please contact PRTG Tools Family directly.
Steps to Go
- Download the sensor SensorCountXML from the PRTG Tools Family sensorxml download page.
- Extract the files and copy the file SensorCountXML.exe into the \Custom Sensors\EXEXML subfolder of your PRTG program directory.
- Add an EXE/Script Advanced sensor to your PRTG installation and use the following parameters:
-s=ip-address|hostname] -u=username -p=password|passhash [-r=rootID] -s = The IP and optional port number of your PRTG server -u = Username -p = Password or passhash -r = Optional, the rootID of the probe or group you want to count from (default = 0)
The channels of this sensor will show the number of sensors for each status under the root ID you specify in the parameters.
- Knowledge Base: Monitoring the Number of Sensors in a Specific Status
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>184.108.40.2064</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.
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
The node to read can be changed with
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.
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.)