個人用ツール

Pandora:Documentation ja:Anexo Ingeniería de Pandora FMS

提供: Pandora FMS Wiki JP

移動先: 案内, 検索

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

Pandora FMS の技術詳細

In this annex we are going to explain some of the design principles and particularities of Pandora FMS. It is only an introduction, since some technical aspects, such as the Pandora FMS Database schema would require much more explanation.

この補足資料では、いくつかの Pandora FMS の特別な機能および設計について説明します。Pandora FMS データベーススキーマなどのいくつかの技術的情報に対しては多くの説明が必要であり、ここに記載している内容はあくまでも概要です。

Pandora FMS のデータベース設計

Pandora FMS first versions, from the 0.83 to the 1.1, were based in a very simple idea: one data, one insertion in the database. This was very easy to develop and allowed the program to do very simple searches, insertions and other operations.

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

These had a lot of advantages and a big problem: scalability. This system has an specific limit in maximum number of modules that could support, not having to implement difficult mechanisms of clustering that would allow more load, and even with this, with certain number of data,the functioning was not so quick (> 5 millions of elements).

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

The solutions based in MySQL cluster are not easy, and always add some minor problems.Neither they offer even a long term solution.

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

The current version of Pandora FMS implements a data compression in real time for each insertion. It also allows data compression based on interpolation. It also implements -as in previous versions- an automatic deletion of data after a certain period of time.

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

The new data processing system keeps only «new» data. If a duplicated value enter in the system, it will not be kept in the database.It is very useful to keep the database reduced. This works for all Pandora FMS modules:numeric, incremental, boolean,and chain. In the boolean data kind, the compressing index is very high, so they are data that rarely change.Nevertheless, the «index» elements are kept every 24 hours, so there is minimum information that is useful as a reference when compacting the information.

新たなデータ処理システムは、新しいデータのみを保持します。同じ値がシステムに入力された場合、それはデータベースに保存されません。これはデータベースを小さい状態に維持するのにとても便利です。これは、数値、インクリメンタルな数値、ブーリアン等のすべての Pandora FMS モジュールで動作します。ブーリアンデータでは、データの変化はまれであるため、とても高圧縮になります。それでもインデックスデータは、24時間ごとに保存されます。情報の圧縮により、参照するのに便利な最小限のデータとなります。

This solves part of the scalability problem reducing the database usage in a 40%-70%. There is also another solution for scalability problems: the total breaking up of components in Pandora FMS, that allows to balance the data files processing load and the network modules execution in different servers. Now it it possible to have several Pandora FMS servers(network servers, data or SNMP), like Pandora FMS Web consoles, and also a database or a high performance cluster (with MySQL5).

これは、データ量が 40%〜70% となり、スケーラビリティの問題を解決します。また、スケーラビリティの問題を解決するための Pandora FMS コンポーネントを分割するという別の解もあります。これは、データファイル処理の負荷を分散させたり、ネットワークモジュールを異なるサーバで実行できるというものです。現在、Pandora FMS ウェブコンソールのように、複数の Pandora FMS サーバ (ネットワークサーバ、データサーバや、SNMP サーバ) を持つことができ、また、データベースも (MySQL5 で) クラスタを組むことができます。

The adjustments imply big changes when reading or interpreting data. We have redesign and implement from zero the graphic motor to could represent data in a quick way with the new data storage model. With the new version, if an agent could not communicate with Pandora FMS, and the Pandora FMS server does not receive data from the agent, then this absence of data could not have a graphic representation. And regarding the module graph, it will be no changes.

データの読み込みや処理の調整は大きな変化を意味します。我々は、新たなデータ保存モデルにおいて、すばやくデータを表示できるように、ゼロからグラフィックエンジンを設計、実装し直しました。新しいバージョンでは、エージェントが Pandora FMS と通信できず、Pandora FMS サーバがエージェントからデータを受け取れない場合、この欠落したデータはグラフに表示されません。そして、モジュールグラフについては、変化しません。

You will get a graph with a perfect horizontal line.Pandora FMS, if does not get new values, will think that there are not, and all things will appear exactly as they were in the last notification.Similar to the MRTG performance, for example.

グラフは完全に水平線になります。Pandora FMS では、新たな値を取得できない場合、それは存在せず、最後に情報が取得できた時の状態にあると判断します。例えば、MRTG の処理に似ています。

To see a graphic example, this image shows the changes for each data, received every 180 seconds.

グラフのサンプルとして、以下の画像では 180 秒ごとに受け取ったデータを表示しています。

Module graph full.jpg

This would be the equivalent graphic for the same data, expect a connection failure, from 05:55 to 15:29 approximately.

以下は、05:55頃〜15:29頃の間に同じデータが続いているグラフです。接続が失敗している可能性があります。

Module graph peak.jpg

In Pandora FMS 1.3 a new general graphic for the agent is introduced. It shows its connectivity, and it shows the access rate from the module agents. This graphic complements the other graphs that are shown when the agent has activity and is receiving data. This is an example of an agent that is regularly connected with the server:

Pandora FMS 1.3 では、新たにエージェント全般のグラフが導入されています。これは、接続性を表し、エージェントモジュールからのアクセス比を示しています。このグラフは、エージェントが稼働していてデータを受け取っている時に表示される他のグラフを補完するものです。以下は、通常サーバに接続しているエージェントの例です。

Access graph full.jpg

If you have peaks (lows) in this graphic, you could have problems or slow connections in the Pandora FMS agent connectivity with the Pandora FMS server. It is also possible that you could have connectivity problems from the network server.

もし、グラフにピークがある場合は、Pandora FMS エージェントと Pandora FMS サーバの接続において問題があるか、遅延が発生している可能性があります。ネットワークサーバからの接続においても問題が発生している可能性があります。

From Pandora's version 5 onwards, a new feature was introduced, which makes possible to cross the data of the "unknown module" type events with the graphs, to show in the graph the piece of data series that is under unknown condition, complementing the graph for a better interpretation, for example:

