JP2002342128A - ホストマシンからサービスの健全性を抽出する方法 - Google Patents

Abstract

(57)【要約】 【課題】 一貫したサービス健全性計量 を提供する。 【解決手段】 観察されているサービスに関する内部ソ
ースおよび外部ソース双方（１１、１０１乃至１０５）
からの様々な測定値を組み合わせる。このサービス健全
性情報は、特定のプロバイダアプリケーションおよび性
能監視ツールセット（１３）から独立して生成され、そ
れにより、サービス管理の解決策に対して、市場へ出る
までの時間をより短くすることができる。出力は、多数
の異なるコンピュータサービスの状態を報告することが
できる高レベルの性能監視ツールによって使用される、
プログラムまたはスクリプト可能インタフェースの形式
（１０８）でもよい。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本技術分野は、コンピュータ
システムの性能を監視するように設計されたソフトウェ
アシステムである。

【０００２】

【従来の技術】ネットワーク化されたコンピュータサー
バを含む最近のコンピュータシステムの性能は、様々な
理由により低下する。その理由の多くは、ディスクバン
ド幅、メモリ容量および中央処理装置（ＣＰＵ）の利用
を含む共用リソースの使用に関する。情報技術（ＩＴ）
システム管理者は、これらの共用資源および他の共用資
源の最適な割当てを保証するように、コンピュータシス
テムの性能を追跡する。性能監視ソフトウェアは、シス
テム性能を追跡し問題を診断するのに必要なツールをシ
ステム管理者に提供する。性能監視ソフトウェアは、コ
ンピュータシステムについての即時の性能情報を提供
し、管理者がコンピュータシステムの活動を検査し、ボ
トルネックを識別し且つ解決し、動作がより効率的にな
るようにコンピュータシステムを調整できるようにして
もよい。性能監視ソフトウェアは、背景タスクとして性
能を監視しながらコンピュータシステムの性能の履歴を
保持し、差し迫る性能問題に対してアラームを送っても
よい。性能監視ソフトウェアを使用して、管理者は、コ
ンピュータシステムの活動における傾向を正確に特定
し、コンピュータシステムの成長を正確に計画するよう
に、作業負荷をバランスさせるようにこの情報を使用す
ることができる。

【０００３】性能を検査するために、性能監視ソフトウ
ェアは、性能情報を最初に収集する必要がある。この性
能情報、すなわち計測(instrumentation)は、オペレー
ティングシステム、ソフトウェアプローブまたはアプリ
ケーションによって提供されてもよい。この計測から導
出される計量(metrics)は、リソースごとまたはグロー
バルレベルからアプリケーションレベル（プロセスのグ
ループ）さらにプロセスまたは個々のスレッドレベルま
でを含むいくつかの種々の仕方で、編成されてもよい。
性能監視ソフトウェアによって導出される計量は、ＣＰ
Ｕおよびメモリの利用、種々のシステムリソースを待つ
ために費やされる時間、待ち行列の長さ、アプリケーシ
ョン特有のテーブルおよび状態情報およびアプリケーシ
ョン応答時間を含んでもよい。これらの計量は、最適な
性能となるようにシステムを調整するように管理者によ
って使用され、閾値に到達し、または、閾値を超えるた
びに、性能監視ソフトウェアが警報および警告を生成す
るようにしてもよい。閾値は調整でき、警報および警告
は、たとえば、電子メールメッセージで提供されてもよ
い。

【０００４】コンピュータシステムは、ユーザおよび計
算機環境の他のサービスにサービスを提供する。調整の
目的は、特定のシステムに常駐するサービスを最適化す
ることである。（データリポジトリサービスまたはイン
ターネットウェブサービスのような）サービスは、１つ
または複数の特定のアプリケーションからなり、当該ア
プリケーションは、コンピュータシステムにおいてイン
スタンス生成された１つまたは複数のプロセスからな
る。コンピュータシステムのユーザは、アクセスするサ
ービスの点で行動を観察するのに対し、内部的にコンピ
ュータシステムは、特定のリソース、プロセスおよびア
プリケーションの点で性能を差別化する。

