アラートシステム

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: 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!!!

フィールド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

It plays a sound if an alert is received.

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

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)

Both options allow you to send a report in different formats (XML, PDF, JSON, CSV) by e-mail, the second option allows you to use a template for the attached report.

どちらのオプションでも、さまざまな形式(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. ファイルを編集し、次のような設定を行います。

useraccount@jabber.org password

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

  chmod 0600 .sendxmpprc

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

  $ echo "Hello" | sendxmpp -s pandora useracount@jabber.org

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

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

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

echo _field2_ | sendxmpp -s pandora _field1_

Jabber 利用例

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

  $ echo "Dinner Time" | sendxmpp -r TheCook --chatroom test2@conference.jabber.org

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

  $ tail -f /var/log/syslog | sendxmpp -i sysadmin@myjabberserver.com

注意: 公開 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: myuser@domain.com\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 user@hostname [_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 で多くの場合に利用される個々の汎用テンプレートグループを用意しておくことができます。

Go to the Alerts menu → Templates. You can create a new template by clicking on the Create button.

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

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

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

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

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

Use special days list

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

Sets the calendar of special days to be used in the template.

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

Schedule

スケジュール(Schedule)

It sets the days the alert could possibly be triggered.

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

It is possible to view and configure when the alert will be active each day of the week thanks to the built-in editor that is displayed by default in simple mode.

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

In this simple mode you may configure them by clicking on each day's alarm period and setting the start or end time in the pop-up form. Enter the start time in the From field and the end time in the To field. You may use the Remove button to delete the selected alarm period, the Cancel button to discard the changes or the Ok button to update the calendar.

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

In addition, by accessing the detailed mode you can configure the schedules more precisely. In this mode you may also use the pop-up form to adjust the time:

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

• Click each day's alarm period and drag the top or bottom edge to extend the alarm time period.
• To move, click in the middle of each day's alarm period and drag it to where it is needed. You will see the times change as you drag.
• To add a new alarm period, click on an empty cell and it will mark a duration time. You may move or modify as described in the previous two steps.
• To delete, drag an alarm period out of the calendar and “drop”.

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

You may add as many time periods as you need. When you go back to simple mode, you will get something like the following:

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

再通知間隔(Time Threshold)

Time required to reset the alarm counter. It defines the time interval in which it is guaranteed that an alert is not going to be fired more times than the number established in Max. number of alerts. After the defined interval, the counter will be reset. The restart of the trigger counter will not be restarted if the alert recovers when a correct value arrives, unless the value Reset counter for non-sustained alerts is activated, in which case the counter will restart immediately after receiving a correct value.

アラームカウンターをリセットする時間です。これは、アラートが アラートの最大数 を超えて再通知されないようにする時間間隔を定義します。指定された間隔の後、カウンターはリセットされます。アラートが復旧しない状態では、カウンターはリセットされません。継続しないアラートのカウンターリセット(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: The module is used, whether its status (Critical status, Warning status, Unknown status, Not normal status) or its value change.(On change, however, when unchecking the verification checkbox Triggered when the value matches allows firing if the value is the same) or just Always, if necessary.

• モジュールスの状態(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)” ボタンをクリックすることにより新たに追加することもできます。

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

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

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

From the agent management section, new alerts can be added by clicking on the corresponding tab.

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

These are the form's available fields:

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

Module

Agent module list.

Actions

Action executed when the alert is triggered. If the template has a default one, leave it as Default.

Template

Template that contains alert triggering terms.

Threshold

The alert action will not be executed more than once every action_threshold seconds, regardless of the number of times the alert is triggered.

モジュール(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% を超えないためです。(これについての詳細は、サービス監視を参照ください。

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

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

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

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

ここでの例として、良く質問される 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” であり、アクションで設定した説明が含まれていることがわかります。

コマンド実行時に、フィールドやその他がどのように引き渡されて実行されたかは簡単にはわかりません。それを確認する簡単な方法は、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 サーバ 設定を行い、資格情報(ドメイン、ユーザ名、パスワードなど)を入力します。

Add an action, for example with the name Mail to Admin, and to configure the email addresses use the command eMail adding the recipients in ·Destination address Field 1 separated by commas:

たとえば、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_

Address of the agent that triggered the alert.

_addressn_n_

Address of the agent that corresponds to the position indicated in “n” e.g: addressn_1_ , addressn_2_ .

_agent_

Alias of the agent that triggered the alert. If there is no alias assigned, the name of the agent will be used instead.

_agentalias_

Alias of the agent that triggered the alert.

_agentcustomfield_n_

Agent number n custom field (e.g. _agentcustomfield_9_).

_agentcustomid_

Agent custom ID.

_agentdescription_

Description of the agent that triggered the alert.

_agentgroup_

Agent group name.

_agentname_

Name of the agent that triggered the alert.

_agentos_

Agent's operative system.

_agentstatus_

Current agent status.

_alert_critical_instructions_

Instructions for CRITICAL status contained in the module.

_alert_description_

Alert description.

_alert_name_

Alert name.

_alert_priority_

Alert’s numeric priority.

_alert_text_severity_

Priority level, in text, for the alert (Maintenance, Informational, Normal Minor, Major, Critical).

_alert_threshold_

Alert threshold.

_alert_times_fired_

Number of times the alert has been triggered.

_alert_unknown_instructions_

Instructions for UNKNOWN status contained in the module.

_alert_warning_instructions_

Instructions for WARNING status contained in the module.

_all_address_

All addresses of the agent that fired the alert.

_critical_threshold_max_

Maximum critical threshold.

_warning_threshold_min_

Minimum critical threshold.

_data_

Module data that caused the alert to be triggered.

_email_tag_

Emails associated to the module’s tags.

_event_cf_text_

(Only event alerts). Output all custom data in text mode (with line breaks).

_event_cf_json_

(Only event alerts). Output all custom data in JSON format.

_event_cfX_

(Only event alerts). Key of the event custom field that triggered the alert. For example, if there is a custom field whose key is IPAM, its value can be obtained using the _event_cfIPAM_ macro.

_event_description_

(Only event alerts) Textual description of the Pandora FMS event.

_event_extra_id_

(Only event alerts) Extra id.

_event_id_

(Only event alerts) ID of the event that triggered the alert.

_event_text_severity_ (Only event alerts)

Priority text about the event that triggered the alert (Maintenance, Informational, Normal Minor, Warning, Major, Critical).

_eventTimestamp_

Timestamp in which the event was created.

_fieldX_

User defined field C.

_group_contact_

Group contact information. Configured when the group is created.

_groupcustomid_

Group custom ID.

_groupother_

Other information about the group. Configured when the group is created.

_homeurl_

It is a link of the public URL this must be configured in the general options of the setup.

_id_agent_

Agent ID, useful for building a direct URL with to Pandora FMS console.

_id_alert_

Alert ID, used to correlate the alert with third party tools.

_id_group_

Agent group ID.

_id_module_

Module ID.

_interval_

Module execution interval.

_module_

Module name.

_modulecustomid_

Module custom ID.

_moduledata_X_

Using this macro (“X” is the module name) the last piece of data of this module is collected, and if it is a number it is returned with the decimals specified in the console and its unit (if it has it). This could be useful for example for sending an email once a module alert is triggered, and also send additional information about other modules of the same agent (which could be very relevant).

_moduledescription_

Module description.

_modulegraph_nh_

(Only for alerts that use the eMail command) It returns an image encoded in base64 of a module graph with a period of n hours (e.g. _modulegraph_24h_). A correct setup of the connection between the server and the console's API is required. This setup is done in the server configuration file.

_modulegraphth_nh_

(Only for alerts that use the eMail command) Same operation as the previous macro, but with the critical and warning thresholds of the module provided they are defined.

_modulegroup_

Module’s group name.

_modulestatus_

Module status.

_moduletags_

URLs associated to the module tags.

_name_tag_

Names of the tags related to the module.

_phone_tag_

Phone numbers associated to the module tags.

_plugin_parameters_

Module plugin parameters.

_policy_

Name of the policy that the module belongs to (if applies).

_prevdata_

Module previous data before the alert was triggered.

_rca_

Root cause analysis chain (only for services).

_server_ip_

Ip of server assigned to agent.

_server_name_

Name of server assigned to agent.

_target_ip_

IP address for the module’s target.

_target_port_

Port number for the module’s target.

_time_down_human_

Time in long format, for example: “1day 10h 35m 40s” (this macro only works for recovery alerts).

_time_down_seconds_

Time in seconds (this macro only works for recovery alerts).

_timestamp_

Time and date on which the alert was triggered (yy-mm-dd hh:mm:ss).

_timezone_

Timezone that is represented on _timestamp_.

_warning_threshold_max_

Maximum warning threshold.

warning_threshold_min_

• _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。
• _groupcontact_: グループ連絡情報。グループ作成時に設定されます。
• _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 ドキュメント一覧に戻る