Nov 10, 2011 5:25 AM
ESX Server monitoring won't work
-
Like (0)
Hi,
My Zenoss version is 3.2.1 running on Ubuntu 10.04 x64.
Monitored hosts are running ESX 4.1.0.
I've followed steps mentionned below from Chapter 17 (VMware Infrastructure ESX Server) instructions in Zenoss Extended Monitoring 3.0 documentation but nothing specific to ESX will show up on my ESX device page (see attachment).
/usr/bin/python: /usr/local/zenoss/common/lib/libcrypto.so.0.9.8: no version information available (required by /usr/bin/python)
/usr/bin/python: /usr/local/zenoss/common/lib/libssl.so.0.9.8: no version information available (required by /usr/bin/python)
Traceback (most recent call last):
File "/usr/lib/command-not-found", line 10, in <module>
import CommandNotFound
ImportError: No module named CommandNotFound
I finally modeled the device but nothing new appeared on the device page.
My guess is that the check_esxtop command error could be a clue but I don't know how to fix it.
Thanks for your help.
Hi there
did you get this isue fixed? I am having similiar problems I believe but i think the issue relates to the version of vsphere CLI client.
what does your zmodeler show ( mine below with debug) note the '
Differing number of param names vs values received ' when I look at our old server less parameters are returned from the ESX host.
Old server returns:
Members 0 Used 0.00 Run 0.00 System 0.00 Wait 0.00 Ready 0.00 Idle 0.00 Overlap 0.00 CoStop 0.00 Max Limited 0.00 Swap Wait 0.00 Switches_sec 0.00 Migrates_sec 0.00 Processor Migrations_sec 0.00 Wakeup Migrate Idle_sec 0.00 Quantum Expires_sec 0.00 Wakeups_sec 0.00 Alloc Min 0 Alloc Max 0 Alloc Shares 0 Alloc Min Limited 0 Timers_sec 0.00
New Server with Vsphere 5
Members 0 Used 0.00 Run 0.00 System 0.00 Wait 0.00 Ready 0.00 Idle 0.00 Overlap 0.00 CoStop 0.00 Max Limited 0.00 Swap Wait 0.00 Switches_sec 0.00 Migrates_sec 0.00 Processor Migrations_sec 0.00 Wakeup Migrate Idle_sec 0.00 Quantum Expires_sec 0.00 Wakeups_sec 0.00 Alloc Min 0 Alloc Max 0 Alloc Shares 0 Alloc Min Limited 0 CPU Latency 0.00 Memory Latency 0.00 Demand 0 Effective Min (MHz) 0 Timers_sec 0.00 Power Usage Watts 0
Is yours similiar?
2012-02-21 11:36:28,700 DEBUG zen.PythonClient: Results for zenoss.cmd.esx.esxtop: ERROR: Differing number of param names vs values received
2012-02-21 11:36:28,700 INFO zen.PythonClient: Python client finished collection for NLESX01
2012-02-21 11:36:28,701 DEBUG zen.ZenModeler: Client for NLESX01 finished collecting
2012-02-21 11:36:28,701 DEBUG zen.ZenModeler: Processing data for device NLESX01
2012-02-21 11:36:28,701 DEBUG zen.ZenModeler: Processing plugin zenoss.cmd.esx.esxtop on device NLESX01 ...
2012-02-21 11:36:28,701 DEBUG zen.ZenModeler: Plugin zenoss.cmd.esx.esxtop results = ERROR: Differing number of param names vs values received
2012-02-21 11:36:28,701 ERROR zen.ZenModeler: ERROR: Differing number of param names vs values received
2012-02-21 11:36:28,701 INFO zen.ZenModeler: No change in configuration detected
Hi Nathan.
I'm not using this particular ZenPack, but your error "Differing number of param values" sounds like something I ran into elsewhere. Is there a ".esxtop4rc" (or perhaps .resxtoprc for the resxtop executable) file in the Zenoss user's home directory? That RC file is used to control which parameters are output by esxtop/resxtop, and is usually configured fron inside an interactive session of resxtop.
If nobody else gives you a better option, I'd look in the ZenPacks modeler/plugin directory, and see what it's expecting to find from the resxtop output, and the double-check that against what's displayed in an interactive resxtop session. Add or subtract fields in the interactive session output to match what the plugin was searching for...
--Jay
Hi Jay
It appears to run check_esxtop - -Server=<Name> - -user=<Name> - -showvms
if i run this on the CMD line directly I get ERROR: No valid data received, removing cache file '/tmp/.nlesx01.cache'
looking at check_esxtop this appears to refer to this line
# Pick a category that shows the system names | |
matchRegex = ".*Group Cpu\([0-9]+:([^)]*)\)" |
to be honest i am getting a bit lost here, I don't get it
Can anyone give us a couple of pointers on this one? I don't know perl or Python
cheers
Nathan
Hi Nathan.
OK, I was looking thru the code, and it seems to get tripped up here:
249 | try: |
---|---|
250 | names = data[0].split(',') |
251 | values = data[1].split(',') |
252 | except IndexError: |
253 | print "ERROR: No valid data received, removing cache file '%s'" % ( |
254 | cacheFile) |
255 | # ... and the cache file is busted |
256 | os.unlink(cacheFile) |
257 | sys.exit(1) |
259 | if len(names) != len(values): |
260 | print 'ERROR: Differing number of param names vs values received' |
---|---|
261 | # ... and the cache file is busted |
262 | os.unlink(cacheFile) |
263 | sys.exit(1) |
...so it's parsing the output of the resxtop command, and treating each line as a comma separated list. And, it's decided that there's one too many commas someplace. Unfortuneately, it then deletes the output file so you can't see what it was working on.
I'd try this: navigate your way to the check_esxtop.py command, and make a backup copy of it (cp check_esxtop.py check_esxtop.bak). Then edit check_esxtop.py and add a # at the beginning of line 262
# os.unlink(cacheFile)
and put another # at the start of line 256
# os.unlink(cacheFile)
then save the file -- this should comment out the bit that deletes your temp file. Then you should be able to run the modeler again, have it fail again, but keep your /tmp/.nlesx01.cache file.
With luck you can see what's in the cache file and figure out if it's got a missing (null) value someplace, or an extra comma in the line with all the value names (which would trigger the error at line 260), or if you got an unexpected number of lines of output (the error at line 253).
--Jay
hello there
Thank you for taking a look, I have resolved the issue by installing vSphere CLI version 4, it appears version 5 has some extra values returned which stops this pack from working correctly.
I am afraid my Python knowledge is hopeless so this was the best option for us.
Follow Us On Twitter »
|
Latest from the Zenoss Blog » | Community | Products | Services Resources | Customers Partners | About Us | ||
Copyright © 2005-2011 Zenoss, Inc.
|
||||||||