【０００５】残念ながら、現在の計算機サービスは、性
能を監視するツールに状態を報告する一貫した仕方を有
していない。各サービス、またはサービスを構成するア
プリケーションおよびプロセスは、性能監視ソフトウェ
アに有用な内部状態測定(measures)および計測を有する
かもしれない。しかしながら、性能計測が利用可能とさ
れまたは報告される仕方には一貫性がない。さらに、ほ
とんどのアプリケーションは、自身の性能情報を生成し
ない。結局、サービスは、サービスが動作する複雑なコ
ンピュータ環境に関する「外部」情報をめったに受け取
らない。ネットワークバンド幅や依存するサービスの不
足などのような、サービス自身の外側のボトルネック
は、サービスの健全性および応答性に影響するかもしれ
ないが、起こり得る外部ボトルネックは、統一された仕
方で監視され管理されることはない。結果として、サー
ビスの健全性は、しばしば、管理することができず、特
徴付けたり報告することさえもできない。サービス状態
が、「アップ」または「ダウン」のみで特徴付けられる
ことがよくある。発展する複雑なコンピュータシステム
において、詳細のよりしっかりしたレベルまでサービス
の健全性(health)を解析するために、一貫した方法が要
求される。サービス状態の粒度(granularity)を増加さ
せると、性能および使用可能度のより高い一貫性を達成
するために、有用なサービス目標の構成およびサービス
レベルの目的の管理が可能となる。

【０００６】サービスの健全性性能監視のその他の問題
は、データ収集および性能計測の解析に関する規則が常
に変化していることである。アプリケーションの新しい
バージョンが環境に導入されるたびに、当該アプリケー
ションに関する性能情報は変わる可能性がある。同様に
性能監視ソフトウェア自身も変わり得る。これらの変化
によって、たとえば計測にアクセスしたり、計測を処理
したり、新しいデータソースを導入する新しい仕方が生
じる可能性がある。システム管理者は、性能監視が構成
される仕方を常に適応させる必要がある。これは、種々
のレイヤのアプリケーション、計測、性能監視ソフトウ
ェアおよびコンピュータオペレーティングシステム環境
の間の固有の依存性のためである。環境に何らかの変更
があれば、性能監視の変更がしばしば必要となる。

【０００７】

【発明が解決しようとする課題】現行のコンピュータシ
ステムで実行されるサービスおよび関連するアプリケー
ションおよびプロセスは、サービスがどの程度機能して
いるかを判断するのに必要なタイプの情報を提供しない
ことがしばしばある。他のサービスは情報を提供する
が、アプリケーションごとに、一貫していない仕方で提
供する。その結果、サービスの管理者は、しばしば、サ
ービスの性能を測定することができず、または性能低下
を予防する処置を行うことができない。

【０００８】

【課題を解決するための手段】一貫したサービス健全性
計量を達成するために、方法および装置は、観察されて
いるサービスに関する内部ソースおよび外部ソース双方
からの様々な測定値を組み合わせる。このサービス健全
性情報は、特定のプロバイダアプリケーションおよび性
能監視ツールセットから独立して生成され、それによ
り、サービス管理の解決策に対して、市場へ出るまでの
時間をより短くすることができる。

【０００９】当該方法の出力は、多数の異なるコンピュ
ータサービスの状態を報告することができる高レベルの
性能監視ツールによって使用される、プログラムまたは
スクリプト可能インタフェースの形式でもよい。性能監
視ツールは、種々のシステムやアーキテクチャに常駐し
てもよく、種々のベンダーによって供給されてもよい。
結果として、サービス健全性計量にアクセスするプログ
ラムまたはスクリプト可能インタフェースは、汎用的且
つ柔軟であるように設計される。

【００１０】装置は、サービスまたはサービスを構成す
るアプリケーションまたはプロセスから、情報を動的に
集めおよび／または導出することによって、およびアプ
リケーションが実行されるシステムに関する情報から、
サービスの健全性を判断する健全性生成モジュールを含
む。生成されるサービス健全性計量は、たとえば、サー
ビス使用可能度、サービス容量および現在のスループッ
トを含む。方法は、広範囲のサービスに対する一貫した
健全性計量を動的に導出する。健全性生成器への入力
は、種々のアプリケーション、その計測ソースおよび種
々のアプリケーションが、様々な外部要因によってどの
ように影響されるかについての知識を要約する。健全性
生成器の出力は、プログラムまたはスクリプト可能イン
タフェースを介してアクセスされてもよく、無関係の性
能監視ツールセットによって使用され得る。

【００１１】一貫したサービス健全性計量を作成する際
に、装置は、サービスを構成するアプリケーションおよ
びプロセスによって提供される計測、ユーザ入力から、
プラグイン計測およびシステムレベルの性能情報を使用
してもよい。計量がどのようなソースからも直接利用で
きない場合には、装置は、間接的なデータソースの組み
合わせから計量を導出してもよい。

【００１２】装置は、任意のサービスの健全性を特徴付
ける、限定された計量のセットを生成する。たとえば、
アプリケーションに関連する計測から導出され得る、種
々の潜在的に測定可能なパラメータの全ての代わりに、
１０より少ない特定の計量を、サービス健全性を包括的
に定義するように使用してもよい。１実施形態におい
て、計量のセットは、使用可能度、容量、現在のスルー
プット、現在の平均サービス時間、待ち行列長さ、全体
利用度、サービス違反およびユーザ満足度を含む。

