Zabbix Sender によるバッチ処理結果の監視
Tricorn Labs では初投稿になります。インフラグループの Morikawa です。今回はインフラグループで最近進めています、Zabbix Sender を用いたバッチ処理結果の監視について紹介します。
Zabbix はサーバ、ネットワーク、アプリケーションを監視するための統合監視ソフトウェアであり、GNU General Public License (GPL) v2 で配布されていて無償で利用可能です。ざっくりと仕組みを説明しますと、各サーバ上で動作する Zabbix Agent がサーバの様々なステータスを取得し、Zabbix Server が各 Agent からの情報を取得してデータベースに蓄積した上で、予め障害として設定された条件にマッチするものが検知された場合に管理者に対して障害報告を行います。また Web UI も備えており、そちらから諸々の設定を行えるだけでなく、ダッシュボードで状況を一覧することも可能です。
さて、インフラグループではトライコーンが提供するサービスの異常もしくはサービスに影響を与えうるサーバ・ネットワーク障害を速やかに検知するための様々な対策をとっていますが、その一環として Zabbix による監視も行なっています。一般的な監視項目であるサーバのディスク使用率やプロセス稼働に加え、最近は日次のバッチ処理の成否についても Zabbix で監視を行い始めています。バッチ処理の成否の取得には Zabbix Sender を用いていますが、なぜ Zabbix Sender を用いているのか、また実際にどのように監視しているのかについてご紹介します。
Zabbix Sender による監視のメリット
さて、前述のとおり日次バッチの処理結果の取得には Zabbix Sender を用いていますが、Zabbix にはユーザ定義のスクリプトの実行およびその成否を監視するという点で似た機能を提供する UserParameter もあります。まずそちらと Zabbix Sender との違いを整理し、どういったメリットがあるのかを考えてみます。日次のバッチ処理の成否を Zabbix で監視する方法はいくつかあると思いますが、今回は以下の 3 パターンについて考えてみます。
1. Zabbix Sender を用いる方法 (以降記事内では ZabSender と略記)
- バッチ処理に用いるスクリプト内で zabbix_sender コマンドを用い (具体的な使い方は記事の後半で)、バッチ処理時に Zabbix Server に処理結果の情報を送信
- バッチ処理の実行のタイミングは CRON などでバッチ処理実行ホスト上で制御
- 監視アイテムのタイプは Zabbix Trapper
- 下図は Zabbix Sender を用いた場合の処理の流れの一例を示してみたものです。バッチ処理として bk 上で web, mail からのデータバックアップ処理を行い、その結果を Zabbix Sender を介して Zabbix Server へと送っています。
2. UserParameter を用いる方法 1 (以降記事内では UserParam 1 と略記)
- バッチ処理時にその処理の成否をホスト上のファイルに出力
- UserParameter に上記ファイル内のバッチ処理結果の情報を取得できるコマンドを指定 (例えば上記ファイルを cat するなど) し、Zabbix Agent を介して成否の情報を Zabbix Server に引渡し
- バッチ処理の実行のタイミングは CRON などでバッチ処理実行ホスト上で制御
- 値の取得タイミングは Zabbix Server の監視アイテム側で制御
- 監視アイテムのタイプは Zabbix Agent
3. UserParameter を用いる方法 2 (以降記事内では UserParam 2 と略記)
- UserParameter でバッチ処理に用いるスクリプトを直に指定し、成否の情報を Zabbix Server に引渡し
- バッチ処理の実行タイミングと値の取得タイミングが同じとなり、ともに Zabbix Server の監視アイテム側で制御
- 監視アイテムのタイプは Zabbix Agent
日次バッチ処理成否監視の観点からこれらの方法のメリット・デメリットをまとめると以下のようになります。
| No. | 比較項目 | ZabSender | UserParam 1 | UserParam 2 |
|---|---|---|---|---|
| 1. | 監視ホスト名の任意設定 | ○ | × | × |
| 2. | バッチ処理の「何時何分に 実行」という制御 |
○ | ○ | × |
| 3. | Agent のアイテム取得の Timeout 制限を受けにくい |
○ | ○ | × |
| 4. | 中間ファイル管理不要 | ○ | × | ○ |
| 5. | 余剰な通信が発生しない 余剰なデータを保存しない |
○ | × | ○ |
| 6. | バッチ処理が実行されて いない状態の検知 |
△ | × | △ |
以下、それぞれの比較についての説明です。
1. 監視ホスト名の任意設定
- ZabSender の場合、バッチ処理実行ホストから情報を送った場合であっても、その情報を登録する先の監視ホスト名を別のもの (例えば日次バックアップなどであればバックアップ対象のホスト名) にすることが可能です。上図の例で言えば zabbix_sender コマンドを実行するのが bk というサーバであっても、バッチ処理成否を登録する監視ホストを web や mail に指定可能 ということですね（下図）。
- 一方 Zabbix Agent を用いる UserParam 1,2 の場合は監視ホスト名はバッチ処理実行ホストに固定されるため、アイテムやトリガーに個別に対象ホスト名を付与するなどの工夫が必要となります（下図）。
- アイテム名を共通化できた方がテンプレート化も容易であり、管理上は ZabSender の方が便利と言えるでしょう。
2. バッチ処理の「何時何分に実行」という制御
- UserParam 2 の場合、監視アイテムの値の更新間隔がそのままバッチ処理の実行間隔となります。あくまで数時間おき、一日おき、という間隔での指定となり、CRON などで可能な「何時何分で実行」という制御は不可能です。バッチの処理は時間を細かく制御したい場合も多いはずですので、その点で UserParam 2 を使える場面は限られそうです。
3. Agent のアイテム取得の Timeout 制限を受けにくい
- Zabbix Agent による監視である UserParam 1, 2 についてはアイテムの値取得時に Timeout 制限が存在します。この Timeout はデフォルトは 3 秒で、設定によって 30 秒まで延ばすことが可能です（参考）。UserParam 1 の方は、Zabbix Agent で行うのはバッチ処理成否が記載された小さなテキストファイルをオープンするだけですのでこの制限に引っかかることはほとんど無いと思います。しかし UserParam 2 の方は処理によって 30 秒を超えることは十分ありえます。この点においても UserParam 2 を用いる場面は制限されてくるでしょう。
4. 中間ファイル管理不要
- UserParam 1 の場合バッチ処理の成否を書き出す中間ファイルの管理が必要となり、スクリプトの数が増えてくると管理が煩雑になる可能性があります。他の方法であれば中間ファイルは不要です。
5. 余剰な通信が発生しない／余剰なデータを保存しない
- UserParam 1 の場合, バッチ処理のタイミングとは独立して監視アイテムの取得を行うため、都度通信とデータ保存が必要となります。本来バッチ処理時、もしくはその前後でのみ値が必要なものであり、UserParam 1 では (大した量ではないとはいえ) 不要にリソースを消費していると言えます。残り2つの方法はバッチ処理時にのみ監視用の通信とデータ保存が行われることになります。
6. バッチ処理が実行されていない状態の検知
- 運用上、「バッチ処理が異常終了した」という状態を検知したいのはもちろんですが、何かしらの理由で「バッチ処理が実行されなかった」という状態も検知したいところです。ZabSender と UserParam 2 の場合はそれぞれトリガーの設定によりその検知が可能ですが、UserParam 1 ではその検知は困難です。
- ZabSender, UserParam 2 の場合、異常終了を検知するための値参照のトリガーに加え、「どれぐらいの期間内にアイテムの値が更新されていなければならないか」を判定するトリガーが必要です。具体的には nodata (参考) などの関数を用いることでその判定が可能です。
- UserParam 2 の場合、バッチ処理が実行されない場合には値取得ができないはずなので、監視アイテムが値の取得不可状態となります。zabbix[items_unsupported] 関数を用いることで取得不可のアイテムの有無自体の検知が可能なため、こちらの検知を足がかりにバッチ処理の未実行を把握することも可能です。 (参考)。
- UserParam 1 の場合、Zabbix Agent はバッチ処理の成否を記録したファイルを参照するだけなので、バッチ処理が実行されないことについては検知できません。
なお、上記の表だけ見ると、「UserParameter より Zabbix Sender が優れてる」みたいに見えますが、あくまで日次バッチ処理の成否の監視についてフォーカスした場合の比較に過ぎません。例えば UserParameter (というか Zabbix Agent 監視全般ですが) による監視は数秒間隔で実施でき、最短1分間隔の CRON 実行よりもはるかに細かくホストの状態を監視できます。秒単位で変化する値などを監視する場合は Zabbix Sender よりも UserParameter を用いた方が良いでしょう。両機能とも、その特徴を理解して監視の内容に応じて適材適所で用いたいですね。
Zabbix Sender による日次バックアップ処理の監視
さて、前置きがだいぶ長くなりましたが、日次のバックアップバッチ処理について監視する場合の一例を紹介します。
まず zabbix_sender コマンドの基本的な使い方は以下の通りです（その他オプションに関しては Zabbix Sender manpage を参照下さい）。
$ zabbix_sender -c [config-file] -s [host-name] -k [item-key] -o [item-value]
例えば、ホスト上の Zabbix Agent の設定ファイルが /etc/zabbix/zabbix-agentd.conf, 監視対象ホスト名が web01, 監視アイテム名が custom.operation.rsyncbackup で、アイテムの値として 0 を渡したい場合は以下のようになります。Zabbix Server の IP アドレスなどの基本的な情報は zabbix_agentd.conf に記載されている前提となります。
$ zabbix_sender -c /etc/zabbix/zabbix-agentd.conf -s web01 -k custom.operation.rsyncbackup -o 0
実際には以下のようにバッチスクリプトに組み込む感じです（実際に使用しているものよりはかなり簡略化し、設定値も変更しています）。以下の例は、バックアップサーバが web01.example.org というサーバの /var/www/html 領域のバックアップを行い、その結果を Zabbix Server 上の監視ホスト web01 の値として登録することを想定しています。
#!/bin/sh
# Settings
REMOTE_HOST="web01.example.org"
REMOTE_DIR="/var/www/html/"
LOCAL_DIR="/backup/web01.example.org/var/www/html/"
RSYNC_PATH="/usr/bin/rsync"
RSYNC_OPT="-a"
ZBX_SENDER="/usr/bin/zabbix_sender"
ZBX_AGENT_CONF="/etc/zabbix/zabbix_agentd.conf"
ZBX_NAME="web01"
ZBX_KEY="custom.operation.rsyncbackup"
# Backup
${RSYNC_PATH} ${RSYNC_OPT} ${REMOTE_HOST}:${REMOTE_DIR} ${LOCAL_DIR}
RC="$?"
# Zabbix Sender
${ZBX_SENDER} -c ${ZBX_AGENT_CONF} -s ${ZBX_NAME} -k ${ZBX_KEY} -o ${RC}
rsync のステータスコードを $RC という変数に代入し、zabbix_sender でサーバに対して送るようにしており、正常終了すれば 0 が、異常終了時はそれ以外の値が送られる想定です。今回の例ですと、rsync のステータスコードの値がそのまま Zabbix Server で登録されるため、その値から異常終了の原因をある程度推定可能ですね。
一方、 Zabbix Server ではバッチ処理の結果を取得・判定するアイテムやトリガーが必要になります。日次のバッチ処理を監視する上で必要なトリガーのイベント発生条件は以下でしょうか。
- 値として 0, 24[1] 以外が与えられた場合
- 1 日以上 (例えば 25 時間 = 90000 秒)、 値が取得されない場合
複数サーバで簡単に使い回すことを考えるとテンプレート化しておくのが便利ですね。せっかくなのでアイテム名として上記スクリプト例でキーとして指定している custom.operation.rsyncbackup を含み、トリガーのイベント発生条件として上記 2 つを含んだ簡単なテンプレート (ダウンロード) を作ってみました。一応 Zabbix Server v1.8.11, v2.0.4 にインポートできることは確認済みです。ご利用は自己責任となりますが、アイテム・トリガー作成の参考になりましたら幸いです。
既に Zabbix による監視を行なっているシステムであれば、監視テンプレートさえ事前に用意しておけば、
- バッチ処理スクリプトに数行の zabbix_sender 関連のコードを埋め込む
- テンプレートを監視ホストに適用する
といった作業だけで日々のバッチ処理の監視も Zabbix に統合することが可能です。処理に失敗した場合や処理自体が行われない場合には他のトリガーと同様に Zabbix で検知されますので速やかに異常を把握できますし、解消されない限りは下図のようにダッシュボードに表示されてますので「対応を後回しにしているうちに忘れてしまってた」といったリスクも小さくできるかなと思います。
まとめ
以上、インフラグループで最近取り組んでます、Zabbix を利用した運用効率化の一例でした。長く運用をしてますと様々な「日々監視すべきモノ」が増えてきます。もちろんそれによってサービス障害の予兆検知を行える可能性が増えることは良いことなのですが、エンジニアが見るべき対象が多量のメール通知、各サーバ上のログなどと点在化が進むと、逆に見落としのリスクも増えてしまいます。Zabbix などの統合監視システムでは Zabbix Sender のように利用者側が任意で実行するプログラムの成否監視も行えるため、監視結果の集約をさらに進められるので助かりますね。
日頃運用していて「あぁ、ここはもっと効率化したいなぁ」ということは多いですので、この手の機能を活用して手間を減らし、浮いた時間でシステム改善をさらに進められるようにしていきたいですね。
参考サイト・資料
- Zabbix 公式サイト
- ZABBIX-JP | Japanese Zabbix Community
- 書籍: Zabbix統合監視「実践」入門 ~障害通知、傾向分析、可視化による省力運用
- Zabbix Senderで複数の値を一括登録: ike-daiの日記
- zabbix_senderが素晴らしすぎる件: zabbiたん AMIたん
- zabbix_agentdの設定パラメータのTimeout値について – ZABBIX-JP
- アイテムの状態が「取得不可」となっているアイテムの数を監視したい – ZABBIX-JP
- Zabbix SIAのオフィシャルRPMパッケージの事前公開 – Kodai’s Blog
- 24 については rsync(1) の man を参照下さい。実質的に問題はないため障害扱いしていません。 [↩]