アラートシステム

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

An alert is the reaction of Pandora FMS to an incorrect value of a Module. Said reaction is configurable and can consist of anything that can be triggered by a script configured in the Operating System where the Pandora FMS server that processes the Module runs.

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

In Pandora FMS, the alerts work by defining some trigger conditions, some actions chosen for that alert, and finally the execution of some commands in the Pandora FMS server, which will be in charge of carrying out the configured actions.

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

There are several types of alerts:

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

• Alerts simple.
• Alerts about events.
• Alerts about traps SNMP.

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

• Commands: Specify what will be done; It will be the execution that the Pandora FMS server will carry out when triggering the alert.
• Actions: Specify how it will be done; they are the customizations of the command arguments.
• Templates: Specify when it will be done; define the conditions for triggering the action(s).

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

Templates and actions have a series of generic fields called Field1 , Field2 , Field3, (…) , Fieldn which they are used to transfer the information from the template to the action and from the action to the command, to finally be used as parameters in the execution of said command.

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

Said information is transferred whenever the next step does not already bring information defined in its Fieldn fields. That is, in case of overlapping fields or parameters, it overwrites the action to the template (for example, if the template has Field1 defined and the action as well, the Field1 of the action overwrites the template action).

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

Management menu → Alerts → Commands.

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

The actions that Pandora FMS will carry out in the event of alert situations will ultimately be translated into executions on the server, in the form of commands.

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

Management Menu → Alerts → Commands → Create.

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

• Command: Command that will be executed when triggering the alert. It is possible to use macros to replace the parameters configured in the alert declaration.
• Group: This determines which group of alerts you can associate the command with. You can only assign a group to which the user creating the alert command belongs, unless that user explicitly belongs to the group EVERYONE (ALL) .
• Field description and Field values:
  • Available Field Values: A collection of possible values for that field. If this field is set (not empty), the field will be a combo select instead of a text box. The combo needs for each possible value a label (the visible option) and a value (the sent option). The syntax is as follows: value1,label1;value2,label2;value3,label3;valueN,labelN.
  • Hide: If the field contains any passwords, this option hides the contents with asterisks.
• It is possible to display an HTML editor in a command field when creating or editing an alert action if that command field has the special token value _html_editor_ .

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

• eMail: Sends an email from the Pandora FMS server. Email messages are sent in HTML format. It must be taken into account that the receiver must be able to access the resources used in the template, such as images.
• Internal audit: Generates an entry in the internal audit system of Pandora FMS. This is stored in the databasee Pandora FMS and can be reviewed with the event viewer from the console.
• Monitoring Event: Create a custom event in the Pandora FMS event console.
• Pandora FMS Alertlog: It is a predefined alert that writes the alerts in plain ASCII format in the file /var/log/pandora/pandora_alert.log.
• SNMP Trap: Sends an SNMP trap parameterized with the arguments used.
• Syslog: Sends an alert to the syslog using the logger system command.
• Sound Alert: Plays a sound in the sound console of events when an alert occurs.
• Jabber Alert: Send a Jabber alert to a chat room on a predefined server (the .sendxmpprc file must be configured first). Put in field1 the username, field2 the name of the chat room, and field3 the text message.
• SMS Text: Sends an SMS to a specific mobile phone. First it is necessary to define an alert and configure a gateway for sending SMS that is accessible from the Pandora FMS server.
• Validate Event: Validates all events related to a module. It will be passed the name of the agent and the name of the module.
• Remote agent control: Send commands to agents with UDP server enabled. The UDP server is used to instruct agents (Windows and UNIX) to refresh the execution of the agent: that is, to force the agent to execute and send data.
• Generate Notification: Allows you to send an internal notification to any user or group.
• Send report by e-mail and Send report by e-mail (from template): Both options allow you to send a report in different formats (XML, PDF, JSON, CSV) by email, the The second option allows you to use a template for that attached report.

• 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 menu → Alerts → Commands → click on the name of the command to edit. Once the chosen alert has been modified, click the Update button.

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

Actions are the alert components in which a command is related to the generic variables Field 1, Field , … , Field 10.

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

Actions allow you to define how to launch the command.

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

Management Menu → Alerts → Actions → Create.

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

