JP2007026303A - システム性能監視プログラム及びシステム性能監視方法 - Google Patents

Abstract

【課題】 任意のタイミング、所望の状況下で性能監視を行う。
【解決手段】 観測手段１ａは、サーバ３ａ、３ｂ、３ｃ、・・・の動作状態に関する観測情報を収集し、観測情報記憶手段１ｃに格納する。そして、性能の測定に必要な観測情報に不足があれば、アクセス発生手段１ｂに観測情報を取得可能にする所定のアクセスを指示する。アクセス発生手段１ｂが所定のアクセスを発生させると、不足する観測情報に対応する観測可能状況が作り出され、観測情報が生成される。観測手段１ａは、このときの観測情報を収集し、観測情報記憶手段１ｃに格納する。こうして、観測情報記憶手段１ｃに観測情報が揃うと、性能評価手段１ｄにより、必要な観測情報が読み出され、性能測定が行われて性能基準を満たしているかどうかが評価される。
【選択図】 図１

Description

本発明はシステム性能監視プログラム及びシステム性能監視方法に関し、特に複数のサーバがネットワークによって接続され、所定のサービスを行うサーバシステムの性能を監視するシステム性能監視プログラム及びシステム性能監視方法に関する。

アウトソーシングサービスなどに利用されるサーバシステムでは、クライアントが処理要求を発してからそのサーバシステムの応答（レスポンス）を受けるまでの応答時間などのサービスレベルが予め契約などで定められている場合が多い。このため、定められたサービスレベルが維持されているかどうかといった、システム性能の監視が必須となっている。

図１５は、従来の代表的なシステム性能監視装置の例を示した図である。
図に示したサーバシステムでは、複数のクライアント９４１で構成されるユーザ９４０側から、複数のサーバ９３１、サーバ９３２及びサーバ９３３で構成されるシステム９３０側に対し、所定のサービスを利用するための各種アクセスが発生している。このようなサーバシステムにおけるシステム性能を監視するため、従来は、システム９３０内部で監視を行う内部監視装置９０１、または、システム９３０外部から監視を行うシステム性能監視装置９０２が設けられていた。双方がともに設置される場合もある。

内部監視装置９０１は、システム９３０内部に設置され、たとえば、モニタリング用エージェントによって、システム９３０内部での応答時間を計測する。一方、外部のシステム性能監視装置９０２は、監視用クライアント９１２が、たとえば、契約で定められたサービスを定期的にアクセスし、応答が得られるまでに要する時間が規定の応答時間に収まっているかをチェックする。

また、サーバシステムは、アクセスの増加に追随して処理の多重度を上げてスループットの向上を図っており、アクセスの集中によってレスポンス処理が低下して実用的でないレベルまで処理速度が遅くなることがある。そこで、応答時間を計測するのではなく、処理多重度と応答時間の関係を予め求め、サーバシステムの処理の多重度を示すシステムパラメータを監視することによって、サーバシステムの稼動状況を監視するシステムが提案されている。（たとえば、特許文献１参照）。
特開２００４−３０２５４７号公報（段落番号〔００４６〕〜〔００７７〕、図３）

しかし、従来のシステム性能監視技術は、システム９３０の外部に設けたシステム性能監視装置９０２による観測では、定期的に行われるアクセスの時間帯以外の状況がわからないという問題点がある。たとえば、ピーク時間帯や通常時間帯など、システムの状況によって応答時間は変化するが、外部のシステム性能監視装置９０２はシステムの状況によらずアクセスを行うので、これらの時間帯を区別して分析することができない。また、応答時間が長くなるなど、サービスレベルの低下が検出されても、システム内部に原因があるのか、時間帯によるものなのかなど、原因やその後の推移の予測ができないという問題点もある。特に、近年では、システムが大規模化しており、原因と推定される要素も多岐に渡り、原因の特定は容易ではない。

一方、システム９３０内部に設けた内部監視装置９０１による観測は受動的な観測であり、特定のサービスについてレスポンスを計測したい場合には、そのサービスに対するアクセスが発生するのを待つ必要があった。これは、処理多重度を用いて監視する場合にも同様で、所望の処理多重度の状況となるまで待つ必要があった。このように、任意のタイミング、または所望の状況下で観測を行うことができないという問題がある。

また、ユーザ視点での応答時間、すなわち、クライアント９４１が要求を出してから応答を得るまでの時間を計測することができないという問題もある。
このように、従来の技術では、システム内部の稼動状況に応じた任意のタイミング、かつ所望の多重度、パターンにおける対象のサービスに関する応答時間や、ＣＰＵ（Central Processing Unit）処理時間の監視など、きめ細かな監視が難しいという問題点がある。

本発明はこのような点に鑑みてなされたものであり、任意のタイミング、所望の状況下で性能監視を行うことが可能なシステム性能監視プログラム及びシステム性能監視方法を提供することを目的とする。また、本発明の他の目的は、観測情報を分析し、ピーク時のサービスレベル予測を行うシステム性能監視プログラム及びシステム性能監視方法にある。

本発明では上記課題を解決するために、図１に示すような、複数のサーバが接続されるサーバシステムの性能を監視するためのシステム性能監視プログラムが提供される。コンピュータが、このシステム性能監視プログラムを実行することにより、図１に示すような各処理機能を実現することができる。ここで、サーバ３ａ、３ｂ、３ｃ、・・・は、互いに連携して所定のサービスを実行するサーバシステムを構成する。

観測手段１ａは、サーバ３ａ、３ｂ、３ｃ、・・・の動作状態に関する観測情報を取得し、観測情報記憶手段１ｃに格納する。このとき、性能の測定に必要な観測情報に不足があれば、不足する観測情報に応じた観測可能状況をサーバ３ａ、３ｂ、３ｃ、・・・に発生させる所定のアクセスを指示し、発生した所定のアクセスに応じて作成される観測情報を取得して観測情報記憶手段１ｃに格納する。アクセス発生手段１ｂは、観測手段１ａからの所定のアクセス指示を取得すると、指示に従って、サーバ３ａ、３ｂ、３ｃ、・・・に対して所定のアクセスを行って、不足する観測情報の生成が可能な観測可能状況を発生させる。性能評価手段１ｄは、観測情報記憶手段１ｃに格納される観測情報を分析して性能を測定し、サーバ３ａ、３ｂ、３ｃ、・・・より成るサーバシステムが所定の性能基準を満たしているかどうか評価する。

このようなシステム性能監視プログラムをコンピュータに実行させることで、観測手段１ａにより、サーバ３ａ、３ｂ、３ｃ、・・・の動作状態に関する観測情報が収集され、観測情報記憶手段１ｃに格納される。このとき、観測手段１ａは、性能測定に必要な観測情報に不足があれば、不足する観測情報に応じた観測可能状況をサーバ３ａ、３ｂ、３ｃ、・・・に発生させることのできる所定のアクセスをアクセス発生手段１ｂに指示する。アクセス発生手段１ｂが、指示された所定のアクセスを行うことで、不足する観測情報の生成が可能となる観測可能状況がサーバ３ａ、３ｂ、３ｃ、・・・に発生し、これに伴って観測情報が生成される。観測手段１ａは、この観測情報を収集し、観測情報記憶手段１ｃに格納する。こうして観測情報記憶手段１ｃに観測情報が揃うと、性能評価手段１ｄは、観測情報記憶手段１ｃに格納される観測情報を分析して性能を測定し、測定された性能が予め決められた性能基準を満たしているかどうかを評価する。

