Pandora:Documentation ja:Intro Monitoring

提供: Pandora FMS Wiki JP

移動先: 案内, 検索

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


All user interaction with Pandora FMS is done through the WEB console. The console allows access through a browser without the need to install heavy applications, allowing management from any computer with a browser.

Pandora FMS のすべてのユーザ操作は、ウェブコンソールを通して行います。コンソールへのアクセスは、任意のコンピュータから特別なプログラムを必要とせずブラウザで行うことができます。

Monitoring is the execution of processes on all types of systems to collect and store information, take action and make decisions based on such data.


Pandora FMS is a scalable monitoring system that has multiple functionalities to extend the scope and volume of information collected practically without limits.

Pandora FMS は、収集する情報の範囲や量を拡張できる複数の機能をもったスケール可能な監視システムです。

Pandora FMS におけるエージェント

All monitoring done by Pandora FMS is managed through a generic entity called 'Agent' which is included in a more generic segment called 'Group'. These agents will be equivalent to each of the different monitored computers, devices, websites or applications.

Pandora FMS によるすべての監視は、'グループ' と呼ばれるより一般的な範囲に含まれる 'エージェント' と呼ばれる一般的なエンティティを通して管理されます。 これらエージェントは、監視対象のさまざまなコンピュータ、デバイス、Webサイト、またはアプリケーションを表します。

The agents defined in the Pandora FMS console can present local information gathered through a software agent, remote information collected through network checks, or both. Therefore, it is worth highlighting the difference between agents as an organizational unit in the Pandora FMS console, and software agents as local data collection services.

Pandora FMS コンソールで定義されたエージェントでは、ソフトウェアエージェントを通じて収集されたローカル情報、ネットワークチェックを通じて収集されたリモート情報、またはその両方を表示できます。 そのため、Pandora FMS コンソール上で表現されるエージェントと、対象システムにインストールしてローカルでデータを収集するソフトウェアエージェントは異なるということを理解することが重要です。



Monitoring can be divided into two large groups based on how we collect the information: monitoring based on software agents and remote monitoring.

Pandora FMS には、主にソフトウエアエージェントを使った方法とリモートで行う方法の 2つの監視手法があります。

Agent-based monitoring consists of installing a small software that remains running on the system and obtaining information locally through the execution of commands and scripts.

エージェントベースの監視 は、監視対象にインストールした小さなソフトウエアを用い、ローカルでコマンドやスクリプトを実行して情報を取得します。

Remote monitoring is the use of the network to run remote checks on systems, without the need to install any additional components on the equipment to be monitored.

リモート監視 は、監視対象の確認をリモートからネットワークを介して行います。監視対象には、追加のソフトウエアをインストールする必要はありません。

As can be seen, agent based monitoring will obtain the information through local checks while remote monitoring will obtain the information through network checks from the Pandora FMS server.

つまり、エージェントベースの監視は監視対象のローカルでチェックをして情報を取得し、リモート監視は Pandora FMS サーバからリモートでのチェックで情報を取得します。

With Pandora FMS, the monitoring can be carried out one way or another and also combined, producing a mixed monitoring.

Pandora FMS においては、一つの手法もしくは組み合わせでの監視が可能です。

Both types of agent share the same general configuration and data visualization.



  • Alias: For proper operation of all functions performed by Pandora FMS with their agents/modules, it is recommended not to use characters such as /,\,|,%,#,&,$ in the name of the agent. When dealing with these agents, they can be misleading when using system paths or when running other commands, causing errors on the server.
  • Server: Server that will execute the checks configured in agent monitoring, special parameter in case of having configured HA in its installation.
  • Secondary groups: Optional parameter for an agent to belong to more than one group.
  • Cascade protection: Parameter with which an avalanche of alerts can be avoided. It is possible to choose an agent or a module of an agent. In the first case, when the chosen agent is in critical, the agent will not generate alerts. In the second case, only when the specified module is critical, the agent will not generate alerts.
  • Module definition: Three work modes can be selected
    • Learning mode: If an XML arrives with new modules, they will be created automatically (by default).
    • Normal mode: If an XML arrives with new modules, they will not be created unless they have already been declared in the console.
    • Auto-disable mode: Same as learning mode, but if all modules go into unknown, the agent will be disabled until information arrives again.
  • 別名(Alias): Pandora FMS がエージェント/モジュールを使って実行するすべての機能を正しく処理するために、エージェント名には /、\、|、%、#、&、$などの文字を使用しないことをお勧めします。 これらのエージェントを使うと、システムパスを使用しているときや他のコマンドを実行しているときに誤解を招き、サーバー上でエラーを引き起こす可能性があります。
  • サーバ(Server): エージェント監視で設定されたチェックを実行するサーバです。インストールで HA を設定した場合は特別なパラメータです。
  • セカンダリグループ(Secondary groups): エージェントが複数のグループに属するためのオプションパラメータ。
  • 関連障害検知抑制(Cascade protection): 関連アラートが大量にあがることを回避することができるパラメータ。 エージェントまたはエージェントのモジュールを選択することができます。 前者の場合、選択されたエージェントが障害状態にあると、エージェントはアラートを生成しません。 後者の場合、指定されたモジュールが障害の場合は、エージェントはアラートを生成しません。
  • モジュール定義(Module definition): 3つの動作モードを選択できます。
    • 学習モード(Learning mode)): 新たなモジュールを含む XML を受け取った場合、モジュールを自動的に作成します。(デフォルト)
    • 通常モード(Normal mode): 新たなモジュールを含む XML を受け取った場合、すでにコンソールに設定が無ければ作成しません。
    • 自動無効化モード(Auto-disable mode): 学習モードと同じですが、全モジュールが不明になった場合に情報が再度車でエージェントを無効化します。


