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:
アラートにはいくつかのタイプがあります。
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 が実行するアクションは、最終的にサーバ上で コマンド の形式で実行されます。
To create alert commands you must access as PFMS superuser.
アラートコマンドを作成するには、Pandora FMS 管理者 でログインする必要があります。
Management Menu → Alerts → Commands → Create.
管理(Management) メニュー → アラート(Alerts) → コマンド(Commands) → 作成(Create)
It is recommended to check from the command line if the execution of the command is successful and that it produces the desired result (send an email, generate an entry in a log file, etc).
コマンドの実行が成功するかどうか、また期待した結果が得られるかどうか (電子メールの送信、ログ ファイルへのエントリの生成など) をコマンドラインから確認することをお勧めします。
_html_editor_
._html_editor_
がある場合、アラートアクションの作成または編集時にコマンドフィールドに HTML エディターを表示できます。It must be taken into account that the commands for alerts executed by the Pandora FMS server are carried out with the same privileges as the user that executes the Pandora FMS server.
Pandora FMS サーバによって実行されるアラートのコマンドは、Pandora FMS サーバを実行するユーザと同じ権限で実行されることを考慮する必要があります。
/var/log/pandora/pandora_alert.log
..sendxmpprc
file must be configured first). Put in field1
the username, field2
the name of the chat room, and field3
the text message.When a public URL is set for a Web Console, emails sent will have that link set.
ウェブコンソールで 公開 URL が設定されている場合、送信されるメールにはそのリンクが設定されます。
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) ボタンをクリックします。
The system commands eMail
, Internal Audit
and Monitoring Event
cannot be changed or deleted.
eMail, Internal Audit および Pandora FMS Event は変更や削除はできません。
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)
_field1_
to _field10_
, to be used in the command. These fields can be a text field or a select combo if configured.When the Fields are assigned a value in the Triggering section, by default these will be the same values for Recovery, unless a different value is assigned.
障害通知の “フィールド” に値を設定すると、デフォルトでは異なる値を割り当てない限り、同じ値が復旧通知用にも使われます。
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: 概要
ステップ 2: 状態
NG 760 version or later: It is possible to see and configure when the alert will be active each day of the week thanks to the built-in editor that is displayed by default in simple mode. In addition, by accessing the detailed mode you can configure the schedules with greater precision.
バージョン NG 760 以降: デフォルトのシンプルモードで表示される組み込みのエディターにより、アラートが毎日有効になるタイミングを表示および設定することができます。さらに、詳細モードにアクセスすると、より正確にスケジュールを設定できます。
To periodically check modules in unknown status (Unknown status) you can either activate the token unknown_updates
in the server configuration PFMS.
不明状態 のモジュールを定期的に確認するには、Pandora FMS サーバ設定 で unknown_updates
トークンを有効にします。
Step 3: Advanced Fields
ステップ 3: 高度なフィールド
field1
… field10
(both in the alert template, as well as in the command and in the action) those defined in the macro_list.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))をクリック。
action_threshold
seconds, regardless of the number of times the alert is fired.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:
次の操作ができます。
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) 設定) が正しく設定されている必要があります。
If the parent Agent has at that moment any Module alert in a critical state, it firesda, the lower agent with cascading protection will not execute its alerts. This does not apply for module alerts in warning
or unknown
status.
親エージェントに障害状態のモジュールアラートがある場合、関連障害検知抑制が設定された下位エージェントはそのアラートを実行しません。 これは、警告
または 不明
状態のモジュールアラートには適用されません。
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) のチェックボックスをチェックします。
Version NG 727 or higher.
バージョン NG 727 以上
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.
以下の特定のマクロは、任意のモジュールのマクロセクションを展開することで追加できます。
_myMacro
..conf
)._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
アクション設定
Alert Settings
アラート設定
In the Module configuration, Alerts tab, a new alert is created with the action created.
モジュール設定のアラートタブで、作成されたアクションを使用して新しいアラートを作成します。
Version NG 741 or higher.
バージョン NG 741 以上
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.
これらの論理演算子は、設定されたフィルタルールに一致するログ内のイベント/式を検索するために使用され、一致するものが見つかった場合はアラートが発報されます。
When defining alerts about events, it will be essential to indicate the parameters agent, module and event.
イベントに関するアラートを定義する場合、agent、module、および event パラメータを指定することが重要です。
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.
また、アラートが動作する日などのいくつかのパラメーターを定義したテンプレートを利用します。 ただし、この場合、テンプレートはイベントアラートがいつ発報されるかを定義しません。フィルタールールを介して一致するイベントが検索され、対応するアラートが発報されます。
Given the high number of events that the Pandora FMS database can host, the server works on a maximum event window, which is defined in the pandora_server.conf
configuration file through the event_window
and log_window
parameters. Events that have been generated outside this time window will not be processed by the server, so it does not make sense to specify in a rule a time window greater than the one configured on the server.
Pandora FMS データベースに保存できるイベントの数が多い場合、サーバは、pandora_server.conf
設定ファイルで event_window
という名前のパラメータで定義された最大イベントウィンドウで動作します。指定された時間範囲外に生成されたイベントは、サーバで処理されません。そのため、サーバで設定された時間範囲よりも広い時間範囲をルールで指定することには意味がありません。
For the event correlation alerts to work, the event correlation server must be activated with the eventserver 1
parameter in the Pandora FMS server configuration file.
イベント相関アラートが機能するためには、Pandora FMS サーバ設定ファイルのパラメーター eventserver 1
でイベント相関サーバを有効化する必要があります。
Menu Management → Alerts → Alert correlation.
メニュー 管理(Management) → アラート(Alerts) → アラート相関(Alert correlation)。
In this overview, 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.
この概要には、登録済みの相関アラートとそれらに関する情報のリストが表示されるほか、スタンバイモードでアクションを無効化、アクション追、相関アラートの編集または削除などのオプションも表示されます。
With the Create button, a new correlation alert is added, the process is similar to Alert Template creation. 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 つだけです。
In case of alerts that contain logs rules, it will only affect grouping by Agent. If you choose a different grouping, alerts based on log entries will never be honored.
ログルールを含むアラートの場合、エージェントによるグループ化にのみ影響します。 別のグループ化を選択した場合、ログベースのエントリのアラートは決して一致しません 。
Each rule is configured to trigger based on 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:
これらの要素は、ユーザがルールの文法を満たすようにするガイドをします。ここで、使用される文法についてさらに説明します。
S → R | R + NEXUS +R
R → FIELD + OPERATOR + C | FIELD + OPERATOR + C + MODIFIER
C → VARIABLE
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:
たとえば次のようなイメージになるように、要素をルール定義の領域にドラッグする必要があります。
The comparison operators ==
and !=
compare text strings literally. For more flexibility consider using the REGEX
operator which uses Regular Expressions.
比較演算子 ==
および !=
では、テキスト文字列が文字通り比較されます。 より柔軟な比較には、正規表現を用いる REGEX
の利用を検討ください。
To clean and undo all changes there are two buttons: Cleanup and Reset.
すべての変更をクリーンアップして元に戻すには、'クリーンアップ(Cleanup)' および 'リセット(Reset)' ボタンを使用します。
It will only save the changes when you click the Next button.
次(Next) ボタンを押さないうちは、変更は保存されません。
Remember: The blocks have simultaneity when fulfilling the condition. Look at the following theoretical examples.
条件を満たすブロックが同時にあることに注意してください。次の理論的な例を確認してください。
(A and B)
It forces the analyzed element (whether event or log) to fulfill A and B simultaneously.
分析された要素(イベントまたはログ)が A と B を同時に満たすようにします。
A and 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
パラメータで定義される)には、両方のルールを満たすエントリが存在する必要があります。
Version 764 or later:
The macros related to modules and agents are not available in the Fields of the recovery section since the recovery of these alerts is executed when the threshold ends and lacks an event recovery to obtain such information.
バージョン 764 以降:
モジュールとエージェントに関連するマクロは復旧セクションのフィールドでは使用できません。これらのアラートの復旧がしきい値範囲内に戻った際に実行されますが、情報を取得するための復旧イベントがないためです。
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.
ここでは、アラートが発報されたときに実行するアクションを設定と、そのようなアクションを実行する間隔と頻度を設定します。
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.
If “X” (name of the Module in question) contains spaces, these must be placed as an HTML entity:
 