【００１３】種々のソースからこれらの計量を取り入れ
るために、顧客からフィードバックを求め、サービスを
ベンチマークテストし、またはサービスを探索するよう
に装置および方法を使用してもよい。アプリケーション
に特有のパッケージを本質的に監視している、プラグイ
ンモジュールは、アプリケーションに特有の性能計測に
アクセスするように使用してもよい。どのように性能情
報が集められても、装置および方法は、集められた性能
情報または計量を健全性計量に変換する。結果は、健全
性計量がどのように導出されたかを知る必要なしに、性
能監視ツールが性能監視計量を使用することができるよ
うに、性能監視ツールに提供され得る、一貫したサービ
ス健全性計量の要約されたセットである。これにより、
性能ツールの実現が計量抽出から切り離され、サービ
ス、サービスの実現および管理ツールセットの間の依存
が取り除かれる。たとえば、ツールは、サービスレベル
違反が閾値より上昇したときに、警告を生成するように
生成されたサービスレベル違反計量を使用してもよい。
性能監視ツールは、サービス、サービスの計測またはサ
ービスレベル計量がどのように計算されたかについて何
も知るが必要がない。ツールは、単に結果としての計量
を、その閾値と比較する。性能監視ツールは、全ての現
在のサービスに対する健全性計量にアクセスするため
に、プログラムインタフェースライブラリ呼出しまたは
スクリプトインタフェースを使用する。基礎をなすアプ
リケーションが変化しても、この一貫したインタフェー
スのために、性能監視ツールの現在のバージョンは、影
響されない。結果として、システム管理者は、必ずし
も、性能監視ツールの新しいバージョンをインストール
する必要がない。このように、装置および方法は、管理
ソフトウェアのより高位のレベルまで依存を広めること
なく、拡張可能である。

【００１４】

【発明の実施の形態】詳細な説明は、図面を参照し、図
面において同様の符号は同様の項目に関係する。

【００１５】ネットワーク化されたコンピュータを含む
最近のコンピュータシステムおよびそれによって提供さ
れるサービスは、様々な理由により性能低下しやすい。
その理由の多くは、ディスクバンド幅、メモリ容量およ
び中央処理装置（ＣＰＵ）の利用を含む共用リソースの
使用に関する。情報技術（ＩＴ）システム管理者は、こ
れらの共用資源および他の共用資源の最適な割当てを保
証するように、これらのコンピュータシステムの性能を
追跡する。性能監視ソフトウェアは、システム性能を追
跡し問題を診断するのに必要なツールをシステム管理者
に提供する。性能監視ソフトウェアは、コンピュータシ
ステムについての即時の性能情報を提供し、管理者がコ
ンピュータシステムの活動を検査し、ボトルネックを識
別し且つ解決し、動作がより効率的になるようにコンピ
ュータシステムを調整できるようにしてもよい。システ
ム管理者は、これらの共用資源および他の共用資源の最
適な割当てを保証するように、これらのコンピュータシ
ステムの性能を追跡することに関心を有する。性能管理
ソフトウェアは、継続的にコンピュータシステム性能を
追跡し、問題を診断するのに必要なツールを管理者に提
供する。性能管理ソフトウェアは、コンピュータシステ
ムについての即時の性能情報を提供し、管理者がコンピ
ュータシステムの活動を検査し、ボトルネックを識別し
且つ解決し、動作がより効率的になるようにコンピュー
タシステムを調整できるようにしてもよい。

【００１６】様々なウェブおよびデータベースアプリケ
ーションからなることもある各サービスは、外部の監視
ソフトウェアに利用可能とされ得る内部状態計測を有す
るかもしれない。サービスの健全性の測定を個別に提供
するアプリケーションもあるが、アプリケーション環
境、プラットフォームが様々であり、新しいサービスの
開発ペースが速いので、いずれか１つの標準計測アプロ
ーチの汎用的な実現は、創造できそうもない。同様に、
市場において入手可能な監視ツールは、監視する必要が
ある、アプリケーションにおける、速いペースの特定の
変更に適応することができない。さらに、サービスは、
そのアプリケーションが動作する複雑なコンピュータ環
境を、めったに認識していない。外部ソースは、サービ
スに影響を与えるが、外部ソースは、統一された仕方で
監視され管理されることはない。その結果、サービスの
健全性は、しばしば、特徴付けたり報告することができ
ない。

【００１７】これらの問題を解決するために、観察下の
サービスに関する内部ソースおよび外部ソースの双方か
らの様々な計測を組み合わせて、一貫したサービス健全
性測定値を導出するために方法および装置が使用され
る。サービス健全性計量は、たとえば、アプリケーショ
ン、プロセスおよびスレッド計測から直接測定されても
よい。当該方法は、特定のプロバイダアプリケーション
および管理ツールセットから独立しており、したがって
サービス管理の解決策に対して、市場へ出るまでのより
短い時間を見込んでいる。

