Cacti Windows Graphs Not Accurate

[the_sphynx]

I have been using Cacti for about 6 years now and it has never really treated me wrong (using the plugin arch as well).
I have recently upgraded to 0.8.7e and seem to be getting really spotty accuracy of my Windows graphs using the default 2000/XP host templates.
I have attached a screenshot of what some of my physical memory graphs look like but I do also have some Disk Space graphs that are wacky like this too. Has anyone run into this before or could anyone offer me some advice to make this more accurate? Right now I have some alerts that count on that value being correct and so I am getting a lot of false positives.

[BSOD2600]

Post a snmpwalk of .1.3.6.1.2.1.25.2.3.1. If the values are off there, then it's something wrong with the Windows SNMP agent.

[the_sphynx]

Posted snmpwalk (looks fine to me):

Code: Select all

dhrm-gentoo ~ # snmpwalk -v 2c -c xxx 10.101.64.115 .1.3.6.1.2.1.25.2.3.1
HOST-RESOURCES-MIB::hrStorageIndex.1 = INTEGER: 1
HOST-RESOURCES-MIB::hrStorageIndex.2 = INTEGER: 2
HOST-RESOURCES-MIB::hrStorageIndex.3 = INTEGER: 3
HOST-RESOURCES-MIB::hrStorageIndex.4 = INTEGER: 4
HOST-RESOURCES-MIB::hrStorageIndex.5 = INTEGER: 5
HOST-RESOURCES-MIB::hrStorageIndex.6 = INTEGER: 6
HOST-RESOURCES-MIB::hrStorageIndex.7 = INTEGER: 7
HOST-RESOURCES-MIB::hrStorageIndex.8 = INTEGER: 8
HOST-RESOURCES-MIB::hrStorageIndex.9 = INTEGER: 9
HOST-RESOURCES-MIB::hrStorageIndex.10 = INTEGER: 10
HOST-RESOURCES-MIB::hrStorageIndex.11 = INTEGER: 11
HOST-RESOURCES-MIB::hrStorageType.1 = OID: HOST-RESOURCES-TYPES::hrStorageRemovableDisk
HOST-RESOURCES-MIB::hrStorageType.2 = OID: HOST-RESOURCES-TYPES::hrStorageFixedDisk
HOST-RESOURCES-MIB::hrStorageType.3 = OID: HOST-RESOURCES-TYPES::hrStorageCompactDisc
HOST-RESOURCES-MIB::hrStorageType.4 = OID: HOST-RESOURCES-TYPES::hrStorageFixedDisk
HOST-RESOURCES-MIB::hrStorageType.5 = OID: HOST-RESOURCES-TYPES::hrStorageFixedDisk
HOST-RESOURCES-MIB::hrStorageType.6 = OID: HOST-RESOURCES-TYPES::hrStorageFixedDisk
HOST-RESOURCES-MIB::hrStorageType.7 = OID: HOST-RESOURCES-TYPES::hrStorageFixedDisk
HOST-RESOURCES-MIB::hrStorageType.8 = OID: HOST-RESOURCES-TYPES::hrStorageFixedDisk
HOST-RESOURCES-MIB::hrStorageType.9 = OID: HOST-RESOURCES-TYPES::hrStorageFixedDisk
HOST-RESOURCES-MIB::hrStorageType.10 = OID: HOST-RESOURCES-TYPES::hrStorageVirtualMemory
HOST-RESOURCES-MIB::hrStorageType.11 = OID: HOST-RESOURCES-TYPES::hrStorageRam
HOST-RESOURCES-MIB::hrStorageDescr.1 = STRING: A:\
HOST-RESOURCES-MIB::hrStorageDescr.2 = STRING: C:\ Label:  Serial Number 98ad5957
HOST-RESOURCES-MIB::hrStorageDescr.3 = STRING: D:\
HOST-RESOURCES-MIB::hrStorageDescr.4 = STRING: U:\ Label:DB_Disk_2  Serial Number 2c19a9f1
HOST-RESOURCES-MIB::hrStorageDescr.5 = STRING: V:\ Label:Quorum  Serial Number d2f330ee
HOST-RESOURCES-MIB::hrStorageDescr.6 = STRING: W:\ Label:Backups  Serial Number d6c7e77e
HOST-RESOURCES-MIB::hrStorageDescr.7 = STRING: X:\ Label:Logs_RAID10  Serial Number 70aadb79
HOST-RESOURCES-MIB::hrStorageDescr.8 = STRING: Y:\ Label:DB_Disk_1  Serial Number 388be1da
HOST-RESOURCES-MIB::hrStorageDescr.9 = STRING: Z:\ Label:MGD  Serial Number 288c8266
HOST-RESOURCES-MIB::hrStorageDescr.10 = STRING: Virtual Memory
HOST-RESOURCES-MIB::hrStorageDescr.11 = STRING: Physical Memory
HOST-RESOURCES-MIB::hrStorageAllocationUnits.1 = INTEGER: 0 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.2 = INTEGER: 4096 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.3 = INTEGER: 0 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.4 = INTEGER: 4096 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.5 = INTEGER: 512 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.6 = INTEGER: 4096 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.7 = INTEGER: 4096 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.8 = INTEGER: 4096 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.9 = INTEGER: 4096 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.10 = INTEGER: 65536 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.11 = INTEGER: 65536 Bytes
HOST-RESOURCES-MIB::hrStorageSize.1 = INTEGER: 0
HOST-RESOURCES-MIB::hrStorageSize.2 = INTEGER: 6550495
HOST-RESOURCES-MIB::hrStorageSize.3 = INTEGER: 0
HOST-RESOURCES-MIB::hrStorageSize.4 = INTEGER: 65535151
HOST-RESOURCES-MIB::hrStorageSize.5 = INTEGER: 1012031
HOST-RESOURCES-MIB::hrStorageSize.6 = INTEGER: 268434093
HOST-RESOURCES-MIB::hrStorageSize.7 = INTEGER: 26214055
HOST-RESOURCES-MIB::hrStorageSize.8 = INTEGER: 65535151
HOST-RESOURCES-MIB::hrStorageSize.9 = INTEGER: 170391406
HOST-RESOURCES-MIB::hrStorageSize.10 = INTEGER: 120718
HOST-RESOURCES-MIB::hrStorageSize.11 = INTEGER: 94196
HOST-RESOURCES-MIB::hrStorageUsed.1 = INTEGER: 0
HOST-RESOURCES-MIB::hrStorageUsed.2 = INTEGER: 4090756
HOST-RESOURCES-MIB::hrStorageUsed.3 = INTEGER: 0
HOST-RESOURCES-MIB::hrStorageUsed.4 = INTEGER: 28780398
HOST-RESOURCES-MIB::hrStorageUsed.5 = INTEGER: 13797
HOST-RESOURCES-MIB::hrStorageUsed.6 = INTEGER: 102839470
HOST-RESOURCES-MIB::hrStorageUsed.7 = INTEGER: 4013242
HOST-RESOURCES-MIB::hrStorageUsed.8 = INTEGER: 17473715
HOST-RESOURCES-MIB::hrStorageUsed.9 = INTEGER: 27969278
HOST-RESOURCES-MIB::hrStorageUsed.10 = INTEGER: 97254
HOST-RESOURCES-MIB::hrStorageUsed.11 = INTEGER: 90951
HOST-RESOURCES-MIB::hrStorageAllocationFailures.1 = Counter32: 0
HOST-RESOURCES-MIB::hrStorageAllocationFailures.2 = Counter32: 0
HOST-RESOURCES-MIB::hrStorageAllocationFailures.3 = Counter32: 0
HOST-RESOURCES-MIB::hrStorageAllocationFailures.4 = Counter32: 0
HOST-RESOURCES-MIB::hrStorageAllocationFailures.5 = Counter32: 0
HOST-RESOURCES-MIB::hrStorageAllocationFailures.6 = Counter32: 0
HOST-RESOURCES-MIB::hrStorageAllocationFailures.7 = Counter32: 0
HOST-RESOURCES-MIB::hrStorageAllocationFailures.8 = Counter32: 0
HOST-RESOURCES-MIB::hrStorageAllocationFailures.9 = Counter32: 0
HOST-RESOURCES-MIB::hrStorageAllocationFailures.10 = Counter32: 0
HOST-RESOURCES-MIB::hrStorageAllocationFailures.11 = Counter32: 0

My math went 65536*94196= "# of bytes" which is accurate (~6GB)

On the same note I did increase the SNMP timeout value to 2000ms on my Windows hosts that have this problem. These are all LAN connected devices over 1Gb+ connections so it is unlikely that the timeout is the culprit. I might not know until tomorrow if it really helped.
Let me know if you need anything else from me. Thanks for your help!

[BSOD2600]

Agreed, that snmpwalk looks alright.

Time for the slower diagnostic method. Change the cacti logging level to Medium. Watch the graph when it gets unrealistic numbers. Then go back to cacti.log and look what cacti got for the total/used memory for that host.

[the_sphynx]

It has been a while since I replied so I apologize.
This is still an issue that I am unable to pinpoint. I have reinstalled the SNMP agents on the Windows hosts as well as increased the SNMP timeout value to 5000 ms. It is only the Windows disk graphs that are erratic (both physical mem & disk usage). Things like processes, network, etc are just fine.
I suppose I might just have to live with it . I am thinking of moving my Cacti host to Windows rather than the current Gentoo because of this as well as WMI capabilities. Is there anything wrong with using Windows 2008 R2 to run Cacti that anyone is aware of?