説明

運用管理支援装置及び運用管理支援プログラム

【課題】システムの性能劣化状況の検知をより柔軟に行うことができ、また劣化の原因や対策を詳細に提示することができる運用管理支援装置を提供する。
【解決手段】各要素の稼動情報を所定時間毎に収集する稼働情報収集部101と、収集した稼働情報を記憶する稼働情報DB102と、記憶した各要素の稼働情報間の統計的分析値を求める前処理部103と、複数の稼動モデルに対応した各要素の稼働情報間の統計的分析値を予め記憶したモデル情報DB105と、前処理部103で求めた統計的分析値をモデル情報DB105に記憶された統計的分析値と比較することで、収集した稼働情報に対応する稼動モデルを求める判断部106とを備えている。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ネットワークシステム等のシステムの運用管理を支援するために用いて好適な運用管理支援装置及び運用管理支援プログラムに関する。
【背景技術】
【0002】
従来の運用管理では、監視対象の各サーバやネットワーク機器のハードウェア的な稼動情報や、各プログラムが動作しているかという情報を収集し、システムの構成要素ごとのアラートや稼動情報の提示を行っている。例えば、特許文献1に記載されている装置では、データベースに事前定義された一定範囲の条件を満たす運用状況が発生したときにアラートを発するようにしている。また、この装置では、収集した情報に基づいて性能劣化の到達予想を直線・曲線近似によって提示できるようになっている。ただし、この装置では、定義外の異常障害は基本的に考慮されていない。すなわち、監視対象の各構成要素の稼動情報に対して一定の値の範囲を予め定義し、その範囲に入るかまたは外れるかということを検出することで性能劣化状態が判定されるようになっていた。また、この装置では、検知した結果に基づいて予め定義されているものに関して、相関分析によって原因を絞り込み、対応する対策が表示されるようになっていた。
【0003】
一方、特許文献2に記載されている装置では、正常動作からの外れ値を検知することで、性能劣化が判定されるようになっている。測定値から導かれる制御量(を基にしたデータ)と動作を行う操作量(を基にしたデータ)の相関を取り、検定を行うことで、性能劣化状態を検知している。ただし、各構成要素のデータは取得していないので、性能劣化の原因や対策を判断することはできなかった。
【特許文献1】特開2004−145536号公報
【特許文献2】特開2003−208219号公報
【発明の開示】
【発明が解決しようとする課題】
【0004】
システムに障害が発生したときには、管理者がシステムの構成要素ごとのアラートや稼動情報から、システムの状況を推定・想像したり、あらかじめ定義したマニュアルに従って対応を行う。前者は、管理者のスキルに依存する部分が大きいため、障害、性能低下の改善に時間を要したり、人為的なミスによる2次被害の可能性があったりする。後者は条件の定義が厳密であるため、取得値が定義には含まれないが危険な兆候である場合などのケースでは、対応がとれなかったり、誤った対応を行ってしまったりするという問題点がある。
【0005】
特許文献1に記載されている装置では、劣化の数値範囲・原因・対策が事前定義され、その範囲内において検出と対策を示すことができ、また、範囲外となる場合には、数値を直線・曲線で予測するのみで各構成要素の関連性などは考慮されていなかった。そのため、事前定義外の状況には対応しきれない場合が発生すると考えられる。
【0006】
また、特許文献2に記載の装置では、正常動作の状態を以前のデータから生成し、比較することで異常を検出する。すなわち“異常”の検出までを目的とするものあって、何処がおかしいかまでは、提示することができなかった。
【0007】
本発明は、上記の事情を考慮してなされたものであって、性能劣化状況の検知をより柔軟に行うことができ、また劣化の原因や対策を詳細に提示することができる運用管理支援装置を提供することを目的とする。
【課題を解決するための手段】
【0008】
上記課題を解決するため、請求項1記載の発明は、3以上の要素の稼動情報を所定時間毎に収集する稼働情報収集手段と、稼働情報収集手段で収集した稼働情報を記憶する稼働情報記憶手段と、記憶した各要素の稼働情報間の統計的分析値を求める統計処理手段と、複数の稼動モデルに対応した各要素の稼働情報間の統計的分析値を予め記憶したモデル情報記憶手段と、統計処理手段で求めた統計的分析値をモデル情報記憶手段に記憶された統計的分析値と比較することで、収集した稼働情報に対応する稼動モデルを求める判断部とを備えることを特徴とする。
【0009】
請求項2記載の発明は、前記判断部が、比較結果が一致した稼働モデルを求め、比較結果が一致しなかった場合には類似する稼働モデルを求めることを特徴とする。
【0010】
請求項3記載の発明は、前記判断部が、検定によって類似する稼働モデルを求め、検定によって類似する稼働モデルが求められない場合に比較結果が不一致となった統計的分析値の個数に基づいて類似する稼働モデルを求めることを特徴とする。
【0011】
請求項4記載の発明は、前記判断部によって稼働モデルが求められた場合に所定の通知先にその旨を通知する通知手段と、前記判断部によって稼働モデルが求められた場合に所定のアプリケーションを実行する対応アプリケーション連携手段とをさらに備えることを特徴とする。
【0012】
請求項5記載の発明は、前記対応アプリケーション連携手段が、求められたモデルが類似する稼働モデルである場合には所定のアプリケーションを実行しないことを特徴とする。
【0013】
請求項6記載の発明は、前記統計的分析値が、相関係数であることを特徴とする。
【0014】
請求項7記載の発明は、前記統計的分析値が、主成分分析結果であることを特徴とする。
【0015】
請求項8記載の発明は、前記稼働情報が、ハードウェア稼動情報及びアプリケーション稼動情報の両者を含むことを特徴とする。
【0016】
請求項9記載の発明は、前記モデル情報記憶手段に記憶された稼働モデルが、各要素を稼働させた状態で実際に収集された稼働情報に基づいて作成されたものであることを特徴とする。
【0017】
請求項10記載の発明は、3以上の要素の稼動情報を所定時間毎に収集する稼働情報収集段階と、稼働情報収集段階で収集した稼働情報を記憶する稼働情報記憶段階と、記憶した各要素の稼働情報間の統計的分析値を求める統計処理段階と、複数の稼動モデルに対応した各要素の稼働情報間の統計的分析値を予め記憶したモデル情報記憶手段を用いて、統計処理段階で求めた統計的分析値をモデル情報記憶手段に記憶された統計的分析値と比較することで、収集した稼働情報に対応する稼動モデルを求める判断段階とをコンピュータを用いて実行するための記述を含むことを特徴とする。
【発明の効果】
【0018】
請求項1記載の発明では、各要素の稼働情報に対して一定の検出範囲を設定するのではなく、複数の要素の稼働情報間の統計的分析値(例えば相関係数、主成分分析結果等)と、予め定義した複数の稼働モデルに対応した統計的分析値とを比較することで、対応する稼働モデルを求めるようにしている。すなわち、統計的な稼働モデルを利用して通常の状況や障害の状況を定義し、各要素の稼働状態間の統計的分析値に基づき、いずれの稼働モデルに一致あるいは類似するかということを判断することで、通常の状況や性能劣化等の障害の状況を提示することができる。したがって、性能劣化状況の検知をより柔軟に行うことができる。また各要素の稼働情報を収集しているので、劣化の原因や対策を詳細に提示することができる。
【0019】
また、請求項2記載の発明によれば、前記判断部が、比較結果が一致した稼働モデルを求め、比較結果が一致しなかった場合には類似する稼働モデルを求めるので、性能劣化状況の検知をより柔軟に行うことができる。
【0020】
請求項3記載の発明によれば、前記判断部が、検定によって類似する稼働モデルを求め、検定によって類似する稼働モデルが求められない場合に比較結果が不一致となった統計的分析値の個数に基づいて類似する稼働モデルを求めるので、類似モデルを求める処理の精度を向上させることができる。
【0021】
請求項4記載の発明によれば、前記判断部によって稼働モデルが求められた場合に所定の通知先にその旨を通知する通知手段と、前記判断部によって稼働モデルが求められた場合に所定のアプリケーションを実行する対応アプリケーション連携手段とをさらに備えたので、所定の対応や通知を自動的に行うことができる。
【0022】
請求項5記載の発明によれば、前記対応アプリケーション連携手段が、求められたモデルが類似する稼働モデルである場合には所定のアプリケーションを実行しないようにしたので、予期しない稼働状態によって誤った類似モデルが検知されたような場合に誤った対応策が自動的に実施されないようにすることができる。
【0023】
請求項6記載の発明によれば、前記統計的分析値が相関係数なので、各要素の2個の稼働情報間に稼働状況に応じて相関が十分認められる場合に、稼働状況の識別精度を向上させることができる。
【0024】
請求項7記載の発明によれば、前記統計的分析値は主成分分析結果あり、相関係数行列が2変数の相関を行列にしたものであるのに対し主成分分析はn変数の場合にはn個の特性より定まるため、主成分分析結果に特徴が十分認められる場合に、稼働状況の識別精度を向上させることができる。
【0025】
請求項8記載の発明によれば、前記稼働情報が、ハードウェア稼動情報及びアプリケーション稼動情報の両者を含むので、より詳細に原因を特定することができる。
【0026】
請求項9記載の発明によれば、前記モデル情報記憶手段に記憶された稼働モデルが、各要素を稼働させた状態で実際に収集された稼働情報に基づいて作成されたものであるので、基準とする稼働モデルを実システムにより一致したものにしやすくなる。
【発明を実施するための最良の形態】
【0027】
以下、図面を参照して本発明による運用管理支援装置の実施の形態について説明する。図1は、本発明による運用管理支援装置の実施の形態の構成を示すシステム図である。図1では、インターネット等のネットワーク1に対して通信回線2を介して監視対象システム10が接続され、さらに監視対象システム10に対して本実施の形態の運用監視装置としての管理サーバ100が接続されている。管理サーバ100は、監視対象システム10の稼働状態を監視し、ハードウェア的な稼動情報や、各プログラムが動作しているかという稼働情報を収集し、自装置の表示装置100aやクライアント端末200の表示装置200aを用いて、システムの構成要素ごとのアラートや稼動情報の提示を行う。
【0028】
監視対象システム10は、ネットワーク1に対して各種通信サービスを提供するものであって、ファイアウォール11、各装置間を接続するネットワーク12、NIDS(Network Intrusion Detection System;ネットワーク型不正侵入検知システム)13、Webサーバ14、AP(APplication)サーバ15、およびDB(DataBase)サーバ16から構成されている。ファイアウォール11は、ネットワーク12に対するネットワーク1からの不正なアクセスを制限する。NIDS13は、ネットワーク12への侵入を検知するシステムであり、ファイアウォール11が発見できない攻撃を認識することができる。Webサーバ14は、ネットワーク1を介してWebブラウザ等で閲覧されるコンテンツを提供するためのコンピュータである。APサーバ15は、ネットワーク1を介したWebブラウザ等からの要求に応じて所定のアプリケーションプログラムを実行するためのコンピュータであり、例えばWebサーバ14とDBサーバ16の中間に位置して所定の処理を行う。そして、DBサーバ16は、複数のデータ、ファイル等の情報を蓄積、整理し、ネットワーク1を介したWebブラウザ等からの要求に応じて所定の情報を提供するためのコンピュータである。
【0029】
監視対象システム10を構成する各装置11、13〜16は、それぞれ、本実施の形態における監視対象の構成要素の1または複数を有するものである。各装置は、CPU(Central Processing Unit)の使用率、DBクエリ数(検索数)、アクセス数、エラーログ記録数、アクセスログ記録数、送出パケット数、NIDSアラート数等の稼働情報の1または複数を、管理サーバ100の要求に応じて、あるいは自発的に、管理サーバ100に対して送信する。これらの稼働情報は、ネットワーク12を介して、ICMP(Internet Control Message Protocol)、SNMP(Simple Network Management Protocol)等のプロトコルや、rsh(remote shell)を用いて転送される。
【0030】
管理サーバ100は、所定のOS(Operating System)上でそのハードウェア資源を利用して所定のプログラム実行することで運用監視装置としての機能を提供するコンピュータである。図1では、管理サーバ100内にソフトウェアとハードウェアと一方または組み合わせから構成されている各機能をブロックに分けて示している。この場合、管理サーバ100は、稼働情報収集部101、稼働情報DB102、前処理部103、モデル生成部104、モデル情報DB105、判断部106、ユーザインターフェース107、アラート通知部108、対応情報DB109、および対応アプリケーション連携部110を備えている。
【0031】
稼働情報収集部101は、監視対象システム10内の複数の装置11、13〜16(3個以上の構成要素)から、ICMP、SNMP、rshなどを利用して、CPU、Network IO(ネットワークInput/Output)などのハードウェア稼動情報、Webサーバのアクセス量、DBサーバの処理クエリ量などのアプリケーション稼動情報を一定時間間隔で取得し、稼動情報DB102に保存する。稼働情報DB102は、稼動情報収集部101が取得したデータ(稼働情報)をタイムスタンプをキーとして保存する。
【0032】
図2は稼働情報DB102に格納されるデータの一例を示す図である。図2に示す例では、それぞれ1分間隔で収集した、サーバ1(例えばWebサーバ14)のCPU使用率、サーバ2(例えばAPサーバ15)のCPU使用率、DBクエリ数(DBサーバ16における検索数に対応)、アクセス処理数(例えばWebサーバ14の所定の機能による処理数)が記録されている。
【0033】
前処理部103は、モデル生成部104または判断部106で使用するデータの前処理(統計処理)を行う。前処理部103は、稼働情報DB102に格納されている各構成要素の稼働情報間の統計的分析値を求める統計処理を行う。前処理部103は、例えば、稼働情報DB102に格納されている各装置11、12〜16から取得した稼働情報に対して、各稼働情報間の相関係数を求めたり、各稼働情報間で主成分分析を行ったりして、統計的分析値を求める。この統計的分析値は、所定時刻における各装置の稼働情報間の関連度を示す値となっている。図3に前処理部103の処理結果の一例を示す。
【0034】
図3は、図2に示す稼働情報に対して、相関係数を求める処理を行った結果を示すものであり、処理結果が相関係数行列として求められていることを示している。図3に示す例では、サーバ1のCPU使用率とサーバ2のCPU使用率との相関係数が「0.93」、サーバ1のCPU使用率とDBクエリ数との相関係数が「0.75」、サーバ2のCPU使用率とDBクエリ数との相関係数が「0.89」等となっている。
【0035】
相関関数は、2次元のデータにおける変量間の関係をある1つ係数で表現する手法であり、相関係数は、2つの変量間の相関関係の程度を表す数値である。いま、ある集合(xi, yi)、xi∈X、yi∈Yという2次元データ集合が存在した場合、下式(1)で、相関係数RXYは−1≦RXY≦1の範囲で与えられる。
【0036】
【数1】

