アラートシステム

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

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

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

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

• シンプルなアラート
• イベントに関する アラート
• SNMPトラップに関するアラート

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

アクションとテンプレートには、'フィールド1'、'フィールド2'、'フィールド3'、(…) フィールドn といった一般的なフィールドがあります。これらのフィールドは、テンプレート → アクション → コマンド という情報の伝達の優先順位に従って適用され、最後にはコマンドの実行パラメータとして使われます。

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

管理(Management) メニュー → アラート(Alerts) → コマンド(Commands)

アラート状況が発生した場合に Pandora FMS が実行するアクションは、最終的にサーバ上で コマンド の形式で実行されます。

管理(Management) メニュー → アラート(Alerts) → コマンド(Commands) → 作成(Create)

• コマンド(Command): アラート発報時に実行されるコマンドです。アラートの設定でパラメータを置き換える マクロ を利用することができます。
• グループ(Group): これにより、コマンドをどのアラートグループに関連付けることができるかが決まります。 ユーザが明示的にグループ すべて (すべてグループ) に属している場合を除き、アラートコマンドを作成しているユーザが属するグループのみを割り当てることができます。
• フィールドの説明(Field description) および フィールドの値(Vield values):
  • 存在するフィールド値: そのフィールドで使用可能な値のコレクションです。 このフィールドが設定されている (空ではない) 場合、フィールドはテキストボックスではなくコンボ選択になります。 コンボには、可能な値ごとにラベル (表示されるオプション) と値 (送信されたオプション) が必要です。 構文は次のとおりです: value1,label1;value2,label2;value3,label3;valueN,labelN。
  • 隠す(Hide): フィールドにパスワードを含む場合は、このオプションでコンテンツをアスタリスクで隠します。
• コマンドフィールドに特別なトークン値 _html_editor_ がある場合、アラートアクションの作成または編集時にコマンドフィールドに HTML エディターを表示できます。

• eMail: Pandora FMS サーバからメールを送信します。Perl の sendmail モジュールを利用します。メールは HTML 形式で送信されるため、視覚的に魅力的なテンプレートを作成できます。メールの受信者は、画像などテンプレートで使用されるリソースにアクセスできる必要があることに注意してください。
• Internal audit: これは、Pandora FMS の内部監査システムに記録を残す内部アラートです。これは、Pandora FMS のデータベースに保存され、コンソールのイベントビューワから確認することができます。
• Monitoring Event: 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番目のオプションでは、添付レポートにテンプレートを使用できます。

• Console notification: Webコンソール経由で任意のユーザに通知を送信できます。利用可能な受信者は対話的に追加できます。通知は、対応するアラートが発生または回復すると表示または非表示になります。また、メッセージはtoken Max. days before delete old messages(メッセージ保存日数)に従って完全に削除されます。事前設定されたマクロは、エージェント、モジュールなどの情報を表示します。受信者がアラート対象項目に対する十分な読み取り権限を持っていることを確認してください。
• API request: このコマンドに基づくアラートアクションを通じてAPIクエリを実行します。以下のパラメータがこの順序で必要です。

1. URL: クエリが実行される API サーバの IP アドレスまたは Web リンク。
2. Method: 使用するメソッド。オプションの一覧 (GET、POST、PUT、PATCH、DELETE) から選択します。PFMS API で使用されるものと同様です (PATCH を除く)。
3. Headers: リクエスト形式 (通常は JSON 形式)、認証トークンなどを指定します。
4. Data: クエリ自体と、そのパラメータです。
5. SSL: 接続にセキュア接続を使用するかどうかを指定します。

一般的なリクエストには次のようなコードが含まれます。

• HEADER:

Authorization: Bearer abc123token; Content-Type: application/json; X-Request-ID: 123456

• DATA:

{'title': 'foo', 'body': 'bar'}

管理(Management) → アラート(Alerts) → コマンド(Commands) メニュー → 編集するコマンドの名前をクリック。選択したアラートを編集したら、更新(Update) ボタンをクリックします。

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

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

