Cheshire Cat Computing

Hello

I'm successfully using check_esx2 (Version 2.4) for some months.
Now I tried to monitor an ESX Server (Version 3.0.1) over the WAN, the Network link is not really fast, but good enough to do the most.

It seems that the check_esx2 plugin has problem over a "slow" Network link, often I had snmp timeout problems. The execution time was about 1 minute.
Then I applied a recently published ESX patch concerning snmp timeout problems, but now it is much worse than better. Now the check takes 2 minutes and and the Nagios status output is "Service Check Time Out". I know a can increase the Timeout value in nagios.cfg, but I think this is not the idea if a plugin takes so much time.

Is there a way to improve the execution time? Or is it a "usual" SNMP problem?
The ping response of the remote ESX Server takes 450 ms. Other snmp checks e.g. disk usage of a mountpoint takes 5 seconds.
Therefore I cannot understand why it takes 2 minutes.

Thanks!
Peter

The plugin will run several snmp checks and download a lot of information, including running the remote plugin to collect more.

To identify the slow part, try running the /etc/snmp/vmware-stats script as root on the esx server. Does it take a long time to run (ie, more than a couple of seconds)? Then, try to snmpwalk the 1.3.6.1.4.1.2021.1000 tree. Is this quick (ie, a couple of seconds)? This checks the SNMP daemon. Finally, try to snmpwalk the 1.3.6.1.4.1.6876 tree. If this times out, then you have a problem with the vmware SNMP agent plugin.

I believe the plugin and SNMP daemon architecture is done slightly differently in ESX3, but I do not have an ESX3 server handy to test this with yet. Under ESX2 there were occasional problems with the agent locking up, which is why I have tried to move away to using just the vmware-stats plugin in the new check_esx 2.5 (since I cant rely on the vmware OID tree).

_________________
Steve Shipway
UNIX Systems, ITSS, University of Auckland, NZ
Woe unto them that rise up early in the morning... -- Isaiah 5:11

I see, there are really a lot of information loaded during the query.

When I run vmware-stats script on the ESX it takes some ms to get the output, it's fast as it should be.

From remote, when I try a snmpwalk to the x.1000 tree it takes about 90 seconds, I got back 3 values (lines) per second.
The snmpwalk to the x.6876 tree takes much longer, of course more data. But the speed is the same and no timeout problems.

I'm monitoring a ESX 2.5x Server in the same location too. It's not better with the performance. I suppose the Network link is not fast enough or probably the respons time is bad, on a ping the response time is on average 400 ms.

From my point of view there is no chance to have it better as long the Network link is not faster.
Maybe in the future you're going to change the scripts to query only e.g. the CPU data or a passive check on the ESX (cron job or daemon) and transmitting the result to Nagios.

Thanks for you help!

The new version of the script uses the vmware-stats output almost exclusively, and only falls back to using the vmware OID tree when the data cannot be obtained in another way (eg, network and HBA throughputs). This works out as faster and more efficient.

_________________
Steve Shipway
UNIX Systems, ITSS, University of Auckland, NZ
Woe unto them that rise up early in the morning... -- Isaiah 5:11

You're speaking about a new script. Do you mean the current version 2.4 or are you developing an update?

A v2.5 exists although not in general release, which is an attempt to correctly support ESX3 as well as ESX2.x. This is due for release once we have a proper ESX3 test server for me to verify it on.

_________________
Steve Shipway
UNIX Systems, ITSS, University of Auckland, NZ
Woe unto them that rise up early in the morning... -- Isaiah 5:11