【００１８】当該方法のアウトプットは、多数の異なる
コンピュータサービスの状態を報告することができる高
レベル監視ツールによって使用されるプログラム可能イ
ンタフェースまたはスクリプト可能インタフェースのい
ずれかの形式であってもよい。当該ツールは、種々のシ
ステムおよびアーキテクチャに常駐してもよく、種々の
ベンダーによって供給されてもよい。種々の性能監視ツ
ールに対処するために、当該インタフェースは、汎用的
であり、柔軟である。

【００１９】図１は、サービスの健全性を提供するため
の全体的な概念を示すブロック図である。図１におい
て、サービス１１を構成するスレッド、プロセスおよび
アプリケーションに固有のインタフェースが、健全性発
生器１０によってアクセスされる。健全性発生器１０
は、当該サービス１１に関する性能情報１２を導出す
る。性能情報１２は、性能に関する１つまたは複数の計
量を含んでもよい。健全性発生器１０は、性能情報１２
を、最終消費者１３によってアクセスすることができる
健全性計量１４の一貫したセットに変換する。最終消費
者１３は、サービス１１の性能を監視するように意図さ
れ、アラーム、警報を生成し、グラフィカルユーザイン
タフェース（ＧＵＩ）を介して健全性データを表示する
性能監視ツールセットでもよい。性能監視ツールセット
は、１つまたは複数の特定の性能監視ツールを含んでも
よい。

【００２０】図１に説明された概念において、サービス
の健全性は、別個の部分からなる計量セットによって定
量化されてもよい。サービスの健全性を完全に、または
少なくとも十分に定義するために、たとえば８個の計量
が導出される。図２は、サービスの色々なグループの健
全性を特徴付けるのに使用される８個の計量のセットを
示すブロック図である。計量は、以下を含む。

【００２１】使用可能度は、サービスが現在動作可能で
あるかどうかの２値の指示（「アップ」または「ダウ
ン」）である。

【００２２】容量は、現時点におけるサービスの最大ス
ループットの指示である。容量は、外部要因および内部
構成により時間にわたり変化する。

【００２３】スループットは、サービストランザクショ
ンレートである。現時点においてサービスによってどの
くらいの仕事が行われているかの指示である。通常、適
切な収集間隔にわたる平均である。

【００２４】サービス時間は、トランザクションごと
の、平均の現在のクロック時間である。

【００２５】待ち行列長さは、収集間隔にわたり、サー
ビスを待って待ち行列に置かれるトランザクションの平
均数である。

【００２６】利用度は、サービスがその容量に関係する
場合におけるサービスの現在のスループットのパーセン
ト表示である。

【００２７】サービスレベル違反について、サービスレ
ベルの目標がサービスに対して示されていれば、測定間
隔にわたる違反回数は、指定されたサービス時間を超え
るトランザクションの数である。この計量は、トランザ
クション分布レベル（たとえば、「遅い」および「非常
に遅い」）を区別するのに使用することができる複数の
サービス目標の定義を考慮している。また、サービス内
の種々のタイプのトランザクションまたはサービスの種
々の最終ユーザに対して、種々のサービスの品質（ＱＯ
Ｓ）の目標があり得ることに留意されたい。このよう
に、各々が種々のＱＯＳカテゴリに対応する、複数のサ
ービスレベルがあり得る。たとえば、「プラチナ」高優
先度ユーザは、通常の低優先度ユーザよりもより限定的
なサービスレベルを有し得る。

【００２８】ユーザ満足度は、要求されたサービスを提
供するシステムの相対的な能力についてのサービス消費
者からの指示である。この計量は、使用可能度の拡張で
あり、ユーザの観点からサービスの性能を判断する共通
のスケールを提供する。ある実施形態では、コンピュー
タシステムのユーザに質問を提出し、顧客の応答を記録
することによってユーザ満足度を測定してもよい。たと
えば、ウェブサービスは、サービスの応答性について、
ユーザがどのくらい「満足している」かについて、ウェ
ブページにアクセスした１００人目のユーザごとに問い
合わせる、サービスのウェブページ上の会話型ウィンド
ウを含み得る。ユーザに対して、「すばらしい」、「Ｏ
Ｋ」および「遅すぎる」などの応答のリストから選択す
るように頼んでもよい。収集された応答は、ユーザ満足
度を判断するために有用な計量であるが、サービスの品
質カテゴリにしたがってスケールする必要もあるかもし
れない。

【００２９】図２に示した計量は十分であるが、サービ
スの健全性の詳細をさらに定義するために他の計量を追
加してもよい。１２個の計量を使用することを後で詳細
に記述する。

