Indeed, like an ESXi is intended to host vm's, Hyper-V server is intended to host VM's. I see PRTG as an application, and that should never run on a VMware or Hyper-V Server itself.
In my opinion a server restart which is self-triggered is not recommended. The automatic software update of PRTG is nice in a DTA environment, but not in an P environment. What if the update doesn't work that well ? And auto update is uncontrolled.
The recommendation to run PRTG on dedicated hardware: is that a truly good recommendation ? The market goes to a software defined data center, and services of the biggest vendors go virtual. Software defined storage and software defined networking. Why should a monitoring tool then be physical ?
We have 13,515 sensors in a virtual environment. A dedicated virtual master and failover cluster node. In the datacenter 4 remote probes for physical equipment, our core application, Citrix, and miscellaneous. On every location (23) we have one standalone ESXi, with a virtual remote probe, a virtual domain controller and virtual deployment server.
I more prefer that you guys give good recommendations regarding the workload of a sensor. Do not use auto-discovery but really think what you really want to monitor in big environments. Really think about what the impact on the systems are on a high scanning interval.
My colleagues implemented PRTG and done a great job. I implemented PRTGplugins. I'm fascinated by the possibilities and how to optimize PRTG, and hope a lot of PRTG clients will share there experience to do some knowledge sharing. My intention is to share some cool ways of monitoring, and maybe a reader has optimization recommendations for that.
Add comment