1.6 Zabbix のインストール - (6) 基本的な監視設定（トリガーの確認）
Zabbixでは、監視データに異常が発生したかどうか確認する仕組みを、トリガーと呼びます。監視データの取得・参照と並んで、トリガーはシステム監視ツールの非常に重要な機能です。Zabbixは、多彩な判断条件やアラート通知機能を提供します。
今回は、監視しているホストでエラーを意図的に発生させ、それをZabbixのWebインターフェース上で確認する方法を紹介します。
トリガー設定の確認
今回は、前回の記事で登録したPingテンプレートのトリガーで障害の発生を確認します。まず対象のトリガーを確認します。
メニューから、設定→テンプレート を選択します。
テンプレート Template Module ICMP Ping からトリガー をクリックします。
このテンプレートには、3件のトリガーが設定されています。警告レベルで設定されている2件のトリガーは、それぞれ応答速度の悪化、応答率の悪化でトリガー発生するよう条件式が記載されています。それぞれ依存先の下に記載されています。これは、別のトリガーの名称で、それらのトリガーが発生している状態のとき、このトリガーの発生はさせない、という定義になります。
本体の電源断や通信ケーブル抜けなどが発生すると、これらのトリガーすべて発生してしまいます。実際の運用監視では、不要なアラートをできるだけ発生させないことが望ましいです。このケースのように、エラーの内容によって通知する内容をコントロール（本体が停止しているときに、応答速度の警告を通知しても意味がない）する機能は、実際に運用の場面で活用するケースが多いでしょう。
トリガー条件式
トリガーの発生条件は、トリガー条件式で定義します。書式はとおりです。
{ホスト名:アイテム（キー）.トリガー関数}=比較値
ホスト名とアイテムのキー（名称ではなく、アイテムキー）がごちゃごちゃしているため、ちょっと可読性に難がありますが、上記の構造になっていることを意識すれば、理解しやすくなると思います。
Zabbixには、監視アイテムを評価するための様々な関数が用意されています。 今回確認するトリガー Unreacheable by ICMP Ping では、
max(#3)=0
という条件式が定義されています。これは、過去3回の監視データの最大値が0であれば真（=障害と判断する）という定義です。
トリガーの詳細は、ZabbixのWebマニュアルで確認できます。
監視ホストにエラーを発生させる
前回、Wifiルータを監視ホストとして登録しました。ただ、Pingのエラーを確認するために、Wifiルータの電源を落とすわけには行きません。私が使用している機種（Aterm）では、Pingの応答を管理が画面でコントロールできるので、そちらでPingの応答をしないように設定し、トリガーの発生を確認します。Atermの場合は、以下の画面で設定の変更が可能です。
これで、Pingの応答がなくなります。Linuxのコマンドラインで、対象のIPアドレスから応答がなくなったことを確認してください。
WiFiルータ以外でも、ZabbixアプライアンスをインストールしているWindows PCでも簡単に、Pingの許可・禁止をコントロールできます。WindowsファイアウォールでのPingのフィルタリングについては、以下の記事を参照ください。
発生したトリガーの確認
Pingの監視は1分間隔なので、Pingの応答ができないようになってから、3分後にはトリガーが発生します。
トリガーの確認は、メニューから 監視データ → トリガー を選択します。
以下のように障害情報が表示されていれば、OKです。
確認後、再びPingの応答ができるように変更します。
Pingの応答ができるようになると、先ほどのトリガー条件が最初の1回目の応答で解除（偽）になるので、すぐにトリガーの復旧が確認できます。