• Group: The group of the action. You can only assign a group to which the user creating the alert command belongs, unless that user explicitly belongs to the group EVERYONE (ALL) . If the associated command has a group other than All, only the group associated with the command or the All group can be set as the action's group. If for some reason this defers, you will see a warning message for prompt correction by a user with the necessary rights.
• Command: Command that will be used in the event that the alert is executed. You can choose between different predefined commands in Pandora FMS.
• Threshold: An alert action is executed only once within this time interval, regardless of how many times the alert is triggered.
• Command Preview: In this field, not editable, the command to be executed in the system will automatically appear.
• Field 1 ~ Field 10: If necessary, these fields define the value of the macros, from _field1_ to _field10_, to be used in the command. These fields can be a text field or a select combo if configured.

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

Management Menu → Alerts → Actions → click on the name of the action to modify.

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

Management menu → Alerts → Actions → click on the corresponding trash can icon (Delete column).

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

The templates define the conditions for triggering the alert (when to execute the action). They are associated to Modules, in such a way that when the template conditions are met, the associated action(s) will be executed.

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

Its design allows to generate a small group of generic templates that serve for the majority of possible cases in Pandora FMS.

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

Management Menu → Alerts → Templates → Create.

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

Then follow the three guided steps.

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

Step 1: Overview

ステップ 1: 概要

• Group: The group to which the template will be applied. You can only assign a group to which the user who is creating the template belongs, unless said user explicitly belongs to the group ALL (ALL).
• Priority: Informative field about the alert. The event generated when the alert is triggered will inherit this priority, useful for filtering alert searches.

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

ステップ 2: 状態

• Use special days list: Sets the special days calendar to be used in the template.
• Time Threshold: Time that must elapse to reset the alert counter. Defines the time interval in which an alert is guaranteed not to fire more times than the number set in Max. number of alerts. After the defined interval, the counter will be restarted. The shot counter reset will not be reset if the alert recovers upon reaching a correct value, unless the value Reset counter for non-sustained alerts is enabled, in which case the counter will be reset immediately after receiving a correct value.
• Min number of alerts: Minimum number of times that the situation defined in the template has to occur (always counting from the number defined in the FlipFlop parameter of the Module) to start triggering an alert. The default value is 0, which means that the alert will be triggered when the first value that meets the condition is reached. It works like a filter, useful for ignoring false positives.
• Max number of alerts: Maximum number of alerts that can be sent consecutively in the same time interval (Time Threshold). It is the maximum value of the alert counter. No more alerts will arrive per time interval than those indicated in this field.
• Default Action: This list defines the default action that the template will have. This is the action that will be automatically created when you assign the template to the module. Place one action or none, however you cannot place place multiple actions by default.
• Schedule: Establishes the days on which the alert can be triggered.