Pandora のバージョン 5以降では、"不明モジュール" タイプのイベントのデータをグラフに関連づけることができ、不明状態のデータをグラフに表示し、グラフを補完することができる新しい機能が導入されました。わかりやすいように以下に例を示します。


ファイル:Grafica-dsconocido.jpg


データベースにおけるインデックスの改良とその他技術的側面

We have implemented small improvements in the relational model of the Pandora FMS database. One of the changes that we have introduced is the indexation by module kinds.In this way, the access to the information is quicker, so the Pandora FMS logic agent, that is useful to "upload" all the information about monitoring. It is distributed in small pieces of information that could came form very different sources. In the new version of Pandora FMS we have planned until four kinds of new specific servers that will offer a wider variety of information kinds to process.

Pandora FMS データベースのリレーショナルモデルにおいて、小さな拡張を実装しました。導入した変更の一つは、モジュールの種類によるインデックス設定です。これにより、データへのアクセスが早くなりました。それにより、Pandora FMS エージェントがモニタリングしている全データをアップロードしやすくなりました。異なるソースのデータを細かく分割して提供されます。Pandora FMS の新バージョンでは、多くの種類の情報を処理できる 4つの種類の新しいサーバを計画しました。

Module distribution.jpg

In later versions, table partitioning (by time stamps) is recommended to further improve data history access performance.

最近のバージョンでは、過去データへのアクセスパフォーマンスをさらに向上させるために、テーブルのパーティショニング(タイム・スタンプによる)を推奨します。

We also have added factors such as the numerical representation of time marks (in UNIX format, or number of seconds from the 1 January 1970), speeds the searches of date ranks, comparisons of these ones, etc. This work has allowed a considerable improvement in the search times an in the insertions.

我々はまた、時刻表記の数値表現 (UNIX フォーマットや、1970年1月からの経過秒数) のような要素を追加しました。日付の検索や比較などが高速化しています。これは、データ挿入における検索時間の拡張と考えることもできます。

データベースのメインテーブル

Next is shown an ER diagram and also a detailed description of the main tables of Pandora FMS database. The rest of the tables are briefly commented too.

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