また、上記課題を解決するために、複数のサーバがネットワークによって接続されて所定のサービスを行うサーバシステムの性能を監視するシステム性能監視方法において、観測手段が、前記サーバシステムの動作状態に関する観測情報を取得して観測情報記憶手段に格納するとともに、性能測定に必要な前記観測情報に不足があれば、不足する前記観測情報に応じた状況を前記サーバシステムに発生させる所定のアクセスを指示し、アクセス発生手段が、前記観測手段から前記所定のアクセス指示を取得すると、前記ネットワークを介して前記サーバシステムに対して前記所定のアクセスを行って、前記サーバシステムに前記観測情報に応じた状況を発生させ、前記観測手段が、前記所定のアクセスに応じて生成される前記観測情報を取得して前記観測情報記憶手段に格納し、性能評価手段が、前記観測情報記憶手段に格納される前記観測情報を分析して性能を測定し、前記サーバシステムが所定の性能基準を満たしているかどうかを評価する、ことを特徴とするシステム性能監視方法、が提供される。

このようなシステム性能監視方法によれば、システムの性能測定のため収集された観測情報に不足がある場合には、不足する観測情報に対応するアクセスを発生させることにより、所望の観測情報を得る。そして、収集された観測情報に基づき、サーバシステムの性能を測定し、性能基準を満たしているかどうか評価される。

本発明では、所定の性能の測定に必要な観測情報が不足する場合、不足する観測情報を生成するための所定のアクセスを任意のタイミングで発生させることにより、観測したい状況（多重度、アクセスのパターンなど）を作り出し、所望の観測情報を獲得する。したがって、任意のタイミング、所望の状況下での観測情報の取得が可能となり、取得した観測情報により監視対象のサービスレベルを維持できているかどうかを任意に検証することができる。

以下、本発明の実施の形態を図面を参照して説明する。まず、実施の形態に適用される発明の概念について説明し、その後、実施の形態の具体的な内容を説明する。
図１は、実施の形態に適用される発明の概念図である。

システム３側のサーバ３ａ、３ｂ、３ｃ、・・・は、ネットワーク２を介して、ユーザ４側のクライアント４ａ、４ｂ、４ｃ、・・・と接続されている。サーバ３ａ、３ｂ、３ｃ、・・・は、クライアント４ａ、４ｂ、４ｃ、・・・からの要求に応じて所定のサービスを提供する。また、複数のサーバ３ａ、３ｂ、３ｃ、・・・は、システム３内部のネットワーク（以下、内部ネットワークとする）によって接続し、互いに連携してサービスの提供を行っている。システム性能監視装置１は、システム３側の内部ネットワークに接続し、必要に応じて、ネットワーク２にも接続する。

システム性能監視装置１は、システム３の内部ネットワークに接続してサーバ３ａ、３ｂ、３ｃ、・・・の動作状態を観測した観測情報を取得・分析し、サーバシステムが所定の性能基準を満たしているかどうかを監視している。このため、システム性能監視装置１は、観測手段１ａ、アクセス発生手段１ｂ、観測情報記憶手段１ｃ、性能評価手段１ｄ、維持予測手段１ｅ及び出力手段１ｆを具備する。

なお、詳細は後述するが、システム性能監視装置１は、アクセス発生手段１ｂをシステム３外部のユーザ４側に設ける構成とすることもできる。
観測手段１ａは、システム３の状態を把握するため、各サーバ３ａ、３ｂ、３ｃ、・・・の内部の動作状態に関する観測情報を収集する。たとえば、サーバ３ａ、３ｂ、３ｃ、・・・にエージェントを設け、エージェントにＣＰＵ利用率、アクセスの多重度、個々のアクセスに関する情報を観測させ、生成される観測情報を観測手段１ａが収集する。また、サーバ３ａ、３ｂ、３ｃ、・・・を接続する内部ネットワーク途中のスイッチのミラーポートを利用してサーバで受け渡されるパケットデータを取得し、これを解析してサービス種別（ＵＲＬ；Uniform Resource Locators）、サービス数、応答時間などの情報を観測情報として得ることもできる。収集した観測情報は、観測情報記憶手段１ｃに格納され、データベースとして管理される。観測手段１ａは、さらに、性能を測定するために必要な観測情報に不足はないかどうか、観測情報記憶手段１ｃに格納される観測情報を調べる。そして、不足した観測情報がある場合には、その観測情報がアクセス発生手段１ｂからの所定のアクセスによって生成可能なものであれば、その所定のアクセスをアクセス発生手段１ｂに指示する。そしてこの所定のアクセスに応じて生成される観測情報を収集し、観測情報記憶手段１ｃに格納する。

アクセス発生手段１ｂは、観測手段１ａからの所定のアクセス指示を受ける。アクセス指示には、発生させるアクセスのパターンや、発生のタイミングが指示される。そこで、指示に従って、サーバ３ａ、３ｂ、３ｃ、・・・に向けてアクセスを発生させることによって、サーバシステムに不足する観測情報に対応する観測が可能な状況を発生させる。たとえば、所定のサービスに関する観測情報が不足する場合には、この所定のサービスを要求するサービス要求アクセスを発生させ、サーバ３ａ、３ｂ、３ｃ、・・・に所定のサービス処理を実行させる。なお、アクセスは、１種類または１回だけでなく、複数のアクセス手順から成るパターンで発生させることもできる。たとえば、あるサービスと別のサービスを連続して発生させたい場合には、そのパターンと発生タイミングを指定することができる。また、所定の多重度のときの観測情報が不足する場合には、所望の多重度を作り出すようにアクセス指示が設定される。このとき、現在の要求の多重度に応じて、所望の多重度に不足する分のアクセスのみを発生させるように、指示することができる。そのほか、様々な設定を行うことにより、サーバシステムに観測したい状況を作り出すことができる。

観測情報記憶手段１ｃは、観測手段１ａが取得した監視対象のサーバ３ａ、３ｂ、３ｃ、・・・の観測情報を格納する記憶装置である。
性能評価手段１ｄは、観測手段１ａによって収集され観測情報記憶手段１ｃに格納される観測情報のうち、現在の状態を表す観測情報を読み出して解析し、性能を測定する。そして、測定された性能値を予め設定された性能基準と比較し、要求される性能基準を満たしているかどうかを評価する。たとえば、サービスごとの応答時間が監視対象である場合には、観測情報をサービスごとに分類して分析し、サービスごとの応答時間の最大値を算出する。そして、性能基準を満たしているか否かを分ける性能基準の限界値と算出された最大値を比較し、判定を行う。このように、性能評価手段１ｄは、現在のサーバシステムの性能を評価する機能を有する。

維持予測手段１ｅは、観測情報記憶手段１ｃに格納されるこれまでに収集された観測情報に基づいて、性能を示す性能パラメータの予測モデルを作成する。観測情報記憶手段１ｃから予測モデルの作成に必要な観測情報が読み出される。たとえば、性能パラメータの１日の動きを表す予測モデルを過去１日分の観測情報を利用して作成する場合には、過去１日分の観測情報が読み出される。そして、性能パラメータと、観測情報に含まれる所定のデータ項目との対応関係に基づき、性能パラメータを所定のデータ項目の関数で表した予測モデルを生成する。たとえば、応答時間を性能パラメータとし、多重度との関係モデルを作成するため、これまでに収集された観測情報記憶手段１ｃから多重度と、その多重度の間に処理された、または処理途中であったアクセスの最大応答時間とを抽出し、これらを用いて応答時間を多重度の関数として表す。そして、作成された予測モデルに要求される性能基準の限界値を適用することによって、サービスレベルを維持可能な多重度の値範囲を決める。このようにして算出された値範囲と現時のデータ値を比較し、現時のデータが値範囲に収まっていれば、サービスレベルが維持されていると判断できる。また、現時のデータが値範囲の境界付近にあれば、サービスレベルが維持できなくなる可能性があるという判断ができる。このように、維持予測手段１ｅは、現時のシステム状態からサービスレベルが維持できなくなる可能性を判定するための情報を設定する機能を有する。

出力手段１ｆは、性能評価手段１ｄが行った評価結果や、維持予測手段１ｅが行った予測結果を管理者に提供するため、これらの情報を表示装置などの出力装置に応じたデータに変換し、出力装置に出力する。また、必要に応じて、電子メールなどの手段により管理者に通知するようにしてもよい。

