JP2011146074A - 運用管理装置、運用管理システム、情報処理方法、及び運用管理プログラム - Google Patents

Abstract

【課題】本発明は、実運用で発生するボトルネックを正確に予測できる運用管理装置を提供する。
【解決手段】運用管理装置は、性能情報の時系列変化を示す性能系列情報から性能情報間の複数の相関関数および各相関関数の予測誤差を示す重み情報を含む相関モデルを生成する相関モデル生成部１２３と、性能情報のうちの第１の性能情報から第２の性能情報を予測しうる相関関数またはその組み合わせによる経路が相関モデルの中に複数存在する場合に、重み情報の数値が最大となる経路を利用して第２の性能情報を予測するモデル探索部１２４を含む。
【選択図】図５

Description

本発明は、運用管理装置、運用管理システム、情報処理方法、及び運用管理プログラムに関し、特に、情報通信サービスを提供するシステム全体の性能のボトルネックを解析する運用管理装置などに関する。

企業情報システムやＩＤＣ（Ｉｎｔｅｒｎｅｔ Ｄａｔａ Ｃｅｎｔｅｒ）など比較的大規模なシステムなどにおいて、ＷＥＢサービスや業務サービスといった情報通信サービスの社会インフラとしての重要性が高まるにつれて、そのサービスを提供するサーバなどの装置の安定稼動が重要となっている。このような装置の運用管理は、管理者が手作業で行っていた。装置が大規模・複雑化するにつれて、管理者には知識および操作の面での負担が飛躍的に増大し、判断ミスや操作ミスによるサービス停止といった事態も発生している。

このような事態に対処するため、システムを構成するハードウェアあるいはソフトウェアを一元的に状態監視し制御する統合運用管理システムが提供されている。

この統合管理システムでは、管理対象となる複数のハードウェアまたはソフトウェアの稼動状況に関する情報をオンラインで取得し、統合管理システムに接続した表示装置に出力する。管理対象となるシステムの障害を判別するには、あらかじめ性能情報に閾値を設定しておく方法や、平均値からのずれを評価する方法などがあり、障害と判定された場合、該箇所が報告される。
障害箇所が報告された場合、それがメモリ容量不足が原因なのか、ＣＰＵ負荷が原因なのか、ネットワーク負荷が原因なのか等、解決のために原因を絞り込む必要がある。一般に原因の解明には関係がありそうな計算機のシステムログやパラメータの調査、さらにはシステムエンジニアの経験と勘に頼る必要があり、解決に時間と労力を要する。

このため、統合運用管理システムでは、複数の機器から収集したイベントデータ（状態通知）に基づいて異常状態の組み合わせ等の分析を自動的に行い、大局的な問題点や原因を推定して管理者に通知し、対処支援を行うことが重要となる。

特に、サービスの長期連続運用での信頼性確保には、発生した異常だけでなく、明確な異常になっていない性能劣化や将来発生が予想される障害の兆候といった状態を検出し、計画的な設備増強を行うことが求められている。このような要求への対応として、統合運用管理システムにおいて、システム全体における性能のボトルネックの解析を行うことが重要となる。

このような統合運用管理システムに関連する技術として、例えば以下に示す特許文献１乃至特許文献７などが挙げられる。

第１の関連技術である特許文献１の運用管理装置では、システムへの入力を擬似的に発生させるテストを行うことによって、想定される高負荷な状態で性能監視を行い、ボトルネックとなる要素を特定する。この運用管理装置では、テスト時と同様な負荷が発生した場合のシステムの挙動を分析することができる。

第２の関連技術である特許文献２の運用管理装置では、システム要素の処理の履歴と性能情報の変化の履歴とを比較することによって、特定の処理に起因する負荷量を特定し、将来の処理量での負荷を分析する。この運用管理装置では、予め処理と負荷との関係が把握できている場合には、システムの挙動を特定することができる。

第３の関連技術である特許文献３の運用管理装置では、収集した性能情報の履歴から、各々の性能情報の時系列変化を曲線近似して将来値を予測する。この運用管理装置では、現在の性能変化から発生しうる状況を仮説として導出し、ボトルネックとなり得る要素の候補を列挙する。

第４の関連技術である特許文献４の運用管理装置では、システムの構成要素間の関係の大きさを稼動情報を元に定量化することにより障害の原因となる構成要素を特定する。この運用管理装置では、異常となった要素に対して、その時点で性能値に相関のある要素が重み付けされて一覧表示されることで、原因の候補を列挙する。

第５の関連技術である特許文献５の運用管理装置では、稼働情報収集部は、監視対象システム内の複数の装置から、ＩＣＭＰ、ＳＮＭＰ、ｒｓｈなどを利用して、ＣＰＵ、Ｎｅｔｗｏｒｋ ＩＯ（ネットワークＩｎｐｕｔ／Ｏｕｔｐｕｔ）などのハードウェア稼動情報、Ｗｅｂサーバのアクセス量、ＤＢサーバの処理クエリ量などのアプリケーション稼動情報を一定時間間隔で取得し、稼動情報ＤＢに保存する。
前処理部は、稼働情報ＤＢに格納されている各構成要素の稼働情報間の統計的分析値を求める統計処理を行う。前処理部は、例えば、各稼働情報間の相関係数を求めたり、各稼働情報間で主成分分析を行ったりして、統計的分析値を求める。この統計的分析値は、所定時刻における各装置の稼働情報間の関連度を示す値となっている。例えば特許文献５の図２では、「サーバ１のＣＰＵ使用率」と「サーバ２のＣＰＵ使用率」との相関係数が「０．９３」等となっている。相関係数は、２つの変量間の相関関係の程度を表す数値である。
このような運用管理装置では、まず、監視対象となるサーバ、ネットワーク機器等から、ＣＰＵ使用率のようなハードウェア稼動情報、またＷｅｂサーバであれば、アクセスの状況といったアプリケーションレベルの情報を定期的に取得するようにし、正常なアクセス時や、障害発生時といった各状況における稼動情報から、各状況を特徴付ける“取得値間の関連”を相関分析・主成分分析といった統計的手法を用いて算出し、各状況のモデルを定義してモデル情報ＤＢに保持しておく。
そして、運用時には、定期的に、あるいは障害のアラートや、提供サービスのレスポンス低下などをトリガとして、現在の稼働情報に対して定義したモデルと同様の統計的手法を行い、モデル情報ＤＢに定義したモデルと比較して、マッチしたモデルの状況を現在置かれている状況として識別する。

第６の関連技術である特許文献６の運用管理装置では、モニタ部は、ＡＣ環境及び非ＡＣ環境の状態に係る状態情報を取得し、分析部又はモデル診断部は、取得された状態情報に基づいて、ＡＣ環境の装置の状態を判定する。シミュレーション部は、その判定結果に対応する対策リストを参照し、対策リストに含まれる少なくとも一つの対策夫々によるシミュレーション処理を実行し、各対策の効果を評価する。
モデル抽出部は、時間に対するＣＰＵの使用率の関係を表す座標系において、時間１〜時間３の監視データをプロットし、プロットした各監視データの線形近似式（ｆａ（ｘ）＝αｘ＋β）を求めることによって、ＣＰＵ使用率の時系的変化を表すモデルを抽出する。モデル抽出部は、抽出したモデルを知識情報蓄積部に対して蓄積する。
同様にして、時間に対するスループットの関係を表す座標系においてもモデルを求める。
そして、モデル抽出部は、これらの２つのモデルに対して相関分析及び多変量解析を行うことで、処理Ａと処理Ｂとの夫々について、ＣＰＵ使用率とスループットとの相関を表す線形近似式（ｆＴＡ（ｘ）＝ρ１ｘ＋θ１、ｆＴＢ（ｘ）＝ρ２ｘ＋θ２）を求め、ＣＰＵ使用率とスループットとの相関を示すモデルを抽出する。モデル診断部は、各モデルに該当するポリシーを夫々参照し診断を実行する（特許文献６の段落番号００６０〜００６２）。

第７の関連技術である特許文献７では、コンピュータ上でどのようなワークロードが稼動中かを判断し、ワークロードのタイプに基づいてコレクタを始動し、ワークロード・ミックスに基づいてメトリックスのためのしきい値を設定し、メトリックスがしきい値を超えるときを（現在のワークロードおよび予測されるワークロードの両方で）判断し、メトリックスの相関をとってハードウェア・キャパシティが問題の原因かどうかを判断する。

特開２００３−１３１９０７号公報 特開２００６−０２４０１７号公報 特開２００２−２６８９２２号公報 特開２００２−３４２１８２号公報 特開２００６−１４６６６８号公報 特開２００７−２０７１１７号公報 特表２００５−５２４８８６号公報

しかしながら、関連技術の運用管理装置においては、次のような不具合がある。

すなわち、特許文献１では、運用継続によって部分的に構成が変更されたり、サービス利用に偏りが生じたりすると、テスト時とは異なる要素に負荷が集中することになる。このような変化を事前にすべて想定することは困難であり、結果的に、想定外の利用状況で予期せぬ要素がボトルネックになってしまうことを避けられない、という不具合があった。

特許文献２では、システムが大規模化したり、他システムと連携したりする場合には、処理と負荷の関係が極めて複雑になり、正確な負荷を予測するためには、関係しうるすべての処理の履歴を収集して分析しなければならない。
このため、正確な予測には、データ収集および分析の負荷が大きく、それを分析するための高度な知識も必要となる、という不具合があった。また、特定の処理だけから予測された負荷では信頼性が低く、正確なボトルネック解析ができない、という不具合があった。

特許文献３では、システムを構成する要素の性能値は完全に独立に変動するものではないため、各々の性能情報から予測された値がシステムの実稼動で発生しうるかどうかは、別途管理者が検証しなければならない。このため、ボトルネックとなる要素を正確に判定するために、管理者に多くの知識が要求され、検証の作業負担も大きくなるという不具合があった。

特許文献４では、性能情報間の関係の大きさを定量化するだけでは、因果関係があり得るという仮説を提示できるのみであり、第３の関連技術と同様に、実際にどれが原因なのかを管理者が検証しなければならないという不具合があった。
また、関係の大きさを定量化するために、１つの要素毎に他の要素のすべてとの重回帰分析する処理が必要となるため、システムが大規模化して要素が増えると負荷が膨大になってしまうという不具合があった。
さらに、ある１つの要素の値に対して他の要素の値を算出することが困難であるため、将来発生しうる負荷に対してどの要素がボトルネックとなり得るかといった解析ができないという不具合があった。

特許文献５では、相関係数は値であるため、ある時点（異常時）の値の相関から、関係する異常原因を提示できるが、実在しない将来値の相関を算出することはできないので、正確なボトルネック解析を行うことができない、という不具合があった。

特許文献６では、個々の性能情報の関数を推定するもの（第３の関連技術と同様）である。そして、ｙ＝ｆ（ｘ）の式において、ｘは時間で、１つのｙの時間変化を表す。この式を２つ用意して、別途与えた相関関係ルールで２つの関係を判定する。ルールは、自動生成されるわけではないので、システムを構成する各要素について全ての性能情報間のルールを別途与えなければ、ボトルネック解析を正確に予測できない、という不具合があった。
すなわち、ＣＰＵ使用率とスループットとの相関は、一の要素と他の要素との間の相関のみであるため、システムを構成する全要素についてのそれぞれ相関が不明であるため、システムのボトルネックがどの要素に最も生じやすくなるかを予測することができない、という不具合があった。

特許文献７では、ワークロードやメトリックスの変換は行われるが、いずれも値を算出しているものであるため、モデルを用いないため、これらの変換方法の全てを手作業で入力しなければならない、という不具合があった。

このように、関連技術の運用管理装置では、実際の運用状況で発生するボトルネックを正確に予測できず、管理者の負担や分析処理の負荷が増大する、という不具合があった。
すなわち、第１に、将来発生しうる状況を事前にすべて想定することは困難であり、結果的に、想定外の利用状況で予期せぬ要素がボトルネックになってしまうことを避けられないという不具合があった。
第２に、正確な予測には、データ収集および分析の負荷が大きく、それを分析するための高度な知識も必要となるという不具合があった。また、特定に処理だけから予測された負荷では信頼性が低く、正確なボトルネック解析ができないという不具合があった。
第３に、ボトルネックとなる要素を正確に判定するために、管理者に多くの知識が要求され、検証の作業負担も大きくなるという不具合があった。
第４に、システムが大規模化して要素が増えると負荷が膨大になってしまうという問題があった。さらに、ある１つの要素の値に対して他の要素の値を算出することが困難であるため、将来発生しうる負荷に対してどの要素がボトルネックとなり得るかといった解析ができない、という不具合があった。

本発明は、上記した技術の不具合を解決することを課題としてなされたものであって、その目的とするところは、実際の運用状況で発生するボトルネックを正確に予測可能としながらも、管理者の負担が少なく、大規模環境においても分析に必要となる処理負荷を低減したボトルネック解析が可能な運用管理装置、運用管理システム、情報処理方法、及び運用管理プログラムを提供することにある。

上記目的を達成するため、本発明の運用管理装置は、システムを構成する被管理装置から複数種の性能種目に関わる性能情報を取得する運用管理装置であって、前記性能情報の時系列変化を示す性能系列情報から前記性能情報間の複数の相関関数および前記各相関関数の予測誤差を示す重み情報を含む相関モデルを生成する相関モデル生成部と、前記性能情報のうちの第１の性能情報から第２の性能情報を予測しうる前記相関関数またはその組み合わせによる経路が前記相関モデルの中に複数存在する場合に、前記重み情報の数値が最大となる前記経路を利用して前記第２の性能情報を予測するモデル探索部と備えることを特徴としている。

本発明の運用管理システムは、複数のコンピュータ装置である被管理装置と、前記複数の被管理装置から該装置の動作に関する複数種の性能種目に関わる性能情報を取得する運用管理装置と、を含み、前記運用管理装置は、前記性能情報の時系列変化を示す性能系列情報から前記性能情報間の複数の相関関数および前記各相関関数の予測誤差を示す重み情報を含む相関モデルを生成する相関モデル生成部と、前記性能情報のうちの第１の性能情報から第２の性能情報を予測しうる前記相関関数の組み合わせによる経路が前記相関モデルの中に複数存在する場合に、前記重み情報の数値が最大となる前記経路を利用して前記第２の性能情報を予測するモデル探索部とを備えることを特徴としている。

