☰

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

tag-icon • tag-icon snmp opennms
NET-SNMP 可能会遇到报告分区大于 2TB 的问题

我们最近将我们的一台 MYSQL 机器升级为 2.5TB 的阵列。

这样做之后，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 中。

从我的谷歌搜索来看，这似乎是一个常见问题，但我找不到任何解决方案。

有人知道解决办法吗？

答案1

这实际上不是一个答案，但是对于评论来说它太大了。

  • Linux 2.6.26-gentoo-r4 #10 SMP 2009 年 1 月 17 日星期六 22:38:48 EST i686 Intel(R) Celeron(R) CPU E1200 @ 1.60GHz 正版 Intel GNU/Linux
  • NET-SNMP版本：5.4.2.1
  • 逻辑卷大小：3.4TB

我没有遇到任何问题。但我不确定 snmpd 是否编译为 64 位。不过我很乐意为您做任何 (非侵入式) 检查。

答案2

我在另一个平台上遇到了这个问题。我发现您的日志告诉了您，它返回的值超过了有符号 32 位整数的最大值。特定的 SNMP 守护程序返回负数，这就是我发现它是有符号/无符号整数问题的原因。在我的脚本中，我进行了数学运算，将有符号整数转换为无符号整数，这将使我能够监视这个最大 4TB 的特定卷。此时，我几乎运气不佳。

至于解决方法……听起来它不会让您获得原始值，因此您可能必须编写一个脚本，该脚本将在查询特定 OID 时执行。此脚本将返回卷的 KB 值，而不是 B 值。这应该可以让您达到 16TB，然后才会达到最大值。

在您的 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 位整数的值。当然，您必须编写该脚本。它应该只返回一个整数。

相关内容