このようなシステム性能監視装置１によれば、観測手段１ａは、所定の周期ごとや、予め決められた観測開始条件が満たされた場合などにサーバ３ａ、３ｂ、３ｃ、・・・の動作状態を示す観測情報を取得し、観測情報記憶手段１ｃに格納する。このとき、観測手段１ａは、性能の測定に不足する観測情報があるかどうかを調べ、不足する観測情報があり、その観測情報がアクセス発生手段１ｂから所定のアクセスを発生させれば観測可能であれば、アクセス発生手段１ｂに所定のアクセスを指示する。アクセス発生手段１ｂは、指示に従って、サーバ３ａ、３ｂ、３ｃ、・・・に対する所定のアクセスを発生させる。これにより、サーバ３ａ、３ｂ、３ｃ、・・・では、所望の観測情報が得られる状況が発生し、観測情報が生成される。観測手段１ａは、このときの観測情報を収集し、観測情報記憶手段１ｃに格納する。

現在のサーバシステムがサービスレベルを満たしているかどうかについては、性能評価手段１ｄが、観測情報記憶手段１ｃに格納される現在の状態を表す観測情報を分析し、求める性能の測定値を算出する。算出した測定値は、性能基準の限界値と比較することによって、性能基準を満たしているか、すなわち、サービスレベルが満たされているかどうかを評価する。評価結果は、出力手段１ｆを介して管理者に通知される。

また、サーバシステムがサービスレベルを維持できるかどうかについては、維持予測手段１ｅが、これまでに蓄積された観測情報を分析し、求める性能に関する予測モデルを作成し、サービスレベルが維持可能な値範囲を算出する。たとえば、応答時間を多重度の関数で表した応答時間予測モデルを作成し、応答時間に関するサービスレベルが維持可能な多重度の値範囲を算出する。このとき、応答時間（性能パラメータ）がサービスレベルを満たしているかどうかを分ける限界値を予測モデルに適用して算出された多重度（データ綱目）の値を値範囲とした場合、サービスレベルが維持可能かどうか評価される。また、この値範囲にマージンをとり、値範囲を狭くした場合には、サービスレベルが維持できなくなる可能性があるかどうかを予測することができる。なお、予測結果は、出力手段１ｆを介して管理者に通知される。

このように、サーバシステムを構成するサーバ３ａ、３ｂ、３ｃ、・・・の観測情報を収集時、現在の性能測定、もしくは、予測モデル作成に不足する観測情報を収集するためのアクセスを発生させ、観測したい状況を作り出し、不足する観測情報を取得する。これにより、任意のタイミングで所望の状況を作り出して必要な観測情報を収集し、性能監視を行うことが可能となる。また、このようにして任意に得られた観測情報に基づき予測モデルを作成し、ピーク時などのサービスレベル予測を行うことができる。

以下、実施の形態を、サービスをＷｅｂサーバ、アプリケーション（Ａｐｐ）サーバ及びデータベース（ＤＢ）サーバから成るＷｅｂ３階層システムのレスポンス監視に適用した場合を例に図面を参照して詳細に説明する。ここでは、レスポンスがサービスレベルを満たしているかどうかを、応答時間を限界値と比較することによって評価する。したがって、応答時間が限界値を超えていなければ、サービスレベルを満たしているとし、応答時間が限界値を超えている場合には、サービスレベルが満たされていないと評価する。

まず、本実施の形態のシステム性能監視装置の構成と配置について、アクセス発生手段を外部に設けるか否かの２つの場合で説明する。
図２は、本実施の形態のシステム性能監視装置の第１の構成を示した図である。これは、アクセス発生手段を外部に設けない構成である。

システム３は、スイッチ（ＳＷ）３４ａ、３４ｂ、３４ｃを介して、Ｗｅｂサーバ３１、Ａｐｐサーバ３２、ＤＢサーバ３３が接続される。Ｗｅｂサーバ３１、Ａｐｐサーバ３２及びＤＢサーバ３３は、外部ネットワーク２０を介して接続するクライアント２１、２２、２３からの要求に応じて、所定のサービスを提供する。また、スイッチ３４ａ、３４ｂ、３４ｃは、自身を通過するデータをミラーリングするミラーポートを有している。ミラーリングとは、あるポートに出力されるデータと同じデータを、他のポートからも出力する機能である。

本実施の形態のシステム性能監視装置の第１の構成例である擬似クライアント／監視装置１００ａは、アクセス発生手段を具備し、システム３内に配置される。
擬似クライアント／監視装置１００ａは、システム３内のスイッチ３４ａ、３４ｂ、３４ｃに接続し、Ｗｅｂサーバ３１、Ａｐｐサーバ３２、ＤＢサーバ３３に受け渡される情報データをスイッチ３４ａ、３４ｂ、３４ｃのミラーポートを介してキャプチャし、得られたパケットデータを解析することで、ＵＲＬ、サービス数、応答時間などを計測し、観測情報を生成する。観測情報が不足する場合には、この観測情報を得るために、擬似アクセスを発生させ、システム３の内部ネットワーク経由でＷｅｂサーバ３１、Ａｐｐサーバ３２及びＤＢサーバ３３に対し所定のサービスを要求する情報データを送信する。そして、擬似アクセスによってキャプチャされたパケットを解析し、所望の観測情報を得る。

このようにアクセス発生手段を装置内部に設けた構成は、任意のタイミングで擬似アクセスを発生させる場合に適している。たとえば、所望の多重度（ｎとする）の状況を作り出したい場合、多重度（ｎ−１）が観測された時点で擬似アクセスを発生させれば、多重度（ｎ）の状態を作り出すことができる。

次に、第２の構成例について説明する。
図３は、本実施の形態のシステム性能監視装置の第２の構成を示した図である。これは、アクセス発生手段を外部に設けた構成である。図２と同じものには同じ番号を付し、説明は省略する。

本実施の形態のシステム性能監視装置の第２の構成例は、システム３内部に配置される監視装置１００ｂと、外部ネットワーク２０を介して接続する擬似クライアント１００ｃにより成る。

監視装置１００ｂは、Ｗｅｂサーバ３１、Ａｐｐサーバ３２及びＤＢサーバ３３に実装されたエージェントが観測した観測情報の収集と、サービスレベルの監視処理を行う。擬似クライアント１００ｃとは、外部ネットワーク２０を介して接続し、監視装置１００ｂから擬似クライアント１００ｃに指示データを送信することによって連携動作を行う。エージェントは、実装されたサーバの運用状況を解析し、そのレポートを行うプログラムであり、各収集項目について定期的に、もしくは定常的に観測を行う。たとえば、ＣＰＵ利用率、アクセスの多重度、個々のアクセスに関する情報を観測する。あるタイミングを決めて、そのときの多重度と、そのタイミング以降の最初のアクセスの種別・時刻・データサイズや応答時間をセットにして、アクセスに関する情報としてもよい。

擬似クライアント１００ｃは、アクセス発生手段を具備し、監視装置１００ｂからのアクセス発生要求に応じて、所定のアクセスを発生させる。
監視装置１００ｂは、Ｗｅｂサーバ３１、Ａｐｐサーバ３２、ＤＢサーバ３３に実装されるエージェントが観測した観測情報を収集する。そして、不足する観測情報があり、アクセス発生手段によって発生させることができるアクセスによって観測できるものであれば、擬似クライアント１００ｃに対し、アクセスの発生を依頼する。擬似クライアント１００ｃは、依頼を取得すると、擬似アクセスを発生させ、外部ネットワーク２０を介してＷｅｂサーバ３１、Ａｐｐサーバ３２、ＤＢサーバ３３に対し所定のサービスを要求する情報データを送信する。Ｗｅｂサーバ３１、Ａｐｐサーバ３２、ＤＢサーバ３３が取得する擬似クライアント１００ｃからのサービス要求は、他のクライアント２１、２２と同等であるので、同じように処理される。エージェントはこの処理状況を観測し、観測情報を生成する。監視装置１００ｂは、エージェントから再度監視情報を取得することにより、不足していた観測情報を獲得する。