In this screen, plenty of information on the agent can be seen, with the possibility of forcing the remote execution and refreshing the data.


In the upper part a summary with the agent data can be seen:

  • Total of modules and their status.
  • Events in the last 24 hours
  • Agent Information
    • Name
    • Version
    • Agent accessibility
    • Group
  • ...


  • 全モジュールとその状態
  • 直近 24時間のイベント
  • エージェント情報
    • 名前
    • バージョン
    • エージェント接続
    • グループ
  • ...

Next, the list of modules belonging to the agent is displayed, where it will not be possible to view modules in uninitiated status, and below the alerts generated for those modules.


Finally, the events generated from the agent are displayed.



Modules are units of information stored within an agent. They are the monitoring elements with which the information is extracted from the device or server to which the agent points. Each module can store only one metric. There cannot be two modules with the same name inside the same agent. All modules have an associated status, which can be:

  • Not started: where no data has been received yet.
  • Normal: data is being received with values out of the warning or critical thresholds.
  • Warning: Data is being received with values within the warning threshold.
  • Critical: Data is being received with values within the critical threshold.
  • Unknown: the module has been running and has stopped receiving information for a certain amount of time.

モジュールは、エージェント内に格納されている情報の単位です。 これらは、エージェントが指しているデバイスまたはサーバの状態を見る監視項目です。 各モジュールに格納できるメトリックは 1つだけです。 同じエージェント内に同じ名前の 2つのモジュールを設定することはできません。 すべてのモジュールは以下の状態を持ちます。

  • 未初期化(Not started): まだデータを受け取っていません。
  • 正常(Normal): データを受け取っており、値が警告や障害の閾値を超過していません。
  • 警告(Warning): データを受け取っており、値が警告閾値を超過しています。
  • 障害(Critical): データを受け取っており、値が障害閾値を超過しています。
  • 不明(Unknown): モジュールは動作していますが、一定期間情報の受け取りが停止しています。

The modules have different types of data, such as Boolean, numeric or alphanumeric. Depending on the information collected by the module, it will be one type or another.



There are several types of modules inside Pandora FMS.

  • Data module: it is a type of local monitoring module with which checks are made on the system in which the agent is located, such as for example the use of CPU of the device or its free memory. To find out more about this type of monitoring, go to the following link.
  • Network module: it is a type of remote monitoring module with which checks are made to verify the connection with the device or server to which the agent points, for example whether it is working or whether it has a particular port open. To learn more about this type of monitoring, go to the following link.
  • Plugin module: this is a type of local or remote monitoring module with which custom checks can be made through the creation of scripts. With them, more advanced and extensive checks than the ones proposed directly through Pandora FMS console can be done. To find out more about this type of monitoring, go to the following link.
  • WMI module: this is a type of local monitoring module with which the Windows system can be checked through the WMI protocol, such as obtaining the list of installed services or the current CPU load. To find out more about this type of monitoring, go to the following link.
  • Prediction module: this is a type of predictive monitoring module with which different arithmetic operations are performed through the consultation of data from other "base" modules, such as the average CPU usage of the monitored servers or the sum of connection latency. To learn more about this type of monitoring, go to the following link.
  • Webserver module: this is a type of web monitoring with which checks of the status of a website are made and data is obtained from it, such as for example to see whether a website is down or if it contains a specific word. To find out more about this type of monitoring, go to the following link.
  • Web analysis module: this is a type of web monitoring with which simulations of a user's web browsing are carried out, such as browsing a website, introducing credentials or complying with forms. To learn more about this type of monitoring, go to the following link.

Pandora FMS には、いくつかのモジュールのタイプがあります。

  • データモジュール(Data module): これは、たとえばデバイスの CPU や空きメモリの使用など、ソフトウエアエージェントがインストールされているシステムでチェックが行われるローカル監視モジュールです。 この種の監視についてもっと知りたい場合は、こちら を参照してください。
  • ネットワークモジュール(Network module): これは、エージェントが機能しているかどうか、または特定のポートが開いているかどうかなど、エージェントが指しているデバイスまたはサーバとの接続を確認するために使用されるリモート監視モジュールです。 この種の監視についてもっと知るためには、こちら を参照してください。
  • プラグインモジュール(Plugin module): これは、ローカルまたはリモートの監視モジュールで、スクリプトを作成してカスタムチェックを行うことができます。 それらを使って、Pandora FMS コンソールからデフォルトの監視機能よりもさらに高度で広範囲なチェックを行うことができます。この種の監視についてもっと知りたい場合は、こちら を参照してください。
  • WMI モジュール(WMI module): これは、Windows システムに対して、インストールされているサービスのリストや現在の CPU 負荷の取得などができるリモート監視モジュールです。 この種の監視についてもっと知りたい場合は、こちら を参照してください。
  • 予測モジュール(Prediction module): これは、監視対象サーバーの平均 CPU 使用率や接続待ち時間の合計など、他の "基本" モジュールからのデータを参照してさまざまな算術演算を実行する予測監視モジュールです。 この種の監視についてもっと知るためには、こちら を参照してください。
  • ウェブサーバモジュール(Webserver module): これは、たとえば Web サイトが停止しているかどうか、または特定の単語が含まれているかどうかを確認するなど、Web サイトの状態をチェックしてデータを取得する Web 監視です。この種の監視についてもっと知りたい場合は、こちら を参照してください。
  • ウェブ分析モジュール(Web analysis module): これは、Web サイトの参照、資格情報の導入、フォームへの準拠など、ユーザの Web 参照のシミュレーションが実行できる Web 監視です。 この種の監視についてもっと知りたい場合は、こちら を参照してください。


