Snmpd 更新接口计数器缓慢或类似这样的

Question

我将我的一个 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 收集有关接口的信息到 2 个不同的软件，zabbix 和 cacti。

他们都用空白字段绘制图形。

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

snmpd.conf 是空的——只有一个访问控制。

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

我的错在哪里？如何修复这个图形？

UPD： 更改池时间，关闭代理之一，没有帮助。我查看了 zabbix 日志（从 snmpd 接收到的数据）并看到：抱歉俄罗斯语言环境，看看数字：

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

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

我试着用 64 位计数器重新编译 snmpd，没有它。在这两种变体中，都存在此空白字段。

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

我仍然收集 tcpdump 以找到这个请求/响应。但是有问题，太多垃圾。

UPD2： 我解密了 tcpdump-ed 文件，并在gdocfile 上将其作为谷歌文档公开

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

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

看起来操作系统中的所有计数器都很好。现在我认为问题在于： 1. zabbix 在行中两次获取请求（以及仙人掌呢） 2. snmpd 使用 counter32

Answer 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 流量。确保请求和响应及时地来回传递，并且不会因某种原因而丢失/被拒绝。经常查看电线上的数据会给你一个很好的指示，告诉你什么地方出了问题以及如何修复它。