管理(Management) メニュー → アラート(Alerts) → アクション(Actions) → 作成(Create)

• グループ(Group): アクショングループです。ユーザが"すべて"グループに属してない場合は、アクションを作成するユーザが属するグループのみを割り当てることができます。コマンドに 全て(All) 以外のグループが割り当てられている場合、コマンドに関連付けられたグループまたは 全て(All) グループのみをアクショングループとして設定できます。何らかの理由でこれが実行できない場合は、必要な権限を持つユーザによる修正を求める警告メッセージが表示されます。
• コマンド(Command): アラートが発生したときに実行されるコマンドをこのフィールドで定義します。Pandora FMS にあらかじめ定義されているコマンド以外も選択できます。
• しきい値(Threshold): アラートアクションは、アラートが発報された回数に関係なく、この時間間隔内で 1 回だけ実行されます。
• 実行されるコマンドのプレビュー(Command Preview): このフィールドは編集できません。システムで実行されるコマンドが自動的に表示されます。
• フィールド 1-10(Field 1-10): '_field1_' から '_field10_' までのマクロの値をここで定義します。必要に応じて、コマンドとともに使用することを目的としています。 これらのフィールドは、設定されている場合、テキストフィールドまたは選択メニューになります。

• Console notification: このコマンドを使用すると、アラートが発生した際に管理者への通知を生成できます。定義済みアラートコマンド Console notifiction を使用します。この定義済みアクションを変更することで、通知先のユーザーを選択できます。
• Create Pandora ITSM ticket: Pandora ITSM との連携が有効になっている場合、そのアプリケーションでインシデントが自動的に作成されます。
• Mail to Admin: 定義済みコマンド eMail を使用して、Destination address フィールドで設定されたメールアドレスにメールを送信します。
• Monitoring Event: 同名のコマンドを使用して、イベントの種類や重要度（発生および回復）などの詳細を設定します。
• Pandora ilert、Pandora Slack、Pandora Telegram、Pandora Vonage: Pandora FMS は、設定後に複数のインスタントメッセージングアプリケーションに通知を送信できます。
• Restart agent: Remote agent control コマンドに従って、PFMS エンドポイントに指示（デフォルトでは再起動）を送信できます。
• Send Report by e-mail および Send Report by email (from template): レポートをメールで送信します。ここでは、受信者、レポート自体 (またはテンプレート)、およびその形式 (PDF、JSON、または CSV) を設定できます。

管理(Management) メニュー → アラート(Alerts) → アクション(Actions) → 編集するアクションの名前をクリックします。