本発明の情報処理方法は、システムを構成する複数のコンピュータ装置である被管理装置から取得される該装置の動作に関する複数種の性能種目に関わる性能情報に基づいて、前記被管理装置を運用管理する情報処理方法であって、前記性能情報の時系列変化を示す性能系列情報から前記性能情報間の複数の相関関数および前記各相関関数の予測誤差を示す重み情報を含む相関モデルを生成する相関モデル生成ステップと、前記性能情報のうちの第１の性能情報から第２の性能情報を予測しうる前記相関関数の組み合わせによる経路が前記相関モデルの中に複数存在する場合に、前記重み情報の数値が最大となる前記経路を利用して前記第２の性能情報を予測するモデル探索ステップとを含むことを特徴としている。

本発明の運用管理プログラムは、システムを構成する複数のコンピュータ装置である被管理装置から該装置の動作に関する複数種の性能種目に関わる性能情報を取得して、前記被管理装置を運用管理する運用管理装置が備えたコンピュータに諸機能を実現させることが可能な運用管理プログラムであって、前記性能情報の時系列変化を示す性能系列情報から前記性能情報間の複数の相関関数および前記各相関関数の予測誤差を示す重み情報を含む相関モデルを生成する相関モデル生成機能と、前記性能情報のうちの第１の性能情報から第２の性能情報を予測しうる前記相関関数の組み合わせによる経路が前記相関モデルの中に複数存在する場合に、前記重み情報の数値が最大となる前記経路を利用して前記第２の性能情報を予測するモデル探索機能と、を含む機能をコンピュータに実現させることを特徴としている。

本発明によれば、相関モデル生成部が、各々の要素の性能情報間の相関関数を用いてシステムの全体的な稼動状態の相関モデルを生成する。また、モデル探索部が、この相関モデル内の相関関数を順次辿ることで、一の要素の性能情報を仮定した場合に他の要素の性能情報を予測する。
これにより、各要素の性能情報間の相関関係を適切に抽出してモデル化することで、実際の運用状況で発生するボトルネックを正確に予測できるとともに、管理者の負担が少なく、大規模環境においても分析に必要となる処理負荷を増大させないボトルネック解析を実現できるという、関連技術にない優れた運用管理装置、運用管理システム、情報処理方法、及び運用管理プログラムを提供することができる。

本発明の第１の実施の形態による運用管理装置を含む運用管理システムの全体構成の一例を示すブロック図である。 本発明の第１の実施の形態による運用管理装置の前提となる構成の一例を示すブロック図である。 本発明の第１の実施の形態による運用管理装置で利用する性能情報の一例を示す説明図である。 本発明の第１の実施の形態による運用管理装置で利用する性能情報の時系列変化のグラフの一例を示す説明図である。 本発明の第１の実施の形態による運用管理装置の全体構成の一例を示すブロック図である。 本発明の第１の実施の形態による運用管理装置の全体構成の一例を示すブロック図である。 本発明の第１の実施の形態による運用管理装置において、変換関数同定を説明するための一例を示す説明図である。 本発明の第１の実施の形態による運用管理装置において、相関モデルのデータ構造の一例を示す説明図である。 本発明の第１の実施の形態による運用管理装置において、重み比較を説明するための一例を示す説明図である。 本発明の第１の実施の形態による運用管理装置において、リソース情報のデータ構造の一例を示す説明図である。 本発明の第１の実施の形態による運用管理装置において処理される全体の処理手順の一例を示すフローチャートである。 本発明の第１の実施の形態による運用管理装置において、相関モデル生成の詳細処理手順の一例を示すフローチャートである。 本発明の第１の実施の形態による運用管理装置において、モデル探索の詳細処理手順の一例を示すフローチャートである。 本発明の第１の実施の形態による運用管理装置において、ボトルネック解析の詳細処理手順の一例を示すフローチャートである。 本発明の第１の実施の形態による運用管理装置において、表示される表示画面の一例を説明するための説明図である。 本発明の第２の実施の形態による運用管理装置の全体構成の一例を示すブロック図である。 本発明の第２の実施の形態による運用管理装置の全体構成の一例を示すブロック図である。 本発明の第２の実施の形態による運用管理装置において、総計性能値生成を説明するための一例を示す説明図である。 本発明の第２の実施の形態による運用管理装置において、リソース情報のデータ構造の一例を示す説明図である。 本発明の第２の実施の形態による運用管理装置において、相関モデル生成の詳細処理手順の一例を示すフローチャートである。 本発明の第２の実施の形態による運用管理装置において、モデル探索の詳細処理手順の一例を示すフローチャートである。 本発明の第３の実施の形態による運用管理装置の全体構成の一例を示すブロック図である。 本発明の第３の実施の形態による運用管理装置の全体構成の一例を示すブロック図である。 本発明の第３の実施の形態による運用管理装置において、分析設定生成の詳細処理手順の一例を示すフローチャートである。 本発明の第３の実施の形態による運用管理装置において、表示される表示画面の一例を説明するための説明図である。 本発明の第３の実施の形態による運用管理装置において、表示される表示画面の一例を説明するための説明図である。

〔運用管理装置の基本的構成〕
先ず、運用管理装置の基本的構成について説明する。本発明の運用管理装置（例えば図５に示す符号１００など）は、システムを構成する複数の被管理装置から複数種の性能種目毎の性能情報を取得して、前記被管理装置を運用管理するものを対象とするものである。

この運用管理装置は、前記性能情報の時系列変化を示す性能系列情報から前記性能情報間の複数の相関関数および前記各相関関数の予測誤差を示す重み情報を含む相関モデルを生成する相関モデル生成部（例えば図５に示す符号１２３など）と、前記性能情報のうちの第１の性能情報から第２の性能情報を予測しうる前記相関関数またはその組み合わせによる経路が前記相関モデルの中に複数存在する場合に、前記重み情報の数値が最大となる前記経路を利用して前記第２の性能情報を予測するモデル探索部（例えば図５に示す符号１２４など）と、を含む構成としている。

また、前記相関モデル生成部が、前記性能系列情報のうちの２項目についての前記相関関数の係数および前記重み情報を算出する処理を前記性能系列情報の全ての組み合わせについて行って前記相関モデルを生成するものとすることができる。

この運用管理装置では、前記モデル探索部が、少なくとも１つの前記第１の性能情報に対して複数の前記経路によって異なる前記第２の性能情報が算出され得る場合に、前記重み情報の数値が最大となる前記経路を利用すべき経路として決定する。

さらに、前記モデル探索部が、前記相関モデルに含まれる前記各相関関数を順次探索して、前記各性能情報間の利用すべき経路を決定する処理を行う。

そして、前記モデル探索部が、決定された前記経路に基づいて前記第１の性能情報から前記第２の性能情報を予測する機能を備えるものとすることができる。

このように、本発明の運用管理装置では、検出した性能情報の相関関係を適切に抽出してモデル化することで、関連技術の課題を解決し、管理者の負担が少なく、大規模環境においても分析に必要となる処理負荷を増大させないボトルネック解析を実現できる。

以下、このような本発明の「運用管理装置」を、「運用管理システム」に適用した好適な実施の形態の一例について、図面を参照して具体的に説明する。

〔第１の実施の形態〕
（運用管理システムの全体構成）
先ず、本実施の形態の運用管理システムの具体的構成について、全体構成から説明し、続いて各部の詳細構成について説明することとする。
図１は、本発明における第１実施の形態の運用管理装置を含む運用管理システムの全体の概略構成の一例を示すブロック図である。

図１に示すように、本実施の形態の運用管理システム１は、複数の被管理装置の一例である各コンピュータ２と、これらの各コンピュータ２とネットワークＮを介して通信可能に形成され各コンピュータ２を運用管理する運用管理装置３と、を含んで構成される。

運用管理装置３は、複数のコンピュータ２から複数種の性能種目毎（例えばＣＰＵ利用率やメモリ残量など）の性能情報を取得可能に構成される。

コンピュータ２、運用管理装置３は、プログラム制御により動作するものであり、ネットワーク関連の機能を有していれば、デスクトップ、ラップトップコンピュータ、サーバー、その他無線・有線通信機能を有する情報機器、またはこれに類するコンピュータなどいかなるコンピュータでもよく、移動式・固定式を問わない。

運用管理装置３のハードウエア構成は、種々の情報等を表示するための表示部（スクリーン）、この表示部の表示画面上（の各種入力欄等）にデータを操作入力するための操作入力部（例えばキーボード・マウス等）、各種信号・データを送受信するための送受信部（通信部）、各種プログラム・各種データを記憶しておく記憶部（例えばメモリ、ハードディスク等）、これらの制御を司る制御部（例えばＣＰＵ等）などを有している。

また、コンピュータ２は、ネットワーク機器やその他の機器、メインフレームなどであってもよい。

（前提となる構成）
ここで、本実施の形態の特徴的構成を説明する前に、本実施の形態の前提となる運用管理装置の構成について、図２、図３、図４を用いて説明する。
図２を参照すると、本実施の形態の前提となる構成を示す運用管理装置３は、サービス実行部２１と、性能情報蓄積処理部１２と、情報収集部２２と、分析設定蓄積処理部１４と、障害分析部２６と、管理者対話部２７と、対処実行部２８と、を含んで構成される。

サービス実行部２１は、ＷＥＢサービスや業務サービスといった情報通信サービスを提供するものである。このサービス実行部２１は、他の独立したコンピュータなどで構成することもできる。
性能情報蓄積処理部１２は、サービス実行部２１の各々の要素の性能情報を蓄積する。
情報収集部２２は、サービス実行部２１の動作状態を検出して出力するとともに、動作状態に含まれる性能情報を性能情報蓄積処理部１２に蓄積する。

分析設定蓄積処理部１４は、サービス実行部２１の異常を検出するための分析設定を蓄積する。
障害分析部２６は、情報収集部２２から動作状態を受け取って分析設定蓄積処理部１４の分析設定に従って障害分析を行う。

管理者対話部２７は、障害分析部２６から障害分析の結果を受け取って管理者に提示し、管理者の入力を受け付け、管理者の入力に従って対処実行部２８に対処を指示する。
対処実行部２８は、管理者対話部２７の指示に応じてサービス実行部２１上で障害の対処となる処理を実行する。

図３は、情報収集部２２が出力し、性能情報蓄積処理部１２に蓄積される性能情報の例を示す。性能情報１２ａは、サービス実行部２８の状態変化に伴って順次収集される性能情報の一覧を示す。性能情報１２ａを参照すると、個々の性能情報は、同一時刻の各々の性能の値で構成され、それらが一定時間間隔でリストアップされたものとなっている。

図４は、性能情報に含まれる１つの要素を時系列グラフで示した例を示す。グラフＧ１０１は、図３に示す性能情報１２ａに含まれる「ＳＶ１．ＣＰＵ」を時系列で示し、グラフＧ２０１は、グラフＧ１０１の時系列の変化を線形予測した例を示す。

上述のような前提となる構成を有する運用管理装置３の動作について、図２、図３、図４を用いて説明する。

まず、図２の情報収集部２２がサービス実行部２１の動作状態を検出し、性能情報蓄積処理部１２に性能情報を蓄積する。例えば、サービス実行部２１でＷＥＢサービスが実行されている場合、ＷＥＢサービスを提供する各サーバのＣＰＵ使用率やメモリ残量を一定時間間隔で検出する。
図３の性能情報１２ａは、このようにして検出された性能情報の例である。例えば、「ＳＶ１．ＣＰＵ」は、１つのサーバのＣＰＵ利用率の値を示し、２００７年１０月５日の１７時２５分の値が１２である。さらに、１分間隔で１７時２６分から１５、３４、６３といった値が検出されている。同様に、「ＳＶ１．ＭＥＭ」は同じサーバのメモリ残量の値を、「ＳＶ２．ＣＰＵ」は別のサーバのＣＰＵ利用率の値を、それぞれ同時刻に検出したものである。

次に、障害分析部２６は、分析設定蓄積処理部１４に蓄積されている分析設定に従って障害分析を行う。分析設定としては、例えば、ＣＰＵ利用率が一定値以上であれば管理者に警告メッセージを提示するといったことが指定されており、これに従って、情報収集部２２で検出された性能情報の値から、特定のサーバの負荷が高くなっているかどうかを閾値判定する。

管理者対話部２７は、このような障害分析の結果を管理者に提示し、管理者が何らかの対処を指示する入力を行った場合、対処実行部２８を介してサービス実行部２１上で対処コマンドを実行する。
例えば、管理者は、ＣＰＵ負荷が高くなっていることを知って、業務量を減らしたり、負荷分散を行うための構成変更を行ったりすることができる。

この後、一定時間間隔で情報収集部２２によって収集された性能情報の値が低下していれば、障害分析部２６で障害が回復したと判断され、その結果が管理者対話部２７を介して管理者に提示されることになる。このような情報収集、分析、対処の処理の繰り返しにより、サービス実行部２１の障害対処が継続して行われる。

ここで、第１の関連技術に示した運用管理装置では、運用管理装置３のサービス実行部２１に相当する機能により、想定される高負荷状態になるような処理を実行する。
例えば、ＷＥＢサービスの多数のクライアントからのアクセスを擬似的に発生させる等である。この状態で、運用管理装置３の情報収集部２２に相当する機能により、サービス実行部２１に相当する機能から性能情報を収集し、障害分析部２６に相当する機能によって分析を行えば、想定される高負荷状態において、システムのどの要素が異常となるかが把握できる。
例えば、図４のグラフＧ１０１に示すような負荷が得られ、そのピーク値が閾値を超えて予め判明している危険域に達することがわかれば、「ＳＶ１」の処理能力が不足することがわかる。逆に、すべての性能情報が閾値以内であることがわかれば、想定される負荷に対してシステムが安全であることがわかる。

この第１の関連技術では、想定される高負荷状態の場合のシステムの性能情報は正確に分析できるものの、将来システムに発生しえる高負荷状態をすべて事前にテストすることはできない。例えば、クライアントが平均的なサービス利用を行う場合のアクセスを発生させるテストによって、平均的と思われる利用での耐障害性を確保することが可能である。しかし、利用者の嗜好や社会的な状況変化から特定のサービスに偏ったアクセスが行われる場合までを想定することは困難であり、結果的に、運用が長期化すると、想定外の利用によって予期せぬ要素がボトルネックとなって障害が発生してしまう場合が多くなるという不具合があった。