Pandora db eer.png
  • taddress: Contains agent additional addresses.
  • taddress: エージェントの追加アドレス。
  • taddress_agent: Addresses asociated to an agent(rel. taddress/tagente).
  • taddress_agent: エージェントのアドレス。(taddress/tagente に関連)
  • tagente: Contains the information of Pandora FMS agents.
  • tagente: Pandora FMS エージェントの情報。
    • id_agente: Agent unique identifier.
    • id_agente: エージェントのユニーク ID。
    • nombre: Name of the agent (case sensitive).
    • nombre: エージェント名。(大文字・小文字を区別します)
    • direccion: Agent address. It is possible to assign additional addresses through taddress.
    • direccion: エージェントアドレス。traddress を通して、追加アドレスを割り当てることができます。
    • comentarios: Free text.
    • comentarios: フリーテキスト。
    • id_grupo: Identifier of the group the agent belongs to (ref. tgrupo).
    • id_grupo: エージェントが所属するグループ ID。(tgrupo に関連)
    • ultimo_contacto: last date of agent contact, either through a software agent or through a remote module.
    • ultimo_contacto: ソフトウエアエージェントもしくは、リモートモジュールでの、エージェント接続の最終日時。
    • modo:Way in which the agent runs, 0 normal, 1 training.
    • modo:エージェントの動作モード。0 は通常モード、1 は学習モードです。
    • intervalo: agent execution interval. Depending on this interval, the agent will be showed as out of limits.
    • intervalo: エージェント実行間隔。この間隔に応じて、エージェントはタイムアウトを表示します。
    • id_os: Agent SO identifier (ref. tconfig_os).
    • id_os: エージェントの OS ID。(tconfig_os に関連)
    • os_version: SO version (free text).
    • os_version: OS バージョン。(フリーテキスト)
    • agent_version: Agent version (free text). Updated by the software agents.
    • agent_version: エージェントバージョン。(フリーテキスト) ソフトウエアエージェントによって更新されます。
    • `ultimo_contacto_remoto: Last date of contact received by the agent. In case of software agents, and unlike the last contact, the date is sent by the agent itself.
    • `ultimo_contacto_remoto: エージェントが接続してきた最終日時。ソフトウエアエージェントの場合、日時はエージェントから送信されます。
    • disabled: Agent state, disabled (0) or enabled (1).
    • disabled: エージェントの状態。無効状態であれば 0、有効であれば 1 です。
    • id_parent: Identifier of the agent parent (ref. tagente).
    • id_parent: 親エージェントの ID。(tagente に関連)
    • custom_id: Agent customized identifier. Useful to interact with other tools.
    • custom_id: エージェントのカスタマイズ ID。他のツールとの連携に便利です。
    • server_name: Name of the server the agent is assigned to.
    • server_name: エージェントに割り当てられたサーバ名。
    • cascade_protection: Cascade protection. Disabled at 0. When is at 1 it avoid that he alerts that are associated to the agent would be fired if a critical alert of the parent of the agent has been fired. For more info, check the section about Alerts.
    • cascade_protection: 関連障害検知抑制。0 で無効です。1 の場合は、親エージェントで障害が発生した場合に、該当エージェントでの障害発生を抑制します。詳細は、 アラートシステムを確認してください。
  • tagente_datos: Data received from each module. If for the same module the last received data is the same as the immediate previous one it will be not added (but tagente_estado is updated). The incremental and string type data are kept in different tables.
  • tagente_datos: モジュールから受信したデータ。同一のモジュールが最後に受信したデータと同じ値の場合は記録されません。(ただし、tagente_estado は更新されます。) インクリメンタルデータおよび、文字列タイプのデータは、別のテーブルに保持されます。
  • tagente_datos_inc: Incremental data type.
  • tagente_datos_inc: インクリメンタルデータタイプ。
  • tagente_datos_string: String kind data.
  • tagente_datos_string: 文字列データ。
  • tagente_estado: Information of the current status of each module.
  • tagente_estado: それぞれのモジュールの現在の状態。
    • id_agente_estado: Identifier.
    • id_agente_estado: ID。
    • id_agente_modulo: Module identifier.(ref. tagente_modulo).
    • id_agente_modulo: モジュール ID。(tagente_modulo に関連)
    • datos: Value of the last received data.
    • datos: 最新の受信データの値。
    • timestamp: Data of the last data received (could come from the agent).
    • timestamp: (エージェントからの)最新のデータを受け取った日時。
    • estado: Module status: 0 NORMAL, 1 CRITICAL, 2 WARNING, 3 UNKNOWN.
    • estado: モジュールの状態で、0 正常、1 障害、2 警告、3 不明 です。
    • id_agente: Agent identifier associated to the module (ref. tagente).
    • id_agente: モジュールに関連づけられたエージェント ID。(tagente に関連)
    • last_try: Data of the module last successful execution.
    • last_try: 最後に実行に成功したモジュールの日時。
    • utimestamp:Data of the module last execution in UNIX format.
    • utimestamp:UNIX フォーマットでの最後に実行したモジュールの日時。
    • current_interval:Module execution intervale in seconds.
    • current_interval:モジュールの実行間隔を秒で示します。
    • running_by: Name of the server that executed the module.
    • running_by: モジュールを実行するサーバ名。
    • last_execution_try: Date of the module execution last try.The execution could have failed.
    • last_execution_try: 実行が失敗している場合でも、最後にモジュールの実行を試みた日時を示します。
    • status_changes: Number of status changes that have been occurred. It is used to avoid continuous status changes. http://www.openideas.info/wiki/index.php?title=Pandora_3.0:Documentation_es:Operacion#FF_Threshold
    • status_changes: 状態の変化が発生した回数。継続的な状態変化を避けるために利用されます。http://www.openideas.info/wiki/index.php?title=Pandora_3.0:Documentation_ja:Operations#.E8.A4.87.E6.95.B0.E5.9B.9E.E9.80.A3.E7.B6.9A.E8.A8.AD.E5.AE.9A
    • last_status: Module previous status.
    • last_status: モジュールの一つ前の状態。
  • tagente_modulo: Module configuration.
  • tagente_modulo: モジュールの設定。
    • id_agente_modulo: Module unique identifier.
    • id_agente_modulo: モジュールの ID。
    • id_agente: Agent identifier associated to the module(ref. tagente).
    • id_agente: モジュールに関連付けられたエージェント ID。(tagente に関連)
    • id_tipo_modulo: Kind of module (ref. ttipo_modulo).
    • id_tipo_modulo: モジュールの種類。(ttipo_modulo に関連)
    • descripcion: Free text.
    • descripcion: フリーテキスト。
    • nombre: Module name.
    • nombre: モジュール名
    • max: Module maximum value. Higher data than this value will be consider invalid.
    • max: モジュールの最大値。これより大きな値は、不正な値として認識されます。
    • min: Module minimum value. Lower data than this value will be consider invalid.
    • min: モジュールの最小値。これより小さな値は、不正な値として認識されます。
    • module_interval: Module execution interval in seconds.
    • module_interval: 秒単位のモジュール実行間隔。
    • tcp_port: Destination TCP port in network modules and plugin. Name of the column to read in WMI modules.
    • tcp_port: ネットワークモジュールおよびプラグインの接続先 TCP ポート。WMI モジュールでは、読み込むカラム名。
    • tcp_send:Data to send in network modules. Namespace in WMI modules.
    • tcp_send:ネットワークモジュールでの送信データ。WMI モジュールでは、ネームスペース。
    • tcp_rcv: Expected answer in network modules.
    • tcp_rcv: ネットワークモジュールでの想定する受信データ。
    • snmp_community:SNMP community in network modules. Filter in WMI modules.
    • snmp_community:ネットワークモジュールでの SNMP コミュニティ。WMI モジュールでのフィルタ。
    • snmp_oid: OID in network modules. WQL Query in WMI modules.
    • snmp_oid: ネットワークモジュールでの OID。WMI モジュールでの WQL クエリ。
    • ip_target: Destination address in network modules, plugin and WMI.
    • ip_target: ネットワーク、プラグイン、および WMI モジュールでの対象アドレス。
    • id_module_group:Identifier of the group the module belongs to (ref. tmodule_group).
    • id_module_group:モジュールが所属するグループの ID。(tmodule_group に関連)
    • flag: Flag of forced execution. If is at 1 the module will be executed though it would be not entitled by interval.
    • flag: 強制実行フラグ。1 に設定されている場合、実行間隔に関係なく実行されます。
    • id_modulo: Identifier for modules that could not been recognized by its id_tipo_módulo. 6 for WMI modules, 7 for WEB modules.
    • id_modulo: id_tipo_módulo では見分けることができないモジュール ID。6 が WMI モジュール、7 が、WEB モジュール。
    • disabled: Module status, 0 enabled, 1 disabled.
    • disabled: モジュールの状態。0 が有効、1 が無効。
    • id_export: Identifier of the export server associated to the module (ref. tserver).
    • id_export: モジュールに関連づけられた、エクスポートサーバの ID。(tserver に関連)
    • plugin_user: User name in plugin and WMI modules, user-agent in Web modules.
    • plugin_user: プラグインおよび WMI モジュールのユーザ名。Web モジュールのユーザエージェント。
    • plugin_pass: Passwork in plugin modules and WMI, number of reattempts in Web modules.
    • plugin_pass: プラグインおよび WMI モジュールのパスワード。Web モジュールの試行回指数。
    • plugin_parameter: Additional parameters in plugin modules, configuration of Goliat task in Web modules.
    • plugin_parameter: プラグインモジュールの追加パラメータ。Web モジュールの Goliat タスク設定。
    • id_plugin: Identifier of the plugin associate to the module in plugin modules (ref. tplugin).
    • id_plugin: プラグインモジュールのモジュールに関連付けられた、プラグインの ID。(tpluginに関連)
    • post_process: Value with the module data will be multiplied by before being kept.
    • post_process: モジュールデータの値に対して、保存前にかける倍率。
    • prediction_module: 1 if it is a prediction module, 0 in any other case.
    • prediction_module: 1 であれば予測モジュール。0 であればそれ以外。
    • max_timeout: time to wait in seconds in plugin modules.
    • max_timeout: プラグインモジュールでの、秒単位の最大タイムアウト値。
    • custom_id: Module customized identifier. Useful to interact with other tools.
    • custom_id: モジュールのカスタム ID。他のツールとの連携に便利です。
    • history_data: If it is at 0 module data will not be kept at tagente_datos*, only tagente_estado will be updated.
    • history_data: 0 の場合、モジュールのデータは tagente_datos に保存されません。tagente_estado のみ更新されます。
    • min_warning: Minimum value that activates the WARNING status.
    • min_warning: 警告状態になる最小値。
    • max_warning: Maximum value that activates the WARNING status.
    • max_warning: 警告状態になる最大値。
    • min_critical: Minimum value that activates the CRITICAL status.
    • min_critical: 障害状態になる最小値。
    • max_critical: Maximum status that activates the CRITICAL status.
    • max_critical: 障害状態になる最大値。
    • min_ff_event: Number of times that should be a condition of status change before this change take place. It is is related with

tagente_estado.status_changes. http://www.openideas.info/wiki/index.php?title=Pandora_3.0:Documentation_es:Operacion#FF_Threshold

    • min_ff_event: 何回まで状態変化を許容するかのデータを保持します。これは、tagente_estado.status_changes に関連しています。 http://www.openideas.info/wiki/index.php?title=Pandora_3.0:Documentation_ja:Operations#.E8.A4.87.E6.95.B0.E5.9B.9E.E9.80.A3.E7.B6.9A.E8.A8.AD.E5.AE.9A
    • delete_pending: If it is at 1 it will be deleted by the maintenance script of pandora_db.pl database.
    • delete_pending: 1 に設定されると、データベースのメンテナンススクリプト pandora_db.pl のメンテナンスによって削除されます。
    • custom_integer_1: When prediction_module = 1 this field is the module id that is used to predict. When prediction_module = 2 this field is the service id assigned to the module
    • 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: A new entry will be inserted each time that it is received data from an agent to any of the servers, but never more than one by minute to avoid overload the database. It could be deactivated setting the agentaccess to 0 in the pandora_server.conf configuration file.
  • tagent_access: いずれかのサーバにエージェントからデータを受信するたびに新たな時間が追加されます。ただし、データベースの高負荷を避けるために、1分より細かい時間は記録されません。pandora_server.conf ファイルで、agentaccess を 0 にすると無効になります。
  • talert_snmp: Configuration of SNMP alerts.
  • talert_snmp: SNMP アラートの設定です。
  • talert_commands: Commands that could be executed from actions associated to an alert (eg. send mail).
  • talert_commands: エージェントに関連づけられたアクションから実行されるコマンド。(send mail など)
  • talert_actions: Command instance associated to one alert (eg. send mail to administrator).
  • talert_actions: アラートに関連づけられたコマンド。(administrator へのメール送信など)
  • talert_templates: Alert templates.
  • talert_templates: アラートテンプレート。
    • id: Template unique identifier.
    • id: テンプレート ID。
    • name: Template name.
    • name: テンプレート名。
    • description: Description.
    • description: 説明。
    • id_alert_action: Identifier of the default action associated to the template.
    • id_alert_action: テンプレートに関連づけられたデフォルトアクション ID。
    • field1: Customized field 1(free text).
    • field1: カスタマイズフィールド 1 (フリーテキスト)
    • field2: Customized field 2(free text).
    • field2: カスタマイズフィールド 2 (フリーテキスト)
    • field3: Customized field 3 (free text).
    • field3: カスタマイズフィールド 3 (フリーテキスト)
    • type: kind of alert depending on the shot condition ('regex', 'max_min', 'max', 'min', 'equal', 'not_equal', 'warning', 'critical').
    • type: アラートの状態別の種類。('regex', 'max_min', 'max', 'min', 'equal', 'not_equal', 'warning', 'critical')
    • value: Value for alerts kind regex (free text).
    • value: regex の場合のアラートの値。(フリーテキスト)
    • matches_value: To 1 it inverts the logic of the shot condition.
    • matches_value: 1 にすると、状態を反転させます。
    • max_value: Maximum value for max_min and max alerts.
    • max_value: max_min および最大アラートの最大値。
    • min_value: Minimum value for max_min and min alerts.
    • min_value: max_min および最小アラー他の最小値。
    • time_threshold: Alert interval.
    • time_threshold: アラーとの間隔。
    • max_alerts: Maximum number of times that an alert will be fired during an interval.
    • max_alerts: 一間隔中における、アラート実行最大回数。
    • min_alerts: Minimum number of times that the shot condition should be shown during an interval to the alert will be fired.
    • min_alerts: アラートが実行される一間隔中における、状態表示最小回数。
    • time_from: Time from which the alert will be active.
    • time_from: アラートが有効になる開始時間。
    • time_to: Time to which the alert will be active.
    • time_to: アラートが有効になる終了時間。
    • monday: To 1 the alert is active on Mondays.
    • monday: 1 の場合、アラートが月曜に有効になります。
    • tuesday: To 1 the alert will be active on Tuesdays.
    • tuesday: 1 の場合、アラートが火曜に有効になります。
    • wednesday: To 1 the alert will be active on Wednesdays.
    • wednesday: 1 の場合、アラートが水曜に有効になります。
    • thursday: To 1 the alert will be active on Thursdays.
    • thursday: 1 の場合、アラートが木曜に有効になります。
    • friday: To 1 the alert will be active on Fridays.
    • friday: 1 の場合、アラートが金曜に有効になります。
    • saturday: To 1 the alert will be active on Saturdays.
    • saturday: 1 の場合、アラートが土曜に有効になります。
    • sunday: To 1 the alert will be active on Sundays.
    • sunday: 1 の場合、アラートが日曜に有効になります。
    • recovery_notify: To 1 activate the alert recovery. http://www.openideas.info/wiki/index.php?title=Pandora_3.0:Documentation_es:Alertas#Plantilla_de_alerta
    • recovery_notify: 1 の場合、復旧通知が有効になります。http://www.openideas.info/wiki/index.php?title=Pandora_3.0:Documentation_ja:Alerts#.E3.82.A2.E3.83.A9.E3.83.BC.E3.83.88.E3.83.86.E3.83.B3.E3.83.97.E3.83.AC.E3.83.BC.E3.83.88
    • field2_recovery: Customized field 2 for alert recovery (free text).
    • field2_recovery: 復旧通知のカスタムフィールド 2。(フリーテキスト)
    • field3_recovery: Customized field 3 for alert recovery (free text).
    • field3_recovery: 復旧通知のカスタムフィールド 3。(フリーテキスト)
    • priority: Alert criticity: 0 Maintenance, 1 Informational, 2 Normal, 3 Warning, 4 Critical.
    • priority: アラートの重要度。0 メンテナンス、1 情報、2 正常、3 警告、4 障害
    • id_group: Identifier of the group the template belongs to (ref. tgrupo).
    • id_group: テンプレートが属するグループ ID。 (tgrupo に関連)
  • talert_template_modules: Instance of an alert template associated to a module.
  • talert_template_modules: モジュールに関連付けられたアラートテンプレートのインスタンス。
    • id: Alert unique identifier.
    • id: アラートのユニーク ID。
    • id_agent_module: Identifier of the module associated to the alert (ref. tagente_modulo).
    • id_agent_module: アラートに関連付けられたモジュールの ID。(tagente_modulo に関連)
    • id_alert_template: Identifier of the templated associated to the alert (ref. talert_templates).
    • id_alert_template: アラートに関連付けられたテンプレートの ID。(talert_templates に関連)
    • internal_counter: Number of times that the alert shot condition has occurred.
    • internal_counter: アラート通知状態の発生回数。
    • last_fired: Last time the alert was fired (Unix time)
    • last_fired: アラートを通知した最後の時間。(Unix time)
    • last_reference: Start of the current interval (Unix time).
    • last_reference: 現在の間隔の開始時間。(Unix time)
    • times_fired: number of times the alert was fired (could be different from internal_counter)
    • times_fired: アラートが通知された回数。(internal_counter とは異なります)
    • disabled: At 1 the alert is deactivated.
    • disabled: 1 の場合、アラートは無効です。
    • priority: Alert criticity : 0 Maintenance, 1 Informational, 2 Normal, 3 Warning, 4 Critical.
    • priority: アラートの重要度。0 メンテナンス、1 情報、2 正常、3 警告、4 障害
    • force_execution: At 1 the action of the alert will be executed thought it has not been fired. It is used for the alert manual execution.
    • force_execution: 1 の場合、アラートが発生していなくてもアラートのアクションが実行されます。アラートの手動実行に便利です。
  • talert_template_module_actions: Instance of an action associated to one alert (ref. talert_template_modules).
  • talert_template_module_actions: 一つのアラートに関連付けられたアクションのインスタンス。(talert_template_modules に関連)
  • talert_compound: Compound alerts, the columns are similar to the talert_templates.
  • talert_compound: 関連付けアラートです。カラムは、talert_templates に似ています。
  • talert_compound_elements: Simple alerts associated to a compound alert, each one with its correspondent logic operation (ref. talert_template_modules).
  • talert_compound_elements: 関連付けアラートに関連付けられた、それぞれのロジックを持った単一アラートです。(talert_template_modules に関連)
  • talert_compound_actions: Actions associated with a compound alert (ref. talert_compound).
  • talert_compound_actions: 関連付けアラートに関連付けられたアクションです。(talert_compound に関連)
  • tattachment: Attachments associated to one incident.
  • tattachment: 一つのインシデントに関連付けられた添付です。
  • tconfig: Console configuration.
  • tconfig: コンソールの設定。
  • tconfig_os: Valid Operative systems in Pandora FMS.
  • tconfig_os: Pandora FMS が扱う OS です。
  • tevento: Event entries. The criticity values are the same ones than for the alerts.
  • tevento: イベントエントリー。重要度の値はアラートと同じです。
  • tgrupo: Defined groups in Pandora FMS.
  • tgrupo: Pandora FMS に定義されているグループ。
  • tincidencia: Incident entries
  • tincidencia: インシデントエントリー。
  • tlanguage: Available languages in Pandora FMS.
  • tlanguage: Pandora FMS で扱える言語。
  • tlink: Links showed at the console menu lower side.
  • tlink: コンソールの下の方のメニューに表示されるリンク。
  • tnetwork_component: Network components. They are modules associated to a network profile used by the Recon Server. After they result in an entry at tagente_modulo, so the columns of both tables are similar.
  • tnetwork_component: ネットワークコンポーネント。自動検出サーバで使われるネットワークプロファイルに関連付けられたモジュールです。tagente_module にエントリーが保存されると、双方のテーブルは似た状態になります。
  • tnetwork_component_group: Groups to classify the network components.
  • tnetwork_component_group: ネットワークコンポーネントを分類するグループ。
  • tnetwork_profile: Network profile. Network components group that will be assigned to recognition tasks of the Recon Server. The network components associated to the profile will result in modules in the created agents.
  • tnetwork_profile: ネットワークプロファイル。自動検出サーバの検出タスクに関連付けられるネットワークコンポーネントグループです。プロファイルに関連付けられるネットワークコンポーネントは、作成されたエージェントにモジュールを定義します。
  • tnetwork_profile_component: Componentes de red asociados a un perfil de red (rel. tnetwork_component/tnetwork_profile).
  • tnetwork_profile_component: ネットワークプロファイルに関連付けられているネットワークコンポーネント。(tnetwork_component/tnetwork_profile に関連)
  • tnota: Notes associated to an incident.
  • tnota: インシデントに関連づけられたメモ。
  • torigen: Possible origins of an incident.
  • torigen: インシデントの発生元リスト。
  • tperfil: User profiles defined at the console.
  • tperfil: コンソールで定義されたユーザプロファイル。
  • tserver: Registered servers.
  • tserver: 登録されているサーバ。
  • tsesion: information on actions that toke place during an user session for administration and statistical logs.
  • tsesion: ユーザの操作記録。
  • ttipo_modulo: Kinds of modules depending on their origin and kind of data.
  • ttipo_modulo: 取得元およびデータの種類に応じた、モジュールの種類。
  • ttrap: SNMP traps received by the SNMP console.
  • ttrap: SNMP コンソールで受信したトラップ。
  • tusuario: Registered users at the console.
  • tusuario: コンソールで登録されているユーザ。
  • tusuario_perfil: Profiles asociated to an user (rel. tusuario/tperfil).
  • tusuario_perfil: ユーザに関連付けられたプロファイル (tusuario/tperfil に関連)
  • tnews: News showed at the console.
  • tnews: コンソールに表示されるニュース。
  • tgraph: Customized graphs created in the console.
  • tgraph: コンソールで作成されたカスタムグラフ。
  • tgraph_source: Modules associated to a graph (rel. tgraph/tagente_modulo).
  • tgraph_source: グラフに関連付けられたモジュール。(tgraph/tagente_modulo に関連)
  • treport: Customized reports created at the console.
  • treport: コンソールで作成されたカスタムレポート。
  • treport_content: Elements associated to one report.
  • treport_content: 一つのレポートに関連付けられた要素。
  • treport_content_sla_combined: Components of an SLA element associated to one report.
  • treport_content_sla_combined: 一つのレポートに関連付けられた SLA のコンポーネント。
  • tlayout: Customized maps created at the console.
  • tlayout: コンソールで作成されたカスタムマップ。
  • tlayout_data: Elements associated to a map.
  • tlayout_data: マップに関連付けられた要素。
  • tplugin: Plugin definitions for the Plugin Server.
  • tplugin: プラグインサーバのためのプラグイン定義。
  • tmodule: Kinds of modules (Network, Plugin, WMI...).
  • tmodule: モジュールの種類。(ネットワーク、プラグイン、WMI...).
  • tserver_export_data: Data to export, associated to a destination.
  • tserver_export_data: 宛先に関連付けられた、エクスポートするデータ。
  • tplanned_downtime: Programmed stops.
  • tplanned_downtime: 計画停止。
  • tplanned_downtime_agents: Agents associated to a programmed stop (rel. tplanned_downtime/tagente).
  • tplanned_downtime_agents: 計画停止に関連付けられたエージェント。(tplanned_downtime/tagente に関連)

