[Solved] VMware - check_esx3.pl takes minutes to run.
Posted: Mon Dec 02, 2013 4:59 pm
I have been trying to get some vSphere hosts added to my monitoring environment using the check_esx3.pl script that is included with XI, however I am running into some issues.
The command that I am running is:
[root@statistics ~]# time /usr/local/nagios/libexec/check_esx3.pl -H "10.1.1.101" -f "/usr/local/nagiosxi/etc/components/vmware/Vmhost_auth.txt" -l CPU
ESX3 OK - cpu usage=7084.00 MHz (9.62%) | cpu_usagemhz=7084.00Mhz;; cpu_usage=9.62%;;
Test 1:
real 3m49.388s
user 0m0.594s
sys 0m0.045s
Test 2:
real 3m47.660s
user 0m0.387s
sys 0m0.037s
Test 3:
real 3m49.840s
user 0m0.576s
sys 0m0.038s
This behavior has been observed consistently over the past few weeks.
Even if I specify a timeout (such as '-t 30'), the command will continue to run past 30 seconds and return the result in the end.
I have tested hosts that are running ESXi 5.0, 5.1 with identical behavior.
ESXi 5.5 running the same script gives the following error, again at 3m48s.
[root@statistics ~]# time /usr/local/nagios/libexec/check_esx3.pl -H "10.1.1.104" -f "/usr/local/nagiosxi/etc/components/vmware/Vmhost_auth.txt" -l CPU
ESX3 CRITICAL - HOST CPU Unknown error
real 3m48.408s
user 0m0.395s
sys 0m0.031s
Due to the very long time to run, within Nagios the command will ultimately offer Status: (Service Check Timed Out).
OS: CentOS 6.5 (x86-64)
Nagios XI Version: 2012R2.7 Enterprise
Installation Source: VMDK
CPU: 4 Cores presented via vSphere on a dual socket AMD Opteron 6376 server.
Memory: 8GB presented via vSphere on a 128GB server.
Storage: 60GB presented via vSphere on a 4TB SSD server.
Load Average: 0.02, 0.03, 0.08
When I originally installed from VMDK, it was on a previous version of XI. I don't remember specifically.
After experiencing this issue for several weeks and not making headway, I upgraded to 2012R2.7 via the Source Installer and did a 'yum update' to go to CentOS 6.5.
I am not averse to re-installing if need be, or going with an alternate installation path.
Of note, no other service checks are experiencing this long execution time issue.
Any assistance on this matter would be greatly appreciated.
The command that I am running is:
[root@statistics ~]# time /usr/local/nagios/libexec/check_esx3.pl -H "10.1.1.101" -f "/usr/local/nagiosxi/etc/components/vmware/Vmhost_auth.txt" -l CPU
ESX3 OK - cpu usage=7084.00 MHz (9.62%) | cpu_usagemhz=7084.00Mhz;; cpu_usage=9.62%;;
Test 1:
real 3m49.388s
user 0m0.594s
sys 0m0.045s
Test 2:
real 3m47.660s
user 0m0.387s
sys 0m0.037s
Test 3:
real 3m49.840s
user 0m0.576s
sys 0m0.038s
This behavior has been observed consistently over the past few weeks.
Even if I specify a timeout (such as '-t 30'), the command will continue to run past 30 seconds and return the result in the end.
I have tested hosts that are running ESXi 5.0, 5.1 with identical behavior.
ESXi 5.5 running the same script gives the following error, again at 3m48s.
[root@statistics ~]# time /usr/local/nagios/libexec/check_esx3.pl -H "10.1.1.104" -f "/usr/local/nagiosxi/etc/components/vmware/Vmhost_auth.txt" -l CPU
ESX3 CRITICAL - HOST CPU Unknown error
real 3m48.408s
user 0m0.395s
sys 0m0.031s
Due to the very long time to run, within Nagios the command will ultimately offer Status: (Service Check Timed Out).
OS: CentOS 6.5 (x86-64)
Nagios XI Version: 2012R2.7 Enterprise
Installation Source: VMDK
CPU: 4 Cores presented via vSphere on a dual socket AMD Opteron 6376 server.
Memory: 8GB presented via vSphere on a 128GB server.
Storage: 60GB presented via vSphere on a 4TB SSD server.
Load Average: 0.02, 0.03, 0.08
When I originally installed from VMDK, it was on a previous version of XI. I don't remember specifically.
After experiencing this issue for several weeks and not making headway, I upgraded to 2012R2.7 via the Source Installer and did a 'yum update' to go to CentOS 6.5.
I am not averse to re-installing if need be, or going with an alternate installation path.
Of note, no other service checks are experiencing this long execution time issue.
Any assistance on this matter would be greatly appreciated.