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 收集有關介面的資訊到 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 文件，並將其作為Google文件在gdocfile 公開
Timediff 看起來很奇怪.. 就像 zabbix 有時“忘記”做請求，然後在行做兩次，ehh
UPD3： 我從命令“while true; do netstat -bin -I vlan4008 >> /var/log/netstat; sleep 300; done”解析日誌並載入為Google文件，並添加速度公式：連結
看起來作業系統中的所有計數器都很好。現在我認為問題在於： 1. zabbix 在行中兩次獲取請求（仙人掌呢） 2. snmpd 使用 counter32
這通常與未及時收到 SNMP 響應有關。
因為 SNMP 使用 UDP，這可能意味著網路擁塞或主機擁塞導致請求/回复失去，但更常見的是，所涉及的兩台機器中的一台根本無法及時處理請求，而另一台機器得到了厭倦了等待。
一台機器或另一台機器落後的機會隨著工作量的增加而增加——如果您有很多 SNMP 代理查詢特定主機，它可能無法像某些代理期望的那樣及時提供回复（並且這些代理將顯示空白圖中的點，或報告其他錯誤）。
相反，如果您有一個代理查詢一堆主機 - 超過它在輪詢間隔內可以處理的數量 - 在輪詢間隔期間未查詢的機器將在其圖表中出現間隙。（這個問題在 Cacti 的 PHP 輪詢器中特別常見，並導致了
cactid(nowspine) 的開發，如果您還沒有使用它，我強烈建議您使用它）。我對解決此問題的一般建議：
- 如果可能，每 5 分鐘輪詢一次。
大多數環境不需要 1/5/15/30/60/90/120 秒的輪詢間隔。
如果五分鐘的粒度對您來說足夠好，請堅持下去。伺服器的工作量更少，SNMP 監控代理的工作量更少，要儲存的數據也更少（或者“全粒度”的時間更長） 2. 增加代理上的 SNMP 超時。
給伺服器更多時間來處理您的請求。SNMP 守護程序是程序中的懶惰少年——你要求他們在周一打掃房間（或給你一棵樹的數據），而在周三或週四，他們可能會撿到幾隻襪子。 3. 限制每次輪詢對伺服器的要求。
如果您只需要一個計數器，請不要要求整個介面 MIB —— 它（通常）需要更長的時間來遍歷樹並生成完整輸出，而不是只給您一個 OID。 4. 限制請求數據的代理數量。
如果您可以將監控整合到一個盒子（Zabbix 或 Cacti）上，您對伺服器的需求就會減少，並且不太可能無法及時響應。
如果您在嘗試上述操作後仍然遇到問題，則可以進行最終的調試步驟：搜尋您的日誌並嗅探 SNMP 流量。確保請求和響應及時來回傳遞，並且不會由於某種原因而失去/拒絕為格式錯誤。經常查看網路上的數據可以很好地指出問題所在以及如何解決問題。