このようにアクセス発生手段を装置外部に設けた構成では、擬似クライアント１００ｃはクライアント２１、２２と同等の処理機能を有しており、たとえば、所望のサービスに対するクライアント側検出の応答時間を、擬似クライアント１００ｃが要求を出してから応答を得るまでの時間によって測定することができる。

以上のように、本実施の形態は、擬似クライアント（アクセス発生手段）と監視装置を一体型とする構成、あるいは、擬似クライアントを外部に配置する構成のいずれでも実現することができる。どちらを選択するかは、監視対象の性能や、システム構成に応じて適宜決定される。また、サーバからのデータ収集も、ミラーポートを介したパケットキャプチャによるものであっても、サーバに実装したエージェントによるものであってもよい。また、ＨＴＴＰＤ（HyperText Transfer Protocol Daemon）などのサーバソフトウェアにプローブを入れて計測してもよい。また、これらの手段を複数同時に利用してもよい。

一体型の擬似クライアント／監視装置１００ａであるか、別装置の監視装置１００ｂと擬似クライアント１００ｃの構成であるかについては、処理機能上は同等であるので、以下の説明ではどちらの構成であるかについては特に言及せず、まとめて監視装置１００と略記する。

ここで、監視装置のハードウェア構成について説明する。図４は、本実施の形態の監視装置のハードウェア構成例を示すブロック図である。
監視装置１００は、ＣＰＵ１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０７を介してＲＡＭ（Random Access Memory）１０２、ハードディスクドライブ（ＨＤＤ：Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、通信インタフェース１０６が接続されている。

ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。ＨＤＤ１０３には、ＯＳやアプリケーションのプログラムが格納される。グラフィック処理装置１０４には、モニタ１０８が接続されており、ＣＰＵ１０１からの命令に従って画像をモニタ１０８の画面に表示させる。入力インタフェース１０５には、キーボード１０９ａやマウス１０９ｂが接続されており、キーボード１０９ａやマウス１０９ｂから送られてくる信号を、バス１０７を介してＣＰＵ１０１に送信する。通信インタフェース１０６は、ネットワークに接続されており、スイッチ３４ａ、３４ｂ、３４ｃを介して監視対象のサーバからデータを収集する。

このようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図４には、監視装置のハードウェア構成を示したが、サーバ及び擬似クライアントを含むクライアントのハードウェア構成も同様である。

図５は、本実施の形態の監視装置の機能ブロックを示す図である。
本実施の形態の監視装置１００は、観測情報ＤＢ１１１及びモデルＤＢ１１２の記憶手段と、観測情報収集部１２０、観測制御部１３０、アクセス発生部１４０、性能測定部１５０、評価部１６０、予測モデル作成部１７０、維持予測部１８０及び出力部１９０の各処理手段を具備する。また、監視装置１００は、監視対象のサーバ群に接続するスイッチ３４を介して、図示しないＷｅｂサーバ３１、Ａｐｐサーバ３２及びＤＢサーバ３３に接続する。

観測情報ＤＢ１１１は、観測制御部１３０が収集した観測情報が格納されるデータベース（ＤＢ）であり、モデルＤＢ１１２には、予測モデル作成部１７０が作成した予測モデルやサービスレベルが維持可能な範囲などの情報が格納される。

観測情報収集部１２０は、観測制御部１３０に従って、スイッチ３４のミラーポートを介して入力されるＷｅｂサーバ３１、Ａｐｐサーバ３２及びＤＢサーバ３３に受渡しされるパケットデータ、もしくは、Ｗｅｂサーバ３１、Ａｐｐサーバ３２及びＤＢサーバ３３に実装されるエージェントが観測・記録した観測情報を収集する。

観測制御部１３０は、タイマ１２１によるタイマ情報に従って、所定の間隔で観測情報収集部１２０に指示を行って観測情報収集を制御する。収集した観測情報は、すべて観測情報ＤＢ１１１に格納する。こうして観測情報ＤＢ１１１に格納された観測情報は、性能測定やモデル予測で利用する際に不足している場合がある。このような不足の観測情報は、それがアクセス発生部１４０によるアクセス発生により観測可能であれば、アクセス発生部１４０に対し、所定のアクセス発生を指示する。そして、対象のサーバシステムに所定のアクセスが発生し、所望の観測情報が得られる頃、観測情報収集部１２０に観測指示を出す。こうして収集された観測情報も観測情報ＤＢ１１１に格納する。

性能測定部１５０は、観測情報ＤＢ１１１に格納される現時の観測情報を分析し、所定の性能に関する測定値を算出する。評価部１６０は、算出された測定値と、サービスレベルが維持されるこの性能の基準値とを比較し、現在サービスレベルが維持されているかどうかを評価する。評価結果は、出力部１９０に出力する。なお、必要であれば、過去の任意の時点においてサービスレベルが維持されていたかどうかを評価することもできる。

予測モデル作成部１７０は、予測モデル作成に必要な観測情報を観測情報ＤＢ１１１より抽出し、性能と観測情報の対応関係に基づき、予測モデルを作成する。さらに、予測モデルに関し、サービスレベルが維持可能な値範囲を設定し、予測モデルとともにモデルＤＢ１１２に格納する。予測モデルは、一旦作成されモデルＤＢ１１２に格納された後は、指示があるまで更新されなくてもよい。維持予測部１８０は、観測情報ＤＢ１１１に格納される現時の観測情報とサービスレベルが維持可能な値範囲を照合し、サービスレベルが維持可能かどうかを評価する。評価結果は、出力部１９０に出力する。

出力部１９０は、評価結果を取得し、評価結果を表示装置などに表示するためのデータに変換して出力する。また、必要に応じて、電子メールなどで管理者に通知を出力する処理を行う。

このような構成の監視装置１００で、次のようなシステム性能監視処理が実行される。
まず、観測情報の収集について説明する。観測情報の収集には、パケットキャプチャや、サーバにエージェントを実装して観測を行わせるなどの方法がある。

パケットキャプチャでは、観測したサーバの直前にあるスイッチでＷｅｂサーバの通信を複製して監視装置１００に振り分ける、もしくは、観測対象サーバのネットワークインタフェースでキャプチャすることができる。このキャプチャデータからクライアント−サーバ間の通信を解析することで、アクセスの種類や要求内容、応答コード、要求・応答のデータサイズ、応答時間などの観測情報を得ることができる。たとえば、プロトコルがＨＴＴＰの場合、アクセスの種類はＨＴＴＰアクセスの種類（ＧＥＴ、ＰＯＳＴなど）、要求内容はアクセス対象のＵＲＬ、応答コードはレスポンスコード（２００ ＯＫなど）、データサイズはそれぞれのパケットのＴＣＰペイロード部分合計、応答時間は応答の送信時刻から処理要求の送信時刻を差し引いたものとすることができる。これには、本願発明者による「システム分析プログラム、システム分析方法及びシステム分析装置」（特願２００４−１８５９０９号）における方法を用いることができる。

なお、パケットの解析はキャプチャを行った装置が行うので、サーバがキャプチャする場合には観測情報を生成するのはサーバであり、監視装置１００は生成された観測情報を取得する必要がある。

また、観測したプロトコル種別に対応するサーバにプローブを埋め込み、処理の要求・応答が発生すると同時に、その情報を同じ装置上もしくは別装置に設けられたエージェントへ送信するか、または、データベースに格納する。こうして得られた情報を解析することによって、パケット解析と同等の観測情報を得ることができる。この観測情報は、監視装置１００からの要求に対して送信してもよいし、定期的に監視装置１００に送信するようにしてもよい。

さらに、観測対象のサーバにエージェントを入れておき、定期的にＣＰＵ利用率やメモリ使用率、アクセスの多重度などを計測し、この観測情報を上記と同様に、システム内の装置に設けられたエージェントに送信するか、データベースに格納して保存しておく。エージェントは、各収集項目について、定期的にもしくは定常的に観測を行う。また、項目ごとに観測の周期を変えるようにしてもよい。たとえば、ＣＰＵ利用率、多重度は定常的に観測して１分ごとに集計し、アクセスに関する情報は１秒ごとに収集するなどとしてもよい。また、この観測情報は、監視装置１００からの要求に対して送信してもよいし、定期的に監視装置１００に送信するようにしてもよい。

監視装置１００では、観測制御部１３０によって観測情報の収集が行われる。以下、観測情報収集処理を、サーバに設けられたエージェントから観測情報を収集する場合で説明する。

図６は、本実施の形態の観測情報収集処理の手順を示したフローチャートである。
［ステップＳ１１］ 観測制御部１３０は、タイマ１２１からタイマ情報を取得し、現在の時刻を獲得する。

［ステップＳ１２］ 監視の終了時刻が設定されている場合には、現在の時刻と終了時刻を比較し、終了時刻が経過したかどうかを判定する。経過している場合には、処理を終了する。監視装置１００による性能監視は、監視が必要な時間、たとえば処理が集中する時間帯に行われていればよく、処理件数が少ない時間帯は性能を満たしているかどうかを監視する必要がないことが多い。そこで、予め監視の終了時刻を設定しておき、監視処理を中断する時間帯を設けることもできる。

［ステップＳ１３］ 監視を行う場合、観測情報を取得する取得条件が成立したかどうかを判定する。たとえば、定周期で観測情報を収集する場合には、前回の収集から一定期間が経過したかどうかが判定される。また、ある事象発生時に観測を開始するなどの条件が設定されていてもよい。取得条件が成立しない場合、ステップＳ１１に戻る。

［ステップＳ１４］ 取得条件が成立した場合、観測情報収集部１２０に対し、観測情報を収集するよう要求を行う。観測情報収集部１２０は、全エージェントから観測情報を収集する。

［ステップＳ１５］ 観測情報を分析し、不足する観測情報を取得するための擬似アクセスを発生する項目があるかどうかを判定する擬似アクセス判定処理を行う。処理の詳細は後述する。

［ステップＳ１６］ ステップＳ１５の擬似アクセス判定処理によって、擬似アクセスを発生させる発生条件が成立したかどうかを判定する。不足する観測情報がない場合、または、擬似アクセスを発生させても所望の観測情報が得られない場合、発生条件不成立とし、処理をステップＳ２０へ進める。

［ステップＳ１７］ 擬似アクセスの発生条件が成立した場合、観測情報収集部１２０を経由して、各エージェントに観測情報の採取指示を出す。
［ステップＳ１８］ アクセス発生部１４０に対し、アクセス発生の指示を行う。

［ステップＳ１９］ 観測情報収集部１２０に対し、観測情報を収集するよう要求を行う。観測情報収集部１２０は、全エージェントから観測情報を収集する。
［ステップＳ２０］ 収集された観測情報を観測情報ＤＢ１１１に格納する。このとき、データを蓄積するため、同じパラメータのデータがあった場合にも、それぞれのデータを格納する。

［ステップＳ２１］ 観測情報を調べ、不足する観測情報があるかどうかを判定する情報不足判定処理を実行する。処理の詳細は後述する。
［ステップＳ２２］ 観測情報の取得時刻を記録し、ステップＳ１１に処理を戻し、次の観測情報収集を待つ。

以上の処理手順が実行されることにより、性能の測定やモデル作成に必要な観測情報が取得され、観測情報ＤＢ１１１に格納される。
ここで、擬似アクセス判定処理（ステップＳ１５）の処理手順について説明する。

図７は、本実施の形態の擬似アクセス判定処理の処理手順を示したフローチャートである。
［ステップＳ１５１］ 直近の観測情報から、現在観測可能な多重度の範囲を算出する。所望の多重度ｎとし、アクセス発生部１４０では多重度ｎ−１が検出されたときに、１アクセスの発生は可能であるとする。この場合、観測可能な多重度の範囲は、ｎ−１までとなる。また、多重度ｎから適宜与えられた閾値以内（閾値をｍとしてｎ−ｍからｎ＋ｍの範囲）を観測可能範囲としてもよい。さらに、観測情報ＤＢ１１１の過去のアクセス状況を参照し、直近のアクセス数が上昇傾向にある場合は、ｎからｎ＋ｍを観測可能範囲とし、下降傾向にある場合はｎ−ｍからｎを観測可能範囲とするようにしてもよい。

［ステップＳ１５２］ 観測情報ＤＢ１１１に格納されるアクセス情報など、利用するテーブル情報を参照する。
［ステップＳ１５３］ ステップＳ１５２において、参照したテーブルから読み出していない未読のＵＲＬがあるかどうか、すなわち、擬似アクセスの要否を判定していないＵＲＬがあるかどうかを判定する。ない場合、すなわち、全ＵＲＬの処理が終了した場合、処理を終了する。

［ステップＳ１５４］ 未読のＵＲＬが存在する場合、すなわち、まだ擬似アクセス要否の判定処理をしていないＵＲＬが存在する場合、情報不足判定処理（ステップＳ２１）によって情報不足フラグがセットされているかどうかを判定する。セットされていない場合、ステップＳ１５２に戻って、次のＵＲＬについて処理を行う。

［ステップＳ１５５］ このＵＲＬについて要求される多重度は、ステップＳ１５１で算出された観測可能範囲内であるかどうかを判定する。所望の多重度の状態で観測情報を得たい場合、要求される多重度が現時の状態で作り出すことが可能な観測可能範囲でなければならない。観測可能範囲内でない場合、擬似アクセスを発生させても要求される多重度の状況を作り出すことができないので、ステップＳ１５２に戻って、次のＵＲＬについて処理を行う。なお、所望の多重度状態にする必要がない場合、常に観測可能範囲内と判定される。

［ステップＳ１５６］ 不足する観測情報があり、多重度が観測可能範囲内であれば、この観測情報を観測するための状況が擬似アクセスを発生させることによって作り出すことができるので、発生させる擬似アクセスに関する項目を設定し、処理を終了する。

以上の処理手順により、擬似アクセスを発生させる発生条件が整えば、発生させる擬似アクセスに関する項目が設定され、次処理に引き渡される。
次に、情報不足判定処理（ステップＳ２１）の処理手順について説明する。

図８は、本実施の形態の情報不足判定処理の処理手順を示したフローチャートである。
［ステップＳ２１１］ 観測情報ＤＢ１１１に格納されるアクセス情報など、利用するテーブル情報を参照する。

［ステップＳ２１２］ ステップＳ２１１において、参照したテーブルから読み出していない未読のＵＲＬがあるかどうか、すなわち、情報不足の判定をしていないＵＲＬがあるかどうかを判定する。ない場合、すなわち、全ＵＲＬの処理が終了した場合、処理を終了する。

［ステップＳ２１３］ このＵＲＬについて、必要とする観測情報（データ）が存在するか否かが判定される。データが存在しない場合、処理をステップＳ２１６へ進める。
［ステップＳ２１４］ 観測情報（データ）が存在する場合、そのデータが予め設定された期限内に取得されたデータであるかどうかを判定する。たとえば、このＵＲＬに関するテーブルに設定された最新の観測時刻（観測情報を取得した最も新しい時刻）と現在時刻を比較し、その差が予め設定されている閾値を超えているかどうかを調べることによって、期限内のデータであるかどうかを判定する。期限内データでない場合は、処理をステップＳ２１６へ進める。

［ステップＳ２１５］ 存在する観測情報（データ）が、期限内データである場合、さらに、観測回数を判定し、規定回数観測されているデータであるかどうかを判定する。たとえば、このＵＲＬに関するテーブルに設定された観測回数と、観測回数の平均値を比較し、平均値より少なければ、規定回数観測されていないと判定する。規定回数観測されていると判定された場合、このＵＲＬに関する観測情報（データ）は、利用可能であるので情報不足フラグはセットせず、ステップＳ２１１に戻って、次のＵＲＬの処理を行う。

