Pandora FMS の技術情報

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

Pandora FMS early versions, from 0.83 to 1.1, were based on a very simple idea: one data, one database insertion. This allowed the software to perform easy searches, insertions and other operations quickly.

0.83 から 1.1 までの Pandora FMS 初期バージョンでは、データベースに一つのデータに対して一つの挿入を行うという、とてもシンプルな考えに基づいていました。この方法は、開発がとても簡単で、簡単な検索や挿入などの操作をプログラムしやすくなっていました。

Apart from all the advantages of this development, there was a drawback: scalability (rapid growth without affecting or with little effect on operations and work routines). This system had a defined limit in the maximum number of modules it could support, and with a certain amount of data (more than 5 million elements), performance was affected.

これは、多くの利点がありましたが、スケーラビリティに関しては大きな問題をもっていました。このシステムでは、サポートできるモジュールの最大数にある上限があり、一定数のデータで負荷が増大しクラスタリングの仕組みを実装しにくく、(5万を超える項目では) 処理も早くはありませんでした。

MySQL cluster-based solutions, on the other hand, are difficult: although they allow you to handle a larger load, they add some extra problems and difficulties, and also do not offer a long-term solution to the performance problem with large amounts of data.

MySQL クラスタをベースにしたソリューションは簡単ではなく、常に何らかの問題が発生していました。そして改善に長時間を要しました。

Currently, Pandora FMS implements a data compaction in real time for each insertion, besides performing a data compression based on interpolation. On the other hand, the maintenance task allows to automatically delete data that exceeds a certain age.

現在のバージョンの Pandora FMS では、データの挿入におけるリアルタイムでのデータ圧縮を実装しています。それは、収集間隔に基づいたデータ圧縮を行います。また、メンテナンスタスクにて特定の日付のデータを自動的に削除するような実装も行っています。

The Pandora FMS processing system stores only “new” data: if a duplicate value enters the system, it will not be stored in the database. This is very useful to keep the database reduced, and it works for all Pandora FMS module types (numeric, incremental, boolean and text string).

新たなデータ処理システムは、新しいデータのみを保持します。同じ値がシステムに入力された場合、それはデータベースに保存されません。これはデータベースを小さい状態に維持するのにとても便利です。これは、数値、インクリメンタルな数値、ブーリアン等のすべての Pandora FMS モジュールで動作します。

These modifications involve big changes when reading and interpreting data. In the latest versions of Pandora FMS, the graphic engine has been redesigned from scratch to be able to represent the data quickly with the new data storage model.

これらの変更により、データの読み取りと解釈に大きな変化が生じます。Pandora FMS の最新バージョンでは、新しいデータストレージモデルでデータをすばやく表示できるように、グラフィックエンジンが最初から再設計しました。

The compaction mechanisms also have certain implications when reading and interpreting the data graphically: Currently there is a graphical configuration menu which allows adding percentiles, real-time data, when events and/or alerts occurred, in addition to other options.

圧縮メカニズム は、データをグラフィカルに読み取って解釈するときにも 特定の影響 を及ぼします。現在、パーセンタイル、リアルタイムデータ、イベントやアラートが発生した日時、その他のオプションを追加できるグラフ設定メニューがあります。

Additionally, Pandora FMS allows the total disaggregation of components, so that the load of data file processing and execution of network modules in different servers can be balanced.

さらに、Pandora FMS ではコンポーネントを完全に分離できるため、異なるサーバーのデータ ファイル処理とネットワーク モジュールの実行の負荷を分散できます。

Throughout the software updates, improvements have been implemented in the relational model of the Pandora FMS database. One of the changes introduced has been indexing the information based on different types of modules. This way, Pandora FMS can access much faster to the information, because it is distributed in different tables.

ソフトウェアアップデートを通じて、Pandora FMS データベースのリレーショナルモデルに改善が実装されました。導入された変更の 1 つは、異なるタイプのモジュール に基づいて 情報をインデックス化 することです。これにより、情報が異なるテーブルに分散されるため、Pandora FMS は情報に非常に速くアクセスできます。

It is possible to partition the tables (by timestamps) to further improve the performance of access to historical data.