【００３０】図３は、システム１００において処理され
るサービスの健全性を判断するために、健全性生成アル
ゴリズムを使用するシステム１００の全体ブロック図で
ある。図３において、健全性生成器１０に入力される性
能情報１２を生成するように、サービス１１をインスタ
ンス生成するアプリケーション内の計測ソースがアクセ
スされる。健全性生成器１０は、性能監視ツールセット
として図３に示される、最終消費者１３に出力健全性デ
ータ１４を提供する。最終消費者１３と健全性生成器１
０の間には、共用メモリインプリメンテーション１０７
および健全性アプリケーションプログラムインタフェー
ス（ＡＰＩ）すなわちスクリプト可能インタフェース１
０８が置かれている。共用メモリインプリメンテーショ
ン１０７は、たとえば、健全性ＡＰＩ１０８を介してア
クセス可能なデータ記憶装置を提供する。

【００３１】共用メモリインプリメンテーション１０７
は、健全性データ１４を記憶する。その結果、性能監視
ツールセットの中の任意の性能管理ツールは、健全性デ
ータ１４にアクセスし、性能監視ツールセットの設計と
一貫した間隔でアクセスし得る。たとえば、第１のベン
ダーは、性能情報を報告する、第２のベンダーと異なっ
たエージェントを有するかもしれない。双方のベンダー
ツールは、非同期且つ異なった時間間隔で同じ健全性デ
ータ１４を得るように、共通のＡＰＩライブラリを介し
て共用メモリインプリメンテーション１０７にアクセス
し得る。共用メモリインプリメンテーション１０７は、
アクセスのためのＡＰＩライブラリとともに、複数の消
費者の要求に対処する。

【００３２】コンピュータシステム１００は、また、オ
ペレーティングシステム１０３および他の外部データソ
ース１０１とともに示されている。オペレーティングシ
ステム１０３における様々なサブシステムの性能は、サ
ービス１１のいずれかのサービスの健全性に影響し、健
全性を示し得る。したがって、オペレーティングシステ
ム１０３は、健全性生成器１０に性能情報を提供し得
る。他のデータソース１０１は、特定のサービス１１に
無関係のアプリケーション１０４からの計量、または独
立したプローブまたはセンサ１０５からの応答時間デー
タを含んでもよい。

【００３３】データソース１０１および１０３乃至１０
５の例は、性能情報を報告するために使用され得る技術
およびプログラムを含む。これらの技術およびプログラ
ムは、顧客、ユーザまたはサービスに依存する他のサー
ビスからの、サービスの応答の直接測定値であるユーザ
アプリケーション応答を含む。このデータを提供するた
めに、（アプリケーション応答測定（ＡＲＭ）業規格な
どの）様々な計測パッケージを使用することができる。

【００３４】性能情報は、また、プラグイン計測によっ
て供給され得る。多くのアプリケーションは、アプリケ
ーションに専用にカスタマイズされたプラグインモジュ
ールを有する。プラグインモジュールは、状態を提供す
るために性能監視ツールによって使用される。実例は、
データベースパッケージ内で利用可能な監視パッケージ
である。これらのプラグインモジュールは、インプリメ
ンテーション、インタフェースおよび応用性において様
々である。柔軟なインタフェースによって、外部から供
給されるプラグインまたは基礎をなすアプリケーション
に対して変更する必要なく、健全性生成器１０に対する
ソースとしてプラグイン計測データを使用することがで
きる。

【００３５】データは、また、たとえばサーベイ１０２
から人手によって集めることができる。全てのソース１
１および１０１乃至１０４から集めたデータは、健全性
データ１４を作成するために健全性生成器１０によって
使用される。

【００３６】図４は、健全性生成器１０の例示的なブロ
ック図である。１乃至多数の独立したデータ収集エンジ
ン１２１の集まりが、サービス計測１１、ＯＳ計測１０
３および外部ソース１０１から性能情報１２を集める。
データ収集エンジン１２１は、後で詳細に説明する。間
隔管理エンジン１２３は、種々のデータソースが調整さ
れることを保証する。収集された情報は、データ解析エ
ンジン１２５に渡される。データ解析エンジン１２５
は、入力データの公表される健全性計量１４への変換を
管理する規則のセット１２７を適用する。たとえば、サ
ービス時間健全性計量１４を管理する特定の規則１２７
に影響を及ぼすように、アプリケーション応答測定（Ａ
ＲＭ）データのための特定応答時間データ収集エンジン
１２１が使用されてもよい。