［ステップＳ２１６］ データが存在しない場合、情報不足フラグをセットした後、ステップＳ２１１に戻って、次のＵＲＬの処理を行う。
以上の処理手順が実行されることにより、収集した観測情報と、観測情報ＤＢ１１１を検索し、性能測定または予測モデル作成に不足している観測情報がないかどうかが調べられ、不足していれば、情報不足フラグがセットされる。不足の基準として、上記では、情報がない、情報の取得回数が規定値に満たない、情報の新鮮度が低い（最後に観測されてから、設定された閾値以上の時刻が経過した）などを例としてあげているが、基準は適用システムに応じて任意の設定とすることができる。

以上の処理が行われることにより、内部観測の結果に応じて動的に所望のデータを採取することが可能となり、任意の時間にサービスレベルを維持できているかどうか検証することができる。

なお、観測制御部１３０は、必要に応じて、擬似アクセスを発生させながらの観測を行わないようにすることもできる。たとえば、起動時からの１時間は、データ蓄積のため、擬似アクセスを発生させない受動的な観測を続ける。そして、１時間が経過したら、擬似アクセス発生を含む観測処理を行う。また、たとえば、１０分以上新しいパターンのデータが取得できなくなったところで、擬似アクセス発生を含む観測処理に移行することもできる。

擬似アクセス（負荷）の発生は、観測情報が必要なサービス要求のパケットの送信のほか、任意の多重度の状態を作り出すために実行される。たとえば、多重度ｎでのｉｎｄｅｘ．ｈｔｍの応答時間が計測できていない場合は、多重度ｎ−１の状況が計測されたと同時にアクセス発生部１４０によってｉｎｄｅｘ．ｈｔｍのアクセスを１回発生させ、観測を行う。このときのデータには、アクセス発生部１４０が発生させた擬似アクセスであることを示すフラグを付けておいてもよい。また、１回でうまく観測できない場合には、計測区間の平均多重度がｎ−１と予め決められた閾値以内の多重度の場合に、１多重アクセスを何度か連続して発生させ、計測できたら終了させてもよい。

図９は、本実施の形態の観測情報収集処理により収集されたアクセス情報を示した図である。
アクセス情報３０１には、パケット解析により得られたアクセスに関する情報項目が記録されている。図の例では、開始時刻と、要求内容（ＵＲＬ）、応答時間、リクエストデータサイズと、レスポンスデータサイズが記録されている。

また、図１０は、本実施の形態の観測情報収集処理により収集されたＣＰＵ利用率情報を示した図である。
ＣＰＵ利用率情報３０２には、エージェントによって計測されたＣＰＵによる処理状況が記録されている。図の例では、経過時間と、その間の平均ＣＰＵ利用率、処理中のリクエスト数及びサービス処理の内容（ｉｎｄｅｘ．ｈｔｍｌ、ｍｅｎｕ．ｊｓｐ、ｌｏｇｉｎ．ｊｓｐ、ｎｅｗｓ．ｊｓｐ）ごとの処理数が記録されている。

このようなアクセス情報３０１、ＣＰＵ利用率情報３０２が収集されると、性能測定部１５０は、これらの情報を解析して性能の測定を行い、評価部１６０は、性能が要求された基準を満たしているかどうかを評価する。

以下では、性能の測定として、応答時間を監視する場合で説明する。
性能測定部１５０は、アクセス情報を解析し、各エントリをサービス（ＵＲＬ）ごとにまとめ、レスポンス情報を生成する。

図１１は、本実施の形態の性能測定処理によって生成されたレスポンス情報を示した図である。
レスポンス情報３０３は、性能測定部１５０がアクセス情報３０１及びＣＰＵ利用率情報３０２を解析して得た応答時間に関する性能情報である。

性能測定部１５０では、アクセス情報３０１の各エントリをサービス（ＵＲＬ）ごとに分類し、ＵＲＬごとに、開始時刻、応答時間、データサイズ（要求、応答）をまとめて、テーブルを作成する。

観測回数は、アクセス情報３０１に観測情報が設定されている回数を示している。最終観測時刻は、アクセス情報３０１の開始時刻のうち、最も新しく観測されたエントリの開始時刻が設定される。観測回数及び最終観測時刻は、図８に示した情報不足判定処理において、観測情報の更新が必要かどうかの判定に用いられる。

多重度は、ＣＰＵ利用率情報３０２や、アクセス情報３０１の各エントリの開始時刻と応答時間の関係などによって算出される。
評価部１６０は、性能測定部１５０によって分析された個々のアクセスに関するレスポンス情報と、予め決められたアクセスに関する限界値を比較し、サービスレベルが満たされているかどうかを評価する。たとえば、ｉｎｄｅｘ．ｈｔｍｌに対する応答時間の限界値が３０００ｍｓのとき、収集した観測情報から得られる応答時間に３０００ｍｓ以上のデータがあれば、サービスレベルを満たしていないと評価できる。図１１のレスポンス情報３０３の場合、ｉｎｄｅｘ．ｈｔｍｌの応答時間は、３ｍｓと２ｍｓであるので、サービスレベルを満たしていると評価できる。出力部１９０は、この結果を表示画面などに表示して通知する。

また、サービスレベルが満たされていないと評価された場合は、表示画面に表示して管理者に通知する他、その旨を通知する電子メールを管理者に送るなどの方法がとられてもよい。

このように、上記の説明の処理手順が実行されることによって、任意のタイミングで必要な観測情報を取得し、限界値と比較することによって所定のサービスレベルが満たされているかどうかを評価することができる。もし、不足する観測情報がある場合には、対応する情報データを所定のタイミングで監視対象のサーバに送信することによって、所望の状況下の観測情報を発生させることができる。

なお、上記の処理では、現時のサーバシステムが所定のサービスレベルを満たしているかどうかについての確認ができる。さらに、このような観測情報を日々収集することによって、ピーク時などの状況における予測モデルを生成し、所定の状況下においてもサービスレベルが維持可能であるかどうかを予測することが可能となる。

以下、ピーク時など、所定の状況下でサービスレベルが維持できるかどうかを予測する維持予測処理を、処理要求が増加し、多重度が増えた場合に、応答時間がサービスレベルを維持できるかどうかを予測する場合で説明する。

予測モデル作成部１７０は、モデル作成対象範囲のすべてのレスポンス情報を順次読み込んで多重度と応答時間の対応関係を表すテーブルを作成し、そのテーブルに基づき応答時間を多重度の関数として表す。モデル作成対象範囲は、たとえば、１日分、１週間分などのように任意に設定される。

図１２は、本実施の形態の予測モデル作成処理の手順を示したフローチャートである。モデル作成対象範囲のレスポンス情報が格納される観測情報ＤＢ１１１の記憶領域を示され、処理が開始される。

［ステップＳ３１］ モデル作成対象範囲のレスポンス情報（データ）を１つ読み込む。
［ステップＳ３２］ ステップＳ３１でデータがあったかどうかを判定する。データが存在せず、データの読み込みができなかった場合は、すべてのデータの読み込みが完了していると判定し、処理をステップＳ３５に進める。

［ステップＳ３３］ データ有の場合、すなわち、データが読み込めた場合、このデータのうち、同じ多重度で最も応答時間の長いデータの応答時間（データの最大値）を選択し、既に応答時間と多重度の関係を表すテーブルに登録されている応答時間の最大値と比較する。登録されている応答時間の最大値より読み出されたデータの最大値の方が小さい場合には、ステップＳ３１に戻って次のデータの読み出しから処理を繰り返す。

［ステップＳ３４］ 登録されている応答時間の最大値より読み出されたデータの最大値の方が大きい場合は、登録されている応答時間の最大値を読み出されたデータの最大値に更新した後、ステップＳ３１に戻って次のデータの読み出しから処理を繰り返す。

以上の処理手順が繰り返されることにより、モデル作成対象範囲のすべてのデータについて、多重度と、その間に処理された、もしくは処理途中だったアクセスのうち、最も時間がかかったものの応答時間のペアが示されたテーブルを作ることができる。

