Pandora FMS の概要

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

Pandora FMS は、すべての環境を対象とした監視ソフトウエアです。“監視” という言葉には広い意味があり、特定の環境に適用できる数百ものツールがあり、その言葉の利用には危険性があります。小さなオフィスで 2台のプリンタを監視するのと、何千ものインタフェースや何千ものサーバがあるデータセンタにおける大量のトラフィックがあるスイッチを監視することは異なります。

Pandora FMS どのような環境や組織にも適用できるように設計しています。主な狙いは、他の監視ツールのように時間や費用をかけずにインフラを管理、操作するのに十分な柔軟性があることです。

FMS は、Flexible Monitoring System (フレキシブルモニタリングシステム)の略です。目的は、アクセスしにくかったり互換性が低かったりする中で、複雑かつ新たなツール、システム、古い要素いずれも一つのプラットフォームで監視できることです。

Pandora FMS は現在、市場に出回っているすべての最新のオペレーティングシステム用のエージェントがあります。監視対象システムにインストールされたソフトウェアで、“ソフトウエアエージェント” と呼びます。そのシステムの情報を抽出して Pandora FMS サーバにそれを送ります。

Pandora FMS はもちろん、システムの監視ツールとして使えるだけでなく、SNMP、TCP プロトコル(ftp, dns, http, https など)、ICMP、UDP を使ってネットワークデバイスの監視にも利用できます。

強力で柔軟性があるために、必然的に設定は難しくなります。Pandora のほとんどの設定は GUI でできますが、最初は複雑に見える利用方法を覚える必要があります。そのため、800ページにもおよぶユーザーズガイドをいくつかの章に分けています。

• 第1章: Pandora FMS の理解
• 第2章: インストールと設定
• 第3章: Pandora FMS でのモニタリング
• 第4章: Pandora FMS の操作と管理
• 第5章: 複雑な環境とパフォーマンスの最適化
• 第6章: 技術付録情報
• 第7章: 技術参考資料

公式ドキュメントに加えて、我々の ユーザフォーラム も利用できます。英語、スペイン語、日本語で投稿できます。Pandora FMS 開発者による公式トレーニングが必要な場合は、公式トレーニングプログラムもあります。

Pandora FMS の設定および、Pandora のツールを使って簡単なモニタリング設定を行うための、いくつかのクイックリファレンスである クイックガイド も用意しています。Windows および Linux のソフトウエアエージェントをインストールするためのクイックリファレンスマニュアルもあります。

より詳細の情報は、我々のウェブサイト http://pandorafms.com を参照してください。

Pandora は、2003年に Sancho Lerena によってつくられました。それ以来、我々が今日提供している柔軟性があり革新的なモニタリングツールとして進化してきました。

オリジナルは 100% オープンソースのコードとして書かれています。年を追うごとに経験を積み重ね、大きな企業からのプロダクトに対する強い要求から、エンタープライズ版の必要性を感じました。このバージョンでは、大量の情報処理や何千ものデバイスで動作できるよう要求される条件下において、いくつかの特徴的な機能が実装されています。

Pandora FMS の開発の資金面や調整のサポートは、Pandora の開発者によって 2005年に設立された Artica ST というスペインの会社で行っています。

Pandora FMS は最近、Sourceforge において、世界中で数千のダウンロード数およびユーザの満足で上位に現れています。Pandora の進化およびプロジェクトのロードマップの詳細は、https://pandorafms.com/ja/roadmap/ を参照してください。

• 自動検出(ローカル) Pandora エージェントのデフォルトの監視で、ハードディスク、パーティション、データベースサーバにおけるデータベース、その他を検出できます。

• 自動検出(リモート) リモートでネットワークを使って、稼働中のシステムや OS およびモニタリングできる設定などの関連情報を検出することができます。また、ネットワークトポロジーの検出および、ルーティングに基づくネットワーク図を作成することができます。

• モニタリング Pandora FMS のエージェントは最も強力です。基本的なコマンドの実行結果や Windows API から、イベント、ログ、数値データ、プロセスの状態、メモリやCPUの使用率などの情報を取得することができます。Pandora にはデフォルトでモニタリング用のライブラリがあります。しかし、Pandora の最大の利点は、新たなモニタリングを作成し追加できることにあります。

• コントロール エージェントはそれ自身でサービスを有効化したり、テンポラリファイルを削除したり、プロセスを実行したりできます。コンソールからリモートでサービスの停止・起動などのコマンド実行も可能です。さらに、指定した時間にタスクを実行することもできます。eHorus を用いて Pandora FMS からリモートのシステムにアクセスすることや、ウェブインタフェースから telnet や ssh のツールを利用することも可能です。

• アラートと警告 通知は障害検出と同様に重要です。Pandora は、ほぼ無限の通知方法とフォーマットを提供します。エスカレーション、アラートの関連、イベントの依存関係による集約なども制限なしで含みます。

• 分析と表示 モニタリングは trap を受信したりダウンしているサービスを表示したりするだけではありません。予測レポートや、長期間収集したデータの関連グラフを出すことができ、ユーザポータルとして第三者に提供したり、独自のグラフや表の定義を作成できます。

• インベントリ生成 一般なソリューションとして構成管理ツールがありますが、Pandora ではこれがオプションとしてついています。インベントリは柔軟で動的です(自動検出可能で、リモート入力等も可能です)。変更(ソフトウエアのアンインストールなど)を通知するために利用したり、単純に一覧を生成するために利用したりできます。

全てのソフトウエアでは、最初、テキストファイル、データベース、プロトコルなどの設定を説明しています。そこでは、全ての機能ではなく、何を設定するとどうなるかといった最低限の設定方法を学びます。この章では、モニタリングの概念とそのためのソフトウエアの利用について、簡潔に、ただし体系だって説明します。

'どのような要素があるのか'というと、サーバ、データベース、ウェブですが、次のような疑問が出てくるでしょう。

1. .どのように情報を取得するのでしょうか。何か必要でしょうか。決まった方法があるのでしょうか。
2. .定常的に問い合わせをするのでしょうか、それとも何かデータが来るのを待っているのでしょうか。
3. .情報からは何を得られるのでしょうか。グラフを見たり、進捗を見たりできるのでしょうか。

最初の質問に対する回答は、エージェントを使ってその機器の内部からモニタリングを行うか、インターネット接続で外部からモニタリングを行うかです。一種類の方法でデバイスのモニタリングを行うシステムもありますが、Pandora FMS は全てのモデルをサポートしています。

2つ目の質問は、モニタリングが同期(値が変わったかどうかに関わらず決まった秒間隔で情報を収集)か非同期(値が変わった場合のみ情報を収集)かに関連しています。もし、1000万の項目に対して同期モニタリングを 5分間隔で利用している場合は、かなりの負荷になります。しかし、50分間隔であれば余裕ができます。間の値を調整することもできます。もし、非同期モニタリング (SNMP トラップやログ) を利用しているのであれば、多くのリソースを節約できます。しかし、発生したインシデントに関するものを除いて、推移を示すグラフを書くことができません。パフォーマンスやキャパシティに関する多くのツールはいずれかのモデルにもとづいています。イベント管理のツールもそうです。機能を変更することはできません。Pandora FMS では両方の仕組みをサポートしています。

3つ目の質問は、指定したタイミングで何を見たいかによります。テキストの情報(イベントの内容)、小数(グラフ描画可能)、シンプルな状態(ダウン・アップ)を見ることができます。異なる種類のデータの取り扱いができればより柔軟性があります。Pandora FMS は全ての種類のデータに対応しています。

これら 3つのパラダイムは、モニタリングツールの選択とともに、それぞれの環境の違いを意味します。どんな種類の情報が必要で、それを得るための最善策は何かを認識してください。どんな情報があって、どのようにモニタリングするかを計画してください。

リモートモニタリングと言った場合、Pandora FMS サーバが定期的にモニタしたいデバイスにポーリングをかけることを意味します。これは、監視対象デバイスにインストールされたエージェントによるローカルモニタリングではありません。

一般的に言えば、リモートからモニタリングする場合には次の 2つの目的があります。

• 生きているかどうかの確認 (例えば、インタフェースやシステムの応答)
• 値の取得 (例えば、ウェブトラフィックやアクティブな接続数)

同期モニタリングは、常に監視サーバから監視対象に対して同じ方向で行われます。

また、インシデントが発生した場合に警告を受信するような別の手法も存在します。これはリモートモニタリングでも非同期のモニタリングで、通常 SNMP trap で使います。

同期モニタリングは、通常、ウェブシステムで幅広く利用されている SNMP プロトコルを使って行われますが、Microsoft によってつくられた似たプロトコルである WMI を利用することもできます。

双方のプロトコルは同じような動作をします。基本的には、サーバが監視対象の 'SNMP エージェント' または、'WMI サービス' の指定した項目にリクエストを送信します。項目は SNMP および WMI では OID と呼ばれます。WMI では、WQL クエリによって特定されます。メモリの空き容量、ルータの接続数、指定したインタフェースのトラフィックなどを取得できます。

モニタリングが主にインターネット環境を対象としている場合、SNMP の詳細を知ることが重要です。SNMP はモニタリングツールで幅広く利用されています。SNMP を使った非同期のモニタリングもまた重要です。モニタリングツールと一緒に、SNMP デバイスベンダから提供された MIB ファイルを参照するための外部エクスプローラがあると良いでしょう。もちろん、デバイスは通常それ独自の OID を持っているため、調査するのが大変です。しかし、何千もの項目の中で必要なもののみを使えば良いです。

Windows サーバのモニタリングでエージェントをインストールしたくない場合は、WMI のリモートモニタリングが非常に強力で適しています。WMI インタフェースは、WMI と共に(SNMPよりも)強力です。Windows サーバのさまざまなデータ、状態、イベントを取得することができます。

Unix と Windows システムは、ともに SNMP に対応しています。しかし、取得できる情報は乏しく、OS で SNMP エージェントを設定し有効かする必要があります。これは、Pandora FMS のエージェントをインストールするより複雑です。

最後に、TCP や ICMP のチェックを使って対象をモニタリングすることもできます。ICMP は主に次の 2つの目的で使われます。

• 対象のシステムの応答確認 (ping)
• デバイスの応答遅延計測 (ミリ秒)

TCP テストでは、ウェブサーバが正しく応答するかを確認できます。また、メール(SMPT)サーバがメールを送れるかを確認できます。これらのタイプのテストは、ポートが開いているかどうかだけではなく、通信もテストできます。例えば、メール送信コマンドの応答が 0.K であることや、ウェブサーバからの応答が '200 OK' (HTTPプロトコルの正常応答) であることを確認できます。

デフォルトで TCP チェックのプラグインもあります。独自のチェックスクリプトを作成したり、既存のものに追加することも簡単にできます。Pandora FMS への統合には、複雑な構造や独自ライブラリを必要とするような API はありません。

ウェブトランザクションモニタリングもまた、特定のコンテンツを確認するリモートモニタリングですが、別の章で説明しています。

システムおよびアプリケーションに関して情報を収集する最も良い方法は、間違いなくそのシステム自身から取得することです。システム自身でコマンドを実行したり、システムのデータソースに対してクエリを実行したりすることができます。同じ仕組みでモニタリングしたいと考えます。これはつまり、システムやアプリケーションを監視するのに、コマンドやスクリプトを実行する必要があるということを意味します。そこで、このようなモニタリング処理を実行できるソフトウエアである Pandora エージェントを利用します。

Pandora FMS で使用される命名方法では、すべての情報を含むモニタリング対象の単位を 'エージェント' といい、情報を Pandora FMS サーバに送信するために対象にインストールしたソフトウエアを 'ソフトウエアエージェント' といいます。ソフトウエアエージェントは、定常的に対象システムで実行され、定期的に情報を提供します。

エージェントは、コマンドで情報を取得するほかに、インベントリ情報を取得するなど、ほかのこともできます。問題や障害が発生した場合に、指定したコマンドを実行してテンポラリファイルを削除するなどの動作を定義することもできます。

正確な特定の情報を取得するためには、モニタ対象のアプリケーションのマニュアルを参照する必要があります。一般的なモニタリングであっても、必要な情報にたどりつくのは簡単ではないからです。

Windows では、ほぼ無限の情報へのアクセス手法があります。WMI、パフォーマンスカウンタ、イベントログ、システムログ、レジストリ、コマンド、powershellスクリプト、API(Windows NT) などです。 実際、Microsoft のアーキテクチャはより強力で良いドキュメントがそろっていて、システムの情報を取得することが簡単なものの一つです。Unix/Linux システムでは、ソフトウエアエージェントでコマンドを実行することができ、シェルスクリプトでさまざまな情報を取得できます。

導入や設定を開始する前に、監視対象における技術的なキーポイントを把握しておくことが重要です。それにより、無駄な時間を浪費せずに、システム上の特定のデータに関する情報が何のためにあるのか、最大限に活用するにはどうすべきかが明確になります。

いくつかの質問に答えるために 5分使ってみてください。あなたの監視で必要なものは何でしょうか。

• 障害を避ける → 可用性
• 性能低下分析 → パフォーマンス
• 拡張評価 → キャパシティプランニング

それぞれの要素は、それぞれの側面があります。

