アラートシステム

Pandora FMS ドキュメント一覧に戻る

アラートは、モジュールの値が変化したときに Pandora FMS が行う動作の定義です。このような動作は設定可能で、管理者へメールやSMS を送ったり、SNMP トラップの送信、システムログへのインシデントの記録などができます。アラートは、基本的に、モジュールを実行している Pandora FMS サーバが動作している OS 上で、アクションから起動させるスクリプトです。

アラートにはいくつかのタイプがあります。

• 単一アラート
• イベントアラート
• SNMPトラップアラート

この章では、最初の 2つのタイプにおけるアラートシステムについて説明します。

Pandora FMS では、アラートはいくつかの発報条件、そのアラートのために選択されたアクション、そして、設定されたアクションの実行を担当する Pandora FMS サーバにおけるいくつかのコマンド実行の定義によって動作します。

一般的なアラートシステムは、各モジュールに一つのアラートを関連付けます。アラートは、一つ以上のアクションを実行できます。

ビデオチュートリアル «Do not panic: we talk about alert systems» も参照ください。

アラートは次の組み合わせです。

• コマンド: アラートが発生したときに Pandora FMS サーバが実行するコマンド定義します。コマンドの例としては、ログへの書き込み、email または SMS の送信、スクリプトの実行などです。
• アクション: これは「どのように行われるか」を定義するものであり、コマンドの引数のカスタマイズです。モジュール名やエージェントなどの特定のパラメータをコマンドに渡して、コマンド実行をカスタマイズすることができます。
• テンプレート: これは、「いつ実行されるのか」を指定し、アクションを引き起こす条件を定義します。 たとえば、モジュールが障害状態になった場合などです。

アクションとテンプレートを定義するとき、'フィールド1'、'フィールド2'、'フィールド3' といったアラートをカスタマイズするために使う一般的なフィールドがあります。

これらのフィールドは、テンプレート → アクション → コマンド という情報の伝達の優先順位に従って適用され、最後にはコマンドの実行パラメータとして使われます。

次のステップの Fieldn フィールドに情報が定義されていないと、前のステップの情報が引き継がれます。 つまり、フィールドまたはパラメータが上書きされるというのは、アクションのフィールド設定はテンプレートのフィールド設定を上書きするということです。(たとえば、テンプレートに field1 が定義されていて、アクションも定義されている場合、アクションの field1 の設定が利用されます。)

次の図は、テンプレートからコマンドへのこのパラメータの受け渡しを示しています。

これは、テンプレートの値がアクションの値で上書きされる例です。

例として、次のフィールド設定で、アラート発生時にメールを送信するテンプレートを作成します。

• テンプレート:
  • フィールド1: [email protected]
  • フィールド2: [Alert] The alert was fired
  • フィールド3: The alert was fired!!! SOS!!!

• アクション:
  • フィールド1: [email protected]
  • フィールド2:
  • フィールド3:

コマンドに渡される値は次のようになります。

• コマンド:
  • フィールド1: [email protected]
  • フィールド2: [Alert] The alert was fired
  • フィールド3: The alert was fired!!! SOS!!!

フィールド2 と フィールド3 については、テンプレートで定義された値が使われますが、フィールド1 の場合は、アクションで定義された値が使用されます。

異常値を検知した場合、Pandora FMS はさまざまな動作ができます。syslog への記録、メールや SMS の送信、また、Pandora FMS サーバ上でのスクリプトの実行が可能です。

前章の画面の 作成(Create) をクリックすると、次のような画面が表示されます。

以下に、各フィールドについて説明します。

名前 コマンドの名前です。解りやすく簡潔に書きます。例えば、「ログ出力」など。

コマンド アラートが発報したときに実行されるコマンドです。マクロを使用すると、アラートで設定されたパラメータを置き換えることができます。 使用できるマクロは、以降のマクロの章で詳しく説明します。

グループ

コマンドグループです。どのアラートのコマンドが関連付けられるかを定義します。ユーザが"すべて"グループに属してない場合は、アラートコマンドを作成するユーザが属するグループのみを割り当てることができます。

フィールドの説明(Field description) および フィールドの値(field values): カスタムフィールドごとに、以下を設定できます。

• フィールドの説明(Field description): コマンドアクションの設定フォームのテキストボックスの横にあるラベル。

• とり得る値(Possible values): そのフィールドがとり得る値のコレクション。 フィールドが設定されている場合(空ではない場合)、テキストボックスではなく選択コンボになります。 コンボには、可能な値ごとにタグ(表示オプション)と値(送信オプション)が必要です。 サポートされている構文は次のとおりです。

value1,tag1;value2,tag2;value3,tag3

• 隠す(Hide): フィールドにパスワードなどを含める場合、このオプションでコンテンツをアスタリスクで隠すことができます。

すべてのパラメータを入力したら、作成(Create) ボタンをクリックします。

最初の4つの数字を選択できる単純なフィールド：

1,Number one;2,Number two;3,Number three;4,Number four

コマンド(command) フィールドを設定する必要があります。

アクション(action) へ行くと、次のような画面が見られます。

コマンド設定で使用できるマクロは、この章の最後の マクロ一覧 にあります。

Pandora FMS アラートシステムで利用できるようにあらかじめ定義されたコマンドがあります。

eMail

Pandora FMS サーバからメールを送信します。Perl の sendmail モジュールを利用します。メールは HTML 形式で送信されるため、視覚的に魅力的なテンプレートを作成できます。メールの受信者は、画像などテンプレートで使用されるリソースにアクセスできる必要があることに注意してください。

Internal audit

これは、Pandora FMS の内部監査システムに記録を残す内部アラートです。これは、Pandora FMS のデータベースに保存され、コンソールのイベントビューワから確認することができます。

Pandora FMS Event

Pandora FMS イベントマネージャにカスタムイベントを生成します。

Pandora FMS Alertlog

/var/log/pandora/pandora_alert.log に、プレーンテキストのログファイルとしてアラートを出力します。

SNMP Trap

引数を使って SNMP トラップを送信します。

Syslog

アラートを syslog に飛ばします。システムの logger コマンドを利用します。

Sound Alert

アラートが発生した時に音を鳴らします。

Jabber Alert

事前に定義したサーバのチャットルームに Jabber アラートを送信します(先に .sendxmpprc ファイルを編集します)。フィールド3 をテキストメッセージに利用し、フィールド1 が発信者の名前、フィールド2 がチャットルーム名です。

SMS Text

指定した携帯に SMS を送信します。ただし、これが実行できるようにアラートを事前に定義しておく必要があります。また、Pandora FMS から SMS を送信できるように設定したゲートウェイが必要です。また、SMS を送信するのみ Gnokii をインストールすることも可能です。この場合、ノキアの携帯を USB ケーブルで接続して直接送信できます。具体的方法は別途説明しています。

Validate Event

モジュールに関連するすべてのイベントを承諾します。エージェント名とモジュール名を指定します。

Remote agent control

このコマンドは、UDP サーバが有効になっているエージェントにコマンドを送信するために使用します。UDP サーバは、エージェント(Windows および UNIX)にエージェントの実行を “リフレッシュ” するように命令するために使用されます。つまり、エージェントにデータの実行と送信を強制します。

Generate Notification

このコマンドを使用すると、任意のユーザまたはグループに内部通知を送信できます。

Send report by e-mail および Send report by e-mail (from template)

どちらのオプションでも、さまざまな形式(XML、PDF、JSON、CSV)のレポートをメールで送信できます。2番目のオプションでは、添付レポートにテンプレートを使用できます。