テーブルを（タイムスタンプ別に）パーティション分割して、履歴データへのアクセスのパフォーマンスをさらに向上させることが可能です。

In addition, factors such as the numerical representation of timestamps (_timestamp_ UNIX format), speed up searches for date ranges, date comparisons, etcetera. This work has led to a considerable improvement in search times and insertions.

さらに、タイムスタンプの数値表現 (UNIX 形式 _timestamp_ ) などの要素により、日付範囲の検索、日付の比較などが高速化されます。この作業により、検索時間と挿入が大幅に改善されました。

To avoid overloading the database, the server performs a simple insertion time compression. A piece of data is not stored in the database unless it is different from the previous one or there is a difference of more than 24 hours between the two.

データベースの高負荷を避けるために、データ挿入時にサーバは簡単な圧縮を行います。データが一つ前のデータと同じ場合や、24時間以内に変化が内場合は、データベースに保存されません。

For example, assuming an approximate 1 hour interval, the sequence 0,1,0,0,0,0,0,0,0,0,0,1,1,0,0,0 is stored in the database as 0,1,0,1,1,0. Another consecutive 0 will not be stored unless 24 hours have passed.

例えば、だいたい 1時間の間隔で 0,1,0,0,0,0,0,0,0,0,0,1,1,0,0,0 というデータがあった場合、データベースには、0,1,0,1,1,0 と記録されます。24時間経過しないと、連続した 0 は記録されません。

赤で示したデータのみがデータベースに保存されます。

Compression greatly affects data processing algorithms, both metrics and graphs, and it is important to keep in mind that the “gaps” caused by compression need to be filled.

圧縮は、データ処理のアルゴリズムに影響を与えます。グラフ描画では、圧縮により発生した空白のデータを埋める必要があるということを認識することが重要です。

Taking into account all the above, to perform calculations with the data of a module given an interval and an initial date, the following steps must be followed:

以上を理解して、あるモジュールの実行間隔と最初のデータを使って、そのモジュールのデータを求めるためには、次のような手順を踏む必要があります。

• Search for the previous data, out of the given interval and date. If it exists, bring it to the beginning of the interval. If it did not exist previously, there would be no data.
• Search for the next data, out of the given interval and date up to a maximum equal to the module interval. If it exists, bring it to the end of the interval. If it does not exist, the last available value should be extended to the end of the interval.
• All data is traversed, taking into account that a data is valid until a different data is received.

• 指定した間隔や日時よりも古いデータを検索します。見つかった場合は、それが現在の値になった最初のデータです。見つからなかった場合は、過去にデータは存在しません。
• モジュールの実行タイミングと同じ日時まで、指定した間隔や日時よりも新しいデータを検索します。見つかった場合は、それが値が変化したタイミングのデータとなります。もし、見つからなかった場合は、最後に記録された値が現時点まで続いていることになります。
• あるデータを特定するためには、それが可能となる他のデータを全て確認する必要があります。

Pandora FMS has included a system for compacting the database information. This system is oriented to small and medium size scenarios (from 250 to 500 agents and with less than 100,000 modules) that want to have an extensive information history but losing details.

Pandora FMS は、データベースに保存する情報を削減するシステムを持っています。これは中小規模のシステム(250-500エージェント、100,000未満のモジュール数)で、精度を落として長期間のデータ保存を想定したものです。

The maintenance of the Pandora FMS database that is executed every hour, and among other cleaning tasks allows to perform a compaction of old data. This compaction uses a simple and linear interpolation, as it is an interpolation, this makes that detail is lost in this information, but it will still be informative enough for the generation of reports and monthly, annual graphs, et cetera.

1 時間ごとに実行される Pandora FMS データベースのメンテナンスでは、他のクリーニングタスクとともに、古いデータの圧縮を実行できます。この圧縮は、補間 であり、単純な線形補間が使用されます。このため、この情報の詳細は失われますが、レポートや月次、年次グラフなどを生成するには十分な情報となります。

In large databases, this behavior can be quite costly in terms of performance and would have to be disabled; instead, it is recommended to opt for the historical database model.