リアルタイムでのデータ圧縮

To avoid overload the database, the server does a simple compression in time of insertion.One data won't be stored at the database unless it would be different to the previous one or it would be a difference of 24 hours between both of them.

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

For example, supposing an interval of approximately 1 hour, then the sequence 0,1,0,0,0,0,0,0,1,1,0,0 is kept in the database as 0,1,0,1,0. It won't kept other consecutive 0 unless 24 h. have passed.

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

The graph that is shown next has been drawn from the data of the previous example. Only the data in red has been inserted in the database.

以下のグラフでは、上記の例のデータを示しています。赤で示したデータのみがデータベースに保存されます。

Data compression 01.png

The compression affects to the algorithms of data processing. Either to the metrics as to the graphs, and it's important to consider that you should fill in the blanks that are caused by the compression.

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

Considering all the previous things, in order to calculate with the data of a given module the interval and the starting data, you should follow these steps:

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

  • Search for the previous data out of the interval and date given. If it exists, you have to put it at the beginning of the range. If it doesn't exist, then previously there was no data.
  • 指定した間隔や日時よりも古いデータを検索します。見つかった場合は、それが現在の値になった最初のデータです。見つからなかった場合は、過去にデータは存在しません。
  • Search the following data out of the range and data given until a maximum equal to the module interval. If it exists, then you have to put it at the end of the interval. If not, you have to extend the last available value until the end of the interval.
  • モジュールの実行タイミングと同じ日時まで、指定した間隔や日時よりも新しいデータを検索します。見つかった場合は、それが値が変化したタイミングのデータとなります。もし、見つからなかった場合は、最後に記録された値が現時点まで続いていることになります。
  • All data should be check, considering that one data is valid until we get another data.
  • あるデータを特定するためには、それが可能となる他のデータを全て確認する必要があります。