【0037】
なお、相関係数の値(RXYの絶対値|RXY|)については一般的に次の特性が認められている。|RXY|≦0.2…ほとんど相関がなく、0.2≦|RXY|≦0.4…弱い相関があり、0.4≦|RXY|≦0.7…中程度の相関があり、そして、0.7≦|RXY|…高い相関がある。
【0038】
図1のモデル生成部104は、本装置で基準(標準)となる複数の稼働モデルを定義してモデル情報DB105に登録したり、追加したりするための動作を行う。各稼働モデルは、意図的に障害を発生させるなどして所望の状態を作り出し、稼働情報収集部101で各構成要素から稼働情報を実際に収集することで作成することができる。ここで、各稼働モデルは、正常状態、正常状態で比較的アクセスが増大した状態、APアプリ(アプリケーション)異常負荷時状態、APサーバ障害状態、エラーアクセス増大、ハードディスク・エラー多発状態等の稼働状態を所定の形式で表したものであり、各構成要素の稼働情報間の統計的分析値を用いて定義される。図4および図5にモデル情報DB105の登録情報(モデル情報テーブル)の一例を示した。
【0039】
図4に示す例では、複数の稼働モデルに対応させて(この場合、APアプリ異常負荷、エラーアクセス増大の2つの稼働モデルに対応させて)、モデルID(Identification)、対応ID、通知ID、モデルデータによってモデル情報テーブルの各レコードが構成されている。モデルIDは各稼働モデルの識別情報であり、対応IDはその状態が発生した場合に取るべき対応を特定する情報であり、通知IDはその状態が発生した場合に通知すべきアラート通知先等の内容を特定する情報であり、モデルデータはその状態で取得された構成要素の稼働情報間の統計的分析値である。対応IDと通知IDに対応する具体的内容は、図1の対応情報DB109に記憶されている。モデルデータは、例えば相関係数を統計的分析値として用いる場合には、図5に示すような各構成要素の稼働情報間の各相関係数からなる相関係数行列となる。この各モデルの定義データは、実際のデータと比較処理を行う際に比較基準値の中央値として用いられ、所定の幅を持たせた上で各データ間の比較が行われるようになっている。すなわち、中央値を基準として所定の幅を持たせた値が各モデルの定義データとなる。ただし、本実施の形態では、複数のモデル間の自他識別性を向上させるため、モデル情報DB105に登録される各定義データに対しては次のような中央値の変更処理を予め行うようにしている。
【0040】
図5は、モデル情報DB105に登録される相関係数行列の一例を示す図であり、図3に示す前処理部103で作成された相関係数行列に対して、モデル生成部104によって中央値の変更処理を行ったものである。中央値の変更処理は、先に登録された他のモデルと、相関係数行列の各要素が同一あるいは非常に近い値とならないようにするためのものである。図6を参照して、この中央値変更処理について説明する。
【0041】
図6は、モデル生成部104による中央値変更処理を含むモデル追加処理の流れを示すフローチャートである。入力データは、前処理が行われた中間データ(図3参照)、コメント、対応ID、通知IDである(コメント、対応ID、通知IDは、モデル作成者が与える。ただし、対応ID、通知IDは少なくとも一方があればよい)。データの置き換え処理(ステップS11)では、入力(インプット)されたデータを事前に定義されたレンジ幅の(○○〜○○)の中央値の形式に置き換える処理を行う。インプットのデータが、そのレンジに入っていれば変更可能であるとする。すなわち、インプットデータが0.65であり、レンジ幅が0.2であれば、0.55〜0.75の範囲で中央値を設定できるとしている(図7参照)。ただし、レンジ幅はチューニングパラメータとして、モデル毎に変更可能とすることができる。初期値はインプットの値を使用する。
【0042】
事前の限度回数Nを超えていない場合には(ステップS12で「No」)、既存モデルとの比較を行う(ステップS14)。既存モデルとの比較は、すでに存在するモデルとすべての要素にレンジの重複がある場合には両方のモデルの状況と判断されてしまうのでそのようなモデルを登録しないようにするためのチェック作業である。明確な差がある場合には(ステップS15で「Yes」)、モデル情報DB105のすでに登録されているレコード分の回数、比較対象の既存モデルを変化させながらステップS14の処理を繰り返し行う(ステップS16〜ステップS13〜ステップS14〜ステップS15〜ステップS16〜…)。ステップS15では、例えば図8に示すように、既存モデルのレンジと、今回のインプットデータのレンジとの重複部分(矢印太線)が所定の値以下であるかどうかを確認し、所定の値以下である場合に明確な差があると判定する。
【0043】
一方、明確な差が無い場合には(ステップS15で「No」)、重複が少ない部分を走査する(ステップS18)。ステップS18では、差がないと判断された要素についてレンジ間の重なりが少ない部分をリストアップして、データの置き換え候補として、ステップS11のデータの置き換え処理に渡される。ステップS11では置き換え候補に基づいて中央値を変更する処理を行う。
【0044】
以上のようにして、すべての既存モデルと明確な差がある状態となったところで、今回のインプットデータがモデル情報DB105に追加される(ステップS17)。また、コメント、対応ID、通知IDもセットされる。ただし、ステップS11のデータの置き換え処理が所定の限界回数Nを超えた場合には、処理不能として、エラー処理へと引き継がれる(ステップS12で「Yes」)。
【0045】
以上の構成および処理によって、モデル情報DB15に稼働モデルが定義される。次に、図1を参照して、定義した稼働モデルを利用した監視処理について説明する。
【0046】
図1の判断部106は、定義されている稼働モデルと未知のデータ(新たに収集した稼働情報)との判断を行う。この判断部106は、モデル生成部104と排他的に動作する。つまり、稼働情報収集部101によって収集され、稼働情報DB102に記憶された監視対象システム10の稼働情報は、前処理部103によって統計処理された後、判断部106へ入力される。判断部106は、前処理部103で求めた統計的分析値を、モデル情報DB105に記憶された統計的分析値と比較することで、収集した稼働情報に対応する稼動モデルを求める判断を実行する。なお、本実施の形態では、まず、厳密に一致するモデルを探索し、厳密に一致するモデルが見つからない場合には、類似するモデルを探索する処理を行うようにしている。判断部106は、定期的に、あるいは障害のアラートや、提供サービスのレスポンス低下などをトリガとしてこれらの処理を行う。
【0047】
図9を参照して判断部106による処理について説明する。入力データは、例えば統計的分析値が相関係数であるとすれば図3に示すような前処理が行われた中間データとなる。まず、新たな処理の開始に際してレンジ外の要素の個数を記憶する記憶領域(ステップS25参照)が初期化される。ステップS22では、既存モデルとの比較処理が行われる。既存モデルとの比較処理では、前処理が行われた中間データの各要素(相関係数行列の各要素)がモデルのレンジに入るかが計算される。例えば今回の比較対象データと、あるモデル(今回選択中のモデル情報DB105のレコードに含まれる各要素のレンジ)を比較した結果が、図10に示すようになった場合(太線で示すレンジ内に今回の要素が含まれる場合)、この要素についてはOK(レンジに入っている)とされる。これを要素の個数回繰り返し行い、中間データの全要素について既存モデルの対応する要素との比較を行う。
【0048】
次に、すべての要素がそのモデルのレンジに入っているかを判定し(ステップS23)、入っている場合には(ステップS23で「Yes」)、現在の稼働状態がそのモデルの状態であると推定する。そして、コメント、対応ID、通知IDを、図1のユーザインターフェース107、アラート通知部108、対応アプリケーション連携部110に出力し、終了する。
【0049】
一方、レンジから外れる要素があった場合には(ステップS23で「No」)、外れた個数が他のモデルに対して記録されているものより少ないかを判定し、少ない場合には(ステップS24で「Yes」)、外れた個数とモデルIDを所定の記憶領域に記録する(ステップS25)。ステップS22以降の処理を、モデル情報DB105に定義されている各レコード(各モデル)に対して実行する。その際、すべての要素がレンジに入るモデルがあれば処理を終了するが(ステップS23で「Yes」の場合)、すべての要素がレンジに入るモデルが無い場合には、記録している外れの個数が最も少ないモデルのIDと個数を引数として、類似マッチングフローへと処理を進める(ステップS27)。
【0050】
図11は、類似マッチングフローの一例を示すフローチャートである。入力データは、前処理が行われた中間データ(図3参照)と、図10のステップS25で記録された外れの個数が最も少ないモデルIDである。この場合、モデルの再探索は行われず、入力されたモデルIDで指定されるモデルが類似するモデルとして出力される。ただし、その際、再度比較を行い(ステップS31)、外れた要素をリストアップして(ステップS32)、類似であることのフラグ、コメント、通知IDを、ユーザインターフェース107およびアラート通知部108に出力し、処理を終了する。ただし、一致ではなく類似であるので、対応アプリケーション連携は行わない。
【0051】
上記で図10および図11を参照して説明した判断部フローの流れでは、図12に示すように、基本的には厳密なマッチング(ステップS41)を行い、厳密なマッチングができない場合に回数による類似マッチング(ステップS42)を行うこととしている。これに対し、検定を用いる類似マッチングを追加して、精度向上を図ることも可能である。すなわち、図13に示すように、まず、厳密なマッチングを行い(ステップS51)、厳密なマッチングができない場合に検定を用いるマッチングを行い(ステップS52)、そして、検定を用いるマッチングで所定条件を満たすモデルが得られない場合に回数による類似マッチングを行うようにする(ステップS53)ことも可能である。
【0052】
図14は、図1の判断部106で検定によるマッチング(類似マッチング追加例)を行う場合の処理の一例を示すフローチャートである。この場合、前提として、モデル情報DB105のモデルデータには、相関係数行列に加え、分散共分散行列とサンプル数を予め定義しておく。分散共分散行列の定義の仕方は、上述した相関係数行列のものと同様である。また、前処理部103からは、収集した稼働情報から得られる相関係数行列のほか分散共分散行列とサンプル数が入力される。外れの個数とモデルIDの入力は必要としない。
【0053】
図14の類似判定フローでは、まず、モデル情報DB105に定義されている既存モデルの分散共分散行列と、入力された分散共分散行列とを用いて検定が行われる(ステップS62)。そして、検定の結果得られた検定統計量を所定の有意水準と比較して、検定が採択される場合には(ステップS63で「No」)、そのモデルを類似モデルに決定する。一方、検定が棄却された場合には(ステップS63で「Yes」)、モデルを変更し、検定を再度実行する(ステップS64〜ステップS61〜ステップS62〜…)。モデル情報DB105のレコードの回数繰り返しても採択されるモデルが見つからない場合(すべてのモデルが棄却された場合)には、図11を参照して説明した回数による類似マッチングの処理へ移行させる(ステップS65)。
【0054】
なお、ステップS62およびステップS63における検定処理は、次のようにして行うことができる。ここで、入力されるP個の稼動情報から求められるP×P行列である分散共分散行列とサンプル数をS,N、モデルの分散共分散行列とサンプル散をS’,N’とする。この時の差の検定は次のようにして行うことができる。
【0055】
1.分散共分散行列とサンプル数から平方和積和行列の行列式を下式(2)にて求める。
【0056】
【数2】

