☰

Snmpd 更新接口计数器缓慢或类似情况

tag-icon • tag-icon monitoring freebsd snmp zabbix net-snmp
Snmpd 更新接口计数器缓慢或类似情况

我将我的一个 freebsd 盒子更新到 9-stable（全新安装）并安装 net-snmp 进行监控。

uname -r 
9.1-PRERELEASE

pkg_info net-snmp-5.7.1_7 
Information for net-snmp-5.7.1_7:

Comment:
An extendable SNMP implementation
....


cat /var/db/ports/net-snmp/options 
# This file is auto-generated by 'make config'.
# Options for net-snmp-5.7.1_7
_OPTIONS_READ=net-snmp-5.7.1_7
_FILE_COMPLETE_OPTIONS_LIST= IPV6 MFD_REWRITES PERL PERL_EMBEDDED PYTHON DUMMY TKMIB DMALLOC MYSQL AX_SOCKONLY UNPRIVILEGED
OPTIONS_FILE_UNSET+=IPV6
OPTIONS_FILE_UNSET+=MFD_REWRITES
OPTIONS_FILE_SET+=PERL
OPTIONS_FILE_SET+=PERL_EMBEDDED
OPTIONS_FILE_UNSET+=PYTHON
OPTIONS_FILE_SET+=DUMMY
OPTIONS_FILE_UNSET+=TKMIB
OPTIONS_FILE_SET+=DMALLOC
OPTIONS_FILE_UNSET+=MYSQL
OPTIONS_FILE_UNSET+=AX_SOCKONLY
OPTIONS_FILE_UNSET+=UNPRIVILEGED

我在这台机器上有大约 500 个 vlan，并通过 snmpd 收集有关接口的信息到两个不同的软件，zabbix 和 cacti。

并且它们都绘制了空白字段的图形。

扎比克斯 仙人掌

我尝试将 zabbix 中的轮询时间从 15 秒更改为 30、60、90、120、10。但无论如何，我的字段都是空白的。

snmpd.conf 为空 – 仅有访问控制。

此配置在 freebsd 8 上运行良好。

我的错在哪里？如何修复此图表？

更新： 更改池时间，关闭其中一个代理，都没有帮助。我查看了 zabbix 日志（从 snmpd 接收的数据）并看到：抱歉，对于俄语语言环境，请只查看数字： zabbix数据

但事实并非如此，因为我的“iftop”显示速度约为 90Mbits，但 snmpd 返回 2Mbits。

我知道 snmpd 不返回速度，它只返回一个计数器。但这怎么可能呢？为什么是 2Mbit/s？

我尝试重新编译带有 64 位计数器的 snmpd 和不带有 64 位计数器的 snmpd。在这两种情况下，都存在此空白字段。

所以我认为是我的操作系统（freebsd）不能很好地更新接口计数器。

我仍然收集 tcpdump 以找到此请求/响应。但是这样做存在问题，垃圾太多。

更新2： 我解密了 tcpdump 文件，并将其作为 google doc 公开在gdoc文件

Timediff 看起来很奇怪.. 就像 zabbix 有时会“忘记”执行请求，然后连续执行两次，呃

更新3： 我从命令“while true; do netstat -bin -I vlan4008 >> /var/log/netstat; sleep 300; done”解析日志并将其加载为谷歌文档，并添加速度公式：关联

看起来操作系统中的所有计数器都很好。现在我认为问题在于：1. zabbix 连续两次获取请求（cacti 怎么样）2. snmpd 使用 counter32

答案1

这通常与未及时收到 SNMP 响应有关。
由于 SNMP 使用 UDP，这可能意味着网络拥塞或主机拥塞导致请求/回复丢失，但更常见的情况是所涉及的两台机器中的一台无法及时处理请求，而另一台机器厌倦了等待。

一台机器或另一台机器落后的可能性会随着工作量的增加而增加——如果您有大量 SNMP 代理查询特定主机，则可能无法像某些代理期望的那样及时提供回复（并且这些代理将在图表中显示空白点，或报告其他错误）。
相反，如果您有一个代理查询一堆主机 - 超过它在轮询间隔内可以处理的数量 - 在轮询间隔内未被查询的机器将在其图表中出现空白。（这个问题在 Cacti 的 PHP 轮询器中尤为常见，并导致了cactid（现在的spine）的开发，如果您还没有使用它，我强烈建议您使用它）。

我对解决这个问题的一般建议是：

  1. 如果可能的话，每 5 分钟轮询一次。
    大多数环境不需要 1/5/15/30/60/90/120 秒的轮询间隔。
    如果五分钟的粒度对你来说足够好，那就坚持下去。这对你的服务器来说工作量更少，对你的 SNMP 监控代理来说工作量更少，需要存储的数据也更少（或者在“全粒度”下存储的时间更长）

  2. 增加代理上的 SNMP 超时时间。
    让服务器有更多时间处理您的请求。SNMP 守护进程是进程中的懒惰少年 - 您要求它们在星期一打扫房间（或给您一棵树的数据），而在星期三或星期四它们可能已经捡起了几只袜子。

  3. 限制每次轮询时对服务器的要求。
    如果您只需要一个计数器，则不要请求整个接口 MIB——它（通常）需要更长的时间来遍历树并生成完整输出，而不是只给您一个 OID。

  4. 限制请求数据的代理数量。
    如果您可以将监控整合到一个框（Zabbix 或 Cacti），您对服务器的要求就会减少，服务器不及时响应的可能性也会降低。

如果尝试上述方法后仍然遇到问题，那么还有最终的调试步骤：搜寻你的日志和嗅探 SNMP 流量确保请求和响应及时来回，不会因为某种原因丢失/被拒绝为格式错误。经常查看线路上的数据可以很好地指示哪里出了问题以及如何修复它。

答案2

您使用哪个版本的 SNMP 协议？SNMP v1 不支持 64 位计数器。这是 Cacti 的一个老问题，只需在相关“设备”上切换到“版本 2”即可

相关内容