管理(Management) メニュー → アラート(Alerts) → アクション(Actions) → 対応するゴミ箱アイコン(削除(Delete)カラムをクリックします。

テンプレートは、アラートを発報するための条件（アクションを実行するタイミング）を定義します。テンプレートはモジュールに関連付けられており、テンプレートの条件が満たされると、関連付けられたアクションが実行されます。テンプレートの設計により、Pandora FMS のほとんどのケースで使用できる汎用テンプレートの絞り込みグループを生成できます。

管理(Management) メニュー → アラート(Alerts) → テンプレート(Templates) → 作成(Create)

続いて、次の 3つのステップを実施します。

• グループ(Group): テンプレートが適用されるグループ。 テンプレートを作成しているユーザがグループ 全て (全てグループ) に明示的に属している場合を除き、テンプレートを作成しているユーザが属するグループのみを割り当てることができます。
• 優先度(Priority): アラートに関する情報を提供するフィールドです。 アラートが発報されると、生成されたイベントはこの優先度を継承します。 アラートを検索する際のフィルタリングに役立ちます。

• 特別日一覧を利用する(Use special days list): テンプレートで利用する特別日のカレンダーを設定します。
• 再通知間隔(Time Threshold): アラームカウンターをリセットする時間です。これは、アラートが アラートの最大数 を超えて再通知されないようにする時間間隔を定義します。指定された間隔の後、カウンターはリセットされます。アラートが復旧しない状態では、カウンターはリセットされません。継続しないアラートのカウンターリセット(Reset counter for non-sustained alerts) が有効化されていない限り、正常な状態に戻ってアラートが復旧した場合は、すぐにカウンターはリセットされます。
• 最小アラート数(Min. number of Alerts): テンプレートに設定された条件を何回(モジュールの連続抑制回数パラメータで定義された数から数えます)満たした場合にアラートを発報するかの定義です。デフォルトは '0' です。これは、条件を満たす値が最初に受信されたときにアラートを発報することを意味します。これはフィルターとして機能することを目的としており、誤検知を排除するのに役立ちます。
• 最大アラート数(Max number of Alerts): 同じ時間間隔(再通知間隔)内で連続して送信できるアラートの最大数です。これは最大アラートカウンタ値です。 指定した数を超えるアラートは再通知間隔内では発報されません。
• 通常のアクション(Default Action): テンプレートが持つデフォルトのアクションをここで定義します。これは、テンプレートがモジュールに割り当てられたときに自動的に作成されるアクションになります。ここでは、1 つを割り当てるもしくは何も割り当てないことができますが、複数のデフォルトアクションを割り当てることはできません。
• スケジュール(Schedule): アラートが発報される日です。

• アラートが継続しない場合にカウンターをリセット(Reset counter for non-sustained alerts): これを有効化すると、示された条件が連続して繰り返されない場合にアラートカウンターがリセットされます。これの有効化は、最小アラート数 に示されている数が 0 より大きいことにも依存します。たとえば、フィールド 最小アラート数 の値が 2 の場合、モジュールがアラートを発報するには 条件タイプ で割り当てられた状態を 3 回経る必要があることを意味します。以降、トークンには 2 つのシナリオがあります。
• リセットトークンがチェックされている場合、障害状態の数は連続している必要があります。そうでない場合は、カウンターがリセットされます。

• リセットトークンがチェックされていない場合、交互または連続した一連の障害状態の後にアラートが発報されます。

• イベント無効化(Disable event): このトークンをチェックすると、アラート発報イベント表示で生成されるイベントは作成されなくなります。
• 状態タイプ(Condition type): アラートを発報する要素を指定できます。 障害状態 (障害状態 オプション)、または単に正常の状態とは異なる (正常の状態ではない(Not normal state) オプション)。 たとえば、過去 30 日間の合計がちょうど 2 に等しい場合など、複雑なアラートを定義することもできます (複雑なアラート(Complex alert) オプション)。

• 復旧アラート (Alert Recovery): 復旧アラートを有効にするかどうかを設定します。復旧アラートが有効になっている場合、モジュールがテンプレートで示された条件を満たさなくなったときに、このカラムに定義されているフィールドで指定された引数で関連付けられたアクションが実行されます。
• フィールド 1 (Field 1) ~ フィールド 10 (Field 10) (アラートテンプレート、コマンド、アクションいずれも) では、マクロ一覧 のマクロを利用できます。

設定が完了したら、終了(Finish) をクリックします。

デフォルトで作成済のテンプレートは次のとおりです。

1. Critical conditon: 障害状態の条件タイプである 障害重要度 が設定されています。デフォルトのアクションとして、管理者へのメール送信とアラート復旧が有効になっています。
2. Manual alert: これは手動アラートを発報するためのテンプレートです。ここで定義された条件は実行されません。このテンプレートは、リモート管理（エンドポイントの再起動、サーバ上でのコマンド実行など）を行うためのアクションとコマンドをマッピングするために使用されます。
3. Warning condition: 警告状態の条件タイプである 警告重要度 が設定されています。デフォルトのアクションとして、管理者へのメール送信とアラート復旧が有効になっています。
4. Unknown condition: 不明状態 の状態タイプとして 警告の重要度 が設定されており、デフォルトのアクションとして管理者へのメール送信とアラート復旧が有効になっています。
5. Default critical condition: 前述の 4 つのテンプレートはカスタマイズ可能です。このテンプレートは読み取り専用 (システムテンプレート) で、障害状態 テンプレートのコピーです。障害状態の重要性から含まれています。

管理(Management) メニュー → アラート(Alerts) → アラート一覧(List of alerts) → 鉛筆アイコン(アラートビルダ(Builder alert))をクリック。

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

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

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

バージョン 781 では、デフォルトのアクションはそれのみが存在する場合に表示されます。

エージェント管理セクションから、対応するタブに移動して、新しいアラートを追加できます。

次の操作ができます。

• エージェントに割り当てられた各アラートの個々またはすべてのアクションを編集または削除 (アクション 列)。
• オプション列 (Op.):
  • 無効化または有効化ができます。
  • アラートを スタンバイ モードにできます。
  • アクションを追加できます。
  • アラートを完全に クリア できます。
  • アラート詳細を参照できます。

• モジュールで障害および警告のしきい値を定義します。
• アラートをモジュールに関連付けます。これを行うには、モジュールが存在するエージェント内のアラートタブに移動します。
  • 必要に応じてボタンをクリックすると対応するセクションにリダイレクトされ、新しいアクション または 新しいテンプレート を作成できます。 新しいコンポーネントを作成したら、前のステップに戻る必要があります。
• アラート追加(Add alert) ボタンで、新しいアラートが保存されます。
• アラートエスカレーション: アラートエスカレーションは、アラートが一定回数連続して繰り返された場合に実行される追加アクションです。
  • アクションを追加し、アラートが何回連続して繰り返した場合 (一致するアラートの数) にこのアクションを実行するかを決定することが必要です。
  • アラートが復旧すると、現在の 一致するアラートの数 設定に対応するアクションだけでなく、その時点までに実行されたすべてのアクションが再度実行されます。
  • さらに、しきい値 を 2 番目のパラメータとして設定できます。このパラメータに対しては、上記の間隔中に複数回アラートを起動することはできません。
• 最後に、Telegram などのインスタントメッセージングを介してアラートメッセージの送信を設定できます。

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

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

関連障害検知抑制は、ある範囲のエージェントへの通信が切れた場合に大量のアラートが発生するのを避けるための Pandora FMS の機能です。

ルータやスイッチ等の中間のデバイスがダウンすると、その先の全てのデバイスに対して Pandora FMS との通信ができなくなるような場合を考えます。おそらく、デバイスは正しく動作していますが、Pandora FMS は ping で疎通確認がとれないため、ダウンと認識します。

エージェントが関連障害検知抑制を有効にして動作するには、依存する親エージェント (詳細オプション の 親(Parent) 設定) が正しく設定されている必要があります。

関連障害検知抑制は、エージェントの設定で有効にできます。詳細オプション(Advanced options) で 関連障害検知抑制(Cascade protection modules) のチェックボックスをチェックします。

サービスベースの関連障害検知抑制は、サービス の要素が属するサービスのアラートが発報された場合に、その要素のアラートが発報されるのを防ぎます。

この機能を有効にするには、この動作が必要な エージェントの詳細設定 で サービス関連障害検知抑制(Cascade protection services) トークンを有効にし、これらのエージェントが属する サービスの設定 で 関連障害検知抑制の有効化(Cascade protection enabled) トークンを有効にする必要があります。

サービスアラートが発報されると、サービスのどの要素が障害であるかという情報が マクロ _rca_ を使用してアラートで送信され、サービスステータスの根本原因が示されます。

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

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

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

以下の特定のマクロは、任意のモジュールのマクロセクションを展開することで追加できます。

• これらはモジュールで定義されます。
• 情報はデータベースに保存します。
• 任意の名前を持てます。例: _myMacro
• エージェントのローカル設定ファイル(.conf)には影響しません
• アラート専用で使用されます。
• ローカルコンポーネントには追加できません
• ポリシー内で定義できます
• 設定値は、アラート定義のフィールドの一部として使用できます。

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

ただし、柔軟性があるため、別のメール送信プラットフォームで送信することもできます。

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

アクション設定

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

アラート設定

モジュール設定のアラートタブで、作成されたアクションを使用して新しいアラートを作成します。

• Office365 アカウントを持っている必要があります。
• コンソールの一般設定 または Pandora FMS サーバ 設定を行い、資格情報(Office365 web ドメイン、ユーザ名、パスワードなど)を入力します。

管理(Management) → アラート(Alerts) → イベントアラート(Event Alerts) メニュー。

受信したイベントに基づいてアラートを作成できます。これらのアラートは、論理的な関係を持つ一連のルールに基づいて、単純なものから複雑なものまで作成できます。

このタイプのアラートでは、アラートが特定のモジュールのステータスに基づいて生成されるのではなく、複数の異なるモジュールや異なるエージェントによって生成された可能性のあるイベントに基づいて生成されるため、より柔軟な観点からの作業が可能になります。

各イベント アラートは、特定の種類のイベントで発報されるように設定されています。ルールとその演算子によって定義された論理式が満たされると、アラートが発報されます。

管理(Management) → アラート(Alerts) → イベントアラート(Event Alerts) メニュー。

作成(Create) ボタンをクリックすると、新しいイベントアラートが追加されます。手順は アラートテンプレート の作成と似ています。イベントアラートを完全に作成するには、以下の 5 つのステップがあります。重要な点は以下のとおりです。

• ステップ 1、設定(Configure): 名前、イベントアラートが属するエージェントグループ、重要度などの基本データが含まれています。
• ステップ 2、条件(Conditions): アラートテンプレート、特別日リスト、[イベント無効化] オプション (このトークンがチェックされている場合、アラート発報イベント表示で生成されるイベントは作成されません)、およびルール評価モードが割り当てられます。

イベント アラートが 2 つ以上ある場合は、作成日時順に 1 つずつ評価され、必要に応じて階層が確立されます。

各イベント アラートには、この目的のための 2 つの特定の構成パラメータがあります。

• ルール評価モード(Rule evaluation mode): Pass または Drop を指定できます。前者は、イベントが アラートのルール を満たしている場合、残りのアラートは引き続き評価されます。これがデフォルトの動作です。それ以外の場合の Drop は、イベントがアラートを満たしている場合、残りのアラートの評価を停止 することを意味します。
• グループごと(Grouped by): ルール をエージェント、グループ、モジュール、またはモジュールアラートごとにグループ化できます。したがって、2 つの重要なイベントを受信したときにルールがトリガーされるように設定され、エージェントごとにグループ化されている 場合、2 つの重要なイベントは同じエージェントから到着することになります。

• ステップ 3、ルール(Rules): イベントアラート内のルール。
• ステップ 4、フィールド(Fields): イベントアラート内のフィールド。
• ステップ 5、発報(Triggering): イベントアラート内で発報されます。

作成が完了し、全体表示に戻ると、登録済みのイベントアラートのリストとそれらに関する情報、およびそれらに関するオプション（アクションを無効にしてスタンバイモードで操作する、アクションを追加する、対応するイベントアラートを編集または削除する）が表示されます。また、異なるイベントアラート間の順序を変更することもできます。

イベントアラートは、次の論理演算子を使用したフィルタリングルールに基づいています。

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

これらの論理演算子は、設定されたフィルタリングルールに一致するイベントや式を検索するために使用され、一致するものが見つかった場合、アラートが発報されます。アラートルールを定義するには、左側の要素を右側のドロップエリア(drop area)にドラッグしてルールを構築する必要があります。

利用可能な設定項目:

これらの要素は、ユーザがルールの文法に従うようガイドするために有効になります。以下は、使用される文法の簡単な説明です。

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

すべての変更をクリアして元に戻すためのボタンが 2 つあります: クリーンアップ(Cleanup) と リセット(Reset)。

分析された要素 (イベント) が A と B に同時に準拠するように強制します。

評価ウィンドウにおいて、ルール（A）と（B）の両方を満たすことを強制します。つまり、最後の数秒間（event_window パラメータで定義）に、両方のルールを満たすエントリが存在する必要があります。

Field2、Field3、(…)、Fieldn を設定する必要があります。これらは、テンプレート から アクション へ、またアクションから コマンド へ情報を転送するために使用され、最終的にそのコマンドの実行時にパラメータとして使用されます。

この情報は、次のステップの Fieldn フィールドに既に情報が定義されていない限り、転送されます。つまり、フィールドまたはパラメータが重複している場合、テンプレートのアクションが上書きされます（例えば、テンプレートに Field1 が定義されており、アクションも定義されている場合、アクションの Field1 がテンプレートのアクションを上書きします）。

このセクションでは、アラートが発報されたときに実行されるアクションを設定し、このアクションが実行される間隔と頻度を指定する必要があります。

• アクション(Actions): 実行する必要がある アクション。
• しきい値(Threshold): アラートが発報されてから、アクションが再度実行されるまでの経過時間間隔。

上記のパラメータを選択したら、追加(Add) ボタンを押して、設定されたアクションのリストを選択して表示できます (セクション このアクションの発報フィールドを表示するには、目的のアクションとモードを選択してください)。

イベントアラートの設定内で使用できるマクロは、マクロ一覧にあります。

管理(Management) → アラート(Alerts) → ログアラート(Log Alerts) メニュー。

アラートは、受信したログに基づいて作成できます。これらのアラートは、論理的な関係を持つ一連のルールに基づいて、単純なものから複雑なものまで作成できます。

このタイプのアラートでは、アラートが特定のモジュールのステータスに基づいて生成されるのではなく、複数の異なるモジュールや異なるエージェントによって生成された可能性のあるログに基づいて生成されるため、より柔軟な観点からの作業が可能になります。

各ログアラートは、特定の種類のイベントで発報されるように設定されています。ルールとその演算子によって定義された論理式が満たされると、アラートが発報されます。

管理(Management) → アラート(Alerts) → ログアラート(Log Alerts) メニュー。

作成(Create) ボタンをクリックすると、新しいログアラートが追加されます。手順は アラートテンプレート の作成と似ています。ログアラートを完全に作成するには、以下の 5 つのステップがあります。重要な点は以下のとおりです。

• ステップ 1、設定(Configure): 名前、イベントアラートが属するエージェントグループ、重要度などの基本データが含まれています。
• ステップ 2、条件(Conditions): アラートテンプレート、特別日リスト、[イベント無効化] オプション (このトークンがチェックされている場合、アラート発報イベント表示で生成されるイベントは作成されません)、およびルール評価モードが割り当てられます。

ログアラートが 2 つ以上ある場合は、作成日時順に 1 つずつ評価され、必要に応じて階層が確立されます。

各ログアラートには、この目的のための 2 つの特定の構成パラメータがあります。

• ルール評価モード(Rule evaluation mode): Pass または Drop を指定できます。前者は、ログが アラートのルール を満たしている場合、残りのアラートは引き続き評価されます。これがデフォルトの動作です。それ以外の場合の Drop は、ログがアラートを満たしている場合、残りのログの評価を停止 することを意味します。
• グループごと(Grouped by): ルール をエージェント、グループ、モジュール、またはモジュールアラートごとにグループ化できます。したがって、2 つの重要なログを受信したときにルールがトリガーされるように設定され、エージェントごとにグループ化されている 場合、2 つの重要なログは同じエージェントから到着することになります。

• ステップ 3、ルール(Rules): ログアラート内のルール。
• ステップ 4、フィールド(Fields): ログアラート内のフィールド。
• ステップ 5、発報(Triggering): ログアラート内で発報されます。

作成が完了し、全体表示に戻ると、登録済みのログアラートのリストとそれらに関する情報、およびそれらに関するオプション（アクションを無効にしてスタンバイモードで操作する、アクションを追加する、対応するログアラートを編集または削除する）が表示されます。また、異なるログアラート間の順序を変更することもできます。

ログアラートは、次の論理演算子を使用したフィルタリングルールに基づいています。

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

これらの論理演算子は、設定されたフィルタリングルールに一致するログや式を検索するために使用され、一致が見つかった場合はアラートが発報されます。

アラートのルールを定義するには、左側の要素を右側の ドロップエリア(drop area) にドラッグしてルールを構築する必要があります。

利用可能な設定項目:

これらの要素は、ユーザがルールの文法に従うようガイドするために有効になります。以下は、使用される文法の簡単な説明です。

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

すべての変更をクリアして元に戻すためのボタンが 2 つあります: クリーンアップ(Cleanup) と リセット(Reset)。

分析された要素 (イベント) が A と B に同時に準拠するように強制します。

評価ウィンドウにおいて、ルール（A）と（B）の両方を満たすことを強制します。つまり、最後の数秒間（log_window パラメータで定義）に、両方のルールを満たすエントリが存在する必要があります。

Field2、Field3、(…)、Fieldn を設定する必要があります。これらは、テンプレート から アクション へ、またアクションから コマンド へ情報を転送するために使用され、最終的にそのコマンドの実行時にパラメータとして使用されます。

この情報は、次のステップの Fieldn フィールドに既に情報が定義されていない限り、転送されます。つまり、フィールドまたはパラメータが重複している場合、テンプレートのアクションが上書きされます（例えば、テンプレートに Field1 が定義されており、アクションも定義されている場合、アクションの Field1 がテンプレートのアクションを上書きします）。

このセクションでは、アラートが発報されたときに実行されるアクションを設定し、このアクションが実行される間隔と頻度を指定する必要があります。

• アクション(Actions): 実行する必要がある アクション。
• しきい値(Threshold): アラートが発報されてから、アクションが再度実行されるまでの経過時間間隔。

上記のパラメータを選択したら、追加(Add) ボタンを押して、設定されたアクションのリストを選択して表示できます (セクション このアクションの発報フィールドを表示するには、目的のアクションとモードを選択してください)。

ログアラートの設定内で使用できるマクロは、マクロ一覧にあります。

これらのアラートは生成時に SIEM イベントサーバによって評価されるため、正しく動作するには SIEM 監視 を有効にして設定する必要があります。

管理(Management) → アラート(Alerts) → SIEM アラート(SIEM Alerts) メニュー。

このセクションでは、SIEMアラートの作成、編集、削除が可能です。このセクションにアクセスするには、LW権限が必要です。

これらのアラートは SIEM イベント表示のフィルタシステムに基づいているため、設定されたフィルタ条件で表示されたすべてのイベントによってアラートが発報されます。

たとえば、SIEM アラートが障害イベントフィルタで設定されている場合、SIEM イベントサーバがその条件でアラートを生成する直前にアラートが発報されます。

SIEM アラートには、他のすべてのアラートと同様に、発報するための全体設定オプションがあります。

操作(Operation) → SIEM → アラート(Alerts) メニュー。

このセクションでは、環境内で利用可能なSIEMアラートの表示、有効化/無効化、スタンバイモードの変更が可能です。このセクションにアクセスするには、LM権限が必要です。

コマンドマクロ、アクションマクロ、および イベントアラートマクロ は互いに類似していますが、それぞれの説明にいくつかの例外が指定されています。

注意:

マクロ _prevdata_ については、Pandora FMS サーバ設定ファイルの次のセクションを コメント解除 する必要があります。

# Default texts for some events. The macros _module_ and _data_ are supported.
text_going_down_normal Module '_module_' is going to NORMAL (_data_) with previous data (_prevdata_)
#text_going_up_critical Module '_module_' is going to CRITICAL (_data_)
#text_going_up_warning Module '_module_' is going to WARNING (_data_)
#text_going_down_warning Module '_module_' is going to WARNING (_data_)
#text_going_unknown Module '_module_' is going to UNKNOWN

新しい変更を有効にするには、サーバプロセスを再起動する必要があります。

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