このような分析をさらに詳細に行うものとして、第２の関連技術に示した運用管理装置では、運用管理装置３の情報収集部２２に相当する機能により、性能情報に加えて、運用管理装置３のサービス実行部２１に相当する機能にて行われた処理の履歴を収集し、運用管理装置３の障害分析部２６に相当する機能にて性能情報と処理履歴を合わせて分析する。
例えば、予めＣＰＵ負荷との関係がわかっている処理の詳細な実行履歴を収集することで、いつどの処理が実行されるとどの程度のＣＰＵ利用率になるのかを算出することができる。図４のグラフＧ１０１におけるピーク値が、どの処理によって引き起こされたのかがわかれば、その処理がいつ行われる予定であるかによって、将来の「ＳＶ１．ＣＰＵ」の負荷を予測することができる。

この第２の関連技術では、予め性能との因果関係が明確な処理に対しては、詳細な障害分析が行えるものの、処理の履歴を追加収集するために処理負荷が増加するとともに、因果関係が複雑になると、管理者がその分析結果を理解することが難しくなる。
特に、近年ＩＴシステムは社会インフラとしての重要性が増しており、システムが大規模化し、他システムと連携する場合が多い。このような状況では、膨大な処理履歴を収集する負荷が発生し、複雑な因果関係を分析する高度な知識も必要となってしまう、という不具合があった。

処理との関連ではなく各々の性能情報の時系列変化から負荷の予測を行うものとして、第３の関連技術に示した運用管理装置では、運用管理装置３の障害分析部２６に相当する機能が、検出された性能情報の時系列変化の傾向を分析し、将来の変化を予測する。
例えば、図４のグラフＧ１０１のような時系列変化から、グラフＧ２０１のように「ＳＶ１．ＣＰＵ」の値が単調増加の傾向にあることを導出し、その増加割合からＣＰＵ負荷が危険域になる時期を予測することができる。同様に、他の要素に対しても危険域になる時期を予測すれば、システム全体として最も早く危険域に達すると予想される要素を発見することができる。

この第３の関連技術では、各々の要素の将来ボトルネックになる可能性を管理者に提示することが可能であるものの、その状況が実際に発生しうるかどうかは管理者が経験によって判断しなければならない。
例えば、メモリ残量が一定以下になれば、新たな処理は開始できずにメモリ量の回復を待つ場合がある。メモリ残量の変化を考慮しなければ、ＣＰＵ負荷がある時点の傾向と同様に将来も単調増加するかどうかは明確ではない。
管理者は、傾向予測の結果の妥当性を判断するために、実際にシステムに存在する要素間の相関関係を正確に理解しなければならず、管理者への負担が大きい、という不具合があった。

システムを構成する要素間の相関関係を分析するものとして、第４の関連技術に示した運用管理装置では、運用管理装置３の障害分析部２６に相当する機能が、あるシステム要素の性能異常を発見した場合に、情報収集部２２から受け取った性能情報から、その時点の性能値に相関のある構成要素の一覧を生成し、管理者対話部２７に相当する機能にて管理者に提示する。
例えば、図３の性能情報１２ａにおける「ＳＶ１．ＣＰＵ」の異常を発見した場合に、「ＳＶ１．ＭＥＭ」や「ＳＶ２．ＣＰＵ」の値と「ＳＶ１．ＣＰＵ」の値の重回帰分析を行って、相関が高いとみなされたものを列挙する。
これにより、管理者は、「ＳＶ１．ＣＰＵ」の異常が「ＳＶ２．ＭＥＭ」よって引き起こされているといった可能性を考慮することができる。

この第４の関連技術では、ある異常と因果関係の可能性を提示することができるものの、それが正しいかどうかの検証は管理者が行わなければならない。また、検出された性能情報の値の相関は提示できるものの、将来発生しうる負荷に対してどの要素がボトルネックになるのかを導出することができない、という不具合があった。

以上述べたように、関連技術の運用管理装置では、実際の運用状況で発生するボトルネックを正確に予測できず、管理者の負担が大きく、情報収集や分析の処理負荷が大きいという不具合があった。
そこで、本実施の形態では、以下に示す特徴的構成を有する。

（本実施の形態の特徴的構成）
ここで、本発明の第１の実施の形態の運用管理装置の特徴的構成について、図５を参照しつつ説明する。図５は、本発明の第１の実施の形態の運用管理装置の特徴的構成の一例を示すブロック図である。

図５に示すように、本発明の第１の実施の形態の運用管理装置１００は、図２に示す運用管理装置３と同様の構成である、サービス実行部１２１、性能情報蓄積処理部１１２、情報収集部１２２、分析設定蓄積処理部１１４、障害分析部１２６、管理者対話部１２７、対処実行部１２８に加えて、相関モデル生成部１２３と、相関モデル情報蓄積処理部１１６と、モデル探索部１２４と、リソース情報蓄積処理部１１８と、ボトルネック解析部１２５と、を含んで構成される。

相関モデル生成部１２３は、性能情報蓄積処理部１１６から一定期間の性能情報を取り出し、任意の２つの性能情報の値の時系列に対して、一方を入力とし他方を出力とした場合の変換関数を導出するとともに、この変換関数で生成された性能値の系列と出力となる性能情報の実際の検出値の系列とを比較し、その値の差から前記変換関数の重み情報を算出する。さらに、これらの処理をすべての性能情報に対して繰り返すことで、サービス実行部１２１の全体的な稼動状態の相関モデルを生成する。

相関モデル蓄積処理部１１６は、相関モデル生成部１２３が生成した相関モデルを蓄積処理する。
モデル探索部１２４は、相関モデル蓄積処理部１１６に蓄積される相関モデルの各々の性能情報間の変換関数を順次辿ることで、１つの性能情報の値を仮定した場合に他の性能情報の値を算出する。また、１つの性能情報に対して複数の変換関数によって異なった値が算出された場合に、重み情報に基づいて１つの値を選択あるいは算出する。

リソース情報蓄積処理部１１８は、性能情報毎の性能値の最大値、最小値、単位といった属性を記述した情報であるリソース情報を蓄積する。

ボトルネック解析部１２５は、性能情報のうち予め指定された１つの入力性能情報の値を順次増加あるいは減少させながらモデル探索部１２４に指示する。
ボトルネック解析部１２５は、モデル探索部１２４が算出した他の性能情報の値を受け取って、リソース情報蓄積処理部１１８に蓄積されるリソース情報と比較する。
ボトルネック解析部１２５は、性能値がリソース情報に示す範囲を超える要素を検出する。
ボトルネック解析部１２５は、その性能情報とその時点の入力性能情報の値を含む解析結果を生成し、管理者対話部１２７に出力する。

ここで、これらの各部は、図６に示すように、制御部が発揮する複数の機能として構成することもできる。

また、相関モデル生成部１２３は、性能種目又は被管理装置を要素とした場合に、少なくとも第１の要素に関する性能情報の時系列変化を示す第１の性能系列情報と、第２の要素に関する性能情報の時系列変化を示す第２の性能系列情報との相関関数を導出し、この相関関数に基づいて相関モデルを生成し、この相関モデルを前記各要素間の組み合わせについて求めることができる。

さらに、モデル探索部１２４は、前記各要素間の前記各相関モデルを順次探索して最適な相関モデルを決定し、この決定された相関モデルに基づいて少なくとも前記第１の要素の性能情報から前記第２の要素の性能情報を予測することができる。

また、ボトルネック解析部１２５は、前記性能情報のとり得る範囲を規定したリソース情報に基づいて、前記モデル探索部にて予測された前記性能情報が前記範囲を超える要素、及びその要素に関する前記性能情報を含むボトルネック解析結果を生成することもできる。

さらに、相関モデル生成部１２３は、前記相関関数を用いて前記第１の要素に関する性能情報から算出された前記第２の要素に関する算出性能情報と、取得された前記第２の要素に関する性能情報との誤差に基づいて、前記相関モデルの重み情報を算出することができる。この場合、前記モデル探索部１２４は、少なくとも１つの前記要素に対して複数の前記相関関数によって異なる前記性能情報が算出され得る場合に、前記重み情報に基づいて一つの前記相関モデルを決定することができる。

また、前記相関モデル生成部１２３は、前記第１の要素と前記第２の要素との前記相関モデルの第１の重み情報と、前記第１の要素と前記第３の要素との前記相関モデルの第２の重み情報と、前記第３の要素と前記第２の要素との前記相関モデルの第３の重み情報とをそれぞれ算出することができる。この場合、前記モデル探索部１２４は、前記第２の重み情報と前記第３の重み情報との合成重みと、前記第１の重み情報とを比較して、前記相関モデルを決定することができる。

さらに、前記ボトルネック解析部１２５は、性能の前記範囲を超えた前記要素に関する性能情報とともに、他の前記要素に関する前記性能情報を利用率で順序付けして提示可能とすることができる。また、前記ボトルネック解析部１２５は、性能の前記範囲を超えた前記要素に関する性能情報と、前記範囲が算出された時点の入力となる前記性能情報とを含む結果を提示可能とすることができる。

（相関モデル生成について）
ここで、相関モデル生成部１２３による相関モデル生成の概要について、図７を参照して説明する。図７は、本実施の形態にかかる運用管理装置の相関関数生成の概要の一例を示す説明図である。

相関関数生成は、図１２に示す相関関数（変換関数）を生成するステップＳ１０３（相関関数生成機能）および誤差を算出するステップＳ１０４（重み情報算出機能）の処理により行うことができる。

図７に示すように、変換関数Ｇ３００は、グラフＧ１０１に示す「ＳＶ１．ＣＰＵ」の性能値の系列（第１の性能系列情報）を入力とした場合に、グラフＧ１０１に示す「ＳＶ１．ＭＥＭ」の性能値の系列（第２の性能系列情報）を出力するものである。
この変換関数Ｇ３００を、システム同定処理Ｇ３０１に示す処理によって算出する。
一例として、「ｙ＝Ａｘ＋Ｂ」の式で示される変換関数では、「Ａ＝−０．６」、「Ｂ＝１００」の値が算出される。
さらに、グラフＧ３０２で示すように、この変換関数でグラフＧ１０１から生成された性能値の予測値の系列と、グラフＧ１０２で示される実際の性能値の差分から重みｗが生成される。

図８は、本実施の形態にかかる運用管理装置の相関モデルの例である。相関モデル１１６ａは、変換関数の入力となる性能値の系列の名称と、出力となる性能値の系列の名称と、変換関数を特定する各々係数の値と、重み情報と、を含んで構成される。例えば、図７に示す変換関数を算出した結果として、「ＳＶ１．ＣＰＵ」を入力とし、「ＳＶ１．ＭＥＭ」を出力とし、「ｙ＝Ａｘ＋Ｂ」の式で示される変換関数は、係数Ａの値が「−０．６」、係数Ｂの値が「１００」、重みが「０．８８」となる相関関係が蓄積されている。

（モデル探索について）
続いて、モデル探索部１２４によるモデル探索の概要について、図９を参照して説明する。図９は、本実施の形態にかかる運用管理装置の重み情報を利用したモデル探索の概要の一例を示す説明図である。

重み情報を利用したモデル探索は、図１３に示す性能値を選択するステップＳ２０６により行うことができる。

相関グラフＧ３１０では、要素ｘ、ｙ、ｚの間の変換関数として、「ｙ＝２ｘ」、「ｚ＝２ｙ」、「ｚ＝３．９ｘ」があり、それぞれの重みｗが「０．７」、「０．９」、「０．８」である。重み比較処理８１１では、ｚの値を算出する場合に、「ｘ→ｙ→ｚ」と「ｘ→ｚ」の２つの経路のそれぞれの重み「０．６３」、「０．８」を比較し、値の大きい「ｘ→ｚ」の経路を選択する。この結果、「ｘ＝１０」の場合には、「ｚ＝３．９ｘ」の式を適用して、ｚの値「３９」を算出する。

（ボトルネック解析について）
さらに、ボトルネック解析部１２５によるボトルネック解析では、リソース情報に基づいて、モデル探索部１２４にて予測された性能情報が限界を超えたか否かの判定が行われる。
図１０は、本実施の形態にかかる運用管理装置のリソース情報の一例である。リソース情報１１８ａは、システムの性能情報の要素の名称と、性能値の単位と、性能値の最小値と、性能値の最大値と、を含んで構成される。

そして、ボトルネック解析部１２５では、解析結果を表示部にて表示することができる。
図１５は、運用管理装置の表示部に表示される表示画面の一例が示されている。同図では、ボトルネック解析における表示画面の一例が示されている。
表示画面Ｕ１００は、図１５に示すように、ボトルネック解析の結果として、システムへの入力が「６００／ｓｅｃ」の値である場合に、要素「ＳＶ２．ＣＰＵ」の性能が限界値を超えることを提示する。
また、その時点での要素の一覧を、利用率の大きい順に一覧表示される。
さらに、一覧表示で選択された「ＳＶ２．ＣＰＵ」の性能値とシステムへの入力の値との関係を示すグラフとして、変換関数で表現される予測線と検出された性能値を示す点が表示される。

また、表示部に表示される表示画面Ｕ１００（ボトルネック解析画面）は、ボトルネック解析結果を表示する解析結果表示部Ｕ１１０を有する。解析結果表示部Ｕ１１０は、利用率が最も高い要素（性能種目と装置名を識別する略文字又は記号）、その要素の利用率、入力性能値、などを表示することができる。
さらに、表示画面Ｕ１００は、利用率の高い要素を順にリストアップした要素リスト表示部Ｕ１２０を有する。要素リスト表示部Ｕ１２０は、要素（性能種目）、その要素の利用率、その他の情報などを表示することができる。
さらに、表示画面Ｕ１００は、要素リスト表示部Ｕ１２０の要素リストのうち、選択された要素に関するグラフを表示するグラフ表示部Ｕ１３０を有する。グラフ表示部Ｕ１３０は、性能値と入力の値との関係を示すグラフを表示することができる。グラフ表示部Ｕ１３０は、変換関数で表現される予測線、検出された性能値を示す点、１００％のライン、などを表示することができる。
またさらに、表示画面Ｕ１００は、相関モデルの詳細情報を表示するための第１の表示操作部Ｕ１４２を有する。表示画面Ｕ１００は、リソース情報の詳細情報を表示するための第２の表示操作部Ｕ１４４を有する。表示画面Ｕ１００は、ボトルネック解析画面の表示を終了するための第３の表示操作部Ｕ１４６を有する。
管理者は、このようなユーザーインタフェースを利用して、ボトルネックがどこにあるのかを正確に解析できる。

