Important note: The following information is outdated.

This article applies to PRTG Network Monitor 8 through 15.2.16

Connect Remote Probes to the Master Node

You can use Remote Probes in a PRTG cluster. These monitor the (remote) network they're installed in and forward monitoring data to the PRTG Master Node core server.

However, there are some restrictions when using Remote Probes in a cluster setup:

1. You can configure Remote Probes for a connection with the Master Node only. Due to the individual authentication method, a Remote Probe is bound to the Master Node and cannot be setup for connection with a Failover Node.
2. If the Master Node of a cluster fails, another Failover Node takes the Master role as long as the original Master Node is down. During this time, a Remote Probe cannot send any data, as the Failover Nodes are unknown to it. So, the probe will buffer monitoring data (this possible for a certain time) and send it once the original Master Node server is back online.

More

Remote Probes are a powerful monitoring feature. However, some restrictions apply when the connection to the (Master Node) core server is lost. For more information about this, please see the article Monitoring Client Computers Offline Using Remote Probes.

This is a feature that some of us have been asking for since PRTG7. I, for one, had hoped that PRTG9 would include the ability to connect remote probes to a failover server. I really don't understand why it's not possible to do this. Can you advise please when this feature will be available?

"Clustered Remote Probes" are considered, but I'm afraid I cannot give you an exact release-date/version in the moment. Please bear with us.

Please don't "Consider" but add it to the to-do list, we need this as well. When maintenance is done to the primary server you not only loose sight during that time, you also get inaccuracy in monthly reports.

Need this function as well. Please add to to-do-list

I am curious how hard this would be to implement. Assuming I am using a domain name for my remote probes to connect to as long as the DNS redirects to the failover site when the primary site fails all of the probes would be able to redirect to the failover site. As long as the failover site can accept the access key it is using it seems to like it would work. Maybe I am missing something that makes this much harder to program for.

unfortunately there is more to it. If it was easy we would have already implemented it.

Ba assured that all your votes are counted and that we consider the effort.

Hello,

Having the ability to redirect the remote probes to another node that is acting as the current Master node would make PRTG more excellent than it currently is.

Clustering really has no functional value without that ability.

Is there any timeline or consideration for the addition of this feature?

Also, I do not recall, but once the communication failure that isolated the original Master node is resolved, does the current Master then update the original Master node and return control ?

Thanks!

This is a huge feature I am looking for as well. If I am running a clustered PRTG setup it would be natural to think that if my Master goes down the devices then re-connect to the Failover as I have the DNS set to roll to the Failover server.

all votes for this feature are counted.

+1 for this feature

Any news about this feature? I am looking forward to have cluster probe to take over as failover when the master node goes down.

The feature is still on the wishlist but no release date has been determined yet.

+1 for this feature.

I would assume that all the probes have a list of the different cluster servers. And when the master can't be reached for a period of time it asks one of the other servers it knows, what server is the new master. Just my 2 cents.

Love the product, please continue the great support!

Vincent

+1 for this feature

THX

Any news regarding this feature that seems "indefinitely postponed" ?

As mentioned earlier: if this was easy to implement, we would have already added this feature. However, unfortunately it is not. There is still no specific timeframe for when such a feature will be included - we still have it on our future implementation list, but it is unlikely that such a function will be available any time soon. Sorry.

Nothing worth doing is easy. ;)

Honestly, this is the only reason why we can't rely on PRTG for up/down monitoring of critical services. We use remote probes heavily and can't have the master server become a single point of failure in our monitoring infrastructure.

+1 Vote to this feature.

This would make PRTG even better. We really like PRTG and we would like to see this feature implemented in the near future.

Regards.

+1 Vote to this feature.

+1 Vote

it does not make sense such things are not build in. you make a cluster feature and the use of remote probes for larger installs is a requirement. in orther words that a remote probe cannot connect to a failed over master is a bug not a feature imo.

please add asap..

Thx

Throwing in my +1 again for this. I think this is the most voted for feature I've seen yet in all the KB articles. Any update on when this will be implemented or whether or not it is on the roadmap for the near future?

At least 7 of our monitoring customers moved away from PRTG in favor of other services/software solutions that have failover capabilities for remote monitoring and we would really like to try to recover some of them as they were happier with PRTG before switching.

