第2回ではZabbix 2.2から4.0の間に追加された監視データ収集に関わる機能改善や新機能について解説を行いました。最終回の今回は障害検知や通知に関する以下の機能について解説します。
- 障害の手動クローズと確認機能
- イベントのタグ機能
- 障害通知とリモートコマンドの改善
障害の手動クローズと確認機能
Zabbix 3.2から4.0の間では以下のトリガーの機能強化が多数行われており，以前のバージョンと比べてログ監視やSNMPトラップ監視により発生した障害の対応に活用できる機能が追加されています。
- 復旧条件式（3.2）
- 手動クローズ（3.2）
- 障害確認とメッセージの入力（3.2）
- 深刻度の変更（4.0）
Zabbix 3.2ではトリガーの条件式設定に復旧するための条件式を個別に設定することができるようになりました。トリガーの状態はデフォルトでは以前のバージョンと同様に「条件式」に設定した式の判定結果が真になれば障害，偽になれば正常に戻ります。新しく追加された「正常イベントの生成」設定で「復旧条件式」を選択することで，復旧のための条件を個別に設定できるようになります。これにより，以下のように障害発生と復旧の条件を柔軟に設定できます（図1）。
図1
![図1]( "図1")
- CPUロードアベレージの例: 5以上で障害，その後1を下回った場合に復旧
- ログ監視の例: 「Stopped」の出力があった場合に障害，その後「Started」の出力があった場合に復旧
また，「正常イベントの生成」では「なし」を選択することで障害を自動的に復旧させないことも可能です。ログやSNMPトラップ監視の場合は障害になる文字列が出力されたとしても，復旧の判定ができる文字列の出力はないものがあったり，障害となる文字列が出力されたまま以降はログ出力がない場合もあります。また，以前のバージョンのように条件式が1つだけの設定であったときは，障害判定文字が含まれないログが出力されると障害が復旧するという動作も都合が悪い場合もありました。ログ監視やSNMPトラップ監視では自動的には復旧させないように設定し，あわせて同じく3.2で追加された「手動クローズ」の設定を利用することで発生した障害をWebインターフェースから手動でクローズして対応することができます。
手動クローズの新機能は以前より要望が非常に多かった機能です。利用するためにはあらかじめトリガーの設定で手動クローズを許可しておく必要があります。前述の通り，ログ監視やSNMPトラップ監視を利用している場合はトリガーが正常に戻る条件の設定が明確にならない場合があり，発生した障害で対応が完了したものはWebインターフェースの障害画面（第1回で解説した3.2からの新しい画面）の各障害の行の「確認済」の列にあるリンクをクリックした「障害更新」画面でクローズを行うことができます（図2）。クローズするとトリガーも正常状態に戻り，次回に障害となる監視データを受信すると障害イベントを生成します。
図2
![図2]( "図2")
Zabbix 3.2ではこの手動クローズの実装にあわせて，以前は「障害対応コメント」という機能であった画面で実行できる機能を強化しています。以前のバージョンではコメントを入力することで障害が確認済みの状態になる，という簡単な動作しか行えませんでしたが，新しい画面ではメッセージ入力のみ，障害確認を行う，手動クローズの操作が行えるほか，4.0では発生した障害の深刻度を変更することも可能になりました。これらの機能を利用して発生した障害に対して操作を行なったときに，後述する「障害更新時の通知」機能を利用することもできます。
イベントのタグ機能
Zabbix 3.2で新たにイベントに付与するタグの機能が追加されました。イベントタグはトリガーの設定でタグ名とタグの値の組み合わせを複数設定することができ，障害が発生した場合にイベントにタグを付与する機能です。障害画面でタグを表示して確認ができるほか（図3），フィルターで指定したタグで絞り込んで表示したり，アクションの実行条件としてタグが利用できます。
図3
![図3]( "図3")
また，トリガーのタグ設定ではマクロを利用して
{{ITEM.VALUE}.regsub("^.+ systemd: (Started|Stopped) (.+)\.$",\2)}
の形式で障害発生時に受信した監視データから正規表現指定で文字列を抜き出してタグに利用することができます。ログ監視では1つのログファイルに様々なアプリケーションのログが出力されるような場合に，ログから抜き出した文字列をタグに動的に設定することが可能です。
トリガー設定では，障害が復旧した際に同じトリガーから発生した障害イベントをクローズする方法を「すべての障害」と「指定したタグのみ」に変えることができ，上記のように動的にタグを付与する設定にした場合は特定のタグを持つ障害のみ自動的にクローズができます。さらに「イベントの相関関係」の機能を利用することで，タグを利用してトリガーをまたいだ自動的な障害のクローズの条件を設定することが可能です。
タグの機能によりイベントに任意の情報を付与することができるようになり，さらにZabbix 4.0ではタグを利用して以下の機能強化が行われています。
- 監視対象のメンテナンスでタグフィルターを利用できるようになり，以前はホストが最小単位だったメンテナンス機能の対象をトリガーやイベントレベルで設定できる
- ユーザーグループの表示権限の対象にタグフィルターを利用できるようになり，イベントレベルで表示権限を設定できる
障害通知とリモートコマンドの改善
Zabbix 3.0では障害通知のメール送信にSMTPSやSMTP Authを利用できるようになりました（図4）。以前は認証が必要なメールサーバーを利用する場合はスクリプトの作成が必要だったものが，Zabbixからの設定のみで行えるようになりました。また，Zabbix 3.4ではアクションの実行が並列化できるようになったり，4.0では1通の通知メールに複数の宛先アドレスが設定できるようになり，多数の障害通知を送信する必要がある場合でも効率よく通知メールが送信できます。
図4
![図4]( "図4")
Zabbix 3.2ではアクションの設定の機能強化を行い，復旧通知でも通知先を選択できたり，リモートコマンドを実行できるようになりました。あわせて設定画面や内部動作についても変更が行われています（図5）。
図5
![図5]( "図5")
- 障害通知の送信条件には暗黙に「トリガーの状態 = 障害」の条件が付与されている動作となり，アクション設定の選択項目からも削除されています
- 復旧通知の設定は専用の「復旧時の実行内容」タブで設定するようになり，柔軟な設定が行えます
さらにZabbix 4.0では新しく「更新時の実行内容」タブで，障害に対してのメッセージ入力や障害確認，深刻度の変更を行った場合に通知メールを送信することができます。以前のバージョンではZabbixの画面から招待に対してコメントを入力した場合でもZabbixのWebインターフェースへアクセスしないと確認ができませんでしたが，メール通知を確認しているだけでも現在の障害の対応状況を把握することができるようになりました。
他にも，Zabbix 4.0ではZabbixプロキシ経由のリモートコマンドに対応しました（図6）。リモートコマンドは障害発生時に障害発生元の機器で任意のコマンドを実行し，障害の自動対応を行うことができます。Zabbixプロキシ経由での実行に対応したことで，分散環境でリモート拠点の監視を行っている場合でも障害の自動対応を実行することができるようになり，より運用の自動化を進めることが可能です。
図6
![図6]( "図6")
その他の機能強化とアップグレード方法
その他にも，正規表現にPCREが利用できるようになったり，マップに図形を表示する機能，グラフなどの期間の選択方法の改善，Zabbixのコンポーネント間の暗号化機能，障害検知の予測関数，Zabbixサーバーとプロキシ間の通信の圧縮など，Zabbix 2.2から4.0までには様々な機能強化が行われており，実際の運用に役立つ機能が搭載されています。4.0より前のバージョンで機能上の仕様により手間のかかる設定となっているものを簡素化したり，運用で対応していたものが標準的に機能として搭載されている場合もあると思います。今回の連載では主な機能のみの紹介となりましたが，公式のオンラインドキュメントの各メジャーバージョンの「What's New」のページには細部も含めて機能強化や変更を行った内容を記載しています。詳細の確認はドキュメントも参考ください。
Zabbix 2.0以降，メジャーバージョンをまたぐアップグレードを実施する場合でも作業は非常に簡単に行えるようになっています。目的のバージョンのRPMパッケージをアップデートインストールし，Zabbixサーバープロセスを起動することで，自動的に以下の処理を行うようになっています。
- 現在のデータベースのスキーマのバージョンを確認
- データベースのスキーマを必要なバージョンまで自動的に更新
- すでに保存されている設定や監視データは引き継ぎつつ，変更が必要な設定は自動的に更新
データベースの更新が完了次第，新しいバージョンで起動して監視処理を開始するようになっています。Zabbixサーバーは自身のバージョンより古いエージェントとは通信が行えるように開発を行っているため，バージョンアップ後はすぐに監視を再開することができます。ただしZabbix 2.2から2.4，Zabbix 3.0から3.2の間では監視データを保存するヒストリ系のテーブルの更新が必要になるため，それらのテーブルの容量が多い場合はアップグレードに時間がかかること，変換のためのディスク容量が必要になることには注意してアップグレードを実施ください。
