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

SNMP Trap は、ネットワーク機器やアプライアンスが自発的に送信する通知です。障害発生時に機器側から即座に通知できるため、リアルタイム性という意味では便利です。

しかし、Trap は監視対象の状態そのものではありません。あくまで「何かが起きた」というイベント通知であり、状態の正本として扱うには弱い仕組みです。この記事では、SNMP Trap を監視設計の主役に置くべきではない理由と、現実的な使い方を整理します。

Polling と Trap は構造が違う

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

方式	通信の向き	状態確認	復旧判定
Polling	監視サーバーから監視対象へ問い合わせる	定期的に現在状態を取得できる	次回取得値で復旧を判定しやすい
Trap	監視対象から監視サーバーへ通知する	通知されたイベントだけを受け取る	復旧 Trap が来ないと戻しにくい

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 がない	障害は通知されるが復旧イベントが送られない
取りこぼし	UDP や中継処理の都合で Trap が失われる可能性がある
ベンダー差	OID や varbind の内容が機器ごとに異なる
試験が必要	実際に障害を起こして Trap の内容を確認しないと設計しづらい
自動化しづらい	MIB、OID、文字列、重大度のマッピングが個別対応になりやすい

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

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

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

役割	主に使うもの	Trap の位置づけ
死活監視	ICMP、TCP、SNMP Polling	補助
リソース監視	Polling、メトリクス	補助
リンク状態	Polling と Trap の併用	即時通知として有用
ハードウェア異常	Trap、ログ、Polling	早期検知の手掛かり
障害復旧判定	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 の取りこぼしや未実装に弱くなります。状態確認を別系統で持っておく方が、監視システムとして安定します。

Trap が有効な場面

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

場面	Trap の価値	注意点
リンク up/down	即時通知として有用	最終状態は interface status で確認する
電源 / FAN / 温度異常	機器固有イベントを拾える	OID と重大度の整理が必要
冗長系の切替	発生タイミングの記録に有用	現在の主系 / 従系状態は別途確認する
ライセンスや閾値イベント	機器が発するイベントを記録できる	Trap 文面だけで判断しない

監視設計としての結論

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

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

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

参考
書籍

参考書籍

マスタリングTCP/IP SNMP編

SNMP、MIB、ネットワーク管理の基礎を確認したい場合の参考書籍です。古い書籍のため、価格や在庫はリンク先で確認してください。

Amazon で見る

このリンクは Amazon アソシエイトリンクです。

参考

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

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

Polling と Trap は構造が違う

Trap は状態の正本ではない

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

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

Zabbix で Trap を扱う時の考え方

Trap だけに依存しない設計

Trap が有効な場面

監視設計としての結論

参考

Related posts:

コメントを残す コメントをキャンセル

コメントを残すコメントをキャンセル