Pandora FMS アーキテクチャ

Pandora FMS アーキテクチャ

この章では Pandora FMS のコンポーネントの一般的な説明をします。インフラの構成によって異なるさまざまな課題を解決するために、どのように Pandora FMS のアーキテクチャを利用するかです。

Pandora FMS は、モジュール式で分散型にすることも、シンプルでモノリシックにすることもできます。最も重要なコンポーネントは、すべての情報が保存されている MySQL データベース です。 Pandora FMS の各コンポーネントは複製でき、パッシブ、アクティブ、またはクラスタ環境(アクティブ/アクティブな負荷分散) など、完全な HA環境で動作します。。

Pandora FMS' Architecture

Pandora FMS はいくつかの要素で構成されており、その中には、データの収集と処理を担当する要素、つまり サーバ が含まれます。 サーバは、サーバ自体またはエージェントによって生成された情報を使用して、データベースにデータを入力します。コンソールは、データベースに存在するデータの表示とエンドユーザとの対話を担当する部分です。ソフトウェアエージェントは、監視対象システムで実行されるアプリケーションであり、情報を収集して Pandora FMS サーバに送信します。

Pandora FMS サーバ

Pandora FMS は、その中に合計 12 の異なるサーバがあり、それぞれが必要なさまざまなタスクに特化た責任を負っています。サーバは、'Pandora Server' という全体を表す名前で単一のアプリケーションに統合されます。これは、Pandora FMS のインスタンスまたは機能に特化したサーバをそれぞれ異なるサブプロセス(スレッド)で実行するマルチスレッドアプリケーション(マルチプロセッシング)です。詳細については、ビデオチュートリアル «Server monitoring software» を参照してください。 ここに、さまざまな機能に特化した Pandora FMS サーバの説明があります。

Pandora FMS サーバは、適切な監視の実行を担当する要素です。それらは実行結果を検証し、結果に応じてステータスを変更します。また、データの状態を監視するように設定されたアラートを発報する役割もあります。

Pandora FMS データサーバは、高可用性を持ち負荷分散して動作することができます。 非常に大規模なアーキテクチャでは、複数のサーバを同時に使用して大量の情報を処理することが可能であり、地理的または機能的なゾーンに分けて分散される場合があります。

Pandora FMS サーバは常に動作しており、監視対象の要素に問題が発生していないかどうかを確認し、アラートとして定義されている場合は適切なアクションを実行できます。問題が発生すると、SMS、電子メールの送信、スクリプトの実行など、アラートで定義された処理を実行します。

同時に複数のサーバが存在する場合があります。そのうちの 1つはメインサーバで、残りのサーバはスレーブです。 マスターサーバとスレーブサーバの関係がありますが、それらは同時に機能します。 2つの違いは、同じタイプのサーバ(ネットワークサーバなど)がダウンしている場合、マスターサーバがダウンしているサーバに関連付けられているすべてのデータの処理を担当することです。

エージェントからデータファイルを受信するサーバ、または情報を処理するサーバ(これがリモートタイプの場合)は、データの処理後に関連するアラートを発報させるサーバです。

Pandora FMS は、各サーバのステータス、負荷レベル、およびその他のパラメータを自動的に管理します。 ユーザは、Web コンソールのサーバ管理を介して各サーバの状態を確認できます。

Enterprise 版WEBチェックサーバ(Goliat)、エクスポートサーバ、インベントリサーバ、イベント相関サーバ、および Enterprise ネットワークサーバは、Pandora FMS Enterprise 版でのみ使用できます。

データ(Data)サーバ

ソフトウエアエージェントから送信されるデータを処理します。ソフトウエアエージェントからは、XML データがサーバに送信(FTP, SSH, Tentacle のいずれかのプロトコル)され、サーバはその新たなデータファイルを確認・処理します。このプロセスは、処理するデータを “キュー” として貯めるハードディスク上のディレクトリを利用します。 異なるデータサーバを、異なるシステムや同一のホスト(仮想サーバなど)にインストールすることもできます。複数のサーバは、能力の高いハードウエア(たとえばマルチ CPU の環境など)が必要な巨大な環境において一緒に動作することができます。

データサーバは、Pandora FMS のデータベースにアクセスするためのサーバです。データベースは、ウェブサーバと共有しており多くのデータを保存しています。サーバはデーモンとして実行され、多くのデータを保存します。データサーバは、アラートやイベント生成の元となるすべてのエージェントの情報を処理するので、そのシンプルさとわずかな資源の消費にもかかわらず、システムの中で重要な機能となっています。データサーバは、ソフトウエアエージェントから送られてくる XML データの処理のみを実施します。リモートチェック(監視)などは行いません。

ネットワーク(Network)サーバ

ネットワークサーバは、ICMP テスト(Ping, 応答時間)、TCP および SNMP リクエストなど、リモートモニタリングタスクを実行します。エージェントがサーバに割り当てられるときは、ネットワークサーバに割り当てられ、データサーバには割り当てられません。ネットワークの応答確認はネットワークサーバが実行するため、モニタリング処理はネットワークサーバに割り当てられるということが重要だからです。ネットワークサーバが選択した監視対象に接続できるようにする必要があります。

例えば、192.168.2.0/24 上の監視サーバで、192.168.1.1 への ping 疎通確認のモジュールを作成した場合、監視サーバが 192.168.1.0/24 にはアクセスできないため、ダウン状態となります。

SNMP サーバ (SNMP Trap コンソール)

このサーバは、snmptrapd デーモンが受信したトラップを扱います。このデーモンは SNMP トラップを受信し、Pandora FMS の SNMP サーバはそれをデータベースに保存します。それらを分析して、Pandora FMS の SNMP コンソールにおいて、アラートの定義を行うこともできます。

WMI サーバ

frame

WMI は、Microsoft Windows 環境におけるオペレーティングシステムおよびアプリケーションの情報を取得するための、Microsoft 標準です。Pandora FMS には、ネイティブ WMI 呼び出しを実施するための専用サーバがあります。これにより、リモートからエージェントレスで Windows システムのデータを収集することができます。

自動検出(Recognition)サーバ

自動検出(Recon)サーバは、ネットワーク探索および新たなネットワーク上のシステムを検出するために利用します。自動検出サーバは、システムを検出するためにモニタリングのためのテンプレートを適用することもできます。また、新たなシステムをモニタリングできるように、テンプレートに定義されたデフォルトのモジュールを自動的に適用することもできます。 システムアプリケーションの nmap, xprobe, traceroute を利用して、オペレーティングシステムや開いているポート、すでに認識しているシステムを利用したネットワークトポロジによって、システムを特定することができます。

自動検出サーバは、スケジュールされたタスクを起動し、仮想環境、クラウド、データベース、または監視を開始する前にあらゆる存在するアプリケーションや環境を検出するためにも使用されます。

プラグイン(Plugin)サーバ

任意の言語で独自に開発した監視コマンドを、Pandora FMS のインタフェースから組み込み、統合管理できます。これにより Pandora FMS にユーザ自身が開発した、複雑な監視の仕組みや追加機能を組み込むことができるようになっています。

予測(Prediction)サーバ

これは、これまでに収集したデータ(最大 30日間のデータの 4つの値)を元にしてデータ予測を行う小さな AI (人工知能)のコンポーネントです。10〜15分間隔で数値データの予測を行い、これまでに収集したデータと比較して異常を検出します。基本的に、一週間ごとに動的な基準値を生成します。 このサーバは、Pandora FMS 5.0 からはサービスモニタリング(BPM)の計算も管理します。

ウェブサーバ(Goliat)

Enterprise 版

ウェブサーバは、ウェブアクセスのテストに利用します。ウェブ全体のチェック、ユーザ認証、フォームへのデータ入力、コンテンツチェック、メニューの確認等、組み合わせのチェックが可能です。応答があるか無いかのチェックおよび、全体(画像、全テキストなど)の表示時間の取得ができます。

エクスポート(Export)サーバ

Enterprise 版

frame

Pandora FMS のエクスポートサーバは、Pandora FMS のモニタデータを他のサーバにコピーすることができます。これは、複数の Pandora FMS が動作している大きな環境で、重要な情報を一カ所に集めたい場合に便利です。

インベントリ(Inventory)サーバ

Enterprise 版

インベントリサーバは、インストールされているソフトウエア、インストールされているパッチ、搭載されているメモリチップ、ハードディスク、システムで稼働しているサービスなど、システムのインベントリ情報を収集・可視化することができます。これらの情報は、リモートおよび、ソフトウエアエージェントを通してローカルで取得できます。

イベント関連付(Event correlation)サーバ

Enterprise 版

frame

イベントの関連付けでアラートを生成できる特別なサーバです。これは他のサーバとは違ってモニタは行わない、起動時に設定する特別なサーバです。このサーバは他のサーバとは違いスレッドや冗長化設定はありません。

エンタープライズネットワーク(Enterprise Network)サーバ SNMP & ICMP 用

Enterprise 版

オープンソースバージョンよりも高いパフォーマンスで ICMP (ping) および SNMP (ポーリング) を実行するための追加の拡張サーバがあります。(特に SNMPで) いくつかのリクエストは、事前にサーバに該当 OID があるかを確認したうえで実行します。

効率的にブロック単位で監視ができるような、サーバの TCP/IP スタックにアクセスするためのバイナリツールを利用します。

サテライトサーバ

Enterprise 版

サテライトサーバは特別なサーバで、エージェントとサーバの間の中間でリモート監視を行います。また、自動検出サーバのように新たなシステムを検出し、リモートプラグインを実行します。中央データベースへの接続は必要としません。代わりに、データサーバへ XML データを送信します。より詳細については、サテライトサーバによる分散監視 を参照してください。

WUX サーバ

Enterprise 版

frame

Selenium Grid と組み合わせたサーバで、複雑なウェブアクセスを再現する監視を分散して実行することができます。シンプルなウェブチェック(Goliat)と異なり、実際のブラウザで実行されます。また、ウェブアクセスのステップごとの実行結果、詳細な統計情報が表示され、エラー画面のキャプチャもあります。

Syslog サーバ

Versión Enterprise.

Log server

このコンポーネントにより、Pandora FMS はサーバ上の syslog を分析し、その内容を分析して対応する ElasticSearch サーバに保存できます。

Syslog サーバの主な利点は、ログの統合を補完することです。Linux® および Unix® 環境の Syslog サーバからエクスポートされた Syslog を、ログの発生元がどこであるかに関係なく単一の共通ポイント(Pandora FMS コンソールログビューアー)で検索しチェックできます。

トランザクションサーバ

Versión Enterprise.

Transactional serverバージョン 7 の Pandora FMS からは、ビジネスプロセス監視 ができます。このバージョンで実装された トランザクションサーバのコンポーネントを使用すると、ユーザが定義した設計に従って、他のタスクに依存するタスクを実行できます。これは、特定の時間に対象をチェックするために、さまざまな実行を調整できることを意味します。

Pandora FMS ウェブコンソール

これは、Pandora FMS のユーザインタフェースです。この管理およびオペレーションコンソールは、それぞれのユーザに別の権限を設定することが可能で、エージェントの状態の操作、状態の参照、グラフおよびデータの生成、さらにはシステムに組み込まれているインシデント管理までできます。また、レポートの生成や、新たなモジュール、エージェント、アラートおよび、ユーザの作成やポリシー設定を行うことができます。

ウェブコンソールは PHP で書かれており、ユーザによる他の追加ソフトウエアのインストールを必要としません。ブラウザには、HTML および CSS をサポートした最近のものが必要で、Firefox 2.x 以上または Chrome をお勧めします。これまでの経験によると、IE6 は機能不足であり必要な機能が動作しません。

ウェブコンソールは複数のサーバで動作させることが可能です。ロードバランシングや配置の問題(巨大なネットワーク、多くの異なるユーザグループ、地理的な違い、管理の違いなど)に対してアクセスを簡単にするように、多くのウェブコンソールを立てることができます。唯一の条件は、Pandora FMS のデータ、つまりデータベースにアクセスできることです。エンタープライズ版の場合は、(NFS経由で)エージェント設定リポジトリにもアクセスできる必要があります。

Pandora FMS データベース

Pandora FMSは、さまざまなソースのすべてのデータを受信し、正規化してリアルタイム MySQL データベースに保存しています。これは、Pandora FMS のインストールで最も重要なコンポーネントであり、情報や履歴データだけでなく、設定情報も含みます。 以前は PostgreSQL と Oracle がサポートされていましたが、現在は MySQL/MariaDB/Percona のみがサポートされています。

//データベースは Pandora FMS のコアです。//

これらのデータは、データベースの定期的な自動メンテナンスが実行されることで Pandora FMS により自動的に管理されます。そのために、Pandora FMS では、データベース管理者、手動オペレータや管理者を必要としません。一定期間(デフォルトでは 30日)が経過した後にデータを圧縮し、さらにまた一定期間が経過(デフォルトでは 90日)した後にデータを削除します。

Pandora FMS のソフトウエアエージェント

Pandora FMS のエージェントと言った場合、次の 2つを区別することが重要です。* エージェント: コンテナとして、コンソール上で表示されるエージェント* ソフトウエアエージェント: コンピュータ上で実行するソフトウエア

エージェント

Pandora FMS で単純に「エージェント」と言った場合、それはウェブコンソールで作成したモニタ・管理対象を指します。それは、モジュールのグループ(または個々のモニタリング要素)に関連付けられています。そのため、このエージェントは、(オプションで) 1つ以上の IP アドレスに関連付けることが可能です。

エージェントは、ネットワーク、WMI、プラグイン等のサーバを利用して、リモートモジュールに関連付け可能です。

  • 管理対象が起動しオンライン状態であるかどうかの確認 (PING)
  • 管理対象が起動しオンライン状態であるかどうかの確認 (PING)
  • 特定ポートの応答による、ウェブサイトが稼働しているかどうかの確認
  • 特定ポートおよび期待する応答による、ウェブサイトが稼働しているかどうかの確認
  • SNMP (MIB の利用)経由でのハードウエアの確認
  • 管理対象と Pandora FMS サーバの間の通信遅延の確認

エージェントはまた、ローカルモジュールとの関連付けを持つこともできます。これらはソフトウエアエージェントの設定で定義したり、ウェブコンソールのエージェント設定で定義します。最初にエージェントからデータパケットが送られてきた時、学習モード(デフォルト)であれば、これらのローカルモジュールがウェブコンソール上に自動的に設定されます。 したがって、「エージェント」は、リモートもしくはローカルのいずれかのモジュールを含むことが可能です。リモートモジュールはネットワークサーバ等からリモートで情報を取得し、ローカルモジュールはデータサーバによって情報を取得します。

ソフトウエアエージェント

ソフトウエアエージェントは監視対象のコンピュータにインストールされるものであり、それが動作しているマシンの情報をローカルで取得します。主に、サーバリソース(CPU、メモリ、ディスクなど)およびインストールされたアプリケーション(MySQL, Apache, JBoss など)を監視します。一般的にサーバの監視はソフトウエアエージェントで実施し、ネットワーク機器は何らかのソフトウエアのインストールは無しでリモートから監視を行います。

//Pandora FMS グローバルアーキテクチャの概要//

それぞれのソフトウエアエージェントは、モジュールと呼ばれる複数のチェックを実施します。それぞれが、CPU 使用率といった特定のデータに紐づけられます。すべての監視結果のデータは、一つの XML フォーマットのファイルにまとめられ、Pandora FMS サーバへ送られます。

エージェントからサーバへのデータのコピー処理は、通常定期的に実施されます。この 間隔 はソフトウエアエージェントにて定義され、ソフトウエアエージェントがサーバに対して通信を開始します。

間隔は、最大 300秒まで設定できます。つまり 5分です。100(秒)未満の値はお勧めしません。サーバのパフォーマンスに影響を与える可能性があります。細かいポーリング間隔は、データベースおよびシステムの処理に過負荷をかけることがあります。

Pandora FMS はリアルタイムシステムではない ということを認識しておくことが重要です。リアルタイム性が重要な要素ではない環境におけるシステムおよびアプリケーションの一般的な監視システムです。3〜5秒の応答時間を要求する環境の運用に適しています。

Illustration: Logical diagram of an agent, physical agent 図: エージェントおよび物理エージェントの論理構成

パケットの転送は、Tentacle プロトコルにより実行されます。SSH や FTP を利用することも可能です。

ネットワークを通してパスワード無しの非暗号化データが流れるため、SSH を利用して Tentacle を暗号化することも可能です。エージェントとサーバの間の接続においてセキュリティが保証されます。SCP(SSH) および Tentacle プロトコルを用いての自動転送のための、キー生成プロセスは、エージェントとサーバのインストールおよび設定のドキュメントにて詳細を説明しています。

転送はまた、FTP やその他ファイル転送システムにより実行することも可能です。Tentacle は、ユーザが信頼できる等、システムのセキュリティが確保されている場合に選択可能です。

他のプロトコルによる転送設定については、補足ドキュメントを参照ください。

Pandora FMS のエージェントは、それがインストールされたマシンから他のホストにアクセスするようなデータ収集も可能です。これをサテライトエージェントと呼びます。

複数の Pandora FMS エージェントを持つように設定することも可能です。これは、たとえば、ソフトウエアエージェントとサテライトエージェントがあるようなまれなケースです。基本的なソフトウエアエージェントはそれが動作しているマシンをモニタし、サテライトエージェントは、telnet や SNMP その他コマンドにてリモートのシステムをモニタするように設定されます。

XML データファイル

データファイルは XML 構造となっており、ファイル名はホスト名またはエージェントの場所、それぞれのデータファイルごとの異なるシリアル番号および、データを意味する .data という拡張子を組み合わせてできています。

<ホスト名>.<シリアル番号>.data