（処理手順について）
（全体処理）
次に、上述のような構成を有する運用管理装置における各部の処理は、方法としても実現可能であり、情報処理方法としての各種の処理手順について、図１１乃至図１４を参照しつつ説明する。
図１１は、本発明の第１の実施の形態による運用管理装置における処理手順の一例を示すフローチャートである。

本実施の形態に係る情報処理方法は、システムを構成する複数の被管理装置から取得される複数種の性能種目毎の性能情報に基づいて、前記被管理装置を運用管理する制御する情報処理を（例えば１又は複数のコンピュータやその他の装置など）が行うものを対象とするものである。

この情報処理方法は、基本的構成として、前記性能種目又は前記被管理装置を要素とした場合に、少なくとも第１の要素に関する性能情報の時系列変化を示す第１の性能系列情報と、第２の要素に関する性能情報の時系列変化を示す第２の性能系列情報との相関関数を導出し、この相関関数に基づいて相関モデルを生成し、この相関モデルを前記各要素間の組み合わせについて求める相関モデル生成ステップ（例えば図１１に示すステップＳ１１など）と、前記各要素間の前記各相関モデルを順次探索して最適な相関モデルを決定し、この決定された相関モデルに基づいて少なくとも前記第１の要素の性能情報から前記第２の要素の性能情報を予測するモデル探索ステップ（例えば図１１に示すステップＳ１２など）と、含むことができる。

さらに、この情報処理方法では、前記性能情報のとり得る範囲を規定したリソース情報に基づいて、前記モデル探索ステップにて予測された前記性能情報が前記範囲を超える要素、及びその要素に関する前記性能情報を含むボトルネック解析結果を生成するボトルネック解析ステップ（例えば図１１に示すステップＳ１３など）を含むことができる。

以下、これらの「相関モデル生成」、「モデル探索」、「ボトルネック解析」の詳細処理について説明する。

（相関モデル生成の詳細処理）
図１２は、本発明の第１の実施の形態による運用管理装置における相関モデル生成の詳細処理手順の一例を示すフローチャートである。

本実施の形態における相関モデル生成の詳細処理では、まず、情報収集部１２２によってサービス実行部１２１の動作状態が収集され、性能情報蓄積処理部１２２に図３に示す性能情報１２ａが蓄積される。
ここで、相関モデル生成部１２３は、性能情報蓄積処理部１１２から性能情報１２ａを読み込む（図１２に示すステップＳ１０１）。

次に、未分析の性能情報の有無を判定する（ステップＳ１０２）。
相関モデルが生成されていない状態では、未分析の性能情報があるため、性能情報間の変換関数を算出する処理（ステップＳ１０３）に移る。

最初に、性能情報１２ａの「ＳＶ１．ＣＰＵ」の性能値の系列と「ＳＶ１．ＭＥＭ」の性能値の系列の変換関数を算出する。
図７を参照すると、「ＳＶ１．ＣＰＵ」を入力ｘとし、「ＳＶ２．ＭＥＭ」を出力ｙとする変換関数Ｇ３００を、システム同定処理Ｇ３０１によって決定することになる。

一般的に、このようなシステム同定にはいくつかの手法があり、例えば、「ｙ＝Ａｘ（ｔ）＋Ｂｘ（ｔ−１）＋Ｃｘ（ｔ−２）＋Ｄｙ（ｔ−１）＋Ｅｙ（ｔ−２）＋Ｆ」といった式を用いて、ｘから算出したｙの時系列の値が実際に検出された値に最も近くなるように、変数Ａ〜Ｆの値を決定することで変換関数が算出できる。
以下では、説明を簡略化するために、式「ｙ＝Ａｘ＋Ｂ」のＡとＢを決定する形で説明するが、その例に限定されるものではなく、他のシステム同定手法を用いても１つの性能値の系列から他の性能値の系列が算出できる変換関数であれば同様の効果が得られるものである。

図７のシステム同定処理Ｇ３０１を参照すると、関数として「ｙ＝Ａｘ＋Ｂ」を選択し、グラフＧ１０１からグラフＧ１０２を近似できるＡとＢの値として、それぞれ「−０．６」、「１００」を決定する（図１２に示すステップＳ１０３）。

さらに、グラフＧ３０２に示すように、グラフＧ１０１をこの変換関数で算出した予測値の系列と、グラフＧ１０２の性能値の系列を比較して、その差分である変換誤差から、この変換関数の重み情報を算出する（図１２に示すステップＳ１０４）＜重み情報算出ステップないしは重み情報算出機能＞。

この後、算出された変換関数と重み情報を相関モデルに追加する（ステップＳ１０５）。
図８は、このようにして追加された相関モデルの例であり、「ＳＶ１．ＣＰＵ」と「ＳＶ２．ＭＥＭ」の相関として、Ａ、Ｂ、Ｗの値が蓄積されている。
以降、同様にして、ステップＳ１０３からステップＳ１０５の処理を、性能情報１２ａに含まれる性能値の系列のすべての組合せに対して行うことで、相関モデル蓄積処理部１１６に現在のシステムの性能情報に関する相関モデルが完成する。

（モデル探索の詳細処理）
次に、本実施の形態におけるモデル探索の詳細処理について、図５、図１３、図９を参照して説明する。図１３は、本実施の形態にかかる運用管理装置のモデル探索の詳細処理手順の一例を示すフローチャートである。

モデル探索部１２４は、ボトルネック解析部１２５から性能情報の１つの要素の値を受け取るとともに（ステップＳ２０１）、相関モデル蓄積処理部１１６から相関モデルを読み込む（ステップＳ２０２）。

最初に、値が全く算出されていない状態では未探索の相関があるので、未探索の相関の有無を判定する（ステップＳ２０３）。
そして、運用管理装置が備えたコンピュータ（のモデル探索部１２４）が、未探索の相関があると判定した場合には、受け取った１つの要素の値から他の要素の性能値を算出し、その算出に用いた変換関数の重みを記録する（ステップＳ２０４）。

続いて、算出済みの性能値の有無を判定する（ステップＳ２０５）。最初の算出では、算出済みの性能値がないので、算出済みの性能値がないと判定される。算出済みの性能値がないと判定された場合には、ステップＳ２０３に戻る。

そして、再度、未探索の相関を探索する（ステップＳ２０３）。
最初に受け取った性能値は決定しているので、それ以外の性能値の１つを選択し、他の性能値を算出する。
同様に、出力となる性能値と重みを算出する（ステップＳ２０４）。この場合、前回算出済みの性能値があるので、ステップＳ２０５の判定処理では、性能値があると判定される。
そして、前回の算出値と、今回の算出値の重み情報を比較し、重みに応じて性能値を選択する処理を行う（Ｓ２０６）。

より具体的には、図９に示すように、前回ｘからｙおよびｚを算出したとすると、ｙの算出値は、「ｙ＝２ｘ」の変換関数が持つ「０．７」という重み情報を持つ。同様に、ｚの算出値は、「ｚ＝３．９ｙ」の変換関数が持つ「０．８」という重み情報を持つ。ここで、今回ｙからｚを算出する場合は、ｙの値の持つ「０．７」という重み情報に、「ｚ＝２ｙ」という変換関数の持つ「０．９」を乗算して「０．６３」という重み情報を得る。この値と、既に前回予測された値の重み情報「０．８」を比較すると、前回の方が値が大きいので、前回の値を予測値として選択し（ステップＳ２０６）、ステップＳ２０３に戻る。

このようにして、性能情報の各々の要素を複数の経路から算出し、その重みの大きいものを選択することで、最終的に、複数の経路の中で正確に予測できる変換関数の組合せで算出された値を選択することができる。

（ボトルネック解析の詳細処理）
次に、本実施の形態におけるボトルネック解析の詳細処理について、図５、図１４、図１０、図１５を参照しつつ説明する。図１４は、本実施の形態にかかる運用管理装置のボトルネック解析動作のフローチャートを示す。

先ず、図１４に示すように、運用管理装置が備えたコンピュータ（のボトルネック解析部１２５）は、システムの入力となる要素の性能値を決定する（ステップＳ３０１）。
入力となる要素は、例えば、ＷＥＢ、ＡＰ、ＤＢで構成される３Ｔｉｅｒのシステムであれば、ＷＥＢサーバへの入力トラフィック等が挙げられる。性能値としては、例えば、現在検出されている最大値等が挙げられる。

次に、ボトルネック解析部１２５は、決定した性能値をモデル探索部１２４に渡して、モデル探索を行う（ステップＳ３０２）。
モデル探索では、与えられた性能値から、相関モデルを探索して他の性能値を算出する。
この後、ボトルネック解析部１２５は、この算出された性能値を受け取り、リソース情報蓄積処理部１１８に蓄積されるリソース情報１１８ａと比較して、性能情報に含まれる要素の利用率を算出する（ステップＳ３０３）。

例えば、「ＳＶ１．ＣＰＵ」の現在の値を与えてモデル探索を行った場合、算出された「ＳＶ２．ＣＰＵ」の値と、図１０のリソース情報１１８ａに含まれる「ＳＶ２．ＣＰＵ」の最小値、最大値と比較を行う。

そして、運用管理装置が備えたコンピュータ（のボトルネック解析部１２５）は、性能容量が不足しているか否かを判定する（ステップＳ３０４）。
ステップＳ３０４にて、性能容量が不足していると判定した場合には、運用管理装置が備えたコンピュータ（のボトルネック解析部１２５）は、管理者に解析結果を提示する（ステップＳ３０６）。

一方、ステップＳ３０４にて、性能容量が不足していないと判定した場合には、運用管理装置が備えたコンピュータ（のボトルネック解析部１２５）は、入力となる要素の性能値を順次増加させ（ステップＳ３０５）、ステップＳ２０３以降の処理を繰り返す。

例えば、ステップＳ３０４において、「ＳＶ２．ＣＰＵ」の算出値が、リソース情報１１８ａに規定されている最小値と最大値の範囲内であれば、性能容量は不足していないと判定し、「ＳＶ１．ＣＰＵ」の値を一定量増加させて（ステップＳ３０５）、モデル探索を再度実施する。

同様にして、入力となる要素の性能値を順次増加させながらモデル探索を行い、算出された性能値のいずれかがリソース情報１１８ａで規定されている範囲を超えた場合、性能容量が不足していると判断し、管理者に解析結果を提示する（ステップＳ３０６）。

図１５は、管理者に提示するボトルネック解析の結果の画面であり、表示画面Ｕ１００では、性能容量が不足した要素「ＳＶ２．ＣＰＵ」とその時点の入力となる性能値「６００／ｓｅｃ」を含む情報が提示される。
これにより、管理者は、現状のサービス実行部１２１は、入力性能値が「６００／ｓｅｃ」以上になる状況に耐えられないことがわかり、それ以上の負荷が予想される場合は、「ＳＶ２」の処理能力が向上するように設定変更や設備増強を行わなければならないことがわかる。

ここで、前記相関モデル生成ステップでは、前記相関関数を用いて前記第１の要素に関する性能情報から算出された前記第２の要素に関する算出性能情報と、取得された前記第２の要素に関する性能情報との誤差に基づいて、前記相関モデルの重み情報を算出することができる。この場合、前記モデル探索ステップでは、少なくとも１つの前記要素に対して複数の前記相関関数によって異なる前記性能情報が算出され得る場合に、前記重み情報に基づいて一つの前記相関モデルを決定することができる。

さらに、前記ボトルネック解析ステップでは、性能の前記範囲を超えた前記要素に関する性能情報とともに、他の前記要素に関する前記性能情報を利用率で順序付けすることができる。

また、前記ボトルネック解析ステップでは、前記ボトルネック解析結果として、性能の前記範囲を超えた前記要素に関する性能情報と、前記範囲が算出された時点の入力となる前記性能情報とを含む結果を提示する処理を行うことができる。

前記相関モデル生成ステップでは、前記第１の要素と前記第２の要素との前記相関モデルの第１の重み情報と、前記第１の要素と前記第３の要素との前記相関モデルの第２の重み情報と、前記第３の要素と前記第２の要素との前記相関モデルの第３の重み情報とをそれぞれ算出することができる。この場合に、前記モデル探索ステップでは、前記第２の重み情報と前記第３の重み情報との合成重みと、前記第１の重み情報とを比較して、前記相関モデルを決定することができる。

以上のように本実施の形態によれば、相関モデル生成部が、各々の要素の性能情報間の変換関数を用いてシステムの全体的な稼動状態の相関モデルを生成する。モデル探索部が、この相関モデル内の変換関数を順次辿ることで、１つの要素の性能情報の値を仮定した場合に他の要素の性能情報の値を算出する。さらに、ボトルネック解析部が、１つの入力性能情報の値を順次増加あるいは減少させながらモデル探索部が算出した性能値が限界を超える要素を検出してその性能情報とその時点の入力性能情報の値を含む解析結果を生成する。

これにより、検出された性能情報から自動的に性能情報の相関モデルを生成してボトルネック解析を行うことで、サービス実行部１２１のボトルネックを網羅的に解析することができる。また、実際の運用で検出された性能情報の相関関係に基づいて、相関モデル内の複数の経路を用いてより正確な性能値の算出が行えるため、解析結果の検証を管理者の経験に頼る必要がない。さらに、生成する相関モデルが各々の性能情報間を１対１で変換する変換関数で構成されるため、１つの性能情報から他の性能情報を容易に導出でき、システムが大規模化しても処理量が膨大になることがない。

また、ボトルネック解析の結果として、性能の限界を超えた性能情報と、その時点の入力を提示する。このように、システムの最大性能の値と、その時にどこがボトルネックになるかという情報を合わせて提示することで、システムのどの部分の性能に注意が必要かを明確に管理者に提示できるとともに、想定される将来負荷に対してシステムのどの要素をどう増強すれば良いかを明確にできる。