大規模なデータベースでは、この動作はパフォーマンスの面で非常にコストがかかる可能性があるため、無効にする必要があります。代わりに、ヒストリデータベース モデルを選択することをお勧めします。

The historical database is a feature used to store all the past information, which is not used in recent day views, such as data older than one month. This data is automatically migrated to a different database, which must be on a different server with a different storage (disk) than the main database.

ヒストリデータベース は、1 か月以上前のデータなど、最近の表示では使用されない過去のすべての情報を保存するために使用される機能です。このデータは、メインデータベースとは異なるストレージ (ディスク) を持つ 別のサーバ上にある必要があります 別のデータベースに自動的に移行されます。

When a graph or a report with old data is displayed, Pandora FMS will search the first days in the main database, and when it reaches the point where it migrates to the historical database, it will search in it. Thanks to this, the performance is maximized even when accumulating a large amount of information in the system.

古いデータを含むグラフやレポートを表示する場合、Pandora FMS は最初の数日間はメインデータベースを検索し、ヒストリデータベースを参照する必要がある時点に達するとヒストリデータベースを検索します。これにより、システムに大量の情報が蓄積されている場合でも、パフォーマンスが最大化されます。

The Pandora FMS default configuration does not transfer string text string type data to the history database, however if this configuration has been modified and the history database is receiving this type of information it is essential to configure its purging, otherwise it will end up occupying too much, causing big problems and obtaining a negative impact in the performance.

Pandora FMS のデフォルト設定では、文字列 テキスト文字列タイプのデータはヒストリデータベースに転送されませんが、この設定が変更され、ヒストリデータベースがこのタイプの情報を受信して​​いる場合は、消去を設定することが不可欠です。そうしないと、占有量が大きくなり、大きな問題が発生し、パフォーマンスに悪影響が及ぶことになります。

To configure this parameter, a query must be executed directly in the database to determine the days after which this information will be purged. The table in question is tconfig and the field string_purge. To set 30 days for the purge of this type of information, the following query would be executed directly on the history database:

このパラメータを設定するには、データベース内で直接クエリを実行して、この情報が消去される日数を決定する必要があります。問題のテーブルは tconfig とフィールド string_purge です。このタイプの情報の消去を 30 日間に設定するには、次のクエリを履歴データベース内で直接実行します。

UPDATE tconfig SET VALUE = 30 WHERE token = "string_purge";

The database is maintained by a script called pandora_db.pl, to check that the database maintenance is executed correctly the maintenance script is executed manually:

データベースは pandora_db.pl というスクリプトによってメンテナンスされます。データベースのメンテナンスが正しく実行されているかどうかを確認するために、メンテナンス スクリプトを手動で実行します。

/usr/share/pandora_server/util/pandora_db.pl /etc/pandora/pandora_server.conf

It should not report any errors. If any other instance is using the database, you may use option -f that forces execution ; with parameter -p it does not compact data. This is particularly useful in High Availability (HA) environments with history database, since the script makes sure to properly and orderly perform the necessary steps for said components.

エラーは報告されません。別のインスタンスがデータベースを使用している場合は、実行を強制する -f オプションを使用することもできます。 -p パラメーターを使用すると、データは圧縮されません。これは、スクリプトがコンポーネントに対して必要な手順を正しい順序と方法で確実に実行するため、ヒストリデータベースを備えた HA 環境で特に役立ちます。

• On the one hand, each module has WARNING and CRITICAL thresholds in its configuration.
  • These thresholds define the values of your data for which these statuses will be activated.
  • If the module provides data outside these thresholds, it is considered to be in NORMAL status.

• Each module has, in addition, a time interval that will establish the frequency with which it will obtain the data.
  • This interval will be taken into account by the console to collect the data.
  • If the module has not collected data for twice its interval, the module is considered to be in UNKNOWN status.

• Finally, if the module has alerts configured and any of them has been triggered and has not been validated, the module will have the corresponding status of Alert triggered.

• それぞれのモジュールには、警告 や 障害 状態のしきい値の設定があります。
  • これらのしきい値は、データの値によっていそれぞれの状態になるということを定義します。
  • モジュールのデータがこれらのしきい値の範囲から外れれば、正常状態と認識されます。
