====== アラート設定クイックガイド ======
===== Pandora FMS アラート設定クイックガイド =====
==== アラートシステムの概要 ====
{{ wiki:Esquema-alert-structure.png?700 }}
アラートは次の組み合わせです。
* コマンド
* アクション
* テンプレート
**コマンド**は、アラートが発生したときに実行する操作を定義します。コマンドの例としては、ログへの書き込み、email または SMS の送信、スクリプトの実行などです。
**アクション**は、テンプレートと共にコマンドに関連付けられており、フィールド1、フィールド2、フィールド3の 3つのパラメータを使ってコマンドを実行するようにカスタマイズできます。これらのパラメータは、コマンド実行時の引数として渡すことができるため、コマンドの実行をカスタマイズできます。
**テンプレート**では、アラートの発生条件、アクション、復旧通知といった一般的なパラメータを定義します。
* **発生条件**: アラートが発生する条件で、例えば、データが閾値を越えた場合や、状態が障害になった場合などです。
* **実行アクション**: アラートが発生した時に、実行するアクションの設定です。
* **復旧通知**: アラート発生後にシステムが復旧したときに実行するアクションの設定です。
=== アラートシステムの情報の流れ ===
アクションとテンプレートを定義するとき、コマンド実行のパラメータとなるフィールド(フィールド1、フィールド2 など)があります。これらのパラメータは、テンプレートからアクションに展開され、最終的にコマンドに渡されます。テンプレートからアクションへの引き渡しは、アクションのフィールド設定が空の場合のみ行われます。アクションで値が定義されていればそれが利用され、定義されていなければ、テンプレートの値が使われます。
例1: テンプレートのフィールド1とフィールド2が定義されており、アクションでは定義されていない場合、テンプレートの値を継承してコマンドパラメータとします。
例2: テンプレートのフィールド1とフィールド2が定義されており、かつアクションにも定義されている場合、テンプレートの値は継承せず、アクションの値を使います。
{{ wiki:Esquema-parameters-carrying.png?700 }}
以下は、アクションによってテンプレートの値がどのように上書きされるかの例です。
{{ wiki:Alertas esquema6.png?700 }}
例として、次のフィールド設定で、アラート発生時にメールを送信するテンプレートを作成します。
* **テンプレート**:
* フィールド1: myemail@domain.com
* フィールド2: [Alert] The alert was fired
* フィールド3: The alert was fired!!! SOS!!!
* **アクション**:
* フィールド1: myboss@domain.com
* フィールド2:
* フィールド3:
コマンドに渡される値は次のようになります。
* **コマンド**:
* フィールド1: myboss@domain.com
* フィールド2: [Alert] The alert was fired
* フィールド3: The alert was fired!!! SOS!!!
==== アラートの作成 ====
ここで、上記のような例を仮定すると、まずは数値データのモジュールを一つモニタします。以下の例では、system CPU 使用率をモニタするモジュールをとりあげます。温度を返す温度センサーなどでも良いです。まず最初に、モジュールがデータを正しく受け取っているかを見てみましょう。
{{ wiki:Qgcpu1.png }}
このスクリーンショットでは、//sys_cpu// というモジュールがあり、現在の値が 7 であるということが解ります。この例では、この値が 20以上になったらアラートを上げたいと考えます。そのためには、20以上の値になったら、障害状態になるようにモジュールを設定します。設定するには、スパナアイコンをクリックします。
{{ wiki:Qgcpu2.png }}
以下の画面の赤で囲っている部分の値を設定します。
{{ wiki:threshold.JPG?800 }}
設定を反映させます。これで、CPU モジュールの値が 20以上になるとステータスが障害状態になり、次のように赤い表示になります。
{{ wiki:Qgcpu4.png?800 }}
以上で、どのような時が正常 (正常で緑表示) で、どのような時が異常 (障害で赤表示) かをシステムが認識するようになりました。次のすべきは、モジュールが障害状態になったときにメール通知する設定です。そのためには、Pandora FMS アラートシステムを利用します。
この設定をするには、まずは、必要なコマンド (メールを送る) が一つあるということを確認する必要があります。この例では、Pandora FMS にあらかじめ定義されているメール送信コマンドを利用するので簡単です。必要に応じて、スクリプトの実行や外部のチケットをオープンするなどの任意のコマンドを作成することもできます。
==== アクションの設定 ====
まずは、"Send an email to the operator" というアクションを作成しないといけません。新たなアクションを作成するには、システム管理メニューから、アラート管理 -> アクションの順にクリックします。
{{ wiki:Qgcpu5.png?700 }}
このアクションでは、eMail というメールを送信するコマンドを使います。これはとても簡単で、一つのフィールド (フィールド 1) だけ設定すれば良く、他の 2つの設定は不要です。**フィールド1、2、3 は何か**というのは、Pandora FMS のアラートシステムの中で最もわかりにくい部分の一つです。
これらのフィールドは、アラートテンプレートの情報をコマンド設定へ "渡す" ために利用されます。また、そこから、実際に実行されるコマンドに渡されます。つまり、テンプレートとコマンド設定の両方から、異なる情報を実行されるコマンドに与えることができます。この場合、コマンドに対してフィールド 1のみを指定し、フィールド 2 と 3 は設定していません。
フィールド 1 にはオペレータのメールアドレスを設定します。この例では、"sancho.lerena@notexist.com" 宛にメールを送ります。
==== テンプレートの設定 (アラートテンプレート) ====
次に、後から使えるように可能な限り一般的な内容で、アラートテンプレートを作成する必要があります。これは、"モジュールが障害状態であることを認識" し、デフォルトとして、オペレータにメールを送信します。システム管理メニューから、「アラート管理」->「テンプレート」をクリックして、「作成」ボタンをクリックしてください。
{{ wiki:Qgcpu6.png?700 }}
最初のステップは、アラートの特定の要素の定義です。この場合、"Critical status" と設定されていますが、この段階ではモジュールの "障害" 状態に対しては何も定義しません。優先順位付けしたアラートはイベントビューワ内に決められた色で表示されますが、機能レベルでは、アラートの処理には影響しません。ステップ2では、アラートが正しく動作するための最も重要なパラメータのいくつかが見られます。
{{ wiki:Qgcpu7.png?700 }}
"**条件種別(Condition Type)**" フィールドは、アラートを発報させる条件を定義します。この例では、"障害状態(Critical Status)" となっており、モジュールの状態に関連付けられます。モジュールの状態が障害になると発報します。"cpu_user" が 20以上になった場合に障害状態を表示するためには、あらかじめそのモジュールの設定を行っておく必要があります。
ステップ2では、アラートの時間範囲、時間ごとや一週間のうちの何曜日かといった発報条件も設定します。
これらは、特定の日や時間のみにアラートアクションを実行するように制限します。
最も重要なパラメータは次の通りです。
* 再通知間隔(Time threshhold): デフォルトでは 1日です。例では 1日ですが、5分に設定すると、モジュールが常にダウン状態の場合、5分間隔でアラート通知されます。もし、1日 (24時間) に設定すると、ダウンしたときに、まず一度アラート通知します。モジュールが復旧し、再びダウンすると、再びアラート通知します。しかし、二度目のダウンからダウン状態が続いても、24時間以内であればアラートを通知しません。
* 最小アラート数(Min. Number of alerts): Pandora FMS がアラートテンプレートで定義したアクションを実行する状態変化 (この例では、モジュールの障害状態) の回数です。この設定により、正常状態と障害状態を繰り返す大量のアラートが発生を避けることができます。ここに 1を設定すると、モジュールの一度の障害状態は無視します。0 を設定すると、モジュールの初回の障害状態でアラート通知がされます。
* 最大アラート数(Max. Number of alerts): 1 は、アクションを一度だけ実行することを意味します。もし、ここに 10 を設定すると、アクションを 10回実行します。この設定により、アラートの実行回数を制限することができます。
再び、"フィールド1(field1)"、"フィールド2(field2)"、"フィールド3(field3)" があります。フィールド1(field1)には何も書かれていませんが、これによりアクションを設定したときに定義したものが使われます。フィールド2(field2)およびフィールド3(field3)は、メール送信のアクションで件名と本文として使われます。ここで、フィールド1(field1)は、受信アドレス (カンマ区切りで複数書けます) の定義をすることもできます。テンプレートは、マクロを使って件名と本文を定義します。この例では、次のようなメールが送信されます。("Farscape" というエージェントのモジュールを想定)
To: sancho.lerena@notexist.ocm
Subject: [PANDORA] Farscape cpu_sys is in CRITICAL status with value 20
Texto email:
This is an automated alert generated by Pandora FMS
Please contact your Pandora FMS for more information. *DO NOT* reply this email.
下に、前もって定義したデフォルトのアクションが表示されます。このテンプレートを利用する全てのアラートは、設定を変更しなければデフォルトでこの定義済アクションを利用します。
次のステップ3では、障害状態が復旧したときの通知に関する設定をみていきます。
{{ wiki:Qgcpu8.png }}
{{ wiki:Qgcpu8_1.png }}
アラートテンプレートの本文には、HTML とプレーンテキストが利用できます。
ほとんど一緒ですが、フィールド1(field1)がありません。なぜなら、(アラート通知時に) 実行されたアクションと同じだからです。この例では、cpu-syst モジュールが復旧したということを示す件名のメールを送るだけです。
復旧アラートはオプションです。復旧アラートのデータはここのフィールド(フィールド2 および 3)で定義されるという点が重要です。アクションのフィールド設定内容は "無視され、上書き" され、ここの設定が参照されます。唯一変更できないのは、フィールド1(field1)です。
==== アラートのモジュールへの関連付け ====
以上で、必要な設定が完了しました。あとは、アラートテンプレートをモジュールに関連づけるだけです。そのためには、エージェントのモジュールのアラートタブへいきます。
{{ wiki:Qgcpu9.png?700 }}
設定は簡単です。この画面ショットでは、 "Last_Backup_Unixtime" というモジュールに対して、事前に定義した "Module critical" というアラートが設定されています。加えて、ここでは下の画面を操作して、モジュール "cpu-sys" と、アラートテンプレート "Module critical" を関連づけようとしています。デフォルトで、このテンプレートで設定した "Sancho Lerena へメールを送信する" というアクションが表示されています。
==== アラートのスケーリング ====
"アクションを起こすアラートの数(Number of alerts match from)" では、アラートのスケーリングを定義します。これにより、アラート頻度を少し "再調整" することができます。例えば、最大値を 5 に設定すると、その回数だけアラートが発生します。また、1回のみ通知したい場合は、0 と 1 を設定します。そうすると、0 から 1回の間で (つまり一度だけ) メールが送信されます。
一つのアラートに複数のアクションを設定することができます。それぞれに対して "アクションを起こすアラートの数(Number of alerts match from)" を定義することにより、何回通知するかを設定できます。
例えば、最初の障害発生時は XXXXX にメールを送り、障害状態が継続している場合は ZZZZ にメールを送信したい場合があったとします。そのためには、アラートの関連付のあとに、割り当てられたアラートに定義済のアクションを追加することができます。以下に画面ショットを示します。
{{ wiki:Qgcpu9.png?700 }}
{{ wiki:Qgcpu10.png?700 }}
==== アラートのスタンバイ ====
アラートは、有効・無効やスタンバイにすることができます。アラートの無効化とスタンバイの違いは、無効化ではアラートは動作ぜずアラートビューにも表示されませんが、スタンバイは、アラートビューへの表示だけは実行されます。アラートが発生すると、アクションおよびイベントの生成は行われません。
スタンバイアラートは、アラートを受ける人に迷惑をかけることなく表示だけする場合に便利です。
==== メール送信以外のアラートコマンドの利用 ====
メール送信は、Pandora FMS の内部コマンドであり、フィールド1、フィールド2、フィールド3 はそれぞれメール送信先、件名、本文として使うように定義されており変更することはできません。では、別のアクションを自分で定義したい時はどうすれば良いでしょうか。
この場合は、新たなコマンドの定義画面へ行き、自分で定義を行います。検知したアラートそれぞれのログファイルを作成したいとします。ログファイルのフォーマットは次のようなものを想定します。
DATE_ HOUR - NAME_AGENT - NAME_MODULE - VALUE - PROBLEM DESCRIPTION
ここで、VALUE は、そのときのモジュールの値です。コマンドを呼び出すアクションごとに、ログファイルができます。アクションでは、説明と、どのイベントをファイルに書くかを定義します。
そのためには、次のようにコマンドの作成へ行きます。
{{ wiki:Qgcpu11.png?700 }}
そして、アクションを定義します。
{{ wiki:Qgcpu12.png?700 }}
作成したログを見ると次のようになっています。
2010-05-25 18:17:10 - farscape - cpu_sys - 23.00 - Custom alert for LOG#1
アラートは、"farscape" エージェントの "cpu_sys" モジュールで、18:17:10 に発生したこと、また、現在のデータは "23.00" であり、アクションで設定した説明が含まれていることがわかります。
コマンド実行時に、フィールドやその他がどのように引き渡されて実行されたかは簡単にはわかりません。それを確認する簡単な方法は、pandora サーバの設定ファイル /etc/pandora/pandora_server.conf にて、デバッグトレースを有効にする (verbose 10) ことです。
そして、Pandora FMS サーバがどのようにコマンドを実行しているか確認するには、サーバを再起動し (/etc/init.d/pandora_server restart)、///var/log/pandora/pandora_server.log// に出力されている定義されたアラートの実行ログを探します。