このように、本実施の形態では、管理者の経験と勘に頼って部分的あるいは不確かな解析しか実現できなかった関連技術に対して、管理者の能力に頼ることなく自動的に、負荷を増大させることなくシステム全体に渡って網羅的に、実稼働状況に基づき正確に、ボトルネック解析を実現することができる、という顕著な効果がある。

また、本実施の形態では、重み情報によって性能値を選択する形で説明したが、これに限定されるものではなく、重み情報に基づいて複数の算出値に一定の演算をかけて性能値を算出してもよい。また、性能値の算出を行ってから重み情報で選択する形で説明したが、これに限定されるものでははく、予め重み情報に基づいて相関モデルの経路を枝刈りして探索してもよい。異なる手順であっても、１つの性能値からモデルを探索して他の性能値を算出できるものであれば、同様の効果が得られるものである。

さらに、関連技術では、１つの性能情報の時間変化関数としてモデルを生成し、時間が経過した場合の、その性能情報の予測値が算出できる。また、関連技術にも２つの性能情報の間の「相関係数」が用いられているが、相関係数は「値」であって「変換関数」ではないので、値の予測（ボトルネック解析）には使えない。一方の値が判明したら他方が算出できるものでないので、異常検知の支援はできても、ボトルネック解析を実現できない。
これに対して本実施の形態では、２つの性能情報の間の変換関数としてモデルを生成し、１つの性能情報の値が増えた場合の、他の要素の性能値を算出でき、システムを構成する各要素について全体としての正確な性能情報の予測を行うことができ、正確なボトルネックの要素の解析を行うことができる。

このように、検出された性能情報から自動的に性能情報の相関モデルを生成してボトルネック解析を行うことで、テスト時に想定できていなかった状況も含めて、稼動時の状況に合わせたボトルネックを解析することができる。また、予め想定される特定の処理に関係するものだけでなく、サービス実行部全体の挙動を網羅的に解析することができる。

さらに、実際の運用で検出された性能情報の相関関係に基づいて、将来対象システムで発生する可能性の高いボトルネックが抽出できるため、解析結果の検証を管理者の経験に頼る必要がない。さらにまた、生成する相関モデルが各々の性能情報間を１対１で変換する変換関数で構成されるため、１つの性能情報から他の性能情報を容易に導出でき、システムが大規模化しても処理量が膨大になることなくボトルネックを解析できる。

このように、本発明は、検出した性能情報の相関関係を適切に抽出してモデル化することで、実際の運用状況で発生するボトルネックを正確に予測できるとともに、管理者の負担が少なく、大規模環境においても分析に必要となる処理負荷を増大させないボトルネック解析を実現できる。

また、相関モデル生成部が、変換関数毎の正確さを示す重み情報を生成し、モデル探索部が、１つの性能情報に対して複数の変換関数によって異なった値が算出された場合に、重み情報に基づいて１つの値を算出する。これにより、相関モデル内の複数の経路を用いてより正確な性能値の算出が行えるため、第２の課題を解決し、より正確にボトルネックを解析できるという効果がある。

またさらに、管理者対話部が、ボトルネック解析部の解析結果として、性能の限界を超えた性能情報と、その時点の入力を提示する。このように、システムの最大性能の値と、その時にどこがボトルネックになるかという情報を合わせて提示することで、想定される将来負荷に対して、システムのどの要素をどう増強すれば良いかを明確にできる。

さらに、管理者対話部が、性能の限界を超えた性能情報とともに、その他の性能情報を性能の利用率で順序付けして提示する。これにより、他の性能情報も含めて、システムのどの部分の性能に注意が必要かを明確に管理者に提示することができる。

ここで、図５に示すブロック図における一部の各ブロック（例えば符号１２３、１２４、１２５、１２１、１２２、１２６、１２７、１２８等）は、コンピュータが適宜なメモリに格納された各種プログラムを実行することにより、該プログラムにより機能化された状態を示すソフトウエアモジュール構成であってもよい。

すなわち、物理的構成は例えば一又は複数のＣＰＵ（或いは一又は複数のＣＰＵと一又は複数のメモリ）等ではあるが、各部（回路・手段）によるソフトウエア構成は、プログラムの制御によってＣＰＵが発揮する複数の機能を、それぞれ複数の部（手段）による構成要素として表現したものである。

ＣＰＵがプログラムによって実行されている動的状態（プログラムを構成する各手順を実行している状態）を機能表現した場合、ＣＰＵ内に各部（手段）が構成されることになる。プログラムが実行されていない静的状態にあっては、各手段の構成を実現するプログラム全体（或いは各手段の構成に含まれるプログラム各部）は、メモリなどの記憶領域に記憶されている。

以上に示した各部（手段）の説明は、プログラムにより機能化されたコンピュータをプログラムの機能と共に説明したものと解釈することも出来るし、また、固有のハードウエアにより恒久的に機能化された複数の電子回路ブロックからなる装置を説明したものとも解釈することが出来ることは、当然である。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現でき、いずれかに限定されるものではない。

また、各部は、通信可能な専用のコンピュータからなる装置としてそれぞれ構成し、これらの各装置により運用管理システムを構成してもよい。

［第２の実施の形態］
次に、本発明にかかる第２の実施の形態について、図１６、図１７、図１８、図１９、図２０、図２１に基づいて説明する。以下には、前記第１の実施の形態の実質的に同様の構成に関しては説明を省略し、異なる部分についてのみ述べる。図１６は、本発明の運用管理装置の第２の実施の形態の一例を示すブロック図である。

本実施の形態における構成は、第１の実施の形態の図５を用いて説明した構成に加えて、総計性能値管理部２３１を含む構成としている。
具体的には、本実施の形態の運用管理装置２００は、図１６に示すように、前記第１の実施の形態の構成である、サービス実行部２２１、性能情報蓄積処理部２１２、情報収集部２２２、分析設定蓄積処理部２１４、障害分析部２２６、管理者対話部２２７、対処実行部２２８、相関モデル生成部２２３、相関モデル情報蓄積処理部２１６、モデル探索部２２４、リソース情報蓄積処理部２１８、ボトルネック解析部２２５に加えて、総計性能値管理部２３１と、を含んで構成される。

リソース情報蓄積処理部２１８は、図５で説明した情報に加えて、複数の性能情報から算出される総計性能情報とその算出の対象となる複数の性能情報の組み合わせを指定するグループ情報を蓄積する。

総計性能値管理部２３１は、リソース情報蓄積処理部２１８からグループ情報を受け取り、相関モデル生成部２２３に対して総計性能情報の生成を指示する。また、総計性能値管理部２３１は、モデル探索部２２４に対して総計性能情報の値の更新を指示する。

相関モデル生成部２２３は、第１の実施の形態の機能に加えて、総計性能値管理部２３１の指示に従って、検出された複数の性能情報の同時刻の値に一定の算術演算を行って算出した値の時系列を性能値とする総計性能情報を生成し、性能情報にこの総計性能情報を加えて相関モデルを生成する。

モデル探索部２２４は、第１の実施の形態の機能に加えて、性能情報の値を算出する場合に、総計性能値管理部２３１からの指示に従って総計性能情報の値を再計算する（総計性能情報再計算機能）。

ここで、これらの各部は、図１７に示すように、制御部が発揮する複数の機能として構成することもできる。

また、統計性能値管理部２３１は、前記要素をグループ化し、各要素の統計性能値を生成することができる。この場合、前記相関モデル生成部２２３は、前記統計性能値によるグループ要素を新要素として加え、一の前記新要素と他の前記新要素との相関から相関モデルを生成することができる。

このような構成からなる運用管理装置２００において、総計性能値を用いた相関モデル生成の概要について説明する。図１８は、本実施の形態にかかる運用管理装置の総計性能値を用いた相関モデル生成の概要の一例を示す説明図である。

図１８に示すように、構成グラフＧ３２０は、ＷＥＢ層、ＡＰ層、ＤＢ層の３層からなる負荷分散システムの構成を示し、ＷＥＢ層が３台のサーバで負荷分散され、ＡＰ層が２台のサーバで負荷分散される。性能情報の要素Ａ〜Ｃは、ＷＥＢ層の各サーバの性能を示し、同様に、要素Ｄ〜ＥはＡＰ層、要素ＦはＤＢ層の性能を示す。

相関グラフＧ３２１では、第１の実施の形態で説明した動作で相関モデルを生成した場合の結果の一例を示す。同じ処理を分散して実行する各層では正確な相関関係が生成でき、層間では有意な相関関係ができなかった例である。

相関グラフＧ３２２は、本実施の形態の総計性能値を用いて相関モデルを生成した場合の一例を示す。ＷＥＢ層の性能値の合計の値を持つ総計性能情報Ｘ、ＡＰ層の性能値の合計の値を持つ総計性能情報Ｙをそれぞれ生成している。これにより、層間に正確な相関関係を生成できる。

このように、総計性能値を用いることで、各層間を相関させることができる。

次に、総計性能情報を蓄積するためのリソース情報蓄積処理部２１８のリソース情報１１８ｂのデータ構造について説明する。図１９は、本実施の形態にかかる運用管理装置のリソース情報のデータ構造の一例を示す。
リソース情報１１８ｂは、図１０に示すリソース情報１１８ａの情報に加えて、「グループ」という新たな属性が追加されている。
総計性能情報Ｘ、総計性能情報Ｙでは、グループ情報として総計性能値の算出に必要な性能情報の要素が列挙されている。

例えば、総計性能情報Ｘでは、図１８の構成グラフＧ３２０に示すＷＥＢ層の性能情報の要素Ａ、Ｂ、Ｃをグループ情報として持つ。また、総計性能情報Ｙでは、図１８の構成グラフＧ３２０に示すＡＰ層の性能情報の要素Ｄ、Ｅをグループ情報として持つ。総計性能情報以外の性能情報の要素では、グループ情報には何も記述されていない。
リソース情報１１８ａのテーブルにグループ情報の項目を設けることで、各要素の性能値をグループ化して、総計性能情報を管理することができる。

（処理手順について）
次に、上述のような構成を有する運用管理装置における各部の処理は、方法としても実現可能であり、運用管理方法としての各種の処理手順について、図２０乃至図２１を参照しつつ説明する。

（相関モデル生成の詳細処理）
図２０は、本実施の形態にかかる運用管理装置の相関モデル生成の詳細処理手順の一例を示すフローチャートである。
図２０では、第１の実施の形態で図１２を用いて説明したステップＳ１０１〜Ｓ１０５と同様のステップであるステップＳ４０１〜Ｓ４０５に加えて、総計性能情報を生成するステップＳ４０６が追加されている。

本実施の形態における相関モデル生成の詳細処理は、第１の実施の形態で説明したものと同様であり、性能情報を読み込むステップＳ４０１に続いて、総計性能情報を生成するステップＳ４０２を行う点が異なる。

図２０を参照すると、相関モデル生成部２２３は、性能情報蓄積処理部２１２から性能情報を読み込むとともに（ステップ４０１）、総計性能値管理部２３１の指示に従って総計性能情報を生成する（ステップ４０２）。

この場合、総計性能値管理部２３１は、リソース情報蓄積処理部２１８からリソース情報１１８ｂを読み込み、グループ情報が指定されている総計性能情報Ｘと総計性能情報Ｙを探索し、この総計性能情報Ｘと総計性能情報Ｙを生成することを相関モデル生成部２２３に指示する。
相関モデル生成部２２３は、この指示に従って、性能情報の要素Ａ、Ｂ、Ｃの同時刻の性能値を加算して総計性能情報Ｘの性能値の時系列を生成する。
同様に、性能情報の要素Ｄ、Ｅから総計性能情報Ｙの時系列を生成する。

以降、性能情報蓄積処理部２１２に蓄積されている他の性能情報にこの総計性能情報Ｘ、総計性能情報Ｙを加えて相関モデルの生成を行う。第１の実施の形態で説明した通り、未分析性能情報がなくなるまで（ステップ４０３）、変換関数の生成（ステップ４０４）、重みの算出（ステップ４０５）、相関モデルの追加（ステップ４０６）を繰り返す。

図１８は、このようにして生成される相関モデルの一例を示す。
構成グラフＧ３２０は、図１８に示すように、ＷＥＢ、ＡＰ、ＤＢの３層構成で、それぞれのサーバが３台、２台、１台で構成されるシステムである。
各サーバの性能情報の相関関係をモデル化した場合、相関グラフＧ３２１に示すように、各層の間の相関関係は、適切に生成できない場合がある。あるいは、各層の間の相関関係は生成できるが、極めて誤差の大きい場合がある。

例えば、ＤＢ層の処理負荷は、性能情報の要素Ｆのみに現れるが、ＡＰ層の処理負荷は、２台のサーバで分散して行われるため、要素Ｄ、Ｅで分散して現れる。
ここで、要素Ｄと要素Ｆの相関関係を考えると、要素Ｆの性能値は、要素Ｄと要素Ｅの両方の性能値の和に依存する。要素Ｄと要素Ｅが全く均等に処理を分散している場合には、要素Ｄの性能値の２倍が要素Ｆと相関することになるが、処理に偏りがあった場合、要素Ｄの性能値だけからは要素Ｆの性能値が正確に特定できない。
同様に、要素Ｅと要素Ｆの間の相関も希薄となる。同じ問題がＷＥＢ層とＡＰ層の間にも発生し、要素Ａ、Ｂ、Ｃから要素Ｄ、Ｅへの相関は希薄となる。この結果、相関グラフ８２１に示すような部分的な相関関係しか抽出できない状態が発生する。

一般的には、このような不具合を解決するために、要素の１対１の変換関数ではなく、Ｎ対１の変換関数を用いて相関モデルを生成することが考えられる。しかし、性能情報の要素の数が増えると膨大な計算資源が必要となる。加えて、入力がＮ個、出力が１個の変換関数では、ある１つの性能値を算出するためには、Ｎ個の入力が確定していなければならず、システムの１つの入力負荷が増えた場合にどこがボトルネックになるかというような解析を行うことが困難になってしまう。