• それぞれのモジュールには、データを収集する間隔の設定もあります。
  • データ収集の間隔はコンソールで確認されます。
  • もし、モジュールが収集間隔の 2倍の期間データを収集できなかった場合、そのモジュールは不明状態となります。
• 最後に、モジュールにアラート設定があり、アラートが発生し承諾されていなければ、モジュールはアラート発生状態となります。

Within the Pandora FMS organization, certain elements depend on others, as is the case of the modules of an agent or the agents of a group. This can also be applied to the case of Pandora FMS policies, which have associated certain agents and certain modules that are considered associated to each agent.

Pandora の仕組においては、いくつかの要素は他に依存しています。たとえば、一つのエージェントにおけるモジュールや、一つのグループにおけるエージェントです。これらはまた、Pandora FMS ポリシーに適用することができます。ポリシーは、個々のエージェントに割り当てられたもののように、いくつかのエージェントおよびモジュールを関連付けることができます。

Such a structure is especially useful for evaluating module statuses at a glance. This is achieved by propagating upwards in this organization the statuses, thus giving status to agents, groups and policies.

この構造は、モジュールの状態を簡単に評価するには特に便利です。これにより、エージェント、グループ、およびポリシーの状態を仕組の中で伝播していくことができます。

An agent will be shown with the most critical status of the statuses of its modules. In turn, a group will have the most critical status of the statuses of the agents that belong to it, and the same for the policies, which will have the most critical status status of their assigned agents.

エージェントの状態は、モジュールの状態の中で最も悪い状態を採用します。グループの状態は、それに属するエージェントの中で最も悪い状態を採用します。そして、ポリシーの状態も同様で、割り当てられたエージェントの最も悪い状態を採用します。

Thus, when you see a group with a critical status, for example, you will know that at least one of its agents has the same status. To locate it, you will have to go down another level, to the agents' level, to narrow the circle and find the module or modules causing the propagation of this critical status.

これにより、たとえば、障害状態の一つのグループを見ることによって、そこに属する少なくとも一つのエージェントがそれと同じ状態であることがわかります。それを特定したら、上位レベルへ障害状態を伝播させる原因となったモジュールへと、細かいレベルへの情報へ掘り下げていくことができます。

As the most critical status of the statuses is propagated, it must be clear which statuses take priority over the others:

状態のうち 最も重要な状態 が伝播されるため、どの状態が他の状態よりも優先されるかが明確である必要があります。

1. Alerts triggered.
2. Critical condition.
3. Warning status.
4. Status unknown.
5. Normal condition.

1. アラート発生
2. 障害状態
3. 警告状態
4. 不明状態
5. 正常状態

When a module has triggered alerts, its status has priority over all the others and the agent to which it belongs will have that status and the group to which that agent belongs, in turn, will also have that status.

アラートが発生した場合、その状態は他よりも優先順位が高く、エージェントもこの状態となり、またこのエージェントが属するグループもこの状態となります。

On the other hand, for a group, for example, to have normal status, all its agents must have such status; which means that all the modules of such groups will have normal status.

言い換えると、例えば一つのグループが正常状態であれば、そのグループの全エージェントは正常状態であり、全てのモジュールが正常状態であるといえます。

Status of triggered alerts.

Critical Condition.

Warning Status.

Condition Unknown.

Normal condition.

アラート発生

障害状態

警告状態

不明状態

正常状態

Graphs are one of the most complex implementations of Pandora FMS, they extract data in real time from the database and no external system (RRDtool or similar) is used.

グラフは、Pandora FMS の実装において最も複雑なもののひとつです。なぜなら、DB からリアルタイムで情報を収集していて(rrdtool などの)外部のツールは利用していないためです。

There are several behaviors of the graphs depending on the type of source data:

グラフにはいくつかの動きがあり、それはデータのタイプに依存します。