We understand well the unpleasant situation for those of you who use Remote Probes heavily and still need a fail-safe cluster setup.

Currently, there is only one solution for a fail-safe monitoring in different locations: At each location, install two PRTG core servers and configure them to run as a two-node fail-safe cluster. Using the Enterprise Console, you can still connect to all of your individual installations and see all data in one console.

However, we know that the need for remote probes that are connected to several cluster nodes is increasing. So, we're definitely looking into a solution for this. But as always, I cannot give any dates yet. We're still in research for this.

+1 vote to this feature.

This would make PRTG even better. We really like PRTG but we would like to see this feature implemented as soon as possible.

Part of a an organisation that monitors multiple customers using the probes and this feature would greatly bolster our operations.

+1

+1 vote for this Feature

Our planned deployment is totally based on remote probes...

+1 vote for this feature.

Hopefully when added the implementation allows for defining a group of remote probes as its own "probe cluster group" as well.

So we can have fail-safe of the devices connected to a remote probe cluster and the remote probe cluster itself will fail-safe back to it's core cluster.

Making the loss and replacement of a single remote probe device no big deal, as well as the core service will still be online and servicing the remaining remote probes even if the cluster master is offline.

+1 for this feature request as well.

+1 for probes connected to every cluster node.

I suggest everyone to click Vote on "Best answer" ^above^

+1 for remote probes in cluster node.

Just setting up a distributed PRTG solution for a cloud infrastructure, i hit this problem, which is disappointing but can be worked around with a little extra outlay , if the monitoring is important enough this shouldn't be a problem , i will probably just do without the remote monitoring until i get the PRTG core back on-line - or just point the probes to the other node in the event of a master failure.

If in fact the probe connection endpoint could be changed / service restarted via script it could switch over automatically in the event of an outage and swap back when it came back up

This is a bit further down the line for me but when i get there i will look at this providing paessler haven't done something by then :)

What particular version includes the support of remote probes for PRTG cluster? I couldn't find anything in Release notes.

I apologize the previous post was not fully correct. Clustered Remote Probes will arrive in the Preview Channel shortly. Please bear with us.

+1! I noticed the original request was over 5 years ago but I need this as well.

Has it been implemented yet? Thanks.

Yes, it has been implemented: Failover Cluster Configuration > Remote Probes in Cluster :)

Ok thanks for the reply and I just read it, however it doesn't scale.

Right now we have a 2 node cluster and if I add 1 device to the cluster probe all sensors are automatically queried by both nodes and that is the desired behavior. Our PRTG installation is so large now that soon we will have the need to separate core and probe services onto different servers. But it seems if that is done then we lose the cluster features.

In the quote below you mention we can copy all devices onto another probe but this is impossible and doesn't scale at all. We have many people that adds, deletes, and modifies devices and there doesn't need to be possibility of human error, not to mention doubling the work to add and delete devices having to do everything twice.

What we need is to be able to cluster 2 remote probes together. As an example see below:

Cluster Configuration:

• Core Node 1
• Core Node 2
• Remote Probe 1
• Remote Probe 2

"Remote Probe" should show up in the PRTG interface so you only have to add, delete, or modify a device once. This way you can separate out core and probe devices and still get the cluster benefits. You can lose any one server and still have full monitoring. Otherwise PRTG's cluster capabilities doesn't scale.

"Note: You can use remote probes in a cluster as described above, which is showing monitoring data of all your probes on all nodes in your cluster. However, you cannot cluster a remote probe itself. To ensure gapless monitoring for a specific remote probe, install a second remote probe on a machine in your network next to the existing probe, and create all devices and sensors of the original probe on it. For example, you can clone the devices from the original probe. The second probe would be a copy of the first probe then and you can still monitor the desired devices if the original probe fails."

Could you explain what you try to do with a schematic? I'm not sure if I can follow your description :/

Due to this probably not being implemented in a reasonable time, you could simply set up two remote probes that have a ping sensor for each other that pauses all sensors accordingly, once either ping goes down. However, you need to keep the groups in sync using the API.

A bit tedious to set up, but should work rather flawlessly :)