一時期はサーバの死活監視・リソースチェックといえばNagios + Cacti/MRTGでしたが、最近はZABBIXが割と話題に上ることも多いので、昨年末に1.8がリリースされたこともあり、筆者自宅での事例を交えつつご紹介したいと思います。

ZABBIXとは?

• Nagiosでのリソース監視/死活監視、Cactiなどでの視覚化をワンパッケージで。
  • 1.6は監視のための負荷が結構あったが、1.8で改善された印象。
  • ホストの死活監視。
  • リソース監視。
  • サービスの死活監視。
  • プロセスの死活監視・同時実行数の監視など。
  • HTTPベースでのWebサイト死活監視。
• SNMP以外に、各ホストで実行するZABBIXエージェントでのポーリングが可能。
• 任意のトリガーに対するアクションで、ZABBIXエージェントに任意のコマンドを実行させることが可能。
  • ネットワークが回復したらデーモンを再起動。
  • 監視対象が落ちたらアラート。 etc.
  • 複数ホストのリソースを1画面で監視。

必要なもの

• ZABBIXサーバ・フロントエンド
  • MySQLやPostgreSQLなどのRDB。なければsqliteでも可。
  • PHP 5.2。5.3では何かと問題が。
• ZABBIXエージェント
  • KIAI

監視の流れ

3つの要素

• アイテム - ZABBIXでの監視対象。CPU負荷、プロセス数 etc.
• トリガー - アイテムに対する監視条件。
• アクション - トリガーと組み合わせて、条件を満たしたときに行うアクション。
  • メール通知
  • 任意のホスト上のZABBIXエージェントでコマンドを実行。etc.

上記3つを組み合わせて、監視対象と「問題」とする閾値、そしてそれに対するアクションを設定していく。

深刻度

トリガーには以下の4通りの深刻度がある。

• 致命的
• 重度
• 軽度
• 情報

アクションの実行条件で、「トリガーの深刻度が一定以上の場合」といった設定も可能。

監視設定

深刻度が一定以上の場合にアラートメール

Nagiosなどでもよくあるアラートメールを、各観測値ではなくトリガーの深刻度が一定以上の場合に送信するようにしてみます。なお、事前に送信対象のユーザのメールアドレスを設定しておく必要があります。

1. [設定]→[アクション]→[アクションの作成]
2. 名前は適当に設定。
3. [アクションのコンディション - 新規]→[トリガーの深刻度][>=][任意の深刻度]と設定→追加
4. [アクションのオペレーション - 追加]→[オペレーションのタイプ]を[メッセージの送信]→メールの送信先を適宜設定→[ユーザのメディア]を[Email]→[追加]
5. [アクション]のところの[保存]

Web死活監視

Web死活監視を行うには、Web死活監視用のアイテム(シナリオ)を追加します。

1. [設定]→[ウェブ]→[シナリオの追加]
2. [アプリケーション]は適宜選択。「Web Services」など追加してもいいかもしれません。追加は[設定]→[アプリケーション]→[アプリケーションの作成]です。
3. [名前]は適当に設定。
4. [Basic認証] - ZABBIX 1.8から追加になりました。必要に応じて設定します。
5. [更新間隔]は必要がない限りデフォルトの60秒で問題ないかと思います。
6. [エージェント] - 偽装するユーザエージェントを適宜選択します。
7. [変数]は必要がない限り空欄でokです。
8. [ステップ]→[追加]で、実際にどこにアクセスして何が返ってくるべきかを設定します。ステップは複数指定できます。
   1. [名前]は適当に設定。
   2. [URL]は、アクセス先のURLを設定します。
   3. POSTメソッドで何らかのパラメータを与える場合は[POST]に設定します。設定しない場合はGETでアクセスします。
   4. [タイムアウト]はデフォルトで問題ないかと思いますが、Railsアプリケーションなどのようにレスポンスが返ってくるまでに時間がかかる可能性がある場合は適宜のばすといいでしょう。
   5. [要求文字列]は、レスポンスに指定した文字列が含まれるかをチェックします。
   6. [ステータスコード]は通常200で問題ありませんが、リダイレクトしたり特定のステータスであることを保証する必要がある場合は変更します。
   7. [保存]を押してステップを追加します。

シナリオを追加した後、それに対応するトリガーとアクションを設定してください。私の場合は面倒なのもあって、深刻度を「重度」にした上で、「重度」以上のトリガーが発生した場合はアラートメールを送信するようにしています。

アラートボイス

会社によっては、深刻な問題が発生したときにパトライトを回したりする会社があるようですが、個人環境なのにそれが羨ましかったのでアラートボイスを流す設定をしてみました。アラートボイスには、Falcon 4.0というゲームに含まれる「F-16C」戦闘機実機とほぼ同じ「WARNING!」という音声を選びました。

まず、ZABBIXエージェントがリモートコマンドを実行できるようにする必要があります。ZABBIXエージェントの設定ファイルを編集し、

EnableRemoteCommands=1

にした上でエージェントを再起動します。

次に、zabbixユーザから/dev/dsp*に読み書きできるようにします。筆者自宅環境のGentoo機ではaudioグループに追加すればいいので、

gpasswd -a zabbix audio

です。今回は/dev/dsp*にアクセスできればいいので問題ないのですが、例えばapacheが落ちたときにapacheを再起動したいといった場合は、zabbixユーザでsudoできるように設定する必要があります。

準備ができたら、あとは対応するアクションを設定します。[アクションのオペレーション - 追加]で[オペレーションのタイプ]を[リモートコマンド]に、[リモートコマンド]欄に実行するコマンドを記述します。コマンドを記述する際、先頭にコマンドを実行するホスト名を「:」区切りで書く必要があります。筆者環境の場合、ulyssesで/usr/local/bin/alert.shを実行ですので、

ulysses:/usr/local/bin/alert.sh {STATUS}

となります。引数の{STATUS}は、問題発生時に"PROBLEM"、回復時に"OK"が入ります。なお、ホスト名はDNS上のホスト名ではなく、ZABBIX上でのホスト名になります。

監視設定

勉強会では時間も限られていたので、フロントエンドのPHPスクリプトに手を入れないと日本語でグラフが表示されないといったインストールの苦労やインストール手順などは割愛しました。 グラフなどビジュアルな部分は「それを見てニヤニヤすること」がモチベーションとなりますが、様々な監視については万が一に備えてのものなのでどうしてもおざなりになり、実際に直面してからそれを監視対象に含めるという作業になりがちです。 ですので、今回はいくつかの監視パターンを中心にご紹介してみました。