JP5267684B2 - 運用管理装置、運用管理方法、及びプログラム記憶媒体 - Google Patents
運用管理装置、運用管理方法、及びプログラム記憶媒体 Download PDFInfo
- Publication number
- JP5267684B2 JP5267684B2 JP2011548953A JP2011548953A JP5267684B2 JP 5267684 B2 JP5267684 B2 JP 5267684B2 JP 2011548953 A JP2011548953 A JP 2011548953A JP 2011548953 A JP2011548953 A JP 2011548953A JP 5267684 B2 JP5267684 B2 JP 5267684B2
- Authority
- JP
- Japan
- Prior art keywords
- performance
- monitored
- abnormal
- operation management
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/079—Root cause analysis, i.e. error or fault diagnosis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3466—Performance evaluation by tracing or monitoring
- G06F11/3495—Performance evaluation by tracing or monitoring for systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/81—Threshold
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Health & Medical Sciences (AREA)
- Biomedical Technology (AREA)
- Computer Hardware Design (AREA)
- Debugging And Monitoring (AREA)
Description
本発明は、システムの稼働情報を監視する運用管理装置、運用管理方法、及びプログラム記憶媒体に関する。
データセンタ等に設置された多数のサーバやネットワーク機器で構成される情報システムの技術分野において、ＷＥＢサービスや業務サービスなど、システムが提供するサービスの社会インフラとしての重要性が高まっている。このため、それらのサービスを管理する各サーバの安定稼働が不可欠になっている。このようなシステムを管理する技術として、複数のサーバの稼働状況を一元的に監視し、障害の発生を検出する統合管理システムが知られている。
この統合管理システムとしては、例えば、監視対象となる複数のサーバから稼働状況に関する実測データをオンラインで取得し、この実測データが閾値を越えた場合に異常を検出するシステムが広く知られている。しかしながら、このシステムでは、異常が検出された場合、その原因がメモリ容量不足か、ＣＰＵ負荷か、ネットワーク負荷か等、修復のために原因を絞り込む必要があった。
一般に異常の原因を解明するには、関係がありそうな計算機のシステムログやパラメータの調査を要する。この調査は、システムエンジニアの経験と勘に頼る必要あり、異常解明に時間と労力を要する。このため、通常の統合管理システムでは、複数の機器から収集したイベントデータ（状態通知）に基づいて、異常状態の組み合わせ等の分析を自動的に行い、大局的な問題点や原因を推定して管理者に通知し、対処支援を行うことが重要である。特に、サービスの長期連続運用での信頼性確保には、発生した異常だけでなく、明確な異常になっていない性能劣化や将来発生が予想される障害の兆候といった状態を検出し、計画的な設備増強を行うことが求められている。
ここで、このような統合管理システムに関連する以下のような技術が開示されている。特開２００２−３４２１０７号公報に開示された技術は、検出されたシステム障害がソフトウェア障害と特定された場合に、そのソフトウェア障害が発生したプロセスの再起動の再開範囲をドメイン単位に限定することで、サービスの中断時間を短縮する。
特開２００５−２８５０４０号公報に開示された技術は、複数のネットワーク装置から初期監視情報として連続量情報を収集し、この連続量情報の統計的な振舞いを監視し、通常と異なる振舞いを検出した場合に初めて、関連する複数の監視情報を収集して、その各値を判定することで障害の原因を特定する。
特開２００６−２４４４４７号公報に開示された技術は、データ記憶アレイにおける各種パラメータの障害傾向を検出してシステムの障害を回避する。この技術は、複数のデータ記憶装置により構成されるメモリ・アレイ空間へのアクセスを制御し、履歴ログへ各データ記憶装置からの動作性能データを累積する。そして、この技術は、データ記憶装置の異常な動作を検出するために動作性能データを解析し、解析に応答してデータ記憶装置の訂正処置を開始する。
特開２００８−９８４２号公報に開示された技術は、コンピュータシステムの稼動状態に関する情報を収集し、この収集された情報間の相関関係を示す相関情報を記録し、相関情報と収集情報からコンピュータシステムで実行されるサービスに生じた障害を検出し、この障害を回復するための処理を生成する。そして、この技術は、この処理の実行によってコンピュータシステムに与えられる効果及び影響を相関情報を参照して判定し、効果及び影響が判定された処理の実行の要否、実行順序及び実行時刻の少なくとも一つを決定する。
特開２００９−１９９５３３号公報に開示された技術は、複数の被管理装置から複数種の性能種目毎の性能情報を取得し、性能種目又は被管理装置を要素とした場合に、少なくとも第１の要素に関する性能情報の時系列変化を示す第１の性能系列情報と、第２の要素に関する性能情報の時系列変化を示す第２の性能系列情報との相関関数に基づいて、相関モデルを各要素間の組み合わせについて生成する。そして、この技術は、被管理装置から新たに検出された性能情報が相関モデルを維持しているか否かを分析し、その結果が否であれば、その要素を異常とする。
この統合管理システムとしては、例えば、監視対象となる複数のサーバから稼働状況に関する実測データをオンラインで取得し、この実測データが閾値を越えた場合に異常を検出するシステムが広く知られている。しかしながら、このシステムでは、異常が検出された場合、その原因がメモリ容量不足か、ＣＰＵ負荷か、ネットワーク負荷か等、修復のために原因を絞り込む必要があった。
一般に異常の原因を解明するには、関係がありそうな計算機のシステムログやパラメータの調査を要する。この調査は、システムエンジニアの経験と勘に頼る必要あり、異常解明に時間と労力を要する。このため、通常の統合管理システムでは、複数の機器から収集したイベントデータ（状態通知）に基づいて、異常状態の組み合わせ等の分析を自動的に行い、大局的な問題点や原因を推定して管理者に通知し、対処支援を行うことが重要である。特に、サービスの長期連続運用での信頼性確保には、発生した異常だけでなく、明確な異常になっていない性能劣化や将来発生が予想される障害の兆候といった状態を検出し、計画的な設備増強を行うことが求められている。
ここで、このような統合管理システムに関連する以下のような技術が開示されている。特開２００２−３４２１０７号公報に開示された技術は、検出されたシステム障害がソフトウェア障害と特定された場合に、そのソフトウェア障害が発生したプロセスの再起動の再開範囲をドメイン単位に限定することで、サービスの中断時間を短縮する。
特開２００５−２８５０４０号公報に開示された技術は、複数のネットワーク装置から初期監視情報として連続量情報を収集し、この連続量情報の統計的な振舞いを監視し、通常と異なる振舞いを検出した場合に初めて、関連する複数の監視情報を収集して、その各値を判定することで障害の原因を特定する。
特開２００６−２４４４４７号公報に開示された技術は、データ記憶アレイにおける各種パラメータの障害傾向を検出してシステムの障害を回避する。この技術は、複数のデータ記憶装置により構成されるメモリ・アレイ空間へのアクセスを制御し、履歴ログへ各データ記憶装置からの動作性能データを累積する。そして、この技術は、データ記憶装置の異常な動作を検出するために動作性能データを解析し、解析に応答してデータ記憶装置の訂正処置を開始する。
特開２００８−９８４２号公報に開示された技術は、コンピュータシステムの稼動状態に関する情報を収集し、この収集された情報間の相関関係を示す相関情報を記録し、相関情報と収集情報からコンピュータシステムで実行されるサービスに生じた障害を検出し、この障害を回復するための処理を生成する。そして、この技術は、この処理の実行によってコンピュータシステムに与えられる効果及び影響を相関情報を参照して判定し、効果及び影響が判定された処理の実行の要否、実行順序及び実行時刻の少なくとも一つを決定する。
特開２００９−１９９５３３号公報に開示された技術は、複数の被管理装置から複数種の性能種目毎の性能情報を取得し、性能種目又は被管理装置を要素とした場合に、少なくとも第１の要素に関する性能情報の時系列変化を示す第１の性能系列情報と、第２の要素に関する性能情報の時系列変化を示す第２の性能系列情報との相関関数に基づいて、相関モデルを各要素間の組み合わせについて生成する。そして、この技術は、被管理装置から新たに検出された性能情報が相関モデルを維持しているか否かを分析し、その結果が否であれば、その要素を異常とする。
しかしながら、上述の関連技術では、サーバシステムが大規模になると、異常が検出されるサーバの数が多くなるため、管理者が障害発生源とは異なる箇所に注目し、障害発生源のサーバが特定されるまでに時間を要するという課題があった。
例えば、複数のサーバ群により構成される多階層システムでは、１つのサーバで発生した障害による異常が多数のサーバに波及して影響を及ぼすことがある。この場合、この異常の波及により障害発生源が埋没してしまう。例えば、３階層システムでは、アプリケーションサーバで発生した障害による異常が上位のＷｅｂサーバ群に波及することにより、類似の異常がＷｅｂサーバ群で一斉に発生する。このような異常の波及は、１対多の関係で発生することが多く、１台のアプリケーションサーバの障害が１００台のＷｅｂサーバの異常として検出されることがある。ここで、管理者が、異常が検出されたサーバを順に調査するときに、１００台のＷｅｂサーバに着目してしまうと、障害発生源のアプリケーションサーバに行き着くまでに相当な時間がかかってしまう。
本発明は、上記課題を解決して、複数のサーバから異常を検出した場合に、異常の要因となる障害発生源を特定するために有効な情報を提示し、管理者が異常原因を特定するまでに要する時間を短縮できる運用管理装置、運用管理方法、及びプログラム記憶媒体を提供することを目的とする。
例えば、複数のサーバ群により構成される多階層システムでは、１つのサーバで発生した障害による異常が多数のサーバに波及して影響を及ぼすことがある。この場合、この異常の波及により障害発生源が埋没してしまう。例えば、３階層システムでは、アプリケーションサーバで発生した障害による異常が上位のＷｅｂサーバ群に波及することにより、類似の異常がＷｅｂサーバ群で一斉に発生する。このような異常の波及は、１対多の関係で発生することが多く、１台のアプリケーションサーバの障害が１００台のＷｅｂサーバの異常として検出されることがある。ここで、管理者が、異常が検出されたサーバを順に調査するときに、１００台のＷｅｂサーバに着目してしまうと、障害発生源のアプリケーションサーバに行き着くまでに相当な時間がかかってしまう。
本発明は、上記課題を解決して、複数のサーバから異常を検出した場合に、異常の要因となる障害発生源を特定するために有効な情報を提示し、管理者が異常原因を特定するまでに要する時間を短縮できる運用管理装置、運用管理方法、及びプログラム記憶媒体を提供することを目的とする。
本発明の運用管理装置は、共通の装置に接続された複数の被監視対象装置の各々を対象に、複数の性能指標について計測値を取得し、前記複数の被監視対象装置の各々における計測値が異常な前記性能指標を異常項目として検出する障害検出手段と、前記複数の被監視対象装置の各々の前記異常項目から、前記複数の被監視対象装置の全てにおいて検出された前記異常項目を除外して、残った前記異常項目を出力する波及判定手段とを含む。
本発明の運用管理方法は、共通の装置に接続された複数の被監視対象装置の各々を対象に、複数の性能指標について計測値を取得し、前記複数の被監視対象装置の各々における計測値が異常な前記性能指標を異常項目として検出し、前記複数の被監視対象装置の各々の前記異常項目から、前記複数の被監視対象装置の全てにおいて検出された前記異常項目を除外して、残った前記異常項目を出力する。
本発明のプログラム記録媒体は、コンピュータに、共通の装置に接続された複数の被監視対象装置の各々を対象に、複数の性能指標について計測値を取得し、前記複数の被監視対象装置の各々における計測値が異常な前記性能指標を異常項目として検出し、前記複数の被監視対象装置の各々の前記異常項目から、前記複数の被監視対象装置の全てにおいて検出された前記異常項目を除外して、残った前記異常項目を出力する処理を実行させる運用管理プログラムを記録する。
本発明の運用管理方法は、共通の装置に接続された複数の被監視対象装置の各々を対象に、複数の性能指標について計測値を取得し、前記複数の被監視対象装置の各々における計測値が異常な前記性能指標を異常項目として検出し、前記複数の被監視対象装置の各々の前記異常項目から、前記複数の被監視対象装置の全てにおいて検出された前記異常項目を除外して、残った前記異常項目を出力する。
本発明のプログラム記録媒体は、コンピュータに、共通の装置に接続された複数の被監視対象装置の各々を対象に、複数の性能指標について計測値を取得し、前記複数の被監視対象装置の各々における計測値が異常な前記性能指標を異常項目として検出し、前記複数の被監視対象装置の各々の前記異常項目から、前記複数の被監視対象装置の全てにおいて検出された前記異常項目を除外して、残った前記異常項目を出力する処理を実行させる運用管理プログラムを記録する。
本発明の効果は、複数のサーバから異常を検出した際に、管理者がシステムで発生した障害の原因を迅速に特定できることである。
以下、本発明にかかる一実施形態を、図面に基づいて説明する。
図１は、本実施形態の監視システムの構成を示す機能ブロック図である。図１に示すように、本実施形態の監視システムは、サーバ運用管理装置２と、監視端末３とを含む。サーバ運用管理装置２は、複数の被監視サーバ１（被監視装置）を監視する。監視端末３は、管理者の操作により入力される調査指令に従って、サーバ運用管理装置２に対し各被監視サーバ１の異常の有無の調査依頼を送信すると共に、サーバ運用管理装置２から受けた調査結果を管理画面３１に表示する。
被監視サーバ１は、サーバ運用管理装置２が監視対象としている多階層システムを構成するサーバである。多階層システムとは、サービスを提供するための情報処理を複数の階層に分離し、各階層に、負荷分散されたサーバ群を設けたシステムである。例えば、３階層システムは、ウェブサーバ群、アプリケーションサーバ群、及びデータベースサーバ群とからなる。図２は、本実施形態における多階層システムの構成の一例を示す図である。図２の例では、被監視サーバ１が３階層システムを構成している。この３階層システムは、被監視サーバ１として、２機のアプリケーションサーバと３機のウェブサーバとを含む。また、ＡＰサーバグループＢは、２機のアプリケーションサーバを含み、ＷｅｂサーバグループＡは、３機のウェブサーバを含む。図示していないクライアント又は他のサーバからのインターネットＤを介したＷｅｂサーバグループＡへのアクセスは、ロードバランサＣにより各ウェブサーバへ均等に負荷分散される。そして、それぞれのウェブサーバは、ランダムに第１又は第２のアプリケーションサーバにリクエストを転送する。
また、各被監視サーバ１は、自機における複数の性能指標（メトリック）を一定間隔毎に計測し、この各性能指標の実測データを性能情報としてサーバ運用管理装置２へ送る。ここで、メトリックとは、サーバやネットワーク機器から観測できる性能指標のことを指す。例えば、性能指標としては、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）使用率、メモリ使用量、ディスク使用状況、サービスアプリケーションの稼働状況、最新の修正モジュールがＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）またはアプリケーションに適用されているか否か、パスワードエラーの回数などがある。
本実施形態のサーバ運用管理装置２は、性能情報収集部２１と、性能情報蓄積部２２と、障害検出部２６と、波及判定部２７とを含む。性能情報収集部２１は、多階層システムを構成する複数の被監視サーバ１の各々から、複数の性能指標について、収集時刻毎に、計測された各実測データの組を性能情報として収集する。性能情報蓄積部２２は、収集された各被監視サーバ１の性能情報を蓄積する。障害検出部２６は、監視端末３からの調査依頼において管理者が指定した調査時刻に計測された各被監視サーバ１の性能情報を性能情報蓄積部２２から読み出し、各性能指標の実測データが正常か異常かを各モデルデータとの比較結果に基づいて判断し、異常な性能指標を異常項目として検出する。波及判定部２７は、障害検出部２６により検出された各被監視サーバ１の異常項目から、同一階層の全被監視サーバ１間で共通する異常項目を抽出して除外し、各被監視サーバ１の残りの異常項目を示す管理用異常情報を管理者への提示用として生成する。
このような構成の本実施形態のサーバ運用管理装置２によれば、波及判定部２７により、同一階層の全サーバに共通する異常項目を他階層のサーバからの波及により生じたものであるとして除外し、各サーバの残りの異常項目を管理用異常情報とするため、階層間の異常の波及による障害発生源の埋没がない情報を管理者に提示することができる。
ここで、異常の波及とは、１つのサーバで発生した障害が、そのサーバに接続された他の階層における多数のサーバに異常をもたらすことである。図３は、本実施形態における多階層システムで発生する障害の波及状態の一例を示す図である。例えば、図３に示すように、アプリケーションサーバ群の１つのサーバに障害が発生すると、ウェブサーバ群の全てのサーバに一様に影響を与えて、全てのウェブサーバで同一傾向の異常が同時発生する。その結果、１つのアプリケーションサーバの障害が波及すると、ウェブサーバではアプリケーションサーバの数倍の範囲で異常が検出される。
また、本実施形態のサーバ運用管理装置２は、異常スコア計算部２８を含んでいてもよい。異常スコア計算部２８は、波及判定部２７により生成された管理用異常情報に基づいて各被監視サーバ１の異常項目数を集計し、被監視サーバ１毎に性能指標数に占める異常項目数の割合を異常スコアとして算出する。
これにより、各被監視サーバ１の異常度合いを表す値として、性能指標数（メトリック数）の違いを打ち消した異常スコアを算出するので、各被監視サーバ１の性能指標数の違いに左右されずに異常が集中する被監視サーバ１を判定し、正確な原因候補のランキングを得ることができる。
更に、本実施形態のサーバ運用管理装置２は、相関モデル生成部２３と、相関モデル記憶部２４とを含む。相関モデル生成部２３は、性能情報蓄積部２２に蓄積された一定期間分の正常な各被監視サーバ１の性能情報に基づいて、被監視サーバ１毎に、２つの性能指標の組み合わせ毎に、当該２つの性能指標の実測データ間の相関関係を示す変換関数を相関モデルとして生成する。相関モデル記憶部２４は、生成された各相関モデルを記憶する。障害検出部２６は、調査時刻に計測された各被監視サーバの性能情報における性能指標の組み合わせのうちの一方の実測データを、当該組み合わせに係る相関モデルに基づいて他方の実測データから算出されるモデルデータと比較する。そして、障害検出部２６は、その差分が一定の誤差範囲内を満たすか否かを判定し、否と判定された性能指標の組み合わせを、上述した異常項目として検出する。
これにより、正常時の相関関係が崩れている性能指標の組を複数検出し、重複している性能指標を異常発生源として迅速に特定できる。
また更に、本実施形態のサーバ運用管理装置２は、論理構成情報記憶部２５と、通信制御部２９とを含む。論理構成情報記憶部２５は、複数の各被監視サーバ１がどの階層に属しているかを示す多階層の論理構成情報を予め記憶する。通信制御部２９は、監視端末３との通信を制御する。
サーバ運用管理装置２における性能情報収集部２１は、各被監視サーバ１で計測された各々の性能情報を各被監視サーバ１から収集し、性能情報蓄積部２２へ順次送る。
性能情報蓄積部２２は、各被監視サーバ１の性能情報を、性能指標毎の時系列データとして保存管理すると共に、相関モデル生成部２３又は障害検出部２６からの要求に応じて、指定された期間の各被監視サーバ１の性能情報を出力する。
相関モデル生成部２３は、各被監視サーバ１の一定期間分の正常な性能情報を性能情報蓄積部２２から取得する。ここで、相関モデル生成部２３は、各被監視サーバ１の全ての性能指標（メトリック）について、実測データを取得する。そして、相関モデル生成部２３は、予め定められた算術的アルゴリズムに基づいて、被監視サーバ１毎に、２つのメトリックの組み合わせ全てについて、相関関係を示す相関モデルを算出する。ここで、一定期間としては、例えば、１週間又は１ヶ月などが設定されていてもよい。また、相関モデル生成部２３は、特開２００９−１９９５３３号公報に記載された技術を用いて相関モデルを生成してもよい。
例えば、相関モデル生成部２３は、算術的アルゴリズムとして、被監視サーバ１の性能情報における性能指標の組み合わせのうち、一方の性能指標の実測データをｘとし他方の性能指標の実測データをｙとした場合に、変換関数「ｙ＝Ａｘ＋Ｂ」が成り立つように係数Ａ、Ｂの値を算出する。そして、相関モデル生成部２３は、この算出した係数Ａ、Ｂの値を含む変換関数「ｙ＝Ａｘ＋Ｂ」を、この性能指標の組み合わせに対応する相関モデルとしてもよい。
相関モデル記憶部２４は、相関モデル生成部２３により生成された相関モデルを受け取り記憶すると共に、障害検出部２６からの要求に対応して相関モデルを出力する。論理構成情報記憶部２５は、各被監視サーバ１の識別子にその被監視サーバ１が所属する階層の階層名を対応付けた、多階層の論理構成情報を予め記憶する。
障害検出部２６は、各被監視サーバ１の、監視端末３からの調査依頼で指定された調査期間の性能情報を性能情報蓄積部２２から読み出すと共に各被監視サーバ１の相関モデルを相関モデル記憶部２４から読み出す。障害検出部２６は、調査期間内の収集時刻毎に、各被監視サーバ１の性能情報における性能指標（メトリック）の組み合わせの一方の実測データと、この組み合わせに係る相関モデルに他方の実測データを代入して算出したモデルデータとの間の残差値を算出する。障害検出部２６は、残差値が予め設定された値を超えていた場合、この性能指標（メトリック）の組み合わせを異常項目として検出する。
例えば、性能指標の組み合わせを「システムプロセスのＣＰＵ使用率」と「メモリ使用量」とした場合、障害検出部２６は、「システムプロセスのＣＰＵ使用率」を入力として相関モデルを基に算出される「メモリ使用量」のモデルデータと、「メモリ使用量」の実測データとを比較する。そして、障害検出部２６は、その残差が予め設定された許容範囲内でない場合、この組み合わせを異常項目として検出する。
波及判定部２７は、論理構成情報記憶部２５に予め記憶された論理構成情報を基に各被監視サーバ１が属する階層（サーバグループ）を同定し、障害検出部２６によって検出された各被監視サーバ１の異常項目から同一階層の全ての被監視サーバ１間で共通する異常項目を抽出する。そして、波及判定部２７は、この抽出した共通の異常項目を各被監視サーバの全異常項目から除外することで、異常の波及を考慮した管理用異常情報を生成する。
ここで、波及判定部２７の機能を図４及び図５に示す具体例に基づいて説明する。図４は、本実施形態における異常項目の一例を示す図である。図４は、３つのウェブサーバと２つのアプリケーションサーバとを被監視サーバ１とした場合の、障害検出部２６が検出した各被監視サーバ１の異常項目である。図５は、本実施形態における管理用異常情報の一例を示す図である。図５は、図４に示す各被監視サーバ１の異常項目から、波及判定部２７が、各階層の被監視サーバ１間で共通な異常項目を抽出し、除外することにより生成した管理用異常情報である。
図４及び図５における「Ｗｅｂ１」、「Ｗｅｂ２」、「Ｗｅｂ３」はそれぞれウェブサーバの識別子（サーバ名）を表し、「ＡＰ１」、「ＡＰ２」はそれぞれアプリケーションサーバの識別子（サーバ名）を表す。図４では、各サーバの異常項目として、相関関係の異常を検出した性能指標の組み合わせ（一方の性能指標ｕと他方の性能指標ｙ）が示されている。ここで、「ＣＰＵ ｕｓｅｒ％」は、ユーザプロセスのＣＰＵ使用率を表す。「ＣＰＵ ｓｙｓｔｅｍ％」は、システムプロセスのＣＰＵ使用率を表す。「Ｄｉｓｋ ＩＯ／ｓｅｃ」は、ディスク入出力レートを表す。「Ｍｅｍ ｕｓｅｄ％」は、メモリ使用量を表す。「Ｄｉｓｋ ｕｓｅｄ％」は、ディスク使用量を表す。「ＣＰＵ Ｗａｉｔ Ｉ／Ｏ％」は、ＣＰＵ入出力待ち時間を表す。「Ｐａｃｋｅｔ Ｒｅｃｖ」及び「Ｐａｃｋｅｔ Ｓｅｎｔ」は、受信パケット数及び送信パケット数を表す。
図４に示す例では、「Ｗｅｂ１」、「Ｗｅｂ２」、「Ｗｅｂ３」からなるウェブサーバグループにおいて、「ＣＰＵ ｕｓｅｒ％」と「ＣＰＵ ｓｙｓｔｅｍ％」の組み合わせ、及び「Ｍｅｍ ｕｓｅｄ％」と「Ｄｉｓｋ ｕｓｅｄ％」の組み合わせが３つのウェブサーバ間で、共通の異常項目である。一方で、「ＡＰ１」、「ＡＰ２」からなるアプリケーションサーバグループにおいて、共通の異常項目は無い。この結果、波及判定部２７によって生成される管理用異常情報は図５のようになる。
異常スコア計算部２８は、波及判定部２７から管理用異常情報を受け取り、管理用異常情報を基に各被監視サーバ１の異常項目数をカウントする。そして、異常スコア計算部２８は、被監視サーバ１毎に、２つのメトリックの組み合わせ総数に占める異常項目数の割合を異常スコアとして算出し、各被監視サーバ１の異常スコアを示す情報と上述した管理用異常情報とを監視端末３へ送出する。図６は、本実施形態における異常スコア計算部２８から出力される情報の一例を示す図である。図６に示すように、異常スコア計算部２８が出力する情報は、サーバ識別子、異常項目数、メトリックの組み合わせ総数（相関モデル数）、異常スコアの４つのカラムを持つテーブルである。図６の例では、このテーブルの１番目のレコードに、サーバ識別子としてアプリケーションサーバの１つを表す「ＡＰ１」が記録されており、異常項目数に「７」、相関モデル数に「２０」、異常スコアに「０．３５」が記録されている。
監視端末３は、管理者による操作に従って、サーバ運用管理装置２に調査指令を送る。また、監視端末３は、調査指令に対してサーバ運用管理装置２から送られてくる各被監視サーバ１の異常スコアと管理用異常情報とに基づく監視情報を管理画面３１に表示する。
図７は、本実施形態における監視端末３の管理画面３１に表示される監視情報の一例を示す図である。図７に示す監視情報には、各被監視サーバ１の異常スコアを示すテーブル７１、相関異常マップ７２、実測データグラフ７３が含まれている。テーブル７１は、サーバ識別子及びその異常スコアのカラムを持つ。テーブル７１の行は、異常スコアに応じて整列されていてもよい。また、テーブル７１の行の数は、管理者が決めた数に限定されていてもよい。これにより、管理者は分析の結果もっとも異常の可能性の高い被監視サーバ１を容易に把握することができる。
相関異常マップ７２には、各階層と各被監視サーバ１との関係が矩形のエリアで表される。そして、各被監視サーバ１のエリア内にメトリックを表す円が表示され、異常が検出されたメトリック間に直線が描画される。実データグラフ７３には、異常が検出された両メトリックの実測データを時系列で示したグラフと、障害検出部２６によって算出された、実測データと相関モデルとの差分を示したグラフが含まれる。
ここで、本実施形態のサーバ運用管理装置２は、論理構成情報記憶部２５を含み、波及判定部２７が、論理構成情報記憶部２５に予め記憶された論理構成情報を基に各被監視サーバ１が属する階層（サーバグループ）を同定する。しかしながら、これに限らず、サーバ運用管理装置２が論理構成情報記憶部２５を含まずに、波及判定部２７が、上述した各被監視サーバ１の性能情報に含まれるサーバ識別子から、各被監視サーバ１が所属する階層を判別してもよい。例えば、波及判定部２７は、性能情報に含まれるサーバ識別子が「Ｗｅｂ２」であれば、「Ｗｅｂ」部分が同じ「Ｗｅｂ１」及び「Ｗｅｂ３」と同一階層に属すると判別してもよい。
本実施形態のサーバ運用管理装置２によれば、波及判定部２７により同一階層の被監視サーバ１に共通する異常項目を他階層からの波及により生じたものとして除外し、残りの異常項目を管理用異常情報として表示するため、階層間の異常の波及による障害発生源の埋没を解消することができる。また、サーバ間のメトリック数の違いに左右されない指標である異常スコアを被監視サーバ１毎に算出するため、管理者は障害発生源である可能性が大きい被監視サーバ１を容易に特定することができる。
次に、本実施形態におけるサーバ運用管理装置２の動作について説明する。ここで、以下の動作説明は、本発明のサーバ運用管理方法の実施形態の説明でもある。
図８は、本実施形態のサーバ運用管理装置２の性能情報収集動作を示すフローチャートである。図８に示すように、まず、性能情報収集部２１が、予め一定間隔（例えば１分間隔）で設定された収集時刻になったか否かを判断し（図８のステップＳ８１）、収集時刻になったと判断すると被監視サーバ１にアクセスして性能情報を取得する（図８のステップＳ８２）。そして、この取得された被監視サーバ１の性能情報を性能情報蓄積部２２が記憶する（図８のステップＳ８３）。続いて、性能情報収集部２１が、論理構成情報記憶部２５の論理構成情報を参照して全ての被監視サーバ１から性能情報を取得したか否かを判断し（図８のステップＳ８４）、全ての被監視サーバ１から性能情報を取得した場合、次の収集時刻まで待機する。
次に、図９は、本実施形態のサーバ運用管理装置２の相関モデル生成動作を示すフローチャートである。
まず、相関モデル生成部２３が、監視端末３からの指示に従って、性能情報蓄積部２２に蓄積された一定期間分（例えば、１週間分）の正常な各被監視サーバ１の性能情報を読み出す（図９のステップＳ９１）。相関モデル生成部２３は、被監視サーバ１毎に、２つの性能指標の組み合わせ毎に、当該性能指標の実測データ間の相関関係を示す変換関数を相関モデルとして生成する（図９のステップＳ９２）。この生成された各相関モデルを相関モデル記憶部２４が記憶する（図９のステップＳ９３）。そして、相関モデル生成部２３は、すべての被監視サーバ１について相関モデルを生成したら（図９のステップＳ９４のはい）、相関モデル生成動作を終了する。
次に、図１０は、本実施形態のサーバ運用管理装置２の管理用異常情報検出動作を示すフローチャートである。
まず、障害検出部２６が、監視端末３に指定された調査対象期間（例えば、１週間）に含まれる測定時刻毎の各被監視サーバ１の性能情報を性能情報蓄積部２２から読み出す（図１０のステップＳ１０１）。障害検出部２６は、その各性能指標の実測データの組み合わせが、対応する相関モデル（変換関数）を一定の誤差範囲内で満たすか否かを判定し、否と判定された性能指標の組み合わせを異常項目として検出する（図１０のステップＳ１０２）。
続いて、波及判定部２７が、論理構成情報を参照して、障害検出部２６によって検出された各被監視サーバ１の異常項目から、同一階層の全被監視サーバ１間で共通する異常項目を抽出する（図１０のステップＳ１０３）。波及判定部２７は、各被監視サーバ１の異常項目から、この抽出した共通の異常項目を除外した残りの異常項目を示す管理用異常情報を生成する（図１０のステップＳ１０４）。そして、波及判定部２７は、全ての階層について管理用異常情報を生成した場合に（図１０のステップＳ１０５のはい）、その管理用異常情報を異常スコア計算部２８へ出力する（図１０のステップＳ１０６）。
これにより、同一階層の全被監視サーバ２に共通する異常項目を他階層からの波及により生じたものとして除外し、残りの異常項目を管理用異常情報とするので、階層間の異常の波及による異常発生源の埋没を抑制することができる。
次に、図１１は、本実施形態のサーバ運用管理装置２の異常スコア算出動作を示すフローチャートである。
まず、異常スコア計算部２８が、波及判定部２７から入力された管理用異常情報に基づいて、被監視サーバ１毎に異常項目数を計数する（図１１のステップＳ１１１）。異常スコア計算部２８は、相関モデル記憶部２４に記憶されている相関モデルを参照して、被監視サーバ１毎に相関モデル数を計数する（図１１のステップＳ１１２）。続いて、異常スコア計算部２８は、被監視サーバ１毎に異常項目数の相関モデル数に対する割合を異常スコアとして算出する（図１１のステップＳ１１３）。
そして、全ての被監視サーバ１について異常スコアを算出した場合に（図１１のステップＳ１１４のはい）、各被監視サーバ１の異常スコアを監視端末３へ出力する（図１１のステップＳ１１５）。
これにより、各被監視サーバ１についてメトリック数に応じた異常スコアを算出できるため、メトリック数に左右されず、異常が集中している被監視サーバ１を判定し、正確な原因候補のランキングを得ることが出来る。
ここで、上述したサーバ運用管理装置２における、性能情報収集部２１、相関モデル生成部２３、障害検出部２６、波及判定部２７、及び異常スコア計算部２８については、その機能内容をプログラム化して、コンピュータに実行させるように構成してもよい。
次に、本実施形態の特徴的な構成について説明する。図１２は、本実施形態の特徴的な構成を示すブロック図である。
運用管理装置は、障害検出部２６と、波及判定部２７とを含む。
ここで、障害検出部２６は、共通の装置に接続された複数の被監視対象装置の各々を対象に、複数の性能指標について計測値を取得し、複数の被監視対象装置の各々における計測値が異常な性能指標を異常項目として検出する。波及判定部２７は、複数の被監視対象装置の各々の異常項目から、複数の被監視対象装置の全てにおいて検出された異常項目を除外して、残った異常項目を出力する。
以上のように、本実施形態のサーバ運用管理装置２は、負荷分散クラスタサーバ群の特徴を利用して、サーバグループ毎に発生した異常の類似性を判定し、サーバグループ間に発生する異常の波及を特定し、異常情報の補正を行うため、管理者は、異常原因を容易に判別できる。
本実施形態のサーバ運用管理装置２は、多階層システムにおける複数の被監視サーバ１から異常を検出した場合に、各被監視サーバ１の異常項目から、同一階層の全被監視サーバ１に共通する異常項目を他階層のサーバからの波及により生じたものとして除外し、残りの異常項目を管理用異常情報とするため、障害発生源の被監視サーバ１の異常項目を相対的に多くして、障害発生源の埋没を抑えることができる。よって、管理者は分析の結果もっとも異常の可能性の高い被監視サーバ１を容易に把握することができ、多階層システムで発生した異常の原因解明を正確且つ迅速に実施することができる。
また、上述の特開２００９−１９９５３３号公報等に開示された関連技術では、多階層システムにおいて、障害発生源のサーバのメトリック数が少数であった場合に、障害の原因が埋没してしまう問題があった。
例えば、アプリケーションサーバとデータベースサーバとの間では、ディスク搭載数の違い、ソフトウェアの監視項目数の違いにより、何倍ものメトリック数の違いがあり、各階層のサーバグループ間では、メトリック数に相対的に大きな差異がある。ここで、メトリック総数が相対的に少ないサーバが障害の発生源である場合、その障害発生源のサーバは、異常メトリック数の上限が他に比べて少ないため、全てのメトリックが異常を示していても、障害が波及した他のサーバより異常メトリック数が少ない。管理者は、通常、異常メトリック数の絶対数が多いサーバから調査するため、障害発生源のサーバの異常は他のサーバ群に埋没してしまう。このため、管理者は誤ったサーバに着目してしまい、結果として異常原因を見誤る。
本実施形態のサーバ運用管理装置２は、被監視サーバ１毎にメトリック数に応じた異常スコアを算出するため、相対的にメトリック数の少ない被監視サーバ１の分析をシームレスに可能にし、各被監視サーバ１間のメトリック数の違いに左右されず、異常が集中している被監視サーバ１を特定し、正確な原因候補のランキングを得ることができる。これにより、管理者は正確且つ迅速な障害箇所の特定が可能となる。
以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
例えば、上記実施形態では、障害検出部２６が、２つの性能指標の計測値が当該２つの性能指標に対応する相関モデルを満足していない場合、当該２つの性能指標の組み合わせを異常項目として検出している。しかしながら、障害検出部２６は、各性能指標の計測値を所定の閾値と比較する等により、各性能指標が異常かどうかを判定し、異常と判定された各性能指標を異常項目として出力してもよい。
この出願は、２０１０年１月８日に出願された日本出願特願２０１０−００３００８を基礎とする優先権を主張し、その開示の全てをここに取り込む。
図１は、本実施形態の監視システムの構成を示す機能ブロック図である。図１に示すように、本実施形態の監視システムは、サーバ運用管理装置２と、監視端末３とを含む。サーバ運用管理装置２は、複数の被監視サーバ１（被監視装置）を監視する。監視端末３は、管理者の操作により入力される調査指令に従って、サーバ運用管理装置２に対し各被監視サーバ１の異常の有無の調査依頼を送信すると共に、サーバ運用管理装置２から受けた調査結果を管理画面３１に表示する。
被監視サーバ１は、サーバ運用管理装置２が監視対象としている多階層システムを構成するサーバである。多階層システムとは、サービスを提供するための情報処理を複数の階層に分離し、各階層に、負荷分散されたサーバ群を設けたシステムである。例えば、３階層システムは、ウェブサーバ群、アプリケーションサーバ群、及びデータベースサーバ群とからなる。図２は、本実施形態における多階層システムの構成の一例を示す図である。図２の例では、被監視サーバ１が３階層システムを構成している。この３階層システムは、被監視サーバ１として、２機のアプリケーションサーバと３機のウェブサーバとを含む。また、ＡＰサーバグループＢは、２機のアプリケーションサーバを含み、ＷｅｂサーバグループＡは、３機のウェブサーバを含む。図示していないクライアント又は他のサーバからのインターネットＤを介したＷｅｂサーバグループＡへのアクセスは、ロードバランサＣにより各ウェブサーバへ均等に負荷分散される。そして、それぞれのウェブサーバは、ランダムに第１又は第２のアプリケーションサーバにリクエストを転送する。
また、各被監視サーバ１は、自機における複数の性能指標（メトリック）を一定間隔毎に計測し、この各性能指標の実測データを性能情報としてサーバ運用管理装置２へ送る。ここで、メトリックとは、サーバやネットワーク機器から観測できる性能指標のことを指す。例えば、性能指標としては、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）使用率、メモリ使用量、ディスク使用状況、サービスアプリケーションの稼働状況、最新の修正モジュールがＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）またはアプリケーションに適用されているか否か、パスワードエラーの回数などがある。
本実施形態のサーバ運用管理装置２は、性能情報収集部２１と、性能情報蓄積部２２と、障害検出部２６と、波及判定部２７とを含む。性能情報収集部２１は、多階層システムを構成する複数の被監視サーバ１の各々から、複数の性能指標について、収集時刻毎に、計測された各実測データの組を性能情報として収集する。性能情報蓄積部２２は、収集された各被監視サーバ１の性能情報を蓄積する。障害検出部２６は、監視端末３からの調査依頼において管理者が指定した調査時刻に計測された各被監視サーバ１の性能情報を性能情報蓄積部２２から読み出し、各性能指標の実測データが正常か異常かを各モデルデータとの比較結果に基づいて判断し、異常な性能指標を異常項目として検出する。波及判定部２７は、障害検出部２６により検出された各被監視サーバ１の異常項目から、同一階層の全被監視サーバ１間で共通する異常項目を抽出して除外し、各被監視サーバ１の残りの異常項目を示す管理用異常情報を管理者への提示用として生成する。
このような構成の本実施形態のサーバ運用管理装置２によれば、波及判定部２７により、同一階層の全サーバに共通する異常項目を他階層のサーバからの波及により生じたものであるとして除外し、各サーバの残りの異常項目を管理用異常情報とするため、階層間の異常の波及による障害発生源の埋没がない情報を管理者に提示することができる。
ここで、異常の波及とは、１つのサーバで発生した障害が、そのサーバに接続された他の階層における多数のサーバに異常をもたらすことである。図３は、本実施形態における多階層システムで発生する障害の波及状態の一例を示す図である。例えば、図３に示すように、アプリケーションサーバ群の１つのサーバに障害が発生すると、ウェブサーバ群の全てのサーバに一様に影響を与えて、全てのウェブサーバで同一傾向の異常が同時発生する。その結果、１つのアプリケーションサーバの障害が波及すると、ウェブサーバではアプリケーションサーバの数倍の範囲で異常が検出される。
また、本実施形態のサーバ運用管理装置２は、異常スコア計算部２８を含んでいてもよい。異常スコア計算部２８は、波及判定部２７により生成された管理用異常情報に基づいて各被監視サーバ１の異常項目数を集計し、被監視サーバ１毎に性能指標数に占める異常項目数の割合を異常スコアとして算出する。
これにより、各被監視サーバ１の異常度合いを表す値として、性能指標数（メトリック数）の違いを打ち消した異常スコアを算出するので、各被監視サーバ１の性能指標数の違いに左右されずに異常が集中する被監視サーバ１を判定し、正確な原因候補のランキングを得ることができる。
更に、本実施形態のサーバ運用管理装置２は、相関モデル生成部２３と、相関モデル記憶部２４とを含む。相関モデル生成部２３は、性能情報蓄積部２２に蓄積された一定期間分の正常な各被監視サーバ１の性能情報に基づいて、被監視サーバ１毎に、２つの性能指標の組み合わせ毎に、当該２つの性能指標の実測データ間の相関関係を示す変換関数を相関モデルとして生成する。相関モデル記憶部２４は、生成された各相関モデルを記憶する。障害検出部２６は、調査時刻に計測された各被監視サーバの性能情報における性能指標の組み合わせのうちの一方の実測データを、当該組み合わせに係る相関モデルに基づいて他方の実測データから算出されるモデルデータと比較する。そして、障害検出部２６は、その差分が一定の誤差範囲内を満たすか否かを判定し、否と判定された性能指標の組み合わせを、上述した異常項目として検出する。
これにより、正常時の相関関係が崩れている性能指標の組を複数検出し、重複している性能指標を異常発生源として迅速に特定できる。
また更に、本実施形態のサーバ運用管理装置２は、論理構成情報記憶部２５と、通信制御部２９とを含む。論理構成情報記憶部２５は、複数の各被監視サーバ１がどの階層に属しているかを示す多階層の論理構成情報を予め記憶する。通信制御部２９は、監視端末３との通信を制御する。
サーバ運用管理装置２における性能情報収集部２１は、各被監視サーバ１で計測された各々の性能情報を各被監視サーバ１から収集し、性能情報蓄積部２２へ順次送る。
性能情報蓄積部２２は、各被監視サーバ１の性能情報を、性能指標毎の時系列データとして保存管理すると共に、相関モデル生成部２３又は障害検出部２６からの要求に応じて、指定された期間の各被監視サーバ１の性能情報を出力する。
相関モデル生成部２３は、各被監視サーバ１の一定期間分の正常な性能情報を性能情報蓄積部２２から取得する。ここで、相関モデル生成部２３は、各被監視サーバ１の全ての性能指標（メトリック）について、実測データを取得する。そして、相関モデル生成部２３は、予め定められた算術的アルゴリズムに基づいて、被監視サーバ１毎に、２つのメトリックの組み合わせ全てについて、相関関係を示す相関モデルを算出する。ここで、一定期間としては、例えば、１週間又は１ヶ月などが設定されていてもよい。また、相関モデル生成部２３は、特開２００９−１９９５３３号公報に記載された技術を用いて相関モデルを生成してもよい。
例えば、相関モデル生成部２３は、算術的アルゴリズムとして、被監視サーバ１の性能情報における性能指標の組み合わせのうち、一方の性能指標の実測データをｘとし他方の性能指標の実測データをｙとした場合に、変換関数「ｙ＝Ａｘ＋Ｂ」が成り立つように係数Ａ、Ｂの値を算出する。そして、相関モデル生成部２３は、この算出した係数Ａ、Ｂの値を含む変換関数「ｙ＝Ａｘ＋Ｂ」を、この性能指標の組み合わせに対応する相関モデルとしてもよい。
相関モデル記憶部２４は、相関モデル生成部２３により生成された相関モデルを受け取り記憶すると共に、障害検出部２６からの要求に対応して相関モデルを出力する。論理構成情報記憶部２５は、各被監視サーバ１の識別子にその被監視サーバ１が所属する階層の階層名を対応付けた、多階層の論理構成情報を予め記憶する。
障害検出部２６は、各被監視サーバ１の、監視端末３からの調査依頼で指定された調査期間の性能情報を性能情報蓄積部２２から読み出すと共に各被監視サーバ１の相関モデルを相関モデル記憶部２４から読み出す。障害検出部２６は、調査期間内の収集時刻毎に、各被監視サーバ１の性能情報における性能指標（メトリック）の組み合わせの一方の実測データと、この組み合わせに係る相関モデルに他方の実測データを代入して算出したモデルデータとの間の残差値を算出する。障害検出部２６は、残差値が予め設定された値を超えていた場合、この性能指標（メトリック）の組み合わせを異常項目として検出する。
例えば、性能指標の組み合わせを「システムプロセスのＣＰＵ使用率」と「メモリ使用量」とした場合、障害検出部２６は、「システムプロセスのＣＰＵ使用率」を入力として相関モデルを基に算出される「メモリ使用量」のモデルデータと、「メモリ使用量」の実測データとを比較する。そして、障害検出部２６は、その残差が予め設定された許容範囲内でない場合、この組み合わせを異常項目として検出する。
波及判定部２７は、論理構成情報記憶部２５に予め記憶された論理構成情報を基に各被監視サーバ１が属する階層（サーバグループ）を同定し、障害検出部２６によって検出された各被監視サーバ１の異常項目から同一階層の全ての被監視サーバ１間で共通する異常項目を抽出する。そして、波及判定部２７は、この抽出した共通の異常項目を各被監視サーバの全異常項目から除外することで、異常の波及を考慮した管理用異常情報を生成する。
ここで、波及判定部２７の機能を図４及び図５に示す具体例に基づいて説明する。図４は、本実施形態における異常項目の一例を示す図である。図４は、３つのウェブサーバと２つのアプリケーションサーバとを被監視サーバ１とした場合の、障害検出部２６が検出した各被監視サーバ１の異常項目である。図５は、本実施形態における管理用異常情報の一例を示す図である。図５は、図４に示す各被監視サーバ１の異常項目から、波及判定部２７が、各階層の被監視サーバ１間で共通な異常項目を抽出し、除外することにより生成した管理用異常情報である。
図４及び図５における「Ｗｅｂ１」、「Ｗｅｂ２」、「Ｗｅｂ３」はそれぞれウェブサーバの識別子（サーバ名）を表し、「ＡＰ１」、「ＡＰ２」はそれぞれアプリケーションサーバの識別子（サーバ名）を表す。図４では、各サーバの異常項目として、相関関係の異常を検出した性能指標の組み合わせ（一方の性能指標ｕと他方の性能指標ｙ）が示されている。ここで、「ＣＰＵ ｕｓｅｒ％」は、ユーザプロセスのＣＰＵ使用率を表す。「ＣＰＵ ｓｙｓｔｅｍ％」は、システムプロセスのＣＰＵ使用率を表す。「Ｄｉｓｋ ＩＯ／ｓｅｃ」は、ディスク入出力レートを表す。「Ｍｅｍ ｕｓｅｄ％」は、メモリ使用量を表す。「Ｄｉｓｋ ｕｓｅｄ％」は、ディスク使用量を表す。「ＣＰＵ Ｗａｉｔ Ｉ／Ｏ％」は、ＣＰＵ入出力待ち時間を表す。「Ｐａｃｋｅｔ Ｒｅｃｖ」及び「Ｐａｃｋｅｔ Ｓｅｎｔ」は、受信パケット数及び送信パケット数を表す。
図４に示す例では、「Ｗｅｂ１」、「Ｗｅｂ２」、「Ｗｅｂ３」からなるウェブサーバグループにおいて、「ＣＰＵ ｕｓｅｒ％」と「ＣＰＵ ｓｙｓｔｅｍ％」の組み合わせ、及び「Ｍｅｍ ｕｓｅｄ％」と「Ｄｉｓｋ ｕｓｅｄ％」の組み合わせが３つのウェブサーバ間で、共通の異常項目である。一方で、「ＡＰ１」、「ＡＰ２」からなるアプリケーションサーバグループにおいて、共通の異常項目は無い。この結果、波及判定部２７によって生成される管理用異常情報は図５のようになる。
異常スコア計算部２８は、波及判定部２７から管理用異常情報を受け取り、管理用異常情報を基に各被監視サーバ１の異常項目数をカウントする。そして、異常スコア計算部２８は、被監視サーバ１毎に、２つのメトリックの組み合わせ総数に占める異常項目数の割合を異常スコアとして算出し、各被監視サーバ１の異常スコアを示す情報と上述した管理用異常情報とを監視端末３へ送出する。図６は、本実施形態における異常スコア計算部２８から出力される情報の一例を示す図である。図６に示すように、異常スコア計算部２８が出力する情報は、サーバ識別子、異常項目数、メトリックの組み合わせ総数（相関モデル数）、異常スコアの４つのカラムを持つテーブルである。図６の例では、このテーブルの１番目のレコードに、サーバ識別子としてアプリケーションサーバの１つを表す「ＡＰ１」が記録されており、異常項目数に「７」、相関モデル数に「２０」、異常スコアに「０．３５」が記録されている。
監視端末３は、管理者による操作に従って、サーバ運用管理装置２に調査指令を送る。また、監視端末３は、調査指令に対してサーバ運用管理装置２から送られてくる各被監視サーバ１の異常スコアと管理用異常情報とに基づく監視情報を管理画面３１に表示する。
図７は、本実施形態における監視端末３の管理画面３１に表示される監視情報の一例を示す図である。図７に示す監視情報には、各被監視サーバ１の異常スコアを示すテーブル７１、相関異常マップ７２、実測データグラフ７３が含まれている。テーブル７１は、サーバ識別子及びその異常スコアのカラムを持つ。テーブル７１の行は、異常スコアに応じて整列されていてもよい。また、テーブル７１の行の数は、管理者が決めた数に限定されていてもよい。これにより、管理者は分析の結果もっとも異常の可能性の高い被監視サーバ１を容易に把握することができる。
相関異常マップ７２には、各階層と各被監視サーバ１との関係が矩形のエリアで表される。そして、各被監視サーバ１のエリア内にメトリックを表す円が表示され、異常が検出されたメトリック間に直線が描画される。実データグラフ７３には、異常が検出された両メトリックの実測データを時系列で示したグラフと、障害検出部２６によって算出された、実測データと相関モデルとの差分を示したグラフが含まれる。
ここで、本実施形態のサーバ運用管理装置２は、論理構成情報記憶部２５を含み、波及判定部２７が、論理構成情報記憶部２５に予め記憶された論理構成情報を基に各被監視サーバ１が属する階層（サーバグループ）を同定する。しかしながら、これに限らず、サーバ運用管理装置２が論理構成情報記憶部２５を含まずに、波及判定部２７が、上述した各被監視サーバ１の性能情報に含まれるサーバ識別子から、各被監視サーバ１が所属する階層を判別してもよい。例えば、波及判定部２７は、性能情報に含まれるサーバ識別子が「Ｗｅｂ２」であれば、「Ｗｅｂ」部分が同じ「Ｗｅｂ１」及び「Ｗｅｂ３」と同一階層に属すると判別してもよい。
本実施形態のサーバ運用管理装置２によれば、波及判定部２７により同一階層の被監視サーバ１に共通する異常項目を他階層からの波及により生じたものとして除外し、残りの異常項目を管理用異常情報として表示するため、階層間の異常の波及による障害発生源の埋没を解消することができる。また、サーバ間のメトリック数の違いに左右されない指標である異常スコアを被監視サーバ１毎に算出するため、管理者は障害発生源である可能性が大きい被監視サーバ１を容易に特定することができる。
次に、本実施形態におけるサーバ運用管理装置２の動作について説明する。ここで、以下の動作説明は、本発明のサーバ運用管理方法の実施形態の説明でもある。
図８は、本実施形態のサーバ運用管理装置２の性能情報収集動作を示すフローチャートである。図８に示すように、まず、性能情報収集部２１が、予め一定間隔（例えば１分間隔）で設定された収集時刻になったか否かを判断し（図８のステップＳ８１）、収集時刻になったと判断すると被監視サーバ１にアクセスして性能情報を取得する（図８のステップＳ８２）。そして、この取得された被監視サーバ１の性能情報を性能情報蓄積部２２が記憶する（図８のステップＳ８３）。続いて、性能情報収集部２１が、論理構成情報記憶部２５の論理構成情報を参照して全ての被監視サーバ１から性能情報を取得したか否かを判断し（図８のステップＳ８４）、全ての被監視サーバ１から性能情報を取得した場合、次の収集時刻まで待機する。
次に、図９は、本実施形態のサーバ運用管理装置２の相関モデル生成動作を示すフローチャートである。
まず、相関モデル生成部２３が、監視端末３からの指示に従って、性能情報蓄積部２２に蓄積された一定期間分（例えば、１週間分）の正常な各被監視サーバ１の性能情報を読み出す（図９のステップＳ９１）。相関モデル生成部２３は、被監視サーバ１毎に、２つの性能指標の組み合わせ毎に、当該性能指標の実測データ間の相関関係を示す変換関数を相関モデルとして生成する（図９のステップＳ９２）。この生成された各相関モデルを相関モデル記憶部２４が記憶する（図９のステップＳ９３）。そして、相関モデル生成部２３は、すべての被監視サーバ１について相関モデルを生成したら（図９のステップＳ９４のはい）、相関モデル生成動作を終了する。
次に、図１０は、本実施形態のサーバ運用管理装置２の管理用異常情報検出動作を示すフローチャートである。
まず、障害検出部２６が、監視端末３に指定された調査対象期間（例えば、１週間）に含まれる測定時刻毎の各被監視サーバ１の性能情報を性能情報蓄積部２２から読み出す（図１０のステップＳ１０１）。障害検出部２６は、その各性能指標の実測データの組み合わせが、対応する相関モデル（変換関数）を一定の誤差範囲内で満たすか否かを判定し、否と判定された性能指標の組み合わせを異常項目として検出する（図１０のステップＳ１０２）。
続いて、波及判定部２７が、論理構成情報を参照して、障害検出部２６によって検出された各被監視サーバ１の異常項目から、同一階層の全被監視サーバ１間で共通する異常項目を抽出する（図１０のステップＳ１０３）。波及判定部２７は、各被監視サーバ１の異常項目から、この抽出した共通の異常項目を除外した残りの異常項目を示す管理用異常情報を生成する（図１０のステップＳ１０４）。そして、波及判定部２７は、全ての階層について管理用異常情報を生成した場合に（図１０のステップＳ１０５のはい）、その管理用異常情報を異常スコア計算部２８へ出力する（図１０のステップＳ１０６）。
これにより、同一階層の全被監視サーバ２に共通する異常項目を他階層からの波及により生じたものとして除外し、残りの異常項目を管理用異常情報とするので、階層間の異常の波及による異常発生源の埋没を抑制することができる。
次に、図１１は、本実施形態のサーバ運用管理装置２の異常スコア算出動作を示すフローチャートである。
まず、異常スコア計算部２８が、波及判定部２７から入力された管理用異常情報に基づいて、被監視サーバ１毎に異常項目数を計数する（図１１のステップＳ１１１）。異常スコア計算部２８は、相関モデル記憶部２４に記憶されている相関モデルを参照して、被監視サーバ１毎に相関モデル数を計数する（図１１のステップＳ１１２）。続いて、異常スコア計算部２８は、被監視サーバ１毎に異常項目数の相関モデル数に対する割合を異常スコアとして算出する（図１１のステップＳ１１３）。
そして、全ての被監視サーバ１について異常スコアを算出した場合に（図１１のステップＳ１１４のはい）、各被監視サーバ１の異常スコアを監視端末３へ出力する（図１１のステップＳ１１５）。
これにより、各被監視サーバ１についてメトリック数に応じた異常スコアを算出できるため、メトリック数に左右されず、異常が集中している被監視サーバ１を判定し、正確な原因候補のランキングを得ることが出来る。
ここで、上述したサーバ運用管理装置２における、性能情報収集部２１、相関モデル生成部２３、障害検出部２６、波及判定部２７、及び異常スコア計算部２８については、その機能内容をプログラム化して、コンピュータに実行させるように構成してもよい。
次に、本実施形態の特徴的な構成について説明する。図１２は、本実施形態の特徴的な構成を示すブロック図である。
運用管理装置は、障害検出部２６と、波及判定部２７とを含む。
ここで、障害検出部２６は、共通の装置に接続された複数の被監視対象装置の各々を対象に、複数の性能指標について計測値を取得し、複数の被監視対象装置の各々における計測値が異常な性能指標を異常項目として検出する。波及判定部２７は、複数の被監視対象装置の各々の異常項目から、複数の被監視対象装置の全てにおいて検出された異常項目を除外して、残った異常項目を出力する。
以上のように、本実施形態のサーバ運用管理装置２は、負荷分散クラスタサーバ群の特徴を利用して、サーバグループ毎に発生した異常の類似性を判定し、サーバグループ間に発生する異常の波及を特定し、異常情報の補正を行うため、管理者は、異常原因を容易に判別できる。
本実施形態のサーバ運用管理装置２は、多階層システムにおける複数の被監視サーバ１から異常を検出した場合に、各被監視サーバ１の異常項目から、同一階層の全被監視サーバ１に共通する異常項目を他階層のサーバからの波及により生じたものとして除外し、残りの異常項目を管理用異常情報とするため、障害発生源の被監視サーバ１の異常項目を相対的に多くして、障害発生源の埋没を抑えることができる。よって、管理者は分析の結果もっとも異常の可能性の高い被監視サーバ１を容易に把握することができ、多階層システムで発生した異常の原因解明を正確且つ迅速に実施することができる。
また、上述の特開２００９−１９９５３３号公報等に開示された関連技術では、多階層システムにおいて、障害発生源のサーバのメトリック数が少数であった場合に、障害の原因が埋没してしまう問題があった。
例えば、アプリケーションサーバとデータベースサーバとの間では、ディスク搭載数の違い、ソフトウェアの監視項目数の違いにより、何倍ものメトリック数の違いがあり、各階層のサーバグループ間では、メトリック数に相対的に大きな差異がある。ここで、メトリック総数が相対的に少ないサーバが障害の発生源である場合、その障害発生源のサーバは、異常メトリック数の上限が他に比べて少ないため、全てのメトリックが異常を示していても、障害が波及した他のサーバより異常メトリック数が少ない。管理者は、通常、異常メトリック数の絶対数が多いサーバから調査するため、障害発生源のサーバの異常は他のサーバ群に埋没してしまう。このため、管理者は誤ったサーバに着目してしまい、結果として異常原因を見誤る。
本実施形態のサーバ運用管理装置２は、被監視サーバ１毎にメトリック数に応じた異常スコアを算出するため、相対的にメトリック数の少ない被監視サーバ１の分析をシームレスに可能にし、各被監視サーバ１間のメトリック数の違いに左右されず、異常が集中している被監視サーバ１を特定し、正確な原因候補のランキングを得ることができる。これにより、管理者は正確且つ迅速な障害箇所の特定が可能となる。
以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
例えば、上記実施形態では、障害検出部２６が、２つの性能指標の計測値が当該２つの性能指標に対応する相関モデルを満足していない場合、当該２つの性能指標の組み合わせを異常項目として検出している。しかしながら、障害検出部２６は、各性能指標の計測値を所定の閾値と比較する等により、各性能指標が異常かどうかを判定し、異常と判定された各性能指標を異常項目として出力してもよい。
この出願は、２０１０年１月８日に出願された日本出願特願２０１０−００３００８を基礎とする優先権を主張し、その開示の全てをここに取り込む。
本発明は、多階層システムにおける各サーバの稼働状況を監視する技術に適用可能である
１ 被監視サーバ
２ サーバ運用管理装置
３ 監視端末
２１ 性能情報収集部
２２ 性能情報蓄積部
２３ 相関モデル生成部
２４ 相関モデル記憶部
２５ 論理構成情報記憶部
２６ 障害検出部
２７ 波及判定部
２８ 異常スコア計算部
２９ 通信制御部
３１ 管理画面
２ サーバ運用管理装置
３ 監視端末
２１ 性能情報収集部
２２ 性能情報蓄積部
２３ 相関モデル生成部
２４ 相関モデル記憶部
２５ 論理構成情報記憶部
２６ 障害検出部
２７ 波及判定部
２８ 異常スコア計算部
２９ 通信制御部
３１ 管理画面
Claims (12)
- 共通の装置に接続された複数の被監視対象装置の各々を対象に、複数の性能指標について計測値を取得し、前記複数の被監視対象装置の各々における計測値が異常な前記性能指標を異常項目として検出する障害検出手段と、
前記複数の被監視対象装置の各々の前記異常項目から、前記複数の被監視対象装置の全てにおいて検出された前記異常項目を除外して、残った前記異常項目を出力する波及判定手段と
を含む運用管理装置。 - さらに、前記複数の被監視対象装置の各々について、前記複数の性能指標の内の異なる２つの性能指標毎に、当該２つの性能指標間の相関関係を示す変換関数を記憶する相関モデル記憶手段を含み、
前記障害検出手段は、前記複数の性能指標の内の２つの性能指標の一方の計測値を、当該２つの性能指標に対応する変換関数に入力して得られた値と、他方の計測値との差分が所定値以上の場合、当該２つの性能指標を前記異常項目として検出する
請求項１に記載の運用管理装置。 - さらに、前記複数の被監視対象装置の各々について、前記波及判定手段により出力された前記異常項目の数の、当該被監視装置の前記変換関数の数に対する割合を、異常スコアとして出力する異常スコア算出手段を含む
請求項２に記載の運用管理装置。 - さらに、
前記複数の被監視対象装置の各々において計測された、前記複数の性能指標についての計測値を時系列に記憶する性能情報蓄積手段と、
前記性能情報蓄積手段に記憶された所定期間の前記複数の性能指標の計測値をもとに前記変換関数を生成し、相関モデル記憶手段に保存する相関モデル生成手段と
を含む請求項３に記載の運用管理装置。 - 共通の装置に接続された複数の被監視対象装置の各々を対象に、複数の性能指標について計測値を取得し、前記複数の被監視対象装置の各々における計測値が異常な前記性能指標を異常項目として検出し、
前記複数の被監視対象装置の各々の前記異常項目から、前記複数の被監視対象装置の全てにおいて検出された前記異常項目を除外して、残った前記異常項目を出力する
運用管理方法。 - さらに、前記複数の被監視対象装置の各々について、前記複数の性能指標の内の異なる２つの性能指標毎に、当該２つの性能指標間の相関関係を示す変換関数を記憶し、
前記異常項目を検出する場合、前記複数の性能指標の内の２つの性能指標の一方の計測値を、当該２つの性能指標に対応する変換関数に入力して得られた値と、他方の計測値との差分が所定値以上の場合、当該２つの性能指標を前記異常項目として検出する
請求項５に記載の運用管理方法。 - さらに、前記複数の被監視対象装置の各々について、前記異常項目の数の、当該被監視装置の前記変換関数の数に対する割合を、異常スコアとして出力する
請求項６に記載の運用管理方法。 - さらに、
前記複数の被監視対象装置の各々において計測された、前記複数の性能指標についての計測値を時系列に記憶し、
所定期間の前記複数の性能指標の計測値をもとに前記変換関数を生成する
請求項７に記載の運用管理方法。 - コンピュータに、
共通の装置に接続された複数の被監視対象装置の各々を対象に、複数の性能指標について計測値を取得し、前記複数の被監視対象装置の各々における計測値が異常な前記性能指標を異常項目として検出し、
前記複数の被監視対象装置の各々の前記異常項目から、前記複数の被監視対象装置の全てにおいて検出された前記異常項目を除外して、残った前記異常項目を出力する
処理を実行させる運用管理プログラムを記録したプログラム記録媒体。 - さらに、前記複数の被監視対象装置の各々について、前記複数の性能指標の内の異なる２つの性能指標毎に、当該２つの性能指標間の相関関係を示す変換関数を記憶し、
前記異常項目を検出する場合、前記複数の性能指標の内の２つの性能指標の一方の計測値を、当該２つの性能指標に対応する変換関数に入力して得られた値と、他方の計測値との差分が所定値以上の場合、当該２つの性能指標を前記異常項目として検出する
前記運用管理プログラムを記録した請求項９に記載のプログラム記録媒体。 - さらに、前記複数の被監視対象装置の各々について、前記異常項目の数の、当該被監視装置の前記変換関数の数に対する割合を、異常スコアとして出力する
前記運用管理プログラムを記録した請求項１０に記載のプログラム記録媒体。 - さらに、
前記複数の被監視対象装置の各々において計測された、前記複数の性能指標についての計測値を時系列に記憶し、
所定期間の前記複数の性能指標の計測値をもとに前記変換関数を生成する
前記運用管理プログラムを記録した請求項１１に記載のプログラム記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2011548953A JP5267684B2 (ja) | 2010-01-08 | 2010-12-15 | 運用管理装置、運用管理方法、及びプログラム記憶媒体 |
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2010003008 | 2010-01-08 | ||
| JP2010003008 | 2010-01-08 | ||
| JP2011548953A JP5267684B2 (ja) | 2010-01-08 | 2010-12-15 | 運用管理装置、運用管理方法、及びプログラム記憶媒体 |
| PCT/JP2010/073058 WO2011083687A1 (ja) | 2010-01-08 | 2010-12-15 | 運用管理装置、運用管理方法、及びプログラム記憶媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPWO2011083687A1 JPWO2011083687A1 (ja) | 2013-05-13 |
| JP5267684B2 true JP5267684B2 (ja) | 2013-08-21 |
Family
ID=44305424
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2011548953A Expired - Fee Related JP5267684B2 (ja) | 2010-01-08 | 2010-12-15 | 運用管理装置、運用管理方法、及びプログラム記憶媒体 |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US8645769B2 (ja) |
| EP (1) | EP2523115B1 (ja) |
| JP (1) | JP5267684B2 (ja) |
| CN (1) | CN102713861B (ja) |
| WO (1) | WO2011083687A1 (ja) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2016136198A1 (ja) * | 2015-02-25 | 2016-09-01 | 日本電気株式会社 | システム監視装置、システム監視方法、及び、システム監視プログラムが記録された記録媒体 |
| US10719380B2 (en) | 2014-12-22 | 2020-07-21 | Nec Corporation | Operation management apparatus, operation management method, and storage medium |
| JPWO2019073512A1 (ja) * | 2017-10-10 | 2020-10-22 | 日本電気株式会社 | システム分析方法、システム分析装置、および、プログラム |
Families Citing this family (43)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9389946B2 (en) | 2011-09-19 | 2016-07-12 | Nec Corporation | Operation management apparatus, operation management method, and program |
| US9081834B2 (en) | 2011-10-05 | 2015-07-14 | Cumulus Systems Incorporated | Process for gathering and special data structure for storing performance metric data |
| US20130091266A1 (en) | 2011-10-05 | 2013-04-11 | Ajit Bhave | System for organizing and fast searching of massive amounts of data |
| US9081829B2 (en) | 2011-10-05 | 2015-07-14 | Cumulus Systems Incorporated | System for organizing and fast searching of massive amounts of data |
| EP2808797B1 (en) * | 2012-01-23 | 2019-07-31 | NEC Corporation | Operation management device, operation management method, and program |
| JP5508449B2 (ja) * | 2012-02-06 | 2014-05-28 | 日本電信電話株式会社 | リソース監視装置、リソース監視システム、リソース監視方法及びリソース監視プログラム |
| CN104956373A (zh) * | 2012-12-04 | 2015-09-30 | 惠普发展公司，有限责任合伙企业 | 确定异常网络行为的可疑根本原因 |
| US10311172B2 (en) | 2013-03-13 | 2019-06-04 | Nec Corporation | System analysis device and system analysis method |
| US20150200820A1 (en) * | 2013-03-13 | 2015-07-16 | Google Inc. | Processing an attempted loading of a web resource |
| WO2015137481A1 (ja) * | 2014-03-14 | 2015-09-17 | Ｎｅｃフィールディング株式会社 | 情報提供装置、情報提供システム、情報提供方法、及びプログラム |
| DE102014208034A1 (de) * | 2014-04-29 | 2015-10-29 | Siemens Aktiengesellschaft | Verfahren zum Bereitstellen von zuverlässigen Sensordaten |
| US10904312B2 (en) * | 2014-12-10 | 2021-01-26 | Akamai Technologies, Inc. | Server-side prediction of media client steady state |
| US10031831B2 (en) | 2015-04-23 | 2018-07-24 | International Business Machines Corporation | Detecting causes of performance regression to adjust data systems |
| US11200529B2 (en) * | 2015-08-06 | 2021-12-14 | Ns Solutions Corporation | Information processing apparatus, information processing system, information processing method and non-transitory computer readable recording medium |
| US10404791B2 (en) * | 2015-12-04 | 2019-09-03 | Microsoft Technology Licensing, Llc | State-aware load balancing of application servers |
| US10885461B2 (en) | 2016-02-29 | 2021-01-05 | Oracle International Corporation | Unsupervised method for classifying seasonal patterns |
| US10331802B2 (en) | 2016-02-29 | 2019-06-25 | Oracle International Corporation | System for detecting and characterizing seasons |
| US10699211B2 (en) | 2016-02-29 | 2020-06-30 | Oracle International Corporation | Supervised method for classifying seasonal patterns |
| US11113852B2 (en) | 2016-02-29 | 2021-09-07 | Oracle International Corporation | Systems and methods for trending patterns within time-series data |
| JP6881434B2 (ja) * | 2016-03-30 | 2021-06-02 | 日本電気株式会社 | ログ分析装置、ログ分析方法及びプログラム |
| US9705751B1 (en) * | 2016-03-31 | 2017-07-11 | Sas Institute Inc. | System for calibrating and validating parameters for optimization |
| US10198339B2 (en) | 2016-05-16 | 2019-02-05 | Oracle International Corporation | Correlation-based analytic for time-series data |
| US10635563B2 (en) | 2016-08-04 | 2020-04-28 | Oracle International Corporation | Unsupervised method for baselining and anomaly detection in time-series data for enterprise systems |
| US11082439B2 (en) | 2016-08-04 | 2021-08-03 | Oracle International Corporation | Unsupervised method for baselining and anomaly detection in time-series data for enterprise systems |
| US10915830B2 (en) | 2017-02-24 | 2021-02-09 | Oracle International Corporation | Multiscale method for predictive alerting |
| US10949436B2 (en) | 2017-02-24 | 2021-03-16 | Oracle International Corporation | Optimization for scalable analytics using time series models |
| EP3611489B1 (en) * | 2017-04-13 | 2023-07-05 | NTN Corporation | State monitoring device, state monitoring system, and state monitoring method |
| US10817803B2 (en) | 2017-06-02 | 2020-10-27 | Oracle International Corporation | Data driven methods and systems for what if analysis |
| JP6829158B2 (ja) * | 2017-07-18 | 2021-02-10 | 株式会社東芝 | データ処理装置、データ処理方法、およびプログラム |
| JP6904418B2 (ja) | 2017-08-02 | 2021-07-14 | 日本電気株式会社 | 情報処理装置、情報処理システム、情報処理方法、及び、プログラム |
| JP6835763B2 (ja) * | 2018-03-08 | 2021-02-24 | 富士通フロンテック株式会社 | メッセージ監視サーバ、方法、プログラム |
| CN108923952B (zh) * | 2018-05-31 | 2021-11-30 | 北京百度网讯科技有限公司 | 基于服务监控指标的故障诊断方法、设备及存储介质 |
| US10963346B2 (en) | 2018-06-05 | 2021-03-30 | Oracle International Corporation | Scalable methods and systems for approximating statistical distributions |
| US10997517B2 (en) | 2018-06-05 | 2021-05-04 | Oracle International Corporation | Methods and systems for aggregating distribution approximations |
| US11640459B2 (en) | 2018-06-28 | 2023-05-02 | Nec Corporation | Abnormality detection device |
| US10938623B2 (en) * | 2018-10-23 | 2021-03-02 | Hewlett Packard Enterprise Development Lp | Computing element failure identification mechanism |
| US11138090B2 (en) | 2018-10-23 | 2021-10-05 | Oracle International Corporation | Systems and methods for forecasting time series with variable seasonality |
| US10855548B2 (en) | 2019-02-15 | 2020-12-01 | Oracle International Corporation | Systems and methods for automatically detecting, summarizing, and responding to anomalies |
| US11533326B2 (en) | 2019-05-01 | 2022-12-20 | Oracle International Corporation | Systems and methods for multivariate anomaly detection in software monitoring |
| US11537940B2 (en) | 2019-05-13 | 2022-12-27 | Oracle International Corporation | Systems and methods for unsupervised anomaly detection using non-parametric tolerance intervals over a sliding window of t-digests |
| US11887015B2 (en) | 2019-09-13 | 2024-01-30 | Oracle International Corporation | Automatically-generated labels for time series data and numerical lists to use in analytic and machine learning systems |
| US11892930B2 (en) * | 2021-04-29 | 2024-02-06 | Hewlett-Packard Development Company, L.P. | Performance metric calculations |
| US20230237178A1 (en) * | 2022-01-24 | 2023-07-27 | Sap Se | Providing database performance report in restricted environment |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4112191B2 (ja) | 2001-05-14 | 2008-07-02 | 日本電信電話株式会社 | 分散サーバシステム、障害復旧方法、障害復旧プログラムおよび記録媒体 |
| JP2003263342A (ja) | 2002-03-07 | 2003-09-19 | Telecommunication Advancement Organization Of Japan | 情報処理装置の監視装置および監視方法並びにそのプログラム |
| US7444263B2 (en) * | 2002-07-01 | 2008-10-28 | Opnet Technologies, Inc. | Performance metric collection and automated analysis |
| JP4412031B2 (ja) | 2004-03-31 | 2010-02-10 | 日本電気株式会社 | ネットワーク監視システム及びその方法、プログラム |
| JP4980581B2 (ja) * | 2004-04-16 | 2012-07-18 | 新日鉄ソリューションズ株式会社 | 性能監視装置、性能監視方法及びプログラム |
| US7349746B2 (en) * | 2004-09-10 | 2008-03-25 | Exxonmobil Research And Engineering Company | System and method for abnormal event detection in the operation of continuous industrial processes |
| US20060200726A1 (en) | 2005-03-03 | 2006-09-07 | Seagate Technology Llc | Failure trend detection and correction in a data storage array |
| JP5105218B2 (ja) * | 2005-06-06 | 2012-12-26 | トヨタ自動車株式会社 | 異常判定装置 |
| US7246043B2 (en) * | 2005-06-30 | 2007-07-17 | Oracle International Corporation | Graphical display and correlation of severity scores of system metrics |
| JP4725724B2 (ja) * | 2005-10-27 | 2011-07-13 | 日本電気株式会社 | クラスタ障害推定システム |
| JP2007207173A (ja) | 2006-02-06 | 2007-08-16 | Fujitsu Ltd | 性能分析プログラム、性能分析方法、および性能分析装置 |
| JP4573179B2 (ja) | 2006-05-30 | 2010-11-04 | 日本電気株式会社 | 性能負荷異常検出システム、性能負荷異常検出方法、及びプログラム |
| JP4859558B2 (ja) | 2006-06-30 | 2012-01-25 | 株式会社日立製作所 | コンピュータシステムの制御方法及びコンピュータシステム |
| JP5123641B2 (ja) * | 2007-10-31 | 2013-01-23 | 株式会社日立製作所 | 性能履歴の管理方法および性能履歴の管理システム |
| JP4872944B2 (ja) | 2008-02-25 | 2012-02-08 | 日本電気株式会社 | 運用管理装置、運用管理システム、情報処理方法、及び運用管理プログラム |
| JP2010003008A (ja) | 2008-06-18 | 2010-01-07 | Fujitsu Ltd | 検出プログラム、検出装置および検出方法 |
-
2010
- 2010-12-15 US US13/133,719 patent/US8645769B2/en not_active Expired - Fee Related
- 2010-12-15 JP JP2011548953A patent/JP5267684B2/ja not_active Expired - Fee Related
- 2010-12-15 EP EP10842200.7A patent/EP2523115B1/en active Active
- 2010-12-15 WO PCT/JP2010/073058 patent/WO2011083687A1/ja active Application Filing
- 2010-12-15 CN CN201080060935.9A patent/CN102713861B/zh not_active Expired - Fee Related
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10719380B2 (en) | 2014-12-22 | 2020-07-21 | Nec Corporation | Operation management apparatus, operation management method, and storage medium |
| WO2016136198A1 (ja) * | 2015-02-25 | 2016-09-01 | 日本電気株式会社 | システム監視装置、システム監視方法、及び、システム監視プログラムが記録された記録媒体 |
| JPWO2016136198A1 (ja) * | 2015-02-25 | 2017-12-07 | 日本電気株式会社 | システム監視装置、システム監視方法、及び、システム監視プログラム |
| US10539468B2 (en) | 2015-02-25 | 2020-01-21 | Nec Corporation | Abnormality detection apparatus, abnormality detection method, and non-transitory computer-readable medium |
| JPWO2019073512A1 (ja) * | 2017-10-10 | 2020-10-22 | 日本電気株式会社 | システム分析方法、システム分析装置、および、プログラム |
| US11378944B2 (en) | 2017-10-10 | 2022-07-05 | Nec Corporation | System analysis method, system analysis apparatus, and program |
Also Published As
| Publication number | Publication date |
|---|---|
| CN102713861B (zh) | 2015-09-23 |
| CN102713861A (zh) | 2012-10-03 |
| EP2523115A4 (en) | 2015-08-12 |
| EP2523115B1 (en) | 2020-05-06 |
| EP2523115A1 (en) | 2012-11-14 |
| JPWO2011083687A1 (ja) | 2013-05-13 |
| US8645769B2 (en) | 2014-02-04 |
| US20120278663A1 (en) | 2012-11-01 |
| WO2011083687A1 (ja) | 2011-07-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5267684B2 (ja) | 運用管理装置、運用管理方法、及びプログラム記憶媒体 | |
| JP6394726B2 (ja) | 運用管理装置、運用管理方法、及びプログラム | |
| US9672085B2 (en) | Adaptive fault diagnosis | |
| US10303533B1 (en) | Real-time log analysis service for integrating external event data with log data for use in root cause analysis | |
| JP4859558B2 (ja) | コンピュータシステムの制御方法及びコンピュータシステム | |
| JP5874936B2 (ja) | 運用管理装置、運用管理方法、及びプログラム | |
| JP5267736B2 (ja) | 障害検出装置、障害検出方法およびプログラム記録媒体 | |
| US9424157B2 (en) | Early detection of failing computers | |
| US8375251B2 (en) | Monitoring and healing a computing system | |
| WO2016103650A1 (ja) | 運用管理装置、運用管理方法、及び、運用管理プログラムが記録された記録媒体 | |
| US20160378583A1 (en) | Management computer and method for evaluating performance threshold value | |
| JP6190468B2 (ja) | 管理システム、プラン生成方法、およびプラン生成プログラム | |
| JP6521096B2 (ja) | 表示方法、表示装置、および、プログラム | |
| JP6009089B2 (ja) | 計算機システムを管理する管理システム及びその管理方法 | |
| US9021078B2 (en) | Management method and management system | |
| JP6252309B2 (ja) | 監視漏れ特定処理プログラム，監視漏れ特定処理方法及び監視漏れ特定処理装置 | |
| JP7032640B2 (ja) | 影響範囲特定プログラム、影響範囲特定方法、および影響範囲特定装置 | |
| US20210208962A1 (en) | Failure detection and correction in a distributed computing system | |
| AU2014200806B1 (en) | Adaptive fault diagnosis | |
| WO2015145676A1 (ja) | 監視計算機および監視方法 | |
| JP2023136444A (ja) | 解析プログラム、解析方法、および情報処理システム | |
| CA2843004C (en) | Adaptive fault diagnosis |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20130409 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20130422 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 5267684 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |