我们最近升级了一台2.5TB的MYSQL机器。
这样做后，OpenNMS停止报告有关我们的MySQL数据分区的信息…
当我做一个：
snmpwalk -v 1 localhost -c public .1.3.6.1.4.1.2021.9 我在/ var / log / messages中得到了这个
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中填充。
从我的谷歌search它看起来像一个共同的问题，但我找不到任何解决scheme。
任何人都知道工作？
这不是一个真正的答案，但它太大了评论。
我没有问题。 我不确定snmpd是否被编译为64bit。 我很乐意做任何你喜欢的（非侵入性）检查。
我在另一个平台上遇到了这个问题。 我发现什么是你的日志告诉你，它返回的值超过了有符号的32位整数最大值。 特定的SNMP守护进程正在返回负数，这是我怎么知道它是签署/无签名的Int问题。 在我的脚本中，我做了math转换一个有符号的整数到一个无符号整数，这将让我监测这个特定的音量高达4TB。 在这一点上，我几乎不走运。
至于解决方法…听起来不像是让你获得原始值，所以你可能不得不编写一个脚本，在查询特定的OID时执行。 该脚本将返回卷的KB值，而不是B值。 在达到最大值之前，最多可以达到16TB。
在你的snmpd.conf文件中，input一些类似的东西（我从一些vmware笔记中挑逗，所以你使用的OID应该是别的）：
exec .1.3.6.1.4.1.6876.99999.2.0 sqlvolspace /usr/local/script/sqlvolspace /dev/mapper/volname
然后当你查询这个OID时，你会得到一个适合32位整数的值。 当然，你必须写这个脚本。 它应该只返回一个整数。