(57)【要約】【課題】システムの性能劣化状況の検知をより柔軟に行うことができ、また劣化の原因や対策を詳細に提示することができる運用管理支援装置を提供する。【解決手段】各要素の稼動情報を所定時間毎に収集する稼働情報収集部１０１と、収集した稼働情報を記憶する稼働情報ＤＢ１０２と、記憶した各要素の稼働情報間の統計的分析値を求める前処理部１０３と、複数の稼動モデルに対応した各要素の稼働情報間の統計的分析値を予め記憶したモデル情報ＤＢ１０５と、前処理部１０３で求めた統計的分析値をモデル情報ＤＢ１０５に記憶された統計的分析値と比較することで、収集した稼働情報に対応する稼動モデルを求める判断部１０６とを備えている。  【選択図】            図１
2006146668.tif 000002
【特許請求の範囲】
【請求項１】
３以上の要素の稼動情報を所定時間毎に収集する稼働情報収集手段と、
稼働情報収集手段で収集した稼働情報を記憶する稼働情報記憶手段と、
記憶した各要素の稼働情報間の統計的分析値を求める統計処理手段と、
複数の稼動モデルに対応した各要素の稼働情報間の統計的分析値を予め記憶したモデル情報記憶手段と、
統計処理手段で求めた統計的分析値をモデル情報記憶手段に記憶された統計的分析値と比較することで、収集した稼働情報に対応する稼動モデルを求める判断部と
を備えることを特徴とする運用管理支援装置。
【請求項２】
前記判断部が、比較結果が一致した稼働モデルを求め、比較結果が一致しなかった場合には類似する稼働モデルを求める
ことを特徴とする請求項１記載の運用管理支援装置。
【請求項３】
前記判断部が、検定によって類似する稼働モデルを求め、検定によって類似する稼働モデルが求められない場合に比較結果が不一致となった統計的分析値の個数に基づいて類似する稼働モデルを求める
ことを特徴とする請求項２記載の運用管理支援装置。
【請求項４】
前記判断部によって稼働モデルが求められた場合に所定の通知先にその旨を通知する通知手段と、
前記判断部によって稼働モデルが求められた場合に所定のアプリケーションを実行する対応アプリケーション連携手段と
をさらに備えることを特徴とする請求項１〜３のいずれか１項に記載の運用管理支援装置。
【請求項５】
前記対応アプリケーション連携手段が、求められたモデルが類似する稼働モデルである場合には所定のアプリケーションを実行しない
ことを特徴とする請求項４記載の運用管理支援装置。
【請求項６】
前記統計的分析値が、相関係数であることを特徴とする請求項１〜５のいずれか１項に記載の運用管理支援装置。
【請求項７】
前記統計的分析値が、主成分分析結果であることを特徴とする請求項１〜５のいずれか１項に記載の運用管理支援装置。
【請求項８】
前記稼働情報が、ハードウェア稼動情報及びアプリケーション稼動情報の両者を含むことを特徴とする請求項１〜７のいずれか１項に記載の運用管理支援装置。
【請求項９】
前記モデル情報記憶手段に記憶された稼働モデルが、各要素を稼働させた状態で実際に収集された稼働情報に基づいて作成されたものであることを特徴とする請求項１〜８のいずれか１項に記載の運用管理支援装置。
【請求項１０】
３以上の要素の稼動情報を所定時間毎に収集する稼働情報収集段階と、
稼働情報収集段階で収集した稼働情報を記憶する稼働情報記憶段階と、
記憶した各要素の稼働情報間の統計的分析値を求める統計処理段階と、
複数の稼動モデルに対応した各要素の稼働情報間の統計的分析値を予め記憶したモデル情報記憶手段を用いて、統計処理段階で求めた統計的分析値をモデル情報記憶手段に記憶された統計的分析値と比較することで、収集した稼働情報に対応する稼動モデルを求める判断段階と
をコンピュータを用いて実行するための記述を含むことを特徴とする運用管理支援プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークシステム等のシステムの運用管理を支援するために用いて好適な運用管理支援装置及び運用管理支援プログラムに関する。
【背景技術】
【０００２】
従来の運用管理では、監視対象の各サーバやネットワーク機器のハードウェア的な稼動情報や、各プログラムが動作しているかという情報を収集し、システムの構成要素ごとのアラートや稼動情報の提示を行っている。例えば、特許文献１に記載されている装置では、データベースに事前定義された一定範囲の条件を満たす運用状況が発生したときにアラートを発するようにしている。また、この装置では、収集した情報に基づいて性能劣化の到達予想を直線・曲線近似によって提示できるようになっている。ただし、この装置では、定義外の異常障害は基本的に考慮されていない。すなわち、監視対象の各構成要素の稼動情報に対して一定の値の範囲を予め定義し、その範囲に入るかまたは外れるかということを検出することで性能劣化状態が判定されるようになっていた。また、この装置では、検知した結果に基づいて予め定義されているものに関して、相関分析によって原因を絞り込み、対応する対策が表示されるようになっていた。
【０００３】
一方、特許文献２に記載されている装置では、正常動作からの外れ値を検知することで、性能劣化が判定されるようになっている。測定値から導かれる制御量（を基にしたデータ）と動作を行う操作量（を基にしたデータ）の相関を取り、検定を行うことで、性能劣化状態を検知している。ただし、各構成要素のデータは取得していないので、性能劣化の原因や対策を判断することはできなかった。
【特許文献１】特開２００４−１４５５３６号公報
【特許文献２】特開２００３−２０８２１９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
システムに障害が発生したときには、管理者がシステムの構成要素ごとのアラートや稼動情報から、システムの状況を推定・想像したり、あらかじめ定義したマニュアルに従って対応を行う。前者は、管理者のスキルに依存する部分が大きいため、障害、性能低下の改善に時間を要したり、人為的なミスによる２次被害の可能性があったりする。後者は条件の定義が厳密であるため、取得値が定義には含まれないが危険な兆候である場合などのケースでは、対応がとれなかったり、誤った対応を行ってしまったりするという問題点がある。
【０００５】
特許文献１に記載されている装置では、劣化の数値範囲・原因・対策が事前定義され、その範囲内において検出と対策を示すことができ、また、範囲外となる場合には、数値を直線・曲線で予測するのみで各構成要素の関連性などは考慮されていなかった。そのため、事前定義外の状況には対応しきれない場合が発生すると考えられる。
【０００６】
また、特許文献２に記載の装置では、正常動作の状態を以前のデータから生成し、比較することで異常を検出する。すなわち“異常”の検出までを目的とするものあって、何処がおかしいかまでは、提示することができなかった。
【０００７】
本発明は、上記の事情を考慮してなされたものであって、性能劣化状況の検知をより柔軟に行うことができ、また劣化の原因や対策を詳細に提示することができる運用管理支援装置を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記課題を解決するため、請求項１記載の発明は、３以上の要素の稼動情報を所定時間毎に収集する稼働情報収集手段と、稼働情報収集手段で収集した稼働情報を記憶する稼働情報記憶手段と、記憶した各要素の稼働情報間の統計的分析値を求める統計処理手段と、複数の稼動モデルに対応した各要素の稼働情報間の統計的分析値を予め記憶したモデル情報記憶手段と、統計処理手段で求めた統計的分析値をモデル情報記憶手段に記憶された統計的分析値と比較することで、収集した稼働情報に対応する稼動モデルを求める判断部とを備えることを特徴とする。
【０００９】
請求項２記載の発明は、前記判断部が、比較結果が一致した稼働モデルを求め、比較結果が一致しなかった場合には類似する稼働モデルを求めることを特徴とする。
【００１０】
請求項３記載の発明は、前記判断部が、検定によって類似する稼働モデルを求め、検定によって類似する稼働モデルが求められない場合に比較結果が不一致となった統計的分析値の個数に基づいて類似する稼働モデルを求めることを特徴とする。
【００１１】
請求項４記載の発明は、前記判断部によって稼働モデルが求められた場合に所定の通知先にその旨を通知する通知手段と、前記判断部によって稼働モデルが求められた場合に所定のアプリケーションを実行する対応アプリケーション連携手段とをさらに備えることを特徴とする。
【００１２】
請求項５記載の発明は、前記対応アプリケーション連携手段が、求められたモデルが類似する稼働モデルである場合には所定のアプリケーションを実行しないことを特徴とする。
【００１３】
請求項６記載の発明は、前記統計的分析値が、相関係数であることを特徴とする。
【００１４】
請求項７記載の発明は、前記統計的分析値が、主成分分析結果であることを特徴とする。
【００１５】
請求項８記載の発明は、前記稼働情報が、ハードウェア稼動情報及びアプリケーション稼動情報の両者を含むことを特徴とする。
【００１６】
請求項９記載の発明は、前記モデル情報記憶手段に記憶された稼働モデルが、各要素を稼働させた状態で実際に収集された稼働情報に基づいて作成されたものであることを特徴とする。
【００１７】
請求項１０記載の発明は、３以上の要素の稼動情報を所定時間毎に収集する稼働情報収集段階と、稼働情報収集段階で収集した稼働情報を記憶する稼働情報記憶段階と、記憶した各要素の稼働情報間の統計的分析値を求める統計処理段階と、複数の稼動モデルに対応した各要素の稼働情報間の統計的分析値を予め記憶したモデル情報記憶手段を用いて、統計処理段階で求めた統計的分析値をモデル情報記憶手段に記憶された統計的分析値と比較することで、収集した稼働情報に対応する稼動モデルを求める判断段階とをコンピュータを用いて実行するための記述を含むことを特徴とする。
【発明の効果】
【００１８】
請求項１記載の発明では、各要素の稼働情報に対して一定の検出範囲を設定するのではなく、複数の要素の稼働情報間の統計的分析値（例えば相関係数、主成分分析結果等）と、予め定義した複数の稼働モデルに対応した統計的分析値とを比較することで、対応する稼働モデルを求めるようにしている。すなわち、統計的な稼働モデルを利用して通常の状況や障害の状況を定義し、各要素の稼働状態間の統計的分析値に基づき、いずれの稼働モデルに一致あるいは類似するかということを判断することで、通常の状況や性能劣化等の障害の状況を提示することができる。したがって、性能劣化状況の検知をより柔軟に行うことができる。また各要素の稼働情報を収集しているので、劣化の原因や対策を詳細に提示することができる。
【００１９】
また、請求項２記載の発明によれば、前記判断部が、比較結果が一致した稼働モデルを求め、比較結果が一致しなかった場合には類似する稼働モデルを求めるので、性能劣化状況の検知をより柔軟に行うことができる。
【００２０】
請求項３記載の発明によれば、前記判断部が、検定によって類似する稼働モデルを求め、検定によって類似する稼働モデルが求められない場合に比較結果が不一致となった統計的分析値の個数に基づいて類似する稼働モデルを求めるので、類似モデルを求める処理の精度を向上させることができる。
【００２１】
請求項４記載の発明によれば、前記判断部によって稼働モデルが求められた場合に所定の通知先にその旨を通知する通知手段と、前記判断部によって稼働モデルが求められた場合に所定のアプリケーションを実行する対応アプリケーション連携手段とをさらに備えたので、所定の対応や通知を自動的に行うことができる。
【００２２】
請求項５記載の発明によれば、前記対応アプリケーション連携手段が、求められたモデルが類似する稼働モデルである場合には所定のアプリケーションを実行しないようにしたので、予期しない稼働状態によって誤った類似モデルが検知されたような場合に誤った対応策が自動的に実施されないようにすることができる。
【００２３】
請求項６記載の発明によれば、前記統計的分析値が相関係数なので、各要素の２個の稼働情報間に稼働状況に応じて相関が十分認められる場合に、稼働状況の識別精度を向上させることができる。
【００２４】
請求項７記載の発明によれば、前記統計的分析値は主成分分析結果あり、相関係数行列が２変数の相関を行列にしたものであるのに対し主成分分析はｎ変数の場合にはｎ個の特性より定まるため、主成分分析結果に特徴が十分認められる場合に、稼働状況の識別精度を向上させることができる。
【００２５】
請求項８記載の発明によれば、前記稼働情報が、ハードウェア稼動情報及びアプリケーション稼動情報の両者を含むので、より詳細に原因を特定することができる。
【００２６】
請求項９記載の発明によれば、前記モデル情報記憶手段に記憶された稼働モデルが、各要素を稼働させた状態で実際に収集された稼働情報に基づいて作成されたものであるので、基準とする稼働モデルを実システムにより一致したものにしやすくなる。
【発明を実施するための最良の形態】
【００２７】
以下、図面を参照して本発明による運用管理支援装置の実施の形態について説明する。図１は、本発明による運用管理支援装置の実施の形態の構成を示すシステム図である。図１では、インターネット等のネットワーク１に対して通信回線２を介して監視対象システム１０が接続され、さらに監視対象システム１０に対して本実施の形態の運用監視装置としての管理サーバ１００が接続されている。管理サーバ１００は、監視対象システム１０の稼働状態を監視し、ハードウェア的な稼動情報や、各プログラムが動作しているかという稼働情報を収集し、自装置の表示装置１００ａやクライアント端末２００の表示装置２００ａを用いて、システムの構成要素ごとのアラートや稼動情報の提示を行う。
【００２８】
監視対象システム１０は、ネットワーク１に対して各種通信サービスを提供するものであって、ファイアウォール１１、各装置間を接続するネットワーク１２、ＮＩＤＳ（Ｎｅｔｗｏｒｋ  Ｉｎｔｒｕｓｉｏｎ  Ｄｅｔｅｃｔｉｏｎ  Ｓｙｓｔｅｍ；ネットワーク型不正侵入検知システム）１３、Ｗｅｂサーバ１４、ＡＰ（ＡＰｐｌｉｃａｔｉｏｎ）サーバ１５、およびＤＢ（ＤａｔａＢａｓｅ）サーバ１６から構成されている。ファイアウォール１１は、ネットワーク１２に対するネットワーク１からの不正なアクセスを制限する。ＮＩＤＳ１３は、ネットワーク１２への侵入を検知するシステムであり、ファイアウォール１１が発見できない攻撃を認識することができる。Ｗｅｂサーバ１４は、ネットワーク１を介してＷｅｂブラウザ等で閲覧されるコンテンツを提供するためのコンピュータである。ＡＰサーバ１５は、ネットワーク１を介したＷｅｂブラウザ等からの要求に応じて所定のアプリケーションプログラムを実行するためのコンピュータであり、例えばＷｅｂサーバ１４とＤＢサーバ１６の中間に位置して所定の処理を行う。そして、ＤＢサーバ１６は、複数のデータ、ファイル等の情報を蓄積、整理し、ネットワーク１を介したＷｅｂブラウザ等からの要求に応じて所定の情報を提供するためのコンピュータである。
【００２９】
監視対象システム１０を構成する各装置１１、１３〜１６は、それぞれ、本実施の形態における監視対象の構成要素の１または複数を有するものである。各装置は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）の使用率、ＤＢクエリ数（検索数）、アクセス数、エラーログ記録数、アクセスログ記録数、送出パケット数、ＮＩＤＳアラート数等の稼働情報の１または複数を、管理サーバ１００の要求に応じて、あるいは自発的に、管理サーバ１００に対して送信する。これらの稼働情報は、ネットワーク１２を介して、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ  Ｐｒｏｔｏｃｏｌ）、ＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）等のプロトコルや、ｒｓｈ（ｒｅｍｏｔｅ  ｓｈｅｌｌ）を用いて転送される。
【００３０】
管理サーバ１００は、所定のＯＳ（Operating System）上でそのハードウェア資源を利用して所定のプログラム実行することで運用監視装置としての機能を提供するコンピュータである。図１では、管理サーバ１００内にソフトウェアとハードウェアと一方または組み合わせから構成されている各機能をブロックに分けて示している。この場合、管理サーバ１００は、稼働情報収集部１０１、稼働情報ＤＢ１０２、前処理部１０３、モデル生成部１０４、モデル情報ＤＢ１０５、判断部１０６、ユーザインターフェース１０７、アラート通知部１０８、対応情報ＤＢ１０９、および対応アプリケーション連携部１１０を備えている。
【００３１】
稼働情報収集部１０１は、監視対象システム１０内の複数の装置１１、１３〜１６（３個以上の構成要素）から、ＩＣＭＰ、ＳＮＭＰ、ｒｓｈなどを利用して、ＣＰＵ、Ｎｅｔｗｏｒｋ ＩＯ（ネットワークＩｎｐｕｔ／Ｏｕｔｐｕｔ）などのハードウェア稼動情報、Ｗｅｂサーバのアクセス量、ＤＢサーバの処理クエリ量などのアプリケーション稼動情報を一定時間間隔で取得し、稼動情報ＤＢ１０２に保存する。稼働情報ＤＢ１０２は、稼動情報収集部１０１が取得したデータ（稼働情報）をタイムスタンプをキーとして保存する。
【００３２】
図２は稼働情報ＤＢ１０２に格納されるデータの一例を示す図である。図２に示す例では、それぞれ１分間隔で収集した、サーバ１（例えばＷｅｂサーバ１４）のＣＰＵ使用率、サーバ２（例えばＡＰサーバ１５）のＣＰＵ使用率、ＤＢクエリ数（ＤＢサーバ１６における検索数に対応）、アクセス処理数（例えばＷｅｂサーバ１４の所定の機能による処理数）が記録されている。
【００３３】
前処理部１０３は、モデル生成部１０４または判断部１０６で使用するデータの前処理（統計処理）を行う。前処理部１０３は、稼働情報ＤＢ１０２に格納されている各構成要素の稼働情報間の統計的分析値を求める統計処理を行う。前処理部１０３は、例えば、稼働情報ＤＢ１０２に格納されている各装置１１、１２〜１６から取得した稼働情報に対して、各稼働情報間の相関係数を求めたり、各稼働情報間で主成分分析を行ったりして、統計的分析値を求める。この統計的分析値は、所定時刻における各装置の稼働情報間の関連度を示す値となっている。図３に前処理部１０３の処理結果の一例を示す。
【００３４】
図３は、図２に示す稼働情報に対して、相関係数を求める処理を行った結果を示すものであり、処理結果が相関係数行列として求められていることを示している。図３に示す例では、サーバ１のＣＰＵ使用率とサーバ２のＣＰＵ使用率との相関係数が「０．９３」、サーバ１のＣＰＵ使用率とＤＢクエリ数との相関係数が「０．７５」、サーバ２のＣＰＵ使用率とＤＢクエリ数との相関係数が「０．８９」等となっている。
【００３５】
相関関数は、２次元のデータにおける変量間の関係をある１つ係数で表現する手法であり、相関係数は、２つの変量間の相関関係の程度を表す数値である。いま、ある集合（xi, yi）、xi∈X、yi∈Yという２次元データ集合が存在した場合、下式（１）で、相関係数RXYは−1≦RXY≦1の範囲で与えられる。
【００３６】
【数１】
2006146668.tif 000003
【００３７】
なお、相関係数の値（RXYの絶対値｜RXY｜）については一般的に次の特性が認められている。｜RXY｜≦0.2…ほとんど相関がなく、0.2≦｜RXY｜≦0.4…弱い相関があり、0.4≦｜RXY｜≦0.7…中程度の相関があり、そして、0.7≦｜RXY｜…高い相関がある。
【００３８】
図１のモデル生成部１０４は、本装置で基準（標準）となる複数の稼働モデルを定義してモデル情報ＤＢ１０５に登録したり、追加したりするための動作を行う。各稼働モデルは、意図的に障害を発生させるなどして所望の状態を作り出し、稼働情報収集部１０１で各構成要素から稼働情報を実際に収集することで作成することができる。ここで、各稼働モデルは、正常状態、正常状態で比較的アクセスが増大した状態、ＡＰアプリ（アプリケーション）異常負荷時状態、ＡＰサーバ障害状態、エラーアクセス増大、ハードディスク・エラー多発状態等の稼働状態を所定の形式で表したものであり、各構成要素の稼働情報間の統計的分析値を用いて定義される。図４および図５にモデル情報ＤＢ１０５の登録情報（モデル情報テーブル）の一例を示した。
【００３９】
図４に示す例では、複数の稼働モデルに対応させて（この場合、ＡＰアプリ異常負荷、エラーアクセス増大の２つの稼働モデルに対応させて）、モデルＩＤ（Identification）、対応ＩＤ、通知ＩＤ、モデルデータによってモデル情報テーブルの各レコードが構成されている。モデルＩＤは各稼働モデルの識別情報であり、対応ＩＤはその状態が発生した場合に取るべき対応を特定する情報であり、通知ＩＤはその状態が発生した場合に通知すべきアラート通知先等の内容を特定する情報であり、モデルデータはその状態で取得された構成要素の稼働情報間の統計的分析値である。対応ＩＤと通知ＩＤに対応する具体的内容は、図１の対応情報ＤＢ１０９に記憶されている。モデルデータは、例えば相関係数を統計的分析値として用いる場合には、図５に示すような各構成要素の稼働情報間の各相関係数からなる相関係数行列となる。この各モデルの定義データは、実際のデータと比較処理を行う際に比較基準値の中央値として用いられ、所定の幅を持たせた上で各データ間の比較が行われるようになっている。すなわち、中央値を基準として所定の幅を持たせた値が各モデルの定義データとなる。ただし、本実施の形態では、複数のモデル間の自他識別性を向上させるため、モデル情報ＤＢ１０５に登録される各定義データに対しては次のような中央値の変更処理を予め行うようにしている。
【００４０】
図５は、モデル情報ＤＢ１０５に登録される相関係数行列の一例を示す図であり、図３に示す前処理部１０３で作成された相関係数行列に対して、モデル生成部１０４によって中央値の変更処理を行ったものである。中央値の変更処理は、先に登録された他のモデルと、相関係数行列の各要素が同一あるいは非常に近い値とならないようにするためのものである。図６を参照して、この中央値変更処理について説明する。
【００４１】
図６は、モデル生成部１０４による中央値変更処理を含むモデル追加処理の流れを示すフローチャートである。入力データは、前処理が行われた中間データ（図３参照）、コメント、対応ＩＤ、通知ＩＤである（コメント、対応ＩＤ、通知ＩＤは、モデル作成者が与える。ただし、対応ＩＤ、通知ＩＤは少なくとも一方があればよい）。データの置き換え処理（ステップＳ１１）では、入力（インプット）されたデータを事前に定義されたレンジ幅の（○○〜○○）の中央値の形式に置き換える処理を行う。インプットのデータが、そのレンジに入っていれば変更可能であるとする。すなわち、インプットデータが０．６５であり、レンジ幅が０．２であれば、０．５５〜０．７５の範囲で中央値を設定できるとしている（図７参照）。ただし、レンジ幅はチューニングパラメータとして、モデル毎に変更可能とすることができる。初期値はインプットの値を使用する。
【００４２】
事前の限度回数Ｎを超えていない場合には（ステップＳ１２で「Ｎｏ」）、既存モデルとの比較を行う（ステップＳ１４）。既存モデルとの比較は、すでに存在するモデルとすべての要素にレンジの重複がある場合には両方のモデルの状況と判断されてしまうのでそのようなモデルを登録しないようにするためのチェック作業である。明確な差がある場合には（ステップＳ１５で「Ｙｅｓ」）、モデル情報ＤＢ１０５のすでに登録されているレコード分の回数、比較対象の既存モデルを変化させながらステップＳ１４の処理を繰り返し行う（ステップＳ１６〜ステップＳ１３〜ステップＳ１４〜ステップＳ１５〜ステップＳ１６〜…）。ステップＳ１５では、例えば図８に示すように、既存モデルのレンジと、今回のインプットデータのレンジとの重複部分（矢印太線）が所定の値以下であるかどうかを確認し、所定の値以下である場合に明確な差があると判定する。
【００４３】
一方、明確な差が無い場合には（ステップＳ１５で「Ｎｏ」）、重複が少ない部分を走査する（ステップＳ１８）。ステップＳ１８では、差がないと判断された要素についてレンジ間の重なりが少ない部分をリストアップして、データの置き換え候補として、ステップＳ１１のデータの置き換え処理に渡される。ステップＳ１１では置き換え候補に基づいて中央値を変更する処理を行う。
【００４４】
以上のようにして、すべての既存モデルと明確な差がある状態となったところで、今回のインプットデータがモデル情報ＤＢ１０５に追加される（ステップＳ１７）。また、コメント、対応ＩＤ、通知ＩＤもセットされる。ただし、ステップＳ１１のデータの置き換え処理が所定の限界回数Ｎを超えた場合には、処理不能として、エラー処理へと引き継がれる（ステップＳ１２で「Ｙｅｓ」）。
【００４５】
以上の構成および処理によって、モデル情報ＤＢ１５に稼働モデルが定義される。次に、図１を参照して、定義した稼働モデルを利用した監視処理について説明する。
【００４６】
図１の判断部１０６は、定義されている稼働モデルと未知のデータ（新たに収集した稼働情報）との判断を行う。この判断部１０６は、モデル生成部１０４と排他的に動作する。つまり、稼働情報収集部１０１によって収集され、稼働情報ＤＢ１０２に記憶された監視対象システム１０の稼働情報は、前処理部１０３によって統計処理された後、判断部１０６へ入力される。判断部１０６は、前処理部１０３で求めた統計的分析値を、モデル情報ＤＢ１０５に記憶された統計的分析値と比較することで、収集した稼働情報に対応する稼動モデルを求める判断を実行する。なお、本実施の形態では、まず、厳密に一致するモデルを探索し、厳密に一致するモデルが見つからない場合には、類似するモデルを探索する処理を行うようにしている。判断部１０６は、定期的に、あるいは障害のアラートや、提供サービスのレスポンス低下などをトリガとしてこれらの処理を行う。
【００４７】
図９を参照して判断部１０６による処理について説明する。入力データは、例えば統計的分析値が相関係数であるとすれば図３に示すような前処理が行われた中間データとなる。まず、新たな処理の開始に際してレンジ外の要素の個数を記憶する記憶領域（ステップＳ２５参照）が初期化される。ステップＳ２２では、既存モデルとの比較処理が行われる。既存モデルとの比較処理では、前処理が行われた中間データの各要素（相関係数行列の各要素）がモデルのレンジに入るかが計算される。例えば今回の比較対象データと、あるモデル（今回選択中のモデル情報ＤＢ１０５のレコードに含まれる各要素のレンジ）を比較した結果が、図１０に示すようになった場合（太線で示すレンジ内に今回の要素が含まれる場合）、この要素についてはOK（レンジに入っている）とされる。これを要素の個数回繰り返し行い、中間データの全要素について既存モデルの対応する要素との比較を行う。
【００４８】
次に、すべての要素がそのモデルのレンジに入っているかを判定し（ステップＳ２３）、入っている場合には（ステップＳ２３で「Ｙｅｓ」）、現在の稼働状態がそのモデルの状態であると推定する。そして、コメント、対応ＩＤ、通知ＩＤを、図１のユーザインターフェース１０７、アラート通知部１０８、対応アプリケーション連携部１１０に出力し、終了する。
【００４９】
一方、レンジから外れる要素があった場合には（ステップＳ２３で「Ｎｏ」）、外れた個数が他のモデルに対して記録されているものより少ないかを判定し、少ない場合には（ステップＳ２４で「Ｙｅｓ」）、外れた個数とモデルＩＤを所定の記憶領域に記録する（ステップＳ２５）。ステップＳ２２以降の処理を、モデル情報ＤＢ１０５に定義されている各レコード（各モデル）に対して実行する。その際、すべての要素がレンジに入るモデルがあれば処理を終了するが（ステップＳ２３で「Ｙｅｓ」の場合）、すべての要素がレンジに入るモデルが無い場合には、記録している外れの個数が最も少ないモデルのＩＤと個数を引数として、類似マッチングフローへと処理を進める（ステップＳ２７）。
【００５０】
図１１は、類似マッチングフローの一例を示すフローチャートである。入力データは、前処理が行われた中間データ（図３参照）と、図１０のステップＳ２５で記録された外れの個数が最も少ないモデルＩＤである。この場合、モデルの再探索は行われず、入力されたモデルＩＤで指定されるモデルが類似するモデルとして出力される。ただし、その際、再度比較を行い（ステップＳ３１）、外れた要素をリストアップして（ステップＳ３２）、類似であることのフラグ、コメント、通知ＩＤを、ユーザインターフェース１０７およびアラート通知部１０８に出力し、処理を終了する。ただし、一致ではなく類似であるので、対応アプリケーション連携は行わない。
【００５１】
上記で図１０および図１１を参照して説明した判断部フローの流れでは、図１２に示すように、基本的には厳密なマッチング（ステップＳ４１）を行い、厳密なマッチングができない場合に回数による類似マッチング（ステップＳ４２）を行うこととしている。これに対し、検定を用いる類似マッチングを追加して、精度向上を図ることも可能である。すなわち、図１３に示すように、まず、厳密なマッチングを行い（ステップＳ５１）、厳密なマッチングができない場合に検定を用いるマッチングを行い（ステップＳ５２）、そして、検定を用いるマッチングで所定条件を満たすモデルが得られない場合に回数による類似マッチングを行うようにする（ステップＳ５３）ことも可能である。
【００５２】
図１４は、図１の判断部１０６で検定によるマッチング（類似マッチング追加例）を行う場合の処理の一例を示すフローチャートである。この場合、前提として、モデル情報ＤＢ１０５のモデルデータには、相関係数行列に加え、分散共分散行列とサンプル数を予め定義しておく。分散共分散行列の定義の仕方は、上述した相関係数行列のものと同様である。また、前処理部１０３からは、収集した稼働情報から得られる相関係数行列のほか分散共分散行列とサンプル数が入力される。外れの個数とモデルＩＤの入力は必要としない。
【００５３】
図１４の類似判定フローでは、まず、モデル情報ＤＢ１０５に定義されている既存モデルの分散共分散行列と、入力された分散共分散行列とを用いて検定が行われる（ステップＳ６２）。そして、検定の結果得られた検定統計量を所定の有意水準と比較して、検定が採択される場合には（ステップＳ６３で「Ｎｏ」）、そのモデルを類似モデルに決定する。一方、検定が棄却された場合には（ステップＳ６３で「Ｙｅｓ」）、モデルを変更し、検定を再度実行する（ステップＳ６４〜ステップＳ６１〜ステップＳ６２〜…）。モデル情報ＤＢ１０５のレコードの回数繰り返しても採択されるモデルが見つからない場合（すべてのモデルが棄却された場合）には、図１１を参照して説明した回数による類似マッチングの処理へ移行させる（ステップＳ６５）。
【００５４】
なお、ステップＳ６２およびステップＳ６３における検定処理は、次のようにして行うことができる。ここで、入力されるＰ個の稼動情報から求められるＰ×Ｐ行列である分散共分散行列とサンプル数をＳ，Ｎ、モデルの分散共分散行列とサンプル散をＳ’，Ｎ’とする。この時の差の検定は次のようにして行うことができる。
【００５５】
１．分散共分散行列とサンプル数から平方和積和行列の行列式を下式（２）にて求める。
【００５６】
【数２】
2006146668.tif 000004
【００５７】
２．モデルと入力をあわせた形で平方和穏和行列の行列式を下式（３）にて求める。
【００５８】
【数３】
2006146668.tif 000005
【００５９】
３．ウィルクスのΛ統計量を下式（４）にて求める。
【００６０】
【数４】
2006146668.tif 000006
【００６１】
４．有意水準αを定めて検定統計量Ｆ0を下式（５）にて比較して検定とする。ここで、Ｆ（Ｐ，Ｎ＋Ｎ’−Ｐ−１）（α）は自由度（Ｐ，Ｎ＋Ｎ’−Ｐ−１）のαパーセント点を意味する。
【００６２】
【数５】
2006146668.tif 000007
【００６３】
以上のようにして判断部１０６で一致または類似する稼働モデルが求められると、その結果は以下のようにして提示されたり、利用されたりする。すなわち図１のユーザインターフェース１０７は、判断部１０６から提供される情報に基づいて、表示装置１００ａあるいは表示装置２００ａを用い、Ｗｅｂブラウザや専用ビュアーのＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）によって管理者（操作者）に情報を提示する機能を提供する。
【００６４】
アラート通知部１０８は、判断部１０６から提供される情報と対応情報ＤＢ１０９に格納されている情報とに基づいて、管理者に対しては電子メールやページャ、本装置の上位に位置する統合運用管理ソフトウェアに対してはネットワークソケットなどを利用して、状態等を通知する。
【００６５】
対応アプリケーション連携部１１０は、一致する稼働モデルが求められた場合には、判断部１０６から提供される情報と対応情報ＤＢ１０９に格納されている情報とに基づいて、所定の稼働状態を判断したときにそれをトリガとして動作するアプリケーションに対してＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）を利用して指示を行う。
【００６６】
対応情報ＤＢ１０９は、アラート送信や、対応アプリケーションの情報を格納する。格納する情報は、事前に定義しておく。図１５に一例を示した。図１５に示す例において対応情報ＤＢ１０９には、対応動作テーブル１０９ａとアラート通知テーブル１０９ｂとが記憶されている。対応動作テーブル１０９ａには、対応ＩＤに対応づけて連携可能アプリケーションや動作の定義がなされている。アラート通知テーブル１０９ｂには、通知ＩＤに対応づけて管理者や他の運用管理、セキュリティ管理ツールへの通知内容の定義がなされている。これらの対応ＩＤと通知ＩＤは、図４を参照して説明したモデル情報ＤＢ１０５に定義されている対応ＩＤと通知ＩＤにそれぞれ対応している。
【００６７】
例えば現在の稼働情報が、図４のモデル情報ＤＢ１０５（モデル情報テーブル）のモデルＩＤ「００１」の稼働モデル（「ＡＰアプリ異常負荷」、対応ＩＤ「００３」、通知ＩＤ「００２」）に一致すると判断された場合には、アラート通知部１０８は、アラート通知テーブル１０９ｂ内の通知ＩＤ「００２」に設定されたあて先の電子メール（形式「××＠○○」）に状態等の通知を行う。一方、対応アプリケーション連携部１１０は、対応動作テーブル１０９ａ内の対応ＩＤ「００３」に設定された動作（「ＡＰサーバ追加」）を行うための所定の処理を行う。
【００６８】
以上に説明したように、本発明の実施の形態では、まず、監視対象となるサーバ、ネットワーク機器等から、ＣＰＵ使用率のようなハードウェア稼動情報、またＷｅｂサーバ（ＨＴＴＰ（HyperText Transfer Protocol）サーバ）であれば、アクセスの状況といったアプリケーションレベルの情報を定期的に取得するようにし、正常なアクセス時や、障害発生時といった各状況における稼動情報から、各状況を特徴付ける“取得値間の関連”を相関分析・主成分分析といった統計的手法を用いて算出し、各状況のモデルを定義してモデル情報ＤＢ１０５に保持しておく。
【００６９】
そして、運用時には、定期的に、あるいは障害のアラートや、提供サービスのレスポンス低下などをトリガとして、現在の稼働情報に対して定義したモデルと同様の統計的手法を行い、モデル情報ＤＢ１０５に定義したモデルと比較して、マッチしたモデルの状況を現在置かれている状況として識別する。これによって管理者はシステムの状況を容易に理解することが可能となり、個別コンポーネントを見ての対応ではなく、システムにより適した対応を取ることができる。また、モデル情報ＤＢ１０５に通常時の稼働モデルを定義しておくことで、いずれのモデルに対してもマッチしない場合、その状況は、通常の状況時が持つ取得値間の関連の一部が崩れたものであると考えることができる。つまり、対策が必要な異常状態ではないとしても、通常の状態から若干ずれているような状態であると考えることができる。そこで本実施の形態では、そのような場合にモデル情報ＤＢ１０５に保持しているモデルで最も類似性が高いものとその差分を提示することにした。これによって、管理者は取得値間の関連が崩れている部分に異常があるあるいは発生する可能性があることを推定することができる。
【００７０】
本実施形態によれば、従来に比べより詳細にシステムの状態を識別・提示できるので、管理者の状況判断の支援となり、システム全体を考慮に入れた形で迅速に的確な対応を取ることができ、人為ミスの低減が図れる。
【００７１】
また統計的なモデルを利用して通常の状況、障害の状況を定義することで、取得値の揺らぎや障害に近い状況に対しても、管理者に異常があることを提示することができる。例えば、Ｗｅｂアプリケーションのシステムにおいて、そのレスポンスが低下した場合は、正規のリクエスト量が多い、正常でないリクエストにより性能が低下している、Ｗｅｂサーバ、ＡＰサーバ、ＤＢサーバ、ネットワークの何処かに処理が集中している、障害が発生しているといった状況と原因が考えられる。これらのそれぞれに対する対応は異なるが、本実施の形態によれば、これらの状況の判断と原因の切り分けを支援し、運用管理コストを低減させることが可能となる。
【００７２】
なお、稼働モデルとその対応との組み合わせには、上述したもののほか、次のようなものが考えられる。「正常なアクセスで、サーバ負荷が高い。」→サーバがダウンする前にサーバを増強する。「ワームと思われるアクセスが増加している。」→帯域を使い切る前に、該当ホストからのアクセスを遮断する。「アクセス量は多くないのにサーバ負荷が高い」→サービスを継続しながら該当サーバのプロセスの異変に対応する。
【００７３】
また、上記実施の形態において、統計的分析手法として主成分分析を用いる場合には次のような構成とすることができる。すなわち、一般的に主成分分析においては、主成分（固有値）を導出すると第１主成分に総合得点、第２主成分以降に特徴をよくあらわす主成分を得ることかできる。そこで、第２主成分以降の値により、評価することにより、比較を行うようにすれば、各稼働状態の識別をより明確に行うことができると考えられる。
【００７４】
また、本発明の実施の形態は、上記のものに限定されず、例えば、図１の各構成を統合したり、分割したり、ネットワークを介して分散して配置したり、他の構成を追加したりするような変更を適宜行うことができる。例えば図１の構成で、管理サーバ１００とネットワーク１２との間にファイアウォールを追加して、管理サーバ１００に対するパケットに一定の制限を加えることなどが可能である。また、稼働モデルの作成は、実際に収集した稼働情報に基づく場合に限らず、設計によって、あるいは類似のシステムにおける稼働モデルを利用して作成することも可能である。
【００７５】
また、管理サーバ１００は、コンピュータやその周辺装置とそれらのハードウェア資源を用いて実行されるプログラムとによって構成することができるが、そのプログラムは、コンピュータ読み取り可能な記録媒体あるいは通信回線を介して配布することが可能である。
【図面の簡単な説明】
【００７６】
【図１】本発明の運用管理支援システムの一実施の形態の構成を説明するためのブロック図。
【図２】図１の稼働情報ＤＢ１０２の一例を示す構成図。
【図３】図１の前処理部１０３から出力される相関係数行列の一例を示す図。
【図４】図１のモデル情報ＤＢ１０５の一例を示す構成図。
【図５】図４のモデルデータの一例を示す構成図。
【図６】図１の前処理部１０３の処理の一例を示すフローチャート。
【図７】図６の処理を説明するための説明図。
【図８】図６の処理を説明するための説明図。
【図９】図１のモデル生成部１０４の処理（厳密なマッチング）の一例を示すフローチャート。
【図１０】図１０の処理を説明するための説明図。
【図１１】図１のモデル生成部１０４の処理（回数による類似マッチング）の一例を示すフローチャート。
【図１２】図１のモデル生成部１０４の処理（全体処理）の一例を示すフローチャート。
【図１３】図１のモデル生成部１０４の処理（全体処理）の他の例を示すフローチャート。
【図１４】図１のモデル生成部１０４の処理（検定による類似マッチング）の一例を示すフローチャート。
【図１５】図１の対応情報ＤＢ１０９の一例を示す構成図。
【符号の説明】
【００７７】
１…ネットワーク、１０…監視対象システム、１１…ファイアウォール、１２…ネットワーク、１３…ＮＩＤＳ、１４…Ｗｅｂサーバ、１５…ＡＰサーバ、１６…ＤＢサーバ、１００…管理サーバ、１０１…稼働情報収集部、１０２…稼働情報ＤＢ、１０３…前処理部（統計処理）、１０４…モデル生成部、１０５…モデル情報ＤＢ、１０６…判断部、１０７…ユーザインターフェース、１０８…アラート通知部、１０９…対応情報ＤＢ、１１０…対応アプリケーション連携部、２００…クライアント
【図１】
2006146668.tif 000008
【図２】
2006146668.tif 000009
【図３】
2006146668.tif 000010
【図４】
2006146668.tif 000011
【図５】
2006146668.tif 000012
【図６】
2006146668.tif 000013
【図７】
2006146668.tif 000014
【図８】
2006146668.tif 000015
【図９】
2006146668.tif 000016
【図１０】
2006146668.tif 000017
【図１１】
2006146668.tif 000018
【図１２】
2006146668.tif 000019
【図１３】
2006146668.tif 000020
【図１４】
2006146668.tif 000021
【図１５】
2006146668.tif 000022