そこで、本実施の形態における総計性能情報を用いた相関モデル生成の場合、相関グラフＧ３２２に示すように、実際に検出される要素Ａ〜Ｆに加えて要素Ｘ、Ｙが生成される。要素Ｙは、ＡＰ層の要素Ｄ、Ｅの性能値の総和であり、要素Ｙによって、ＡＰ層のサーバが１台であるかのように扱うことができる。
この結果、ＡＰ層全体の処理負荷を示す要素Ｙと、ＤＢ層全体の処理負荷を示す要素Ｆには明確な相関関係ができる。同様にして、ＷＥＢ層全体を示す要素ＸとＡＰ層全体を示す要素Ｙにも相関関係ができる。

（モデル探索の詳細処理）
図２１は、本実施の形態にかかる運用管理装置のモデル探索の詳細処理手順の一例を示すフローチャートである。
図２１では、第１の実施の形態で図１３を用いて説明したステップＳ２０１〜Ｓ２０６と同様のステップであるステップＳ５０１〜Ｓ５０６に加えて、グループ指定を判定するステップＳ５０７と総計性能情報を再計算するステップＳ４０８が追加されている。

図２１を参照すると、本実施の形態におけるモデル探索の動作は、第１の実施の形態で説明したものと同様であり、性能値を決定するステップＳ５０６の後に、決定した性能値が総計性能情報に使われているかを判定するステップＳ５０７と、総計性能情報を再計算するステップＳ５０８が追加されている点が異なる。

モデル探索部２２４は、ある入力性能値に対する他の性能値を算出するために、総計性能情報を含む相関モデルを読み込んで探索を行う（ステップＳ５０１〜ステップＳ５０６）。また、総計性能値管理部２３１の指示に従って、総計性能情報の算出に用いられる性能値を算出した場合に（ステップＳ５０７）、新しい性能値で総計性能情報を再計算する（ステップＳ５０８）。

さらに、ボトルネック解析部２２５が、このようなモデル探索による性能値の算出を繰り返すことで、システムの最大性能とボトルネック要素を特定する。
図１９を参照すると、リソース情報１１８ｂには、ボトルネック解析部２２５が総計性能情報の利用率を判定するための属性が記述されている。
例えば、総計性能情報Ｘは、最大値が１００％である要素Ａ、Ｂ、Ｃの３個の値の総和であるため、最大値が３００％となっている。また、総計性能情報Ｙでは、最大値が１０００Ｍｂｐｓの要素Ｄ、Ｅの２個の総和であるが、ネットワークの帯域は、足し算にはならない場合があるため、最大値が１０００Ｍｂｐｓとなっている。このようなリソース情報３０２を元に、どの要素がボトルネックになるかを解析できる。

ここで、例えば、図１８の要素Ａの負荷が増加すると予想すると、同じＷＥＢ層での相関関係から、要素Ａ、Ｂ、Ｃの間の負荷が算出でき、これらの総和から要素Ｘの値が算出できる。また、要素Ｘから要素Ｙ、要素Ｆの性能値が算出できる。
さらに、要素Ｙの算出値から、グループである要素Ｄ、Ｅの性能値も算出できる。
この結果、要素Ａの負荷が増加する場合に、ＤＢサーバである要素Ｆにどのような負荷がかかるかを正確に算出することができる。

また、前記相関モデル生成ステップでは、前記要素をグループ化して各要素の統計性能値を生成し、前記統計性能値によるグループ要素を新要素として加え、一の前記新要素と他の前記新要素との相関から相関モデルを生成することができる。

以上のように本実施の形態によれば、前記第１の実施の形態と同様の作用効果を奏しながらも、相関モデル生成部が、総計性能値管理部２３１の指示に従って、検出された複数の性能情報に一定の算術演算を行って算出した総計性能情報を含んだ相関モデルを生成し、モデル探索部１０が、この総計性能情報を含めて性能情報の値を算出する。

これにより、例えば、負荷分散処理といったように、１つの性能情報が複数の性能情報の値の総和と関係する場合にも、処理量を増大させること無く正確なボトルネック解析が可能となる。このように、本実施の形態にかかる発明には、第１の実施の形態の効果に加えて、膨大な処理負荷が必要となる従来技術に対して、処理負荷の増加を総計性能情報の数の増加分だけに押さえた上で、複数の要素との相関関係にも対応し、より正確にボトルネック解析を実現することができるという顕著な効果がある。

また、本実施の形態では、総計性能値の演算を、各要素の性能値の和で行う形で説明したが、これに限定されるものではなく、各要素の性能値に一定の演算をかけて総計性能値を算出してもよい。

また、総計性能値管理部が、相関モデル生成部とモデル探索部に指示する形で説明したが、これに限定されるものではなく、性能情報蓄積処理部に直接総計性能値を書き込むものや、相関モデルにグループの依存関係を示す属性を加えて探索を行うものであってもよい。異なる形であっても、検出された性能情報に一定の演算を加えた新たな性能情報を生成し探索することができるものであれば、同様の効果が得られるものである。

このように、相関モデル生成部が、総計性能値管理部の指示に従って、検出された複数の性能情報に一定の算術演算を行って算出した総計性能情報を含んだ相関モデルを生成し、モデル探索部が、この総計性能情報を含めて性能情報の値を算出する。これにより、例えば、負荷分散処理といったように、１つの性能情報が複数の性能情報の値の総和と関係する場合にも、処理量を増大させること無く正確なボトルネック解析が可能であり、第４の課題を解決し、負荷を抑えて正確な解析が行えるという効果がある。

その他の構成およびその他のステップないしは機能並びにその作用効果については、前述した実施の形態の場合と同一となっている。また、上記の説明において、上述した各ステップの動作内容及び各部の構成要素並びにそれらによる各機能をプログラム化し、コンピュータに実行させてもよい。

［第３の実施の形態］
次に、本発明にかかる第３の実施の形態について、図２２に基づいて説明する。以下には、前記第１の実施の形態の実質的に同様の構成に関しては説明を省略し、異なる部分についてのみ述べる。図２２は、本発明の運用管理装置の第３の実施の形態の一例を示すブロック図である。

本発明の第３の実施の形態の運用管理装置は、第２の実施の形態で図１３を用いて説明した構成に加えて、分析設定生成部を含む構成としている。

具体的には、本実施の形態の運用管理装置３００は、図２２に示すように、前記第２の実施の形態の構成である、サービス実行部３２１、性能情報蓄積処理部３１２、情報収集部３２２、分析設定蓄積処理部３１４、障害分析部３２６、管理者対話部３２７、対処実行部３２８、相関モデル生成部３２３、相関モデル情報蓄積処理部３１６、モデル探索部３２４、リソース情報蓄積処理部３１８、ボトルネック解析部３２５、総計性能値管理部３３１に加えて、分析設定生成部３３２を含んで構成される。

分析設定生成部３３２は、ボトルネック解析部３２５の解析結果を受け取り、ボトルネックとなることが予想される性能情報を、障害分析部３２６で監視および分析するための追加設定を生成し、この追加設定に従って分析設定蓄積処理部３１４に蓄積される分析設定を修正する。

ボトルネック解析部３２５は、管理者対話部３２７から管理者の入力を受け取って、分析設定生成部３３２に設定情報の修正を指示することができる。

ここで、ここで、これらの各部は、図２３に示すように、制御部が発揮する複数の機能として構成することもできる。

また、分析設定生成部３３２は、前記ボトルネック解析部にて解析された前記要素について障害分析の監視対象として監視設定を行うことができる。

（処理手順について）
次に、上述のような構成を有する運用管理装置における各部の処理は、方法としても実現可能であり、情報処理方法としての各種の処理手順について、図２４乃至図２６を参照しつつ説明する。図２４は、本発明の第３の実施の形態による運用管理装置における処理手順の一例であり、運用管理装置の分析設定生成の詳細処理手順の一例を示すフローチャートである。

図２５は、本実施の形態にかかる運用管理装置のボトルネック解析での表示画面の例である。第１の実施の形態で図１５を用いて説明した表示画面に加えて、「分析設定」の操作ボタンが追加されている。

図２６は、本実施の形態にかかる運用管理装置のボトルネック解析での表示画面の例である。図２５の分析設定の操作ボタンから呼び出され、管理者が設定変更の可否を確認するものである。

図２４を参照すると、まず、ボトルネック解析部３２５がボトルネック解析処理を行う（ステップＳ６０１）。本実施の形態におけるボトルネック解析の動作は、第１、第２の実施の形態で説明したものと同じである。

分析設定生成部３３２は、ボトルネック解析部３２５から、ボトルネック解析の結果を受け取り、分析設定蓄積処理部３１４の分析設定を参照し、ボトルネックとなっている要素が障害分析の対象となっていない場合には（ステップＳ６０２）、ボトルネック要素を監視するための監視設定を追加する（ステップＳ６０３）。
また、以前に追加したボトルネック要素が、今回のボトルネック解析で安全と判断されていれば（ステップＳ６０４）、その分析設定を削除する（ステップＳ６０５）。
これらのステップＳ６０１乃至ステップＳ６０５により、「設定追加ステップ」を行うことができる。この設定追加ステップでは、コンピュータが、前記ボトルネック解析ステップにて解析された前記要素について障害分析の監視対象として監視設定を追加することができる。

図２５は、運用管理装置の表示部に表示される表示画面の一例が示されている。同図では、ボトルネック解析における表示画面の一例が示されている。
表示画面Ｕ２００は、図１５に示す表示画面Ｕ１００と同様の構成である、解析結果表示部Ｕ２１０、要素リスト表示部Ｕ２２０、グラフ表示部Ｕ２３０、相関モデルの詳細情報を表示するための第１の表示操作部Ｕ２４２、リソース情報の詳細情報を表示するための第２の表示操作部Ｕ２４４、ボトルネック解析画面の表示を終了するための第３の表示操作部Ｕ２４８に加え、「分析設定」の操作ボタンである第４の表示操作部Ｕ２４６が追加されている。

第４の表示操作部Ｕ２４６を押下することで、図２６に示す表示画面Ｕ３００が表示される。
表示画面Ｕ３００（分析ルール設定画面）では、分析ルールを設定するための分析ルール表示設定部Ｕ３２０、現在の設定されている分析ルールを一覧表示した分析ルール一覧表示部Ｕ３３０、分析ルールを追加するか否かのメッセージを表示したメッセージ表示部Ｕ３１０、分析ルール設定画面での設定完了の確認を行うための各表示操作部Ｕ３４２、Ｕ３４４が表示形成されている。

管理者は、ここで、ボトルネック要素が監視対象からもれていないかどうかを確認し、必要に応じて分析設定の修正を行う。

以上のように本実施の形態によれば、前記第１の実施の形態と同様の作用効果を奏しながらも、分析設定生成手段が、ボトルネックとなることが予想される性能情報を障害分析手段で監視および分析するための追加設定を生成する。これにより、システムを網羅的に解析して発見された新たなボトルネックに対して、その要素を継続的に監視することが可能となり、より適切な運用管理が行えるという新たな効果がある。

その他の構成およびその他のステップないしは機能並びにその作用効果については、前述した実施の形態の場合と同一となっている。また、上記の説明において、上述した各ステップの動作内容及び各部の構成要素並びにそれらによる各機能をプログラム化し、コンピュータに実行させてもよい。

[その他の各種変形例]
また、本発明にかかる装置及び方法は、そのいくつかの特定の実施の形態に従って説明してきたが、本発明の主旨および範囲から逸脱することなく本発明の本文に記述した実施の形態に対して種々の変形が可能である。

例えば、上記構成部材の数、位置、形状等は上記実施の形態に限定されず、本発明を実施する上で好適な数、位置、形状等にすることができる。すなわち、上記実施の形態では、統計性能情報を算出するにあたり、Ｗｅｂ層、ＡＰ層、ＤＢ層でグループ化したが、本発明は、これらの層数を制限するものではない。他の種々の区分によってグループ化する場合であってもよい。

本発明の運用管理ソフトウエアは、１台のＰＣにインストールする場合であっても、クライアント・サーバシステムにおける端末及びサーバ、Ｐ２Ｐで利用可能な構成であっても構わない。また、各種表示画面などはＷｅｂ上でアクセス可能な構成であっても構わない。

また、本実施の形態の一態様の運用管理装置は、ＷＥＢサービスや業務サービスといった情報通信サービスを提供するサービス実行部と、前記サービス実行部の各々の要素の性能情報を蓄積する性能情報蓄積処理部と、前記サービス実行部の動作状態を検出して出力するとともに、前記動作状態に含まれる性能情報を前記性能情報蓄積処理部に蓄積する情報収集部と、前記サービス実行部の異常を検出するための分析設定を蓄積する分析設定蓄積処理部と、前記情報収集部から前記動作状態を受け取って前記分析設定蓄積処理部の分析設定に従って障害分析を行う障害分析部と、前記障害分析部から前記障害分析の結果を受け取って管理者に提示し、管理者の入力を受け付ける管理者対話部と、前記管理者対話部の指示に応じて前記サービス実行部上で障害の対処となる処理を実行する対処実行部と、で構成される運用管理装置において、前記性能情報蓄積処理部から一定期間の性能情報を取り出し、任意の２つの性能情報の値の時系列に対して、一方を入力とし他方を出力とした場合の変換関数を導出する処理をすべての性能情報に対して繰り返すことで、前記サービス実行部の全体的な稼動状態の相関モデルを生成する相関モデル生成部と、前記相関モデル生成部が生成した相関モデルを蓄積する相関モデル蓄積処理部と、前記相関モデル蓄積処理部の前記相関モデルの各々の性能情報間の変換関数を順次辿ることで、１つの性能情報の値を仮定した場合に他の性能情報の値を算出するモデル探索部と、前記性能情報毎の性能値の最大値、最小値、単位といった属性を記述した情報であるリソース情報を蓄積するリソース情報蓄積部と、前記性能情報のうち予め指定された１つの入力性能情報の値を順次増加あるいは減少させながら前記モデル探索部に指示するとともに、モデル探索部が算出した他の性能情報の値を受け取って前記リソース情報蓄積部のリソース情報と比較して性能値が限界を超える要素を検出してその性能情報とその時点の入力性能情報の値を含む解析結果を生成し、前記管理者対話部に出力するボトルネック解析部と、を有することができる。