データの削減

Pandora FMS has included a system to "compact" database information. This system is focus on small / mid-size deployments (250-500 agents, < 100,000 modules) which want to have a long history information but "loosing" some resolution.

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

Pandora FMS database maintance, which is executed each day do a scan of old data subject to be compacted. This compactation is done using a simple linear interpolation, that means, if you have 10,000 points of information in a day, you will get a result of a process of interpolation, which replace that 10,000 points for 1000 points.

毎日実行される Pandora FMS データベースのメンテナンスで、古いデータを検索し削減します。この削減は、単純な線形補完を用いて行われます。つまり、一日に 10,000個の情報があったとすると、その処理により 1000個に置き換えられます。

This, obviously "loose" information, because is an interpolation, BUT also saves database storage and on long term graphs (monthly, yearly) the graphs are mostly the same. In big databases this behaviour coult be "costly" in terms on database performance, and should be disabled and you should use the history database model instead.

これは、明らかに情報が欠落します。なぜならば線形補完だからです。しかし、データベース容量を節約し、長期間(月次、年次)のグラフについては同じように見れます。大きなデータベースでは、これでもデータベースパフォーマンスが必要です。その場合はこれを使わずに、代わりにヒストリデータベースモデルを利用してください。


Sample of non compact data

データ削減無しの例


