Unable to get CPU graph for some of the window servers.

[chandresh]

I am using cacti Version 0.8.8c installed in Linux SUSE 11 SP3 which is unable to generate CPU graph for few windows server 2008. It is working well for all other windows servers 2008 systems. Kindly let me know what can be the problem and how to solve it.

I have configured snmp version 2 as cacti community string as cacti.

All windows server 2008 configured with same OS version and same snmp version.

I have done analysis to get CPU graph for windows systems (PCEXXXC51 and PCEXXXC52). I found that snmp OID strings passed by cacti tool is unable to get required data from windows systems to reflect the CPU graphs on cacti dashboard. The same snmp OID starlings are working well for other windows systems and CPU graphs are displaying properly.

Please find below snmpwalk output as reference to compare between problematic and non-problematic system :

Example : OID - 1.3.6.1.4.1.9600.1.1.5.1.11 passed to get CPU Interrupts Per Sec.


Output for PCEXXXC32 - 10.203.111.241 :-

cacti01:/srv/www/cacti/resource/snmp_queries # snmpwalk -v 2c -c cacti 10.203.111.241 .1.3.6.1.4.1.9600.1.1.5.1.11 <---- No problem on this windows server 2008, Hostname is PCEXXXC32.
SNMPv2-SMI::enterprises.9600.1.1.5.1.11.1.48 = Gauge32: 1438
SNMPv2-SMI::enterprises.9600.1.1.5.1.11.1.49 = Gauge32: 3067
SNMPv2-SMI::enterprises.9600.1.1.5.1.11.1.50 = Gauge32: 2104
SNMPv2-SMI::enterprises.9600.1.1.5.1.11.1.51 = Gauge32: 1516
SNMPv2-SMI::enterprises.9600.1.1.5.1.11.6.95.84.111.116.97.108 = Gauge32: 8125
cacti01:/srv/www/cacti/resource/snmp_queries #

Output for PCEXXXC51 - 10.203.111.121
qcexcacti01:/srv/www/cacti/resource/snmp_queries # snmpwalk -v 2c -c cacti 10.203.111.121 .1.3.6.1.4.1.9600.1.1.5.1.11
SNMPv2-SMI::enterprises.9600.1.1.5.1.11 = No more variables left in this MIB View (It is past the end of the MIB tree) <------------------------ This is the problem, I am not getting proper snmp output from this windows systems. Hostname is PCEXXXC51.

Output for PCEXXXC52 - 10.203.111.122
qcexcacti01:/srv/www/cacti/resource/snmp_queries # snmpwalk -v 2c -c cacti 10.203.111.122 .1.3.6.1.4.1.9600.1.1.5.1.11
SNMPv2-SMI::enterprises.9600.1.1.5.1.11 = No more variables left in this MIB View (It is past the end of the MIB tree)

[netniV]

Not a lot we can do about that I am afraid. Microsoft don't even support SNMP and seem to have removed it from newer Windows 10 machines in favour of their slowly and less helpful WMI. You may find that you get better results using third party SNMP services

[chandresh]

Not a lot we can do about that I am afraid. Microsoft don't even support SNMP and seem to have removed it from newer Windows 10 machines in favour of their slowly and less helpful WMI. You may find that you get better results using third party SNMP services

The same snmp version is working on more than 10 windows server 2008 but not working for only 2 systems. I have compared cacti configuration as well which is identical between working and not working systems.

[netniV]

Still doesn't change the facts though. It's basically unsupported.

[TheWitness]

Microsoft sniffing glue as normal. Why does anyone run Windoz on a server platform any more. Honestly, just drives me nuts. Get yourself a Third Party SNMP and next time you see a Microsoft Employee give them both barrels of your disdain.

[dagonet]

Not a lot we can do about that I am afraid. Microsoft don't even support SNMP and seem to have removed it from newer Windows 10 machines in favour of their slowly and less helpful WMI. You may find that you get better results using third party SNMP services

Well it might be correct that they removed SNMP from Windows 10 because it's a client operating system. So it's not necessary.
SNMP is still alive and supported on Windows Server 2019. So basiclly it's supported.
Reading is better than guessing.

@TheWitness: People run Windows on Servers because they know what to do and linux is not the holy grail which some linux disciples believe. Well FreeBSD is.

@chandresh: It's pretty clear what the cause is. Your OID is a vendor spectic OID and is most likely not present on the two Windows Server where it's not working.
Maybe some vendor specific software is absent
Try the HOST MIB (https://www.oidview.com/mibs/0/HOST-RESOURCES-MIB.html) or check your SNMP tree for CPU entries.
Just walk the whole SNMP tree and search.