［ステップＳ３５］ これまでの処理で作成された多重度と、その最大の応答時間のペアからモデルを作成する。多重度と最大応答時間のペアを、たとえば、最小二乗法を用いて多重度と応答時間の関数として表す。応答時間を多重度の一次関数、もしくは指数関数として表し、これを応答時間モデルとする。

［ステップＳ３６］ ステップＳ３５で作成された応答時間モデルに基づき、このモデルと予め決められた応答時間の限界値を比較することによって、サービスレベルを維持可能な多重度の範囲を決める。ステップＳ３５で作成された関数により、応答時間の限界値に対応する多重度を算出して多重度範囲を求める。

［ステップＳ３７］ 応答時間モデル、サービスレベルを維持可能な多重度範囲を含むこれまでに作成されたデータをモデルＤＢ１１２に格納する。
図１３は、本実施の形態のサービスレベル維持予測モデルの一例を示した図である。

図は、応答時間を多重度の一次関数で表した応答時間モデル４０１を、縦軸を応答時間、横軸を多重度で表した例を示している。
応答時間モデル４０１は、需要が増し、多重度が増加するにつれて応答時間が増大することを示している。そして、応答時間モデル４０１から、サービスレベルが維持可能な応答時間を示すＳＬＡ４０２に対応する多重度の許容限界４０３の値が決定される。

予測モデル作成部１７０は、たとえば、毎日所定の時刻に、過去一日分のデータを利用して予測モデルを作成し、この予測モデルを一日のサービスレベルの維持予測に使用するようにしてもよい。また、予測モデルを作成するモデル作成対象範囲は、これまでに蓄積されたすべてのデータとすることもできる。さらに、期間ばかりでなく、モデル作成対象範囲を曜日ごとにして、曜日ごとのモデルを作成することもできる。

なお、以上の手順において、多重度をＣＰＵ利用率に置き換えることで、ＣＰＵ利用率を利用した場合の予測情報であるＣＰＵ利用率予測４０４が作成可能で、ＣＰＵ利用率を用いた維持予測が可能となる。

維持予測部１８０では、このような応答時間モデルを用いて、サービスレベルの維持予測処理を行う。維持予測処理では、観測情報から得られる直近の多重度が許容限界を超えているかどうかでサービスレベルを維持できない可能性があるかどうかを判定することができる。また、観測されている多重度がサービスレベルを維持可能な範囲の条件に近づいたとき、たとえば、多重度がサービスレベル維持可能な範囲の上位１０％になったとき、サービスレベルを維持できなくなる可能性があると判定することもできる。

図１４は、本実施の形態のサービスレベル維持予測処理の手順を示したフローチャートである。
［ステップＳ４１］ 維持予測部１８０は、モデルＤＢ１１２からサービスレベル維持可能範囲を含む応答時間モデルに関する情報を読み込む。なお、サービスレベル維持可能範囲は、早期に警告を行うため、許容限界の９０％を条件とする範囲としておくこともできる。

［ステップＳ４２］ 直近、もしくは、ピーク時など任意の時刻についての判定を行いたい場合は該当時刻の多重度を読み込み、ステップＳ４１で読み込んだサービスレベル維持可能範囲と比較する。

［ステップＳ４３］ 該当時刻の多重度がサービスレベル維持範囲内に収まっているかどうかを判定する。収まっている場合は、処理を終了する。
［ステップＳ４４］ 該当時刻の多重度がサービスレベル維持範囲内に収まっていない場合、管理者に対し、「サービスレベルが維持できない可能性がある」もしくは、「サービスレベルが維持できなくなる可能性がある」旨の警告を通知し、処理を終了する。

以上の処理手順が実行されることにより、サービスレベルが維持できるかどうかの予測が可能となる。
また、サービスレベルが維持できないと判定された場合において、アクセス発生部１４０により擬似アクセスを発生させることによって、実際にサービスレベルが維持できるかどうかを確かめることもできる。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、システム性能監視装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。

プログラムを流通させる場合には、たとえば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、たとえば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

（付記１） 複数のサーバがネットワークによって接続されて所定のサービスを行うサーバシステムの性能を監視するためのシステム性能監視プログラムにおいて、
コンピュータを、
前記サーバシステムの動作状態に関する観測情報を取得して観測情報記憶手段に格納するとともに、性能測定に必要な前記観測情報に不足があれば、不足する前記観測情報に応じた観測可能状況を前記サーバシステムに発生させる所定のアクセスを指示し、指示した前記所定のアクセスの発生に応じて生成される前記観測情報を取得して前記観測情報記憶手段に格納する観測手段、
前記観測手段から前記所定のアクセス指示を取得すると、前記ネットワークを介して前記サーバシステムに対して前記所定のアクセスを行って、前記サーバシステムに前記観測可能状況を発生させるアクセス発生手段、
前記観測情報記憶手段に格納される前記観測情報を分析して性能を測定し、前記サーバシステムが所定の性能基準を満たしているかどうかを評価する性能評価手段、
として機能させることを特徴とするシステム性能監視プログラム。

（付記２） 前記観測手段は、前記サーバ内に実装されるエージェントによって生成されたＣＰＵ利用率やアクセス多重度を含む前記サーバの内部状態を記録した前記観測情報を収集する、
ことを特徴とする付記１記載のシステム性能監視プログラム。

（付記３） 前記観測手段は、前記サーバを接続する前記ネットワーク内に設けられたスイッチのミラーポートを介して、前記サーバに受け渡しされる情報データを取得し、前記情報データの内容を解析して前記情報データの宛先、サービス種別及び応答時間を含む前記観測情報を生成する、
ことを特徴とする付記１記載のシステム性能監視プログラム。

（付記４） 前記観測手段は、不足する前記観測情報の生成が可能な前記観測可能状況を前記サーバシステムに発生させる前記所定のアクセスのアクセスパターンと発生タイミングを前記アクセス発生手段に指示する、
ことを特徴とする付記１記載のシステム性能監視プログラム。

（付記５） 前記観測手段は、前記性能の測定に前記サーバシステムが実行するサービス処理の多重度に応じた前記観測情報が必要となる場合に、前記観測情報に基づいて現時の多重度を計測し、所望の多重度に対し前記現時の多重度が不足する数分の前記所定のアクセスを指示する、
ことを特徴とする付記４記載のシステム性能監視プログラム。

（付記６） 前記観測手段は、予め設定された所定の期間、または、所定の条件が成立した場合に前記観測情報の収集からの処理を行う、
ことを特徴とする付記１記載のシステム性能監視プログラム。

（付記７） 前記コンピュータを、さらに、
前記観測情報記憶手段に格納された前記観測情報を解析し、任意の性能を表す性能パラメータと前記観測情報に含まれる所定のデータ項目との対応関係に基づき、前記サーバシステムが前記所定の性能基準の維持が可能な前記所定のデータ項目の値範囲を算出し、前記観測情報から得られる前記所定のデータ項目の現在値と前記値範囲を比較して前記サーバシステムが前記所定の性能基準を維持できるかどうかを予測する維持予測手段、
として機能させることを特徴とする付記１記載のシステム性能監視プログラム。

（付記８） 前記維持予測手段は、前記観測情報記憶手段に格納された前記観測情報を解析し、前記性能パラメータと前記所定のデータ項目との対応関係に基づいて前記性能パラメータを前記所定のデータ項目の関数で表した予測モデルを作成し、前記予測モデルを用いて前記サーバシステムに要求される前記所定の性能基準が維持できる前記所定のデータ項目の値範囲を算出する、
ことを特徴とする付記７記載のシステム性能監視プログラム。

（付記９） 前記維持予測手段は、前記観測情報記憶手段に格納される前記観測情報のうち所定の期間や時間範囲を含む任意の条件を満たす前記観測情報を抽出し、抽出された前記観測情報を前記予測モデル作成に利用する、
ことを特徴とする付記８記載のシステム性能監視プログラム。

