"システムを構成する被管理装置から複数種の性能種目に関わる性能情報を取得する運用管理装置であって、前記性能情報の時系列変化を示す性能系列情報から前記性能情報間の複数の相関関数および前記各相関関数の予測誤差を示す重み情報を含む相関モデルを生成する相関モデル生成部と、前記性能情報のうちの第1の性能情報から第2の性能情報を予測しうる前記相関関数またはその組み合わせによる経路が前記相関モデルの中に複数存在する場合に、前記重み情報の数値が最大となる前記経路を利用して前記第2の性能情報を予測するモデル探索部とを備える運用管理装置。前記相関モデル生成部が、前記性能系列情報のうちの2項目についての前記相関関数の係数および前記重み情報を算出する処理を前記性能系列情報の全ての組み合わせについて行って前記相関モデルを生成する、請求項1に記載の運用管理装置。前記モデル探索部が、少なくとも1つの前記第1の性能情報に対して複数の前記経路によって異なる前記第2の性能情報が算出され得る場合に、前記重み情報の数値が最大となる前記経路を利用すべき経路として決定する、請求項1に記載の運用管理装置。前記モデル探索部が、前記相関モデルに含まれる前記各相関関数を順次探索して、前記各性能情報間の利用すべき経路を決定する処理を行う、請求項3に記載の運用管理装置。前記モデル探索部が、決定された前記経路に基づいて前記第1の性能情報から前記第2の性能情報を予測する機能を備える、請求項4に記載の運用管理装置。複数のコンピュータ装置である被管理装置と、前記複数の被管理装置から該装置の動作に関する複数種の性能種目に関わる性能情報を取得する運用管理装置と、を含み、前記運用管理装置は、前記性能情報の時系列変化を示す性能系列情報から前記性能情報間の複数の相関関数および前記各相関関数の予測誤差を示す重み情報を含む相関モデルを生成する相関モデル生成部と、前記性能情報のうちの第1の性能情報から第2の性能情報を予測しうる前記相関関数の組み合わせによる経路が前記相関モデルの中に複数存在する場合に、前記重み情報の数値が最大となる前記経路を利用して前記第2の性能情報を予測するモデル探索部とを備えることを特徴とする運用管理システム。システムを構成する複数のコンピュータ装置である被管理装置から取得される該装置の動作に関する複数種の性能種目に関わる性能情報に基づいて、前記被管理装置を運用管理する情報処理方法であって、前記性能情報の時系列変化を示す性能系列情報から前記性能情報間の複数の相関関数および前記各相関関数の予測誤差を示す重み情報を含む相関モデルを生成する相関モデル生成ステップと、前記性能情報のうちの第1の性能情報から第2の性能情報を予測しうる前記相関関数の組み合わせによる経路が前記相関モデルの中に複数存在する場合に、前記重み情報の数値が最大となる前記経路を利用して前記第2の性能情報を予測するモデル探索ステップとを含むことを特徴とする運用管理方法。前記相関モデル生成ステップが、前記性能系列情報のうちの2項目についての前記相関関数の係数および前記重み情報を算出する処理を前記性能系列情報の全ての組み合わせについて行って前記相関モデルを生成する、請求項7に記載の運用管理方法。前記モデル探索ステップが、少なくとも1つの前記第1の性能情報に対して複数の前記相関関数によって異なる前記第2の性能情報が算出され得る場合に、前記重み情報の数値が最大となる前記経路を利用すべき経路として決定する、請求項8に記載の運用管理方法。前記モデル探索ステップが、前記相関モデルに含まれる前記各相関関数を順次探索して、前記各性能情報間の利用すべき経路を決定する、請求項9に記載の運用管理方法。前記モデル探索ステップが、決定された前記経路に基づいて前記第1の性能情報から前記第2の性能情報を予測する、請求項10に記載の運用管理方法。システムを構成する複数のコンピュータ装置である被管理装置から該装置の動作に関する複数種の性能種目に関わる性能情報を取得して、前記被管理装置を運用管理する運用管理装置が備えたコンピュータに諸機能を実現させることが可能な運用管理プログラムであって、前記性能情報の時系列変化を示す性能系列情報から前記性能情報間の複数の相関関数および前記各相関関数の予測誤差を示す重み情報を含む相関モデルを生成する相関モデル生成機能と、前記性能情報のうちの第1の性能情報から第2の性能情報を予測しうる前記相関関数の組み合わせによる経路が前記相関モデルの中に複数存在する場合に、前記重み情報の数値が最大となる前記経路を利用して前記第2の性能情報を予測するモデル探索機能と、を含む機能をコンピュータに実現させることを特徴とする運用管理プログラム。しかしながら、関連技術の運用管理装置においては、次のような不具合がある。すなわち、特許文献1では、運用継続によって部分的に構成が変更されたり、サービス利用に偏りが生じたりすると、テスト時とは異なる要素に負荷が集中することになる。このような変化を事前にすべて想定することは困難であり、結果的に、想定外の利用状況で予期せぬ要素がボトルネックになってしまうことを避けられない、という不具合があった。特許文献2では、システムが大規模化したり、他システムと連携したりする場合には、処理と負荷の関係が極めて複雑になり、正確な負荷を予測するためには、関係しうるすべての処理の履歴を収集して分析しなければならない。このため、正確な予測には、データ収集および分析の負荷が大きく、それを分析するための高度な知識も必要となる、という不具合があった。また、特定の処理だけから予測された負荷では信頼性が低く、正確なボトルネック解析ができない、という不具合があった。特許文献3では、システムを構成する要素の性能値は完全に独立に変動するものではないため、各々の性能情報から予測された値がシステムの実稼動で発生しうるかどうかは、別途管理者が検証しなければならない。このため、ボトルネックとなる要素を正確に判定するために、管理者に多くの知識が要求され、検証の作業負担も大きくなるという不具合があった。特許文献4では、性能情報間の関係の大きさを定量化するだけでは、因果関係があり得るという仮説を提示できるのみであり、第3の関連技術と同様に、実際にどれが原因なのかを管理者が検証しなければならないという不具合があった。また、関係の大きさを定量化するために、1つの要素毎に他の要素のすべてとの重回帰分析する処理が必要となるため、システムが大規模化して要素が増えると負荷が膨大になってしまうという不具合があった。さらに、ある1つの要素の値に対して他の要素の値を算出することが困難であるため、将来発生しうる負荷に対してどの要素がボトルネックとなり得るかといった解析ができないという不具合があった。特許文献5では、相関係数は値であるため、ある時点異常時の値の相関から、関係する異常原因を提示できるが、実在しない将来値の相関を算出することはできないので、正確なボトルネック解析を行うことができない、という不具合があった。特許文献6では、個々の性能情報の関数を推定するもの第3の関連技術と同様である。そして、y=fxの式において、xは時間で、1つのyの時間変化を表す。この式を2つ用意して、別途与えた相関関係ルールで2つの関係を判定する。ルールは、自動生成されるわけではないので、システムを構成する各要素について全ての性能情報間のルールを別途与えなければ、ボトルネック解析を正確に予測できない、という不具合があった。すなわち、CPU使用率とスループットとの相関は、一の要素と他の要素との間の相関のみであるため、システムを構成する全要素についてのそれぞれ相関が不明であるため、システムのボトルネックがどの要素に最も生じやすくなるかを予測することができない、という不具合があった。特許文献7では、ワークロードやメトリックスの変換は行われるが、いずれも値を算出しているものであるため、モデルを用いないため、これらの変換方法の全てを手作業で入力しなければならない、という不具合があった。このように、関連技術の運用管理装置では、実際の運用状況で発生するボトルネックを正確に予測できず、管理者の負担や分析処理の負荷が増大する、という不具合があった。すなわち、第1に、将来発生しうる状況を事前にすべて想定することは困難であり、結果的に、想定外の利用状況で予期せぬ要素がボトルネックになってしまうことを避けられないという不具合があった。第2に、正確な予測には、データ収集および分析の負荷が大きく、それを分析するための高度な知識も必要となるという不具合があった。また、特定に処理だけから予測された負荷では信頼性が低く、正確なボトルネック解析ができないという不具合があった。第3に、ボトルネックとなる要素を正確に判定するために、管理者に多くの知識が要求され、検証の作業負担も大きくなるという不具合があった。第4に、システムが大規模化して要素が増えると負荷が膨大になってしまうという問題があった。さらに、ある1つの要素の値に対して他の要素の値を算出することが困難であるため、将来発生しうる負荷に対してどの要素がボトルネックとなり得るかといった解析ができない、という不具合があった。本発明は、上記した技術の不具合を解決することを課題としてなされたものであって、その目的とするところは、実際の運用状況で発生するボトルネックを正確に予測可能としながらも、管理者の負担が少なく、大規模環境においても分析に必要となる処理負荷を低減したボトルネック解析が可能な運用管理装置、運用管理システム、情報処理方法、及び運用管理プログラムを提供することにある。上記目的を達成するため、本発明の運用管理装置は、システムを構成する被管理装置から複数種の性能種目に関わる性能情報を取得する運用管理装置であって、前記性能情報の時系列変化を示す性能系列情報から前記性能情報間の複数の相関関数および前記各相関関数の予測誤差を示す重み情報を含む相関モデルを生成する相関モデル生成部と、前記性能情報のうちの第1の性能情報から第2の性能情報を予測しうる前記相関関数またはその組み合わせによる経路が前記相関モデルの中に複数存在する場合に、前記重み情報の数値が最大となる前記経路を利用して前記第2の性能情報を予測するモデル探索部と備えることを特徴としている。本発明の運用管理システムは、複数のコンピュータ装置である被管理装置と、前記複数の被管理装置から該装置の動作に関する複数種の性能種目に関わる性能情報を取得する運用管理装置と、を含み、前記運用管理装置は、前記性能情報の時系列変化を示す性能系列情報から前記性能情報間の複数の相関関数および前記各相関関数の予測誤差を示す重み情報を含む相関モデルを生成する相関モデル生成部と、前記性能情報のうちの第1の性能情報から第2の性能情報を予測しうる前記相関関数の組み合わせによる経路が前記相関モデルの中に複数存在する場合に、前記重み情報の数値が最大となる前記経路を利用して前記第2の性能情報を予測するモデル探索部とを備えることを特徴としている。本発明の情報処理方法は、システムを構成する複数のコンピュータ装置である被管理装置から取得される該装置の動作に関する複数種の性能種目に関わる性能情報に基づいて、前記被管理装置を運用管理する情報処理方法であって、前記性能情報の時系列変化を示す性能系列情報から前記性能情報間の複数の相関関数および前記各相関関数の予測誤差を示す重み情報を含む相関モデルを生成する相関モデル生成ステップと、前記性能情報のうちの第1の性能情報から第2の性能情報を予測しうる前記相関関数の組み合わせによる経路が前記相関モデルの中に複数存在する場合に、前記重み情報の数値が最大となる前記経路を利用して前記第2の性能情報を予測するモデル探索ステップとを含むことを特徴としている。本発明の運用管理プログラムは、システムを構成する複数のコンピュータ装置である被管理装置から該装置の動作に関する複数種の性能種目に関わる性能情報を取得して、前記被管理装置を運用管理する運用管理装置が備えたコンピュータに諸機能を実現させることが可能な運用管理プログラムであって、前記性能情報の時系列変化を示す性能系列情報から前記性能情報間の複数の相関関数および前記各相関関数の予測誤差を示す重み情報を含む相関モデルを生成する相関モデル生成機能と、前記性能情報のうちの第1の性能情報から第2の性能情報を予測しうる前記相関関数の組み合わせによる経路が前記相関モデルの中に複数存在する場合に、前記重み情報の数値が最大となる前記経路を利用して前記第2の性能情報を予測するモデル探索機能と、を含む機能をコンピュータに実現させることを特徴としている。本発明によれば、相関モデル生成部が、各々の要素の性能情報間の相関関数を用いてシステムの全体的な稼動状態の相関モデルを生成する。また、モデル探索部が、この相関モデル内の相関関数を順次辿ることで、一の要素の性能情報を仮定した場合に他の要素の性能情報を予測する。これにより、各要素の性能情報間の相関関係を適切に抽出してモデル化することで、実際の運用状況で発生するボトルネックを正確に予測できるとともに、管理者の負担が少なく、大規模環境においても分析に必要となる処理負荷を増大させないボトルネック解析を実現できるという、関連技術にない優れた運用管理装置、運用管理システム、情報処理方法、及び運用管理プログラムを提供することができる。運用管理装置の基本的構成先ず、運用管理装置の基本的構成について説明する。本発明の運用管理装置例えば図5に示す符号100などは、システムを構成する複数の被管理装置から複数種の性能種目毎の性能情報を取得して、前記被管理装置を運用管理するものを対象とするものである。この運用管理装置は、前記性能情報の時系列変化を示す性能系列情報から前記性能情報間の複数の相関関数および前記各相関関数の予測誤差を示す重み情報を含む相関モデルを生成する相関モデル生成部例えば図5に示す符号123などと、前記性能情報のうちの第1の性能情報から第2の性能情報を予測しうる前記相関関数またはその組み合わせによる経路が前記相関モデルの中に複数存在する場合に、前記重み情報の数値が最大となる前記経路を利用して前記第2の性能情報を予測するモデル探索部例えば図5に示す符号124などと、を含む構成としている。また、前記相関モデル生成部が、前記性能系列情報のうちの2項目についての前記相関関数の係数および前記重み情報を算出する処理を前記性能系列情報の全ての組み合わせについて行って前記相関モデルを生成するものとすることができる。この運用管理装置では、前記モデル探索部が、少なくとも1つの前記第1の性能情報に対して複数の前記経路によって異なる前記第2の性能情報が算出され得る場合に、前記重み情報の数値が最大となる前記経路を利用すべき経路として決定する。さらに、前記モデル探索部が、前記相関モデルに含まれる前記各相関関数を順次探索して、前記各性能情報間の利用すべき経路を決定する処理を行う。そして、前記モデル探索部が、決定された前記経路に基づいて前記第1の性能情報から前記第2の性能情報を予測する機能を備えるものとすることができる。このように、本発明の運用管理装置では、検出した性能情報の相関関係を適切に抽出してモデル化することで、関連技術の課題を解決し、管理者の負担が少なく、大規模環境においても分析に必要となる処理負荷を増大させないボトルネック解析を実現できる。以下、このような本発明の運用管理装置を、運用管理システムに適用した好適な実施の形態の一例について、図面を参照して具体的に説明する。第1の実施の形態運用管理システムの全体構成先ず、本実施の形態の運用管理システムの具体的構成について、全体構成から説明し、続いて各部の詳細構成について説明することとする。図1は、本発明における第1実施の形態の運用管理装置を含む運用管理システムの全体の概略構成の一例を示すブロック図である。図1に示すように、本実施の形態の運用管理システム1は、複数の被管理装置の一例である各コンピュータ2と、これらの各コンピュータ2とネットワークNを介して通信可能に形成され各コンピュータ2を運用管理する運用管理装置3と、を含んで構成される。運用管理装置3は、複数のコンピュータ2から複数種の性能種目毎例えばCPU利用率やメモリ残量などの性能情報を取得可能に構成される。コンピュータ2、運用管理装置3は、プログラム制御により動作するものであり、ネットワーク関連の機能を有していれば、デスクトップ、ラップトップコンピュータ、サーバー、その他無線有線通信機能を有する情報機器、またはこれに類するコンピュータなどいかなるコンピュータでもよく、移動式固定式を問わない。運用管理装置3のハードウエア構成は、種々の情報等を表示するための表示部スクリーン、この表示部の表示画面上の各種入力欄等にデータを操作入力するための操作入力部例えばキーボードマウス等、各種信号データを送受信するための送受信部通信部、各種プログラム各種データを記憶しておく記憶部例えばメモリ、ハードディスク等、これらの制御を司る制御部例えばCPU等などを有している。また、コンピュータ2は、ネットワーク機器やその他の機器、メインフレームなどであってもよい。前提となる構成ここで、本実施の形態の特徴的構成を説明する前に、本実施の形態の前提となる運用管理装置の構成について、図2、図3、図4を用いて説明する。図2を参照すると、本実施の形態の前提となる構成を示す運用管理装置3は、サービス実行部21と、性能情報蓄積処理部12と、情報収集部22と、分析設定蓄積処理部14と、障害分析部26と、管理者対話部27と、対処実行部28と、を含んで構成される。サービス実行部21は、WEBサービスや業務サービスといった情報通信サービスを提供するものである。このサービス実行部21は、他の独立したコンピュータなどで構成することもできる。性能情報蓄積処理部12は、サービス実行部21の各々の要素の性能情報を蓄積する。情報収集部22は、サービス実行部21の動作状態を検出して出力するとともに、動作状態に含まれる性能情報を性能情報蓄積処理部12に蓄積する。分析設定蓄積処理部14は、サービス実行部21の異常を検出するための分析設定を蓄積する。障害分析部26は、情報収集部22から動作状態を受け取って分析設定蓄積処理部14の分析設定に従って障害分析を行う。管理者対話部27は、障害分析部26から障害分析の結果を受け取って管理者に提示し、管理者の入力を受け付け、管理者の入力に従って対処実行部28に対処を指示する。対処実行部28は、管理者対話部27の指示に応じてサービス実行部21上で障害の対処となる処理を実行する。図3は、情報収集部22が出力し、性能情報蓄積処理部12に蓄積される性能情報の例を示す。性能情報12aは、サービス実行部28の状態変化に伴って順次収集される性能情報の一覧を示す。性能情報12aを参照すると、個々の性能情報は、同一時刻の各々の性能の値で構成され、それらが一定時間間隔でリストアップされたものとなっている。図4は、性能情報に含まれる1つの要素を時系列グラフで示した例を示す。グラフG101は、図3に示す性能情報12aに含まれるSV1.CPUを時系列で示し、グラフG201は、グラフG101の時系列の変化を線形予測した例を示す。上述のような前提となる構成を有する運用管理装置3の動作について、図2、図3、図4を用いて説明する。まず、図2の情報収集部22がサービス実行部21の動作状態を検出し、性能情報蓄積処理部12に性能情報を蓄積する。例えば、サービス実行部21でWEBサービスが実行されている場合、WEBサービスを提供する各サーバのCPU使用率やメモリ残量を一定時間間隔で検出する。図3の性能情報12aは、このようにして検出された性能情報の例である。例えば、SV1.CPUは、1つのサーバのCPU利用率の値を示し、2007年10月5日の17時25分の値が12である。さらに、1分間隔で17時26分から15、34、63といった値が検出されている。同様に、SV1.MEMは同じサーバのメモリ残量の値を、SV2.CPUは別のサーバのCPU利用率の値を、それぞれ同時刻に検出したものである。次に、障害分析部26は、分析設定蓄積処理部14に蓄積されている分析設定に従って障害分析を行う。分析設定としては、例えば、CPU利用率が一定値以上であれば管理者に警告メッセージを提示するといったことが指定されており、これに従って、情報収集部22で検出された性能情報の値から、特定のサーバの負荷が高くなっているかどうかを閾値判定する。管理者対話部27は、このような障害分析の結果を管理者に提示し、管理者が何らかの対処を指示する入力を行った場合、対処実行部28を介してサービス実行部21上で対処コマンドを実行する。例えば、管理者は、CPU負荷が高くなっていることを知って、業務量を減らしたり、負荷分散を行うための構成変更を行ったりすることができる。この後、一定時間間隔で情報収集部22によって収集された性能情報の値が低下していれば、障害分析部26で障害が回復したと判断され、その結果が管理者対話部27を介して管理者に提示されることになる。このような情報収集、分析、対処の処理の繰り返しにより、サービス実行部21の障害対処が継続して行われる。ここで、第1の関連技術に示した運用管理装置では、運用管理装置3のサービス実行部21に相当する機能により、想定される高負荷状態になるような処理を実行する。例えば、WEBサービスの多数のクライアントからのアクセスを擬似的に発生させる等である。この状態で、運用管理装置3の情報収集部22に相当する機能により、サービス実行部21に相当する機能から性能情報を収集し、障害分析部26に相当する機能によって分析を行えば、想定される高負荷状態において、システムのどの要素が異常となるかが把握できる。例えば、図4のグラフG101に示すような負荷が得られ、そのピーク値が閾値を超えて予め判明している危険域に達することがわかれば、SV1の処理能力が不足することがわかる。逆に、すべての性能情報が閾値以内であることがわかれば、想定される負荷に対してシステムが安全であることがわかる。この第1の関連技術では、想定される高負荷状態の場合のシステムの性能情報は正確に分析できるものの、将来システムに発生しえる高負荷状態をすべて事前にテストすることはできない。例えば、クライアントが平均的なサービス利用を行う場合のアクセスを発生させるテストによって、平均的と思われる利用での耐障害性を確保することが可能である。しかし、利用者の嗜好や社会的な状況変化から特定のサービスに偏ったアクセスが行われる場合までを想定することは困難であり、結果的に、運用が長期化すると、想定外の利用によって予期せぬ要素がボトルネックとなって障害が発生してしまう場合が多くなるという不具合があった。このような分析をさらに詳細に行うものとして、第2の関連技術に示した運用管理装置では、運用管理装置3の情報収集部22に相当する機能により、性能情報に加えて、運用管理装置3のサービス実行部21に相当する機能にて行われた処理の履歴を収集し、運用管理装置3の障害分析部26に相当する機能にて性能情報と処理履歴を合わせて分析する。例えば、予めCPU負荷との関係がわかっている処理の詳細な実行履歴を収集することで、いつどの処理が実行されるとどの程度のCPU利用率になるのかを算出することができる。図4のグラフG101におけるピーク値が、どの処理によって引き起こされたのかがわかれば、その処理がいつ行われる予定であるかによって、将来のSV1.CPUの負荷を予測することができる。この第2の関連技術では、予め性能との因果関係が明確な処理に対しては、詳細な障害分析が行えるものの、処理の履歴を追加収集するために処理負荷が増加するとともに、因果関係が複雑になると、管理者がその分析結果を理解することが難しくなる。特に、近年ITシステムは社会インフラとしての重要性が増しており、システムが大規模化し、他システムと連携する場合が多い。このような状況では、膨大な処理履歴を収集する負荷が発生し、複雑な因果関係を分析する高度な知識も必要となってしまう、という不具合があった。処理との関連ではなく各々の性能情報の時系列変化から負荷の予測を行うものとして、第3の関連技術に示した運用管理装置では、運用管理装置3の障害分析部26に相当する機能が、検出された性能情報の時系列変化の傾向を分析し、将来の変化を予測する。例えば、図4のグラフG101のような時系列変化から、グラフG201のようにSV1.CPUの値が単調増加の傾向にあることを導出し、その増加割合からCPU負荷が危険域になる時期を予測することができる。同様に、他の要素に対しても危険域になる時期を予測すれば、システム全体として最も早く危険域に達すると予想される要素を発見することができる。この第3の関連技術では、各々の要素の将来ボトルネックになる可能性を管理者に提示することが可能であるものの、その状況が実際に発生しうるかどうかは管理者が経験によって判断しなければならない。例えば、メモリ残量が一定以下になれば、新たな処理は開始できずにメモリ量の回復を待つ場合がある。メモリ残量の変化を考慮しなければ、CPU負荷がある時点の傾向と同様に将来も単調増加するかどうかは明確ではない。管理者は、傾向予測の結果の妥当性を判断するために、実際にシステムに存在する要素間の相関関係を正確に理解しなければならず、管理者への負担が大きい、という不具合があった。システムを構成する要素間の相関関係を分析するものとして、第4の関連技術に示した運用管理装置では、運用管理装置3の障害分析部26に相当する機能が、あるシステム要素の性能異常を発見した場合に、情報収集部22から受け取った性能情報から、その時点の性能値に相関のある構成要素の一覧を生成し、管理者対話部27に相当する機能にて管理者に提示する。例えば、図3の性能情報12aにおけるSV1.CPUの異常を発見した場合に、SV1.MEMやSV2.CPUの値とSV1.CPUの値の重回帰分析を行って、相関が高いとみなされたものを列挙する。これにより、管理者は、SV1.CPUの異常がSV2.MEMよって引き起こされているといった可能性を考慮することができる。この第4の関連技術では、ある異常と因果関係の可能性を提示することができるものの、それが正しいかどうかの検証は管理者が行わなければならない。また、検出された性能情報の値の相関は提示できるものの、将来発生しうる負荷に対してどの要素がボトルネックになるのかを導出することができない、という不具合があった。以上述べたように、関連技術の運用管理装置では、実際の運用状況で発生するボトルネックを正確に予測できず、管理者の負担が大きく、情報収集や分析の処理負荷が大きいという不具合があった。そこで、本実施の形態では、以下に示す特徴的構成を有する。本実施の形態の特徴的構成ここで、本発明の第1の実施の形態の運用管理装置の特徴的構成について、図5を参照しつつ説明する。図5は、本発明の第1の実施の形態の運用管理装置の特徴的構成の一例を示すブロック図である。図5に示すように、本発明の第1の実施の形態の運用管理装置100は、図2に示す運用管理装置3と同様の構成である、サービス実行部121、性能情報蓄積処理部112、情報収集部122、分析設定蓄積処理部114、障害分析部126、管理者対話部127、対処実行部128に加えて、相関モデル生成部123と、相関モデル情報蓄積処理部116と、モデル探索部124と、リソース情報蓄積処理部118と、ボトルネック解析部125と、を含んで構成される。相関モデル生成部123は、性能情報蓄積処理部116から一定期間の性能情報を取り出し、任意の2つの性能情報の値の時系列に対して、一方を入力とし他方を出力とした場合の変換関数を導出するとともに、この変換関数で生成された性能値の系列と出力となる性能情報の実際の検出値の系列とを比較し、その値の差から前記変換関数の重み情報を算出する。さらに、これらの処理をすべての性能情報に対して繰り返すことで、サービス実行部121の全体的な稼動状態の相関モデルを生成する。相関モデル蓄積処理部116は、相関モデル生成部123が生成した相関モデルを蓄積処理する。モデル探索部124は、相関モデル蓄積処理部116に蓄積される相関モデルの各々の性能情報間の変換関数を順次辿ることで、1つの性能情報の値を仮定した場合に他の性能情報の値を算出する。また、1つの性能情報に対して複数の変換関数によって異なった値が算出された場合に、重み情報に基づいて1つの値を選択あるいは算出する。リソース情報蓄積処理部118は、性能情報毎の性能値の最大値、最小値、単位といった属性を記述した情報であるリソース情報を蓄積する。ボトルネック解析部125は、性能情報のうち予め指定された1つの入力性能情報の値を順次増加あるいは減少させながらモデル探索部124に指示する。ボトルネック解析部125は、モデル探索部124が算出した他の性能情報の値を受け取って、リソース情報蓄積処理部118に蓄積されるリソース情報と比較する。ボトルネック解析部125は、性能値がリソース情報に示す範囲を超える要素を検出する。ボトルネック解析部125は、その性能情報とその時点の入力性能情報の値を含む解析結果を生成し、管理者対話部127に出力する。ここで、これらの各部は、図6に示すように、制御部が発揮する複数の機能として構成することもできる。また、相関モデル生成部123は、性能種目又は被管理装置を要素とした場合に、少なくとも第1の要素に関する性能情報の時系列変化を示す第1の性能系列情報と、第2の要素に関する性能情報の時系列変化を示す第2の性能系列情報との相関関数を導出し、この相関関数に基づいて相関モデルを生成し、この相関モデルを前記各要素間の組み合わせについて求めることができる。さらに、モデル探索部124は、前記各要素間の前記各相関モデルを順次探索して最適な相関モデルを決定し、この決定された相関モデルに基づいて少なくとも前記第1の要素の性能情報から前記第2の要素の性能情報を予測することができる。また、ボトルネック解析部125は、前記性能情報のとり得る範囲を規定したリソース情報に基づいて、前記モデル探索部にて予測された前記性能情報が前記範囲を超える要素、及びその要素に関する前記性能情報を含むボトルネック解析結果を生成することもできる。さらに、相関モデル生成部123は、前記相関関数を用いて前記第1の要素に関する性能情報から算出された前記第2の要素に関する算出性能情報と、取得された前記第2の要素に関する性能情報との誤差に基づいて、前記相関モデルの重み情報を算出することができる。この場合、前記モデル探索部124は、少なくとも1つの前記要素に対して複数の前記相関関数によって異なる前記性能情報が算出され得る場合に、前記重み情報に基づいて一つの前記相関モデルを決定することができる。また、前記相関モデル生成部123は、前記第1の要素と前記第2の要素との前記相関モデルの第1の重み情報と、前記第1の要素と前記第3の要素との前記相関モデルの第2の重み情報と、前記第3の要素と前記第2の要素との前記相関モデルの第3の重み情報とをそれぞれ算出することができる。この場合、前記モデル探索部124は、前記第2の重み情報と前記第3の重み情報との合成重みと、前記第1の重み情報とを比較して、前記相関モデルを決定することができる。さらに、前記ボトルネック解析部125は、性能の前記範囲を超えた前記要素に関する性能情報とともに、他の前記要素に関する前記性能情報を利用率で順序付けして提示可能とすることができる。また、前記ボトルネック解析部125は、性能の前記範囲を超えた前記要素に関する性能情報と、前記範囲が算出された時点の入力となる前記性能情報とを含む結果を提示可能とすることができる。相関モデル生成についてここで、相関モデル生成部123による相関モデル生成の概要について、図7を参照して説明する。図7は、本実施の形態にかかる運用管理装置の相関関数生成の概要の一例を示す説明図である。相関関数生成は、図12に示す相関関数変換関数を生成するステップS103相関関数生成機能および誤差を算出するステップS104重み情報算出機能の処理により行うことができる。図7に示すように、変換関数G300は、グラフG101に示すSV1.CPUの性能値の系列第1の性能系列情報を入力とした場合に、グラフG101に示すSV1.MEMの性能値の系列第2の性能系列情報を出力するものである。この変換関数G300を、システム同定処理G301に示す処理によって算出する。一例として、y=AxBの式で示される変換関数では、A=-0.6、B=100の値が算出される。さらに、グラフG302で示すように、この変換関数でグラフG101から生成された性能値の予測値の系列と、グラフG102で示される実際の性能値の差分から重みwが生成される。図8は、本実施の形態にかかる運用管理装置の相関モデルの例である。相関モデル116aは、変換関数の入力となる性能値の系列の名称と、出力となる性能値の系列の名称と、変換関数を特定する各々係数の値と、重み情報と、を含んで構成される。例えば、図7に示す変換関数を算出した結果として、SV1.CPUを入力とし、SV1.MEMを出力とし、y=AxBの式で示される変換関数は、係数Aの値が-0.6、係数Bの値が100、重みが0.88となる相関関係が蓄積されている。モデル探索について続いて、モデル探索部124によるモデル探索の概要について、図9を参照して説明する。図9は、本実施の形態にかかる運用管理装置の重み情報を利用したモデル探索の概要の一例を示す説明図である。重み情報を利用したモデル探索は、図13に示す性能値を選択するステップS206により行うことができる。相関グラフG310では、要素x、y、zの間の変換関数として、y=2x、z=2y、z=3.9xがあり、それぞれの重みwが0.7、0.9、0.8である。重み比較処理811では、zの値を算出する場合に、x→y→zとx→zの2つの経路のそれぞれの重み0.63、0.8を比較し、値の大きいx→zの経路を選択する。この結果、x=10の場合には、z=3.9xの式を適用して、zの値39を算出する。ボトルネック解析についてさらに、ボトルネック解析部125によるボトルネック解析では、リソース情報に基づいて、モデル探索部124にて予測された性能情報が限界を超えたか否かの判定が行われる。図10は、本実施の形態にかかる運用管理装置のリソース情報の一例である。リソース情報118aは、システムの性能情報の要素の名称と、性能値の単位と、性能値の最小値と、性能値の最大値と、を含んで構成される。そして、ボトルネック解析部125では、解析結果を表示部にて表示することができる。図15は、運用管理装置の表示部に表示される表示画面の一例が示されている。同図では、ボトルネック解析における表示画面の一例が示されている。表示画面U100は、図15に示すように、ボトルネック解析の結果として、システムへの入力が600/secの値である場合に、要素SV2.CPUの性能が限界値を超えることを提示する。また、その時点での要素の一覧を、利用率の大きい順に一覧表示される。さらに、一覧表示で選択されたSV2.CPUの性能値とシステムへの入力の値との関係を示すグラフとして、変換関数で表現される予測線と検出された性能値を示す点が表示される。また、表示部に表示される表示画面U100ボトルネック解析画面は、ボトルネック解析結果を表示する解析結果表示部U110を有する。解析結果表示部U110は、利用率が最も高い要素性能種目と装置名を識別する略文字又は記号、その要素の利用率、入力性能値、などを表示することができる。さらに、表示画面U100は、利用率の高い要素を順にリストアップした要素リスト表示部U120を有する。要素リスト表示部U120は、要素性能種目、その要素の利用率、その他の情報などを表示することができる。さらに、表示画面U100は、要素リスト表示部U120の要素リストのうち、選択された要素に関するグラフを表示するグラフ表示部U130を有する。グラフ表示部U130は、性能値と入力の値との関係を示すグラフを表示することができる。グラフ表示部U130は、変換関数で表現される予測線、検出された性能値を示す点、100のライン、などを表示することができる。またさらに、表示画面U100は、相関モデルの詳細情報を表示するための第1の表示操作部U142を有する。表示画面U100は、リソース情報の詳細情報を表示するための第2の表示操作部U144を有する。表示画面U100は、ボトルネック解析画面の表示を終了するための第3の表示操作部U146を有する。管理者は、このようなユーザーインタフェースを利用して、ボトルネックがどこにあるのかを正確に解析できる。処理手順について全体処理次に、上述のような構成を有する運用管理装置における各部の処理は、方法としても実現可能であり、情報処理方法としての各種の処理手順について、図11乃至図14を参照しつつ説明する。図11は、本発明の第1の実施の形態による運用管理装置における処理手順の一例を示すフローチャートである。本実施の形態に係る情報処理方法は、システムを構成する複数の被管理装置から取得される複数種の性能種目毎の性能情報に基づいて、前記被管理装置を運用管理する制御する情報処理を例えば1又は複数のコンピュータやその他の装置などが行うものを対象とするものである。この情報処理方法は、基本的構成として、前記性能種目又は前記被管理装置を要素とした場合に、少なくとも第1の要素に関する性能情報の時系列変化を示す第1の性能系列情報と、第2の要素に関する性能情報の時系列変化を示す第2の性能系列情報との相関関数を導出し、この相関関数に基づいて相関モデルを生成し、この相関モデルを前記各要素間の組み合わせについて求める相関モデル生成ステップ例えば図11に示すステップS11などと、前記各要素間の前記各相関モデルを順次探索して最適な相関モデルを決定し、この決定された相関モデルに基づいて少なくとも前記第1の要素の性能情報から前記第2の要素の性能情報を予測するモデル探索ステップ例えば図11に示すステップS12などと、含むことができる。さらに、この情報処理方法では、前記性能情報のとり得る範囲を規定したリソース情報に基づいて、前記モデル探索ステップにて予測された前記性能情報が前記範囲を超える要素、及びその要素に関する前記性能情報を含むボトルネック解析結果を生成するボトルネック解析ステップ例えば図11に示すステップS13などを含むことができる。以下、これらの相関モデル生成、モデル探索、ボトルネック解析の詳細処理について説明する。相関モデル生成の詳細処理図12は、本発明の第1の実施の形態による運用管理装置における相関モデル生成の詳細処理手順の一例を示すフローチャートである。本実施の形態における相関モデル生成の詳細処理では、まず、情報収集部122によってサービス実行部121の動作状態が収集され、性能情報蓄積処理部122に図3に示す性能情報12aが蓄積される。ここで、相関モデル生成部123は、性能情報蓄積処理部112から性能情報12aを読み込む図12に示すステップS101。次に、未分析の性能情報の有無を判定するステップS102。相関モデルが生成されていない状態では、未分析の性能情報があるため、性能情報間の変換関数を算出する処理ステップS103に移る。最初に、性能情報12aのSV1.CPUの性能値の系列とSV1.MEMの性能値の系列の変換関数を算出する。図7を参照すると、SV1.CPUを入力xとし、SV2.MEMを出力yとする変換関数G300を、システム同定処理G301によって決定することになる。一般的に、このようなシステム同定にはいくつかの手法があり、例えば、y=AxtBxt-1Cxt-2Dyt-1Eyt-2Fといった式を用いて、xから算出したyの時系列の値が実際に検出された値に最も近くなるように、変数A~Fの値を決定することで変換関数が算出できる。以下では、説明を簡略化するために、式y=AxBのAとBを決定する形で説明するが、その例に限定されるものではなく、他のシステム同定手法を用いても1つの性能値の系列から他の性能値の系列が算出できる変換関数であれば同様の効果が得られるものである。図7のシステム同定処理G301を参照すると、関数としてy=AxBを選択し、グラフG101からグラフG102を近似できるAとBの値として、それぞれ-0.6、100を決定する図12に示すステップS103。さらに、グラフG302に示すように、グラフG101をこの変換関数で算出した予測値の系列と、グラフG102の性能値の系列を比較して、その差分である変換誤差から、この変換関数の重み情報を算出する図12に示すステップS104<重み情報算出ステップないしは重み情報算出機能>。この後、算出された変換関数と重み情報を相関モデルに追加するステップS105。図8は、このようにして追加された相関モデルの例であり、SV1.CPUとSV2.MEMの相関として、A、B、Wの値が蓄積されている。以降、同様にして、ステップS103からステップS105の処理を、性能情報12aに含まれる性能値の系列のすべての組合せに対して行うことで、相関モデル蓄積処理部116に現在のシステムの性能情報に関する相関モデルが完成する。モデル探索の詳細処理次に、本実施の形態におけるモデル探索の詳細処理について、図5、図13、図9を参照して説明する。図13は、本実施の形態にかかる運用管理装置のモデル探索の詳細処理手順の一例を示すフローチャートである。モデル探索部124は、ボトルネック解析部125から性能情報の1つの要素の値を受け取るとともにステップS201、相関モデル蓄積処理部116から相関モデルを読み込むステップS202。最初に、値が全く算出されていない状態では未探索の相関があるので、未探索の相関の有無を判定するステップS203。そして、運用管理装置が備えたコンピュータのモデル探索部124が、未探索の相関があると判定した場合には、受け取った1つの要素の値から他の要素の性能値を算出し、その算出に用いた変換関数の重みを記録するステップS204。続いて、算出済みの性能値の有無を判定するステップS205。最初の算出では、算出済みの性能値がないので、算出済みの性能値がないと判定される。算出済みの性能値がないと判定された場合には、ステップS203に戻る。そして、再度、未探索の相関を探索するステップS203。最初に受け取った性能値は決定しているので、それ以外の性能値の1つを選択し、他の性能値を算出する。同様に、出力となる性能値と重みを算出するステップS204。この場合、前回算出済みの性能値があるので、ステップS205の判定処理では、性能値があると判定される。そして、前回の算出値と、今回の算出値の重み情報を比較し、重みに応じて性能値を選択する処理を行うS206。より具体的には、図9に示すように、前回xからyおよびzを算出したとすると、yの算出値は、y=2xの変換関数が持つ0.7という重み情報を持つ。同様に、zの算出値は、z=3.9yの変換関数が持つ0.8という重み情報を持つ。ここで、今回yからzを算出する場合は、yの値の持つ0.7という重み情報に、z=2yという変換関数の持つ0.9を乗算して0.63という重み情報を得る。この値と、既に前回予測された値の重み情報0.8を比較すると、前回の方が値が大きいので、前回の値を予測値として選択しステップS206、ステップS203に戻る。このようにして、性能情報の各々の要素を複数の経路から算出し、その重みの大きいものを選択することで、最終的に、複数の経路の中で正確に予測できる変換関数の組合せで算出された値を選択することができる。ボトルネック解析の詳細処理次に、本実施の形態におけるボトルネック解析の詳細処理について、図5、図14、図10、図15を参照しつつ説明する。図14は、本実施の形態にかかる運用管理装置のボトルネック解析動作のフローチャートを示す。先ず、図14に示すように、運用管理装置が備えたコンピュータのボトルネック解析部125は、システムの入力となる要素の性能値を決定するステップS301。入力となる要素は、例えば、WEB、AP、DBで構成される3Tierのシステムであれば、WEBサーバへの入力トラフィック等が挙げられる。性能値としては、例えば、現在検出されている最大値等が挙げられる。次に、ボトルネック解析部125は、決定した性能値をモデル探索部124に渡して、モデル探索を行うステップS302。モデル探索では、与えられた性能値から、相関モデルを探索して他の性能値を算出する。この後、ボトルネック解析部125は、この算出された性能値を受け取り、リソース情報蓄積処理部118に蓄積されるリソース情報118aと比較して、性能情報に含まれる要素の利用率を算出するステップS303。例えば、SV1.CPUの現在の値を与えてモデル探索を行った場合、算出されたSV2.CPUの値と、図10のリソース情報118aに含まれるSV2.CPUの最小値、最大値と比較を行う。そして、運用管理装置が備えたコンピュータのボトルネック解析部125は、性能容量が不足しているか否かを判定するステップS304。ステップS304にて、性能容量が不足していると判定した場合には、運用管理装置が備えたコンピュータのボトルネック解析部125は、管理者に解析結果を提示するステップS306。一方、ステップS304にて、性能容量が不足していないと判定した場合には、運用管理装置が備えたコンピュータのボトルネック解析部125は、入力となる要素の性能値を順次増加させステップS305、ステップS203以降の処理を繰り返す。例えば、ステップS304において、SV2.CPUの算出値が、リソース情報118aに規定されている最小値と最大値の範囲内であれば、性能容量は不足していないと判定し、SV1.CPUの値を一定量増加させてステップS305、モデル探索を再度実施する。同様にして、入力となる要素の性能値を順次増加させながらモデル探索を行い、算出された性能値のいずれかがリソース情報118aで規定されている範囲を超えた場合、性能容量が不足していると判断し、管理者に解析結果を提示するステップS306。図15は、管理者に提示するボトルネック解析の結果の画面であり、表示画面U100では、性能容量が不足した要素SV2.CPUとその時点の入力となる性能値600/secを含む情報が提示される。これにより、管理者は、現状のサービス実行部121は、入力性能値が600/sec以上になる状況に耐えられないことがわかり、それ以上の負荷が予想される場合は、SV2の処理能力が向上するように設定変更や設備増強を行わなければならないことがわかる。ここで、前記相関モデル生成ステップでは、前記相関関数を用いて前記第1の要素に関する性能情報から算出された前記第2の要素に関する算出性能情報と、取得された前記第2の要素に関する性能情報との誤差に基づいて、前記相関モデルの重み情報を算出することができる。この場合、前記モデル探索ステップでは、少なくとも1つの前記要素に対して複数の前記相関関数によって異なる前記性能情報が算出され得る場合に、前記重み情報に基づいて一つの前記相関モデルを決定することができる。さらに、前記ボトルネック解析ステップでは、性能の前記範囲を超えた前記要素に関する性能情報とともに、他の前記要素に関する前記性能情報を利用率で順序付けすることができる。また、前記ボトルネック解析ステップでは、前記ボトルネック解析結果として、性能の前記範囲を超えた前記要素に関する性能情報と、前記範囲が算出された時点の入力となる前記性能情報とを含む結果を提示する処理を行うことができる。前記相関モデル生成ステップでは、前記第1の要素と前記第2の要素との前記相関モデルの第1の重み情報と、前記第1の要素と前記第3の要素との前記相関モデルの第2の重み情報と、前記第3の要素と前記第2の要素との前記相関モデルの第3の重み情報とをそれぞれ算出することができる。この場合に、前記モデル探索ステップでは、前記第2の重み情報と前記第3の重み情報との合成重みと、前記第1の重み情報とを比較して、前記相関モデルを決定することができる。以上のように本実施の形態によれば、相関モデル生成部が、各々の要素の性能情報間の変換関数を用いてシステムの全体的な稼動状態の相関モデルを生成する。モデル探索部が、この相関モデル内の変換関数を順次辿ることで、1つの要素の性能情報の値を仮定した場合に他の要素の性能情報の値を算出する。さらに、ボトルネック解析部が、1つの入力性能情報の値を順次増加あるいは減少させながらモデル探索部が算出した性能値が限界を超える要素を検出してその性能情報とその時点の入力性能情報の値を含む解析結果を生成する。これにより、検出された性能情報から自動的に性能情報の相関モデルを生成してボトルネック解析を行うことで、サービス実行部121のボトルネックを網羅的に解析することができる。また、実際の運用で検出された性能情報の相関関係に基づいて、相関モデル内の複数の経路を用いてより正確な性能値の算出が行えるため、解析結果の検証を管理者の経験に頼る必要がない。さらに、生成する相関モデルが各々の性能情報間を1対1で変換する変換関数で構成されるため、1つの性能情報から他の性能情報を容易に導出でき、システムが大規模化しても処理量が膨大になることがない。また、ボトルネック解析の結果として、性能の限界を超えた性能情報と、その時点の入力を提示する。このように、システムの最大性能の値と、その時にどこがボトルネックになるかという情報を合わせて提示することで、システムのどの部分の性能に注意が必要かを明確に管理者に提示できるとともに、想定される将来負荷に対してシステムのどの要素をどう増強すれば良いかを明確にできる。このように、本実施の形態では、管理者の経験と勘に頼って部分的あるいは不確かな解析しか実現できなかった関連技術に対して、管理者の能力に頼ることなく自動的に、負荷を増大させることなくシステム全体に渡って網羅的に、実稼働状況に基づき正確に、ボトルネック解析を実現することができる、という顕著な効果がある。また、本実施の形態では、重み情報によって性能値を選択する形で説明したが、これに限定されるものではなく、重み情報に基づいて複数の算出値に一定の演算をかけて性能値を算出してもよい。また、性能値の算出を行ってから重み情報で選択する形で説明したが、これに限定されるものでははく、予め重み情報に基づいて相関モデルの経路を枝刈りして探索してもよい。異なる手順であっても、1つの性能値からモデルを探索して他の性能値を算出できるものであれば、同様の効果が得られるものである。さらに、関連技術では、1つの性能情報の時間変化関数としてモデルを生成し、時間が経過した場合の、その性能情報の予測値が算出できる。また、関連技術にも2つの性能情報の間の相関係数が用いられているが、相関係数は値であって変換関数ではないので、値の予測ボトルネック解析には使えない。一方の値が判明したら他方が算出できるものでないので、異常検知の支援はできても、ボトルネック解析を実現できない。これに対して本実施の形態では、2つの性能情報の間の変換関数としてモデルを生成し、1つの性能情報の値が増えた場合の、他の要素の性能値を算出でき、システムを構成する各要素について全体としての正確な性能情報の予測を行うことができ、正確なボトルネックの要素の解析を行うことができる。このように、検出された性能情報から自動的に性能情報の相関モデルを生成してボトルネック解析を行うことで、テスト時に想定できていなかった状況も含めて、稼動時の状況に合わせたボトルネックを解析することができる。また、予め想定される特定の処理に関係するものだけでなく、サービス実行部全体の挙動を網羅的に解析することができる。さらに、実際の運用で検出された性能情報の相関関係に基づいて、将来対象システムで発生する可能性の高いボトルネックが抽出できるため、解析結果の検証を管理者の経験に頼る必要がない。さらにまた、生成する相関モデルが各々の性能情報間を1対1で変換する変換関数で構成されるため、1つの性能情報から他の性能情報を容易に導出でき、システムが大規模化しても処理量が膨大になることなくボトルネックを解析できる。このように、本発明は、検出した性能情報の相関関係を適切に抽出してモデル化することで、実際の運用状況で発生するボトルネックを正確に予測できるとともに、管理者の負担が少なく、大規模環境においても分析に必要となる処理負荷を増大させないボトルネック解析を実現できる。また、相関モデル生成部が、変換関数毎の正確さを示す重み情報を生成し、モデル探索部が、1つの性能情報に対して複数の変換関数によって異なった値が算出された場合に、重み情報に基づいて1つの値を算出する。これにより、相関モデル内の複数の経路を用いてより正確な性能値の算出が行えるため、第2の課題を解決し、より正確にボトルネックを解析できるという効果がある。またさらに、管理者対話部が、ボトルネック解析部の解析結果として、性能の限界を超えた性能情報と、その時点の入力を提示する。このように、システムの最大性能の値と、その時にどこがボトルネックになるかという情報を合わせて提示することで、想定される将来負荷に対して、システムのどの要素をどう増強すれば良いかを明確にできる。さらに、管理者対話部が、性能の限界を超えた性能情報とともに、その他の性能情報を性能の利用率で順序付けして提示する。これにより、他の性能情報も含めて、システムのどの部分の性能に注意が必要かを明確に管理者に提示することができる。ここで、図5に示すブロック図における一部の各ブロック例えば符号123、124、125、121、122、126、127、128等は、コンピュータが適宜なメモリに格納された各種プログラムを実行することにより、該プログラムにより機能化された状態を示すソフトウエアモジュール構成であってもよい。すなわち、物理的構成は例えば一又は複数のCPU或いは一又は複数のCPUと一又は複数のメモリ等ではあるが、各部回路手段によるソフトウエア構成は、プログラムの制御によってCPUが発揮する複数の機能を、それぞれ複数の部手段による構成要素として表現したものである。CPUがプログラムによって実行されている動的状態プログラムを構成する各手順を実行している状態を機能表現した場合、CPU内に各部手段が構成されることになる。プログラムが実行されていない静的状態にあっては、各手段の構成を実現するプログラム全体或いは各手段の構成に含まれるプログラム各部は、メモリなどの記憶領域に記憶されている。以上に示した各部手段の説明は、プログラムにより機能化されたコンピュータをプログラムの機能と共に説明したものと解釈することも出来るし、また、固有のハードウエアにより恒久的に機能化された複数の電子回路ブロックからなる装置を説明したものとも解釈することが出来ることは、当然である。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現でき、いずれかに限定されるものではない。また、各部は、通信可能な専用のコンピュータからなる装置としてそれぞれ構成し、これらの各装置により運用管理システムを構成してもよい。[第2の実施の形態]次に、本発明にかかる第2の実施の形態について、図16、図17、図18、図19、図20、図21に基づいて説明する。以下には、前記第1の実施の形態の実質的に同様の構成に関しては説明を省略し、異なる部分についてのみ述べる。図16は、本発明の運用管理装置の第2の実施の形態の一例を示すブロック図である。本実施の形態における構成は、第1の実施の形態の図5を用いて説明した構成に加えて、総計性能値管理部231を含む構成としている。具体的には、本実施の形態の運用管理装置200は、図16に示すように、前記第1の実施の形態の構成である、サービス実行部221、性能情報蓄積処理部212、情報収集部222、分析設定蓄積処理部214、障害分析部226、管理者対話部227、対処実行部228、相関モデル生成部223、相関モデル情報蓄積処理部216、モデル探索部224、リソース情報蓄積処理部218、ボトルネック解析部225に加えて、総計性能値管理部231と、を含んで構成される。リソース情報蓄積処理部218は、図5で説明した情報に加えて、複数の性能情報から算出される総計性能情報とその算出の対象となる複数の性能情報の組み合わせを指定するグループ情報を蓄積する。総計性能値管理部231は、リソース情報蓄積処理部218からグループ情報を受け取り、相関モデル生成部223に対して総計性能情報の生成を指示する。また、総計性能値管理部231は、モデル探索部224に対して総計性能情報の値の更新を指示する。相関モデル生成部223は、第1の実施の形態の機能に加えて、総計性能値管理部231の指示に従って、検出された複数の性能情報の同時刻の値に一定の算術演算を行って算出した値の時系列を性能値とする総計性能情報を生成し、性能情報にこの総計性能情報を加えて相関モデルを生成する。モデル探索部224は、第1の実施の形態の機能に加えて、性能情報の値を算出する場合に、総計性能値管理部231からの指示に従って総計性能情報の値を再計算する総計性能情報再計算機能。ここで、これらの各部は、図17に示すように、制御部が発揮する複数の機能として構成することもできる。また、統計性能値管理部231は、前記要素をグループ化し、各要素の統計性能値を生成することができる。この場合、前記相関モデル生成部223は、前記統計性能値によるグループ要素を新要素として加え、一の前記新要素と他の前記新要素との相関から相関モデルを生成することができる。このような構成からなる運用管理装置200において、総計性能値を用いた相関モデル生成の概要について説明する。図18は、本実施の形態にかかる運用管理装置の総計性能値を用いた相関モデル生成の概要の一例を示す説明図である。図18に示すように、構成グラフG320は、WEB層、AP層、DB層の3層からなる負荷分散システムの構成を示し、WEB層が3台のサーバで負荷分散され、AP層が2台のサーバで負荷分散される。性能情報の要素A~Cは、WEB層の各サーバの性能を示し、同様に、要素D~EはAP層、要素FはDB層の性能を示す。相関グラフG321では、第1の実施の形態で説明した動作で相関モデルを生成した場合の結果の一例を示す。同じ処理を分散して実行する各層では正確な相関関係が生成でき、層間では有意な相関関係ができなかった例である。相関グラフG322は、本実施の形態の総計性能値を用いて相関モデルを生成した場合の一例を示す。WEB層の性能値の合計の値を持つ総計性能情報X、AP層の性能値の合計の値を持つ総計性能情報Yをそれぞれ生成している。これにより、層間に正確な相関関係を生成できる。このように、総計性能値を用いることで、各層間を相関させることができる。次に、総計性能情報を蓄積するためのリソース情報蓄積処理部218のリソース情報118bのデータ構造について説明する。図19は、本実施の形態にかかる運用管理装置のリソース情報のデータ構造の一例を示す。リソース情報118bは、図10に示すリソース情報118aの情報に加えて、グループという新たな属性が追加されている。総計性能情報X、総計性能情報Yでは、グループ情報として総計性能値の算出に必要な性能情報の要素が列挙されている。例えば、総計性能情報Xでは、図18の構成グラフG320に示すWEB層の性能情報の要素A、B、Cをグループ情報として持つ。また、総計性能情報Yでは、図18の構成グラフG320に示すAP層の性能情報の要素D、Eをグループ情報として持つ。総計性能情報以外の性能情報の要素では、グループ情報には何も記述されていない。リソース情報118aのテーブルにグループ情報の項目を設けることで、各要素の性能値をグループ化して、総計性能情報を管理することができる。処理手順について次に、上述のような構成を有する運用管理装置における各部の処理は、方法としても実現可能であり、運用管理方法としての各種の処理手順について、図20乃至図21を参照しつつ説明する。相関モデル生成の詳細処理図20は、本実施の形態にかかる運用管理装置の相関モデル生成の詳細処理手順の一例を示すフローチャートである。図20では、第1の実施の形態で図12を用いて説明したステップS101~S105と同様のステップであるステップS401~S405に加えて、総計性能情報を生成するステップS406が追加されている。本実施の形態における相関モデル生成の詳細処理は、第1の実施の形態で説明したものと同様であり、性能情報を読み込むステップS401に続いて、総計性能情報を生成するステップS402を行う点が異なる。図20を参照すると、相関モデル生成部223は、性能情報蓄積処理部212から性能情報を読み込むとともにステップ401、総計性能値管理部231の指示に従って総計性能情報を生成するステップ402。この場合、総計性能値管理部231は、リソース情報蓄積処理部218からリソース情報118bを読み込み、グループ情報が指定されている総計性能情報Xと総計性能情報Yを探索し、この総計性能情報Xと総計性能情報Yを生成することを相関モデル生成部223に指示する。相関モデル生成部223は、この指示に従って、性能情報の要素A、B、Cの同時刻の性能値を加算して総計性能情報Xの性能値の時系列を生成する。同様に、性能情報の要素D、Eから総計性能情報Yの時系列を生成する。以降、性能情報蓄積処理部212に蓄積されている他の性能情報にこの総計性能情報X、総計性能情報Yを加えて相関モデルの生成を行う。第1の実施の形態で説明した通り、未分析性能情報がなくなるまでステップ403、変換関数の生成ステップ404、重みの算出ステップ405、相関モデルの追加ステップ406を繰り返す。図18は、このようにして生成される相関モデルの一例を示す。構成グラフG320は、図18に示すように、WEB、AP、DBの3層構成で、それぞれのサーバが3台、2台、1台で構成されるシステムである。各サーバの性能情報の相関関係をモデル化した場合、相関グラフG321に示すように、各層の間の相関関係は、適切に生成できない場合がある。あるいは、各層の間の相関関係は生成できるが、極めて誤差の大きい場合がある。例えば、DB層の処理負荷は、性能情報の要素Fのみに現れるが、AP層の処理負荷は、2台のサーバで分散して行われるため、要素D、Eで分散して現れる。ここで、要素Dと要素Fの相関関係を考えると、要素Fの性能値は、要素Dと要素Eの両方の性能値の和に依存する。要素Dと要素Eが全く均等に処理を分散している場合には、要素Dの性能値の2倍が要素Fと相関することになるが、処理に偏りがあった場合、要素Dの性能値だけからは要素Fの性能値が正確に特定できない。同様に、要素Eと要素Fの間の相関も希薄となる。同じ問題がWEB層とAP層の間にも発生し、要素A、B、Cから要素D、Eへの相関は希薄となる。この結果、相関グラフ821に示すような部分的な相関関係しか抽出できない状態が発生する。一般的には、このような不具合を解決するために、要素の1対1の変換関数ではなく、N対1の変換関数を用いて相関モデルを生成することが考えられる。しかし、性能情報の要素の数が増えると膨大な計算資源が必要となる。加えて、入力がN個、出力が1個の変換関数では、ある1つの性能値を算出するためには、N個の入力が確定していなければならず、システムの1つの入力負荷が増えた場合にどこがボトルネックになるかというような解析を行うことが困難になってしまう。そこで、本実施の形態における総計性能情報を用いた相関モデル生成の場合、相関グラフG322に示すように、実際に検出される要素A~Fに加えて要素X、Yが生成される。要素Yは、AP層の要素D、Eの性能値の総和であり、要素Yによって、AP層のサーバが1台であるかのように扱うことができる。この結果、AP層全体の処理負荷を示す要素Yと、DB層全体の処理負荷を示す要素Fには明確な相関関係ができる。同様にして、WEB層全体を示す要素XとAP層全体を示す要素Yにも相関関係ができる。モデル探索の詳細処理図21は、本実施の形態にかかる運用管理装置のモデル探索の詳細処理手順の一例を示すフローチャートである。図21では、第1の実施の形態で図13を用いて説明したステップS201~S206と同様のステップであるステップS501~S506に加えて、グループ指定を判定するステップS507と総計性能情報を再計算するステップS408が追加されている。図21を参照すると、本実施の形態におけるモデル探索の動作は、第1の実施の形態で説明したものと同様であり、性能値を決定するステップS506の後に、決定した性能値が総計性能情報に使われているかを判定するステップS507と、総計性能情報を再計算するステップS508が追加されている点が異なる。モデル探索部224は、ある入力性能値に対する他の性能値を算出するために、総計性能情報を含む相関モデルを読み込んで探索を行うステップS501~ステップS506。また、総計性能値管理部231の指示に従って、総計性能情報の算出に用いられる性能値を算出した場合にステップS507、新しい性能値で総計性能情報を再計算するステップS508。さらに、ボトルネック解析部225が、このようなモデル探索による性能値の算出を繰り返すことで、システムの最大性能とボトルネック要素を特定する。図19を参照すると、リソース情報118bには、ボトルネック解析部225が総計性能情報の利用率を判定するための属性が記述されている。例えば、総計性能情報Xは、最大値が100である要素A、B、Cの3個の値の総和であるため、最大値が300となっている。また、総計性能情報Yでは、最大値が1000Mbpsの要素D、Eの2個の総和であるが、ネットワークの帯域は、足し算にはならない場合があるため、最大値が1000Mbpsとなっている。このようなリソース情報302を元に、どの要素がボトルネックになるかを解析できる。ここで、例えば、図18の要素Aの負荷が増加すると予想すると、同じWEB層での相関関係から、要素A、B、Cの間の負荷が算出でき、これらの総和から要素Xの値が算出できる。また、要素Xから要素Y、要素Fの性能値が算出できる。さらに、要素Yの算出値から、グループである要素D、Eの性能値も算出できる。この結果、要素Aの負荷が増加する場合に、DBサーバである要素Fにどのような負荷がかかるかを正確に算出することができる。また、前記相関モデル生成ステップでは、前記要素をグループ化して各要素の統計性能値を生成し、前記統計性能値によるグループ要素を新要素として加え、一の前記新要素と他の前記新要素との相関から相関モデルを生成することができる。以上のように本実施の形態によれば、前記第1の実施の形態と同様の作用効果を奏しながらも、相関モデル生成部が、総計性能値管理部231の指示に従って、検出された複数の性能情報に一定の算術演算を行って算出した総計性能情報を含んだ相関モデルを生成し、モデル探索部10が、この総計性能情報を含めて性能情報の値を算出する。これにより、例えば、負荷分散処理といったように、1つの性能情報が複数の性能情報の値の総和と関係する場合にも、処理量を増大させること無く正確なボトルネック解析が可能となる。このように、本実施の形態にかかる発明には、第1の実施の形態の効果に加えて、膨大な処理負荷が必要となる従来技術に対して、処理負荷の増加を総計性能情報の数の増加分だけに押さえた上で、複数の要素との相関関係にも対応し、より正確にボトルネック解析を実現することができるという顕著な効果がある。また、本実施の形態では、総計性能値の演算を、各要素の性能値の和で行う形で説明したが、これに限定されるものではなく、各要素の性能値に一定の演算をかけて総計性能値を算出してもよい。また、総計性能値管理部が、相関モデル生成部とモデル探索部に指示する形で説明したが、これに限定されるものではなく、性能情報蓄積処理部に直接総計性能値を書き込むものや、相関モデルにグループの依存関係を示す属性を加えて探索を行うものであってもよい。異なる形であっても、検出された性能情報に一定の演算を加えた新たな性能情報を生成し探索することができるものであれば、同様の効果が得られるものである。このように、相関モデル生成部が、総計性能値管理部の指示に従って、検出された複数の性能情報に一定の算術演算を行って算出した総計性能情報を含んだ相関モデルを生成し、モデル探索部が、この総計性能情報を含めて性能情報の値を算出する。これにより、例えば、負荷分散処理といったように、1つの性能情報が複数の性能情報の値の総和と関係する場合にも、処理量を増大させること無く正確なボトルネック解析が可能であり、第4の課題を解決し、負荷を抑えて正確な解析が行えるという効果がある。その他の構成およびその他のステップないしは機能並びにその作用効果については、前述した実施の形態の場合と同一となっている。また、上記の説明において、上述した各ステップの動作内容及び各部の構成要素並びにそれらによる各機能をプログラム化し、コンピュータに実行させてもよい。[第3の実施の形態]次に、本発明にかかる第3の実施の形態について、図22に基づいて説明する。以下には、前記第1の実施の形態の実質的に同様の構成に関しては説明を省略し、異なる部分についてのみ述べる。図22は、本発明の運用管理装置の第3の実施の形態の一例を示すブロック図である。本発明の第3の実施の形態の運用管理装置は、第2の実施の形態で図13を用いて説明した構成に加えて、分析設定生成部を含む構成としている。具体的には、本実施の形態の運用管理装置300は、図22に示すように、前記第2の実施の形態の構成である、サービス実行部321、性能情報蓄積処理部312、情報収集部322、分析設定蓄積処理部314、障害分析部326、管理者対話部327、対処実行部328、相関モデル生成部323、相関モデル情報蓄積処理部316、モデル探索部324、リソース情報蓄積処理部318、ボトルネック解析部325、総計性能値管理部331に加えて、分析設定生成部332を含んで構成される。分析設定生成部332は、ボトルネック解析部325の解析結果を受け取り、ボトルネックとなることが予想される性能情報を、障害分析部326で監視および分析するための追加設定を生成し、この追加設定に従って分析設定蓄積処理部314に蓄積される分析設定を修正する。ボトルネック解析部325は、管理者対話部327から管理者の入力を受け取って、分析設定生成部332に設定情報の修正を指示することができる。ここで、ここで、これらの各部は、図23に示すように、制御部が発揮する複数の機能として構成することもできる。また、分析設定生成部332は、前記ボトルネック解析部にて解析された前記要素について障害分析の監視対象として監視設定を行うことができる。処理手順について次に、上述のような構成を有する運用管理装置における各部の処理は、方法としても実現可能であり、情報処理方法としての各種の処理手順について、図24乃至図26を参照しつつ説明する。図24は、本発明の第3の実施の形態による運用管理装置における処理手順の一例であり、運用管理装置の分析設定生成の詳細処理手順の一例を示すフローチャートである。図25は、本実施の形態にかかる運用管理装置のボトルネック解析での表示画面の例である。第1の実施の形態で図15を用いて説明した表示画面に加えて、分析設定の操作ボタンが追加されている。図26は、本実施の形態にかかる運用管理装置のボトルネック解析での表示画面の例である。図25の分析設定の操作ボタンから呼び出され、管理者が設定変更の可否を確認するものである。図24を参照すると、まず、ボトルネック解析部325がボトルネック解析処理を行うステップS601。本実施の形態におけるボトルネック解析の動作は、第1、第2の実施の形態で説明したものと同じである。分析設定生成部332は、ボトルネック解析部325から、ボトルネック解析の結果を受け取り、分析設定蓄積処理部314の分析設定を参照し、ボトルネックとなっている要素が障害分析の対象となっていない場合にはステップS602、ボトルネック要素を監視するための監視設定を追加するステップS603。また、以前に追加したボトルネック要素が、今回のボトルネック解析で安全と判断されていればステップS604、その分析設定を削除するステップS605。これらのステップS601乃至ステップS605により、設定追加ステップを行うことができる。この設定追加ステップでは、コンピュータが、前記ボトルネック解析ステップにて解析された前記要素について障害分析の監視対象として監視設定を追加することができる。図25は、運用管理装置の表示部に表示される表示画面の一例が示されている。同図では、ボトルネック解析における表示画面の一例が示されている。表示画面U200は、図15に示す表示画面U100と同様の構成である、解析結果表示部U210、要素リスト表示部U220、グラフ表示部U230、相関モデルの詳細情報を表示するための第1の表示操作部U242、リソース情報の詳細情報を表示するための第2の表示操作部U244、ボトルネック解析画面の表示を終了するための第3の表示操作部U248に加え、分析設定の操作ボタンである第4の表示操作部U246が追加されている。第4の表示操作部U246を押下することで、図26に示す表示画面U300が表示される。表示画面U300分析ルール設定画面では、分析ルールを設定するための分析ルール表示設定部U320、現在の設定されている分析ルールを一覧表示した分析ルール一覧表示部U330、分析ルールを追加するか否かのメッセージを表示したメッセージ表示部U310、分析ルール設定画面での設定完了の確認を行うための各表示操作部U342、U344が表示形成されている。管理者は、ここで、ボトルネック要素が監視対象からもれていないかどうかを確認し、必要に応じて分析設定の修正を行う。以上のように本実施の形態によれば、前記第1の実施の形態と同様の作用効果を奏しながらも、分析設定生成手段が、ボトルネックとなることが予想される性能情報を障害分析手段で監視および分析するための追加設定を生成する。これにより、システムを網羅的に解析して発見された新たなボトルネックに対して、その要素を継続的に監視することが可能となり、より適切な運用管理が行えるという新たな効果がある。その他の構成およびその他のステップないしは機能並びにその作用効果については、前述した実施の形態の場合と同一となっている。また、上記の説明において、上述した各ステップの動作内容及び各部の構成要素並びにそれらによる各機能をプログラム化し、コンピュータに実行させてもよい。その他の各種変形例また、本発明にかかる装置及び方法は、そのいくつかの特定の実施の形態に従って説明してきたが、本発明の主旨および範囲から逸脱することなく本発明の本文に記述した実施の形態に対して種々の変形が可能である。例えば、上記構成部材の数、位置、形状等は上記実施の形態に限定されず、本発明を実施する上で好適な数、位置、形状等にすることができる。すなわち、上記実施の形態では、統計性能情報を算出するにあたり、Web層、AP層、DB層でグループ化したが、本発明は、これらの層数を制限するものではない。他の種々の区分によってグループ化する場合であってもよい。本発明の運用管理ソフトウエアは、1台のPCにインストールする場合であっても、クライアントサーバシステムにおける端末及びサーバ、P2Pで利用可能な構成であっても構わない。また、各種表示画面などはWeb上でアクセス可能な構成であっても構わない。また、本実施の形態の一態様の運用管理装置は、WEBサービスや業務サービスといった情報通信サービスを提供するサービス実行部と、前記サービス実行部の各々の要素の性能情報を蓄積する性能情報蓄積処理部と、前記サービス実行部の動作状態を検出して出力するとともに、前記動作状態に含まれる性能情報を前記性能情報蓄積処理部に蓄積する情報収集部と、前記サービス実行部の異常を検出するための分析設定を蓄積する分析設定蓄積処理部と、前記情報収集部から前記動作状態を受け取って前記分析設定蓄積処理部の分析設定に従って障害分析を行う障害分析部と、前記障害分析部から前記障害分析の結果を受け取って管理者に提示し、管理者の入力を受け付ける管理者対話部と、前記管理者対話部の指示に応じて前記サービス実行部上で障害の対処となる処理を実行する対処実行部と、で構成される運用管理装置において、前記性能情報蓄積処理部から一定期間の性能情報を取り出し、任意の2つの性能情報の値の時系列に対して、一方を入力とし他方を出力とした場合の変換関数を導出する処理をすべての性能情報に対して繰り返すことで、前記サービス実行部の全体的な稼動状態の相関モデルを生成する相関モデル生成部と、前記相関モデル生成部が生成した相関モデルを蓄積する相関モデル蓄積処理部と、前記相関モデル蓄積処理部の前記相関モデルの各々の性能情報間の変換関数を順次辿ることで、1つの性能情報の値を仮定した場合に他の性能情報の値を算出するモデル探索部と、前記性能情報毎の性能値の最大値、最小値、単位といった属性を記述した情報であるリソース情報を蓄積するリソース情報蓄積部と、前記性能情報のうち予め指定された1つの入力性能情報の値を順次増加あるいは減少させながら前記モデル探索部に指示するとともに、モデル探索部が算出した他の性能情報の値を受け取って前記リソース情報蓄積部のリソース情報と比較して性能値が限界を超える要素を検出してその性能情報とその時点の入力性能情報の値を含む解析結果を生成し、前記管理者対話部に出力するボトルネック解析部と、を有することができる。この運用管理装置においては、相関モデル生成部が、各々の2つの性能情報間の変換関数としてサービス実行部の全体的な稼動状態の相関モデルを生成する。また、モデル探索部が、この相関モデル内の変換関数を順次辿ることで、1つの性能情報の値を仮定した場合に他の性能情報の値を算出する。さらに、ボトルネック解析部が、1つの入力性能情報の値を順次増加あるいは減少させながらモデル探索部が算出した他の性能情報の値を受け取って性能値が限界を超える要素を検出してその性能情報とその時点の入力性能情報の値を含む解析結果を生成する。このように、検出された性能情報から自動的に性能情報の相関モデルを生成してボトルネック解析を行うことで、テスト時に想定できていなかった状況も含めて、稼動時の状況に合わせたボトルネックを解析することができ、第1の課題を解決する。また、予め想定される特定の処理に関係するものだけでなく、サービス実行部全体の挙動を網羅的に解析することができる。さらに、実際の運用で検出された性能情報の相関関係に基づいて、将来対象システムで発生する可能性の高いボトルネックが抽出できるため、解析結果の検証を管理者の経験に頼る必要がない。さらにまた、生成する相関モデルが各々の性能情報間を1対1で変換する変換関数で構成されるため、1つの性能情報から他の性能情報を容易に導出でき、システムが大規模化しても処理量が膨大になることなくボトルネックを解析できる。本実施の形態の一態様の運用管理装置は、本発明の第1の運用管理装置において、前記相関モデル蓄積部が、前記相関モデルに前記変換関数毎の正確さを示す重み情報を新たに蓄積するとともに、前記相関モデル生成部が、前記相関モデルの生成時に前記変換関数を導出する処理に加えて、前記変換関数で生成された性能値の系列と出力となる前記性能情報の実際の検出値の系列とを比較し、その値の差から前記変換関数の重み情報を算出する機能を新たに有し、前記モデル探索部が、1つの性能情報に対して複数の変換関数によって異なった値が算出された場合に、前記重み情報に基づいて1つの値を選択あるいは算出する機能を新たに有することができる。この運用管理装置においては、相関モデル生成部が、変換関数毎の正確さを示す重み情報を生成し、モデル探索部が、1つの性能情報に対して複数の変換関数によって異なった値が算出された場合に、重み情報に基づいて1つの値を算出する。これにより、相関モデル内の複数の経路を用いてより正確な性能値の算出が行えるため、第2の課題を解決し、より正確にボトルネックを解析できるという効果がある。本実施の形態の一態様の運用管理装置は、前記管理者対話部が、前記ボトルネック解析部の解析結果として、性能の限界を超えた前記性能情報と、その限界が算出された時点の入力となる前記性能情報とを含む結果画面を管理者に提示することができる。この運用管理装置においては、管理者対話部が、ボトルネック解析部の解析結果として、性能の限界を超えた性能情報と、その時点の入力を提示する。このように、システムの最大性能の値と、その時にどこがボトルネックになるかという情報を合わせて提示することで、想定される将来負荷に対して、システムのどの要素をどう増強すれば良いかを明確にできる。本実施の形態の一態様の運用管理装置は、前記管理者対話部が提示する前記結果画面が、性能の限界を超えた前記性能情報とともに、その他の前記性能情報を性能の利用率で順序付けして提示することができる。この運用管理装置においては、管理者対話部が、性能の限界を超えた性能情報とともに、その他の性能情報を性能の利用率で順序付けして提示する。これにより、他の性能情報も含めて、システムのどの部分の性能に注意が必要かを明確に管理者に提示することができるという新たな効果がある。本実施の形態の一態様の運用管理装置は、前記リソース情報蓄積部が、複数の性能情報から算出される総計性能情報とその算出の対象となる複数の前記性能情報の組み合わせを指定するグループ情報を新たに蓄積する機能を有し、前記リソース情報蓄積部の前記グループ情報を受け取り、前記相関モデル生成部に前記総計性能情報の生成を指示するとともに、前記モデル探索部に前記総計性能情報の値の更新を指示する総計性能値管理部を新たに有し、前記相関モデル生成部が、前記総計性能値管理部の指示に従って検出された複数の前記性能情報の同時刻の値に一定の算術演算を行って算出した値の時系列を性能値とする前記総計性能情報を生成し、前記性能情報にこの総計性能情報を加えて前記相関モデルを生成する機能を新たに有し、前記モデル探索部が、前記性能情報の値を算出する場合に、前記総計性能値管理部の指示に従って前記総計性能情報の値を再計算する機能を新たに有することができる。この運用管理装置においては、相関モデル生成部が、総計性能値管理部の指示に従って、検出された複数の性能情報に一定の算術演算を行って算出した総計性能情報を含んだ相関モデルを生成し、モデル探索部が、この総計性能情報を含めて性能情報の値を算出する。これにより、例えば、負荷分散処理といったように、1つの性能情報が複数の性能情報の値の総和と関係する場合にも、処理量を増大させること無く正確なボトルネック解析が可能であり、負荷を抑えて正確な解析が行えるという効果がある。本実施の形態の一態様の運用管理装置は、前記ボトルネック解析部の解析結果を受け取り、ボトルネックとなることが予想される性能情報を前記障害分析部で監視および分析するための追加設定を生成し、この追加設定に従って前記分析設定蓄積部に蓄積される分析設定を修正する分析設定生成部を新たに有することができる。と特徴とする。この運用管理装置においては、分析設定生成部が、ボトルネックとなることが予想される性能情報を障害分析部で監視および分析するための追加設定を生成する。本実施の形態の一態様の運用管理装置は、前記ボトルネック解析部が、前記管理者対話部から管理者の入力を受け取って前記設定情報を修正する機能を有することができる。この運用管理装置は、この分析設定を管理者の入力によって制御することができる。これにより、システムを網羅的に解析して発見された新たなボトルネックに対して、その要素を継続的に監視することが可能となり、より適切な運用管理が行えるという新たな効果がある。このように、検出した性能情報の相関関係を適切に抽出してモデル化することで、実際の運用状況で発生するボトルネックを正確に予測できるとともに、管理者の負担が少なく、大規模環境においても分析に必要となる処理負荷を増大させないボトルネック解析を実現できるという顕著な効果がある。さらに、本発明の運用管理装置を構成する手段は、その有する機能をハードウェア的に実現することは勿論、コンピュータとプログラムとで実現することができる。プログラムは、磁気ディスクや半導体メモリ等のコンピュータ可読記録媒体に記録されて提供され、コンピュータの立ち上げ時などにコンピュータに読み取られ、そのコンピュータの動作を制御することにより、そのコンピュータを前述した各実施の形態における手段として機能させることができる。プログラムまた、前述した実施形態の機能を実現する本発明のソフトウエアのプログラムは、前述した各実施の形態における各種ブロック図などに示された処理部処理手段、機能などに対応したプログラムや、フローチャートなどに示された処理手順、処理手段、機能などに対応したプログラムなどにおいて各々処理される各処理プログラム、本明細書で全般的に記述される方法ステップ、説明された処理、データの全体もしくは各部を含む。具体的には、本発明の運用管理プログラムは、システムを構成する複数の被管理装置から複数種の性能種目毎の性能情報を取得して、前記被管理装置を運用管理する運用管理装置が備えたコンピュータに諸機能を実現させることが可能なものである。この運用管理プログラムは、前記性能種目又は前記被管理装置を要素とした場合に、少なくとも第1の要素に関する性能情報の時系列変化を示す第1の性能系列情報と、第2の要素に関する性能情報の時系列変化を示す第2の性能系列情報との相関関数を導出し、この相関関数に基づいて相関モデルを生成し、この相関モデルを前記各要素間の組み合わせについて求める相関モデル生成機能例えば図5に示す符号123などの構成、図11に示すステップS11の機能などと、前記各要素間の前記各相関モデルを順次探索して最適な相関モデルを決定し、この決定された相関モデルに基づいて少なくとも前記第1の要素の性能情報から前記第2の要素の性能情報を予測するモデル探索機能例えば図5に示す符号124などの構成、図11に示すステップS12の機能などと、を含む機能をコンピュータに実現させることができる。また、この運用管理プログラムは、前記性能情報のとり得る範囲を規定したリソース情報に基づいて、前記モデル探索部にて予測された前記性能情報が前記範囲を超える要素、及びその要素に関する前記性能情報を含むボトルネック解析結果を生成するボトルネック解析機能例えば図5に示す符号125などの構成、図11に示すステップS13の機能などを含む機能をコンピュータに実現させることができる。さらに、この運用管理プログラムは、前記相関モデル生成機能では、前記相関関数を用いて前記第1の要素に関する性能情報から算出された前記第2の要素に関する算出性能情報と、取得された前記第2の要素に関する性能情報との誤差に基づいて、前記相関モデルの重み情報を算出する機能をコンピュータに実現させることができる。この場合、前記モデル探索機能では、少なくとも1つの前記要素に対して複数の前記相関関数によって異なる前記性能情報が算出され得る場合に、前記重み情報に基づいて一つの前記相関モデルを決定する機能をコンピュータに実現させることができる。また、この運用管理プログラムは、前記要素をグループ化し、各要素の統計性能値を生成する統計性能値管理機能を含む機能をコンピュータに実現させることができる。さらに、この運用管理プログラムは、前記相関モデル生成機能では、前記統計性能値によるグループ要素を新要素として加え、一の前記新要素と他の前記新要素との相関から相関モデルを生成する機能をコンピュータに実現させることができる。また、この運用管理プログラムは、前記ボトルネック解析機能にて解析された前記要素について障害分析の監視対象として監視設定を行う分析設定生成機能を含む機能をコンピュータに実現させることができる。さらに、この運用管理プログラムは、前記ボトルネック解析機能では、性能の前記範囲を超えた前記要素に関する性能情報とともに、他の前記要素に関する前記性能情報を利用率で順序付けして提示する機能をコンピュータに実現させることができる。また、この運用管理プログラムは、前記ボトルネック解析機能では、性能の前記範囲を超えた前記要素に関する性能情報と、前記範囲が算出された時点の入力となる前記性能情報とを含む結果を提示する機能をコンピュータに実現させることができる。さらに、この運用管理プログラムは、前記相関モデル生成機能では、前記第1の要素と前記第2の要素との前記相関モデルの第1の重み情報と、前記第1の要素と前記第3の要素との前記相関モデルの第2の重み情報と、前記第3の要素と前記第2の要素との前記相関モデルの第3の重み情報とをそれぞれ算出する機能をコンピュータに実現させることができる。この場合、前記モデル探索機能では、前記第2の重み情報と前記第3の重み情報との合成重みと、前記第1の重み情報とを比較して、前記相関モデルを決定する機能をコンピュータに実現させることができる。プログラムは、オブジェクトコード、インタプリタにより実行されるプログラム、OSに供給するスクリプトデータ等、プログラムの形態を問わない。プログラムは、高水準プロシージャ型またはオブジェクト指向プログラミング言語で、あるいは必要に応じてアセンブリまたはマシン言語で実装することができる。いずれの場合も、言語はコンパイラ型またはインタープリタ型言語であってもよい。上述のプログラムを、一般のパソコンや携帯型情報端末などで動作可能なアプリケーションソフトに組み込んだものも含む。プログラムを供給する手法としては、電気通信回線有線、無線を問わないによってコンピュータと通信可能に接続された外部の機器から前記電気通信回線を通じて提供することも可能である。例えば、コンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページからプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、プログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるサーバも、本発明の範囲に含まれるものである。本発明のプログラムによれば、当該運用管理プログラムを格納するROM等の記憶媒体から、当該運用管理プログラムをコンピュータCPUに読み込んで実行させれば、或いは、当該運用管理プログラムを、通信部を介してコンピュータにダウンロードさせた後に実行させれば、上述した本発明に係る装置を比較的簡単に実現できる。発明の思想の具現化例として装置のソフトウェアとなる場合には、かかるソフトウェアを記憶した記憶媒体上においても当然に存在し、利用される。また、プログラムは、一次複製品、二次複製品などの複製段階については全く問う余地無く同等である。プログラムの供給方法として通信回線を利用して行なう場合であれば通信回線が伝送媒体となって本発明が利用されることになる。むろん、プログラムの発明として特定することもできる。さらに、装置における従属請求項は、方法,プログラムにおいて従属請求項に対応した構成にすることも可能である。情報記録媒体また、上述のプログラムを、情報記録媒体に記録した構成であってもよい。情報記録媒体には、上述のプログラムを含むアプリケーションプログラムが格納されており、コンピュータが当該情報記録媒体からアプリケーションプログラムを読み出し、当該アプリケーションプログラムをハードディスクにインストールすることが可能である。これにより、上述のプログラムは、磁気記録媒体、光記録媒体あるいはROMなどの情報記録媒体に記録してプログラムを提供することができる。そのようなプログラムが記録された情報記録媒体を、コンピュータにおいて使用することは、好都合な情報処理装置を構成する。プログラムを供給するための情報記録媒体としては、例えばROM、RAM、フラッシュメモリやSRAM等の半導体メモリ並びに集積回路、あるいはそれらを含むUSBメモリやメモリカード、光ディスク、光磁気ディスク、磁気記録媒体等を用いてよく、さらに、フレキシブルディスク、CD-ROM、CD―R、CD―RW、FD、DVDROM、HDDVDHDDVD-R-SL<1層>、HDDVD-R-DL<2層>、HDDVD-RW-SL、HDDVD-RW-DL、HDDVD-RAM-SL、DVD±R-SL、DVD±R-DL、DVD±RW-SL、DVD±RW-DL、DVD-RAM、Blu-RayDisk<登録商標>BD-RーSL、BD-R-DL、BD-RE-SL、BD-RE-DL、MO、ZIP、磁気カード、磁気テープ、SDカード、メモリスティック、不揮発性メモリカード、ICカード、等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置、等に記録して構成して用いてよい。さらに情報記録媒体は、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの伝送媒体ないしは伝送波、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また、コンピュータ上で稼働しているOS、端末例えば携帯電話など上のRTOS等が処理の一部又は全部を行う場合にも、上記実施の形態と同等の機能を実現できると共に、同等の効果を得ることができる。さらに、プログラムを暗号化してCD-ROM等の記録媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。この場合、本発明の構成は、プログラムの各構成要素各種の手段、ステップ及びデータと、前記プログラム各種の手段、ステップ及びデータを暗号化する暗号化手段と、を含んでよい。また、上記実施の形態では、クライアントサーバーシステムを例に説明したが、サーバを介さずに端末同士がネットワークを組み、相互にデータを送受信するピアツーピアPeerToPeer通信によるシステムであってもよい。その際、管理装置は、ピアツゥピア方式におけるマスタ端末であればよいまた、上述の実施の形態のシステムを、他の情報処理システムと統合したシステムとして、これら全体を本発明のシステムとして構成することも一向に構わない。情報処理システムには、OSや周辺機器等のハードウェアを含むものとする。また、前記実施の形態におけるシステムとは、複数の装置が論理的に集合した物をいい、各構成の装置が同一筐体中にあるか否かは問わない。このため、本発明は、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。システムには、OSや周辺機器等のハードウェアを含んでもよい。さらに、上述のプログラムなどが搭載される情報処理装置としては、サーバは、例えばパーソナルコンピュータに限らず、各種サーバー、EWSエンジニアリングワークステーション、中型コンピュータ、メインフレームなどが挙げられる。情報端末は、以上の例に加えて、携帯型情報端末、各種モバイル端末、PDA、携帯電話機、ウエアラブル情報端末、種々の携帯型などのテレビDVDレコーダ各種音響機器及びそのリモコン、各種情報通信機能を搭載した家電機器、ネットワーク機能を有するゲーム機器等からも利用できる構成としても構わない。あるいは、これらの端末に表示されるアプリケーションとして改良されたものも本発明の範囲に含めることができる。また、上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル差分プログラムであっても良い。さらに、本明細書において、フローチャートに示されるステップは、記載された手順に従って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理を含むものである。また、実装では、プログラム手順ステップが実行される順序を変更することができる。さらに、実装の必要に応じて、本明細書で説明した特定の手順ステップを、組み合わされた手順ステップとして実装、除去、追加、または再配置することができる。さらに、装置の各手段、各機能、各ステップの手順の機能などのプログラムの機能を、専用のハードウエア例えば専用の半導体回路等によりその機能を達成してもよく、プログラムの全機能のうち一部の機能をハードウエアで処理し、全機能のうちさらに他の機能をソフトウエアで処理するようにしてもよい。専用のハードウエアの場合、各部を集積回路例えばLSIにて形成されてもよい。これらは個別に1チップ化されても良いし、一部または全部を含むように1チップ化されても良い。また、LSIには、ストリーミングエンジンなど他の機能ブロックが含まれていても良い。また、集積回路化の手法はLSIに限るものではなく、専用回路又は汎用プロセサで実現してもよい。さらには、半導体技術の進歩又は派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。さらに、通信では、無線通信および有線通信は勿論、無線通信と有線通信とが混在した通信、即ち、ある区間では無線通信が行われ、他の区間では有線通信が行われるようなものであってもよい。さらに、ある装置から他の装置への通信が有線通信で行われ、他の装置からある装置への通信が無線通信で行われるようなものであってもよい。そして、この通信には通信網が含まれる。通信網を構成するネットワークとしては、例えば携帯電話回線網基地局及び交換システムを含む、公衆電話回線網、IP電話網、ISDN回線網などこれに類する各種回線網、インターネット乃ち、TCPIPプロトコルを用いた通信態様やイントラネット、LANイーサネット登録商標、やギガビットイーサネット登録商標などを含む、WAN、光ファイバー通信網、電力線通信網、ブロードバンド対応可能な各種専用回線網などいずれのハードウエア構成でもよい。さらに、ネットワークは、TCPIPプロトコルの他、種々の通信プロトコルを用いたネットワークあるいはソフトウエア的に構築された仮想ネットワークやこれに類するあらゆるネットワークを含むネットワークなどいかなる通信プロトコルであってもよい。また、ネットワークは、有線に限らず、無線衛星通信、各種高周波通信手段等を含むネットワーク例えば、簡易電話システムや携帯電話のようなシングルキャリア通信システム、W―CDMAやIEEE802.11bに準拠した無線LANのようなスペクトラム拡散通信システム、IEEE802.11aやHiperLAN/2のようなマルチキャリア通信システム、などを含むネットワークであっても構わず、これらの組み合わせを利用してもよく、他のネットワークと接続されたシステムであってもよい。さらに、ネットワークは、ポイントツーポイント、ポイントツーマルチポイント、マルチポイントツーマルチポイントなど如何なる形態でもよい。また、運用管理装置と他の被管理装置との間の通信構造に際し、いずれか一方又は双方に形成されるインタフェースの種類は、例えばパラレルインタフェース、USBインタフェース、IEEE1394、LANやWAN等のネットワークやその他これに類するもの、もしくは今後開発される如何なるインタフェースであっても構わない。さらに、相関モデルを生成し、モデル探索を行う手法は、必ずしも実体のある装置に限られる必要はなく、その方法としても機能することは容易に理解できる。このため、方法にかかる発明も、必ずしも実体のある装置に限らず、その方法としても有効であることに相違はない。この場合、方法を実現するための一例として運用管理装置、運用管理システムなども含めることができる。ところで、このような運用管理装置は、単独で存在する場合もあるし、ある機器に組み込まれた状態で利用されることもあるなど、発明の思想としてはこれに限らず、各種の態様を含むものである。従って、ソフトウェアであったりハードウェアであったりするなど、適宜、変更可能である。発明の思想の具現化例として装置のソフトウェアとなる場合には、かかるソフトウェアを記憶した記憶媒体上においても当然に存在し、利用されるといわざるをえない。さらに、一部がソフトウェアであって、一部がハードウェアで実現されている場合であってもよく、一部を記憶媒体上に記憶しておいて必要に応じて適宜読み込まれるような形態のものとしてあってもよい。本発明をソフトウェアで実現する場合、ハードウェアやオペレーティングシステムを利用する構成とすることも可能であるし、これらと切り離して実現することもできる。また、発明の範囲は、図示例に限定されないものとする。さらに、上記各実施の形態には種々の段階が含まれており、開示される複数の構成要件における適宜な組み合わせにより種々の発明が抽出され得る。つまり、上述の各実施の形態同士、あるいはそれらのいずれかと各変形例のいずれかとの組み合わせによる例をも含む。この場合において、本実施形態において特に記載しなくとも、各実施の形態及びそれらの変形例に開示した各構成から自明な作用効果については、当然のことながら実施の形態の作用効果として含めることができる。逆に、本実施の形態に記載されたすべての作用効果を奏することのできる構成が、本発明の本質的特徴部分の必須構成要件であるとは限らない。また、実施の形態に示される全構成要件から幾つかの構成要件が削除された構成による実施の形態並びにその構成に基づく技術的範囲も発明になりうる。そして、各実施の形態及びそれらの変形例を含むこれまでの記述は、本発明の理解を容易にするために、本発明の多様な実施の形態のうちの一例の開示、すなわち、何れも本発明を実施するにあたっての具体化の例を示したものに過ぎず、例証するものであり、制限するものではなく、適宜変形及び/又は変更が可能である。本発明は、その技術思想、またはその主要な特徴に基づいて、様々な形で実施することができ、各実施の形態及びその変形例によって本発明の技術的範囲が限定的に解釈されてはならないものである。従って、上記に開示された各要素は、本発明の技術的範囲に属する全ての設計変更や均等物を含む趣旨である。"