アラート(Alerts) → コマンド(Commands) をクリックすることにより、新たに作成されたアラートコマンドを編集できます。

アラートのコマンドを編集するには、コマンド名をクリックします。

選択したコマンドの編集を行ったら、更新(Update) ボタンをクリックします。

削除(Delete): アラートを削除するには、アラートの右側にあるグレーのごみ箱アイコンをクリックします。

複製(Copy): アラートはコピーすることができます。フィールドやグループなどの詳細を変更することで、既存のコマンドと似たのコマンドを作成する場合に便利です。

eMail 、Internal Audit および、Pandora FMS Event は削除や複製はできません。

Jabber サーバを通して、アラートを送信するように Pandora FMS を設定するのはとても簡単です。Jabber はログだけでなく、アラートをリアルタイムで送ることができるシステムで、アラートを受け取る人のグループを設定することができます。

Jabber サービスのインストール

クライアント側の手順:

1. Gaim (Pidgin ) などの Jabber クライアントをインストールします。
2. アカウントを登録します。(Pigdin にて、“Accounts” タブをクリックしてアカウントを設定します。)
3. 登録したアカウントでログインします。

Pandora FMS サーバ側の手順:

1. sendxmpp をインストールします。このツールにより、Pandora FMS サーバが Jabber サービスにメッセージを送信できるようになります。
2. /home 以下に、.sendxmpprc ファイルを作成します。
3. ファイルを編集し、次のような設定を行います。

[email protected] password

1. ファイルのパーミッションを変更します。

  chmod 0600 .sendxmpprc

以上で、次のようにコマンドラインからメッセージを送信できるようになります。

  $ echo "Hello" | sendxmpp -s pandora [email protected]

Pandora FMS のウェブコンソールにアラートを登録するには、新たなコマンドを追加し、その設定を行います。次のようにすると良いでしょう。

• フィールド1: Jabber アドレス
• フィールド2: テキスト

コマンドを次のように定義します。

echo _field2_ | sendxmpp -s pandora _field1_

Jabber 利用例

チャットルームへメッセージを送信します:

  $ echo "Dinner Time" | sendxmpp -r TheCook --chatroom [email protected]

ログの出力を Jabber に送信します:

  $ tail -f /var/log/syslog | sendxmpp -i [email protected]

注意: 公開 Jabber サーバに負荷をかけたり、利用を拒否されないように気をつけてください。

メールの送信をするのに、SMTP 認証を利用する必要がある場合があります。Pandora FMS には、コンソールの一般設定 に通常のメール転送に必要なすべてのものがあり、メール転送システムを確認するためにテストメールを送信することもできます。 しかし、sendmail の認証設定を行う代わりに Expect スクリプトを使う方が簡単で融通がきくかもしれません。

Expect は、 telnet, ftp, passwd, fsck, rlogin, tip などのインタラクティブな操作が必要なアプリケーションを自動化するツールです。 Expect はそれらを簡単なものにし、同じアプリケーションをテストすることも役立ちます。 Expect は、他のツールでは通常不可能なほど困難なあらゆる種類のタスクを簡単にすることができます。 Expect は非常に貴重なツールであることがわかります。これまで自動化することを考えたことのないタスクを自動化でき、簡単に実行できるようになります。

ここでは、Exchange サーバを使ってメールを送信する場合に、EXPECT を使う例を示します。

/root/smtp というファイルを以下の内容で作成します。

#!/usr/bin/expect -f
set arg1 [lindex $argv 0]
set arg2 [lindex $argv 1]
set arg3 [lindex $argv 2]
set timeout 1
spawn telnet myserver.com 25
expect "220"
send "ehlo mymachine.mydomain.com\r"
expect "250"
send "AUTH login\r"
expect "334"
send "2342348werhkwjernsdf78sdf3w4rwe32wer=\r"
expect "334"
send "YRejewrhneruT==\r"
expect "235"
send "MAIL FROM: [email protected]\r"
expect "Sender OK"
send "RCPT TO: $arg1\r"
expect "250"
send "data\r"
expect "354"
send "Subject: $arg2\r"
send "$arg3 \r\r"
send ".\r"
expect "delivery"
send "quit"
quit

ファイルのパーミッションに実行権限を付けます。

chmod 700 /root/smtp

利用してみる前に、次のスクリプトを保存、実行権限をつけて用意し、/usr/bin/expect が正しく動作するかどうか確認してください。

#!/usr/bin/expect -f

spawn date
sleep 20
expect

Pandora FMS でこれを利用するには、新たなコマンドを作成する (もしくは既存のメール送信コマンドを編集する) 必要があります。Pandora FMS アラートコマンドの “コマンド(Command)” フィールドで次の設定をします。

/root/smtp _field1_ _field2_ _field3_

スクリプトはシステムのどこにあっても構いません。アラートスクリプトは、データを処理するサーバから起動されるということだけ認識しておいてください。ネットワークデータであれば、ネットワークサーバです。XML ファイルを通してエージェントから送られてくるデータであれば、データサーバです。

もし、複数のサーバがある場合は、アラートを実行したい全 Pandora FMS サーバに対して、同じスクリプトを同じ場所に同じユーザおよび同じパーミッションでコピーする必要があります。

コマンドは、Pandora FMS サーバのプロセスを実行しているユーザの権限にて実行されます。

Nokia の携帯電話もしくは、Gnokii に対応した携帯電話 (対応携帯かどうかは Gnokii プロジェクトページを確認してください) を利用するために、Gnokii を利用できます。また、Pandora FMS サーバから SMS アラートを送信するには、携帯電話と接続するための USB ケーブルが必要です。

Gnokii は、多くの Nokia 携帯およびいくつかのその他携帯をサポートしています。

Gnokii を使って、コマンドラインから SMS を送信することができます。この方法は、インターネットを通して SMS を送信するゲートウェイを利用する必要がなく、専用の高い GSM のハードウエアを使う必要もなく、Pandora FMS サーバから直接 SMS を送信するのにとても簡単な方法です (ネットワークがダウンしていても使えます)。

Gnokii の他には、Gammu というプロジェクトもあります。

Gnokii で SMS を送信するコマンドラインの例を示します。

echo "PANDORA: Server XXXX is down at XXXXX" | gnokii --sendsms 555123123

Gnokii は、画像を添付しての SMS 送信はできません。しかしメッセージを受信したときに参照する URL を次のように送信することができます。

echo "Image capture sample" | gnokii --sendsms 555123123 -w http://artica.homelinux.com/capture.jpg

画像の URL を送信したり、携帯からコンソールへアクセスしたり分析データにアクセスするような URL を送信することができます。

開発チームでは、インターネット接続が出来ない状態での Nokia 6030 携帯から SMS の送信をテストしています。Nokia 6030 携帯では、gnokiirc ファイルの module 6510 の定義を利用します。SMS の送信には約 4秒かかります。

Gnokii の代わりに、より強力な送信を行える Gammu をインストールすることもできます。

時々、他のシステムでコマンドを実行したい場合があります。その場合は、ssh コマンドを利用します。コマンドを実行するシステムは UNIX システムで、ssh デーモンがインストールされ、起動されている必要があります。

コマンドを実行するマシンにアクセスしたときに、パスワード入力を求められるのを避けるには、リモートでコマンドを実行する Pandora サーバ側の公開鍵を、コマンドを実行するシステムに先にコピーしておく必要があります。

準備が完了したら、次のようにコマンドを設定します。

ssh [email protected] [_field1_]

_field1_ は変数です。好きなようにコマンドを設定できます。