【００３７】図５は、データ収集エンジン１２１のブロ
ック図である。健全性生成器１０は、多数のデータ収集
エンジン１２１を含み得ることに留意されたい。データ
収集エンジン１２１の各々は、別個のプロセスまたはス
レッドでもよく、種々の健全性計量または性能計量に関
するデータを収集するのに専用であってもよい。データ
エンジンの各々は、特定のデータソースから情報を取得
し、（間隔管理エンジン１２３を経由して）取得したデ
ータをデータ解析エンジン１２５に提供してもよい。

【００３８】データ収集エンジン１２１の各々は、特定
のソースから情報を収集または導出する、１または複数
の入力機構およびコンポーネントを含んでもよい。入力
機構は、データクエリーモジュール１３１およびデータ
導出モジュール１３３を含む。データクエリーモジュー
ル１３１は、データソースが自身の性能の測定を提供す
る場合に使用されてもよい。たとえば、応答時間のよう
な性能情報を提供するようにサービスが計測されるとき
に、健全性生成器１０は、そのままの形式でまたは、修
正または要約されたフォーマットのいずれかで、当該性
能データを使用してもよい。

【００３９】サービスが、性能情報を提供するために計
測されないときまたは報告される性能情報が使用可能な
フォーマットではないときは、データソースから所望の
性能情報を抽出するためにデータ導出モジュール１３３
を使用してもよい。データ導出モジュール１３３は、サ
ービスから情報を抽出する既知の方法に関連して機能し
てもよい。そのような方法の１つは、性能情報を抽出す
るためにラッパプログラムを書くことを含む。ラッパ
は、データ収集エンジン１２１と監視されるサービスと
の間に挿入されるソフトウェアレイヤである。サービス
においてトランザクションが起きるたびに、ラッパを通
して情報が渡される。ラッパは、情報を受け取り、当該
情報をデータ収集エンジンに渡す。たとえば、ラッパ
は、データベースアプリケーションに対して書かれても
よい。データベース呼出しが行われるたびに、呼出しが
ラッパを通過する。呼出しの伝送の際に、ラッパは開始
時間を記録する。データベース呼出しが完了すると、ラ
ッパは停止時間を記録する。開始時間と停止時間の間の
差が計算され、性能計量または性能計量に対する入力と
して報告される。データを抽出する他の方法は、双方と
も当該技術分野において既知の、ベンチマークプログラ
ムの使用およびプローブプログラムの使用を含む。

【００４０】図４に戻り、データ解析エンジン１２５
は、収集された性能情報を図２に示される出力計量１４
に関係付けるように、データ収集エンジン１２１からの
データにアクセスする。特に、データ解析エンジン１２
５は、ユーザが修正可能な規則のセット１２７にしたが
って、どの収集されたパラメータが特定の出力計量に関
連するかを判断する。データ解析エンジン１２５は、特
定の収集された計量が１つまたは複数の出力計量に関連
すべきであると判断してもよい。

【００４１】間隔管理エンジン１２３は、種々の報告時
間、間隔および性能監視ツールの種々のデータ読取り要
求を伴う計量に対処する。すなわち、健全性生成器１０
によって実行される入力取り入れおよび出力生成は、非
同期に進行する必要があるかもしれないので、結果の一
貫性を保証するために、間隔管理が必要となるかもしれ
ない。たとえば、性能監視ツールが期待する時間間隔に
関連する性能監視ツールに対して健全性データ１４を提
供するために、入力データに対して何らかの要約が行わ
れる必要があるかもしれない。より具体的には、データ
ベースアプリケーションは、計量データを３０秒ごとに
１回提供してもよい。しかしながら、性能監視ツール
は、性能情報を５分ごとに要求するかもしれない。結果
として、健全性生成器１０は、性能監視ツールがデータ
の報告を要求するごとに、データの１０個のサンプルを
得る。数個の種々の性能監視ツールがデータにアクセス
するとき、この問題はより悪化する。種々の性能監視ツ
ールは、すべて、健全性生成器１０の出力に種々の制約
を課すかもしれない。その結果、非同期の方法は、結果
の一貫性を保証するように要求されるかもしれない。結
果として、たとえば、１つの間隔の間に解析エンジンに
よって、データが数回処理されていれば、データを要約
する必要があるかもしれない。

【００４２】規則のセット１２７は、データ収集エンジ
ン１２１によって供給される計量を性能監視ツールによ
って使用することができる汎用のフォーマットに変換す
るアルゴリズムおよび規則を提供する。いずれかの収集
された（すなわち、計測アクセスされ、または導出され
た）情報は、図２に示す８個の計量の１つに一致するよ
うに変換されてもよい。サービスが計測されるシステム
を使用するならば、応答時間を報告するようにシステム
が計測されてもよい。たとえば、ＡＲＭエージェント平
均応答時間が、データ収集エンジン１２１によって収集
されるならば、収集される情報は、サービス時間出力計
量に変換されてもよい。他の規則がサービス時間に適用
できなければ、ＡＲＭエージェント入力は、サービス時
間計量をもっぱら支配し、規則１２７はどのような変換
も実行しない。

