NET-SNMP可能遇到了报告大于2TB的分区的问题。

Question

最近，我们用2.5TB的数组对MYSQL机器进行了升级。

这样做之后，OpenNMS停止报告有关mysql数据分区的信息.

当我做一个：

snmpwalk -v 1 localhost -c public .1.3.6.1.4.1.2021.9

我在/var/log/消息中得到了这个

Aug  3 16:44:11 mysql6 snmpd[8789]: Connection from UDP: [127.0.0.1]:47333 
Aug  3 16:44:11 mysql6 snmpd[8789]: truncating signed value to 32 bits (10) 
Aug  3 16:44:11 mysql6 snmpd[8789]: truncating signed value to 32 bits (10) 

当我从snmpd.conf上移除分区时，我没有收到任何通知.其余的资源数据是在OpenNMS中填充的。

从我的googling上看，这似乎是一个常见的问题，但我找不到任何解决方案。

有人知道附近有工作吗？

Answer 1

这不是一个真正的答案，但它太大了，不能发表评论。

• Linux2.6.26-gentoo-R4 #10 SMP 1月17日22:38:48 EST 2009 i686英特尔(注册商标) CPU E1200 @ 1.60GHz GenuineIntel GNU/Linux
• NET-SNMP版本: 5.4.2.1
• 逻辑卷大小: 3.4TB

我也没什么问题。不过，我不确定snmpd是否编译为64位。不过，我很乐意做任何(非侵入性的)检查。

Answer 2

我是在另一个平台上碰到这个的。我发现的是您的日志告诉您的，它返回的值超过了已签名的32位整数的最大值。特定的SNMP守护进程正在返回负数，这就是我如何发现它是签名/未签名的Int问题。在我的脚本中，我做了数学运算，将一个有符号整数转换为一个无符号整数，这将允许我最多监视这个4TB的特定卷。那样的话，我就很不走运了。

至于工作.这听起来不像是会让您获得原始值，因此您可能必须编写一个脚本，在查询特定OID时执行该脚本。此脚本将返回卷的KB值，而不是B值。这应该能让你在达到最大值之前达到16 to。

在您的snmpd.conf文件中，输入类似于以下内容的内容(我是从一些vmware注释中获得的，所以您使用的OID应该是其他的)：

exec .1.3.6.1.4.1.6876.99999.2.0 sqlvolspace /usr/local/script/sqlvolspace /dev/mapper/volname

然后，当您查询该OID时，您将得到一个符合32位整数的值。当然，你得写那个剧本。它应该只返回一个整数。