Can disconnected remote probes be classified as "not an alarm"

Dear Kenneth,

the solution would be:

• Add a ping sensor for each probe (which requires an additional device object for each probe)
• Set the ping sensor to "Auto-Acknowledge"
• Open the probe node's setting tab, go to "Dependencies" and select the according ping sensor as master object

Now if the connection gets lost, the ping sensor goes into the acknowledged alarm and the probe node gets paused by the dependency to the ping sensor.

Dear Arne

Sorry for not getting back earlier.

I'm unable to make the suggested solution work. The ping sensor can't report back when the remote probe looses the internet connection, and never causes the parent nodes 'Dependency' (Ping-sensor) to Auto-Acknowledge.

Adding additional devices to the PRTG server itself with IP addresses pointing towards the Remote Probes won't work as the Remote Probes may change their IP and doesn't have DNS... if that was what you were thinking.

I'm also a bit hesitant to add an extra device for each remote probe. This seems bloated. An extra sensor would however not be a big issue...

Any other ideas, or did I get it wrong?

Dear Kenneth,

if the remote probes can change the IP, the solution outlined by me will not work. There is no good solution in this case. A disconnected probe will cause the probe health sensor being in the alert status.

In principle, you could pause the health sensors. But this would also mean that you don't get useful information about the probe status, which is helpful (or necessary) to isolate the cause if there are any stability issues.

Dear Arne

I see... although it's not the reply we hoped for. This means that we will register a lot of useless alarms when using PRTG in distributed systems. That's a shame, as it can cause important alarms to be hidden among the "I am not presently here" alarms.

Could this be made a request for change? I suggest a global yes/no variable indication whether to mark disconnected devices as alarms, and the possibility to overwrite the setting on the remote probes settings. I guess this would be possible with the current logic in PRTG.

Dear Kenneth,

this is another reply you didn't hope for. We want to keep the PRTG interface concise and only add options if there is enough demand to justify it. Because of this, PRTG is still relatively easy to learn and to operate.

Dear Arne

I understand, but it's really a shame as it means we'll have re reconsider if PRTG is the right tool for monitoring distributed systems.