【００４３】適用されてもよい他の規則は、評価方式で
ある。たとえば、サービス時間は、サービス時間計量の
主要なコンポーネントとして、リモートＮＦＳサーバか
ら導出されてもよい。導出されたサービス時間は、ＡＲ
Ｍデータのような、サービス時間計量のより直接的な測
定値に対して評価されてもよい。

【００４４】他の規則は、特定の性能パラメータに対し
て値を平均し、要約し、加算し減算することを含んでも
よい。たとえば、サービス健全性は、オペレーティング
システムのリソースがどのくらい忙しいかに依存しても
よい。たとえば、システムが１つのサービスに対して完
全に専用であれば、利用度計量は、全体としてのＯＳリ
ソースの利用度からなってもよい。ＣＰＵまたはディス
クＩ／Ｏパスが完全に利用されていれば、サービス自身
もそうである。このように、利用度サービス健全性計量
は、ＣＰＵ利用度またはディスクＩ／Ｏ利用度のいずれ
かの最高値によって導出される。この場合には、データ
解析エンジン１２５は、ＣＰＵ利用度とディスク利用度
とを、サービス利用度である１つの出力計量に組み合わ
せる。

【００４５】健全性生成プロセスの出力は、ＡＰＩイン
タフェースまたはスクリプト可能インタフェースを介し
てアクセス可能である、共用メモリインプリメンテーシ
ョン１０７を使用して利用可能とされる。その結果、種
々の性能管理ツールが、それぞれ自身の間隔で、サービ
ス健全性データ１４について同時に質問することができ
る。データに対するインタフェースを公表することによ
り、健全性データ１４の消費者は、健全性生成器１０に
おいて使用される健全性アルゴリズムの存在またはバー
ジョンに依存しない。このように、監視ツールセット
は、監視されている特定のアプリケーションから切り離
される。健全性生成器１０の出力を使用する性能管理ツ
ールは、特定のサービスに対する変更に基いて改定され
る必要はない。その代わりに、既存の入力機構を新しい
データを収集するように構成し、規則をこの機能を提供
するように追加または変更することができる。

【００４６】図６は、図３のシステムまたは同様の上で
処理される、サービスの健全性を抽出するためのプロセ
ス２００を説明する流れ図である。プロセス２００は、
ブロック２０１で開始する。

【００４７】入力収集ブロック２０３において、収集エ
ンジン１２１は、このシステムで処理される１または複
数のサービスに関連し、提供される性能情報を読み出
す。性能情報は、応答時間、待ち行列長さまたはサービ
スの性能に関する他の情報を含んでもよい。性能情報
は、サービスによって供給され、または外部から導出さ
れる計測によって提供されてもよい。

【００４８】計量変換ブロック２０７において、収集さ
れた性能情報は解析され、健全性データ１４を提供する
ように、収集された情報を、健全性生成器１０によって
使用される出力データ方式で一貫したフォーマットを有
する計量に変換するように、解析エンジン１２５によっ
て適切な規則１２７が適用される。１実施形態におい
て、健全性データ１４は、図２において示される８個の
計量を含んでもよい。このように、どのような収集され
た情報も８個の計量の内の１つに一致するように変換さ
れてもよい。たとえば、サービスを構成する特定のアプ
リケーションによってフィルターをかけられたＡＲＭエ
ージェント平均応答時間がデータ収集エンジン１２１に
よって収集されるならば、収集された情報は、当該サー
ビスに対するサービス時間出力計量に変換されてもよ
い。他の規則がサービス時間に適用できなければ、ＡＲ
Ｍエージェント入力は、サービス時間計量をもっぱら支
配し、規則１２７はどのような変換も実行しない。適用
され得る他の規則は、いくつかの種々の収集器からの入
力を組み合わせる評価方式を含む。

【００４９】サービスに対する全ての計量が定義され、
対応する性能情報が集められるか導出されると、ブロッ
ク２０９において、結果としての健全性データ１４出力
が、共用メモリインプリメンテーション１０７に提供さ
れる。上述したように、出力インタフェースは、ＡＰＩ
インタフェースまたはスクリプト可能インタフェースで
あってもよい。本方法によれば、複数且つ種々の性能監
視ツールが、当該性能監視ツールの設計に対応する間隔
で、健全性データ１４にいて同時に質問することができ
る。健全性データ１４へのアクセスおよび健全性データ
１４の使用は、健全性データ１４を収集するのに使用さ
れる方法および健全性データ１４が記憶される仕方と独
立している。ブロック２１１において、プロセスは終了
する。

【００５０】本発明の態様について以下に例示する。

