Zabbix OID 直指定 SNMP 監視における遅延の回避策

はじめに（現象）

Zabbix で応答の遅いネットワーク機器を SNMP 監視している際、以下のような事象に悩まされたことはありませんか？

Timeout 設定を無視して待たされる
Timeout を「10 秒」に設定しているのに、10 秒でタイムアウトエラーにならず、なぜか 15 秒など遅延して値が取得される。
監視スケジュールが遅延し、キューが滞留する
監視対象ホストの SNMP 監視アイテムが、キューに大量に滞留してしまう。

本記事では、Zabbix 7.0 の「OID 直指定」による SNMP 監視を対象に、これらの遅延が発生する裏側の仕組みと、実行タイミングを分散させる具体的な回避策を解説します。

※ 本記事で使用する用語についてはこちらの用語集を参照してください。

環境

Zabbix Server 7.0.24
Zabbix Agent 7.0.24
Rocky Linux 8.10

原因 : なぜ遅延し、キューが滞留するのか？

原因①：SNMP ライブラリのリトライ処理

SNMP 監視の内部処理では、通常時 SNMP ライブラリによるリトライが行われます^※。Zabbix 上の Timeout 設定は、実は「1 回あたりの通信を待つ時間」です。そのため、機器の応答が遅く 1 回目の試行でタイムアウトし、リトライで成功したケースでは、監視データの取得はエラーにはならず、「Timeout 設定値を超えて遅延して取得される」という事象になります。

※ アイテムの状態が Unreachable である場合はリトライはありません。

原因②：最大 128 個のバルク処理による一斉遅延

「組み合わせたリクエストの使用」を有効にした場合、同一インターフェースの処理は最大 128 個のアイテムがまとめて要求されます。もし機器の応答が遅いと、この「まとめられた最大 128 個のアイテム」が一斉に先述の遅延に巻き込まれてデータ取得が遅延するため、「キュー」に大量のアイテムが表示される結果となります。

例) Timeout=10 を設定した場合

対策 : 更新間隔のカスタマイズによる負荷分散

Timeout 値を増やした場合、その分待機時間が増えるため、遅延を更に悪化させてしまいます。
また、「組み合わせたリクエストの使用」を無効にして 1 個ずつリクエストするという方法がありますが、これを行うと個別のリクエストが増えてしまい、逆に機器の負荷を上げて悪化させることもあるため注意が必要です。
そこで、より現実的で安全な対策としておすすめしたいのが、アイテム群を更新間隔のカスタマイズを使ってグループに分割し実行タイミングをずらすアプローチです。これにより、機器にかかる瞬間的な SNMP 要求の数が減少し、機器がスムーズに応答できるようになり、リトライの発生そのものを防ぐことが期待できます。

例) 200 個のアイテムを 50 個のグループに 4 分割する場合

グループ A：s0 （毎分 00 秒に実行）
グループ B：s15（毎分 15 秒に実行）
グループ C：s30（毎分 30 秒に実行）
グループ D：s45（毎分 45 秒に実行）

設定する際は、以下のようにグループにするアイテムをまとめて選択して「一括更新」機能を使うと便利です。

設定後のログ

実際に設定して分散されて監視が行われることを確認しました。DebugLevel=4 のログから、0 秒、15 秒、30 秒、45 秒のタイミングで 50 個ずつ監視が行われていることが確認できました。

1452:20260710:023730.132 zbx_snmp_get_values() snmp_sess_synch_response() status:0 s_snmp_errno:0 errstat:0 mapping_num:50
1452:20260710:023745.156 zbx_snmp_get_values() snmp_sess_synch_response() status:0 s_snmp_errno:0 errstat:0 mapping_num:50
1452:20260710:023800.178 zbx_snmp_get_values() snmp_sess_synch_response() status:0 s_snmp_errno:0 errstat:0 mapping_num:50
1452:20260710:023815.198 zbx_snmp_get_values() snmp_sess_synch_response() status:0 s_snmp_errno:0 errstat:0 mapping_num:50