Hi,
I'm having doubts according the data request of the Nagios.
For example if I´m using the Check_esx3.pl plugin for vmware data. I'm trying to care the production vcenter of I/O request.
If i have near to 1000 VM on my vcenter environment. And I configured to take all vm with the check_esx3.pl every 5 min.
This mean that for each guest the Nagios going to get 5 services (VM Status, Memory, Netwotrking, CPU Usage and I/O).
Calculating this is:
1000(VM) * 5 (metric/VM) = 5000 Consult
Those 5000 [cons] / 5 [Min] = 1000 [Cons/Min]
Now my question is how Nagios distribute those 1000[Cons/Min] ??
I whish that this mean 1000 [Cons/Min] / 60[Seg/Min] = near to 17 [Cons/Seg] to the vcenter.
Well if can you guide me on how to calculate this because i have some other applications running to vcenter and i dont want to charge the vcenter and collapse by I/O request.
Understanding Nagios XI read request
-
sreinhardt
- -fno-stack-protector
- Posts: 4366
- Joined: Mon Nov 19, 2012 12:10 pm
Re: Understanding Nagios XI read request
If I am understanding this correctly, you are looking to monitor around 1k virtual machines with ~5 checks per machine, from a single Nagios XI host. While this may be possible, your math does seem to be correct and as such I would advise against running these solely from one host. The main issue you would run into would not necessarily be crippling the vcenter server, although it would not be easy on it, but instead crippling Nagios. The check_esx3.pl plugin is quite resource intensive and lengthy to run regardless of what check you are using. The only reason I am not sure it will completely down the vcenter machine is that I don't believe too much is actually run there when a check is called.
You would like be better off doing one of a few different options:
1) Identifying what hosts you cannot monitor through other means like local agents, snmp, or wmi checks and use the check_esx only on those and the host machine. Otherwise use the alternative check mechanisms to avoid overloading both nagios and the vcenter server.
2) Instead of using the vcenter server as the monitoring check point, you can use each individual vmware host and monitor it or its guests individually. This will avoid DOSing your vcenter machine, however will still be a dramatic load on your nagios machine.
3) If you insist on doing something similar to option 2, I cannot recommend enough, looking into a mod gearman distributed setup. This will allow nagios to accept checks from mod gearman, and avoid nagios from having to do all the forks. You can setup multiple servers to do the gearman checks, and have them report back without overloading nagios or the vmware infrastructure if you combine this with option 2.
You would like be better off doing one of a few different options:
1) Identifying what hosts you cannot monitor through other means like local agents, snmp, or wmi checks and use the check_esx only on those and the host machine. Otherwise use the alternative check mechanisms to avoid overloading both nagios and the vcenter server.
2) Instead of using the vcenter server as the monitoring check point, you can use each individual vmware host and monitor it or its guests individually. This will avoid DOSing your vcenter machine, however will still be a dramatic load on your nagios machine.
3) If you insist on doing something similar to option 2, I cannot recommend enough, looking into a mod gearman distributed setup. This will allow nagios to accept checks from mod gearman, and avoid nagios from having to do all the forks. You can setup multiple servers to do the gearman checks, and have them report back without overloading nagios or the vmware infrastructure if you combine this with option 2.
Nagios-Plugins maintainer exclusively, unless you have other C language bugs with open-source nagios projects, then I am happy to help! Please pm or use other communication to alert me to issues as I no longer track the forum.