Same graph after a compactation

データ削減後の例

ヒストリデータベース

This is an Enterprise feature, and is used to store the information from a given point in time, for example, data with more than one month in a different database. This database must be in a different physical server (no virtualize here, please!). Automatically, when you request a data graph for 1 year, Pandora FMS will look the first XX days in the "realtime/main" database and the other information in the history database. In this way you can avoid to have performance penalties when you store a huge ammount of information in your system.

To configure this, you need to setup manually in another server, a history database (importing the Pandora FMS DB Schema into it, without data), and setup permissions to allow access to it from the main Pandora FMS server.

Go to Setup -> History database and configure there the settings to access the history database.

これは Enterprise 版の機能で、指定した時点からのデータを保存します。例えば、1ヶ月以上前のデータを異なるデータベースに保存します。このデータベースは、異なる物理サーバ上にあるべきです(これを仮想化しないでください!)。1年間のグラフを表示しようとした場合、Pandora FMS は、自動的に最初の XX 日を現在のメインのデータベースから取得し、他の情報をヒストリデータベースから取得します。これにより、大量のデータを保存している場合において、パフォーマンスの問題を避けることができます。

これを設定するには、他のサーバにてヒストリデータベースの設定(Pandora FMS のデータベーススキーマをインポートし、データは入れる必要ありません)とメインの Pandora FMS サーバからのアクセスができるような設定を手動で行う必要があります。

設定 -> ヒストリデータベースへ行き、そこでヒストリデータベースへアクセスするための設定を行います。



800px



Some settings interesting which need to be explained:

必要な設定項目について以下に説明します。

  • Days: max days information is stored in main database. After that date, data will be moved to history db. 30 days is a good default.
  • Days: メインのデータベースに保存する最大日数。この日を超えると、データはヒストリデータベースへ移されます。デフォルトで30日がお勧めです。
  • Step: This acts like a buffer, database maintance script, will take XX registers from database, will insert it in the history database and will delete it from main database. This is timeconsuming, and size depends on your setup, 1000 is a good default-
  • Step: これはバッファのように動作するものです。データベースメンテナンススクリプトは、データベースから指定した XX 件読み出し、ヒストリデータベースへ入れます。また、メインのデータベースからそれを削除します。設定サイズにより時間がかかります。デフォルトで 1000がお勧めです。
  • Delay: After a block of step modules, script will wait for delay seconds. Useful if your database performance is poor, to avoid locks. Use values only between 1-5.
  • Delay: setup で設定したサイズを処理したのち、スクリプトが待つ時間を指定します。データベースのパフォーマンスが低い場合にロックを避けるのに便利です。1-5の間の値を指定してください。

The default configuration of Pandora FMS does NOT transfer string type data to the historical database, however, if we have modified this configuration and our historical database is receiving this type of information it is essential that we configure its purging otherwise it will end up occupying too much time, causing big problems, besides having a negative impact on the performance.

Pandora FMS のデフォルト設定では、文字列タイプデータをヒストリデータベースへ転送しません。しかしながら、この設定を変更してヒストリデータベースにこのタイプの情報が送られている場合は、 パフォーマンスに悪影響を与えるだけでなく、大きな問題を引き起こすことになります。

To configure this parameter we must run a query directly in the database to determine the days after which this information will be purged. The table we are interested in is tconfig and the field string_purge. If we wanted for example to set 30 days for the purging of this type of information, for example, we would run the next query directly on the historical database:

このパラメータを設定するには、データベースで直接クエリを実行して、この情報を削除する日数を決定する必要があります。関係するのは、テーブル tconfig とフィールド string_purgeです。 たとえば、このタイプの情報の保存期間を 30日を設定したい場合、ヒストリデータベースで直接次のクエリを実行します。

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

A good way to test this is to run the database maintance script manually:

これをテストするには、データベースメンテナンススクリプトを手動実行します。

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

You should not get any errors there.

エラーが出なければ問題ありません。

Pandora FMS におけるモジュールの状態

In Pandora FMS the modules can have different states:Unkown, Normal, Warning, Critical or with Fired Alerts.

Pandora FMS では、モジュールは、不明、正常、警告、障害や、アラート発生といった状態を持ちます。

状態はいつ変更されるのか

Each module has the Warning and Critical thresholds fixed in its configuration. These thresholds define its data values for which these states will be activate. If the module gives data out of these thresholds, then it will be considered that it's on Normal state.

それぞれのモジュールには、警告や障害状態のしきい値の設定があります。これらのしきい値は、データの値によっていそれぞれの状態になるということを定義します。モジュールのデータがこれらのしきい値の範囲から外れれば、正常状態と認識されます。

Each module has also a time interval that will fix the frequency with which it will get the data. This interval will be taken into account by the console to collect data. If the module has the double of its interval without collecting data, then, it'll be considered that this module is in Unknown State.

それぞれのモジュールには、データを収集する間隔の設定もあります。データ収集の間隔はコンソールで確認されます。もし、モジュールが収集間隔の 2倍の期間データを収集できなかった場合、そのモジュールは不明状態となります。

Finally, if the module has configured alerts and any of them have been fired and have not been validated, then the module will have the corresponding Fired Alert state.

最後に、モジュールにアラート設定があり、アラートが発生し承諾されていなければ、モジュールはアラート発生状態となります。

伝播と優先度

