I would like to request to the features needed to create and deploy clustered remote probes, such that all probe host within each cluster both monitor and contain the all the data collected so that if a remote probe host system is replaced completely without notice, the cluster can continue without data loss and be re-deployed from the remaining probes nodes to the new replacement host.

I know you have a manual process now and it's documented to migrate or clone remote probes system for redundancy. But the problem is you need to have it done in advance of a host replacement of failure and also the clone or copied data goes stale the moment the cloning is completed. I would like to request that this be improved upon greatly by way of a the solution mentioned above.

Thanks again guys.


Article Comments

Hello,

the request is absolutely legit and reasonable, but you are the first one to request this and therefore it is unlikely that you will see this any time soon in PRTG, sorry.


Aug, 2015 - Permalink

Ok, in that case please also note me for this. We also would like to have the remote probes in cluster available, and not by makeing all kinds of changes by hand in advance.


Mar, 2016 - Permalink

Any update on this request? Has any improvement been made in this area outside of the specifics of this requests that you can share?

This feature would still be very useful for us.

Thank you.


Apr, 2016 - Permalink

@stephensuley: Please see this blog article introducing the functionality.
Best regards


Apr, 2016 - Permalink

@Konstantin Wolff [Paessler Support]: That blog is about clustering the main nodes. We are asking for clustering the Remote Probes.

So we would have a cluster at the top and every remote probe would be double also as a cluster.


May, 2016 - Permalink

+1 for this. Clustering the core services is great but having remote probes as a single point of failure totally defeats the object of having a clustered environment, especially if you don't have the ability to have the central cluster monitoring everything.

We have a customer with multiple segregated environments that I am looking to deploy PRTG into. The cluster is in the most secure of the environment with remote probes in each of the others and I can't see any way to make the setup fully redundant without either buying multiple copies of PRTG (one for each environment) or by duplicating all the sensors on each remote probe.

Doesn't make sense to only cluster half of the solution and then have to bodge the rest...


May, 2016 - Permalink

Yes. The ability to create clusters of remote probes, one for every network segment, is what we need.


May, 2016 - Permalink

Add another vote we need to have this work altogether when you setup the cluster mode not just the servers.


Jun, 2016 - Permalink

+1 We also really really Need this Feature


Jun, 2016 - Permalink

Yes, completely agree, this is needed to implement a fully redundant monitoring system.


Oct, 2016 - Permalink

+1 on this. Having had windows servers fail (I still hate having to be forced to use Windows) having the ability to cluster probes themselves together would be ideal as to not end up losing XX time of monitoring for whatever that probe was monitoring.


Nov, 2016 - Permalink

Dear all,

Thank you for your continued interest in clustered remote probes. To enhance the functionality of remote probes and to make them "clusterable" will take a lot of coding as well as testing effort. Unfortunately, just a small amount of our customers would benefit from this feature (considering the total number of PRTG deployments worldwide), therefore I can only confirm Aurelio's previous statement: It is highly unlikely that this will be implemented in the near future.

We do understand this feature request and comprehend this need, but for now the best approach would be to deploy additional failover nodes, though it will require additional licenses.

Sincerely,
Sebastian Kniege


Dec, 2016 - Permalink

Almost 2 years has gone. Any update on this subject. It is great that you have an option to have a clustered core service. But we really need to have a solution to cluster our remote probes.


Sep, 2018 - Permalink

Dear SilverFoxen,

Thank you very much for your continuous interest in clustered Remote Probes. Unfortunately, this feature is still not realized because the reasons I mentioned in late 2016 did not really change. It would still require a lot of coding and testing and this feature is not really requested, I'm afraid.

Please excuse that I am not able to provide you with a more satisfactory answer.

Best regards,
Sebastian


Sep, 2018 - Permalink

I am very interested in this functionality too !

Kind regards, Jeff


Oct, 2018 - Permalink

We are also very interested in this feature. Using remote probes is now not an option for us because of the high availability requirements in our business. Because we have a very large segmented network infrastructure and because we can't open certain network ports due PCI regulations we need the usage of remote probes.


Nov, 2018 - Permalink

Sorry Paessler we are not going to let this one go. Count me in for this feature. I would also be happy to test this for you as well.


Apr, 2020 - Permalink

I may have an easy solution for the PRTG developers. I think about this issue a great deal. I live in the enterprise IT world, and we have at least two of everything. Power feeds going into our building, generators, cluster of everything. I sit in front of PRTG and look at my single remote probe, and it sticks out at me like a splinter. I understand gutting and replacing the core of PRTG turns your stomach. It would for me as well after decades of development.

Here is my simple solution:

Let’s make a mechanism that will automatically move sensors to another probe based on probe health. If a probe disappears, move the sensors to a designated “backup” probe. Understandably Active/Active would require a great deal of changes, but perhaps this rudimentary method I offer will be a good compromise for those of us that absolutely must have two of everything.


Aug, 2020 - Permalink

Hi, new to the forum, but am keen to look at this. We need the ability either to have active/active or active/passive remote probes for monitoring, or a way of quickly and easily transferring the configuration between an active and a standby remote probe.

Is there any easy way of doing this, or is there any progress on looking at this as a new feature as this appears to be something that is in demand.

Regards,

SiW


Mar, 2022 - Permalink

Hello,

the current cluster feature has overall not especially high usage rates, for clustered probes we anticipate even less use.

As the historic data and sensor configuration for all probes is stored on the core server anyway, it is relatively easy to manually replace a remote probe: Add a new, confirm it, move the device groups from the old probe to the new.


Apr, 2022 - Permalink