2. トリガー条件式（復旧条件）

障害の発生と復旧の通知、特に、障害が収束した状態の認識･通知方法は、運用管理の品質や効率化に関わる重要なポイントです。Zabbixのトリガーは、復旧条件も柔軟に設定可能です。

復旧条件

トリガー設定項目のなかに、正常イベントの生成 という設定項目があります。 やや表現が硬い感じはしますが、トリガーを解除する条件の指定方法の設定です。

項目	動作
条件式	トリガー発行時の条件式に合致しなければ、解除。
復旧条件式	トリガー発行とは別に復旧条件を設定し、その条件に一致すれば解除。
なし	一度トリガーが発行されたら自動的に復旧はしない。手動クローズする前提で使用します。

一つの監視アイテムに、上記の各条件を設定したトリガーを別々に設定し、挙動を確認します。

トリガーの設定

アイテムは、Zabbixトラッパーアイテムを使用します。

トリガー設定 その１（解除：条件式）

値が10以上でトリガーONという設定です。解除は、この条件を満たさなくなった時（10未満になった時）です。

トリガー設定 その２（解除：復旧条件式）

値が10以上でトリガーがONになりますが、解除は値が7未満になったら、という復旧条件を別途設定します。

これは、ヒステリシスとか、フラッピング防止といわれる設定で、トリガー条件近辺で値が変化し続けた際に、トリガーのON/OFFを繰り返すような状況を防ぐことができます。以前は、トリガーステータスなどのマクロを使って、やや面倒な条件式を記述する必要がありましたが、V3.2から復旧条件式として独立して記載できるようになり、わかりやすくなりました。

復旧条件式は、あくまでも条件式に合致しなくなった場合にのみ評価されます。そのため、データの存在そのものをチェックするnodata()関数を復旧条件式に記載しても、通常の条件式のように定期的にチェックはしてくれません。気をつけましょう。

トリガー設定 その３（解除：なし）

正常イベントの生成でなしを選択すると、一度トリガーが発行されたあと、値がどのように変化しようが、トリガーはONのままになります。

そのため、手動でトリガーを解除できるよう、手動でのクローズ許可にチェックを入れて設定する前提ではないかと思います。

トリガー発行と解除の動作

まず、トリガー発行される値をzabbix_senderでアイテムに設定します。

$ zabbix_sender -z 192.168.0.9 -s Test001 -k trapper.uint -o 12

３つのトリガーが同時にONになります。

次にトリガー発行条件を下回る、8という値を設定します。

$ zabbix_sender -z 192.168.0.9 -s Test001 -k trapper.uint -o 8

トリガー条件式に合致しなくなったため、1番目のトリガーは解除されましたが、復旧条件を満たしていないため、2番目のトリガーはまだONのままです。

今度は、5を設定します。

$ zabbix_sender -z 192.168.0.9 -s Test001 -k trapper.uint -o 5

2番目のトリガーも解除されました。

3番目のトリガーは、値の変化してもずっとONままです。解除を行いには、対象のトリガーをチェックし、障害対応コメントの一括処理をクリックします。

何かメッセージを入力し（これは必須です）、障害のクローズにチェックを入れ、障害対応コメントをクリックします。

これで、トリガーを解除できました。