PRTG Enterprise Monitor - No downtime during updates
For PRTG Enterprise Monitor, with a cluster, there should be no downtime during updates but due to the automatic update process, there is a documented downtime requirement.
If the communication path and protocol between the master-node, failover and remote probes remain static, then should be able to update the master-node and failover node independently of each other, thus not requiring a downtime, no matter how brief.
Or have a node within the Cluster that is independent of the master-node and failover node, that is not updated automatically to maintain monitoring and also provide for a way to revert in case the update is faulty or is not operational.
Hi there,
Thank you again for submitting your idea to Paessler. We truly appreciate you taking the time to share your feedback.
We will not be enhancing the existing cluster mode the way it exists today. We are launching a new PRTG Database later this year, and we will have a far more robust clustering capability next year based on PostgreSQL based replication. Please get back in touch if you have additional feedback for the team.
After careful consideration by our team, we've decided to decline this idea at this time. This decision was made based on several factors, which may include:
- It doesn't align with our current product roadmap or strategic priorities.
- The resources required for implementation outweigh the current projected benefits for our user base.
- There are technical limitations that prevent us from moving forward.
- A similar feature is already available or planned in a different way.
While this particular idea won't be moving forward, please don't be discouraged! Your input is incredibly valuable, and we encourage you to continue sharing your thoughts and ideas with us.
Thanks for your understanding and for helping us shape the future of Paessler.
Best regards,
The Paessler Product Team
-
Billy Cole
commented
For PRTG Enterprise Monitor, with a cluster, there should be no downtime during updates but due to the automatic update process, there is a documented downtime requirement.
If the communication path and protocol between the master-node, failover and remote probes remain static, then should be able to update the master-node and failover node independently of each other, thus not requiring a downtime, no matter how brief.
Or have a node within the Cluster that is independent of the master-node and failover node, that is not updated automatically to maintain monitoring and also provide for a way to revert in case the update is faulty or is not operational.