Within the configuration of each module, there are parameters common to all of them.


  • Using module component: Pandora FMS has a repertoire of default modules that can be used. Depending on the selected module, the necessary parameters will be automatically filled in to carry out the monitoring. This token appears in all types of modules except prediction ones.
  • Dynamic Threshold Interval: token for dynamic monitoring to be explained in a later section.
  • Warning/Critical Status: token for status monitoring which will be explained in a later section.
  • FF threshold: FlipFlop (FF) is known as a common phenomenon in monitoring: when a value fluctuates frequently between alternative values (RIGHT/WRONG), which makes it difficult to interpret. When this occurs, a "threshold" is usually used so that in order to consider something as having changed status, it has to "stay" more than X intervals in a state without being altered. We call this in Pandora FMS terminology: "FF Threshold".
  • モジュールコンポーネントの利用(Using module component): Pandora FMS には、使用可能なデフォルトモジュールのレパートリーがあります。 選択したモジュールに応じて、監視を実行するために必要なパラメータが自動的に入力されます。 この設定は予測モジュールを除くすべてのタイプのモジュールにあります。
  • 動的閾値間隔(Dynamic Threshold Interval): 後述の章で説明する動的監視の設定です。
  • 警告/障害状態(Warning/Critical Status): 後述の章で説明する状態監視の設定です。
  • 連続抑制回数(FF threshold): 障害と復旧の繰り返しは、監視における一般的な現象として知られています。値が正常・障害の間で頻繁に変動する場合、扱いが難しくなります。 これが発生すると、通常 "しきい値" に従って状態が変化してしまうため、一定回数連続して障害状態になった場合のみ障害としたい場合があります。 これを Pandora FMS の用語では "連続抑制回数(FF threshold)" と呼びます。


The FF Threshold parameter (FF=FlipFlop) is used to "filter" the continuous changes of state in the creation of events/status, so you can indicate to Pandora FMS that until an element is not at least X times in the same status after having changed from an original status, it will not consider as if has changed. Lets see a classical example: one ping for a host where there is loss of packages. In an evironment of this kind, it could give results as these:

連続抑制回数 (FF Threshold: FF は FlipFlop を意味します) パラメータは、イベントや状態の連続的な変化をフィルタするために利用します。オリジナルの状態から変化した状態が連続して X 回を超えて続かないと、変化が発生したと Pandora FMS が認識しないようにすることができます。以下に例を見てみましょう。あるホストへの ping でパケットロスがあります。このような場合、次のような結果になります。


However, the host is alive in all cases. What we really want to say to Pandora is that until the host does not say that is at least three times down, it does not show it as this, so in the previous case it would never be as down, and it would only be this way in this case:

しかし、ホストは稼働しています。連続抑制回数を 2に設定し、少なくとも 3回連続でダウン状態にならないと、Pandora にダウンと認識し通知して欲しくないとすると、上記の例はダウンと見なさないパターンに該当します。逆に以下のような場合にダウンと認識します。


From this point, it will show it as down, but no before.


So the FLip_Flop protections is useful to avoid these disturbing fluctuations. All modules implement it and its use is to avoid the change of status ( limited by its defined limits or automatic limits, as in the case of the *proc modules).

連続抑制回数は、このような不安定な変動を避けるために便利です。すべてのモジュールにおいて実装されており、状態の変化を避けるのに利用します (*proc モジュールの場合は、設定された制限もしくは自動制限により制限されます)。

From 5.1 version, the FF threshold has two modes.

バージョン 5.1 からは、連続抑制回数には 2つのモードがあります。

  • All state changing: same value is used for all state changing, to normal, warning and critical.
  • Each state changing: different value can be set for each state changing, to normal, warning and critical.
  • 全状態変化(All state changing): 正常、警告、障害すべての状態変化に対して、同じ値を利用します。
  • 個別状態変化(Each state changing): 正常、警告、障害への状態変化ごとに異なる値を設定できます。

In async modules, the timeout (FF timeout) can also be set. It's useful if you want to fire an alert only when the data server received several critical/warning data in a short period of time. When data arrival interval exceeded the timeout, the counter of FF threshold is reset.

