Zabbixは「自動化」で運用管理者の負担をどう減らしてきたのか：クラウド／コンテナ時代のZabbix再入門（前編）（2/2 ページ）

[田中敦，SCSK株式会社]

Zabbix 3.0から4.0までに追加された機能

　ここまで紹介したのは、Zabbix 3.0までに用意された基本的な自動化の機能です。Zabbix 3.0から、さらに運用や設定をサポートするような機能や、さまざまな監視対象に対応するための機能が追加されています。下記は、主な機能追加です。

• 3.2で追加された主な機能：
  • トリガーの手動クローズ
  • ヒステリシストリガーの改善
  • イベントタグの設定
  • イベント相関関係の設定
  • LLDで生成したアイテムの詳細確認
  • Webシナリオのエクスポートとインポート
  • イベント画面から障害画面へ
  • ホストグループの階層化
  • ログバースト対応
• 3.4で追加された主な機能：
  • Webインタフェースの改善
  • アイテムの保存前処理
  • 依存アイテム
  • アイテムの値の同時収集
  • スクリプトやコマンドの実行結果のハンドリング
  • プロキシ経由でのリモートコマンドの実行
  • 障害対応コメント入力時の通知
  • 通知処理の並列化対応
  • アイテムの追加（vfs.dir.size[]）
  • JMX監視の改善
  • Web監視のURLエンコーディング対応
  • 収集データのElasticsearchへの保存

　幾つかをピックアップして紹介します。

表示系の改善

　まずは、Webインタフェースの改善です。特に大きな変化は、ダッシュボード機能の拡張でしょう。

　ダッシュボードとは、ログイン後に表示されるデフォルトの画面です。以前はカスタマイズ性も乏しく、1つしかありませんでした。Zabbix 3.4からは、「ウィジェット」と呼ばれる、下記のような部品を自由に配置できるようになり、ダッシュボード画面として複数定義できるようになりました。

• URL
• Web監視
• Zabbixサーバの状態
• お気に入りのグラフ
• お気に入りのスクリーン
• お気に入りのマップ
• アクションログ
• グラフ
• システムステータス
• ディスカバリのステータス
• データの概要
• トリガーの概要
• プレーンテキスト
• ホストステータス
• マップ
• マップナビゲーション
• 時刻
• 障害

　これらを利用することで、用途や操作するユーザーに合わせたダッシュボードを、複数定義して保存できます。例えば、データセンター、システム、サービスごとに、専用のダッシュボードを用意しておくと、ユーザーは、自分の役割や担当範囲に合わせてダッシュボードを選択して、状態を把握できます。

トリガーの改善

　トリガーを手動でクローズできるようになったことは大きな変化でしょう。

　ログ監視やトラップ監視を行う場合、「障害」と判定したトリガーの状態を「障害」の状態から「正常」な状態に復旧させる必要があります。そのために多くの運用管理者が、「nodata()」関数を使って、「一定時間、値が取得できなかった」ことを判定する条件式をトリガーに設定し、自動的にトリガーの状態を復旧させる運用をしていたことでしょう。

　しかしnodata()を使う場合、設定やタイミングによっては、障害が新規に発生していないときにも、nodata()が評価されるタイミングで障害を通知してしまうことがありました。

　Zabbix 3.2では「手動で、トリガーを『正常』に戻したい」というユーザーからの要望が、ようやくかないました。トリガーの設定で「手動クローズを許可」にチェックしておくだけで実現できます。

　他にも、トリガーの状態を変更する条件式を柔軟に設定できるようになりました。例えば3.2で追加された「ヒステリシストリガー」では、「『正常』な状態から『障害』の状態に遷移する」場合と、「『障害』の状態から『正常』な状態に遷移する」場合の条件式を、明確に分けて設定できます。

アイテムの設定の改善

　アイテムの設定でもZabbix 3.4で大きな機能追加がありました。「アイテムの保存前処理」機能と「依存アイテム」機能です。

　保存前処理とは、取得してきたアイテムの値を加工する機能です。下記のような加工方法があります。

• 乗数（Custom multiplier）
• 末尾文字列削除（Right trim）
• 先頭文字列削除（Left trim）
• 前後文字列削除（Trim）
• 正規表現（Regular expression）
• 論理値から10進数（Boolean to decimal）
• 8進数から10進数（Octal to decimal）
• 16進数から10進数（Hexadecimal to decimal）
• 差分（Delta）
• 時間ごとの差分（Delta per second）
• XML XPath
• JSON Path

　特筆すべきは、XMLやJSONから特定の要素の値を取り出す「XML XPath」「JSON Path」です。例えば、アイテムの保存前処理と依存アイテムを利用すると、下図のようなApache HTTP Serverのステータス応答から、各値を切り出すことがでます。

　依存アイテムとは、アイテムの親子関係を設定して、親アイテムの値に保存前処理をかけることで複数の子アイテムの値とする機能です。これによって、1回の処理でまとめて値を取得して、詳細な値に分解することもできます。

ログ監視の改善

　ログ監視で大量のログをファイルに出力して、全ての行がトリガーで設定している障害の条件に合致した場合、「障害イベント生成モード」で「複数」を選択していると、条件に合致したログの行数分のアクションによる大量の通知を行うことになります。

　そこでZabbix 3.2から実装されたのが「ログバースト対応」機能です。この機能を有効にしたアイテムを設定しておくと、「大量のログをZabbixサーバに送るのに時間がかかる」といった場合に、設定した時間以上の遅延が発生しても、Zabbixサーバに送らないようにすることが可能になりました。

　全てのログをZabbixサーバに記録できなくなりますが、大量に発生していたアクションでの通知を削減することはできます。

障害発生通知の改善

　Zabbix 3.4から、障害対応コメント入力時にも通知できるようになりました。アクションの設定で「障害対応コメント入力時実行内容」タブに通知先を設定しておくことで、トリガーで発生した障害のコメントを入力したり、状態を変更したりしたときに、通知できます。

　運用ルールで詳細を決めておくことが必要ですが、この機能によって「発生した障害を認識して、対応作業を開始したかどうか」を周知させることにも利用できると思います。

次回、後編はZabbix 4.0の新機能

　このように、本稿ではZabbixが「自動化」によって運用管理者の負担をどう減らしてきたのかを機能ごとに見てきました。次回、後編では2018年10月2日にリリースされたZabbix 4.0の新機能を取り上げます。3.2や3.4で先行的に実装されてきた機能をさらに有効に活用して、より自動化に役立つ機能が追加されているので、お楽しみに。