アクションは、コマンド (前章にて説明) に、フィールド1、フィールド2 …、フィールド10 を関連付けた、アラートのコンポーネントです。

アクションは、どのように コマンドを起動するかを定義できます。

アラート(Alerts) → アクション(Action) および 作成(Create) をクリックすることにより新たなアクションを作成します。

作成(Create) をクリックすると、次のような画面が表示されます。

次に、各フィールドへ入力します。

名前(Name)

アクションの名前です。

グループ(Group)

アクショングループです。ユーザが"すべて"グループに属してない場合は、アクションを作成するユーザが属するグループのみを割り当てることができます。コマンドに 全て(All) 以外のグループが割り当てられている場合、コマンドに関連付けられたグループまたは 全て(All) グループのみをアクショングループとして設定できます。何らかの理由でこれが実行できない場合は、必要な権限を持つユーザによる修正を求める警告メッセージが表示されます。

コマンド(Command)

アラートが発生したときに実行されるコマンドをこのフィールドで定義します。Pandora にあらかじめ定義されているコマンド以外も選択できます。

しきい値(Threshold)

アクション実行の閾値です。

実行されるコマンドのプレビュー(Command Preview)

このフィールドは編集できません。システムで実行されるコマンドが自動的に表示されます。

フィールド 1-10(Field 1-10)

'_field1_' から '_field10_' までのマクロの値をここで定義します。必要に応じて、コマンドとともに使用することを目的としています。 これらのフィールドは、設定されている場合、テキストフィールドまたは選択メニューになります。

フィールドの入力が完了したら、作成(Create) ボタンをクリックします。

システム管理メニューの アラート管理 → アクション では、すでに作成済みのアクションを編集することも可能です。

アクションで利用できるマクロは、この章の最後のマクロ一覧にあります。

アクションを編集するには、アクション名をクリックします。

編集が完了したら、“更新(Update)” ボタンをクリックします。

アクションを削除するには、アクションの右にあるグレーのごみ箱アイコンをクリックします。

テンプレートは、アラート発報条件を定義します(いつ アクションを実行する必要があるか)。

アラートテンプレートはモジュールに関連付けられ、テンプレートの条件にマッチすると関連するアクションが実行されます。

Pandora FMS で多くの場合に利用される個々の汎用テンプレートグループを用意しておくことができます。

アラート(Alerts)メニュー → テンプレート(Templates) へ行きます。作成(Create)ボタンをクリックすることにより、新たなテンプレートを作成することができます。

各フィールドに入力します。

• 名前(Name): テンプレートの名前です。
• グループ(Group): テンプレートに割り当てられるグループです。ユーザが"すべて"グループに属してない場合は、テンプレートを作成するユーザが属するグループのみを割り当てることができます。
• 説明(Description): テンプレートの説明を入力します。他のテンプレートと区別するのに便利です。
• 優先度(Priority): アラートに関する情報を提供するフィールドです。 アラートが発報されると、生成されたイベントはこの優先度を継承します。 アラートを検索する際のフィルタリングに役立ちます。

以下から優先順位を選択します。

• メンテナンス(Maintenance)
• 情報(Informational)
• 正常(Normal)
• 警告(Warning)
• 障害(Critical)

特別日一覧を利用する(Use special days list)

テンプレートで利用する特別日のカレンダーを設定します。

スケジュール(Schedule)

アラートが発報される日です。

シンプルモードでデフォルトで表示される組み込みのエディターにより、アラートが毎日有効になるタイミングを表示および設定することができます。

このシンプルモードでは、毎日のアラート期間をクリックし、ポップアップフォームで開始時刻または終了時刻を設定することができます。 開始時間を 開始(From) フィールドに、終了時間を 終了(To) フィールドに入力します。削除(Remove) ボタンを使用して選択したアラート期間を削除するか、キャンセルCancel) ボタンを使用して変更を破棄、または、OK ボタンを使用してカレンダーを更新できます。

さらに、詳細モードにアクセスすることで、スケジュールをより正確に設定できます。 このモードでは、ポップアップフォームを使用して時間を調整することもできます。

• 毎日のアラート期間をクリックし、上端または下端をドラッグしてアラート期間を延長します。
• 移動するには、毎日のアラート期間の中央をクリックして、必要な場所にドラッグします。 ドラッグすると時間が変化します。
• 新たなアラート期間を追加するには、空のセルをクリックし期間をマークします。前の 2つの手順で説明したように、移動または変更できます。
• 削除するには、カレンダーからアラーム期間をドラッグして「ドロップ」します。

必要な数の期間を追加できます。 シンプルモードに戻ると、次のようになります。

再通知間隔(Time Threshold)

アラームカウンターをリセットする時間です。これは、アラートが アラートの最大数 を超えて再通知されないようにする時間間隔を定義します。指定された間隔の後、カウンターはリセットされます。アラートが復旧しない状態では、カウンターはリセットされません。アラートが継続しない場合にカウンターをリセット(Reset counter for non-sustained alerts) が有効化されていない限り、正常な状態に戻ってアラートが復旧した場合は、すぐにカウンターはリセットされます。

最小アラート数(Min. number of Alerts)

テンプレートに設定された条件を何回(モジュールの連続抑制回数パラメータで定義された数から数えます)満たした場合にアラートを発報するかの定義です。デフォルトは '0' です。これは、条件を満たす値が最初に受信されたときにアラートを発報することを意味します。これはフィルターとして機能することを目的としており、誤検知を排除するのに役立ちます。

最大アラート数(Max number of Alerts)

同じ時間間隔(再通知間隔)内で連続して送信できるアラートの最大数です。これは最大アラートカウンタ値です。 指定した数を超えるアラートは再通知間隔内では発報されません。

アラートが継続しない場合にカウンターをリセット(Reset counter for non-sustained alerts)

これを有効化すると、示された条件が連続して繰り返されない場合にアラートカウンターがリセットされます。これの有効化は、“最小アラート数” に示されている数が 0 より大きいことにも依存します。

“最小アラート数” フィールドの値が 2の場合、モジュールは “条件種別(Condition type)” で割り当てられた状態を 3回経てアラートを発報することを意味します。

これの動作には 2つのオプションがあります。

• この設定を有効化しない、次のようなシーケンスの後にアラートが発生します。

• この設定を有効化すると、障害の数は連続している必要があります。そうでない場合、カウンターはリセットされます。

イベントの無効化(Disable event)

これをチェックすると、アラートが発報されるときのイベントが生成されません。

通常のアクション(Default Action)

テンプレートが持つデフォルトのアクションをここで定義します。これは、テンプレートがモジュールに割り当てられたときに自動的に作成されるアクションになります。ここでは、1 つを割り当てるもしくは何も割り当てないことができますが、複数のデフォルトアクションを割り当てることはできません。

条件種類(Condition Type)

モジュールの値がどのような状態の時にアラートとするかを定義します。

選択した種類によって、追加の設定があります。以下に説明します。

• 正規表現(Regular Expression): 正規表現が使用されます。 モジュールの値が特定の要件を満たしている場合、アラートが発報されます。

正規表現を選択すると、それにマッチした場合かどうかを選択するチェックボックスが現れます。チェックした場合は、値が正規表現にマッチした場合にアラートが発生します。チェックしない場合は、値が正規表現にマッチしない場合にアラートが発生します。

• 最大および最小(Max and Min): 最大値と最小値が使われます。

