差分
このページの2つのバージョン間の差分を表示します。
次のリビジョン | 前のリビジョン | ||
ja:documentation:05_big_environments:09_pandorafms_engineering [2021/06/17 13:24] – 作成 junichi | ja:documentation:05_big_environments:09_pandorafms_engineering [Unknown date] (現在) – 削除 - 外部編集 (Unknown date) 127.0.0.1 | ||
---|---|---|---|
行 1: | 行 1: | ||
- | ====== Pandora FMS の技術情報 ====== | ||
- | {{indexmenu_n> | ||
- | |||
- | [[ja: | ||
- | |||
- | ===== Pandora FMS の技術詳細 ===== | ||
- | |||
- | この補足資料では、いくつかの Pandora FMS の特別な機能および設計について説明します。Pandora FMS データベーススキーマなどのいくつかの技術的情報に対しては多くの説明が必要であり、ここに記載している内容はあくまでも概要です。 | ||
- | |||
- | ==== Pandora FMS のデータベース設計 ==== | ||
- | 0.83 から 1.1 までの Pandora FMS の初期バージョンでは、データベースに一つのデータに対して一つの挿入を行うという、とてもシンプルな考えに基づいていました。この方法は、開発がとても簡単で、簡単な検索や挿入などの操作をプログラムしやすくなっていました。 | ||
- | |||
- | これは、多くの利点がありましたが、スケーラビリティに関しては大きな問題をもっていました。このシステムでは、サポートできるモジュールの最大数にある上限があり、一定数のデータで負荷が増大しクラスタリングの仕組みを実装しにくく、(5万を超える項目では) 処理も早くはありませんでした。 | ||
- | |||
- | MySQL クラスタをベースにしたソリューションは簡単ではなく、常に何らかの問題が発生していました。そして改善に長時間を要しました。 | ||
- | |||
- | 現在のバージョンの Pandora FMS では、データの挿入におけるリアルタイムでのデータ圧縮を実装しています。それは、収集間隔に基づいたデータ圧縮を行います。また、特定の日付のデータを自動的に削除するような実装も行っています。 | ||
- | |||
- | 新たなデータ処理システムは、新しいデータのみを保持します。同じ値がシステムに入力された場合、それはデータベースに保存されません。これはデータベースを小さい状態に維持するのにとても便利です。これは、数値、インクリメンタルな数値、ブーリアン等のすべての Pandora FMS モジュールで動作します。ブーリアンデータでは、データの変化はまれであるため、とても高圧縮になります。それでもインデックスデータは、24時間ごとに保存されます。情報の圧縮により、参照するのに便利な最小限のデータとなります。 | ||
- | |||
- | これは、データ量が 40%〜70% となり、スケーラビリティの問題を解決します。また、スケーラビリティの問題を解決するための Pandora FMS コンポーネントを分割するという別の解もあります。これは、データファイル処理の負荷を分散させたり、ネットワークモジュールを異なるサーバで実行できるというものです。現在、Pandora FMS ウェブコンソールのように、複数の Pandora FMS サーバ (ネットワークサーバ、データサーバや、SNMP サーバ) を持つことができ、また、データベースも (MySQL5 で) クラスタを組むことができます。 | ||
- | |||
- | データの読み込みや処理の調整は大きな変化を意味します。我々は、新たなデータ保存モデルにおいて、すばやくデータを表示できるように、ゼロからグラフィックエンジンを設計、実装し直しました。新しいバージョンでは、エージェントが Pandora FMS と通信できず、Pandora FMS サーバがエージェントからデータを受け取れない場合、この欠落したデータはグラフに表示されません。そして、モジュールグラフについては、変化しません。 | ||
- | |||
- | グラフは完全に水平線になります。Pandora FMS では、新たな値を取得できない場合、それは存在せず、最後に情報が取得できた時の状態にあると判断します。例えば、MRTG の処理に似ています。 | ||
- | |||
- | グラフのサンプルとして、以下の画像では 180 秒ごとに受け取ったデータを表示しています。 | ||
- | |||
- | {{ wiki: | ||
- | |||
- | 以下は、05: | ||
- | |||
- | {{ wiki: | ||
- | |||
- | Pandora FMS 1.3 では、新たにエージェント全般のグラフが導入されています。これは、接続性を表し、エージェントモジュールからのアクセス比を示しています。このグラフは、エージェントが稼働していてデータを受け取っている時に表示される他のグラフを補完するものです。以下は、通常サーバに接続しているエージェントの例です。 | ||
- | |||
- | {{ wiki: | ||
- | |||
- | もし、グラフにピークがある場合は、Pandora FMS エージェントと Pandora FMS サーバの接続において問題があるか、遅延が発生している可能性があります。ネットワークサーバからの接続においても問題が発生している可能性があります。 | ||
- | |||
- | Pandora のバージョン 5以降では、" | ||
- | |||
- | |||
- | {{ wiki: | ||
- | |||
- | |||
- | |||
- | === データベースにおけるインデックスの改良とその他技術的側面 === | ||
- | Pandora FMS データベースのリレーショナルモデルにおいて、小さな拡張を実装しました。導入した変更の一つは、モジュールの種類によるインデックス設定です。これにより、データへのアクセスが早くなりました。それにより、Pandora FMS エージェントがモニタリングしている全データをアップロードしやすくなりました。異なるソースのデータを細かく分割して提供されます。Pandora FMS の新バージョンでは、多くの種類の情報を処理できる 4つの種類の新しいサーバを計画しました。 | ||
- | |||
- | {{ wiki: | ||
- | |||
- | 最近のバージョンでは、過去データへのアクセスパフォーマンスをさらに向上させるために、テーブルのパーティショニング(タイム・スタンプによる)を推奨します。 | ||
- | |||
- | 我々はまた、時刻表記の数値表現 (UNIX フォーマットや、1970年1月からの経過秒数) のような要素を追加しました。日付の検索や比較などが高速化しています。これは、データ挿入における検索時間の拡張と考えることもできます。 | ||
- | |||
- | === データベースのメインテーブル === | ||
- | |||
- | <WRAP center round tip 60%> (2020年12月23日時点の) Pandora FMS データベース構造のより 詳細については、[[http:// | ||
- | |||
- | 以下に、ER図および、Pandora FMS データベースの主なテーブルの詳細説明を示します。残りのテーブルについても簡単に説明しています。 | ||
- | |||
- | {{ : | ||
- | |||
- | * **taddress**: | ||
- | * **taddress_agent**: | ||
- | * **tagente**: | ||
- | * // | ||
- | * //nombre//: エージェント名。(大文字・小文字を区別します) | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * //id_os//: エージェントの OS ID。(tconfig_os に関連) | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * **tagente_datos**: | ||
- | * **tagente_datos_inc**: | ||
- | * **tagente_datos_string**: | ||
- | * **tagente_estado**: | ||
- | * // | ||
- | * // | ||
- | * //datos//: 最新の受信データの値。 | ||
- | * // | ||
- | * //estado//: モジュールの状態で、0 正常、1 障害、2 警告、3 不明 です。 | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * **tagente_modulo**: | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * //nombre//: モジュール名 | ||
- | * //max//: モジュールの最大値。これより大きな値は、不正な値として認識されます。 | ||
- | * //min//: モジュールの最小値。これより小さな値は、不正な値として認識されます。 | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * //flag//: 強制実行フラグ。1 に設定されている場合、実行間隔に関係なく実行されます。 | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * **tagent_access**: | ||
- | * **talert_snmp**: | ||
- | * talert_commands**: | ||
- | |||
- | * **talert_templates**: | ||
- | * //id//: テンプレート ID。 | ||
- | * //name//: テンプレート名。 | ||
- | * // | ||
- | * // | ||
- | * //field1//: カスタマイズフィールド 1 (フリーテキスト) | ||
- | * //field2//: カスタマイズフィールド 2 (フリーテキスト) | ||
- | * //field3//: カスタマイズフィールド 3 (フリーテキスト) | ||
- | * //type//: アラートの状態別の種類。(' | ||
- | * //value//: regex の場合のアラートの値。(フリーテキスト) | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * //monday//: 1 の場合、アラートが月曜に有効になります。 | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * //friday//: 1 の場合、アラートが金曜に有効になります。 | ||
- | * // | ||
- | * //sunday//: 1 の場合、アラートが日曜に有効になります。 | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * **talert_template_modules**: | ||
- | * //id//: アラートのユニーク ID。 | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * // | ||
- | * **talert_template_module_actions**: | ||
- | * **talert_compound**: | ||
- | * **talert_compound_elements**: | ||
- | * **talert_compound_actions**: | ||
- | * **tattachment**: | ||
- | * **tconfig**: | ||
- | * **tconfig_os**: | ||
- | * **tevento**: | ||
- | * **tgrupo**: Pandora FMS に定義されているグループ。 | ||
- | * **tincidencia**: | ||
- | * **tlanguage**: | ||
- | * **tlink**: コンソールの下の方のメニューに表示されるリンク。 | ||
- | * **tnetwork_component**: | ||
- | * **tnetwork_component_group**: | ||
- | * **tnetwork_profile**: | ||
- | * **tnetwork_profile_component**: | ||
- | * **tnota**: インシデントに関連づけられたメモ。 | ||
- | * **torigen**: | ||
- | * **tperfil**: | ||
- | * **trecon_task**: | ||
- | * **tserver**: | ||
- | * **tsesion**: | ||
- | * **ttipo_modulo**: | ||
- | * **ttrap**: SNMP コンソールで受信したトラップ。 | ||
- | * **tusuario**: | ||
- | * **tusuario_perfil**: | ||
- | * **tnews**: コンソールに表示されるニュース。 | ||
- | * **tgraph**: コンソールで作成されたカスタムグラフ。 | ||
- | * **tgraph_source**: | ||
- | * **treport**: | ||
- | * **treport_content**: | ||
- | * **treport_content_sla_combined**: | ||
- | * **tlayout**: | ||
- | * **tlayout_data**: | ||
- | * **tplugin**: | ||
- | * **tmodule**: | ||
- | * **tserver_export**: | ||
- | * **tserver_export_data**: | ||
- | * **tplanned_downtime**: | ||
- | * **tplanned_downtime_agents**: | ||
- | |||
- | |||
- | === リアルタイムでのデータ圧縮 === | ||
- | データベースの高負荷を避けるために、データ挿入時にサーバは簡単な圧縮を行います。データが一つ前のデータと同じ場合や、24時間以内に変化が内場合は、データベースに保存されません。 | ||
- | |||
- | 例えば、だいたい 1時間の間隔で **0, | ||
- | |||
- | 以下のグラフでは、上記の例のデータを示しています。赤で示したデータのみがデータベースに保存されます。 | ||
- | |||
- | {{ wiki: | ||
- | |||
- | 圧縮は、データ処理のアルゴリズムに影響を与えます。グラフ描画では、圧縮により発生した空白のデータを埋める必要があるということを認識することが重要です。 | ||
- | |||
- | 以上を理解して、あるモジュールの実行間隔と最初のデータを使って、そのモジュールのデータを求めるためには、次のような手順を踏む必要があります。 | ||
- | |||
- | * 指定した間隔や日時よりも古いデータを検索します。見つかった場合は、それが現在の値になった最初のデータです。見つからなかった場合は、過去にデータは存在しません。 | ||
- | |||
- | * モジュールの実行タイミングと同じ日時まで、指定した間隔や日時よりも新しいデータを検索します。見つかった場合は、それが値が変化したタイミングのデータとなります。もし、見つからなかった場合は、最後に記録された値が現時点まで続いていることになります。 | ||
- | |||
- | * あるデータを特定するためには、それが可能となる他のデータを全て確認する必要があります。 | ||
- | |||
- | === データの削減 === | ||
- | Pandora FMS は、データベースに保存する情報を削減するシステムを持っています。これは中小規模のシステム(250-500エージェント、100, | ||
- | |||
- | 毎日実行される Pandora FMS データベースのメンテナンスで、古いデータを検索し削減します。この削減は、単純な線形補完を用いて行われます。つまり、一日に 10, | ||
- | |||
- | これは、明らかに情報が欠落します。なぜならば線形補完だからです。しかし、データベース容量を節約し、長期間(月次、年次)のグラフについては同じように見れます。大きなデータベースでは、これでもデータベースパフォーマンスが必要です。その場合はこれを使わずに、代わりにヒストリデータベースモデルを利用してください。 | ||
- | |||
- | === ヒストリデータベース === | ||
- | これは Enterprise 版の機能で、指定した時点からのデータを保存します。例えば、1ヶ月以上前のデータを異なるデータベースに保存します。このデータベースは、異なる物理サーバ上にあるべきです(これを仮想化しないでください!)。1年間のグラフを表示しようとした場合、Pandora FMS は、自動的に最初の XX 日を現在のメインのデータベースから取得し、他の情報をヒストリデータベースから取得します。これにより、大量のデータを保存している場合において、パフォーマンスの問題を避けることができます。 | ||
- | |||
- | これを設定するには、他のサーバにてヒストリデータベースの設定(Pandora FMS のデータベーススキーマをインポートし、データは入れる必要ありません)とメインの Pandora FMS サーバからのアクセスができるような設定を手動で行う必要があります。 | ||
- | |||
- | **セットアップ(Setup)** -> **セットアップ(Setup)** -> **ヒストリデータベース(Historical database)** へ行き、そこでヒストリデータベースへアクセスするための設定を行います。 | ||
- | |||
- | |||
- | |||
- | {{ wiki: | ||
- | |||
- | |||
- | |||
- | |||
- | 必要な設定項目について以下に説明します。 | ||
- | |||
- | **Days** | ||
- | |||
- | | ||
- | |||
- | **Rate** | ||
- | |||
- | | ||
- | |||
- | **Delay** | ||
- | |||
- | // | ||
- | |||
- | == 詳細設定 == | ||
- | Pandora FMS のデフォルト設定では、文字列タイプデータをヒストリデータベースへ転送しません。しかしながら、この設定を変更してヒストリデータベースにこのタイプの情報が送られている場合は、 パフォーマンスに悪影響を与えるだけでなく、大きな問題を引き起こすことになります。 | ||
- | |||
- | このパラメータを設定するには、データベースで直接クエリを実行して、この情報を削除する日数を決定する必要があります。関係するのは、テーブル //tconfig// とフィールド // | ||
- | |||
- | UPDATE tconfig SET value = 30 WHERE token = " | ||
- | |||
- | データベースは、スクリプト '' | ||
- | |||
- | {{ wiki: | ||
- | |||
- | これをテストするには、データベースメンテナンススクリプトを手動実行します。 | ||
- | |||
- | / | ||
- | |||
- | エラーが出ないことが正常です。別のインスタンスがデータベースを使用している場合は、'' | ||
- | |||
- | ==== Pandora FMS におけるモジュールの状態 ==== | ||
- | Pandora FMS では、モジュールは、不明、正常、警告、障害や、アラート発生といった状態を持ちます。 | ||
- | |||
- | === 状態はいつ変更されるのか === | ||
- | それぞれのモジュールには、警告や障害状態のしきい値の設定があります。これらのしきい値は、データの値によっていそれぞれの状態になるということを定義します。モジュールのデータがこれらのしきい値の範囲から外れれば、正常状態と認識されます。 | ||
- | |||
- | それぞれのモジュールには、データを収集する間隔の設定もあります。データ収集の間隔はコンソールで確認されます。もし、モジュールが収集間隔の 2倍の期間データを収集できなかった場合、そのモジュールは不明状態となります。 | ||
- | |||
- | 最後に、モジュールにアラート設定があり、アラートが発生し承諾されていなければ、モジュールはアラート発生状態となります。 | ||
- | |||
- | === 伝播と優先度 === | ||
- | Pandora の仕組においては、いくつかの要素は他に依存しています。たとえば、一つのエージェントにおけるモジュールや、一つのグループにおけるエージェントです。これらはまた、Pandora FMS エンタープライズポリシーに適用することができます。ポリシーは、個々のエージェントに割り当てられたもののように、いくつかのエージェントおよびモジュールを関連付けることができます。 | ||
- | |||
- | この構造は、モジュールの状態を簡単に評価するには特に便利です。これにより、エージェント、グループ、およびポリシーの状態を仕組の中で伝播していくことができます。 | ||
- | |||
- | == エージェントがとりうる状態 == | ||
- | エージェントの状態は、モジュールの状態の中で最も悪い状態を採用します。グループの状態は、それに属するエージェントの中で最も悪い状態を採用します。そして、ポリシーの状態も同様で、割り当てられたエージェントの最も悪い状態を採用します。 | ||
- | |||
- | これにより、たとえば、障害状態の一つのグループを見ることによって、そこに属する少なくとも一つのエージェントがそれと同じ状態であることがわかります。それを特定したら、上位レベルへ障害状態を伝播させる原因となったモジュールへと、細かいレベルへの情報へ掘り下げていくことができます。 | ||
- | |||
- | == ステータスポリシー == | ||
- | 正常ではない状態が複数発生している場合、どれが最も重要かを判断する必要があります。そのために優先順位のリストがあり、1番目の状態が他よりも最も優先順位が高く、最後のものが優先順位が低くなっています。すべての要素でいずれかが表示されます。 | ||
- | |||
- | - アラート発生 | ||
- | - 障害状態 | ||
- | - 警告状態 | ||
- | - 不明状態 | ||
- | - 正常状態 | ||
- | |||
- | |||
- | |||
- | アラートが発生した場合、その状態は他よりも優先順位が高く、エージェントもこの状態となり、またこのエージェントが属するグループもこの状態となることがわかります。 | ||
- | |||
- | 言い換えると、例えば一つのグループが正常状態であれば、そのグループの全エージェントは正常状態であり、全てのモジュールが正常状態であるといえます。 | ||
- | |||
- | === カラーコード === | ||
- | それぞれの状態には、何かが正常に動作していないことをネットワークマップで簡単に表示できるように、色が設定されています。 | ||
- | |||
- | |||
- | {{wiki: | ||
- | |||
- | {{wiki: | ||
- | |||
- | {{wiki: | ||
- | |||
- | {{wiki: | ||
- | |||
- | {{wiki: | ||
- | |||
- | |||
- | ==== Pandora FMS グラフ ==== | ||
- | グラフは、Pandora FMS の実装において最も複雑なもののひとつです。なぜなら、DB からリアルタイムで情報を収集していて(rrdtool などの)外部のツールは利用していないためです。 | ||
- | |||
- | グラフにはいくつかの動きがあり、それはデータのタイプに依存します。 | ||
- | |||
- | * **非同期モジュール**. データ圧縮が無いことを想定します。DB に保存されているデータは、すべて実際に収集されたデータです(圧縮がないため)。 抜けなく正確なグラフが生成されます。 | ||
- | * **文字列モジュール**. 取集したデータのレートを表示します。 | ||
- | * **数値モジュール**. ほとんどのモジュールはそのデータを表示します。 | ||
- | * **Boolean モジュール**. ping のチェックやインタフェースの状態などの *PROC モジュールでは、数値データになります。0 は、障害を、1 は正常を意味します。 | ||
- | |||
- | === 圧縮 === | ||
- | 圧縮は、グラフがどう表示されるかに影響します。同じ値の 2つのデータを受信した場合、Pandora は新しい方のデータは保存しません。しかし、他の値が存在しない場合は、最後の値をその時間のデータとして使います。グラフを描画するとき、グラフの開始時点で参照する値がない場合は、Pandora はリファレンスとして参照できる値を 48時間までさかのぼって検索します。何もみつからない場合は、0 で開始します。 | ||
- | |||
- | 非同期モジュールでは、圧縮はされていませんが、同じようにさかのぼって検索する動作を行います。 | ||
- | |||
- | === 補間 === | ||
- | グラフを構成するとき、Pandora は 50xN サンプルを利用します。N はグラフの解像度(この値は設定で定義できます)です。データを 300秒(5分)間隔で収集している場合、1時間に 12のデータがあり、1日では 12x24 = 288 のデータがあります。1日のグラフを表示する場合、288個の値を表示するわけではありません。圧縮や補間をして、50x3 = 150 のデータを利用します(デフォルトでは、Pandora のグラフ解像度は 3 です)。 | ||
- | |||
- | これは、精度といくつかのデータを失うことを意味します。そして、保持しているサンプルが多ければ多いほど、より多く失うことになります。 しかし、これは、異なる間隔または拡大率でグラフィックを作成することにより回避できます。 | ||
- | |||
- | {{ wiki: | ||
- | |||
- | |||
- | |||
- | **通常のグラフ**では、補間は簡単な方法で実装されています。間隔内に 2つのデータがある場合(例のB)は、平均をとってそれを表示します。 | ||
- | |||
- | **boolean グラフ**では、複数データ(1または0のみ)がある場合、悲観的なアプローチをとり 0を表示します。これにより、間隔内の障害状態をわかりやすくし、正常状態よりも障害状態の表示を優先します。 | ||
- | |||
- | 両方の場合において、データが存在しない場合(圧縮されているか取得できていない場合)は、その前のタイミングでの最新の収集データを表示に利用します。上記の例の E の ような場合です。 | ||
- | |||
- | === 平均/ | ||
- | {{ wiki: | ||
- | |||
- | |||
- | デフォルトでグラフは、平均、最大および最小値を表示します。サンプル(" | ||