アラートシステム

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 のデータベースに保存され、コンソールのイベントビューワから確認することができます。
• 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番目のオプションでは、添付レポートにテンプレートを使用できます。

管理(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_' までのマクロの値をここで定義します。必要に応じて、コマンドとともに使用することを目的としています。 これらのフィールドは、設定されている場合、テキストフィールドまたは選択メニューになります。

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

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

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

テンプレートは、アラート発報条件を定義します(いつ アクションを実行する必要があるか)。アラートテンプレートはモジュールに関連付けられ、テンプレートの条件にマッチすると関連するアクションが実行されます。

Pandora FMS で多くの場合に利用される個々の汎用テンプレートグループを用意しておくことができます。デフォルトで作成されているテンプレートは次の通りです。

1. Critical condition: 障害状態の条件タイプである 障害の重大度 が設定されています。デフォルトのアクションとして、管理者に電子メールメッセージを送信し、アラートリカバリを有効にします。
2. Manual alert: これは手動アラートをトリガーするためのテンプレートです。ここで定義された条件は実行されません。このテンプレートは、リモート管理（エージェントの再起動、サーバ上でのコマンド実行など）に使用するアクションとコマンドをマッピングするために使用されます。
3. Warning condition: 警告状態の条件タイプである 警告の重大度　が設定されています。デフォルトのアクションとして、管理者に電子メールメッセージを送信し、アラートリカバリを有効にします。
4. Unknown condition: 不明状態 の状態タイプとして 不明の重要度 が設定されており、デフォルトのアクションとして管理者に電子メール メッセージを送信し、アラート回復を有効にします。

管理(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) をクリックします。

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

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

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

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

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

次の操作ができます。

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

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

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

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

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

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

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

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

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

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

この情報を受け取るためには、根本原因分析マクロである _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権限が必要です。

コマンドマクロ 、アクションマクロ および イベントアラートマクロ は、_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。
• _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_: モジュールの最後の状態変更日時。
• _modulelaststatustime_: (コマンド マクロの場合のみ) モジュールの状態が最後に変更された日時。
• _lastdatatimestamp_: モジュールが受信した最終チェックの日時 (不明なアラートへのパスに役立ちます)。
• _lastdatatime_: モジュールによって受信された最終チェックの日時 (Unix 時間形式) (不明なアラートを渡す場合に便利です)。
• _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 ドキュメント一覧に戻る