In Pandora's organization, some elements depend on others, as for example the modules of one agent or the agents of one group.These can also be applied to the case of the Pandora's FMS Enterprise policies, which have associated some agents and some modules that are considered associated to each agent.

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

This structure is specially useful in order to evaluate easily the states of the modules. This is obtained spreading up the states in this organization, giving state to the agents, groups and policies this way.

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

エージェントがとりうる状態

An agent will have the worst of its modules's states. Recursively, a group will have the worst of the agent's states that belong to it, and the same for the policies, that will have the worst state of its assigned agents.

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

This way, by seeing one group with a critical state, for example, we'll known that at least one of its agents has the same state. When we locate it, we could get down another level to get to the module or modules that have caused the spreading of the critical state to the upper level.

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

ステータスポリシー

When we say that the worst of the states is spread, we should be sure which states are the most important ones. This way, there is a priority list, being the first state in it the one that has highest priority over the others and the last one the one that has the lowest. This one will be shown only with all elements have it.

正常ではない状態が複数発生している場合、どれが最も重要かを判断する必要があります。そのために優先順位のリストがあり、1番目の状態が他よりも最も優先順位が高く、最後のものが優先順位が低くなっています。すべての要素でいずれかが表示されます。

  1. Fired Alerts
  2. アラート発生
  3. Critical State
  4. 障害状態
  5. Warning State
  6. 警告状態
  7. Unknown State
  8. 不明状態
  9. Normal State
  10. 正常状態


We can see that when a module has fired alerts, its state has priority over the rest, and the agent to which it belongs will have this state and also the group to which this agent belongs to.

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

On the other hand, in order to one group, for example, has a normal state, all its agents should have this state; which implies that all the modules of these groups will have normal state.

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

カラーコード

Each one of the commented states has a color assigned, in order to could view in the network maps, with a quick view, when something isn't working properly.

それぞれの状態には、何かが正常に動作していないことをネットワークマップで簡単に表示できるように、色が設定されています。

Orange status.png Fired alerts State
Orange status.png アラート発生
Red status.png Critical State
Red status.png 障害状態
Yellow status.png Warning State
Yellow status.png 警告状態
Grey status.png Unknown State
Grey status.png 不明状態
Green status.png Normal State
Green status.png 正常状態

Pandora FMS グラフ

Graphs are one of the most complex implementations on Pandora FMS, because they gather information in real-time from the DB, and no external system is used (rrdtool or similar).

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

There are several behaviors of the graphs that depend on the type of the data:

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

  • Asynchronous modules. It is assumed that there is no data compaction. Data stored in the DB are all the real samples of the data (therefore, no compaction). It produces more "exact" graphs without possible misinterpretation.
  • Text string modules. Shows the rate of the gathered data.
  • Numerical modules. Most modules report such data.
  • Boolean modules. This are numerical data on *PROC modules: for instance, ping checks, interface status, etc. 0 means wrong, 1 means "Normal". They raise events automatically when they change of state.
  • 非同期モジュール. データ圧縮が無いことを想定します。DB に保存されているデータは、すべて実際に収集されたデータです(圧縮がないため)。 抜けなく正確なグラフが生成されます。
  • 文字列モジュール. 取集したデータのレートを表示します。
  • 数値モジュール. ほとんどのモジュールはそのデータを表示します。
  • Boolean モジュール. ping のチェックやインタフェースの状態などの *PROC モジュールでは、数値データになります。0 は、障害を、1 は正常を意味します。状態が変化した場合は自動的にイベントをあげます。

圧縮

Compression affects on how the graphics are represented. When we receive two data with the same value, Pandora does not store the last data, but interprets that the last known value can be used for the present time if we don't have another value. When we are painting a graph, if we do not have a reference value just when the graphic starts, Pandora searches 48 hours back in time to find the last known value to take as reference. If it doesn't find anything, it will start from 0.

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

In asynchronous modules, although there are not compression, the backwards search algorithm behaves similar.

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

補間

When composing a graph, Pandora takes 50xN samples, being N the resolution factor of the graphs (this value can be configured in the setup). A monitor that gathers data every 300 seconds (5 minutes) will have 12 samples per hour, and 12x24 = 288 samples in a day. So when we ask a graph of a day, we are not printing 288 values, we are "compressing" or interpolating the graphic using only 50x3=150 samples (by default, graph resolution in Pandora is 3).

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

This means that we lose some resolution and the more samples. When we have a lot of values, for instance the 2016 samples of a week, of 8400 samples of a month, we must compress them in the 150 samples of a graph. This is why sometimes we lose detail and do not see some details, that's why the graphs can be queried with different intervals and to zoom in or out.

これは、精度といくつかのデータを失うことを意味します。一週間で 2016 サンプル、一か月で 8400 サンプルといった、多くのデータがある場合、一つのグラフで 150 サンプルに圧縮する必要があります。これが詳細部分を失う理由です。なぜなら、グラフは異なる期間でズームしたりできるようにするためです。

ファイル:Graph-explain.png


In the normal graphs, the interpolation is implemented in a simple way: if withing an interval we have two samples (p.e: interval B of the example), we do the average and we draw its value.

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

In boolean graphs, if within a sample we have several data (we can only have 1 or 0), we take the pessimist approach, and draw 0. This helps for the visualization of failures within an interval, having priority showing the problem that the normal status.

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

In both cases, if within a sample we don't have any data (because it's compressed or because it's missing), we will use the last known value of the previous interval to show the data, like the interval E of the above example shows.

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

平均/最大/最小

400px

The graphs by default show the average, maximum and minimum values. Because a sample (see "interpolation") can have several data, we show the average values of the data, the maximum or the minimum. The more interpolation needed (the longer the period we are visualizing and we have considerably more data), the higher the interpolation level will be, therefore the difference between maximum and minimum values will be greater. The lower the range of the graph (an hour or so), there will not be interpolation, or it will be minimum, so we'll see the data with its "real" resolution, and the three series will be identical.

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