There is a thread from 2009 discussing swap space / virtual memory obtained from the host resources MIB - http://community.zenoss.org/message/25747#25747 . The collector plugin is implemented by $ZENHOME/Products/DataCollector/plugins/zenoss/snmp/HRFileSystemMap.py .
The end of the discussion pinpointed issues with Suse and Gentoo linux whereby they both report an hrStorageType of hrStorageVirtualMemory for filesystems where hrStorageDescr = Virtual memory and hrStorageDescr = Swap space . Apparently other versions of Linux only report on swap space - not virtual memory. Ticket 4222 was raised ( http://dev.zenoss.com/trac/ticket/4222 ) which resulted in Changeset 12161 ( http://dev.zenoss.com/trac/changeset/12161 ). This changset is simply 2 extra lines that test whether the descr OID has Virtual memory in it, and skip over if it has. This change certainly exists in Zenoss 2.5.2 and 2.5.1.
My Python isn't great but I think what this does is to ignore ALL results from the HR MIB where the hrStorageDescr contains this value.
In practice, it gives the correct value for Linux systems that report swap space with a description of "Swap space" but Windows systems have the HR MIB populate a Virtual Memory OID table with the sum of pagespace and RAM - it ain't great but it's a lot better than nothing (or installing Informant everywhere). There is no check in the new code that tests whether the MIB value is coming from specific operating systems so this is all trapped out by the Python code. You don't get a value under the hardware tab for Swap and, even if you modify the zFileSystemMapIgnoreTypes zProperty for devices to show virtualMemory, you don't get any values for Virtual Memory or Swap Space under the filesystems table in the OS tab, because the new HRFileSystemMap.py traps out any and all results that have a description of virtual memory.
Is this really what we want???
I have simply commented out the 2 new lines and re-modelled. I now have swap space values in my Hardware tab for all devices (Windows and Linux) - it is equal to RAM + pagefile. I can also see a Virtual Memory filesystem for all my Win devices. The Linux systems have the same - Swap on Hardware is swap+RAM and filesystems on the OS tab reports both Virtual memory (RAM + swap) and Swap space (actual swap space).
For me, this is more useful overall. What do others think? Should I reopen the ticket? Should I create my own data collector that has more selective code around filesystems of type virtualMemory?
After making the change described above I tested a few systems with a "Model device" - Swap in hardware was populated with the Virtual memory value and the OS filesystems table showed virtual memory and created graphs for it.
However, after a zenmodeler cycle happened overnight, everything has gone back to pre-the-change. Swap space under hardware is back at "Unknown" and there is no virtual memory filesystem.
If I manually remodel the device again then my VM parameters return and the VM filesystem graph shows data was collected up until the remodel cycle.
What is different about the way a modeler cycle runs versus manually remodelling???
Jane, did you ever figure this out?
Follow Us On Twitter »
||Latest from the Zenoss Blog »||Community||Products||Services||Customers||About Us|
Copyright © 2005-2011 Zenoss, Inc.