この運用管理装置においては、相関モデル生成部が、各々の２つの性能情報間の変換関数としてサービス実行部の全体的な稼動状態の相関モデルを生成する。また、モデル探索部が、この相関モデル内の変換関数を順次辿ることで、１つの性能情報の値を仮定した場合に他の性能情報の値を算出する。さらに、ボトルネック解析部が、１つの入力性能情報の値を順次増加あるいは減少させながらモデル探索部が算出した他の性能情報の値を受け取って性能値が限界を超える要素を検出してその性能情報とその時点の入力性能情報の値を含む解析結果を生成する。

このように、検出された性能情報から自動的に性能情報の相関モデルを生成してボトルネック解析を行うことで、テスト時に想定できていなかった状況も含めて、稼動時の状況に合わせたボトルネックを解析することができ、第１の課題を解決する。また、予め想定される特定の処理に関係するものだけでなく、サービス実行部全体の挙動を網羅的に解析することができる。

さらに、実際の運用で検出された性能情報の相関関係に基づいて、将来対象システムで発生する可能性の高いボトルネックが抽出できるため、解析結果の検証を管理者の経験に頼る必要がない。さらにまた、生成する相関モデルが各々の性能情報間を１対１で変換する変換関数で構成されるため、１つの性能情報から他の性能情報を容易に導出でき、システムが大規模化しても処理量が膨大になることなくボトルネックを解析できる。

本実施の形態の一態様の運用管理装置は、本発明の第１の運用管理装置において、前記相関モデル蓄積部が、前記相関モデルに前記変換関数毎の正確さを示す重み情報を新たに蓄積するとともに、前記相関モデル生成部が、前記相関モデルの生成時に前記変換関数を導出する処理に加えて、前記変換関数で生成された性能値の系列と出力となる前記性能情報の実際の検出値の系列とを比較し、その値の差から前記変換関数の重み情報を算出する機能を新たに有し、前記モデル探索部が、１つの性能情報に対して複数の変換関数によって異なった値が算出された場合に、前記重み情報に基づいて１つの値を選択あるいは算出する機能を新たに有することができる。

この運用管理装置においては、相関モデル生成部が、変換関数毎の正確さを示す重み情報を生成し、モデル探索部が、１つの性能情報に対して複数の変換関数によって異なった値が算出された場合に、重み情報に基づいて１つの値を算出する。これにより、相関モデル内の複数の経路を用いてより正確な性能値の算出が行えるため、第２の課題を解決し、より正確にボトルネックを解析できるという効果がある。

本実施の形態の一態様の運用管理装置は、前記管理者対話部が、前記ボトルネック解析部の解析結果として、性能の限界を超えた前記性能情報と、その限界が算出された時点の入力となる前記性能情報とを含む結果画面を管理者に提示することができる。

この運用管理装置においては、管理者対話部が、ボトルネック解析部の解析結果として、性能の限界を超えた性能情報と、その時点の入力を提示する。このように、システムの最大性能の値と、その時にどこがボトルネックになるかという情報を合わせて提示することで、想定される将来負荷に対して、システムのどの要素をどう増強すれば良いかを明確にできる。

本実施の形態の一態様の運用管理装置は、前記管理者対話部が提示する前記結果画面が、性能の限界を超えた前記性能情報とともに、その他の前記性能情報を性能の利用率で順序付けして提示することができる。

この運用管理装置においては、管理者対話部が、性能の限界を超えた性能情報とともに、その他の性能情報を性能の利用率で順序付けして提示する。これにより、他の性能情報も含めて、システムのどの部分の性能に注意が必要かを明確に管理者に提示することができるという新たな効果がある。

本実施の形態の一態様の運用管理装置は、前記リソース情報蓄積部が、複数の性能情報から算出される総計性能情報とその算出の対象となる複数の前記性能情報の組み合わせを指定するグループ情報を新たに蓄積する機能を有し、前記リソース情報蓄積部の前記グループ情報を受け取り、前記相関モデル生成部に前記総計性能情報の生成を指示するとともに、前記モデル探索部に前記総計性能情報の値の更新を指示する総計性能値管理部を新たに有し、前記相関モデル生成部が、前記総計性能値管理部の指示に従って検出された複数の前記性能情報の同時刻の値に一定の算術演算を行って算出した値の時系列を性能値とする前記総計性能情報を生成し、前記性能情報にこの総計性能情報を加えて前記相関モデルを生成する機能を新たに有し、前記モデル探索部が、前記性能情報の値を算出する場合に、前記総計性能値管理部の指示に従って前記総計性能情報の値を再計算する機能を新たに有することができる。

この運用管理装置においては、相関モデル生成部が、総計性能値管理部の指示に従って、検出された複数の性能情報に一定の算術演算を行って算出した総計性能情報を含んだ相関モデルを生成し、モデル探索部が、この総計性能情報を含めて性能情報の値を算出する。これにより、例えば、負荷分散処理といったように、１つの性能情報が複数の性能情報の値の総和と関係する場合にも、処理量を増大させること無く正確なボトルネック解析が可能であり、負荷を抑えて正確な解析が行えるという効果がある。

本実施の形態の一態様の運用管理装置は、前記ボトルネック解析部の解析結果を受け取り、ボトルネックとなることが予想される性能情報を前記障害分析部で監視および分析するための追加設定を生成し、この追加設定に従って前記分析設定蓄積部に蓄積される分析設定を修正する分析設定生成部を新たに有することができる。
と特徴とする。

この運用管理装置においては、分析設定生成部が、ボトルネックとなることが予想される性能情報を障害分析部で監視および分析するための追加設定を生成する。

本実施の形態の一態様の運用管理装置は、前記ボトルネック解析部が、前記管理者対話部から管理者の入力を受け取って前記設定情報を修正する機能を有することができる。

この運用管理装置は、この分析設定を管理者の入力によって制御することができる。これにより、システムを網羅的に解析して発見された新たなボトルネックに対して、その要素を継続的に監視することが可能となり、より適切な運用管理が行えるという新たな効果がある。

このように、検出した性能情報の相関関係を適切に抽出してモデル化することで、実際の運用状況で発生するボトルネックを正確に予測できるとともに、管理者の負担が少なく、大規模環境においても分析に必要となる処理負荷を増大させないボトルネック解析を実現できるという顕著な効果がある。

さらに、本発明の運用管理装置を構成する手段は、その有する機能をハードウェア的に実現することは勿論、コンピュータとプログラムとで実現することができる。プログラムは、磁気ディスクや半導体メモリ等のコンピュータ可読記録媒体に記録されて提供され、コンピュータの立ち上げ時などにコンピュータに読み取られ、そのコンピュータの動作を制御することにより、そのコンピュータを前述した各実施の形態における手段として機能させることができる。

（プログラム）
また、前述した実施形態の機能を実現する本発明のソフトウエアのプログラムは、前述した各実施の形態における各種ブロック図などに示された処理部（処理手段）、機能などに対応したプログラムや、フローチャートなどに示された処理手順、処理手段、機能などに対応したプログラムなどにおいて各々処理される各処理プログラム、本明細書で全般的に記述される方法（ステップ）、説明された処理、データの全体もしくは各部を含む。

具体的には、本発明の運用管理プログラムは、システムを構成する複数の被管理装置から複数種の性能種目毎の性能情報を取得して、前記被管理装置を運用管理する運用管理装置が備えたコンピュータに諸機能を実現させることが可能なものである。
この運用管理プログラムは、前記性能種目又は前記被管理装置を要素とした場合に、少なくとも第１の要素に関する性能情報の時系列変化を示す第１の性能系列情報と、第２の要素に関する性能情報の時系列変化を示す第２の性能系列情報との相関関数を導出し、この相関関数に基づいて相関モデルを生成し、この相関モデルを前記各要素間の組み合わせについて求める相関モデル生成機能（例えば図５に示す符号１２３などの構成、図１１に示すステップＳ１１の機能など）と、前記各要素間の前記各相関モデルを順次探索して最適な相関モデルを決定し、この決定された相関モデルに基づいて少なくとも前記第１の要素の性能情報から前記第２の要素の性能情報を予測するモデル探索機能（例えば図５に示す符号１２４などの構成、図１１に示すステップＳ１２の機能など）と、を含む機能をコンピュータに実現させることができる。

また、この運用管理プログラムは、前記性能情報のとり得る範囲を規定したリソース情報に基づいて、前記モデル探索部にて予測された前記性能情報が前記範囲を超える要素、及びその要素に関する前記性能情報を含むボトルネック解析結果を生成するボトルネック解析機能（例えば図５に示す符号１２５などの構成、図１１に示すステップＳ１３の機能など）を含む機能をコンピュータに実現させることができる。

さらに、この運用管理プログラムは、前記相関モデル生成機能では、前記相関関数を用いて前記第１の要素に関する性能情報から算出された前記第２の要素に関する算出性能情報と、取得された前記第２の要素に関する性能情報との誤差に基づいて、前記相関モデルの重み情報を算出する機能をコンピュータに実現させることができる。
この場合、前記モデル探索機能では、少なくとも１つの前記要素に対して複数の前記相関関数によって異なる前記性能情報が算出され得る場合に、前記重み情報に基づいて一つの前記相関モデルを決定する機能をコンピュータに実現させることができる。

また、この運用管理プログラムは、前記要素をグループ化し、各要素の統計性能値を生成する統計性能値管理機能を含む機能をコンピュータに実現させることができる。

さらに、この運用管理プログラムは、前記相関モデル生成機能では、前記統計性能値によるグループ要素を新要素として加え、一の前記新要素と他の前記新要素との相関から相関モデルを生成する機能をコンピュータに実現させることができる。

また、この運用管理プログラムは、前記ボトルネック解析機能にて解析された前記要素について障害分析の監視対象として監視設定を行う分析設定生成機能を含む機能をコンピュータに実現させることができる。

さらに、この運用管理プログラムは、前記ボトルネック解析機能では、性能の前記範囲を超えた前記要素に関する性能情報とともに、他の前記要素に関する前記性能情報を利用率で順序付けして提示する機能をコンピュータに実現させることができる。

また、この運用管理プログラムは、前記ボトルネック解析機能では、性能の前記範囲を超えた前記要素に関する性能情報と、前記範囲が算出された時点の入力となる前記性能情報とを含む結果を提示する機能をコンピュータに実現させることができる。

さらに、この運用管理プログラムは、前記相関モデル生成機能では、前記第１の要素と前記第２の要素との前記相関モデルの第１の重み情報と、前記第１の要素と前記第３の要素との前記相関モデルの第２の重み情報と、前記第３の要素と前記第２の要素との前記相関モデルの第３の重み情報とをそれぞれ算出する機能をコンピュータに実現させることができる。
この場合、前記モデル探索機能では、前記第２の重み情報と前記第３の重み情報との合成重みと、前記第１の重み情報とを比較して、前記相関モデルを決定する機能をコンピュータに実現させることができる。

プログラムは、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。プログラムは、高水準プロシージャ型またはオブジェクト指向プログラミング言語で、あるいは必要に応じてアセンブリまたはマシン言語で実装することができる。いずれの場合も、言語はコンパイラ型またはインタープリタ型言語であってもよい。上述のプログラムを、一般のパソコンや携帯型情報端末などで動作可能なアプリケーションソフトに組み込んだものも含む。

プログラムを供給する手法としては、電気通信回線（有線、無線を問わない）によってコンピュータと通信可能に接続された外部の機器から前記電気通信回線を通じて提供することも可能である。例えば、コンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページからプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、プログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるサーバも、本発明の範囲に含まれるものである。

本発明のプログラムによれば、当該運用管理プログラムを格納するＲＯＭ等の記憶媒体から、当該運用管理プログラムをコンピュータ（ＣＰＵ）に読み込んで実行させれば、或いは、当該運用管理プログラムを、通信部を介してコンピュータにダウンロードさせた後に実行させれば、上述した本発明に係る装置を比較的簡単に実現できる。発明の思想の具現化例として装置のソフトウェアとなる場合には、かかるソフトウェアを記憶した記憶媒体上においても当然に存在し、利用される。

また、プログラムは、一次複製品、二次複製品などの複製段階については全く問う余地無く同等である。プログラムの供給方法として通信回線を利用して行なう場合であれば通信回線が伝送媒体となって本発明が利用されることになる。むろん、プログラムの発明として特定することもできる。さらに、装置における従属請求項は、方法，プログラムにおいて従属請求項に対応した構成にすることも可能である。

（情報記録媒体）
また、上述のプログラムを、情報記録媒体に記録した構成であってもよい。情報記録媒体には、上述のプログラムを含むアプリケーションプログラムが格納されており、コンピュータが当該情報記録媒体からアプリケーションプログラムを読み出し、当該アプリケーションプログラムをハードディスクにインストールすることが可能である。これにより、上述のプログラムは、磁気記録媒体、光記録媒体あるいはＲＯＭなどの情報記録媒体に記録してプログラムを提供することができる。そのようなプログラムが記録された情報記録媒体を、コンピュータにおいて使用することは、好都合な情報処理装置を構成する。

プログラムを供給するための情報記録媒体としては、例えばＲＯＭ、ＲＡＭ、フラッシュメモリやＳＲＡＭ等の半導体メモリ並びに集積回路、あるいはそれらを含むＵＳＢメモリやメモリカード、光ディスク、光磁気ディスク、磁気記録媒体等を用いてよく、さらに、フレキシブルディスク、ＣＤ−ＲＯＭ、ＣＤ―Ｒ、ＣＤ―ＲＷ、ＦＤ、ＤＶＤＲＯＭ、ＨＤＤＶＤ（ＨＤＤＶＤ−Ｒ−ＳＬ＜1層＞、 ＨＤＤＶＤ−Ｒ−ＤＬ＜２層＞、ＨＤＤＶＤ−ＲＷ−ＳＬ、ＨＤＤＶＤ−ＲＷ−ＤＬ、ＨＤＤＶＤ−ＲＡＭ−ＳＬ）、ＤＶＤ±Ｒ−ＳＬ、ＤＶＤ±Ｒ−ＤＬ、ＤＶＤ±ＲＷ−ＳＬ、ＤＶＤ±ＲＷ−ＤＬ、ＤＶＤ−ＲＡＭ、Ｂｌｕ−Ｒａｙ Ｄｉｓｋ＜登録商標＞（ＢＤ−ＲーＳＬ、ＢＤ−Ｒ−ＤＬ、ＢＤ−ＲＥ−ＳＬ、ＢＤ−ＲＥ−ＤＬ）、ＭＯ、ＺＩＰ、磁気カード、磁気テープ、ＳＤカード、メモリスティック、不揮発性メモリカード、ＩＣカード、等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置、等に記録して構成して用いてよい。