非同期モジュールでは、タイムアウト(連続抑制タイムアウト)も設定できます。短時間に複数回、警告や障害のデータを受信した場合にのみ障害通知をしたい場合に便利です。 データを受信する間隔がタイムアウト値を超えた場合は、連続抑制回数のカウンタがリセットされます。

Ff timeout.png

For example, if you want to fire an alert only when agent sends critical data twice in 5 minutes (you don't want to fire an alert when data arrival interval exceeds 5 minutes.), set the FF threshold to 1 and the FF timeout to 300.

たとえば、エージェントから 5分以内に 2回障害データが送られた場合にのみ通知をしたい場合(5分を超える間隔でデータが送られてきても障害通知したくない場合)は、連続抑制回数に 1、連続抑制タイムアウトに 300 を設定します。

    • カウンタ保持

This is an advanced option of the Flip Flop to control the status of a module. By means of "keep counters" some counter values will be established to go from one status into another depending, instead of the value, on the status of the module with the received value.

これは、連続抑制の高度なオプションで、モジュールの状態を制御します。"カウンタ保持" によって、値ではなく、受け取った値を持つモジュールの状態に応じて、あるステータスから別のステータスに移行するためのいくつかのカウンタ値が設定されます。

An example of how it works is shown below:


Let us suppose there is a module with the following characteristics:


Interval: 5 min.
  Critical: 90 - 100;
  Warning: 80 - 90;

Flip Flop:
   Normal: 0;
   Warning: 3;
   Critical: 2;

Current Status: Normal;
間隔: 5分
  障害: 90 - 100;
  警告: 80 - 90;

   正常: 0;
   警告: 3;
   障害: 2;

現在の状態: 正常;

And these data/Status are received:


Data Status
81 Warning
83 Warning
95 Crítical
89 Warning
98 Crítical
81 Warning
86 Warning
データ 状態
81 警告
83 警告
95 障害
89 警告
98 障害
81 警告
86 警告

As it can be seen in the example, the data shown belong to status warning and critical but the current status is normal because the Flip Flop conditions are not met.


By setting the keep counters parameter, a status counter will be kept, resulting in the change of status as shown below:


Data Data Status Module Status
81 Warning Normal
83 Warning Normal
95 Critical Normal
89 Warning Warning
98 Critical Warning
81 Warning Warning
86 Warning Warning
データ データの状態 モジュールの状態
81 警告 正常
83 警告 正常
95 障害 正常
89 警告 警告
98 障害 警告
81 警告 警告
86 警告 警告

Let us look at a more complete case:


Let us suppose there is a module with the following characteristics:


Interval: 5 min.
  Critical: 90 - 100;
  Warning: 80 - 90;

Flip Flop:
   Normal: 2;
   Warning: 3;
   Critical: 2;

Current Status: Normal;
間隔: 5分
  障害: 90 - 100;
  警告: 80 - 90;

   正常: 2;
   警告: 3;
   障害: 2;

現在の状態: 正常;

The Status counter will only accumulate normal and critical statuses if they arrive consecutively. On the other hand, the Status warning may accumulate them even if they do not arrive consecutively.


The Status counter will be restarted in the following cases: - A value whose Status coincides with the current Status is arrives. - The status is changed when the " keep counter " conditions are met.

状態カウンタは、以下のような場合にリセットされます。 - 値の状態が現在の状態と一致する値が到着した場合 - "カウンタ保持" の状態にマッチし、状態が変更された場合

Normal and Critical Counters have a special behavior, for which only these Counters will be restarted, if they are not consecutive.


In this case, the following data is received:


Data Status data Critical counter Warning counter Normal counter Module Status
81 Warning 0 1 0 Normal
83 Warning 0 2 0 Normal
95 Critical 1 2 0 Normal
89 Warning 0 0 0 Warning
When the warning counter gets to three, the status is changed to warning and all counters are restarted
50 Normal 0 0 1 Warning
98 Critical 1 0 0 Warning
The normal counter and the critical counter must be consecutive to keep increasing. When receiving a critical value, the normal counter becomes 0
91 Critical 0 0 0 Critical
When the critical counter reaches two, the status is changed to critical and all counters are restarted
30 Normal 0 0 1/td> Critical
31 Normal 0 0 0/td> Normal
When the normal counter reaches two, the status is changed to normal and all counters are restarted
81 Warning 0 1 0/td> Normal
83 Warning 0 2 0/td> Normal
12 Normal 0 0 0/td> Normal
When receiving data in Normal Status that is equal to the current status, the counters are restarted.
データ データの状態 障害カウンタ 警告カウンタ 正常カウンタ モジュールの状態
81 警告 0 1 0 正常
83 警告 0 2 0 正常
95 障害 1 2 0 正常
89 警告 0 0 0 警告
警告カウンタが 3 になったとき、状態が警告に変更されカウンタはリセットされます。
50 正常 0 0 1 警告
98 障害 1 0 0 警告
正常カウンタと障害カウンタが増え続けるには、連続している必要があります。障害状態の値を受信したとき、正常カウンタは 0 になります。
91 障害 0 0 0 障害
障害カウンタが 2 に達すると、状態は障害に変更されカウンタはリセットされます。
30 正常 0 0 1/td> 障害
31 正常 0 0 0/td> 正常
正常カウンタが 2 に達すると、状態は正常に変更されカウンタはリセットされます。
81 警告 0 1 0/td> 正常
83 警告 0 2 0/td> 正常
12 正常 0 0 0/td> 正常

Within the advanced options of the modules, the following common parameters can be observed.


  • Interval: Parameter where the period in which the module should return data is defined. In the case of remote modules, this is the period in which the remote check is performed. In the case of data modules, it is a numerical value which represents X times the defined agent interval, performing the local check in that period. If a module spends more than two intervals without receiving data, it will go into in unknown state.
  • Post process: Parameter by which the data received by the module can be converted. By default it is disabled with the value 0. The following conversions can be made:
    • Seconds to months
    • Seconds to weeks
    • Seconds to days
    • Seconds to minutes
    • Bytes to Gigabytes
    • Bytes to Megabytes
    • Bytes to Kilobytes
    • Timeticks to weeks
    • Timeticks to days
  • FF interval: If the flip-flop threshold is activated and there is a state change, the module interval will be changed for the next execution.
  • FlipFlop timeout: Parameter that can only be used in asynchronous modules. For a state change by flip-flop to be effective, equal consecutive data must be received within the specified interval.
  • Quiet: Parameter by which the module will continue to receive information, but no type of event or alert will be generated.
  • Cascade Protection Services: Parameter by which the generation of events and alerts would go through to the service to which it belongs if this feature is enabled.
  • Cron: Parameter by which it is possible to specify periods of time in which the module will be executed with the nomenclature: Minute, Hour, Day of the Month, Month, Day of the week. There are three different possibilities:
    • Cron from: any -> No monitoring restrictions (default)
    • Cron from: specific. Cron to: any -> To be executed only when it matches the specified number. Ex: 15 20 * * *, will run every day at 20:15
    • Cron desde: specific. Cron to: specific -> It will run during the established interval. Ex: 5-10 * * * *, will run every hour from 5 to 10 minutes.
  • Custom macros: Any number of custom module macros may be defined. The recommended format for macro names is:
  • 間隔(Interval): モジュールがデータを返す間隔を定義するパラメータです。 リモートモジュールの場合、これはリモートチェックが実行される期間です。 データモジュールの場合、それは定義されたエージェント間隔の X倍を表し、その期間にローカルチェックを実行する数値です。 モジュールがデータを受信しない状態が 3周期以上続くと、不明状態になります。
  • 保存倍率(Post process): モジュールの受信データの保存時の倍率です。デフォルトは 0 で無効状態です。次の変換を実行できます。
    • Seconds to months
    • Seconds to weeks
    • Seconds to days
    • Seconds to minutes
    • Bytes to Gigabytes
    • Bytes to Megabytes
    • Bytes to Kilobytes
    • Timeticks to weeks
    • Timeticks to days
  • 連続抑制時の間隔(FF interval): 連続抑制が有効で状態変化がある場合、次の実行でモジュールの間隔が変更されます。
  • 連続抑制タイムアウト(FlipFlop timeout): 非同期モジュールでのみ使用できるパラメータです。連続抑制による状態変化を有効にするためには、指定された間隔内に連続してデータを受信しなければなりません。
  • 静観(Quiet): モジュールが情報を受信し続けますが、イベントや警告は生成されません。
  • サービス関連障害検知抑制(Cascade Protection Services): これが有効になっている場合、イベントおよびアラートの生成はそれが属するサービスによります。
  • Cron: 分、時間、日、月、曜日でモジュールの実行を指定することができます。3つの設定があります。
    • Cron from: any -> 制限はありません。(デフォルト)
    • Cron from: specific. Cron to: any -> 特定のタイミングで実行します。例: 15 20 * * * は、毎日 20:15 に実行します。
    • Cron desde: specific. Cron to: specific -> 特定の期間で実行します。例: 5-10 * * * * は、毎時 5 から 10分に実行します。
  • カスタムマクロ(Custom macros): 任意の数のカスタムモジュールマクロが定義できます。マクロのフォーマットは次の通りです。

For example:



These macros can be used in module alerts. IF THE MODULE IS A WEB MODULE ANALYSIS TYPE:

これらのマクロは、モジュールのアラートで利用できます。 モジュールが Web 分析モジュールタイプの場合:

Dynamic macros will have a special format starting with @ and will have these possible replacements:

動的マクロは @ で始まる特別なフォーマットを持ち、これらは置換されます。

   @DATE_FORMAT (current date/time with user-defined format)
   @DATE_FORMAT_nh (hours)
   @DATE_FORMAT_nm (minutes)
   @DATE_FORMAT_nd (days)
   @DATE_FORMAT_ns (seconds)
   @DATE_FORMAT_nM (month)
   @DATE_FORMAT_nY (years)
   @DATE_FORMAT (ユーザが指定したフォーマットでの現在日時)
   @DATE_FORMAT_nh (時間)
   @DATE_FORMAT_nm (分)
   @DATE_FORMAT_nd (日)
   @DATE_FORMAT_ns (秒)
   @DATE_FORMAT_nM (月)
   @DATE_FORMAT_nY (年)

Where "n" can be a number without a sign (positive) or negative.

ここで、"n" は符号やマイナスを含まない数値です。

  • Tags: They are tags linked to each of the modules that later on spread to the events generated by this module. They can be used in that module's event alerts. Tags are quite useful since they can work as filter in reports, event views and they even have their own specific views. Each tag's additional information (URL, email, phone number) can be used in alerts as they are available as macro.
  • タグ(Tags): これらは各モジュールにリンクされたタグであり、後でこのモジュールによって生成されたイベントに展開されます。 これらは、そのモジュールのイベントアラートで使用できます。 タグは、レポート、イベント表示でフィルターとして機能し、かつ、独自の表示機能を持っているため、非常に便利です。 各タグの追加情報 (URL、メールアドレス、電話番号) は、マクロとして使用できるため、アラートで使用できます。

To be able to create a tag, click on Module tags:


The tag allows to define a name, a description and there is also the possibility to add the complete URL (http://somewebpage.com), email or phone number associated to that tag. It is worth highlighting that one or several tags can be associated to the same module. However, they must first be created as it was previously described, and then they will be available to be allocated to each module.

タグを使用することにより、名前、説明を定義できます。また、そのタグに関連付けられている完全な URL(http://somewebpage.com )、メールアドレス、または電話番号を追加することもできます。 1つまたは複数のタグを同じモジュールに関連付けることができます。 ただし、先に説明したとおり、最初に作成しておく必要があり、あとから各モジュールに割り当てます。

Within module advanced options, the left column shows the tags available and the right column shows the tags linked to that module:


Furthermore, tags can be used to grant module specific access permissions, so that a user can access only that agent's module without having access to the remaining modules. This can be seen in the user profiling section [1]

さらに、モジュールのアクセス制御にタグを使用できるため、ユーザを必要のないモジュールにアクセスさせることなく、特定のエージェントのモジュールにのみアクセスさせることができます。 これに関する詳細は、ユーザプロファイリングの章 [2] で説明しています。


When monitoring, we obtain values from a system, be it memory, CPU, chassis temperature, number of connected users, orders on an e-commerce website or any other numerical value. Sometimes we are only interested in the data, but generally we want to associate a STATUS with these values, so that when they overcome a "THRESHOLD", the status changes, to let us know if something is right or wrong. That's why when we talk about monitoring, we have to introduce the concept of STATUS.


Pandora FMS allows you to define thresholds to determine the status that a check will have based on the data it shows. The three possible status are: NORMAL, WARNING and CRITICAL. A threshold is a value from which we move from one status to another. The status of the modules will depend on these thresholds, which are specified by the following parameters present in the configuration of each module:

Pandora FMS は、データに基づき状態を決定するための しきい値 を定義することができます。3つの可能な状態として、正常、警告、障害があります。しきい値は、ある状態が他の状態に移る値です。モジュールの状態は、それぞれのモジュールの設定において次のパラメータによって指定されたしきい値に依存します。

  • Warning status - Min. Max.: lower and upper limits for the warning status. If the numerical value of the module is in this range, the module will go to warning status. If no upper limit is specified, it will be infinite (all values above the lower limit).
  • Warning status - Str.: regular expression for alphanumeric modules (string). If any matches are found, the module will go to warning status.
  • Critical status - Min. Max.: lower and upper limits for the critical status. If the numerical value of the module is in this range, the module will go to critical status. If no upper limit is specified, it will be infinite (all values above the lower limit).
  • Critical status - Str.: regular expression for alphanumeric modules (string). If any matches are found, the module will go to critical status.
  • Inverse interval: present for both the warning and critical threshold. If enabled, the module will change status when its values are outside the range specified in the thresholds. It also works for alphanumeric modules (string), if the text strings do NOT match the Warning/Critical Str., the module will change its status
  • 警告状態 - 最小 最大(Warning status - Min. Max.): 警告状態の下限と上限です。モジュールの値がこの範囲に入ると、モジュールは警告状態になります。上限を設定しない場合は、無限(下限を超えたすべての値が対象)となります。
  • 警告状態 - 文字列(Warning status - Str.): 文字列モジュールに対する正規表現です。マッチするとモジュールは警告状態になります。
  • 障害状態 - 最小 最大(Critical status - Min. Max.): 障害状態の下限と上限です。モジュールの値がこの範囲に入ると、モジュールは障害状態になります。上限を設定しない場合は、無限(下限を超えたすべての値が対象)となります。
  • 障害状態 - 文字列(Critical status - Str.): 文字列モジュールに対する正規表現です。マッチするとモジュールは障害状態になります。
  • 範囲の反転(Inverse interval): 警告と障害のしきい値両方の設定に存在します。有効化すると、モジュールは、値がしきい値に指定した 範囲外 になった場合に状態変化します。文字列モジュールに対しても動作します。文字列が、警告/障害文字列にマッチしなかった場合に状態が変わります。


In case the "warning" and "critical" thresholds match in any range, the "critical" threshold will always prevail.


"警告" と "障害" のしきい値が重なっている場合は、"障害" しきい値が常に優先されます。

数値しきい値 - ケーススタディ 1

We have a CPU usage percentage module that will always be green in agent status, as it simply reports a value between 0% and 100%. If we want the CPU use module to go to into warning status (yellow ) when it reaches 70% of its use, and into critical status (red) when it reaches 90%, we must configure the thresholds as follows:

CPU 使用率モジュールは、エージェントのステータスの中で常に緑色です。これは単に 0% と 100% の間の値を報告するためです。 70% に達したときに CPU 使用率モジュールが警告状態(黄色)になり、90% に達したときに障害状態(赤)になるようにするには、次のようにしきい値を設定する必要があります。

  • Warning status Min.: 70
  • Critical status Min.: 90
  • 警告状態 最小値: 70
  • 障害状態 最小値: 90

Thus, when the value 90 is reached, the module will appear in red (CRITICAL), while between 70 and 89.99 will be yellow (WARNING), and below 70 in green (NORMAL).

値が 90 に達すると、モジュールは赤(障害)、70 とp 89.99 の間は黄色(警告)、70 を下回ると緑(正常)になります。

Due to the operation of the thresholds, in cases such as this, it is not necessary to set the upper limits. This is because if only the lower threshold is set, the upper threshold will be taken into account as "no limit", so any value above the lower limit will be taken into account as within the threshold. In addition, if the thresholds are crossed, the critical threshold will prevail over the warning, resulting in the graph of thresholds shown in the previous screenshot.

閾値の操作で、このような場合は上限を設定する必要はありません。 これは、下限しきい値のみが設定されている場合、上限しきい値は「無限」として考慮されるため、下限を超える任意の値がしきい値範囲内であると考慮されるからです。 さらに、しきい値を超えた場合は、警告よりもクリティカルなしきい値が優先され、前のスクリーンショットに示すしきい値のグラフが表示されます。

文字列しきい値 - ケーススタディ 2

If we have a string type module, we can configure the status using regular expressions in the Str fields of the parameters Warning Status and Critical Status. In this case we have a module that can return :"OK", "ERROR connection fail" or "BUSY too many devices", depending on the result of the query.

文字列 タイプのモジュールの場合、警告状態 および 障害状態文字列(Str)パラメータフィールドに正規表現を使うことにより状態を設定することができます。 ここでは、実行結果として "OK", "ERROR connection fail", "BUSY too many devices" を返すモジュールがあるとします。

To configure the WARNING and CRITICAL states of the text module we will use the following regular expressions:


Warning Status: .*BUSY.*
Crirical Status: .*ERROR.*
警告状態: .*BUSY.*
障害状態: .*ERROR.*

With this configuration, the module will have WARNING status when the data contains the string BUSY, and its status will be CRITICAL when the data contains the string ERROR. "Please, be careful, regular expressions are case sensitive."

この設定により、モジュールは、データに BUSY という文字列が含まれている場合は警告状態、データに ERROR という文字列が含まれている場合は障害状態となります。正規表現は大文字小文字を区別するということに注意してください。

動的監視 (自動しきい値設定)

Dynamic monitoring consists of automatically and dynamically adjusting the status thresholds of the modules in an intelligent and predictive way. The procedure consists of collecting the values for a given period and calculating an average and a standard deviation, which are used to establish the corresponding thresholds.


The configuration is done at module level, and the possible parameters are:


  • Dynamic Threshold Interval: time interval to be considered for the calculation of thresholds. If we choose 1 month, the system will take all existing data from the last month and build the thresholds based on that data.
  • Dynamic Threshold Two Tailed: if activated, the dynamic threshold system will also set thresholds below the average. If unchecked (default) only thresholds with values above the average will be set.
  • Dynamic Threshold Max.: allows you to increase the upper limit by the indicated percentage . E.g.: if the average values are around 60 and the critical threshold has been set from 80 on, if we set the value Dynamic Threshold Max: 10, we will increase this critical threshold by 10%, so it would be 88.
  • Dynamic Threshold Min.: only applies if the Dynamic Threshold Two Tailed parameter is active. Allows the lower limit to be reduced by the percentage indicated. E.g.: if the average values are around 60 and the lower critical threshold has been set to 40, if we set the value Dynamic Threshold Min: 10, we will reduce this critical threshold by 10%, so it would be 36.
  • 動的しきい値の間隔(Dynamic Threshold Interval): しきい値を計算するための時間間隔です。1ヵ月を選択すると、システムは過去 1ヵ月間のデータを使ってしきい値を設定します。
  • 2つの動的しきい値を使う(Dynamic Threshold Two Tailed): 有効化すると、動的しきい値システムは、平均より のしきい値も設定します。無効化(デフォルト)している場合は、平均値の のみのしきい値を設定します。
  • 最大動的しきい値(Dynamic Threshold Max.): パーセンテージの設定で上限を増加させることができます。例えば、平均値が 60前後で障害状態のしきい値が 80のときに、最大動的しきい値を 10 に設定すると、障害状態のしきい値を 10% あげることができます。結果、障害状態しきい値は 88 となります。
  • 最小動的しきい値(Dynamic Threshold Min.): 2つの動的しきい値を使うが有効の場合のみ設定可能です。パーセンテージの設定で下限を下げることができます。例えば、平均値が 60前後で障害状態のしきい値が 40のときに、最小動的しきい値を 10 に設定すると、障害状態のしきい値を 10% 下げることができます。結果、障害状態しきい値は 36 となります。

There are also several additional configuration parameters in the file pandora_server. conf.

また、pandora_server.conf にいくつかの追加の設定パラメータがあります。

  • dynamic_updates: this parameter determines how many times the thresholds are recalculated during the time period set in Dynamic Threshold Interval. If we set "Dynamic Threshold Interval" to a value of 1 week, by default the data is collected from one week backwards and the calculation is done only once, repeating the process again after one week. If we modify the parameter "dynamic_updates", we could increase this frequency. For example, setting the parameter to a value of 3 will cause the thresholds to be recalculated up to three times during the period of a week (or the period that we have set in "Dynamic Threshold Interval"). Its default value is 5.
  • dynamic_warning: percentage of difference between the warning and critical thresholds. Its default value is 25.
  • dynamic_constant: determines the deviation of the average that will be used to establish thresholds, higher values will make thresholds further away from the average values. Its default value is 10.
  • dynamic_updates: このパラメータは、動的しきい値の間隔 で指定した期間に何回しきい値を再計算するかを決定します。動的しきい値の間隔 を 1週間に設定した場合、通常は 1週間前までのデータを集め、1回のみ計算します。1週間後、同じ処理を実施します。"dynamic_updates" パラメータの設定で、この頻度を増やすことができます。例えば、値を 3に設定すると、1週間(動的しきい値の間隔で指定した期間)の中で最大 3回再計算します。デフォルトの値は 5です。
  • dynamic_warning: 警告および障害しきい値の間の差分パーセンテージです。デフォルト値は 25 です。
  • dynamic_constant: しきい値を設定するために使う平均の標準偏差を定義します。値を大きくすると、平均値からしきい値が離れていきます。デフォルト値は 10 です。

In the following example, the calculated average value is at the red line (approx. 30):

以下の例では、計算された平均値は赤線です。(約 30)

When the dynamic thresholds are activated, the upper threshold (approx. 45 and above) is set like this :

動的しきい値が有効化されている場合、上限のしきい値は次のように設定されます。(約 45かそれ以上)

We have activated the parameter Dynamic Threshold Two Tailed, which means a critical threshold has also been set below the average values (approx. 15 and lower):

2つの動的しきい値を使う(Dynamic Threshold Two Tailed) を有効化している場合、障害しきい値は平均値の下にも設定されます。(約 15およびそれ以下)

Now we've set the parameters "Dynamic Threshold Min." and "Dynamic Threshold Max." at 20 and 30 respectively, the thresholds have therefore been opened, them being slightly more permissive:

"最大動的しきい値(Dynamic Threshold Max.)" および "最小動的しきい値(Dynamic Threshold Min.)" を 20 および 30 に設定すると、しきい値の範囲が少しだけ広がります。

ケーススタディ 1

We start from a web latency module. The basic settings we have used take into account a week interval:

Web の応答時間モジュールを例にとります。しきい値の計算期間は 1週間です。

When saving changes, after running pandora_db, the thresholds have been set in this way:

設定を保存し、pandora_db が実行後されると、しきい値は次のように設定されます。

The module will therefore switch to warning status when the alteration is greater than 0.33 seconds, and to critical when it is greater than 0.37 seconds. The graph will be shown as follows:

このとき、モジュールは、応答時間が 0.33秒より大きい場合には「警告」ステータスに、0.37秒より大きい場合には「障害」に切り替わります。 グラフは次のようになります。

The threshold has been considered to be somewhat permissive, so we decide to make use of the parameter Dynamic Threshold Min. to lower the minimum thresholds. Since in this case the threshold has no maximum values because everything above a certain value will be considered incorrect, we will not use Dynamic Threshold Max. The modification made would be like this:

ここでは、しきい値はやや高いと考えられるため、パラメータ 最小動的しきい値 を使用して最小のしきい値を下げることにしました。 この場合、ある値を超えるものはすべて対象となり、しきい値は最大値を持たないため、 最大動的しきい値 は使用しません。変更は次のようになります。

After applying changes and executing the pandora_db, the thresholds are set as follows:

変更を行ったあと pandora_db が実行されると、しきい値の設定は次のようになります。

And the graph will look like this:


ケーススタディ 2

In this example we are monitoring the temperature of a control room or a CPD, the graph shown, presents some values with little variation:

この例では、制御室または CPD の温度を監視しています。グラフは、わずかなばらつきのある値を示しています。

In this situation it is essential that the temperature remains stable and does not reach much higher values, neither much lower, so we will use the parameter "Dynamic Threshold Two Tailed" to delimit thresholds both above and below. The configuration is as follows:

このような状況では、温度は安定した状態で、極端に高い値や極端に低い値になることはあまりありません。そのため、パラメータ 2つの動的しきい値を使う を設定して、上下両方のしきい値を調整します。 設定は次のとおりです。

The automatically generated thresholds have been these:


And the graph will look like this:


In this way, all values between 23'10 and 26 will be considered normal, since it is the acceptable temperature in our CPD or control room. If we need to, we could use the parameters "Dynamic Threshold Min." and "Dynamic Threshold Max." again to adjust the thresholds if necessary.

この場合、23.10 と 26 の間の値は常に正常とみなされます。これが制御室で許容される温度です。必要に応じて "最小動的しきい値" および "最大動的しきい値" でしきい値を調整することができます。