SNMP Trap は監視設計の主役ではない – Polling、状態監視、イベント通知を分けて考える

SNMP Trap は、ネットワーク機器やアプライアンスが自発的に送信するイベント通知です。linkDown、linkUp、電源異常、FAN 異常、温度異常、冗長系の切替などを機器側から知らせる仕組みとして使われます。

即時性があるため便利ですが、Trap は監視対象の現在状態そのものではありません。あくまで「何かが起きた」という通知であり、状態の正本として扱うには弱い仕組みです。

監視設計では、Polling で現在状態を確認することと、Trap で発生イベントを受け取ることを分けて考える必要があります。この記事では、SNMP Trap を監視設計の主役に置くべきではない理由と、現実的な使い方を整理します。

Polling と Trap は構造が違う

SNMP 監視には大きく分けて、監視サーバーが定期的に取得する Polling と、監視対象が自発的に送る Trap があります。この 2 つは似ているようで、監視設計上はかなり性質が違います。

Zabbix 公式ドキュメントでも、Trap は SNMP 対応機器から snmptrapd へ送られ、Zabbix server または proxy が trapper file から収集する仕組みとして説明されています。つまり、Polling のように「Zabbix が今の状態を取りに行く」モデルではありません。

Trap は状態の正本ではない

Trap の最大の問題は、状態を継続的に示すものではないことです。Trap はイベントです。イベントは重要ですが、イベントを受け取ったからといって、その後の状態が継続しているか、復旧したか、通知を取りこぼしていないかまでは保証できません。

Polling = 現在状態を定期的に確認する
Trap    = 発生したイベントを通知する

状態の正本として使いやすいのは Polling
Trap は補助信号として扱う方が安定する

障害発生 Trap でアラートを上げることはできます。しかし、復旧 Trap が来ない、機器が Trap を送る前に落ちる、ネットワーク経路で失われる、といった場合に、監視システム側の状態が戻らなくなります。

Trap を主役にすると復旧条件が弱くなる

監視設計では、障害条件と復旧条件の対称性が重要です。Polling であれば、閾値を超えたら障害、正常値に戻ったら復旧、という設計が比較的自然にできます。

一方、Trap はイベント駆動です。障害 Trap と復旧 Trap が必ずペアで送られるとは限りません。ベンダーや機器、ファームウェア、設定によって Trap の内容も異なります。

Trap は重要な参考情報として扱う

Trap を否定する必要はありません。むしろ、ネットワーク機器やアプライアンスでは、Trap が唯一の手掛かりになるイベントもあります。重要なのは、Trap を監視の主役にしないことです。

Trap は「状態の正本」ではなく、「補助的なイベント情報」として扱うのが安定します。障害検知の主軸は Polling やメトリクスに置き、Trap は調査の手掛かり、履歴、補助トリガーとして使います。

Zabbix で Trap を扱う時の考え方

Zabbix では SNMP Trap を受けることができますが、通常のアイテム監視とは構造が異なります。snmptrapd、受信スクリプト、trap ファイル、Zabbix trapper の流れを理解しておく必要があります。

SNMP device
  -> snmptrapd
  -> trap receiver script / SNMPTT
  -> trapper file
  -> Zabbix server or proxy
  -> item / trigger

この経路は便利ですが、Polling よりも部品が多くなります。つまり、Trap 監視が動かない時は、SNMP 機器、UDP/162、snmptrapd、変換処理、trap ファイル、Zabbix の item / trigger を順番に切り分ける必要があります。

Trap だけに依存しない設計

実運用では、Trap を受けたら即アラートにするのではなく、状態確認と組み合わせる設計が扱いやすくなります。

• Trap はイベント履歴として保存する
• 重要 Trap は補助トリガーとして使う
• 最終的な障害状態は Polling やメトリクスで確認する
• 復旧判定は Trap だけに依存しない
• Trap が来なかった場合でも状態監視で検知できるようにする
• Trap の OID / varbind / 重大度のマッピングを記録する

特に「Trap が来たら障害」「復旧 Trap が来たら復旧」という設計は、復旧 Trap の取りこぼしや未実装に弱くなります。状態確認を別系統で持っておく方が、監視システムとして安定します。

linkDown / linkUp は状態確認と組み合わせる

SNMP Trap の代表例として、linkDown / linkUp があります。インターフェイスの状態変化を即時に知るという意味では非常に有用です。

ただし、linkDown Trap を受け取ったことと、現在もリンクが down であることは同じではありません。短時間で linkDown / linkUp が連続した場合、Trap の受信順序や取りこぼしによって、監視システム側の認識が実状態とずれる可能性があります。

そのため、linkDown / linkUp はイベント履歴として扱い、現在状態は interface status や ifOperStatus などの Polling で確認する方が安定します。

Trap は「変化が起きたこと」を早く知るための情報です。最終的に障害として扱うか、復旧として扱うかは、現在状態の確認と組み合わせて判断するべきです。

Trap が有効な場面

Trap は主役ではありませんが、不要なわけではありません。即時性が重要なイベント、Polling 間隔では拾いにくい瞬間的な異常、機器固有のハードウェアイベントなどでは有効です。

監視設計としての結論

Trap は通知としては便利ですが、状態監視の主役には向きません。監視設計の中心には、再現性があり、復旧判定ができ、現在状態を取りに行ける仕組みを置くべきです。

その上で、Trap はイベント履歴、即時通知、補助トリガー、障害解析の材料として使います。Trap を捨てるのではなく、役割を正しく限定することが重要です。

SNMPv2c を使う場合と同じで、古い技術を使うこと自体が問題なのではありません。問題は、その技術が何を保証し、何を保証しないのかを見誤ることです。Trap は状態の正本ではない。この前提を置くだけで、監視設計はかなり安定します。

参考

• Zabbix Documentation – SNMP trap
• RFC 3413 – SNMP Applications
• RFC 3416 – Version 2 of the Protocol Operations for SNMP
• SNMPv2c の community 名は秘匿ではなくアクセス制御のキーとして扱う

まとめ

SNMP Trap は便利ですが、監視設計の主役ではありません。Trap は現在状態ではなく、発生したイベントを通知する仕組みです。

障害検知や復旧判定の正本は、Polling やメトリクスによる状態確認に置く方が安定します。Trap は、即時性のある補助信号、機器固有イベントの記録、調査時の手掛かりとして扱うのが自然です。

特に linkDown / linkUp、電源、FAN、温度、冗長系切替のようなイベントでは Trap は役に立ちます。ただし、Trap を受け取ったことと現在状態がどうなっているかは分けて確認する必要があります。

監視設計で重要なのは、Trap を使うか使わないかではありません。Polling、Trap、ログ、メトリクス、ダッシュボード、アラートの責務を分け、どの情報を状態の正本として扱うのかを決めることです。

関連記事

監視とは何を見ることなのか – Zabbix、Prometheus、Grafana の責務分界で考える 障害切り分けとは何か – 影響範囲から構造を読む ホストとノードの違い – サーバー、VM、Kubernetes で主語を分けて考える TFTP の仕組みとファイアウォール設計 – UDP、動的ポート、PXE Boot を分けて考える クラウド管理型ネットワークと高度設計型ネットワークの違い – 抽象化と制御責任で考える 自動化は業務ロジックと責任分界を透明にする – 効率化の前に構造を定義する 竹中平蔵の提案する「所得制限付きベーシックインカム」に対する批判と考察 スイッチのスタック構成は冗長化なのか – 管理簡素化と障害ドメインで考える