Pandra FMSならではの便利な監視設定

2014年7月22日(火)
株式会社アールワークス

「Webサービス」画面の表示

監視項目編集画面に必要な情報を入力して「作成」をクリックすると、先ほど作成したWeb1の、HTTP応答モジュールがリストアップされた状態のサービスエレメント管理画面に戻るので、同様に、Web2~Web5のHTTP応答モジュールも登録する。

Web1~Web5のHTTP応答モジュールの登録が終了したら、設定は完了である。操作メニューの「サービス」をクリックすると、作成した「Webサービス」が表示されているはずなので、それをクリックしてみてほしい。図4-16のような画面が表示されるはずである。

図3では、Web1~Web4のHTTP応答は「OK」だが、Web5のHTTP応答が「CRITICAL」になっているため、サービスの値としては、Web1~Web4の正常ウエイトの「0」とWeb5の障害ウエイトの「1」が足し合わされ、合計で「1」となる。「1」以上「3」未満の値は、「警告」となるため、状態が「WARNING」になっている。

図3 サービス詳細表示画面
図3:サービス詳細表示画面

「サービス」のモジュール登録

これで、Webサーバー2台までの障害なら「警告」、3台以上の障害なら「障害」となるサービス「ウェブサービス」を定義することができたが、サービスの状態に連動してメール通知などを行うためには、サービスを特定のエージェントに予測サーバーモジュールとして登録し、アラートを設定する必要がある。特定のエージェントに予測サーバーモジュールとして登録し、アラートを設定する必要がある。

エージェントのモジュール管理画面で、「予測サーバーモジュールの新規作成」を選択し、「作成」をクリックすると、図4のような画面になる。

図4 サービスのモジュール登録
図4:サービスのモジュール登録

ここで、対象モジュールに「サービス」を選択すると、定義済みのサービスを選択できるようになるので、ここで「サービス」を選択し、「作成」をクリックする。これで通常のモジュールのように、アラートテンプレートを設定できるので、モジュールが警告状態と障害状態のそれぞれに、営業時間用と休日・夜間用のアラートテンプレートを設定し、各テンプレートに、適切な通知先を設定したメール送信用のアクションを設定すればよい。

ポリシーによる監視設定の適用

Pandora FMSのエンタープライズ版には、「ポリシー」と呼ばれる機能があり、この機能を使うことで、エージェントへのモジュールやアラートの登録を半自動化できる。

この機能を活用することで、監視対象機器の増加に伴う運用コストを大幅に削減できる。

関連付けアラート

Pandora FMSには、サービス監視機能とは別に、アラートの状態を組み合わせた複合的なアラートを作成する、「関連付けアラート」と呼ばれる機能がある。この機能を使うと、例えば、アクティブ側のネットワーク機器で障害が発生した場合には、夜間や休日であっても運用担当者に緊急のアラート通知を行うが、スタンバイ側のネットワーク機器で障害が発生した場合には、夜間や休日の緊急通知は行わない、といったような設定が可能になる。

ソフトウェアエージェントの便利な機能

最後に、ソフトウェアエージェントの機能について、少し述べておこう。

ソフトウェアエージェントには、モジュールの結果に応じて、コマンドを実行することができる機能がある。これを使うと、例えば、プロセスが存在しない場合に起動を試みたり、サーバーローカルでのHTTP応答チェックが障害になった場合に、ロードバランサーのヘルスチェックページを削除などして、自主的にロードバランサーから切り離されるようにする、といったことが実現できる。

例えば、サーバーローカルのHTTP応答チェックを行うモジュールが、[リスト1]のように実装されていたとしよう。

[リスト1]サーバーローカルのHTTP応答チェックを行うモジュール例
module_begin module_name HTTP応答
module_type generic_proc
module_exec  /path/to/check_webapp.sh
module_description ローカルの  HTTP 応答状態
module_end

ここで、check_webapp.shは、正常時には「1」、障害時には「0」を標準出力に出力するスクリプトで、Webアプリケーションが正常に稼働していることを担保できるものであるとする。

「障害時にロードバランサーから切り離される」の実現方法はいくつか考えられるが、ここでは、「障害時にロードバランサーのヘルスチェック用のページを削除する」という方法を採用することにする。また、復旧時には、自動的にロードバランス対象に組み入れられるよう、正常時にはヘルスチェック用のページを生成する、という処理も付け加えよう。これらは、[リスト2]のような行を"module_end"の前に追加することで、実現できる。

[リスト2]障害時にロードバランサーから切り離す例
module_condition = 1 touch /path/to/lb-helth-check.html
module_condition = 0 rm  /path/to/lb-helth-check.html

これで、監視上障害と判断した場合には、必ずロードバランサーからも切り離されるようになるはずである。

著者
株式会社アールワークス
1985年に株式会社アステックとして創業。2000年10月の株式会社アールワークス設立を経て、2005年6月より現在の1社体制に移行。同時に、社名を(株)アールワークス(Rworks, Inc.)に変更。
設立以来、IDC事業やITマネージドサービスを行い、そこで培ったネットワークインフラの運用ノウハウや、さまざまなソフトウェアを開発した技術力を結集し、現在、ITシステムのリモート運用サービスをはじめとして、インフラ構築、ハウジングやホスティングサービス、SaaS/ASP型のシステム監視基盤の提供を行う。単純なオペレーターではない技術提供をベースにした24時間365日の統合的なフルマネージドサービスを提供している。

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています