GroundWork Monitor 運用セオリー
目次 表示
GroundWork Monitor は、継続的に管理され非常に柔軟なモニタリングソリューションを低コストで提供するために、モジュラー化したオープンソース技術と統合情報管理サブシステムを組み合わせています。これは疎結合型コンポーネントベースのアーキテクチャを通して実現され、それによって、データ管理サービスの中核部分が収集と制御機能を提供し、独立した内蔵型の計測と可視化コンポーネントが特定のネットワークを管理するために必要な入出力サービスを提供します。このアプローチにより、GroundWork Monitor は安定した持続的モニタリング・プラットフォームを提供することができます。また、ほとんど上限無くモニタリングとレポーティングツールを個別コンポーネントとして導入することが可能です。
GroundWork Monitor は、鳥瞰図的な視点で言うと、下図に示すような明瞭な4つの層から成る抽象的情報モデルを使用します。まず、コンフィグレーション層はモニタリングの必要なネットワーク・リソースを定義し、また、モニタリングデータが収集された後どのように処理されるかを記述します。一度リソースが定義されると、業務固有の計測コンポーネント(インストゥルメンテーション(計測)層)がさまざまに異なるモニタリングインタフェースを通して、サンプリングデータを収集するために使用されます。その後、コレクション層内の統合ツールがデータを処理して格納するためにデータを拾い集めます。最後に、モデルの最上部にあるビジュアライゼーション(可視化)層内のアプリケーションが情報を参照し、ユーザに対して表示します。
この疎結合型コンポーネントベースのアプローチは、システム全体にわたる矛盾のない予測可能な手法でのデータフローを確実にし、管理しつつも拡張可能なフレームワークを提供します。GroundWork Monitor のユーザは、各々で特別のネットワーク環境のためにモニタリングとレポーティングのツールを配備することが認められています。そのようにして、顧客自らの環境の特別な必要性に適合させるための GroundWork Monitor を作り上げることができます。
図: 論理情報モデル
情報モデルはシステム全体にわたる情報の流れ方について考えるのに便利で、高度に抽象化した全体アーキテクチャを認識するのにも重要ですが、必ずしもシステムレベルのメカニズムを完全に描写するものではありません。
特にGroundWork Monitor は、それら自体の権限の中で自己充足している、多数の独立したオープンソースツールを多用するようにしています。しかしながらGroundWork Monitor は、これらのコンポーネントツールを固定のフレームワーク内に無理に入れるのではなく、構成要素のツールと技術をそれらのネーティブモードで運用できるようにし、そして統合技術を基に個別の独立コンポーネントを広大なモニタリングプラットホームの中で関連付けます。このアプローチは、個別コンポーネントの能力と可能性を保持しつつ、全体の情報フローが必要なレベルの機能性を実現することを保証します。
この概念を、一般的に使用されているコンポーネントツールとGroundWork Monitor の主要コンポーネントを図示している下記の図で説明します。この例からわかるように、GroundWork Monitor システムは業務固有の機能を行う多数の個別コンポーネントを持ち、情報管理ツールキットが個別のコンポーネントを調整し、統一・凝集されモニタリングプラットホームに必要な統合技術を提供します。
先に述べたように、論理情報モデルはシステム内の情報の流れがどのように成っているのかを理解するのに役立つリファレンスガイドとして使うことができ、それは多数のコンポーネントが関わったとしても同じです。使用されているコンポーネントの数に関わらず、まずリソースはコンフィグレーション・サブシステムによって記述されます。次にサンプリングデータはインストゥルメンテーション層のコンポーネントによって取り出され、コレクション層内で格納と処理をされます。最後にビジュアライゼーション層で一つ以上のツールによって表示のために読み出されます。
ソフトウェアのアーキテクチャ図を確かめるために情報モデルを使用すると、コンフィグレーション層がインストゥルメンテーション層とコレクション層を統制することがわかります。特に、この層はネットワークリソースの目録を作るのに責任を持ち、それが結果的にすべてのほかの層に影響します。また一方で、この層は実際の読取り結果を拾い集めるインストゥルメンテーション層により使用されるモニタリングコンポーネントを説明することを担い、また、コレクション層の中で結果データが最終的にどのように処理し格納されるかをコントロールする責任を持ちます。
図: ソフトウェアのアーキテクチャ
次に、コレクション層は個別のコンポーネントをひとつの密接したシステムに結び付けるのに必要な共有データベースと、統合ツールを組み込んでいます。このサブシステムの一部は、グローバルリソース定義(ホストやサービス資産)を格納するMySQLのテーブルと同様に、収集したデータ情報のためのMySQLテーブルを提供しますが、この層はいくつか個別コンポーネント固有のスタンドアロン・データベース(履歴グラフのための長期間のパフォーマンス情報を格納するラウンドロビン・データベースファイルなど)も含んでいます。データベースコンポーネント以外にも、この層には必要な統合業務(外部ログファイルからのデータ引出しや、個別コンポーネントへの構成情報変化の押出し)を果たすのに必要なツールのデータベース、また、共有データベースへのコントロールアクセスとシステム管理サービスを提供する開発ツールが含まれます。
最後に、スタックの最上部にはビジュアライゼーション層を形成する Webベースのアプリケーションが含まれます。 JBoss Portal はポータルの Web インタフェースをホスティングして提供する、コンテンツを提供管理するためオープンソースのスタンドアローン・ベース環境です。 JBoss Portalは GroundWork Monitor の Web アプリケーションをひとつの共通プレゼンテーションフレームワークに統合します。 GroundWork Monitor は、特定データベースの内容を表示する単一目的ツールから、同時に複数のソースからデータを取り込む複雑なアプリケーションまでの多彩な Web アプリケーションを包含し、必要に応じてリモートホストから完全に分離された Web アプリケーションをも統合することができます。
全体として見ると、疎結合型コンポーネントベース・アーキテクチャは、非常に大きな柔軟性を提供します。一方、構造化情報モデルは管理性を損なうことなく拡張性を促進する一貫性のあるプラットホームを提供し、各層でモジュール化コンポーネント技術を使用することで運用管理者が彼固有のネットワークの要求を反映して、モニタリングプラットホームをカスタマイズできるようにします。本論文の後半では、このコンセプトについて情報モデルの層の議論と、それらの構成コンポーネント技術の詳細を説明しさらに深く掘り下げます。
コンフィグレーション(構成設定)業務は、正式なデータ収集と処理サイクルの正規な部分ではありませんが、これらは情報フロー全体の中で重要な役割を果たしています。
まず、コンフィグレーション層はネットワークリソースが登録記載されるところであり、それがシステム全体のほとんど全ての他のコンポーネントに影響を与えます。これには、記載された各々のネットワークリソースから最初に集められた低いレベルのモニタリングデータが含まれるだけでなく、既知のリソースに二次的なデータソースをマップしなければならないコレクション層のコンポーネントをも含んでおり、レポーティングツールのいくつかで使用される既知のホストとサービスのリストなど、軽量のコンポーネントをも含みます。この観点で、この層内のコンフィグレーション・ツールは、システムの行う全てについて影響を及ぼし、たとえこれらのコンポーネントが稼動中のデータ処理サイクルで直接使用されていないとしても、GroundWork Monitorの運用をうまく行うのに非常に重要です。
基本的な構成設定業務を超えて、コンフィグレーション層は他の二つの低位層の機能に影響を及ぼします -それは、どのようにリソース固有のデータがインストゥルメンテーションによって集められるかを制御し、データ処理ツールにデータが集められた後に何を行うか(パフォーマンス読み取り情報を長期のパフォーマンスデータベースに保存するかどうかなど)を指示します。
例えば、この層の主要コンポーネントは、GroundWork Open Source が別途公開しているオープンソースのMonarch ツールをベースとした、Nagios のWeb ベース構成設定フロントエンドです。厳密に言えば、その構成設定ツールは Nagios の構成設定情報をアプリケーション固有の MySQL データベースに格納しますが、その時 GoundWork のアセットデータベースの構成設定テーブルと同期させるために統合スクリプトを使用します。構成設定が終了したら、バックエンドのスクリプトが実際のNagios構成設定ファイルを生成し、同様にこのシステムが知っている他のアプリケーション固有の構成設定リポジトリも更新します。
この特別の処置には、運用管理者が手動でNagios制御ファイルを構成設定することから開放されるという第一のメリットがありますが、それ以上に重要なのは、他のコンポーネントがまったく同一のネットワークのビューを持つということを保証することあり、それにより運用管理者がNagiosへの変更をするたびに他の全てのコンポーネントを再構成する必要から開放されることです。このアプローチはまた、Nagiosに新機能やアドオンを拡張することをより容易にし、Nagios自体の能力向上にもなります。
GroundWorkMonitor は多くの異なるモニタリングデータの収集をサポートしますが、オープンソースのNagiosモニタリングツールキットを第一の計測手段として使用します。Nagiosは、どのようなコマンドラインツールでも動かすことができ、オープンで軽量なテキスト形式プラグインインタフェースを持っています。この単純でオープンなインタフェースにより、数千もの異なるセンサーや計測値を収集・監視する Nagios プラグインの莫大なライブラリが出来上がっており、運用管理者はわずかな努力でを入手することができます。
初めて使う人のために Nagios には、ディスクやメモリ使用量、CPU使用率や他のタイプのシステム情報オペレーティングシステムの詳細情報をローカルのサーバから取り込むためのさまざまなLinuxスクリプトとユーティリティが含まれています。この情報の全ては、単にローカルのコマンドを実行して応答テキストをパースするだけで得られます。Nagiosはこれらのツールのために軽量のコマンドベース・インタフェースを使用しているので、リダイレクトのメカニズムを呼び出すことで、同種のデータを他のシステムから引っ張ってくることができます。
例えば、Nagios は、単に適当な SSH ユーザとセッションキーを生成してターゲットシステムに要求されたツールをコピーするだけで、"local"のLinuxユーティリティとスクリプトをリモートシステム上で実行させることのできる一般的なSSHラッパーを提供します。この設定でNagiosは、SSHラッパーをターゲットのシステムと実行させるリモートコマンドを指定するパラメータ付で呼び出し、リモートのアウトプットをNagiosで処理させるために戻します。より重要なのは、SSHラッパーコマンドは特にNagiosにバンドルされたコマンドに限らないことであリ、事実、適切な応答を返すことができるターゲットプログラムならコマンドとして使用できます。このように、Nagiosはターゲットのコマンドが互換性のあるテキスト型の応答を返せれば、SSHラッパーをほとんど全てのネットワークプラットホームへの問い合わせるのに使用することができます。
Nagios は SSH と似ていますが、より直接的なNRPEと呼ばれるNagios固有のクライアント-サーバ・プロトコルを通してのリモートコマンド実行もサポートしています。このモデルでは、リモートのシステムはNRPEリスナーを実行し、NagiosサーバがNRPEクライアントを使用してリモートのホストに接続します。そしてローカルのコマンドを発行することで、コマンドの出力が結果的にNagiosサーバに返されます。SSHインタフェースとともにNRPEリスナーは、ターゲットのプログラムが適切にフォーマットされた応答を返す限り、どのようなリモートコマンドも実行することができます。
GroundWork Open Source は WMI 呼び出しを通して、Windows 固有のデータを収集するための VBScript ユーティリティの集合を含む、Windows のため NRPE バージョンを提供しています。WMI もネットワーク上で機能するため、Windows のための NRPE の GroundWork のポートは元々の機能として、Windows デバイスのネットワーク全体のための WMI プロキシ機能持ちます。それにより GroundWork サーバは、ターゲットの Windows ホストを VBScript のパラメータで容易に識別することができます。
また、Nagios は単純にホストの稼動と応答性をチェックする ICMP-”ping” テストと同様に、特定のポートが許容されるしきい値内で接続要求に応答するかを見る TCP/IP プローブのようなネットワークレベルのテストを実施するさまざまなツールを提供します。Nagiosは、リモートのメールサーバにログインしたり、有名なDNSドメイン名を問い合わせたりなど、ネットワークプロトコル自体を使うことによりネットワークアプリケーションを積極的にテストすることができます。これら全てのテストはターゲットのサービスが単に接続待ちであるかを確認するだけでなく、実際に正しく機能していることを保証します。
当然、Nagios はネットワークデバイスのプローブから詳細なシステム問い合わせまで全てについて使用されるSNMPの使用もサポートします。唯一の制約事項はSNMP MIB が可能な数のみです。他のプラグインと一緒に、Nagios はローカルの SNMP クライアントを呼び出し、問い合わせのためのターゲットホストと SNMPMIB を与え、そしてそのクライアントが Nagios に必要な形式で収集したデータを返します。
プローブ・ベースのプラグインとは別に Nagios は、Nagios のスケジューラと独立して情報を収集する自律システムを認める ”パッシブ”モニタリングインタフェースも提供します。これらのツールは、重要な出力をNagiosが実行スケジュール毎に 処理するログファイルに記録されます。Nagiosが次のポーリング間隔で、何らかの新しいメッセージをこれらのファイル内で発見した場合、そのデータが取り上げられ、通常のモニタリングイベントと同様に処理されます。
GroundWork Monitor の商用版は、syslog メッセージとSNMP トラップを捕捉してフィルタし、その結果のメッセージを Nagiosの パッシブインタフェースに渡すプラグインを含みます。 両方共に、Nagiosにポーリングベースのツールでは取り逃す、非同期的かつアウト・オブ・バンド・イベントで通知することができます。より一般的なレベルで、NagiosはNSCAと呼ばれるプロトコルも提供します。それはリモートシステムがローカルのコマンドの出力をネットワークを介して、Nagiosのパッシブインタフェースに押し出すことができます。それにより、効果的に複数の独立したモニタリングシステムが、そのモニタリングデータを格納するために単一のマスターサーバに供給することができます。
利用できるプラグインの数と幅広さが累積し、Nagios をほとんどすべての種類の重要なイベントを検出する能力がある並外れて力強いモニタリングツールにします。一方、GroundWork Monitor は運用管理担当者が重要なイベントが発生する際に、常に通知を受けられるようにできるアラーム、およびエスカレーションシステムとして同様に強力なNagiosのコンポーネント技術を利用しています。他方では、GroundWork Monitor はオープンな Nagios インタフェースを使用します(上述の syslog と SNMPtrap など)。また長期間のパフォーマンスデータを保存し、Nagios とRRDtool の統合により、Nagios のデータを直接グラフ化する付加価値を提供します。
先に述べたように、GroundWork Monitor は多様な追加のモニタリングおよび計測ツールをサポートします。既存のソリューション固有なモニタリング業務が実現できない場合には、完全に新しいモニタリングツールを開発することができるプログラミングインタフェースを提供します。
GroundWork Monitor のコレクション層は、簡単に言うとインストゥルメンテーション層とビジュアライゼーション層をお互いに結びつける接着剤の役割を提供します。具体的に言えば、この層はシステム全体としてのデータベースを含み、独立したコンポーネントをシステム全体に結び付けるための統合ツールを提供します。この層内のコンポーネントのほとんどは、GroundWork Foundation として知られるオープンソースパッケージによって提供されますが、いくつかの独立したソフトウェアパッケージがこの層に組み込まれた追加機能を提供します。
データ格納のためGroundWork Foundation は、全体的に関連するデータ(モニタ対象のホストとサービスの状態情報を格納するオブジェクトテーブルなど)を提供するMySQLデータベーステーブルの集合と同様に、全ての重要なモニタリングイベント(Nagiosによって生成されたワーニングメッセージなど)の記録を格納するイベントテーブルを使用します。このデータを共通の場所に格納することで、共通のアクセス制御フレームワーク下で多数のツールによってアクセスされ使用することができます。
これとは別にGroundWorkは、必要とするコンポーネントに統合サービスを提供する制御スクリプトとプログラミング・ライブラリを提供します。制御スクリプトは、イベントレコードをNagiosから適当なデータベースのテーブルへ移動するように、必要なデータの持ち回りを行う「アクティブな」統合サービスを提供します。その一方、GroundWork Foundation に含まれているPerl、PHP、Java および SOAP のプログラミングライブラリはアプリケーションに対して、システムとの直接の相互作用が必要になった時の「パッシブな」インタフェースを提供します。
Foundationパッケージ以外にもコレクション層は、他のパッケージから持ってきた全体的に有用な技術を含んでいます。その最も分かりやすり例は、GroundWork Monitor全体としてのオペレーションにとって重要な Nagios 制御サービスの中で見出されます。例えば、Nagiosは運用管理者が特殊なデバイスの現在の状態をすぐに確かめることができるツールを提供し、GroundWork Monitor は(異なるツールとしてその機能を複製するのではなく)このツールをコレクション層に取り込みます。
同様に、GroundWork Monitor は長期のパフォーマンスデータの保存と表示のために RRD ツールキットを使用するので、その技術が Foundation パッケージでなく RRD のコンポーネントから由来したものであっても、そのような RRD データベースとグラフ化サービスがコレクション層の範囲に含まれます。
GroundWork Monitor アーキテクチャの最上部は、ビジュアライゼーション層です。ビジュアライゼーション層は、コレクション層によって管理されたデータを表示するために使用するWebアプリケーションを含みます。GroundWork Monitor 内には、デフォルトで1ダースほどの Webアプリケーション(正確な数はバージョン種別で異なる)がありますが、この層の第一コンポーネントは JBoss Portal フレームワークです。前述の JBoss Portal は、共通のプレゼンテーションフレームワーク内の GroundWork Monitor web アプリケーションと結合します。 JBoss についての詳細情報は、 OPEN SOURCE REFERENCE
JBoss を参照してください。
GroundWork Monitor は、いくつかのベースアプリケーションを、その基本パッケージに含んでいます。例えば、GroundWork Monitorは ベースのステータスビューアを含んでいます。ステータスビューアは、Foundationデータベースからのサマリ情報・RRDサブシステムからのグラフ・Foundation内に保存されたイベントからのログメッセージを含む複数ソースから取り込まれたデータにより、指定されたホストやサービスの概況を提供します。ステータスビューアは、Nagiosコントロールインタフェースにより、ユーザがターゲットリソースのNagiosビューを操作したりテストしたりできる制御を含んでいます。
一方、GroundWork Monitor の商用版は、Foundationイベントデータベースのシンプルな表形式ビューを提供し、問題が検出されたらネットワークオペレータができるだけ早く気付くようにするconsoleアプリケーションを含んでいます。
このアプリケーションは Guavaベースなので、これを他のアプリケーションの中に取り込むことができ、上述のステータスビューアの例では、リソース固有のステータスメッセージを表示するためにコンソール・ビューアコンポーネントを使用します。
GroundWork Monitror は、使用する版によりますが、長期間の分析レポートを作成するためのいくつかのツールを提供します。まず、Nagiosはホスト毎・サービス毎の稼働率データの簡単なグラフを生成することができ、それら全てはNagiosのWebインタフェースを通して利用できます。一方、GroundWork Monitror の全ての版には、Insight Reports アプリケーションが含まれています。それは、多数のホストとサービスの重要な過去のイベントを同時に表示し、完全なネットワークのスナップショットのビューを提供します。これとは別にGroundWork Monitror の商用版には、オープンソースの BIRT レポーティングツールが含まれており、特別仕立てのレポートを作成することができます。
第1章で説明したように、GroundWork Monitor はオープンソース監視モジュラーと統一された情報マネジメントシステム、および高い拡張性と定期的に管理された監視プラットフォームを統合しています。
上位のアーキテクチャとして、これらのコンポーネントは4層に分けられます。コンフィギュレーション・インストゥルメンテーション・コレクション・ビジュアライゼーションです。これらは設定・収集・プロセス・ビジュアル化などの情報を使用します。しかしながら、これは監視プロセスの概要であり、実際のデータ収集の仕組みは論理モデルが説明ているよりも複雑なものです。特にソフトウェアコンポーネントや機能の追加については顕著です。
これは GroundWork Monitor がコンポーネントを情報モデルにまとめ上げるのに統合ツールに依存していながら、それ自体の情報収集モデルを有するオープンソースコンポーネント技術を多用しているからです。実際、使用されているソフトウェアは日々のオペレーションにとって重要なものですが、論理情報モデルはどのように情報がシステムを流れていくかを理解する際にもっとも有効なツールとなります。
第1章では、GroundWorkMonitor によって使用される論理情報モデルと、アーキテクチャ内で適用する主要なシステムコンポーネントについて述べました。この章では、個々のソフトウェアコンポーネントの観点から情報の流れを検証します。
構成設定のタスクは、現状のデータ収集やプロセスサイクルの正式な一部分ではないように見えますが、このタスクは GroundWorkMonitor の情報フローにおいて重要な役割を果たしています。最低限、監視リソースやリソース設定プロセス内で必要と思われるもの全てが、監視の始まる前あるいはエンドユーザに提供される前に定義される必要があります。一方、構成設定プロセスはさまざまな従属コンポーネント(性能グラフやイベント調査など) にも影響します。その影響は顕著ではありませんが、システムを長期的に使用する場合には使用満足度への影響は大きくなります。
構造的にいえば GroundWork Monitor 内のデータの基本ユニットは、一定時間単位で取得される特定のホスト上にある特定のリソースについての計測データです。しかし、このデータが収集される前に管理者はモニタ対象の定義や、ターゲットホスト上のサービスを定義しなくてはなりません。管理者は収集すべきデータ・基本的な可用性の情報・傾向分析にデータ数値が必要なのかどうかを定義する必要があります。また、運用管理者は監視間隔や通知担当者といった一般的なオプションも設定しなくてはなりません。リソースとそれに必要な全オプションが定義された後、コマンドスケジューラが定期的に適切な監視ツールを実行し、該当するリソースの計測データを作成します。その計測データは、定義されたオプションに従って GroundWork Monitor を通じてさらなるタスクを実行するために使用されます。
リソースとオプションの定義づけプロセスはコンフィギュレーション層を通して管理されます。特に Nagios について設定はオープンソースの GroundWork Monarch で管理されます。このアプリケーションはデータ入力画面とフォームを Web インターフェースを介してユーザに提供する一方、バックエンドでは構成設定を MySQL で読み込み保存しています。管理者が構成設定を反映させたら、個々のソフトウェコンポーネントに必要な設定ファイルとデータベースを追加するプロセスが起動します。この方法によって、管理者がそれぞれのコンポーネントを個別に構成設定しなくても、GroundWork Monitor 内の異なる全ソフトウェアコンポーネントが、常に監視対象ホストとサービスについての整合したビューを持つことを保証します。
Nagiosにおけるリソース定義は、それぞれが共通のリソースタイプの細かな特徴を定義するテンプレートとプロファイルの入れ子になった結びつきを使用します。設定の終了したリソース定義は特定の監視対象機器の監視項目のインスタンスとして、テンプレートとプロファイルにリンクされて設定されます。
このモデルのもっとも重要な項目は、Nagiosにリソースの監視方法を伝えるプラグイン定義を提供するコマンド定義です。コマンド定義は呼び出されるプログラムやスクリプトを指定するとともに、プラグインが機能するのに必要と思われるオプションを指定します。Nagios独自の変数(マクロと呼ばれるもの)もコマンド定義で使用することができ、必要と思われるフィールドにパラメータを設定できます。
例えば、GroundWork Monitorは”check_tcp”というコマンド定義を提供しています(下図)。これは対象ホスト上の特定のTCPポートが、入りの接続リクエスト待ちの状態にあるかをNagiosがテストすることを可能にしています。フルのコマンド定義がプログラムへのパスを指定し、”-H”オプションと"$HOSTADDRESS$"変数で対象ホストを指定、”-p”オプションと"$ARG1$"変数で対象のポート番号を特定します。コマンド定義内での変数を使うことで、単にターゲット固有のデータを変数データに代入することによって、一つのコマンドで複数のプローブが使用できるようになります。
図: コマンド定義
コマンド定義は「Nagiosによって直接処理されず、後に使用されるプラグインを定義するのに使用される」ということを理解することが重要です。コマンド定義が作成されたら、それは一つ以上のリソースにマップされ、最終的には特定リソースを監視するためのリソースに特化したコマンドとなります。簡潔に言うと、コマンド定義は後の実際のリソース監視を定義する構築ブロックを提供するに過ぎません。そのためにGroundWork Monitorは、上図のような単純なツールからリモートホスト上のアプリケーションに接続して、アプリケーション固有の情報を収集する高度なツールまでの範囲の多くの定義済みのコマンドを持っています。
コマンド定義とは別にNagios内のリソース監視でも、各監視ジョブを定義するある種の管理データを必要とします。コマンド定義は、使用される基本的なコマンドラインを示すのに対し、管理データは、ポーリング頻度やクリティカルなイベントが発生した際の通知担当者などのコントロール要素を示します。
リソースが定義された際に、これらの値は手動で入力することができますが、通常それらはコマンド定義と同様に再利用可能なオブジェクト”サービステンプレート”で定義されています。デフォルトでは、GroundWork Monitorは最も一般的なセッティングを使用する"generic-service"ひとつを含んでいますが、もしあるリソースが異なるコントロール設定(別の管理担当者を作ることが必要など)を必要とするならば、追加のテンプレートを定義することができます。
コマンド定義とそれに関連付けられた管理データの組合せは、特定タイプのリソースへの監視方法を定義するサービス定義となります。サービス定義はコマンド定義とサービステンプレートから全ての属性を引き継ぐことができます。また、運用管理者がその下にあるコマンド定義の変数値を設定したり、サービステンプレートから管理データをサービス固有値に置き換えることによって、属性のいくつかを上書きすることができます。
例えば、前述の"check_tcp"コマンドの定義にはターゲットのポート番号を特定するためのコマンドライン変数があります。この変数値を80(HTTP)や25(SMTP)として明確に定義することによって、一つのコマンド定義を複数のサービス定義に対する礎として使用できます。逆に、一般的な"check_tcp"のサービス定義は変数値を未設定のままで作成することができ、それにより、特定のリソースが定義された時点でポート番号の値を与えることができます。
GroundWork Monitor Enterprise は数ダースもの定義済みのサービス定義を持っており、必要に応じて新しいコマンド定義やサービステンプレートを定義、あるいは単に既存値を変更することによって新しいサービス定義を作ることができます。
GroundWork Monitor は、複数のコマンド定義をサービスプロファイルの一部として、リンクすることができます。サービスプロファイルは、複数のホストで共通なサービス定義のセットを定義しなくてはならない際に便利です。例えば、SMTPとPOP3サーバを持つ多数のe-mailシステムがあるとする。その場合、ひとつひとつ個々のサービス定義を各ホストに適用するのではなく、適切なサービス定義を参照する”Internet Email”サービスプロファイルを作成して、それを各ホストに適応することができます。サービスプロファイルは必要に応じて定義できますし、商業版 GroundWork Monitor には数ダースの登録済みプロファイルが含まれています。
ホスト定義は、コマンド定義やサービス定義と同様な法則に従っていますが、いくつか大きな違いがあります。特に、ホスト定義はコマンド定義やサービス定義に見られた複数の抽象的な層を要求しないということです。その代わりにIPアドレスやホスト名、およびホスト特有のコントロールデータを必要とします。後者の場合、ホストテンプレートは一般にサービステンプレートと同じような使い方をされ、同様に目的を果たします。(例:何台かのホストで異なる管理上の連絡先が必要な場合)
次の抽象化レベルであるホストプロファイルは、一つのホストテンプレートと一つ以上のサービスプロファイルの組合せです。例えば、WMIベースのExchangeの問い合わせと前述のe-mailサービスプロファイルと一緒に、一般的なホストテンプレートとシステムレベルのSNMPとWMI lookupを併せた一般的な"Windows Server"ホストプロファイルを持つことができます。そこからは、お客様のネットワーク上のWindowsベースの全Exchangeサーバへ、ホストテンプレートを適用するのは容易です。
Nagiosでは、ホストグループを使用して、個々のホスト定義を論理的な階層にグループ化することができます。ホストグループはいくつかの基本的属性定義(特定のコンタクトグループやエスカレーションツリーなど)を持つことができますが、それらはプレゼンテーションツールによってフィルタリングやソートの際によく使用されます。デフォルトではGroundWorkMonitorは、ローカルシステムのみを含む”Linux Server”ホストグループを持ちますが、要求されるであろうどんな種類の論理グルーピングでも表せるようにホストグループを作成することができます。例えば、ホストグループを地理的位置、組織上の部門、あるいは好きなアレンジで作成することができます。GroundWork Monitorはホストプロファイル内で、ホストグループをあらかじめ定義できるため、組織の階層は影響のあるホスト定義に押し付けられます。
全体としてみると、テンプレート・プロファイル・ホストグループを賢く使用することで、運用管理者はほとんどを事前に設定済みにしておくことができます。例えば、遠隔データセンタにあるWebサーバのハードウェアレベルのエラーについてはサードパーティーのサービスプロバイダに通知し、"ping"サービスプロファイルではホスティングプロバイダーにネットワーク接続性の問題を通知し、アプリケーション固有のサービスプロファイルでは社内のヘルプデスクにアプリケーションの問題を通知するようなホストテンプレートを持ち、それら全ての設定がさまざまなテンプレートやプロファイルに事前に設定されるかもしれません。その一方で、前述したようにGroundWork Monitorは必要であれば、プロファイルとテンプレートの設定を上書きすることでホストやリソースを手動で定義し直すことができます。
また、コンフィギュレーションアプリケーション(特にその下にあるリレーショナルデータベース)におけるテンプレートとプロファイルの使用は、ある非常に強力な継承機能を提供します。例えば、あるサービス定義に対するコンタクトグループを変更する必要がある場合は、管理者は関連するサービステンプレートを変更するだけです。新しいコンタクト情報は、次に設定情報が保存される際に関連するサービスによって自動的に引き継がれます。
GroundWork Monitorでは定期的なデータ収集のほとんど全てがNagiosによって実行されています。GroundWork Monitorは単独で自律した監視ツールの使用をサポートし、カスタムの監視ソリューションのための開発ライブラリやAPIを提供しますが、シンプルで軽いテキストタイプのインタフェースが使いやすいために、Nagiosがほとんどの場合の監視データ収集方式で使用されています。その結果、他の製品もサードパーティーのインターネットサイトからダウンロードできるにもかかわらず、Nagiosはサービス定義の巨大なライブラリを持っており、そのサービス定義はGroundWork Monitorに既に含まれており、大抵の要求に対して適当なNagiosのプラグインがすでに存在している場合が多いです。
Nagiosは情報フロー全体の中のデータ収集フェイズに対して、3つの大きな機能を提供します。一つ目の機能は、定義された項目全てにわたりプラグインプロセスをうまく調整するコマンドスケジューラを提供します。二つ目の重要な機能は、監視データが実際に集められているところでのプラグインコマンド実行です。三つ目の機能ではプラグインのデータを検査し、受け取った応答に基づく追加アクションを行います。これらの3つの機能は、リソース定義が存在する限りそのサイクルを繰り返し継続して実行されます。
Nagiosサービスが再スタートした際は、定義されたホストとそれに関連するリソースを確認し、コマンド実行のスケジュールのローテーションを行います。コマンドスケジュール作成のために使用される方法は、複数のアルゴリズムと変数が関わっているため、やや分かりにくいですがアルゴリズムの背後にある基本的な事柄は Nagios がコマンドの実行頻度を均等に分散しようとすることです。これは新しいポーリングが始まったとき、ローカルサーバが過負荷にならないようにし、対象ホストが複雑な問い合わせで過負荷になることを防ぐことに役立ちます。この点に注意しないと、Nagios自身が障害の原因になるでしょう。
この方法の主要部分の一つは、均等に時間をサービス定義に分割することによります。基本的にこれは実行インターバルを均等に振り分け、コマンドキューにあるリソース定義の数によって、平均のポーリングインターバルを分割することにより行われます。
加えて、Nagiosコマンドスケジューラはホストごとにクエリを入れ子にします。それにより、対象システムは同時に全てのクエリを得ることはありません。これは、"スキップ"値として使用される値の結果とともに、実働しているホスト定義の数により、リソース定義の数が分けられることによってなされます。Nagiosは、スケジュールのウインドウ(時間枠)に最初のコマンドを加えることで、スケジュールプロセスを開始します。そして、"スキップ値"分コマンドキューを先飛ばして次のコマンドをスケジュールの現在スロットに追加します。このプロセスは、すべてのコマンドがコマンドスケジュール全てのスロットに追加されるまで繰り返されます。
これらのテクニックを両方使用することで、適度に均等な順番でサーバ全ての問い合わせを分割する一方、Nagiosスケジューラが適度に低頻度でコマンドを発行することができます。
下図は、3つの異なったホスト上の8つの監視タスクが10分のポーリングウィンドウの中で、どうやって理論的に分けられているかを示したものです。この例では、10分間に”3”というスキップ値を持つ8つの1.25分のインターバルに分けることができます。最初のホストからの最初のコマンドは、最初に使用が可能なスロットに配置されます。それからスケジューラは3つ進んで、最初のホストからの2番目のコマンドをそこに入れます。全てのコマンドがスケジューラに追加されるまで、このコマンドを繰り返します。
図: コマンドスケジューラ
上記の説明は、いかにしてコマンドがスケジュールされるかについての重要な部分に触れています。しかし、他にもNagiosのコマンドキューが埋められた際に、考慮すべき多数の変数やオプションがあり、上述した2つのメカニズムは決して単なる基準ではない、ということを認識することが重要です。アルゴリズムとその変数についての詳細は、Nagios ドキュメント を参照してください。
また、元来のコマンドのスケジュールに関わらず、外部のイベントがコマンドのプロセス方法に影響を与える場合があります。例えば、すべてのホスト定義にはホストがオンラインであるかどうか、を見極めるために使用するサービス定義を持っています。もし、このテストで対象ホストが接続不能になった場合、このホストの他のサービスは延期され、結果としてリソース関連のコマンドは次のスケジュールインターバルでスキップされます。
スケジュールされたコマンドが延期されたりスキップされる結果になるかも知れませんが、Nagiosサーバがポーリングインターバル内で監視できるよりも、多くのリソース定義を持つことは可能です。ポーリングウィンドウ内で実行可能なコマンドの最大数は、ローカルおよびリモートホストのCPUやメモリ稼働率、ネットワーク帯域、コマンドの複雑さ、それぞれのコマンドの実行するまでにかかる時間、などの要素により変動します。一般的にNagiosはできるだけ多くの監視ジョブを実行しようとしますが、多数のプローブによりリソースを使用しているのであれば、残りのジョブは再スケジュールされるか、ジョブが不完全に実行される可能性があります。
Nagios のコマンドインタフェースは監視データ収集の中心です。監視コマンドが実際に実行され、戻り値が読み込まれてキャプチャーされる機能です。 Nagios が収集した全データが最初に受け取られるところなので、おそらくこれは GroundWork Monitor の中でもっとも重要な部分でしょう。
Nagios コマンドインタフェースは非常に簡単ですが、とても重要です。基本的に Nagios はサービス定義に定義された変数がどのように定義されていても、プロセスを行うために、OSにコマンドラインを送って戻り値の出力を読む以上のことはしません。
前述したように、Nagios におけるリソース監視はサービス定義にマップされたコマンド定義を使用しています。サービス定義は、さらに特定ホスト上の特定リソースにマップされます。そして必要に応じて、その元になるコマンドラインの変数値が、サービス定義または特定のリソース定義によって代入されます。これはNagiosコマンドインタフェースに関連するので、Nagiosに使用されるコマンドラインは、変数の代入の最終箇所である最後のリソース定義から供給されます。
一般的なステータス計測法として、Nagios は四つの異なるステータスコードを使用します。”OK”は監視対象リソースが通常の動きであることを示しています。”WARNING”は、リソースが通常とは違う動きをしているが危機的状況にはない状態を意味します。”CRITICAL”は、リソースが正常に動作していないか、危機的状況にある場合を意味し、”UNKNWON”はコマンドが何が起きているかを翻訳できない状況が起こっていることを意味します。ステータスは0がOK、1がWARNING、2がCRITICAL、3がUNKNOWNを示し、STDERRを通してPOSIXコードとして主に提供されます。
また Nagios では STDOUT に文字データが表示されます。エラーメッセージとともにステータスコードと同様の文字データが提供されます。エラーメッセージは性能監視に必要と思われる計測用データと同様に、アラートや通知に必要とされます。
従来、Nagiosは比較的自由な形式の文字データ応答を使用してきましたが、多くのプラグインは "<SERVICE> <STATUS> - <Textual message>" に類似した構文を使用していました。SERVICE はサービス名、STATUSは上記の戻り値の文字表示、Textual messageは書式自由のテキストデータです。
しかしながら、性能監視の追加によって応答に明確に構造化データを含ませるように変わりました。具体的には、性能データを返すプラグインは書式自由のテキストメッセージの最後にパイプシンボル("|")を追加し、そのパイプのうしろに詳細な性能データが付くようにしなければなりません。
性能データでは "<label>=<value>;<warning-threshold>;<critical-threshold>;<minimum-value>;<maximum-value>." の正確な書式が求められます。この構文は、コマンドがリソースやリソースに関連するものの現状を確認するために必要な全ての情報を提供します。特定のフィールドに適当な値がない場合、値は無くても良いですが、セミコロン区切りは必要です。応答の構成ルールについては、Nagios プラグインデベロッパのガイド参照してください。
サービス定義において、特定のリソースを問い合わせるためにコマンドベースのプローブを使用する外部プローブやツールがNagiosの代わりにデータを取りにいくことが望ましいことや、必要である場合があります。これは比較的にランダムなインターバルで、偽メッセージを生成するサービスに有効です。なぜなら、これらのイベントタイプはNagiosのポーリングベースのスケジューラを通して、簡単に監視されることができないためです。
例えば、GroundWork Monitor の商業版は Nagiosとは別に、SNMP トラップと SYSLOG メッセージを拾い上げることのできるツールを提供しており、(通知メッセージ生成やイベントアラームなどの)追加処理のためにNagiosにイベントメッセージを渡すため、パッシブ型インタフェースを使用します。一方、Nagiosはリモートシステムが監視結果をNagiosに直接提供することができるNSCAと呼ばれるネットワークプロトコルを提供します。それは結果として、ローカルサーバの負荷を軽減します。
これらの場合、外部システムプロセスが、Nagios が後で処理を行うために入力メッセージをキューにしておき、同時にNagiosのコマンドスケジューラも"passive"チェックをキューにして、それを通常のコマンドと同様に実行します。特定のリソースに対するそのパッシブチェックの順番が来るたびに、Nagiosはそれに関連付けられた入力を読み込んで、このポイントから先では基本的に見分けがつかないデータとともに、得られたデータを通常のコマンドから得た検知データとして扱います。
Nagiosはそれぞれのコマンドが終了するたびにデータを収集しますが、すぐにそのコマンドの出力を処理し始めるわけではありません。その代わり、応答データをグローバルのイベントキューに入れ、次に空いているコマンドインターバル(即時の場合もあるし、他のタスクで忙しい場合はその後)で処理をします。空きのコマンドウィンドウが回ってきたら、Nagiosはキューイング全ての出力データを集める”reaper(収穫)”イベントを始め、記録された結果それぞれの構文解析を行います。
このプロセスの一部として、最初に、Nagios はコマンドの戻り値の出力とともに、それぞれのリソースに対して実行されたコマンドの詳細について記録を行います。その後、このログファイルはGroundWorkの統合スクリプトによって読み込まれて適切なFoundationデータベースをアップデートされます。ステータスコードは、基本的な可用性監視を行うための基本状態トラッキングテーブルに保存されます。一方、書式自由の戻り値の文章は、イベント履歴文字列のビューを提供するログテーブルに格納されます。
それとは別に、Nagios は、要求されていれば、収集したパフォーマンスデータを別のログファイルに記録し、長期間の性能データベース構築に利用することができます。5分おきにNagiosのイベントプロセッサーが GroundWork Monitor に含まれる収集した性能データからリソース固有のラウンドロビンデータベースを生成し、データを追加するための Perl スクリプトを起動します。このデータベースにより、サンプリング履歴データをプレゼンテーションツールでグラフ表示することができます。
加えて、これらのリポジトリは特定のリソースについての多くの情報を提供することができます。例えば、GroundWork Monitorの ”Status” アプリケーションは、特定のリソースについての現在状況、受け取った主要なメッセージ、および長期のパフォーマンスデータを含む概要情報を表示するために収集した全ての情報を使用します。下の図は、このコンセプトを説明する標準的な Status アプリケーションの画面例です。Webページを作成するために使用されるデータベースソースを説明します。
のブロックにあるデータは、Nagiosステータスログファイルから Foundation に入った概要情報を含んでいます。一方、
のブロックはこの特定のリソースと関連するテキストメッセージです。また、
のブロックにあるデータは、ラウンドロビンデータベース(このデータベース自体はNagiosのパフォーマンスログから由来する)から作成されたグラフです。
図: Status(ステータス)アプリケーション
Nagiosの ”reaper” プロセスは、出力メッセージを色々なログファイルとして処理することのほかに、ステータスを確認し、必要なアクション(アラートの作成など)を実施して、コマンドスケジューラにモニタリング処理を再要求することについての責任を持ちます。
このプロセスにおける重要な情報は、リソースの問い合わせに使用されたプラグインからの戻り値です。OKステータスを返すリソース定義は、単に記録され、それらに関連するコマンドは次の空きインターバルでスケジューラによって再実行されるように設定されます。もし、サービスがWARNINGあるいはCRITICALステータスを返してきたら、Nagiosは監視対象機器自身が稼動していて、接続可能であるかどうかを確認するための要求をキューイングします。
問題のあったサービスに対するホストチェックでも、OKではない結果を返してきた場合、Nagiosはホストダウンと認識し、既定された対象ホストダウン時のアクションを起こします。ホストチェックが成功した場合は、特定のサービスが失敗していると認識しNagiosは既定のサービスダウン時のアクションを行います。
OKではないステータスを返すサービスは、「ハード」エラーとして認識される既定回数のチェックが行われるまで「ソフト」エラーと認識されます。どちらのステータスであっても、フラグがたったサービスでは、ある種の自動復旧を試みるためイベントハンドラを使用することができます(イベントハンドラは通常サービスやホストテンプレート内で定義されますが、全体的にも適応が可能です)。 サービスがハードエラーになったときは、通知メッセージが適当な担当者に送られます。
GroundWork Monitor は Nagios のステータスログ全てについて内部での複製は行ないませんが、商業版の GroundWork Monitor はイベントデータのいくつかを MySQL データベースにコピーし、それにより運用管理者が記録された主要イベントへすばやく簡単にアクセスできるようにします。
このデータは主に GroundWork のイベントコンソール(Event Console )ビューアで使用されます(下図参照)が、他のプレゼンテーションツールでも組み込まれます(特に前述のステータスビューア)。
図: Event Console(イベントコンソール)
GroundWork Foundation データベース内に作成・保存されるデータベースのレコード数は運用管理者によって定義されたフィルタによって決定されます。デフォルトではデータベースは主要イベントのみ(大きな状態変化など)を保存しますが、管理者が望めばより多くの情報をキャプチャーすることができます。例えば、商業版の GroundWork Monitor にバンドルされている SYSLOG や SNMP トラップからのクリティカル情報は、コンソールテーブルに抽出された後保存されます。実際、Foundationデータベースは、どのイベントソースからもイベントデータを受け取り保存できるように拡張が可能です。
Event Console アプリケーション内の全てのレコードは、それらがオペレータによってアラート承認されて、問題対応されたときに、"cleared"(対処済)にすることができますので、古い記録でアプリケーション画面が一杯になることはありません。しかし、それらのイベントは手動で削除されるまでデータベースに残っているので、長期間の運用状況レポートや分析に使うことができます。
このサービスのもう一つの重要な点は、統合スクリプトが自動的に重複しているレコードを削除するということです。それはデータベースのオーバーヘッド削減に有効です。例えば、重複していると認められる二つのイベントが起こった場合、データベースは単純に最後の入力部分にある最初のタイムスタンプを最後に入力された時間で更新し、”Message Count” フィールドに同じレスポンスが複数回あったことを示すための数を加算します。このアルゴリズムは、管理者が違うレベルの詳しさを必要とする場合や、重複したメッセージを特定するための異なった基準を求める場合に変更することができます。
GroundWork Monitor では長期間の性能データの保存は、オープンソースであるRRDツールにより処理されます。このツールはラウンドロビンタイプのデータベースを提供し、時間ベースの表示をためてグラフ表示することが可能です。元来、RRDツールは一定の長さを持つ先入れ先出しローテーションを用いたデータベースを使用します。また、RRDは新しいサンプルが追加されるたびに古いデータを整理して削除するという移動平均アルゴリズムを使用しています。結果として、新しい期間のデータは正確な形で見ることが可能ですが、古い期間のデータは上記の平均アルゴリズムの結果として低い精度となります。該当するデータベースのファイルは一定のサイズで保存されますが、このモデルは、一分から一年までの複数の期間でのデータを提供する、データベースファイルを持つことが可能です。
RRDデータベースは、数分おきに Nagios のジョブスケジューラによって起動される、GroundWork Monitor とともに提供された Perl スクリプトによって作成されます。ログファイルに監視項目の性能データが存在する場合、Perlスクリプトは適切なRRDデータベースにそのデータを加えるか、データベースが存在しない場合はデータベースを作ります。しかしながら、そのPerlスクリプトは Nagiosの性能データが絶対必要というわけではありません。必要であれば、他の情報から性能データを代わりのデータとすることができます。例えば、リモート対象との接続確立時間を要求された場合、Nagios独自の性能データに頼る代わりに、別のデータを基にしたグラフを作成することができます。
Perl スクリプトがどのデータベースを作成して、どのようにデータをキャプチャーして整理するべきかを知るために、GroundWorkMonitor はこの目的だけのために独立した ” Performance Configuration” アプリケーションを提供します。このアプリケーションは、アドミニストレータがパフォーマンスデータベースを必要としているサービスタイプの指定、RRDデータベースへの出力方法、パフォーマンスデータの解析の仕方、そして新しいデータが追加されたRRDデータベースのアップデート方法を指定することを可能にします。
デフォルトでは、パフォーマンス構成設定システムには頻繁に使用されるサービス定義用に、いくつかの定義済みのセッティングを持っています。例えば、CPUとメモリ使用率、ネットワークインタフェースのトラフィック、システム負荷やその他一般的なものです。もし、他のリソースにパフォーマンスグラフを追加する必要があれば、RRDデータベースを作成し、追加して、グラフ化する前に構成設定ツール内で定義する必要があります。
この範囲でのもう一つの記述すべき点は、必要であれば RRD データベースは一つのファイル内の複数のカラムの中に複数の読み込みを保存することができる、ということです。これは、複数のデータタイプを参照する複雑な(一つの画像でトラフィックの送受信量を示すグラフのような)グラフ作成を行うことができますが、カラムへのある種の変更は、新しいデータベースの作成が必要であるため注意してください。