• Asynchronous modules. It is assumed that there is no data compaction. The data in the database are all real samples of the data, there is no compaction. Produces much more “accurate” graphs with no possibility of misinterpretation.
• String type modules. They show graphs with the data rate over time.
• Numerical data modules. Most modules report this type of data.
• Boolean data modules. Correspond to numerical data on monitors, PROC: e.g. Ping checks, interface status, etc. The value 0 corresponds to the Critical status, and the value 1 to the “Normal” status.

• 非同期モジュール. データ圧縮が無いことを想定します。DB に保存されているデータは、すべて実際に収集されたデータです(圧縮がないため)。 抜けなく正確なグラフが生成されます。
• 文字列モジュール. 取集したデータのレートを表示します。
• 数値モジュール. ほとんどのモジュールはそのデータを表示します。
• Boolean モジュール. ping のチェックやインタフェースの状態などの *PROC モジュールでは、数値データになります。0 は、障害を、1 は正常を意味します。

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

以下に、ER図および、Pandora FMS データベースの主なテーブルの詳細説明を示します。残りのテーブルについても簡単に説明しています。

• taddress: エージェントの追加アドレス。
• taddress_agent: エージェントのアドレス。(taddress/tagente に関連)
• tagente: Pandora FMS エージェントの情報。
  • id_agente: エージェントのユニーク ID。
  • nombre: エージェント名。(大文字・小文字を区別します)
  • direccion: エージェントアドレス。traddress を通して、追加アドレスを割り当てることができます。
  • comments: フリーテキスト。
  • id_grupo: エージェントが所属するグループ ID。(tgrupo に関連)
  • ultimo_contacto: ソフトウエアエージェントもしくは、リモートモジュールでの、エージェント接続の最終日時。
  • modo:エージェントの動作モード。0 は通常モード、1 は学習モードです。
  • intervalo: エージェント実行間隔。この間隔に応じて、エージェントはタイムアウトを表示します。
  • id_os: エージェントの OS ID。(tconfig_os に関連)
  • os_version: OS バージョン。(フリーテキスト)
  • agent_version: エージェントバージョン。(フリーテキスト) ソフトウエアエージェントによって更新されます。
  • `ultimo_contacto_remoto: エージェントが接続してきた最終日時。ソフトウエアエージェントの場合、日時はエージェントから送信されます。
  • disabled: エージェントの状態。無効状態であれば 0、有効であれば 1 です。
  • remote: エージェントのリモート設定の状態です。有効であれば 1 です。
  • id_parent: 親エージェントの ID。(tagente に関連)
  • custom_id: エージェントのカスタマイズ ID。他のツールとの連携に便利です。
  • server_name: エージェントに割り当てられたサーバ名。
  • cascade_protection: 関連障害検知抑制。0 で無効です。1 の場合は、親エージェントで障害が発生した場合に、該当エージェントでの障害発生を抑制します。詳細は、 アラートシステムを確認してください。
  • safe_mode_module: セーフオペレーションモードの(同一エージェントの)モジュール ID。(モジュールが障害状態の場合、他のすべてのモジュールは無効化されます)
• tagente_datos: モジュールから受信したデータ。同一のモジュールが最後に受信したデータと同じ値の場合は記録されません。(ただし、tagente_estado は更新されます。) インクリメンタルデータおよび、文字列タイプのデータは、別のテーブルに保持されます。
• tagente_datos_inc: インクリメンタルデータタイプ。
• tagente_datos_string: 文字列データ。
• tagente_estado: それぞれのモジュールの現在の状態。
  • id_agente_estado: ID。
  • id_agente_modulo: モジュール ID。(tagente_modulo に関連)
  • datos: 最新の受信データの値。
  • timestamp: (エージェントからの)最新のデータを受け取った日時。
  • estado: モジュールの状態で、0 正常、1 障害、2 警告、3 不明 です。
  • id_agent: モジュールに関連づけられたエージェント ID。(tagente に関連)
  • last_try: 最後に実行に成功したモジュールの日時。
  • utimestamp:UNIX フォーマットでの最後に実行したモジュールの日時。
  • current_interval:モジュールの実行間隔を秒で示します。
  • running_by: モジュールを実行するサーバ名。
  • last_execution_try: 実行が失敗している場合でも、最後にモジュールの実行を試みた日時を示します。
  • status_changes: 状態の変化が発生した回数。継続的な状態変化を避けるために利用されます。
  • last_status: モジュールの一つ前の状態。
• tagente_modulo: モジュールの設定。
  • id_agente_modulo: モジュールの ID。
  • id_agente: モジュールに関連付けられたエージェント ID。(tagente に関連)
  • id_tipo_modulo: モジュールの種類。(ttipo_modulo に関連)
  • descripcion: フリーテキスト。
  • nombre: モジュール名
  • max: モジュールの最大値。これより大きな値は、不正な値として認識されます。
  • min: モジュールの最小値。これより小さな値は、不正な値として認識されます。
  • module_interval: 秒単位のモジュール実行間隔。
  • tcp_port: ネットワークモジュールおよびプラグインの接続先 TCP ポート。WMI モジュールでは、読み込むカラム名。
  • tcp_send:ネットワークモジュールでの送信データ。WMI モジュールでは、ネームスペース。
  • tcp_rcv: ネットワークモジュールでの想定する受信データ。
  • snmp_community:ネットワークモジュールでの SNMP コミュニティ。WMI モジュールでのフィルタ。
  • snmp_oid: ネットワークモジュールでの OID。WMI モジュールでの WQL クエリ。
  • ip_target: ネットワーク、プラグイン、および WMI モジュールでの対象アドレス。
  • id_module_group:モジュールが所属するグループの ID。(tmodule_group に関連)
  • flag: 強制実行フラグ。1 に設定されている場合、実行間隔に関係なく実行されます。
  • id_modulo: id_tipo_módulo では見分けることができないモジュール ID。6 が WMI モジュール、7 が、WEB モジュール。
  • disabled: モジュールの状態。0 が有効、1 が無効。
  • id_export: モジュールに関連づけられた、エクスポートサーバの ID。(tserver に関連)
  • plugin_user: プラグインおよび WMI モジュールのユーザ名。Web モジュールのユーザエージェント。
  • plugin_pass: プラグインおよび WMI モジュールのパスワード。Web モジュールの試行回指数。
  • plugin_parameter: プラグインモジュールの追加パラメータ。Web モジュールの Goliat タスク設定。
  • id_plugin: プラグインモジュールのモジュールに関連付けられた、プラグインの ID。(tpluginに関連)
  • post_process: モジュールデータの値に対して、保存前にかける倍率。
  • prediction_module: 1 であれば予測モジュール。0 であればそれ以外。
  • max_timeout: プラグインモジュールでの、秒単位の最大タイムアウト値。
  • custom_id: モジュールのカスタム ID。他のツールとの連携に便利です。
  • history_data: 0 の場合、モジュールのデータは tagente_datos に保存されません。tagente_estado のみ更新されます。
  • min_warning: 警告状態になる最小値。
  • max_warning: 警告状態になる最大値。
  • min_critical: 障害状態になる最小値。
  • max_critical: 障害状態になる最大値。
  • min_ff_event: 何回まで状態変化を許容するかのデータを保持します。これは、tagente_estado.status_changes に関連しています。
  • delete_pending: 1 に設定されると、データベースのメンテナンススクリプト pandora_db.pl のメンテナンスによって削除されます。
  • custom_integer_1: prediction_modue = 1 の場合、このフィールドは予測に使うモジュール ID。prediction_module = 2 の場合は、このフィールドはモジュールに割り当てられたサーバ ID。
  • custom_integer_2:
  • custom_string_1:
  • custom_string_2:
  • custom_string_3:
• tagent_access: いずれかのサーバにエージェントからデータを受信するたびに新たな時間が追加されます。ただし、データベースの高負荷を避けるために、1分より細かい時間は記録されません。pandora_server.conf ファイルで、agentaccess を 0 にすると無効になります。
• talert_snmp: SNMP アラートの設定です。
• talert_commands: エージェントに関連づけられたアクションから実行されるコマンド。(send mail など) * talert_actions: アラートに関連づけられたコマンド。(administrator へのメール送信など)

• talert_templates: アラートテンプレート。
  • id: テンプレート ID。
  • name: テンプレート名。
  • description: 説明。
  • id_alert_action: テンプレートに関連づけられたデフォルトアクション ID。
  • field1: カスタマイズフィールド 1 (フリーテキスト)
  • field2: カスタマイズフィールド 2 (フリーテキスト)
  • field3: カスタマイズフィールド 3 (フリーテキスト)
  • type: アラートの状態別の種類。('regex', 'max_min', 'max', 'min', 'equal', 'not_equal', 'warning', 'critical')
  • value: regex の場合のアラートの値。(フリーテキスト)
  • matches_value: 1 にすると、状態を反転させます。
  • max_value: max_min および最大アラートの最大値。
  • min_value: max_min および最小アラー他の最小値。
  • time_threshold: アラーとの間隔。
  • max_alerts: 一間隔中における、アラート実行最大回数。
  • min_alerts: アラートが実行される一間隔中における、状態表示最小回数。
  • time_from: アラートが有効になる開始時間。
  • time_to: アラートが有効になる終了時間。
  • monday: 1 の場合、アラートが月曜に有効になります。
  • tuesday: 1 の場合、アラートが火曜に有効になります。
  • wednesday: 1 の場合、アラートが水曜に有効になります。
  • thursday: 1 の場合、アラートが木曜に有効になります。
  • friday: 1 の場合、アラートが金曜に有効になります。
  • saturday: 1 の場合、アラートが土曜に有効になります。
  • sunday: 1 の場合、アラートが日曜に有効になります。
  • recovery_notify: 1 の場合、復旧通知が有効になります。
  • field2_recovery: 復旧通知のカスタムフィールド 2。(フリーテキスト)
  • field3_recovery: 復旧通知のカスタムフィールド 3。(フリーテキスト)
  • priority: アラートの重要度。0 メンテナンス、1 情報、2 正常、3 警告、4 障害
  • id_group: テンプレートが属するグループ ID。 (tgrupo に関連)
• talert_template_modules: モジュールに関連付けられたアラートテンプレートのインスタンス。
  • id: アラートのユニーク ID。
  • id_agent_module: アラートに関連付けられたモジュールの ID。(tagente_modulo に関連)
  • id_alert_template: アラートに関連付けられたテンプレートの ID。(talert_templates に関連)
  • internal_counter: アラート通知状態の発生回数。
  • last_fired: アラートを通知した最後の時間。(Unix time)
  • last_reference: 現在の間隔の開始時間。(Unix time)
  • times_fired: アラートが通知された回数。(internal_counter とは異なります)
  • disabled: 1 の場合、アラートは無効です。
  • priority: アラートの重要度。0 メンテナンス、1 情報、2 正常、3 警告、4 障害
  • force_execution: 1 の場合、アラートが発生していなくてもアラートのアクションが実行されます。アラートの手動実行に便利です。
• talert_template_module_actions: 一つのアラートに関連付けられたアクションのインスタンス。(talert_template_modules に関連)
• talert_compound: 関連付けアラートです。カラムは、talert_templates に似ています。
• talert_compound_elements: 関連付けアラートに関連付けられた、それぞれのロジックを持った単一アラートです。(talert_template_modules に関連)
• talert_compound_actions: 関連付けアラートに関連付けられたアクションです。(talert_compound に関連)
• tattachment: 一つのインシデントに関連付けられた添付です。
• tconfig: コンソールの設定。
• tconfig_os: Pandora FMS が扱う OS です。
• tevent: イベントエントリー。重要度の値はアラートと同じです。
• tgrup: Pandora FMS に定義されているグループ。
• tincidence: インシデントエントリー。
• tlanguage: Pandora FMS で扱える言語。
• tlink: コンソールの下の方のメニューに表示されるリンク。
• tnetwork_component: ネットワークコンポーネント。自動検出サーバで使われるネットワークプロファイルに関連付けられたモジュールです。tagente_module にエントリーが保存されると、双方のテーブルは似た状態になります。
• tnetwork_component_group: ネットワークコンポーネントを分類するグループ。
• tnetwork_profile: ネットワークプロファイル。自動検出サーバの検出タスクに関連付けられるネットワークコンポーネントグループです。プロファイルに関連付けられるネットワークコンポーネントは、作成されたエージェントにモジュールを定義します。
• tnetwork_profile_component: ネットワークプロファイルに関連付けられているネットワークコンポーネント。(tnetwork_component/tnetwork_profile に関連)
• tnote: インシデントに関連づけられたメモ。
• tsource: インシデントの発生元リスト。
• tprofile: コンソールで定義されたユーザプロファイル。
• trecon_task: 自動検出サーバの自動検出タスク。
• tserver: 登録されているサーバ。
• tsession: ユーザの操作記録。
• ttype_modulo: 取得元およびデータの種類に応じた、モジュールの種類。
• ttrap: SNMP コンソールで受信したトラップ。
• tusuario: コンソールで登録されているユーザ。
• tusuario_perfil: ユーザに関連付けられたプロファイル (tusuario/tperfil に関連)
• tnews: コンソールに表示されるニュース。
• tgraph: コンソールで作成されたカスタムグラフ。
• tgraph_source: グラフに関連付けられたモジュール。(tgraph/tagente_modulo に関連)
• treport: コンソールで作成されたカスタムレポート。
• treport_content: 一つのレポートに関連付けられた要素。
• treport_content_sla_combined: 一つのレポートに関連付けられた SLA のコンポーネント。
• tlayout: コンソールで作成されたカスタムマップ。
• tlayout_data: マップに関連付けられた要素。
• tplugin: プラグインサーバのためのプラグイン定義。
• tmodule: モジュールの種類。(ネットワーク、プラグイン、WMI…).
• tserver_export: エクスポートサーバの宛先設定。
• tserver_export_data: 宛先に関連付けられた、エクスポートするデータ。
• tplanned_downtime: 計画停止。
• tplanned_downtime_agents: 計画停止に関連付けられたエージェント。(tplanned_downtime/tagente に関連)

圧縮は、グラフがどう表示されるかに影響します。同じ値の 2つのデータを受信した場合、Pandora は新しい方のデータは保存しません。しかし、他の値が存在しない場合は、最後の値をその時間のデータとして使います。グラフを描画するとき、グラフの開始時点で参照する値がない場合は、Pandora はリファレンスとして参照できる値を 48時間までさかのぼって検索します。何もみつからない場合は、0 で開始します。

非同期モジュールでは、圧縮はされていませんが、同じようにさかのぼって検索する動作を行います。

グラフを構成するとき、Pandora は 50xN サンプルを利用します。N はグラフの解像度(この値は設定で定義できます)です。データを 300秒(5分)間隔で収集している場合、1時間に 12のデータがあり、1日では 12×24 = 288 のデータがあります。1日のグラフを表示する場合、288個の値を表示するわけではありません。圧縮や補間をして、50×3 = 150 のデータを利用します(デフォルトでは、Pandora のグラフ解像度は 3 です)。

これは、精度といくつかのデータを失うことを意味します。そして、保持しているサンプルが多ければ多いほど、より多く失うことになります。 しかし、これは、異なる間隔または拡大率でグラフィックを作成することにより回避できます。

通常のグラフでは、補間は簡単な方法で実装されています。間隔内に 2つのデータがある場合(例のB)は、平均をとってそれを表示します。

boolean グラフでは、複数データ(1または0のみ)がある場合、悲観的なアプローチをとり 0を表示します。これにより、間隔内の障害状態をわかりやすくし、正常状態よりも障害状態の表示を優先します。

両方の場合において、データが存在しない場合(圧縮されているか取得できていない場合)は、その前のタイミングでの最新の収集データを表示に利用します。上記の例の E の ような場合です。

デフォルトでグラフは、平均、最大および最小値を表示します。サンプル（“補間”を参照）は複数のデータを持つことができるので、データの最大値や最小値の平均値を示しています。長い期間の多くのデータを表示する場合はより多くの補間が必要です。しかし、補間レベルが高くなると、最大と最小の値の差は大きくなります。短い範囲(1時間など)のグラフでは、補間は無いか最小限になります。そのため、実際の解像度で見ることができます。そして、3つの値が同じになります。