問題点
Zabbixにて、各OIDのトラップに対して、深刻度をそれぞれ定義していると思います。
が稀に、同一OIDのトラップに対して、内部メッセージをキーとして、異なる深刻度に分類する要望が発生したりします。
問題点の具体例(サンプル)
(1)設計時の監視ルール
トラップ(OID=.1.3.6.1.4.1.8072.9999(netSnmpExperimental))は、ファイルオープンが失敗した場合のアラームであり、必ず、深刻度「致命的な障害」としてインシデント管理していたとします。
また、当トラップの第一引数には、エラー原因により、以下の3メッセージの何れかを付加していた。
- "FileNotFound"(ファイルが存在しないエラー)
- "FileSizeZero"(ファイルが存在しているが0Bytes)
- "UnknownError"(原因不明のエラー)
※サンプルショボくてすいません
(2)実際に運用してみて、
運用後、ファイル0bytesの場合は、エラーではなく正常な動作であることが判明(よくあることです)。
アプリチームから、トラップnetSnmpExperimentalで、第一引数が"FileSizeZero"の場合は、深刻度「情報」にして欲しい(インシデント管理対象外にしたい)との要望。
(3)Zabbix管理者はその要望を受容しなければなりません。
サービス要件ならば、プログラム側の修正は必須ですが、
今回は監視要件… Zabbix管理側が対応しなければなりませんよね(悲しい!!)
想定するZabbix環境
トラップの流れは、以下の3デーモンを使用していると想定
- SNMPTRAPDでトラップを受信
- SNMPTTでトラップの分類
- ZABBIXでトリガー処理
実現方法(設定)
SNMPTTを利用する。
SNMPTT設定
本来、対象トラップ(netSnmpExperimental)の記載は1本であったが、
以下のように、深刻度(severity)を"INFORMATION(情報)"と"DISASTER(致命的な障害)"の2本に分割。
それぞれにMATCH構文を追記し、"INFORMATION"には"(FileSizeZero)"を追記。
"DISASTER"には"!(FileSizeZero)"を追記する。
EVENT netSnmpExperimental .1.3.6.1.4.1.8072.9999 "Status Event" INFORMATION
MATCH $1: (FileSizeZero)
FORMAT ZBXTRAP $aA ファイルサイズゼロなので処理不要。正常状態です($1)。
EVENT netSnmpExperimental .1.3.6.1.4.1.8072.9999 "Status Event" DISASTER
MATCH $1: !(FileSizeZero)
FORMAT ZBXTRAP $aA ファイルオープンが失敗しました。障害発生($1)。
Zabbix-ITEM設定
(注意)キーの中身は、"INFORMATION"や"DISASTER"のみだと、トラップメッセージ内の文字列がマッチしてしまう可能性があるので、ユニークになるようなルールが必要です(ここでは、深刻度+"Status Event"をキーとしています)。
Zabbix-TRIGGER設定
検証
(1)メッセージに"FileSizeZero"を含むトラップ(netSnmpExperimental) ⇒ 深刻度「情報」
snmptrap -v 2c -c public 127.0.0.1 '' netSnmpExperimental netSnmpExperimental.1 s "FileSizeZero"
(2)メッセージに"FileNotFound"を含むトラップ(netSnmpExperimental) ⇒ 深刻度「致命的な障害」
snmptrap -v 2c -c public 127.0.0.1 '' netSnmpExperimental netSnmpExperimental.1 s "FileNotFound"
(3)メッセージに"UnknownError"を含むトラップ(netSnmpExperimental) ⇒ 深刻度「致命的な障害」
snmptrap -v 2c -c public 127.0.0.1 '' netSnmpExperimental netSnmpExperimental.1 s "UnknownError"
まとめ
Zabbix触りたての頃、私はZabbixにSNMPTRAPを処理させる時に、itemのsnmptrap[]内にトラップ名称(linkUp等々)を記載していた。
これはこれで正確に記載できるが、ここには深刻度(information/warning/disaster等)を記載したほうが管理しやすいと考え、切り替えた経緯があります。
今回のようにSNMPTRAP条件分岐を実現するために、ZABBIXのITEM/TRIGGERよりもSNMPTT機能を活用するほうが容易で強力に感じたので、記事にしてみました。