You can view a list of HTML entities on Wikipedia.
_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進形式で、その単位とともに返されます。 たとえば、同じエージェントの他のモジュールに関する情報をアラートメールで送信する場合に役立ちます(これは非常に重要です)。“X” (モジュール名)にスペースを含む場合は、次のように HTML エンティティ に置き換える必要があります。
 
HTML エンティティ一覧は、ウィキペディアで確認してください。
_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_
: 最小警告閾値削除(Delete): アラートを削除するには、アラートの右側にあるグレーのごみ箱アイコンをクリックします。
複製(Copy): アラートはコピーすることができます。フィールドやグループなどの詳細を変更することで、既存のコマンドと似たのコマンドを作成する場合に便利です。
eMail 、Internal Audit および、Pandora FMS Event は削除や複製はできません。
Jabber サーバを通して、アラートを送信するように Pandora FMS を設定するのはとても簡単です。Jabber はログだけでなく、アラートをリアルタイムで送ることができるシステムで、アラートを受け取る人のグループを設定することができます。
Jabber サービスのインストール
クライアント側の手順:
Pandora FMS サーバ側の手順:
useraccount@jabber.org password
chmod 0600 .sendxmpprc
以上で、次のようにコマンドラインからメッセージを送信できるようになります。
$ echo "Hello" | sendxmpp -s pandora useracount@jabber.org
Pandora FMS のウェブコンソールにアラートを登録するには、新たなコマンドを追加し、その設定を行います。次のようにすると良いでしょう。
コマンドを次のように定義します。
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
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)
アラートが発報されrたときに実行されるアクション。
テンプレートにデフォルトがある場合は、デフォルトのままにします。
テンプレート(Template)
アラート発報設定を含むテンプレート。
閾値(Threshold)
アラートが発報された回数に関係なく、アラートアクションは action_threshold
秒ごとに1回の実行になります。
アラートを作成すると、テンプレートが持っているアクションのみ編集することができます。
アクションの右側にあるグレーのごみ箱アイコンをクリックすることにより、選択したアラートを削除することもできます。また、“追加(Add)” ボタンをクリックすることにより新たに追加することもできます。
以下のスクリーンショットでは、障害と警告のしきい値を設定したい “CPU Load” というモジュールがあります。
次のスクリーンショットに示すように、モジュール編集フォームにアクセスしてしきい値を設定します。
ローカルモジュールの変更は、Enterprise 版のコンソールからのみ可能であることに注意してください。それ以外の場合は、エージェント設定ファイルを直接編集する必要があります。
変更を承認して保存します。 モジュール 'CPU Load' の値が 70〜90 の場合、そのステータスは警告となり、91〜100 は障害となり以下のように赤色で表示されます。
次に、“オペレータに電子メールを送信する” アクションを作成する必要があります。 アラート > アクション のメニューへ行き、新しいアクションを作成するボタンをクリックします。
このアクションは、メールの宛先アドレス、サブジェクト、およびメッセージ本文に対応する 'Field1'、 'Field2'および 'Field3' という名前のフィールドとともに、'Send email' コマンドを利用します。
障害状態のモジュールに対して一般的なアラートテンプレートが作成され、デフォルトのアクションは電子メールでオペレータのグループに通知することです。“テンプレート” セクションからテンプレートを定義します。
ステップ 1:
ここで設定された優先度は、アラートが発報されたときに特定の色でイベントを表示するために使用されます。
ステップ2では、特定の発報条件を決定するパラメータ(モジュールに必要な状態やシステムが動作する時間範囲など)を指定します。
ステップ 2:
このステップで最も重要なパラメータは次の通りです。
ステップ3では、フィールド1、フィールド2、フィールド3 などのフィールドがあります。前に説明したように、テンプレートからアクション、およびアクションからコマンドへのパラメータが転送されます。 さらに、この第3のステップでは、障害発生状況が正常に戻ったときに別のアクションを実行することができる アラートリカバリ を有効または無効にすることができます。
以上で、必要な設定が完了しました。あとは、アラートテンプレートをモジュールに関連づけるだけです。そのためには、エージェントのモジュールのアラートタブへいきます。
設定は簡単です。この画面ショットでは、 “Last_Backup_Unixtime” というモジュールに対して、事前に定義した “Module critical” というアラートが設定されています。加えて、ここでは下の画面を操作して、モジュール “cpu-sys” と、アラートテンプレート “Module critical” を関連づけようとしています。デフォルトで、このテンプレートで設定した “Sancho Lerena へメールを送信する” というアクションが表示されています。
モジュールにアラートを関連付けしたら、連続して複数回繰り返されるアラートがあった場合にアクションを追加することができます。これが、スケーリングアラートです。
追加のアクションを加え、次の画面キャプチャのように、アラートが何回連続したかでアクションを実行するかを定義します。
アラート発生数に達した場合、発生数を定義したアクションだけでなく、その時点まで実行されたすべてのアクションが再実行されます。
さらに、2つ目の間隔を設定することができます。このとき、指定の間隔内に複数回アラートを送信することはできません。
次のようなモニタ設定があったとします。
ウェブサーバとデータベースサーバでは、ルータを親として定義します。ウェブサーバとデータベースサーバにおいて、関連障害検知抑制のチェックボックスをチェックします。 ここで、いくつかの単一アラートを定義します。
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”)になります。
Pandora FMS では、宛先の電話番号に単語(英数字)を使用できますが、一部の携帯電話会社は英数字の ID を適切に管理していないことに注意してください。
次の手順では、既存のアラートテンプレートまたは新しいアラートテンプレートを使用できます。
この場合、アラートテンプレートは、モジュールが障害
状態になったときにのみ発報されます。
これを定義したら、アラートを最大で1日1回発生するように設定します。 ただし、復旧した場合も再び発報します。 次の図を参照してください。
ここで、モジュールにアラートテンプレートとアクションを割り当てます。
CPUワークロードモジュールで、メッセージ転送をテストできるように 20未満の値を設定します。 次の画面を見てください。
最後に、アラートの実行を “強制” することができます。つまり、エージェントのアラートをすぐに実行します。 エージェントのアラートビューに移動し、緑色の円のアイコンをクリックします。
次の図に示すように、携帯電話で SMS を受信するはずです。 テストメッセージが “aeryn” に置き換えられていることに注意してください。さらに、CPUワークロード値は “N/A” を示します。これは、アラートを強制すると、データを取得する時間がなく 、モジュールが実際のデータを受信しないためです。
Pandora FMS には柔軟性があるため、いろいろな場面において便利です。次の手順は高度な手順であり、常に例外的なものとして扱う必要があります。時には、このような定義も必要になるでしょう。
メール送信は、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
に出力されている定義されたアラートの実行ログを探します。
From version NG 754 onwards, additional options are available for manual startup and shutdown of High Availability (HA) environments.
バージョン NG 754 以降では、高可用性(HA)環境における手動での起動・停止の追加オプションがあります。
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