さらに「情報記録媒体」は、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの（伝送媒体ないしは伝送波）、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。

また、コンピュータ上で稼働しているＯＳ、端末（例えば携帯電話など）上のＲＴＯＳ等が処理の一部又は全部を行う場合にも、上記実施の形態と同等の機能を実現できると共に、同等の効果を得ることができる。

さらに、プログラムを暗号化してＣＤ−ＲＯＭ等の記録媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。この場合、本発明の構成は、プログラムの各構成要素（各種の手段、ステップ及びデータ）と、前記プログラム（各種の手段、ステップ及びデータ）を暗号化する暗号化手段と、を含んでよい。

また、上記実施の形態では、クライアントサーバーシステムを例に説明したが、サーバを介さずに端末同士がネットワークを組み、相互にデータを送受信するピアツーピア（Ｐｅｅｒ Ｔｏ Ｐｅｅｒ）通信によるシステムであってもよい。その際、管理装置は、ピア・ツゥ・ピア方式におけるマスタ端末であればよいまた、上述の実施の形態の「システム」を、他の「情報処理システム」と統合したシステムとして、これら全体を本発明の「システム」として構成することも一向に構わない。「情報処理システム」には、ＯＳや周辺機器等のハードウェアを含むものとする。

また、前記実施の形態における「システム」とは、複数の装置が論理的に集合した物をいい、各構成の装置が同一筐体中にあるか否かは問わない。このため、本発明は、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。「システム」には、ＯＳや周辺機器等のハードウェアを含んでもよい。

さらに、上述のプログラムなどが搭載される情報処理装置としては、サーバは、例えばパーソナルコンピュータに限らず、各種サーバー、ＥＷＳ（エンジニアリングワークステーション）、中型コンピュータ、メインフレームなどが挙げられる。情報端末は、以上の例に加えて、携帯型情報端末、各種モバイル端末、ＰＤＡ、携帯電話機、ウエアラブル情報端末、種々の（携帯型などの）テレビ・ＤＶＤレコーダ・各種音響機器及びそのリモコン、各種情報通信機能を搭載した家電機器、ネットワーク機能を有するゲーム機器等からも利用できる構成としても構わない。あるいは、これらの端末に表示されるアプリケーションとして改良されたものも本発明の範囲に含めることができる。

また、上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。

さらに、本明細書において、フローチャートに示されるステップは、記載された手順に従って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理を含むものである。また、実装では、プログラム手順（ステップ）が実行される順序を変更することができる。さらに、実装の必要に応じて、本明細書で説明した特定の手順（ステップ）を、組み合わされた手順（ステップ）として実装、除去、追加、または再配置することができる。

さらに、装置の各手段、各機能、各ステップの手順の機能などのプログラムの機能を、専用のハードウエア（例えば専用の半導体回路等）によりその機能を達成してもよく、プログラムの全機能のうち一部の機能をハードウエアで処理し、全機能のうちさらに他の機能をソフトウエアで処理するようにしてもよい。専用のハードウエアの場合、各部を集積回路例えばＬＳＩにて形成されてもよい。これらは個別に１チップ化されても良いし、一部または全部を含むように１チップ化されても良い。また、ＬＳＩには、ストリーミングエンジンなど他の機能ブロックが含まれていても良い。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセサで実現してもよい。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。

さらに、「通信」では、無線通信および有線通信は勿論、無線通信と有線通信とが混在した通信、即ち、ある区間では無線通信が行われ、他の区間では有線通信が行われるようなものであってもよい。さらに、ある装置から他の装置への通信が有線通信で行われ、他の装置からある装置への通信が無線通信で行われるようなものであってもよい。

そして、この通信には通信網が含まれる。通信網を構成するネットワークとしては、例えば携帯電話回線網（基地局及び交換システムを含む）、公衆電話回線網、ＩＰ電話網、ＩＳＤＮ回線網などこれに類する各種回線網、インターネット（乃ち、ＴＣＰ・ＩＰプロトコルを用いた通信態様）やイントラネット、ＬＡＮ[イーサネット（登録商標）、やギガビットイーサネット（登録商標）などを含む]、ＷＡＮ、光ファイバー通信網、電力線通信網、ブロードバンド対応可能な各種専用回線網などいずれのハードウエア構成でもよい。さらに、ネットワークは、ＴＣＰ・ＩＰプロトコルの他、種々の通信プロトコルを用いたネットワークあるいはソフトウエア的に構築された仮想ネットワークやこれに類するあらゆるネットワークを含むネットワークなどいかなる通信プロトコルであってもよい。また、ネットワークは、有線に限らず、無線（衛星通信、各種高周波通信手段等を含む）ネットワーク（例えば、簡易電話システムや携帯電話のようなシングルキャリア通信システム、Ｗ―ＣＤＭＡやＩＥＥＥ８０２．１１ｂに準拠した無線ＬＡＮのようなスペクトラム拡散通信システム、ＩＥＥＥ８０２．１１ａやＨｉｐｅｒＬＡＮ／２のようなマルチキャリア通信システム、などを含むネットワーク）であっても構わず、これらの組み合わせを利用してもよく、他のネットワークと接続されたシステムであってもよい。さらに、ネットワークは、ポイントツーポイント、ポイントツーマルチポイント、マルチポイントツーマルチポイントなど如何なる形態でもよい。

また、運用管理装置と他の被管理装置との間の通信構造に際し、いずれか一方又は双方に形成されるインタフェースの種類は、例えばパラレルインタフェース、ＵＳＢインタフェース、ＩＥＥＥ１３９４、ＬＡＮやＷＡＮ等のネットワークやその他これに類するもの、もしくは今後開発される如何なるインタフェースであっても構わない。

さらに、相関モデルを生成し、モデル探索を行う手法は、必ずしも実体のある装置に限られる必要はなく、その方法としても機能することは容易に理解できる。このため、方法にかかる発明も、必ずしも実体のある装置に限らず、その方法としても有効であることに相違はない。この場合、方法を実現するための一例として運用管理装置、運用管理システムなども含めることができる。

ところで、このような運用管理装置は、単独で存在する場合もあるし、ある機器に組み込まれた状態で利用されることもあるなど、発明の思想としてはこれに限らず、各種の態様を含むものである。従って、ソフトウェアであったりハードウェアであったりするなど、適宜、変更可能である。発明の思想の具現化例として装置のソフトウェアとなる場合には、かかるソフトウェアを記憶した記憶媒体上においても当然に存在し、利用されるといわざるをえない。

さらに、一部がソフトウェアであって、一部がハードウェアで実現されている場合であってもよく、一部を記憶媒体上に記憶しておいて必要に応じて適宜読み込まれるような形態のものとしてあってもよい。本発明をソフトウェアで実現する場合、ハードウェアやオペレーティングシステムを利用する構成とすることも可能であるし、これらと切り離して実現することもできる。

また、発明の範囲は、図示例に限定されないものとする。
さらに、上記各実施の形態には種々の段階が含まれており、開示される複数の構成要件における適宜な組み合わせにより種々の発明が抽出され得る。つまり、上述の各実施の形態同士、あるいはそれらのいずれかと各変形例のいずれかとの組み合わせによる例をも含む。この場合において、本実施形態において特に記載しなくとも、各実施の形態及びそれらの変形例に開示した各構成から自明な作用効果については、当然のことながら実施の形態の作用効果として含めることができる。逆に、本実施の形態に記載されたすべての作用効果を奏することのできる構成が、本発明の本質的特徴部分の必須構成要件であるとは限らない。また、実施の形態に示される全構成要件から幾つかの構成要件が削除された構成による実施の形態並びにその構成に基づく技術的範囲も発明になりうる。

そして、各実施の形態及びそれらの変形例を含むこれまでの記述は、本発明の理解を容易にするために、本発明の多様な実施の形態のうちの一例の開示、すなわち、何れも本発明を実施するにあたっての具体化の例を示したものに過ぎず、例証するものであり、制限するものではなく、適宜変形及び／又は変更が可能である。本発明は、その技術思想、またはその主要な特徴に基づいて、様々な形で実施することができ、各実施の形態及びその変形例によって本発明の技術的範囲が限定的に解釈されてはならないものである。
従って、上記に開示された各要素は、本発明の技術的範囲に属する全ての設計変更や均等物を含む趣旨である。

本発明は、コンピュータ全般に適用可能である。

１ 運用管理システム
２ コンピュータ（被管理装置）
３、１００、２００、３００ 運用管理装置
１２、１１２、２１２、３１２ 性能情報蓄積処理部
１４、１１４、２１４、３１４ 分析設定蓄積処理部
２１、１２１、２２１、３２１ サービス実行部
２２、１２２、２２２、３２２ 情報収集部
２６、１２６、２２６、３２６ 障害分析部
２７、１２７、２２７、３２７ 管理者対話部
２８、１２８、２２８、３２８ 対処実行部
１１６、２１６、３１６ 相関モデル蓄積処理部
１１８、２１８、３１８ リソース情報蓄積処理部
１２３、２２３、３２３ 相関モデル生成部
１２４、２２４、３２４ モデル探索部
１２５、２２５、３２５ ボトルネック解析部
２３１、３３１ 総計性能値管理部
３３２ 分析設定生成部

Claims (12)

1. システムを構成する被管理装置から複数種の性能種目に関わる性能情報を取得する運用管理装置であって、
   前記性能情報の時系列変化を示す性能系列情報から前記性能情報間の複数の相関関数および前記各相関関数の予測誤差を示す重み情報を含む相関モデルを生成する相関モデル生成部と、
   前記性能情報のうちの第１の性能情報から第２の性能情報を予測しうる前記相関関数またはその組み合わせによる経路が前記相関モデルの中に複数存在する場合に、前記重み情報の数値が最大となる前記経路を利用して前記第２の性能情報を予測するモデル探索部と
   を備える運用管理装置。
2. 前記相関モデル生成部が、前記性能系列情報のうちの２項目についての前記相関関数の係数および前記重み情報を算出する処理を前記性能系列情報の全ての組み合わせについて行って前記相関モデルを生成する、請求項１に記載の運用管理装置。
3. 前記モデル探索部が、少なくとも１つの前記第１の性能情報に対して複数の前記経路によって異なる前記第２の性能情報が算出され得る場合に、前記重み情報の数値が最大となる前記経路を利用すべき経路として決定する、請求項１に記載の運用管理装置。
4. 前記モデル探索部が、前記相関モデルに含まれる前記各相関関数を順次探索して、前記各性能情報間の利用すべき経路を決定する処理を行う、請求項３に記載の運用管理装置。
5. 前記モデル探索部が、決定された前記経路に基づいて前記第１の性能情報から前記第２の性能情報を予測する機能を備える、請求項４に記載の運用管理装置。
6. 複数のコンピュータ装置である被管理装置と、
   前記複数の被管理装置から該装置の動作に関する複数種の性能種目に関わる性能情報を取得する運用管理装置と、
   を含み、
   前記運用管理装置は、
   前記性能情報の時系列変化を示す性能系列情報から前記性能情報間の複数の相関関数および前記各相関関数の予測誤差を示す重み情報を含む相関モデルを生成する相関モデル生成部と、
   前記性能情報のうちの第１の性能情報から第２の性能情報を予測しうる前記相関関数の組み合わせによる経路が前記相関モデルの中に複数存在する場合に、前記重み情報の数値が最大となる前記経路を利用して前記第２の性能情報を予測するモデル探索部と
   を備えることを特徴とする運用管理システム。
7. システムを構成する複数のコンピュータ装置である被管理装置から取得される該装置の動作に関する複数種の性能種目に関わる性能情報に基づいて、前記被管理装置を運用管理する情報処理方法であって、
   前記性能情報の時系列変化を示す性能系列情報から前記性能情報間の複数の相関関数および前記各相関関数の予測誤差を示す重み情報を含む相関モデルを生成する相関モデル生成ステップと、
   前記性能情報のうちの第１の性能情報から第２の性能情報を予測しうる前記相関関数の組み合わせによる経路が前記相関モデルの中に複数存在する場合に、前記重み情報の数値が最大となる前記経路を利用して前記第２の性能情報を予測するモデル探索ステップと
   を含むことを特徴とする運用管理方法。
8. 前記相関モデル生成ステップが、前記性能系列情報のうちの２項目についての前記相関関数の係数および前記重み情報を算出する処理を前記性能系列情報の全ての組み合わせについて行って前記相関モデルを生成する、請求項７に記載の運用管理方法。
9. 前記モデル探索ステップが、少なくとも１つの前記第１の性能情報に対して複数の前記相関関数によって異なる前記第２の性能情報が算出され得る場合に、前記重み情報の数値が最大となる前記経路を利用すべき経路として決定する、請求項８に記載の運用管理方法。
10. 前記モデル探索ステップが、前記相関モデルに含まれる前記各相関関数を順次探索して、前記各性能情報間の利用すべき経路を決定する、請求項９に記載の運用管理方法。
11. 前記モデル探索ステップが、決定された前記経路に基づいて前記第１の性能情報から前記第２の性能情報を予測する、請求項１０に記載の運用管理方法。
12. システムを構成する複数のコンピュータ装置である被管理装置から該装置の動作に関する複数種の性能種目に関わる性能情報を取得して、前記被管理装置を運用管理する運用管理装置が備えたコンピュータに諸機能を実現させることが可能な運用管理プログラムであって、
    前記性能情報の時系列変化を示す性能系列情報から前記性能情報間の複数の相関関数および前記各相関関数の予測誤差を示す重み情報を含む相関モデルを生成する相関モデル生成機能と、
    前記性能情報のうちの第１の性能情報から第２の性能情報を予測しうる前記相関関数の組み合わせによる経路が前記相関モデルの中に複数存在する場合に、前記重み情報の数値が最大となる前記経路を利用して前記第２の性能情報を予測するモデル探索機能と、
    を含む機能をコンピュータに実現させることを特徴とする運用管理プログラム。

Images