//ソフトウェアエージェントモジュールの論理構造//

データファイルは、.data という拡張子があります。正当性確認用のファイルは、データファイルの MD5 ハッシュを含む “.checksum” という拡張子のファイルです。これにより、データが処理する前に書き換えられてないかを最終確認を行うことができます。

<ホスト名>.<シリアル番号>.checksum

エージェントによって生成される XML データファイルは、Pandora FMS の心臓部です。それには、エージェントが収集した情報が含まれています。このデータパケットは、Pandora FMS エージェントを使う多くのユーザが、独自の開発をしたりデータの生成をして、Pandora FMS へ引き渡すことが簡単にできるように、コンパクトで、柔軟性が高く、軽いデザインになっています。

 <agent data os_name=”SunOS” os_version=”5.8” timestamp=”300” agent_name=”pdges01” version=”1.0”>
 <module>
 <name>FTP Daemon</name>
 <type>generic_proc</type>
 <data>0</data>
 </module>
 <module>
 <name>DiskFree</name>
 <type>generic_data</type>
 <data>5200000</data>
 </module>
 <module>
 <name>UsersConnected</name>
 <type>generic_data_inc</type>
 <data>119</data>
 </module>
 <module>
 <name>LastLogin</name>
 <type>generic_data_string</type>
 <data>slerena</data>
 </module>
 </agent_data>

トポロジ、スキーマ、監視モデル

モニタリングの処理には、ローカルとリモートの異なるモデルがあります。みなさんが分かりやすく問題解決ができるように、異なるトポロジで共通の例を示します。それぞれのソリューションは以降の章に記載しています。

アクセス可能な監視対象

これは標準的な構成ですが、集中型で体系化されています。これは最も実装が簡単なモデルです。

  • 集中リモート監視 Pandora サーバから全てのリモートシステムにアクセスできることを意味します。
  • エージェントベース監視 Pandora エージェントをインストールした監視対象から Pandora にアクセスできます。

アクセスが制限されたネットワーク

  • リモートネットワーク: これは、 Pandora FMS からリモートでの監視が到達できないネットワークです。この場合、いくつかのオプションがあります。ソフトウエアエージェントを、他のシステムをリモートで確認するために利用するか、リモート監視を実行でき拡張機能を持ったサテライトサーバを利用します。

//ブローカーモードでの直接アクセスができないリモート対象の実装モデル//

  • Pandora サーバにアクセスできないソフトウエアエージェント この場合、ソフトウエアエージェントのプロキシ機能を利用します。サーバに直接アクセスできないエージェントがそれを通してアクセスできるようになります。

//プロキシエージェントモードを使ったリモートアクセスの実装モデル//

  • 異なるネットワークに対するリモートサーバ監視: この場合、サテライトサーバ を使うこともできます。または、複数の Pandora FMS サーバを同じデータベースに接続させ、一つのサーバが特定の監視を実施し、もう一方が他の監視を実施します。設定方法は異なりますが、どちらの場合でもすべてのネットワークを監視でき、まとめてコンソールから管理できます。

//サテライトサーバを用いたリモートネットワーク監視モデル//

特別な組織構造

  • 異なる設定の監視システムで、複数の拠点を監視する必要性があっとします。この場合、個々の Pandora からのモニタリング情報を複製するエクスポート機能を利用します。

エクスポートサーバを使った階層構造モデル

  • 複数のレポート: 異なる Pandora サーバにデータを送るエージェントを設定することができます。ただし、管理は一つから可能です。
  • 分散管理: 必要な時に別の担当者で監視内容を分散管理する必要がある場合に便利です。これは、構成というより管理が重要です。管理ポリシーの権限設定によって調整します。

大規模環境

  • 数千もの監視項目がある大規模環境では、異なるリモートモニタリング手法を利用します。(50,000以上の)大量の監視項目では、一台のサーバに集約することができません。そのため、異なるサーバをリモート監視を分散するブローカーモードで利用します。

//ブローカーモードのエージェントを使ったリモート監視の分散モデル//

プライマリサーバのハードウエアが故障した場合にそなえて、冗長化の設定が必要です。 2つのサーバを用意し、一方が停止したときにアクティブになるように一台はスタンバイ状態にしておきます。そうするにはいくつかの手法があります。

  • 大規模システムの監視と集中管理(2500エージェント以上)が必要な場合、そのためには、'メタコンソール'でまとめた異なる Pandora サーバを設定します。これにより、リニアにシステムを拡張できます。

Enterprise 版

//メタコンソールモデル//

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