'以下の値にマッチしたら、条件を満たしたと判断する(Trigger when matches the value)'をチェックすると、値が最大と最小の間の範囲に入った場合にアラートを発報します。チェックしないと、値が範囲に入っていないときにアラートを発報します。

• 最大(Max): 最大値が使われます。モジュールの値が指定した値より大きい場合にアラートが発生します。

• 最小(Min): 最小値が使われます。モジュールの値が指定した値より小さい場合にアラートが発生します。

• 同じ値(Equal to): モジュールの値が指定した値と同じになった場合にアラートが発生します。

• 異なる値(Not Equal to): 上記と同じですが条件が逆です。(論理的に NOT)

• モジュールスの状態(Module status)：その状態(障害状態、警告状態、不明状態、非正常状態)または値の変更が発生したかどうかが使われます。(ただし、値が一致したときに発報のチェックを外すと、変化発生 で 値が同じ場合 にもアラートが発生します。) または必要に応じて 常時(Always) を設定できます。

復旧アラート (Alert Recovery)

復旧アラートを有効にするかどうかを設定します。復旧アラートが有効になっている場合、モジュールがテンプレートで示された条件を満たさなくなったときに、このカラムに定義されているフィールドで指定された引数で関連付けられたアクションが実行されます。

フィールド 1 (Field 1) ~ フィールド 10 (Field 10)

後述するマクロを利用できます。

適切なフィールドをすべて入力したら、'終了(Finish)' をクリックします。

Field1 、… Field10 のすべてで使用できるマクロ(アラートテンプレートだけでなく、コマンドおよびアクションも含む)は、この章の最後にあるマクロ一覧に示します。これらのマクロのキーワードは、実行される際に値に置き換えられます。値は、アラートが発報した時間、エージェントなどによって異なります。

次のようなフォーマットでログファイルに記録したいとします。

2009-12-24 00:12:00 pandora [CRITICAL] Agent <agent_name> Data <module_data> Module <module_name> in CRITICAL status

コマンド設定

echo _timestamp_ pandora _field2_>> _field1_

アクション設定

 フィールド1 = /var/log/pandora/pandora_alert.log
 フィールド2 = <空白>
 フィールド3 = <空白>

テンプレート設定

フィールド1 = <空白>
フィールド2 = [CRITICAL] Agent _agent_ Data _data_ Module _module_ in CRITICAL status
フィールド3 = <空白>

復旧通知:

フィールド2 = [RECOVERED] [CRITICAL] Agent _agent_ Data _data_ Module _module_ in CRITICAL status
フィールド3 = <空白>

これにより、アラートが発生するとログに次の行が出力されます。

2009-10-13 13:37:00 pandora [CRITICAL] Agent raz0r Data 0.00 Module Host Alive in CRITICAL status

復旧時には、次の行が出力されます。

2009-10-13 13:41:55 pandora [RECOVERED] [CRITICAL] Agent raz0r Data 1.00 Module Host Alive in CRITICAL status

アラート(Alerts) → テンプレート(Template) へ行き、テンプレート名をクリックして編集します。

テンプレートを削除するには、右側の赤い×印のアイコンをクリックします。

アラートシステムに関する基本的な情報がわかったところで、アラートをモジュールへ割り当てる方法を示します。

アラート(Alerts) > アラート一覧(List of Alerts) へ行きます。その画面から、鉛筆アイコン(アラートビルダ)をクリックして新しいアラートを作成し、フィールドの設定をします。

入力フィールドは次の通りです。

• グループ(Group): エージェントが属するグループを選択します。
• エージェント(Agent): アラートを割り当てるエージェント名を入力します。
• モジュール(Module): アラートを発生させるモジュールを選択します。
• テンプレート(Template): 割り当てたいアラートテンプレートを選択します。
• アクション(Actions):テンプレートで定義済のアクションを選択します。あとから複数のアクションを設定することもできます。
• 閾値(Threshold): アラート発生回数に関係なく、'action_threshold' で指定した秒数内は、一回のみアラートアクションが実行されます。

アラートを作成すると、テンプレートが持っているアクションのみ編集することができます。

アクションの右側にあるグレーのごみ箱アイコンをクリックすることにより、選択したアラートを削除することもできます。また、“追加(Add)” ボタンをクリックすることにより新たに追加することもできます。

作成されたアラートに対して光っている(黄色)電球アイコンをクリックすると、そのアラートを無効化することができます。

有効なアラートは黄色の電球アイコン、無効なアラートは青の電球アイコンで表されます。

アラートの右にある赤い×印のアイコンをクリックすることにより、アラートを削除することができます。

エージェント管理画面から、関連するタブをクリックすることにより新たなアラートを追加することができます。

入力フィールドは次の通りです。

モジュール(Module)

エージェントモジュール一覧。

アクション(Actions)

アラートが発報されｒたときに実行されるアクション。

テンプレートにデフォルトがある場合は、デフォルトのままにします。

テンプレート(Template)

アラート発報設定を含むテンプレート。

閾値(Threshold)

アラートが発報された回数に関係なく、アラートアクションは action_threshold

秒ごとに1回の実行になります。

アラートを作成すると、テンプレートが持っているアクションのみ編集することができます。

アクションの右側にあるグレーのごみ箱アイコンをクリックすることにより、選択したアラートを削除することもできます。また、“追加(Add)” ボタンをクリックすることにより新たに追加することもできます。

作成されたアラートに対して光っている(黄色)電球アイコンをクリックすると、そのアラートを無効化することができます。

有効なアラートは黄色の電球アイコン、無効なアラートは青の電球アイコンで表されます。

アラートの右にある赤い×印のアイコンをクリックすることにより、アラートを削除することができます。

以下のスクリーンショットでは、障害と警告のしきい値を設定したい “CPU Load” というモジュールがあります。

次のスクリーンショットに示すように、モジュール編集フォームにアクセスしてしきい値を設定します。

ローカルモジュールの変更は、Enterprise 版のコンソールからのみ可能であることに注意してください。それ以外の場合は、エージェント設定ファイルを直接編集する必要があります。

変更を承認して保存します。 モジュール 'CPU Load' の値が 70〜90 の場合、そのステータスは警告となり、91〜100 は障害となり以下のように赤色で表示されます。

次に、“オペレータに電子メールを送信する” アクションを作成する必要があります。 アラート > アクション のメニューへ行き、新しいアクションを作成するボタンをクリックします。

このアクションは、メールの宛先アドレス、サブジェクト、およびメッセージ本文に対応する 'Field1'、 'Field2'および 'Field3' という名前のフィールドとともに、'Send email' コマンドを利用します。

障害状態のモジュールに対して一般的なアラートテンプレートが作成され、デフォルトのアクションは電子メールでオペレータのグループに通知することです。“テンプレート” セクションからテンプレートを定義します。

ステップ 1:

ここで設定された優先度は、アラートが発報されたときに特定の色でイベントを表示するために使用されます。

ステップ2では、特定の発報条件を決定するパラメータ(モジュールに必要な状態やシステムが動作する時間範囲など)を指定します。

ステップ 2:

このステップで最も重要なパラメータは次の通りです。