（付記１０） 前記維持予測手段は、前記サーバシステムに要求される前記所定の性能基準の限界値を前記予測モデルに適用して得られる前記所定のデータ項目の値を前記所定のデータ項目の値範囲に設定し、前記観測手段により収集された前記観測情報より得られる前記所定のデータ項目の値が前記所定のデータ項目の値範囲を超えている場合は要求される性能が維持できない可能性があると判断する、
ことを特徴とする付記８記載のシステム性能監視プログラム。

（付記１１） 前記維持予測手段は、前記サーバシステムに要求される前記所定の性能基準の限界値を前記予測モデルに適用して得られる前記所定のデータ項目の値からマージンを差し引いた値を前記所定のデータ項目の値範囲に設定し、前記観測手段により収集された前記観測情報より得られる前記所定のデータ項目の値が前記所定のデータ項目の値範囲を超えている場合は要求される性能が維持できなくなる可能性があると判断する、
ことを特徴とする付記８記載のシステム性能監視プログラム。

（付記１２） 複数のサーバがネットワークによって接続されて所定のサービスを行うサーバシステムの性能を監視するシステム性能監視方法において、
観測手段が、前記サーバシステムの動作状態に関する観測情報を取得して観測情報記憶手段に格納するとともに、性能測定に必要な前記観測情報に不足があれば、不足する前記観測情報に応じた状況を前記サーバシステムに発生させる所定のアクセスを指示し、
アクセス発生手段が、前記観測手段から前記所定のアクセス指示を取得すると、前記ネットワークを介して前記サーバシステムに対して前記所定のアクセスを行って、前記サーバシステムに前記観測情報に応じた状況を発生させ、
前記観測手段が、前記所定のアクセスに応じて生成される前記観測情報を取得して前記観測情報記憶手段に格納し、
性能評価手段が、前記観測情報記憶手段に格納される前記観測情報を分析して性能を測定し、前記サーバシステムが所定の性能基準を満たしているかどうかを評価する、
ことを特徴とするシステム性能監視方法。

（付記１３） 複数のサーバがネットワークによって接続されて所定のサービスを行うサーバシステムの性能を監視するシステム性能監視装置において、
前記サーバシステムの動作状態に関する観測情報を取得して観測情報記憶手段に格納するとともに、性能測定に必要な前記観測情報に不足があれば、不足する前記観測情報に応じた状況を前記サーバシステムに発生させる所定のアクセスを指示し、前記所定のアクセスに応じて生成される前記観測情報を取得して前記観測情報記憶手段に格納する観測手段と、
前記観測手段から前記所定のアクセス指示を取得すると、前記ネットワークを介して前記サーバシステムに対して前記所定のアクセスを行って、前記サーバシステムに前記観測情報に応じた状況を発生させるアクセス発生手段と、
前記観測情報記憶手段に格納される前記観測情報を分析して性能を測定し、前記サーバシステムが所定の性能基準を満たしているかどうかを評価する性能評価手段と、
を具備することを特徴とするシステム性能監視装置。

実施の形態に適用される発明の概念図である。 本実施の形態のシステム性能監視装置の第１の構成を示した図である。 本実施の形態のシステム性能監視装置の第２の構成を示した図である。 本実施の形態の監視装置のハードウェア構成例を示すブロック図である。 本実施の形態の監視装置の機能ブロックを示す図である。 本実施の形態の観測情報収集処理の手順を示したフローチャートである。 本実施の形態の擬似アクセス判定処理の処理手順を示したフローチャートである。 本実施の形態の情報不足判定処理の処理手順を示したフローチャートである。 本実施の形態の観測情報収集処理により収集されたアクセス情報を示した図である。 本実施の形態の観測情報収集処理により収集されたＣＰＵ利用率情報を示した図である。 本実施の形態の性能測定処理によって生成されたレスポンス情報を示した図である。 本実施の形態の予測モデル作成処理の手順を示したフローチャートである。 本実施の形態のサービスレベル維持予測モデルの一例を示した図である。 本実施の形態のサービスレベル維持予測処理の手順を示したフローチャートである。 従来の代表的なシステム性能監視装置の例を示した図である。

符号の説明

１ システム性能監視装置
１ａ 観測手段
１ｂ アクセス発生手段
１ｃ 観測情報記憶手段
１ｄ 性能評価手段
１ｅ 維持予測手段
１ｆ 出力手段
２ ネットワーク
３ システム
３ａ、３ｂ、３ｃ サーバ
４ ユーザ
４ａ、４ｂ、４ｃ クライアント

Claims (5)

1. 複数のサーバがネットワークによって接続されて所定のサービスを行うサーバシステムの性能を監視するためのシステム性能監視プログラムにおいて、
   コンピュータを、
   前記サーバシステムの動作状態に関する観測情報を取得して観測情報記憶手段に格納するとともに、性能測定に必要な前記観測情報に不足があれば、不足する前記観測情報に応じた観測可能状況を前記サーバシステムに発生させる所定のアクセスを指示し、指示した前記所定のアクセスの発生に応じて生成される前記観測情報を取得して前記観測情報記憶手段に格納する観測手段、
   前記観測手段から前記所定のアクセス指示を取得すると、前記ネットワークを介して前記サーバシステムに対して前記所定のアクセスを行って、前記サーバシステムに前記観測可能状況を発生させるアクセス発生手段、
   前記観測情報記憶手段に格納される前記観測情報を分析して性能を測定し、前記サーバシステムが所定の性能基準を満たしているかどうかを評価する性能評価手段、
   として機能させることを特徴とするシステム性能監視プログラム。
2. 前記観測手段は、不足する前記観測情報の生成が可能な前記観測可能状況を前記サーバシステムに発生させる前記所定のアクセスのアクセスパターンと発生タイミングを前記アクセス発生手段に指示する、
   ことを特徴とする請求項１記載のシステム性能監視プログラム。
3. 前記コンピュータを、さらに、
   前記観測情報記憶手段に格納された前記観測情報を解析し、任意の性能を表す性能パラメータと前記観測情報に含まれる所定のデータ項目との対応関係に基づき、前記サーバシステムが前記所定の性能基準の維持が可能な前記所定のデータ項目の値範囲を算出し、前記観測情報から得られる前記所定のデータ項目の現在値と前記値範囲を比較して前記サーバシステムが前記所定の性能基準を維持できるかどうかを予測する維持予測手段、
   として機能させることを特徴とする請求項１記載のシステム性能監視プログラム。
4. 前記維持予測手段は、前記観測情報記憶手段に格納された前記観測情報を解析し、前記性能パラメータと前記所定のデータ項目との対応関係に基づいて前記性能パラメータを前記所定のデータ項目の関数で表した予測モデルを作成し、前記予測モデルを用いて前記サーバシステムに要求される前記所定の性能基準が維持できる前記所定のデータ項目の値範囲を算出する、
   ことを特徴とする請求項３記載のシステム性能監視プログラム。
5. 複数のサーバがネットワークによって接続されて所定のサービスを行うサーバシステムの性能を監視するシステム性能監視方法において、
   観測手段が、前記サーバシステムの動作状態に関する観測情報を取得して観測情報記憶手段に格納するとともに、性能測定に必要な前記観測情報に不足があれば、不足する前記観測情報に応じた状況を前記サーバシステムに発生させる所定のアクセスを指示し、
   アクセス発生手段が、前記観測手段から前記所定のアクセス指示を取得すると、前記ネットワークを介して前記サーバシステムに対して前記所定のアクセスを行って、前記サーバシステムに前記観測情報に応じた状況を発生させ、
   前記観測手段が、前記所定のアクセスに応じて生成される前記観測情報を取得して前記観測情報記憶手段に格納し、
   性能評価手段が、前記観測情報記憶手段に格納される前記観測情報を分析して性能を測定し、前記サーバシステムが所定の性能基準を満たしているかどうかを評価する、
   ことを特徴とするシステム性能監視方法。

Images