• 特別日一覧を利用する(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: Its activation depends on the number indicated in Min. number of alerts is greater than 0. Enabling this token resets the alert counter when the indicated condition doesn't occur consecutively. For example, if the field Min. number of alerts has a value of 2, it means that the module has to go through the state assigned in Condition type 3 times to trigger the alert. There are two scenarios with the latter token:
• If the reset token is checked the number of critical states will need to be consecutive, otherwise the counter will be reset.

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

• If the reset token is not checked, the alert will be triggered after an alternate or continuous sequence of critical states:

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

Step 3: Advanced Fields

ステップ 3: 高度なフィールド

• Alert recovery: Combo where you can define whether or not to enable alert recovery. In the event that alert recovery is enabled, when the module no longer meets the conditions indicated by the template, the action associated with the arguments specified by the field fields defined in this column will be executed.
• In all instances of the fields field1 … field10 (both in the alert template, as well as in the command and in the action) those defined in the macro_list.

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

Once the configuration is complete, finish by clicking the Finish button.

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

Management menu → Alerts → List of alerts → click on the pencil icon Builder alert.

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

• Agent: Autocomplete to choose the Agent.
• Module: List of modules of the previously selected Agent.
• Actions: Action that will be executed when the alert is triggered. If the template already has a default action it can be left at Default.
• Template: Template that will contain the trigger conditions of the alert.
• Threshold: An alert action will not be executed more than once every action_threshold seconds, regardless of the number of times the alert is fired.

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

Once an alert has been created, it will only be possible to modify the actions that have been added to the action that has the template.

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

It is also possible to delete the action that was selected when the alert was created by clicking the gray trash can icon to the right of the action, or add new actions by clicking the + button.

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

From the agent administration section you can add new alerts by navigating to the corresponding tab:

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

There you can:

次の操作ができます。

• Edit or delete each and every one of the actions of each alert assigned to the agent (column Actions).
• From the options column (Op.):
  • You can disable or enable.
  • You can put the alert in standby mode.
  • You can add an action.
  • You can clear the alert completely.
  • You can view the alert in detail.

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

• Define critical and warning threshold in module.
• Associate the alert to the module, to do so go to the alerts tab within the Agent where the Module is.
  • If necessary, you can create a new action and/or new template, by clicking on those buttons will be redirected to the corresponding sections. Once the new components have been created, you must return to the previous step.
• With the Add alert button the new alert is saved.
• Alert escalation: An alert escalation is additional actions that are executed if the alert is repeated a certain number of times consecutively.
  • It is only necessary to add the additional actions and determine between which consecutive repetitions (Number of matching alerts) of the alert this action is going to be executed.
  • When an alert recovers, all actions that have been executed up to that point will be executed again, not just those that correspond to the current Number of alerts match from setting.
  • Additionally, a Threshold can be placed as a second parameter, for which an alert cannot be launched more than once during said interval.
• Finally you can configure the sending of alert messages through instant messaging like Telegram, for example.

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

Alerts can be on, off, or in standby mode (standby). The difference between alerts that are disabled and alerts on standby is that alerts that are disabled simply won't work and therefore won't show up in the alerts view. Instead, alerts on standby will show up in the alert view and will work but only at display level. That is, it will show whether or not they are triggered but they will not carry out the actions that they have programmed nor will they generate events.

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

Alerts on standby are useful to be able to view them without disturbing other aspects.

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

Cascading protection is a feature of Pandora FMS that allows avoiding a massive bombardment of alerts when a group of Agents is not accessible, due to a failed main connection.

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

This type of thing happens, for example, when an intermediate network element such as a router or a switch fail, leaving a large part of the network managed with Pandora FMS inaccessible. Because the network checks would fail in this scenario, alerts would start triggering for downed devices without being true.

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

For the agent to work with cascading protection enabled, the parent Agent (Advanced options, token Parent) must be correctly configured, on which it depends.

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

Cascade protection is activated from the Agent configuration, Advanced options section, click on the Cascade protection modules and/or Cascade protection services option.

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

It is possible to use the Services to avoid alerts from multiple sources reporting the same incident.

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

If Service-based cascading protection is activated, Service elements (Agents, Modules or other Services) will not report problems, but the Service itself will alert on behalf of the affected element.

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

In order to receive this information you must edit or create a new alert template, using the _rca_ macro for a analisis de causa_raiz (root cause analysis ).

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

You can use the status of a Parent Agent Module to prevent them from sending Agent alerts in case it goes critical.

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

Secure operation mode can be enabled in the advanced configuration options of an Agent.

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

If the status of the selected Module goes to critical, the rest of the Agent Modules are disabled until it returns to normal or warning again. This allows, for example, to disable Remote Modules if connectivity is lost.

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

These specific macros can be added by expanding the macros section of any module.

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

• They are defined in the Module.
• Store the data in the database.
• They can have any name, for example _myMacro.
• They are not reflected in the local configuration (.conf).
• Used exclusively for alerts.
• They cannot be defined at the component level.
• They can be defined in the monitoring policies.
• Set values can be used as part of the fields in the alert definition.

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

Pandora FMS by itself has the ability to send emails as explained in general configuration of the Console.

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

However, its flexibility allows sending email with different mail platforms.

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

In order for the Pandora FMS server to be able to send alerts via Google Mail® (Gmail®) account, proceed to general configuration of the Console or to the configuration of Pandora FMS server and enter your credentials (web domain, usernames, password, etc.).

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

Action Settings

アクション設定

• An action is added, for example with the name Mail to Admin.
• To configure the mail recipient, use the eMail command, adding the recipients in Destination address Field 1 separated by commas.

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

Alert Settings

アラート設定

In the Module configuration, Alerts tab, a new alert is created with the action created.

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

• You must have an account created in Office365.
• Proceed to the general configuration of the Console or to the configuration of the Pandora FMS server and place your credentials (Office365 web domain, usernames, password, etc.).

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

Alerts can be built based on the events received or on the data collected with the log collection system. Simple or more complex alerts can be built, based on a set of rules with logical relationships.

受信したイベントまたはログ収集システムによって収集されたログに基づくアラートを作成できます。論理関係を持つ一連の表現を用いて、単純なものから複雑なものまでのアラートを作成できます。

This type of alerts allows working from a much more flexible perspective, since alerts are not generated based on the status of a specific Module, but on an event that may have been generated by several different Modules, from different Agents.

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

Event alerts and/or logs are based on filter rules that use the following logical operators:

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

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

These logical operators are used to search for events/expressions in logs that match the configured filter rules, and if matches are found, the alert will be triggered.

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

They also use the templates to define some parameters, such as the days on which the alert will work; however, in this case the templates do not determine when the event alert is fired, it is through the filter rules that the matching event alerts will be searched for and fired.

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

Management menu → Alerts → Alert correlation. In this global view, you will have the list of registered correlation alerts and the information about them, as well as options such as operating with the action disabled, in standby mode, adding more actions, editing or deleting the correlated alert.

管理(Management) メニュー → アラート(Alerts) → アラート相関(Alert correlation) へアクセスします。このグローバルビューには、登録済みの相関アラートとそれらに関する情報のリストが表示されるほか、スタンバイモードでアクションを無効化、アクション追、相関アラートの編集または削除などのオプションも表示されます。

With the Create button a new correlation alert is added, the process is similar to the creation of Alert Templates. The configuration parameters of the templates for correlation alerts are similar to those of a Module alert, there are only two specific parameters for event alerts:

作成(Create) ボタンで、新しい相関アラートが追加されます。この処理は アラートテンプレート の作成と似ています。 相関アラートのテンプレートの設定パラメータはモジュールアラートの設定パラメータと似ていますが、イベントアラート固有のパラメータは次の 2 つだけです。

• Rule evaluation mode: It can be Pass or Drop. The first means that, in case an event matches an alert, the rest of the alerts continue to be evaluated. Drop means that if an event matches an alert, the rest of the alerts are not evaluated.
• Group by: Allows you to group the rules by Agent, Module, alert or group. For example, if a rule is configured to trigger when two critical events are received and is grouped by Agent, two critical events must arrive from the same Agent. It can be disabled.

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

Each rule is configured to jump to a certain type of event or match from log; when the logical equation defined by the rules and their operators is satisfied, the alert is triggered.

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

To define the alert rules, it will be necessary to drag the elements on the left side to the drop area on the right side to build your rule.

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

Available setting items:

設定可能な項目:

These elements will be enabled to guide the user in complying with the grammar of the rule. The following is a simplified explanation of the grammar to be used:

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

Where S is the set of rules defined for the correlated alert.

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

It will be necessary to drag the element over the area of definition of rules, in such a way that the image is similar to this one for example:

たとえば次のようなイメージになるように、要素をルール定義の領域にドラッグする必要があります。

To clean and undo all changes there are two buttons: Cleanup and Reset.

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

It forces the analyzed element (whether event or log) to fulfill A and B simultaneously.

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

It forces both rules (A) and (B) to be fulfilled in the evaluation window. This means that there must exist in the last few seconds (defined by the log_window and event_window parameters) entries that satisfy both rules.

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

In the previous section "Alerts System" the operation of the fields in alerts is explained in more detail.

アラートのフィールド操作に関する詳細は、"アラートシステム" を参照してください。

In this section you must configure the actions that will be carried out when the alert is triggered and indicate at what intervals and how often said action will be executed.

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

• Actions: Action that needs to be executed.
• Number of alerts match: Number of intervals that have to pass since the alert was triggered for the action to be executed. If you need it to be always, you must leave these fields blank.
• Threshold: Interval that has to pass for the action to be executed again once the alarm is triggered.

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

Then display the list of configured actions. In this listing the triggering field shows at which alert intervals the action will be executed, as configured in number of alerts match. Also, in the Options column you can delete or modify the configured actions.

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

When you have multiple alerts, they have a specific evaluation order. They will always be evaluated in order, starting first with the first in the list.

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

If the PASS rule evaluation mode is configured, if a correlated alert is executed, the following ones will be evaluated as well. It is normal mode.

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

If the DROP rule evaluation mode is configured, if a correlated alert configured with this mode is executed, it will stop the evaluation of the rules below it. This feature gives us the possibility of cascading alert protection.

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

The rest of the correlation rules (action fields and application of actions) work similar to the rest of Pandora FMS alerts.

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

The macros that can be used within the configuration of an event alert are in macrolist.

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

The Command Macros, Action Macros and Event Alert Macros are common to each other but with the following exceptions _modulelaststatuschange_ , _rca_ and _secondarygroups_

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

_address_

Address of the Agent that triggered the alert.

_addressn_n_

The address of the Agent that corresponds to the position indicated in n. Example: addressn_1_ , addressn_2_

_agent_

Alias of the Agent who triggered the alert. If no alias is assigned, the Agent name is used.

_agentalias_

Alias of the Agent who triggered the alert.

_agentcustomfield_n_

Custom field number n of the Agent (eg _agentcustomfield_9_ ).

_agentcustomid_

Agent custom identifier.

_agentdescription_

Description of the Agent that triggered the alert.

_agentgroup_

Agent group name.

_agentname_

Name of the Agent that triggered the alert.

_agents_

Agent operating system.

_agentstatus_

Agent's current state.

_alert_critical_instructions_

Instructions contained in the Module for a critical state.

_alert_description_

Description of the alert.

_alert_name_

Alert name.

_alert_priority_

Numeric priority of the alert.

_alert_text_severity_

Alert text priority (Maintenance, Informational, Normal, Minor, Warning, Major, Critical).

_alert_threshold_

Alert threshold.

_alert_times_fired_

Number of times the alert has been fired.

_alert_unknown_instructions_

Instructions contained in the Module for an unknown state.

_alert_warning_instructions_

Instructions contained in the Module for a warning state.

_all_address_

All the addresses of the Agent who triggered the alert.

_critical_threshold_min_

Minimum critical threshold.

_critical_threshold_max_

Maximum critical threshold.

_data_

Data that caused the alert to be triggered.

_email_tag_

Email mailboxes associated to the tags of Modules.

_event_cf_text_

(Only event alerts). Get all the information from custom data in text mode (with line breaks).

_event_cf_json_

(Only event alerts). Gets the information from custom data in JSON format.

_event_cfX_

(Only event alerts). Key of the custom field of the event 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_

(Event alerts only) Extra identifier.

_event_id_

(Event alerts only) Identifier of the event that triggered the alert.

_event_text_severity_

(Event alerts only) Priority in text of the event that triggers the alert (Maintenance, Informational, Normal Minor, Warning, Major, Critical).

_eventTimestamp_

Timestamp in which the event was created.

_fieldX_

User-defined X field.

_group_contact_

Group contact information. It is configured when creating the group.

_groupcustomid_

Custom group identifier.

_groupother_

Other information about the group. It is configured when creating the group.

_homeurl_

It is a public URL link that must be configured in the general configuration options.

_id_agent_

Agent identifier, useful to build access URL to the Pandora FMS console.

_id_alert_

Alert identifier, useful for correlating the alert in third-party tools.

_id_group_

Agent group identifier.

_id_module_

Module Identifier.

_interval_

Module execution interval.

_module_

Module Name.

_modulecustomid_

Module custom identifier.

_moduledata_X_

Using this macro (“X” is the name of the Module in question) we collect the last data from this Module and if it is numeric it returns it formatted with the decimals specified in the console configuration and with its unit (if it has one). It would be useful, for example, when sending an email when a Module alert is skipped, to also send additional (and perhaps very relevant) information from other modules of the same Agent.

_moduledescription_

Module Description.

_modulegraph_nh_

(Only for alerts using the eMail command) Returns a base64-encoded image of a Module graph with a period of n hours (eg _modulegraph_24h_). It requires a correct configuration of the connection from the server to the console via API, which is done in the server configuration file.

_modulegraphth_nh_

(Only for alerts that use the _email_tag_ command) Same operation as the previous macro but only with the critical and warning thresholds of the Module, if they are defined.

_modulegroup_

Module group name.

_modulestatus_

Module Status.

_modulelaststatuschange_

(For Command Macros only)timestamp at which the Module's last state change occurred.

_moduletags_

URLs associated with the tags of modules.

_name_tag_

Name of the tags associated to the Module.

_phone_tag_

Telephones associated to the tags of modules.

_plugin_parameters_

Module plugin parameters.

_policy_

Name of the policy to which the Module belongs (if applicable).

_prevdata_

Previous data before the alert was triggered.

_rca_

Root cause analysis chain (for Services only).

_secondarygroups_

Shows the child groups of the Agent (only for command macros and action macros).

_server_ip_

IP address of the server to which the Agent is assigned.

_server_name_

Name of the server to which the Agent is assigned.

_target_ip_

IP address of the target of the Module.

_target_port_

Module target port.

_timestamp_

Time and date the alert was triggered.

_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).

_timezone_

The time zone represented by _timestamp_.

_warning_threshold_max_

Maximum warning threshold.

_warning_threshold_min_

Minimum warning threshold.

• _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 ドキュメント一覧に戻る

削除(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_ は変数です。好きなようにコマンドを設定できます。

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) へ行き、テンプレート名をクリックして編集します。

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

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 is an instant messaging platform through which you may receive alert messages from Pandora FMS.

1. Telegram は、Pandora FMS からアラートメッセージを受信できるインスタントメッセージングプラットフォームです。

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

• ルータ: 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.

ここでの例として、良く質問される 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