【００５１】１．ホストマシンに常駐するサービスの健
全性を動的に判断するための方法であって、サービスか
らサービス性能情報を収集し（２０３）、収集されたサ
ービス情報を汎用的な出力に変換する（２０７）方法。

【００５２】２．ホストマシンが、１または複数のコン
ポーネントを備え、当該１または複数のコンポーネント
の内の１または複数から外部性能情報を収集し、収集さ
れた外部性能情報を変換し、汎用的な出力を提供するよ
うに、変換された外部性能情報およびサービス情報を組
み合わせることをさらに含む上記１に記載の方法。

【００５３】３．汎用的な出力がスクリプト可能インタ
フェースおよびアプリケーションプログラムインタフェ
ースの内の１つを含み、上記収集することが、サービス
によって提供される性能情報を読み出すことおよびサー
ビスから性能情報を導出することの内の１つを含む上記
１に記載の方法。

【００５４】４．上記導出することが、性能情報を読み
出すラッパプログラムを使用することおよび性能情報を
読み出すプローブプログラムを使用することの内の少な
くとも１つを備え、収集されたサービス情報が複数の性
能計量（１２）に関係し、汎用的な出力が複数のサービ
ス健全性計量（１４）を含み、変換することが、当該複
数のサービス健全性計量の内の１または複数を提供する
ように、当該複数の性能計量の内の１または複数を組み
合わせることを含む上記３に記載の方法。

【００５５】５．複数のサービス健全性計量（１４）
が、使用可能度、容量、スループット、サービス時間、
待ち行列長さ、利用度、サービスレベル違反およびユー
ザ満足度を含む上記４に記載の方法。

【００５６】６．ホストマシンに常駐するサービスの健
全性を判断する装置（１０）であって、サービス健全性
情報を収集するデータ収集エンジン（１２１）と、収集
されたサービス健全性情報を、健全性生成アルゴリズム
を使用して変換し、１または複数の汎用的な健全性計量
を提供する変換エンジン（１２５）とを備える装置。

【００５７】７．ホストマシンが１または複数の外部コ
ンポーネントを備え、データ収集エンジンは、当該１ま
たは複数の外部コンポーネントのうちの１または複数か
ら外部性能情報を収集し、変換エンジンは、１または複
数の汎用的な健全性計量を提供するように、健全性生成
アルゴリズムを使用して、収集された外部情報を変換す
る上記６に記載の装置。

【００５８】８．データ収集エンジン（１２１）は、サ
ービスから性能情報を読み出すデータクエリーモジュー
ル（１３１）と、サービスから性能情報を導出するデー
タ導出モジュール（１３１）とを備える上記６に記載の
装置。

【００５９】９．データ導出モジュールは、ラッパプロ
グラム、ベンチマークプログラムおよびプローブプログ
ラムの内の１または複数から性能情報を導出する上記８
に記載の装置。

【００６０】１０．健全性生成アルゴリズムは、１また
は複数の性能情報パラメータを評価する評価方式と、１
または複数の性能情報パラメータを組み合わせる要約方
式と、サービス健全性計量に対して、収集された健全性
情報を平均する平均方式とを含む上記６に記載の装置。

【図面の簡単な説明】

【図１】サービスまたはアプリケーションの健全性を提
供するための全体的な概念を示すブロック図である。

【図２】サービスまたはアプリケーションの健全性を測
定する性能計量のブロック図である。

【図３】システムで処理される、サービスの健全性を判
断する健全性生成アルゴリズムを使用するシステムの全
体的なブロック図である。

【図４】図３からの、サービスの健全性を提供する装置
のブロック図である。

【図５】図３の装置とともに使用されるデータ収集エン
ジンのブロック図である。

【図６】図３のシステムで処理される、サービスの健全
性を抽出する方法を説明する流れ図である。

【符号の説明】

１０ 健全性生成器 １２１ データ収集エンジン １２３ 間隔管理エンジン １２５ データ解析エンジン

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ダグ・グルマン アメリカ合衆国95610カリフォルニア州シ トラス・ハイツ、ダブリン・ウェイ 6019 (72)発明者 スティーブン・アール・ランダー アメリカ合衆国75214テキサス州ダラス、 ランジ・サークル 6329 (72)発明者 トーマス・イー・トゥリッチ・ジュニア アメリカ合衆国75206テキサス州ダラス、 マッコマス・ブールバード 5903 Ｆターム(参考） 5B042 HH20 MA09 MA14 MC23 MC29 MC32

Claims (1)

【特許請求の範囲】
1. 【請求項１】 ホストマシンに常駐するサービスの健全
   性を動的に判断するための方法であって、 サービスからサービス性能情報を収集し、 収集されたサービス情報を汎用的な出力に変換する方
   法。