【0057】
2.モデルと入力をあわせた形で平方和穏和行列の行列式を下式(3)にて求める。
【0058】
【数3】

【0059】
3.ウィルクスのΛ統計量を下式(4)にて求める。
【0060】
【数4】

【0061】
4.有意水準αを定めて検定統計量F0を下式(5)にて比較して検定とする。ここで、F(P,N+N’−P−1)(α)は自由度(P,N+N’−P−1)のαパーセント点を意味する。
【0062】
【数5】

【0063】
以上のようにして判断部106で一致または類似する稼働モデルが求められると、その結果は以下のようにして提示されたり、利用されたりする。すなわち図1のユーザインターフェース107は、判断部106から提供される情報に基づいて、表示装置100aあるいは表示装置200aを用い、Webブラウザや専用ビュアーのGUI(Graphical User Interface)によって管理者(操作者)に情報を提示する機能を提供する。
【0064】
アラート通知部108は、判断部106から提供される情報と対応情報DB109に格納されている情報とに基づいて、管理者に対しては電子メールやページャ、本装置の上位に位置する統合運用管理ソフトウェアに対してはネットワークソケットなどを利用して、状態等を通知する。
【0065】
対応アプリケーション連携部110は、一致する稼働モデルが求められた場合には、判断部106から提供される情報と対応情報DB109に格納されている情報とに基づいて、所定の稼働状態を判断したときにそれをトリガとして動作するアプリケーションに対してAPI(Application Program Interface)を利用して指示を行う。
【0066】
対応情報DB109は、アラート送信や、対応アプリケーションの情報を格納する。格納する情報は、事前に定義しておく。図15に一例を示した。図15に示す例において対応情報DB109には、対応動作テーブル109aとアラート通知テーブル109bとが記憶されている。対応動作テーブル109aには、対応IDに対応づけて連携可能アプリケーションや動作の定義がなされている。アラート通知テーブル109bには、通知IDに対応づけて管理者や他の運用管理、セキュリティ管理ツールへの通知内容の定義がなされている。これらの対応IDと通知IDは、図4を参照して説明したモデル情報DB105に定義されている対応IDと通知IDにそれぞれ対応している。
【0067】
例えば現在の稼働情報が、図4のモデル情報DB105(モデル情報テーブル)のモデルID「001」の稼働モデル(「APアプリ異常負荷」、対応ID「003」、通知ID「002」)に一致すると判断された場合には、アラート通知部108は、アラート通知テーブル109b内の通知ID「002」に設定されたあて先の電子メール(形式「××@○○」)に状態等の通知を行う。一方、対応アプリケーション連携部110は、対応動作テーブル109a内の対応ID「003」に設定された動作(「APサーバ追加」)を行うための所定の処理を行う。
【0068】
以上に説明したように、本発明の実施の形態では、まず、監視対象となるサーバ、ネットワーク機器等から、CPU使用率のようなハードウェア稼動情報、またWebサーバ(HTTP(HyperText Transfer Protocol)サーバ)であれば、アクセスの状況といったアプリケーションレベルの情報を定期的に取得するようにし、正常なアクセス時や、障害発生時といった各状況における稼動情報から、各状況を特徴付ける“取得値間の関連”を相関分析・主成分分析といった統計的手法を用いて算出し、各状況のモデルを定義してモデル情報DB105に保持しておく。
【0069】
そして、運用時には、定期的に、あるいは障害のアラートや、提供サービスのレスポンス低下などをトリガとして、現在の稼働情報に対して定義したモデルと同様の統計的手法を行い、モデル情報DB105に定義したモデルと比較して、マッチしたモデルの状況を現在置かれている状況として識別する。これによって管理者はシステムの状況を容易に理解することが可能となり、個別コンポーネントを見ての対応ではなく、システムにより適した対応を取ることができる。また、モデル情報DB105に通常時の稼働モデルを定義しておくことで、いずれのモデルに対してもマッチしない場合、その状況は、通常の状況時が持つ取得値間の関連の一部が崩れたものであると考えることができる。つまり、対策が必要な異常状態ではないとしても、通常の状態から若干ずれているような状態であると考えることができる。そこで本実施の形態では、そのような場合にモデル情報DB105に保持しているモデルで最も類似性が高いものとその差分を提示することにした。これによって、管理者は取得値間の関連が崩れている部分に異常があるあるいは発生する可能性があることを推定することができる。
【0070】
本実施形態によれば、従来に比べより詳細にシステムの状態を識別・提示できるので、管理者の状況判断の支援となり、システム全体を考慮に入れた形で迅速に的確な対応を取ることができ、人為ミスの低減が図れる。
【0071】
また統計的なモデルを利用して通常の状況、障害の状況を定義することで、取得値の揺らぎや障害に近い状況に対しても、管理者に異常があることを提示することができる。例えば、Webアプリケーションのシステムにおいて、そのレスポンスが低下した場合は、正規のリクエスト量が多い、正常でないリクエストにより性能が低下している、Webサーバ、APサーバ、DBサーバ、ネットワークの何処かに処理が集中している、障害が発生しているといった状況と原因が考えられる。これらのそれぞれに対する対応は異なるが、本実施の形態によれば、これらの状況の判断と原因の切り分けを支援し、運用管理コストを低減させることが可能となる。
【0072】
なお、稼働モデルとその対応との組み合わせには、上述したもののほか、次のようなものが考えられる。「正常なアクセスで、サーバ負荷が高い。」→サーバがダウンする前にサーバを増強する。「ワームと思われるアクセスが増加している。」→帯域を使い切る前に、該当ホストからのアクセスを遮断する。「アクセス量は多くないのにサーバ負荷が高い」→サービスを継続しながら該当サーバのプロセスの異変に対応する。
【0073】
また、上記実施の形態において、統計的分析手法として主成分分析を用いる場合には次のような構成とすることができる。すなわち、一般的に主成分分析においては、主成分(固有値)を導出すると第1主成分に総合得点、第2主成分以降に特徴をよくあらわす主成分を得ることかできる。そこで、第2主成分以降の値により、評価することにより、比較を行うようにすれば、各稼働状態の識別をより明確に行うことができると考えられる。
【0074】
また、本発明の実施の形態は、上記のものに限定されず、例えば、図1の各構成を統合したり、分割したり、ネットワークを介して分散して配置したり、他の構成を追加したりするような変更を適宜行うことができる。例えば図1の構成で、管理サーバ100とネットワーク12との間にファイアウォールを追加して、管理サーバ100に対するパケットに一定の制限を加えることなどが可能である。また、稼働モデルの作成は、実際に収集した稼働情報に基づく場合に限らず、設計によって、あるいは類似のシステムにおける稼働モデルを利用して作成することも可能である。
【0075】
また、管理サーバ100は、コンピュータやその周辺装置とそれらのハードウェア資源を用いて実行されるプログラムとによって構成することができるが、そのプログラムは、コンピュータ読み取り可能な記録媒体あるいは通信回線を介して配布することが可能である。
【図面の簡単な説明】
【0076】
【図1】本発明の運用管理支援システムの一実施の形態の構成を説明するためのブロック図。
【図2】図1の稼働情報DB102の一例を示す構成図。
【図3】図1の前処理部103から出力される相関係数行列の一例を示す図。
【図4】図1のモデル情報DB105の一例を示す構成図。
【図5】図4のモデルデータの一例を示す構成図。
【図6】図1の前処理部103の処理の一例を示すフローチャート。
【図7】図6の処理を説明するための説明図。
【図8】図6の処理を説明するための説明図。
【図9】図1のモデル生成部104の処理(厳密なマッチング)の一例を示すフローチャート。
【図10】図10の処理を説明するための説明図。
【図11】図1のモデル生成部104の処理(回数による類似マッチング)の一例を示すフローチャート。
【図12】図1のモデル生成部104の処理(全体処理)の一例を示すフローチャート。
【図13】図1のモデル生成部104の処理(全体処理)の他の例を示すフローチャート。
【図14】図1のモデル生成部104の処理(検定による類似マッチング)の一例を示すフローチャート。
【図15】図1の対応情報DB109の一例を示す構成図。
【符号の説明】
【0077】
1…ネットワーク、10…監視対象システム、11…ファイアウォール、12…ネットワーク、13…NIDS、14…Webサーバ、15…APサーバ、16…DBサーバ、100…管理サーバ、101…稼働情報収集部、102…稼働情報DB、103…前処理部(統計処理)、104…モデル生成部、105…モデル情報DB、106…判断部、107…ユーザインターフェース、108…アラート通知部、109…対応情報DB、110…対応アプリケーション連携部、200…クライアント