可用性 ほとんどの場合、イベントベースの監視と必要に応じてリモート監視で十分な場面が多いでしょう。素早く展開が可能で比較的迅速に結果を得ることができます。 この場合に、SLA レポートが最も役立ちます。

パフォーマンス グラフや数値データが重要な要素です。エージェントまたはリモートから情報を取得します。エージェントでシステムのより深い情報をとる必要があるかもしれません。グループレポートおよび組み合わせグラフがポイントです。

キャパシティプランニング より独自性が高くなり、2つ目の件とどうようにデータの取得が必要です。ただし、それをもとに、予測監視やより特別な予想レポートを使います。エージェントからの初期のアラートは、警告や障害状態の意味を把握するのに必要です。問題が発生する前に防止するために、発生するイベントの管理(運用)ポリシーを策定します。これは、間違いなく最も複雑で興味深いパターンです。

どのモデルでいくかを決めたら、システムがサービスダウンやその他イベントを通知したときに何をするかを決めるのみです。サーバの能力が来週の金曜に限界に達したら何が起るでしょうか。対応手順を考える必要があります。

対応の手順を立てるためには、いくつかの要因を考慮する必要があります：

• イベントの緊急性: まれなものや致命的なものと、通常状態の区別
• 通知形態: email, sms, 音声アラートなど
• スケーリング: 問題が繰り返された後の違う形での報告。一般的なケースでは、問題の解決前に一定時間が経過したらマネージャーに通知するなどです。

設定を実施する前に、これらの概念について明確にし、監視方法、収集されたすべての情報をどのように処理するか、発生した問題をどう報告するかといった、重要な要素の計画を作成することをお勧めします。

まず、最も重要な問題に焦点を当てることで、組織にとって最も重要な問題は何かを定義する論理的な出発点に立つことができます。最も重要な要素が何であるかが分かったら、対象を監視する方法を定義し、そのシステムであがった問題を解決する担当者を考えます。適切な人々に問題の存在を通知する方法について説明します。

管理モデルによって、我々は監視システムが、自動的に情報をレポートするように設計され、人が直接または間接的に参照するシステムであることを理解できます。システムを参照する人は良くオペレータと呼ばれ、画面を見たり、スマートフォンや電子メール、何らかのツールでのログの参照などで、イベントを確認しています。どうやっているかというのは重要ではなく、重要なのはシステムがあるということです。

一方では、全体もしくはインフラにおけるシステム管理者と呼ばれる人がいます。彼らは何か発生したときにオペレータから「障害が発生しました」という連絡を受けたり、SMS や E-mail でシステムから自動送信される警告通知を受けます。

ここに、すでに大きな違いがあります。

• 直接管理モデルは、一人または複数の人が定常的にシステムを見ています。何か障害が発生すればすぐに検出されます。それはちょっとした通知でクリティカルなものではありません。また、より柔軟性があります。すべてのケースを通知 (Pandora でのアラート) する必要はありません。常にシステムで何が起っているかのイベント (状態の変化をみつけます) を参照すれば十分です。多くの画面を定義することができ、集約したアラートを定義することができます。このモデルは、ラートポリシーを定義することが重要ではなく、自動的な管理ができない大規模環境で利用されます。

• 間接管理モデル では、定常的に画面を見る人はいません。イベント、グラフ、マップは誰も見ていないため、自動的にシステムの状態を通知する設定を行う必要があります。このシステムはデバイスが少ない場合や、何が障害状態でどう対処するべきか明確な場合に適しています。

オペレータ、管理者、その上の人のチームワークにとって、Pandora FMS は、イベントのチケット化、インシデント作成、通知のエスカレーション、内部メール、掲示板、Pandora FMS ユーザ間のチャットなどとても便利です。

以降の章からは、完全に Pandora FMS についての内容です。ここまでは Pandora FMS を利用するにあたって、その前に知っておくべき重要なことについて述べてきました。あなたはすでに多くのことを知っているかもしれません。また、他の監視ツールを使っているかもしれません。常にアプリケーションを監視することが良いということは聞いていることでしょう。

しかし、我々の経験から、我々のノウハウを越えて、それぞれのユーザのみなさんには特定の方法が必要です。我々はあなたのインフラがどのように設定されているかを良く知っているわけではありません。モニタリングそのものは簡単で問題ではありません。大変なのは、監視にあなたのビジネスを適用するのではなく、あなたのビジネスに監視を適用することです。あなたの組織で Pandora FMS を使って最善の監視手法を見つけることは、本当のチャレンジです。