Make more custom sensors available on hosted prtg

Hello Noah,

That will be highly unlikely, since adding any of those custom sensor types is blocked anyway on the level of "Hosted Probe".

You can use the REST Custom Sensor alternatively:

• Head to "Setup | Account Settings | My Account", press the button for showing the passhash and copy it, you'll need it later.
• Add a device with the DNS name of your PRTG instance (xxxx.my-prtg.com)
• Add sensor REST Custom to it
• Select template "prtg-sensor-stats" in the sensor's settings as "REST Configuration".
• In "Rest Query" enter this: api/table.json?id=0&content=sensorxref&noraw=1&filter_basetype=probe&columns=totalsens=textraw,upsens=textraw,downsens=textraw,partialdownsens=textraw,warnsens=textraw,pausedsens=textraw,unusualsens=textraw,undefinedsens=textraw,downacksens=textraw&username=USERNAME&passhash=PASSHASH
• Replace USERNAME with your login (email address) and PASSHASH with the aforementioned passhash This will show sensor stats for all sensors run on Hosted Probe.

If you like the sensor to show stats for a particular remote probe, click on the remote probe in the tree, you will see a link like this in your browser's address bar:
https://xxxx.my-prtg.com/probenode.htm?id=1234 1234 is the id of interest in this example, add the same sensor again and replace id=0 with id=1234 api/table.json?id=1234&content=sensorxref&noraw=1&filter_basetype=probe&columns=totalsens=textraw,upsens=textraw,downsens=textraw,partialdownsens=textraw,warnsens=textraw,pausedsens=textraw,unusualsens=textraw,undefinedsens=textraw,downacksens=textraw&username=USERNAME&passhash=PASSHASH

This will result in a sensor showing a summary of all sensor states for the regarding remote probe.

Kind regards,

Erhard

Yes, I realize these sensor types are blocked. That's why I asking for a product improvement to make them available somehow.

I have tried your suggestion, putting in my username and passhash and the id value of the group I want to monitor and the sensor gets the following error: "Could no evaluate channel value of Total: index 0 out of bounds."

I will send you an email shortly for accessing your instance, so I can look at the issue with the REST sensor directly.

In an email back to me, you said:

"You've had "id=2014" in the query, which is the id of a group, that won't work with this query, it has to be the id of a probe, so since the group is monitored by "Hosted Probe", I've changed it to "id=0"."

But I don't want to monitor the whole probe, just the sensors in that group. So my feature improvement request stands.

"But I don't want to monitor the whole probe, just the sensors in that group. So my feature improvement request stands."
It is the only group on "Hosted Probe", so you get the data from those few sensors on "Probe Device" additionally with the query.

"So my feature improvement request stands."
Due to other priorities for this year it was decided that no efforts will be put into any functional changes around the hosted offering besides providing PRTG updates, so chances are not good.

"The problem with this is I use it to monitor mission-critical sensors on the PRTG hosted probe. If our remote probe is unreachable, we would not get notifications from this sensor."
The way I see it, the whole point is that you want to be informed when something's wrong with the mission critical equipment monitored by "Hosted Probe", so why don't you add according notification triggers to those sensors/devices in question instead, which will tell you then in the notification directly which sensor has an issue? Your current approach is to use "SensorCountXML.exe" to query the status of the sensors in that group and then trigger a notification when "Down" sensors are being counted, where the notification will only tell you then "Well, there are down sensors", while the notification triggered by the relevant sensor would directly show the impacted sensor.

"It is the only group on "Hosted Probe", so you get the data from those few sensors on "Probe Device" additionally with the query."
Right, but we're just getting started with our monitoring and may be adding more groups/devices/sensors so want this feature to be as flexible as possible.

"Due to other priorities for this year it was decided that no efforts will be put into any functional changes around the hosted offering besides providing PRTG updates, so chances are not good."
That's fine. You guys asked for product improvement requests, so I made one.

"so why don't you add according notification triggers to those sensors/devices in question instead,"
Because I don't want nearly 400 notification messages if something goes wrong with our web server. I want one summary message, but I want that summary message to be more reliable than running the custom sensor on a remote probe that may or may not be accessible.