RHEL4自带SNMP信息BUG问题

由于linux系统CPU使用情况与Windows不同，造成很难通过Used来判断CPU的使用情况，唯一的办法只有通过Idle的空间情况来决定CPU的使用情况。

SNMPWALK读取LINUX CPU的信息

snmpwalk -c public -v1 XXX.XXX.XXX.XXX .1.3.6.1.4.1.2021.11
UCD-SNMP-MIB::ssIndex.0 = INTEGER: 1
UCD-SNMP-MIB::ssErrorName.0 = STRING: systemStats
UCD-SNMP-MIB::ssSwapIn.0 = INTEGER: 0
UCD-SNMP-MIB::ssSwapOut.0 = INTEGER: 0
UCD-SNMP-MIB::ssIOSent.0 = INTEGER: 0
UCD-SNMP-MIB::ssIOReceive.0 = INTEGER: 1
UCD-SNMP-MIB::ssSysInterrupts.0 = INTEGER: 1
UCD-SNMP-MIB::ssSysContext.0 = INTEGER: 1
UCD-SNMP-MIB::ssCpuUser.0 = INTEGER: 2
UCD-SNMP-MIB::ssCpuSystem.0 = INTEGER: 6
UCD-SNMP-MIB::ssCpuIdle.0 = INTEGER: 91
UCD-SNMP-MIB::ssCpuRawUser.0 = Counter32: 114245222
UCD-SNMP-MIB::ssCpuRawNice.0 = Counter32: 11338
UCD-SNMP-MIB::ssCpuRawSystem.0 = Counter32: 286072807
UCD-SNMP-MIB::ssCpuRawIdle.0 = Counter32: 4294967295
UCD-SNMP-MIB::ssCpuRawWait.0 = Counter32: 15060660
UCD-SNMP-MIB::ssCpuRawKernel.0 = Counter32: 285410727
UCD-SNMP-MIB::ssCpuRawInterrupt.0 = Counter32: 662080
UCD-SNMP-MIB::ssIORawSent.0 = Counter32: 1224085090
UCD-SNMP-MIB::ssIORawReceived.0 = Counter32: 738120092
UCD-SNMP-MIB::ssRawInterrupts.0 = Counter32: 4294967295
UCD-SNMP-MIB::ssRawContexts.0 = Counter32: 4294967295
UCD-SNMP-MIB::ssCpuRawSoftIRQ.0 = Counter32: 0
UCD-SNMP-MIB::ssRawSwapIn.0 = Counter32: 0
UCD-SNMP-MIB::ssRawSwapOut.0 = Counter32: 159

其中IDLE值为
UCD-SNMP-MIB::ssCpuRawIdle.0 = Counter32: 4294967295

使用ZENOSS得到IDLE图值却是0


就其原因到ZENOSS官方论坛查找，结论如下：

Why is my ssCpuRawIdle data point always 0?

This is a known bug in Net-SNMP. After a system has been on and idle long enough the ssCpuRawIdle counter will reach the limits of a 32bit integer and stop incrementing instead of rolling over to 0. The solution is to upgrade NetSNMP or stop collecting ssCpuRawIdle.

原来是个SNMP的BUG
我们用的系统是RHEL4U4，SNMP为自带的net-snmp-5.1.2-11.EL4.11.i386.rpm
RedHat的BUG说明

根据说明提示，找到net-snmp-5.1.2-13.el4.i386.rpm版本，注意，一般系统安装中，有两个SNMP包必需安装，一个是SNMP包一个是LIB包，所以，升级的时候，也需要同时下载与升级两个包
下载地址：


下载及

RPM －Uvh升级安装，然后重启SNMP服务
取出手IDLE值为：
UCD-SNMP-MIB::ssCpuRawIdle.0 = Counter32: 3108845392
看来是原来的BUG是大无限BUG（＠＠）
现在看看出来的结果：



此问题原于RHEL4系列中的SNMP BUG，不属于监控软件BUG，对于使用Cacti，Zenoss等用户，如果你的客户端 也是RHEL4系列的操作系统，如果如现IDLE值有问题时候，都可以借鉴本方法。