• 条件種別(Condition type: 状態変化、値の変化などによってアラートが発報されるかどうかを決定します。アラートが必要に応じて機能するために最も重要なパラメータです。 モジュールが障害状態になったときにアラートを発報するには、障害状態(Critical status) の条件を使用します。
• 通常のアクション(Default action): アラートが発報されたときに実行されるデフォルトのアクションです。オプションです。
• 再通知間隔(Time threshhold): デフォルトでは 1日です。例では 1日ですが、5分に設定すると、モジュールが常にダウン状態の場合、5分間隔でアラート通知されます。もし、1日 (24時間) に設定すると、ダウンしたときに、まず一度アラート通知します。モジュールが復旧し、再びダウンすると、再びアラート通知します。しかし、二度目のダウンからダウン状態が続いても、24時間以内であればアラートを通知しません。
• 最小アラート数(Min. Number of alerts): Pandora FMS がアラートテンプレートで定義したアクションを実行する状態変化 (この例では、モジュールの障害状態) の回数です。この設定により、正常状態と障害状態を繰り返す大量のアラートが発生を避けることができます。ここに 1を設定すると、モジュールの一度の障害状態は無視します。0 を設定すると、モジュールの初回の障害状態でアラート通知がされます。
• 最大アラート数(Max. Number of alerts): 1 は、アクションを一度だけ実行することを意味します。もし、ここに 10 を設定すると、アクションを 10回実行します。この設定により、アラートの実行回数を制限することができます。

ステップ 3:

ステップ3では、フィールド1、フィールド2、フィールド3 などのフィールドがあります。前に説明したように、テンプレートからアクション、およびアクションからコマンドへのパラメータが転送されます。 さらに、この第3のステップでは、障害発生状況が正常に戻ったときに別のアクションを実行することができる アラートリカバリ を有効または無効にすることができます。

以上で、必要な設定が完了しました。あとは、アラートテンプレートをモジュールに関連づけるだけです。そのためには、エージェントのモジュールのアラートタブへいきます。

設定は簡単です。この画面ショットでは、 “Last_Backup_Unixtime” というモジュールに対して、事前に定義した “Module critical” というアラートが設定されています。加えて、ここでは下の画面を操作して、モジュール “cpu-sys” と、アラートテンプレート “Module critical” を関連づけようとしています。デフォルトで、このテンプレートで設定した “Sancho Lerena へメールを送信する” というアクションが表示されています。

モジュールにアラートを関連付けしたら、連続して複数回繰り返されるアラートがあった場合にアクションを追加することができます。これが、スケーリングアラートです。

追加のアクションを加え、次の画面キャプチャのように、アラートが何回連続したかでアクションを実行するかを定義します。

アラート発生数に達した場合、発生数を定義したアクションだけでなく、その時点まで実行されたすべてのアクションが再実行されます。

さらに、2つ目の間隔を設定することができます。このとき、指定の間隔内に複数回アラートを送信することはできません。

1. Telegram は、Pandora FMS からアラートメッセージを受信できるインスタントメッセージングプラットフォームです。 詳細については、このビデオチュートリアル "Notifications Telegram: Pandora FMS" をご覧ください。 このビデオチュートリアルでは、Pandora FMS アラートのすべてのコンポーネントを作成および設定する方法がわかります。

アラートは、有効化、無効化、スタンバイにできます。無効化とスタンバイには次の違いがあります。無効化ではアラートは実行されずアラート表示にも表示されません。スタンバイでは動作しアラート表示に表示されますが、表示のみで割り当てられたアクションは実行せずイベントは生成しません。

スタンバイアラートは、何が発生したかを確認するのに便利です。ただし、通知 / アクションの実行が無効化されます。

関連障害検知抑制は、ある範囲のエージェントへの通信が切れた場合に大量のアラートが発生するのを避けるための Pandora FMS の機能です。ルータやスイッチ等の中間のデバイスがダウンすると、その先の全てのデバイスに対して Pandora FMS との通信ができなくなるような場合を考えます。おそらく、デバイスは正しく動作していますが、Pandora FMS は ping で疎通確認がとれないため、ダウンと認識します。

関連障害検知抑制は、エージェントの設定で有効にできます。“関連障害検知抑制” のチェックボックスをチェックします。

エージェントの関連障害検知抑制が動作するようにするためには、依存する親エージェントを正しく設定する必要があります。親エージェントで障害状態のモジュールがありアラートが発報されると、関連障害検知抑制を設定した下位のエージェントではアラートは実行されません。これは、警告や不明状態のモジュールアラートには適用されません。

次のようなモニタ設定があったとします。

• ルータ: ICMP のチェックと、標準の OID を使って ATM ポートの状態を確認する SNMP チェックを設定されています。また、上流のプロバイダのルータとの遅延を見ています。
• ウェブサーバ: Pandora FMS エージェントでの、CPU 使用率、メモリ使用量、apache のプロセスチェックといった、内部チェックが設定されています。また、4ステップの HTTP チェックの遅延をチェックしています。
• データベースサーバ: Pandora FMS エージェントでの、CPU 使用率、メモリ使用量、データベースのプロセスチェックといった、内部チェックが設定されています。また、いくつかのデータベース整合性チェックがあります。さらに、プラグインにてリモートから、ログイン、クエリの実行を行い終了、応答タイミングをみるチェックをしています。

ウェブサーバとデータベースサーバでは、ルータを親として定義します。ウェブサーバとデータベースサーバにおいて、関連障害検知抑制のチェックボックスをチェックします。 ここで、いくつかの単一アラートを定義します。

• ルータ

ICMP チェック / 障害状態 → メール送信アクション SNMP チェック / 障害状態 → メール送信アクション 遅延 > 200ms / 警告状態 → アクション無し、関連付けのみ

• ウェブサーバ

CPU / 警告状態 → アクション無し、関連付けのみ メモリ / 警告状態 → アクション無し、関連付けのみ プロセス / 障害状態 → メール送信アクション HTTP 遅延 / 警告状態 → アクション無し、関連付けのみ

• データベースサーバ

CPU / 警告状態 → アクション無し、関連付けのみ メモリ / 警告状態 → アクション無し、関連付けのみ プロセス / 障害状態 → メール送信アクション SQL 遅延 / 警告状態 > メール送信アクション

データベースおよびウェブサーバの親としてルータを設定します。関連障害検知抑制を両方のエージェント (データベースおよびウェブ) で有効にします。

ここで、データベースに関連付けアラートを割り当てます。

ルータ ICMP チェックが正常

かつ(AND)

ルータ SNMP チェックが正常

かつ(AND)

ウェブサーバプロセスが正常

かつ(AND)

データベースサーバプロセスが障害状態

であれば、

次のメールを送信: “Service DOWN: Database Failure”

ここで、さらにデータベースに関連付けアラートを割り当てます。

ルータ ICMP チェックが正常

かつ(AND)

ルータ SNMP チェックが正常

かつ(AND)

ウェブサーバプロセスが障害状態

かつ(AND)

データベースサーバプロセスが正常

であれば、

次のメールを送信: “Service DOWN: WebServer Failure”

さらに、次のようなアラートを定義します。

ルータ ICMP チェックが正常

かつ(AND) ルータ SNMP チェックが正常 かつ(AND)

ウェブサーバの HTTP 遅延が正常 かつ(AND)

データベースサーバの SQL の遅延が発生

かつ(AND)

データベースサーバの CPU 使用率が正常

かつ(AND)

データベースサーバのメモリ使用量が超過

であれば、

次のメールを送信: Database is getting exhausted. Please check it ASAP.

サービス監視 は、同じインシデントを報告する複数の同一ソースのアラートを回避するために使用できます。

サービスベースの関連検知抑制を有効化すると、サービス要素(エージェント、モジュール、他のサービス)は問題を通知せず、サービス自身が影響を受けている要素の代わりにアラートを発します。

つまり、次の図のようになります:

要素 <i>192.168.10.149</i> が障害状態になりサービスには影響がない場合、オペレータは <i>192.168.10.149</i> がダウンした旨の通知を受けます。しかし、サービス <i>Service</i> は正しく動作しています。

この情報を受け取るためには、<i>根本原因分析</i>マクロである _rca_ を使って新たなアラートテンプレートを作成または編集します。

_rca_

このマクロはサービス内で影響を受ける 'パス' の情報をオペレータへ提供します。

例えば、図中のサービスステータスに対応するマクロ <i>_rca_</i> の値は次のようになります。

[Service -> web_service -> 192.168.10.149]

サービスの状態は正常ですが、障害状態のコンポーネントが 50% を超えないためです。(これについての詳細は、サービス監視を参照ください。

考察: 根本原因分析で表される一連のイベントは、サービス内の障害状態の要素を表しているため、どの要素が自分のサービスに影響を与えているかを確認できます。

親エージェントのモジュールが障害状態になった場合に、親エージェントのモジュールの状態を使用してエージェントアラートを回避することができます。

エージェントの拡張オプションでセーフオペレーションモードを有効化することができます。

選択したモジュールの状態が障害になった場合、それが警告もしくは正常状態に戻るまで該当エージェントの残りのモジュールが無効化されます。これにより、例えば、接続障害が発生した場合にリモートモジュールを無効化することができます。

Pandora FMS では、休日や休暇の特別日一覧をテンプレートとして定義して、特別日にアラートが発報されないようにしたり、他の曜日と同じように動作させたりできます。

たとえば、通常は月曜日から金曜日に発報されるテンプレートで、2021年11月20日 土曜日を、月曜日のように実行されるように設定できます。 または、同じテンプレートに対して、2021年12月6日 月曜日を日曜日または休日として機能するように設定すると、その日は発報しなくなります。

Pandora FMS バージョン 759 から、さまざまなアラートテンプレートで使用できるさまざまな特別日カレンダーを定義できます。 デフォルトでは、“Default” と呼ばれるカレンダーが存在し、それを削除することはできません。追加でカレンダーを作成することができます。

それには、“アラート(Alerts) > 特別日一覧(List of special days)” メニューへ行き、新規カレンダー定義には “作成(Create)” をクリックします。

カレンダーを作成するための入力フォームが表示されます。

名前(Name)

カレンダー名。

グループ(Group)

カレンダーが属するグループ。

説明(Description)

カレンダーの追加情報などの説明。

新たに特別日を作成するには、すでに作成したカレンダーへアクセスし、“作成(Create)” をクリックするか、日付の隣の “+” をクリックします。

特別日を作成するための入力フォームが表示されます。

日付(Date)

特別日の日付です。日付のフォーマットは YYYY-MM-DD です。毎年同じ日を指定したい場合は、YYYY に '*' を設定することができます。

グループ(Group)

特別日を適用するグループを選択します。ユーザが"すべて"グループに属してない場合は、特別日を作成するユーザが属するグループのみを割り当てることができます。

同一曜日(Same day of the week)

フィールド 日付(Date) の日は、実際の曜日に関係なく、その曜日と同じように扱われます。

たとえば、指定された日が日曜日であり、水曜日であるかのように処理されるようにチェックされている場合、このカレンダーが使用する各テンプレートでは、テンプレートで設定すると、その日を水曜日であるかのように処理し発報するかどうかを判断します。

休日として指定すると、このカレンダーを使用するアラートは該当の日に発報されません。

説明(Description)

特別日に関する追加情報などの説明です。

フィールドの入力が完了したら、“作成(Create)” をクリックします。 その時点のアラートテンプレートの設定では特別日のカレンダーを参照する設定になっていません。アラートテンプレートの設定で、特別日のカレンダーを利用する設定をする必要があります。そうしないと、特別日のアラート発報が動作しません。

特別日は、iCalendar(.ics)ファイルを使っても作成できます。iCalendar ファイルは、画面の上部からアップロードできます。 アップロードが完了すると、当月以降のデータが登録されます。

作成済みの特別日はカレンダーから編集できます。

特別日を編集するには、該当の日の右にあるスパナアイコンをクリックします。

修正が完了したら、“更新(Update)” ボタンをクリックします。作成時と同様に、指定された日に発報されないアラートテンプレートが二重ウィンドウで表示されます。

特別日を削除するには、該当日の右側のゴミ箱アイコンをクリックします。

ここでの例として、良く質問される SMS 送信について見てみます。

smstools など、SMS を送信できるツールをインストールする必要があります。 ここではすでに SMS アカウントが設定済であると仮定します。以下のコマンドを実行します。

> sendsms

宛先とメッセージの2つのパラメータを入力します。

<destination> 'Full message'

完全な宛先番号(例: スペインの電話番号の場合は 346276226223)と、単純な引用符で囲まれたメッセージ(' および ')を入力します。

これにより、Pandora FMS 管理インターフェースで作成されるアラートで コマンド を使用できます。

このコマンドの場合、Field 1 は宛先の電話番号になり、Field 2 はメッセージ自体になります。これらのフィールドはアラートに追加されたものに送信され、値が置き換えられる可能性があることに注意してください。前の画像のその読み取りでは、宛先の電話番号例 は “123456789” でした。

次に、コマンド を使うアクション を設定します。

このアクションは、あらかじめ定義された コマンド を実行し、Field 1 と Field 2 をカスタム値に置き換えます。 Field 1 は宛先の電話番号(前の画像の例では “346666666666”)になり、Field 2 はこのアクション用に定義されたテキスト(前の画面例では “Hello”)になります。

次の手順では、既存のアラートテンプレートまたは新しいアラートテンプレートを使用できます。

この場合、アラートテンプレートは、モジュールが障害 状態になったときにのみ発報されます。

これを定義したら、アラートを最大で1日1回発生するように設定します。 ただし、復旧した場合も再び発報します。 次の図を参照してください。

ここで、モジュールにアラートテンプレートとアクションを割り当てます。

CPUワークロードモジュールで、メッセージ転送をテストできるように 20未満の値を設定します。 次の画面を見てください。

最後に、アラートの実行を “強制” することができます。つまり、エージェントのアラートをすぐに実行します。 エージェントのアラートビューに移動し、緑色の円のアイコンをクリックします。

次の図に示すように、携帯電話で SMS を受信するはずです。 テストメッセージが “aeryn” に置き換えられていることに注意してください。さらに、CPUワークロード値は “N/A” を示します。これは、アラートを強制すると、データを取得する時間がなく 、モジュールが実際のデータを受信しないためです。

メール送信は、Pandora FMS の内部コマンドであり、フィールド1、フィールド2、フィールド3 はそれぞれメール送信先、件名、本文として使うように定義されており変更することはできません。では、別のアクションを自分で定義したい時はどうすれば良いでしょうか。

この場合は、新たなコマンドの定義画面へ行き、自分で定義を行います。検知したアラートそれぞれのログファイルを作成したいとします。ログファイルのフォーマットは次のようなものを想定します。

DATE_HOUR - NAME_AGENT -NAME_MODULE -VALUE- PROBLEM DESCRIPTION

ここで、VALUE は、そのときのモジュールの値です。コマンドを呼び出すアクションごとに、ログファイルができます。アクションでは、説明と、どのイベントをファイルに書くかを定義します。

そのためには、次のようにコマンドの作成へ行きます。

そして、アクションを定義します。

作成したログを見ると次のようになっています。

2010-05-25 18:17:10 - farscape - cpu_user - 23.00 - Custom log alert #1

アラートは、“farscape” エージェントの “cpu_sys” モジュールで、18:17:10 に発生したこと、また、現在のデータは “23.00” であり、アクションで設定した説明が含まれていることがわかります。

アラートは、“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 に出力されている定義されたアラートの実行ログを探します。

1行ごとに次のフォーマットでログを生成したいと仮定します。

2009-12-24 00:12:00 pandora [CRITICAL] Agent <agent_name> Data <module_data> Module <module_name> in CRITICAL status

コマンド設定

echo _timestamp_ pandora _field2_>> _field1_

アクション設定

Field1 = /var/log/pandora/pandora_alert.log
Field2 = <En blanco>
Field3 = <En blanco>

テンプレート設定

Field1 = <En blanco>
Field2 = [CRITICAL] Agent _agent_ Data _data_ Module _module_ in CRITICAL status
Field3 = <En blanco>

復旧セクション:

Field2 = [RECOVERED] [CRITICAL] Agent _agent_ Data _data_ Module _module_ in CRITICAL status
Field3 = <En blanco>

アラートを実行すると、次の行がログに追加されます。

2009-10-13 13:37:00 pandora [CRITICAL] Agent raz0r Data 0.00 Module Host Alive in CRITICAL status

復旧したときは、次の行が追加されます。

2009-10-13 13:41:55 pandora [RECOVERED] [CRITICAL] Agent raz0r Data 1.00 Module Host Alive in CRITICAL status

任意の数のカスタムモジュールマクロをエージェントモジュールに追加することができます。

マクロには次の特徴があります:

• モジュール設定のセクションで定義します
• 情報はデータベースに保存します
• 次のような任意の名前を持てます: _pepito_
• エージェント設定ファイル(pandora_agent.conf)には影響しません
• アラートシステムでのみ利用できます
• ローカルコンポーネントには追加できません
• ポリシー内のモジュールに追加できます

これらのマクロは、モジュールマクロセクションを展開することにより追加できます。

マクロの値はアラート定義のフィールドの一部として利用できます。 例:

xxx へのメール送信アクションにマクロを含め、アラートが発生したときにメール送信するには、e-mail 本文のフィールドに次のような設定をする必要があります。

定義済のカスタムマクロ無しでモジュールが追加された場合は、アラートが発生したときに e-mail の本文内のマクロの値は表示されません。

一般的なコンソール設定 で説明しているように、Pandora FMS にはメールを送信する機能があります。

ただし、柔軟性があるため、さまざまなプラットフォームで電子メールを送信できます。

Pandora FMS サーバが (Gmail) を介してアラートを送信するには、コンソールの一般設定 または Pandora FMS サーバ 設定を行い、資格情報(ドメイン、ユーザ名、パスワードなど)を入力します。

たとえば、Mail to Admin という名前のアクションを追加し、メールの宛先を設定するには、コマンド eMail を使用して、Destination address Field 1 にカンマで区切った受信者を追加します。

この場合、 'モジュール > アラート の設定で、次のモジュールを含む新しいアラートが生成されます。

アラートが発生したら、アクションで選択されたメールがどのように到達するかを確認できます。

Pandora FMS は、次の設定で Office365 を使うことができます。

• Office365 アカウントを持っている必要があります。

• コンソールの一般設定 または Pandora FMS サーバ 設定を行い、資格情報(Office365 web ドメイン、ユーザ名、パスワードなど)を入力します。

Pandora FMS バージョン 741 から、受信したイベントまたはログ収集システムによって収集されたログに基づくアラートを作成できます。論理関係を持つ一連の表現を用いて、単純なものから複雑なものまでのアラートを作成できます。 この機能は、以前のイベントアラートの機能を置き換えるものです。

Pandora FMS では、特定のモジュールの状態に応じてアラートが生成されるだけでなく、異なるエージェントの複数の異なるモジュールによって生成されたイベントに基づいてアラートを生成できるため、かなり柔軟な設定ができます。

イベントアラートは、論理演算子

• and
• or
• xor
• nand
• nor
• nxor

を使用して定義された、フィルタリングルールに基づいて一致するイベントを検索し、一致するものが見つかった場合にアラートが発報されます。

また、アラートが動作する日などのいくつかのパラメーターを定義したテンプレートを利用します。 ただし、この場合、テンプレートはイベントアラートがいつ発報されるかを定義しません。しかし、フィルタールールを介して一致するイベントが検索され、対応するアラートが発報されます。

バージョン 741 から、アラートを視覚的に作成できる新しいルールエディターを使用できます。古いイベントアラートエディタも、しばらくの間は継続して利用できます。

相関アラートを設定するには、メニューから 'アラート相関(Alert correlation)' へアクセスします。

フィールドの概要は次の通りです。

ソート(Sort)“pass” または “drop” として設定されているかを評価する相関アラートの評価順序のマークです。リストの上位にあるほど、先にアラート評価されます。

名前(Name)

アラートの名前です。

グループ(Group)

まとめられたグループです。ユーザが"すべて"グループに属してない場合は、ユーザが属するグループのみを参照することができます。

マッチ(Matched)

現在のしきい値の発報ルールと一致するイベントが検出された回数です。

発報(Triggered)

設定されたしきい値でアラートが発報された回数です。

アクション(Action)

アラートで設定されたアクションを表示します。

オプション(Options)

アクションを無効にしたり、スタンバイ状態にしたり、アクションを追加したり、編集または削除などを行う操作ができます。

ルールを作成し動作を定義します。(アラートテンプレートに似ています)

相関アラートのテンプレート構成パラメータは、モジュールアラートの構成パラメーターに似ています。イベントアラート固有のパラメーターは 2つだけです。

• ルール評価モード(Rule evaluation mode): 通過(Pass) と破棄(Drop) の 2つのオプションがあります。“通過” とは、イベントがアラートと一致した場合、残りのアラートが引き続き評価されることを意味します。 “破棄” は、イベントがアラートと一致した場合、残ったアラートが評価されなくなることを意味します。
• グループごと(Group by): エージェント、モジュール、アラート、またはグループごとにルールをグループ化できます。 例えば。 2つの障害イベントを受信したときにルールがオフになるように設定され、エージェントによってグループ化されている場合、2つの障害イベントが同じエージェントから送信される必要があります。 これは無効にできます。

各ルールは、特定のタイプのイベントまたはログの一致によりオフになるように設定されます。 ルールまたはその演算子によって定義された論理評価が満たされると、アラートが発報されます。

ビデオチュートリアル «What's new in Pandora FMS Workshop» もご覧ください。

これらのルールを定義するには、要素を左側から右側の “ドロップ領域” にドラッグして作成します。

設定可能な項目:

これらの要素は、ユーザがルールの文法を満たすようにするガイドをします。ここで、使用される文法についてさらに説明します。

S -> R | R + NEXUS +R
R -> FIELD + OPERATOR + C | FIELD + OPERATOR + C + MODIFIER
C -> VARIABLE

ここで、S は、相関アラートに対して定義されたルールのセットです。

ルール定義エリアに要素をドラッグします。

たとえば、画面は次のようになります。

すべての変更をクリーンアップして元に戻すには、'クリーンアップ(Cleanup)' および 'リセット(Reset)' ボタンを使用します。

(A and B)

分析された要素(イベントまたはログ)が A と B を同時に満たすようにします。

A and B

評価ウィンドウで両方のルール（A）と（B）が満たされるようにします。 つまり、最後の数秒間（'log_window' および 'event_window' パラメータで定義される)には、両方のルールを満たすエントリが存在する必要があります。

この操作に関しては、"アラートシステム" を参照してください。

ここでは、アラートが発報されたときに実行するアクションを設定と、そのようなアクションを実行する間隔と頻度を設定します。

ここでは、アクションの実行を設定するときの確認のために、“条件” セクションで行った設定のプレビューを行います。

下のフィールドでアクションを設定できます。

• アクション(Actions): 実行したいアクションです。
• 一致するアラート数(Number of alerts match): アクションを実行するためにアラートが発生してから何回分の実行間隔を待つかの設定です。常にアクションを実行する場合は、このフィールドを空白のままにする必要があります。
• しきい値(Threshold): アラート発報後、アクションが再度実行される状態になるまでの間隔です。

次に、設定したアクションの一覧を表示します。この一覧の “発報(triggering)” フィールドには、 “一致するアラート数” で設定したアクションが実行される間隔が表示されます。さらに、“オプション” 列で、設定したアクションを削除または変更できます。

複数のアラートがある場合、これらには特定の評価順序があります。それらは常にリストの最初から順番に評価されます。

'通過(PASS)' ルール評価モードが構成されている場合、相関アラートが実行されると、次のアラートも評価されます。 これは “通常” のモードです。

'破棄(DROP)' ルール評価モードを設定する場合、このモードで設定された相関アラートが実行されると、次のルールの評価は停止します。 この機能により、関連アラート抑制が可能になります。

例:

• 一般的なアラート
• 特別なアラート

一般アラートが失敗した場合、特定のアラートを評価する必要はありません。 両方を破棄(DROP) で設定します。

順序アイコンをクリックしてドラッグし、ルール評価の順序を変更します。

残りの相関ルール(アクションフィールドとアクションアプリケーション)は、他の Pandora FMS アラートと同様に機能するため、追加の説明は行いません。

イベントアラートで利用できるマクロはこの章の最後のマクロ一覧を参照ください。

コマンドマクロ 、アクションマクロ および イベントアラートマクロ は、_modulelaststatuschange_, _rca_ および _secondarygroups_ を除き共通です。

• _address_: アラートを発報したエージェントのアドレス。
• _addressn_n_: “n” で示される位置に対応するエージェントのアドレス。 例) addressn_1_ , addressn_2_
• _agent_: アラートを発報したエージェントの別名。別名が定義されていない場合は、代わりにエージェント名になります。
• _agentalias_: アラートを発報したエージェントと別名。
• _agentcustomfield_n_: n 番のエージェントカスタムフィールド。(例: _agentcustomfield_9_).
• _agentcustomid_: エージェントのカスタム ID。
• _agentdescription_: アラートを発報したエージェントの説明。
• _agentgroup_: エージェントグループ名。
• _agentname_: アラートを発報したエージェント名。
• _agentos_: エージェントの OS。
• _agentstatus_: エージェントの現在の状態。
• _alert_critical_instructions_: モジュールの障害状態時の手順。
• _alert_description_: アラートの説明。
• _alert_name_: アラート名。
• _alert_priority_: アラートの数値での重要度。
• _alert_text_severity_: テキストでの重要度。 (Maintenance, Informational, Normal Minor, Major, Critical).
• _alert_threshold_: アラートの閾値。
• _alert_times_fired_: アラートが発報された回数。
• _alert_unknown_instructions_: モジュールの不明状態時の手順。
• _alert_warning_instructions_: モジュールの警告状態時の手順。
• _all_address_: アラートを発報したエージェントの全アドレス。
• _critical_threshold_max_: 最大障害閾値
• _critical_threshold_min_: 最小障害閾値
• _data_: アラートを発報する原因となったモジュールデータ。
• _email_tag_: モジュールのタグに関連付けられた Email。
• _event_cf_text_ : (イベントアラートのみ) テキストモードで全データを出力(行区切り)。
• _event_cf_json_ : (イベントアラートのみ) JSON フォーマットで全カスタムデータを出力。
• _event_cfX_: (イベントアラートのみ) アラートを発報したイベントカスタムレポートキー。例えば、IPAM というキーのカスタムフィールドがある場合、その値は、_event_cfIPAM_　マクロを用いて取得します。
• _event_description_: (イベントアラートのみ) イベントのテキストでの説明。
• _event_extra_id_: (イベントアラートのみ) 拡張 ID。
• _event_id_: (イベントアラートのみ) アラートを発報したイベントの ID。
• _event_text_severity_: (イベントアラートのみ) イベントのテキストでの重要度 (Maintenance, Informational, Normal Minor, Warning, Major, Critical)
• _eventTimestamp_: イベントが作成されたタイムスタンプ。
• _fieldX_: ユーザ定義フィールド X。
• _group_contact_: グループ連絡情報。グループ作成時に設定されます。
• _groupcustomid_: グループカスタム ID。
• _groupother_: グループに関する他の情報。グループ作成時に設定されます。
• _homeurl_: 公開 URL。設定の一般オプションで設定されます。
• _id_agent_: エージェント ID。コンソールの該当ページに直接行く URL を生成するのに便利です。
• _id_alert_: エージェントの数値 ID(ユニーク)。他のソフトウエアとの連携に利用します。
• _id_group_: エージェントグループ ID。
• _id_module_: モジュール ID。
• _interval_: モジュール実行間隔。
• _module_: モジュール名。
• _modulecustomid_: モジュールカスタムID。
• _moduledata_X_: このマクロ(“X” はモジュール名)を使用することにより、そのモジュールの最新のデータを取得でき、それが数値の場合、コンソールの設定で指定された 10進形式で、その単位とともに返されます。 たとえば、同じエージェントの他のモジュールに関する情報をアラートメールで送信する場合に役立ちます(これは非常に重要です)。
• _moduledescription_: アラートを発報したモジュールの説明。
• _modulegraph_nh_: (コマンド eMail を利用するアラートのみ) n 時間の間のモジュールグラフを base64 でエンコードして返します。(例: _modulegraph_24h_) サーバとコンソールのAPI間の接続を正しく設定する必要があります。 この設定はサーバの設定ファイルで行います。
• _modulegraphth_nh_: (コマンド eMail を利用するアラートのみ) モジュールの障害および警告しきい値が定義されている場合にのみ、前のマクロと同じ操作を行います。
• _modulegroup_: モジュールのグループ名。
• _modulestatus_: モジュールの状態。
• _modulelaststatuschange_: モジュールの最後の状態変更日時。
• _moduletags_: モジュールタグに関連付けられた URL。
• _name_tag_: モジュールに関連したタグの名前。
• _phone_tag_: モジュールタグに関連付けられた電話番号。
• _plugin_parameters_: モジュールプラグインパラメータ。
• _policy_: モジュールが所属するポリシー名。(該当する場合)
• _prevdata_: アラートが発報される前のモジュールデータ。
• _rca_: 根本原因分析チェーン。 (サービスのみ)
• _server_ip_: エージェントに割り当てられたサーバ IP。
• _server_name_: エージェントに割り当てられたサーバ名。
• _target_ip_: モジュールのターゲット IP アドレス。
• _target_port_: モジュールのターゲットポート番号。
• _time_down_human_: 長いフォーマットでの時刻。例: “1day 10h 35m 40s” (このマクロは復旧アラートでのみ動作します)
• _time_down_seconds_: 秒での時刻 (このマクロは復旧アラートでのみ動作します)
• _timestamp_: アラートが発報された日時。(yy-mm-dd hh:mm:ss)
• _timezone_: _timestamp_ のタイムゾーン。
• _warning_threshold_max_: 最大警告閾値
• _warning_threshold_min_: 最小警告閾値

Pandora FMS ドキュメント一覧に戻る