【特許請求の範囲】
【請求項1】
3以上の要素の稼動情報を所定時間毎に収集する稼働情報収集手段と、
稼働情報収集手段で収集した稼働情報を記憶する稼働情報記憶手段と、
記憶した各要素の稼働情報間の統計的分析値を求める統計処理手段と、
複数の稼動モデルに対応した各要素の稼働情報間の統計的分析値を予め記憶したモデル情報記憶手段と、
統計処理手段で求めた統計的分析値をモデル情報記憶手段に記憶された統計的分析値と比較することで、収集した稼働情報に対応する稼動モデルを求める判断部と
を備えることを特徴とする運用管理支援装置。
【請求項2】
前記判断部が、比較結果が一致した稼働モデルを求め、比較結果が一致しなかった場合には類似する稼働モデルを求める
ことを特徴とする請求項1記載の運用管理支援装置。
【請求項3】
前記判断部が、検定によって類似する稼働モデルを求め、検定によって類似する稼働モデルが求められない場合に比較結果が不一致となった統計的分析値の個数に基づいて類似する稼働モデルを求める
ことを特徴とする請求項2記載の運用管理支援装置。
【請求項4】
前記判断部によって稼働モデルが求められた場合に所定の通知先にその旨を通知する通知手段と、
前記判断部によって稼働モデルが求められた場合に所定のアプリケーションを実行する対応アプリケーション連携手段と
をさらに備えることを特徴とする請求項1〜3のいずれか1項に記載の運用管理支援装置。
【請求項5】
前記対応アプリケーション連携手段が、求められたモデルが類似する稼働モデルである場合には所定のアプリケーションを実行しない
ことを特徴とする請求項4記載の運用管理支援装置。
【請求項6】
前記統計的分析値が、相関係数であることを特徴とする請求項1〜5のいずれか1項に記載の運用管理支援装置。
【請求項7】
前記統計的分析値が、主成分分析結果であることを特徴とする請求項1〜5のいずれか1項に記載の運用管理支援装置。
【請求項8】
前記稼働情報が、ハードウェア稼動情報及びアプリケーション稼動情報の両者を含むことを特徴とする請求項1〜7のいずれか1項に記載の運用管理支援装置。
【請求項9】
前記モデル情報記憶手段に記憶された稼働モデルが、各要素を稼働させた状態で実際に収集された稼働情報に基づいて作成されたものであることを特徴とする請求項1〜8のいずれか1項に記載の運用管理支援装置。
【請求項10】
3以上の要素の稼動情報を所定時間毎に収集する稼働情報収集段階と、
稼働情報収集段階で収集した稼働情報を記憶する稼働情報記憶段階と、
記憶した各要素の稼働情報間の統計的分析値を求める統計処理段階と、
複数の稼動モデルに対応した各要素の稼働情報間の統計的分析値を予め記憶したモデル情報記憶手段を用いて、統計処理段階で求めた統計的分析値をモデル情報記憶手段に記憶された統計的分析値と比較することで、収集した稼働情報に対応する稼動モデルを求める判断段階と
をコンピュータを用いて実行するための記述を含むことを特徴とする運用管理支援プログラム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12】
image rotate

【図13】
image rotate

【図14】
image rotate

【図15】
image rotate


【公開番号】特開2006−146668(P2006−146668A)
【公開日】平成18年6月8日(2006.6.8)
【国際特許分類】
【出願番号】特願2004−337411(P2004−337411)
【出願日】平成16年11月22日(2004.11.22)
【出願人】(000102728)株式会社エヌ・ティ・ティ・データ (438)
【Fターム(参考)】