JP2022133094A - 異常要因判定方法および異常要因判定プログラム - Google Patents

Abstract

【課題】異常発生要因の判定時間を短縮する。【解決手段】メトリックＭ１に基づいて時刻Ｔ５に異常が検知された場合、他のメトリックＭ２～Ｍ４の中から、時刻Ｔ５の直前において対応するリソースが不使用状態であることを示すメトリックＭ２，Ｍ３を特定し、時刻Ｔ５の直前から過去に遡って対応するリソースが不使用状態から使用状態に変化する時刻をメトリックＭ２，Ｍ３のそれぞれについて特定し、それらのうち最も古い時刻Ｔ１から時刻Ｔ５までを検索期間として指定して、情報処理システムに対して実行されたイベントのログが蓄積されたデータベースから、検索期間において実行された、メトリックＭ１に基づく異常の要因候補となる候補イベントのログ５を取得し、取得したログ５が示す候補イベントに基づいてメトリックＭ１に基づく異常の発生要因を判定する。【選択図】図１

Description

本発明は、異常要因判定方法および異常要因判定プログラムに関する。

情報処理システムの動作状況を監視装置によって監視して、異常の発生を検知できるようにする技術は、広く普及している。異常の発生を検知する方法としては、例えば、情報処理システムに含まれるリソースの使用状況を示すメトリックを用いる方法がある。また、このような異常検知技術では、異常が検知された場合に、その異常の発生要因を判定することが求められる。異常の発生要因を判定する方法としては、例えば、情報処理システムに対して実行されたイベントのログを解析する方法が挙げられる。

また、情報処理システムの監視や異常要因の解析に関しては、次のような技術が提案されている。例えば、監視対象システムから継続的に監視データを取得してシステムの挙動をモデル化した挙動モデルを作成し、連続して作成された挙動モデルの差に基づいて挙動が変化した期間を推測し、ユーザに通知する障害分析システムが提案されている。また、システム内の機器の入出力とアプリケーションプログラムの変数との対応を示す変数リレーション情報を生成し、機器の異常発生を検知すると、当該機器の入出力に関する変数を変数リレーション情報に基づいて特定し、特定された変数に関連するイベントの情報を発生イベント情報から抽出して表示する異常解析支援システムも提案されている。

国際公開ＷＯ２０１４／１８４９３４号 特開２０１７－２２７９７３号公報

ところで、上記のような監視装置が、情報処理システムの異常が検知すると、情報処理システムに対して実行されたイベントのログを取得し、取得したログの内容に基づいて異常の発生要因を判定することが考えられている。通常、異常が検知された場合、その異常発生要因となり得るイベントは、検知時刻の直前に実行されていることが多い。しかし、イベントの実行によって異常が発生してから、その異常が検知されるまでに長い時間がかかるケースもある。このようなケースでは、異常発生要因となり得るイベントのログをデータベースから検索する検索期間を、異常が検知された時刻を終端とする長い期間に設定しないと、適切なイベントのログを取得できない。しかし、検索期間が長くなるほど、検索対象となるログの数が増大し、検索にかかる時間が長くなって、その結果として異常発生要因の判定にかかる時間が長くなるという問題がある。

１つの側面では、本発明は、異常発生要因の判定時間を短縮することが可能な異常要因判定方法および異常要因判定プログラムを提供することを目的とする。

１つの案では、コンピュータが、それぞれ情報処理システムに含まれるリソースの使用状況を示す複数のメトリックのうち、第１のメトリックに基づいて第１の時刻に異常が検知された場合、複数のメトリックのうち第１のメトリックを除くメトリックの中から、第１の時刻の直前において対応するリソースが不使用状態であることを示す１以上の第２のメトリックを特定し、１以上の第２のメトリックのそれぞれが示す使用状況に基づき、第１の時刻の直前から過去に遡って対応するリソースが不使用状態から使用状態に変化する第２の時刻を１以上の第２のメトリックのそれぞれについて特定し、特定された第２の時刻のうち最も古い第３の時刻から第１の時刻までを検索期間として指定して、情報処理システムに対して実行されたイベントのログが蓄積されたデータベースから、検索期間において実行された、第１のメトリックに基づく異常の要因候補となる候補イベントのログを取得し、取得したログが示す候補イベントに基づいて第１のメトリックに基づく異常の発生要因を判定する、異常要因判定方法が提供される。

また、１つの案では、上記の異常要因判定方法と同様の処理をコンピュータに実行させる異常要因判定プログラムが提供される。

１つの側面では、異常発生要因の判定時間を短縮できる。

第１の実施の形態に係る異常要因判定装置を示す図である。 第２の実施の形態に係る情報処理システムの構成例を示す図である。 監視装置のハードウェア構成例を示す図である。 運用管理装置および監視装置が備える処理機能の構成例を示す図である。 メトリックデータベースのデータ構成例を示す図である。 判定ルールデータベースのデータ構成例を示す図である。 判定結果データベースのデータ構成例を示す図である。 異常発生の要因判定処理についての比較例を示す第１の図である。 異常発生の要因判定処理についての比較例を示す第２の図である。 第２の実施の形態における異常発生の要因判定処理を示す図である。 第２の実施の形態における監視装置の処理手順を示すフローチャートの例である。 変形例における異常発生の要因判定処理を示す図である。 変形例における監視装置の処理手順を示すフローチャートの例である。

以下、本発明の実施の形態について図面を参照して説明する。
〔第１の実施の形態〕
図１は、第１の実施の形態に係る異常要因判定装置を示す図である。図１に示す異常要因判定装置１は、図示しない情報処理システムの動作状況を監視し、異常が検知された場合にその異常の発生要因を判定する装置である。異常要因判定装置１は、例えば、サーバ装置やパーソナルコンピュータなどのコンピュータとして実現される。この場合、以下で説明する異常要因判定装置１の処理は、例えば、異常要因判定装置１が備えるプロセッサが所定のプログラムを実行することで実現される。

異常要因判定装置１は、メトリックデータベース（ＤＢ）２からメトリックを取得可能になっている。メトリックデータベース２には、それぞれ上記の情報処理システムに含まれるリソースの使用状況を示す複数のメトリックが、情報処理システムから逐次収集されて蓄積される。例えば、対応するリソースがＣＰＵ（Central Processing Unit）の場合、メトリックとしてはＣＰＵ使用率、ＣＰＵ待ち時間などがある。対応するリソースがメモリの場合、メトリックとしてはメモリ使用量、メモリスワップアウト量などがある。対応するリソースがネットワークインタフェースの場合、メトリックとしてはネットワーク使用量、パケットロス数などがある。

異常要因判定装置１は、メトリックデータベース２に蓄積された複数のメトリックの中から、特定のメトリックを定期的に取得し、取得したメトリックの値に基づいて情報処理システムにおける異常を検知できる。また、異常要因判定装置１は、異常を検知した場合に、その異常の発生要因を判定するためにメトリックデータベース２内の他のメトリックを取得することもできる。

また、イベントログデータベース（ＤＢ）３には、情報処理システムに対して実行されたイベントのログが蓄積される。異常要因判定装置１は、検知された異常の発生要因を判定するために、検索条件を指定して、検索条件に合致するイベントのログをイベントログデータベース３から取得できる。なお、イベントログデータベース３に対する検索処理自体は、異常要因判定装置１で実行されてもよいし、異常要因判定装置１の外部に接続された他の装置で実行されてもよい。

一方、図１の右側に示すタイムチャート４は、あるメトリックに基づいて異常が検知された場合における他のメトリックやイベントの状況の例を示す。以下、このタイムチャート４に示された例を用いて、異常要因判定装置１の処理を説明する。

異常要因判定装置１は、メトリックデータベース２に蓄積されたメトリックのうち、１以上の特定のメトリックに基づいて、情報処理システムにおける異常の有無を判定する。ここでは例として、特定のメトリックに基づいて異常の有無を判定する判定処理が、所定時間間隔の判定時刻ごとに実行されるものとする。この場合、ある判定時刻における判定処理は、前回の判定時刻から現判定時刻までの期間にメトリックデータベース２に蓄積されたメトリックに基づいて実行される。

図１のタイムチャート４では、メトリックＭ１（第１のメトリック）に基づいて異常の有無が判定されている例を示している。異常要因判定装置１は、メトリックＭ１から、上記の判定時刻のうち時刻Ｔ１，Ｔ２，Ｔ３，Ｔ４では異常を検知しなかったが、時刻Ｔ５（第１の時刻）で異常を検知したとする（ステップＳ１）。

すると、異常要因判定装置１は、メトリックデータベース２に蓄積された複数のメトリックのうち、メトリックＭ１を除く他のメトリックの中から、時刻Ｔ５の直前において対応するリソースが不使用状態であることを示す１以上のメトリック（第２のメトリック）を特定する。図１のタイムチャート４では、メトリックＭ１を除くメトリックＭ２～Ｍ４の中から、時刻Ｔ５の直前の判定時刻である時刻Ｔ４において対応するリソースが未使用状態であることを示すメトリックＭ２，Ｍ３が特定されたとする（ステップＳ２）。

次に、異常要因判定装置１は、特定されたメトリックＭ２，Ｍ３のそれぞれが示す使用状況に基づき、時刻Ｔ５の直前（ここでは時刻Ｔ４）から過去に遡って対応するリソースが不使用状態から使用状態に変化する時刻（第２の時刻）を、メトリックＭ２，Ｍ３のそれぞれについて特定する（ステップＳ３）。

図１のタイムチャート４では、メトリックＭ２については、時刻Ｔ２から時刻Ｔ１までの期間で対応するリソースが使用状態に変化している。このため、メトリックＭ２についての上記時刻としては時刻Ｔ１が特定される。また、メトリックＭ３については、時刻Ｔ３から時刻Ｔ２までの期間で対応するリソースが使用状態に変化している。このため、メトリックＭ３についての上記時刻としては時刻Ｔ２が特定される。

次に、異常要因判定装置１は、ステップＳ３で特定された時刻Ｔ１，Ｔ２のうち、最も古い時刻Ｔ１を選択し、選択した時刻Ｔ１から、異常が検知された時刻Ｔ５までを検索期間として指定する。そして、異常要因判定装置１は、イベントログデータベース３から、指定された検索期間において実行された、メトリックＭ１に基づく異常の要因候補となる候補イベントのログを取得する（ステップＳ４）。ここで、検知された異常の要因候補となる候補イベントは、例えば、異常検知の元になったメトリックに応じてあらかじめ決められている。

ステップＳ４では、時刻Ｔ１から時刻Ｔ５までの検索期間と候補イベントとを検索条件としてイベントログデータベース３が検索されることで、検索条件に合致する候補イベントのログが取得される。なお、前述のように、イベントログデータベース３の検索処理自体は、異常要因判定装置１で実行されてもよいし、異常要因判定装置１の外部に接続された他の装置で実行されてもよい。

図１のタイムチャート４では、時刻Ｔ２から時刻Ｔ３の期間において、異常の要因となったイベントが実行され、このイベントに対応するログ５がイベントログデータベース３に登録されたとする。この場合、ステップＳ４では、候補イベントのログとしてログ５が取得される。すると、異常要因判定装置１は、ステップＳ４で取得したログ５が示す候補イベントに基づいて、メトリックＭ１に基づく異常の発生要因を判定する（ステップＳ５）。

ここで、情報処理システムの異常が検知された場合、その異常発生要因となり得るイベントは、検知時刻の直前に実行されていることが多い。このようなイベントのログをイベントログデータベース３から取得するためには、ログの検索期間を異常の判定周期に相当する期間に設定すれば十分である。

一方、図１のタイムチャート４に示した例では、ログ５が示すイベントの実行によって異常が発生してから、その異常が検知されるまでに長い時間がかかっている。このようなイベントのログをイベントログデータベース３から取得するためには、ログの検索期間をより長くする必要がある。しかし、ログの検索期間が長くなるほど、検索対象となるログの数が増大し、検索にかかる時間が長くなる。その結果、異常発生要因の判定にかかる時間が長くなってしまう。

異常が発生してから検知されるまでに長い時間がかかるケースとしては、リソースが使用されていない期間において、そのリソースに関する異常が発生しているケースがある。より具体的には、あるイベントの実行によってあるリソースに関する異常が発生したが、その時点ではリソースが使用されておらず、その後にリソースの使用が開始された時点で異常事象が出現し、異常が検知される、というケースがある。

図１のタイムチャート４に示した例では、ログ５が示すイベントが実行されたとき、そのイベントに関係するリソースが使用されておらず、その後に時刻Ｔ５の直前でリソースの使用が開始されたことで、時刻Ｔ５で異常が検知された、と考えることができる。

そこで、異常要因判定装置１は、メトリックＭ１を除く他のメトリックの中から、時刻Ｔ５の直前において対応するリソースが不使用状態であることを示すメトリックＭ２，Ｍ３を特定する。次に、異常要因判定装置１は、特定されたメトリックＭ２，Ｍ３のそれぞれについて、時刻Ｔ５の直前から過去に遡って対応するリソースが不使用状態から使用状態に変化する時刻Ｔ１，Ｔ２を特定する。そして、異常要因判定装置１は、特定された時刻Ｔ１，Ｔ２のうち最も古い時刻を、ログの検索期間の開始時刻に決定する。

このような処理により、異常が検知された時刻Ｔ５の直前まで不使用状態になっていたリソースに関係するイベントのログをすべて検索対象に含めることができるように、検索期間の開始時刻が決定される。これにより、検索期間を必要最小限の長さに設定できる。このため、検索期間の長さを抑制しながら、検知された異常の発生要因となり得る候補イベントのログを取得できる可能性が高まる。したがって、イベントログデータベース３の検索にかかる時間を短縮し、それによって異常要因判定装置１による異常の検知から異常発生要因の判定までにかかる時間を短縮しつつ、その判定精度を高めることができる。

〔第２の実施の形態〕
図２は、第２の実施の形態に係る情報処理システムの構成例を示す図である。図２に示す情報処理システムは、運用管理装置１００と監視装置２００とを含む。

運用管理装置１００は、ＩＣＴ（Information and Communication Technology）インフラストラクチャ１１０の運用を管理する。以下、ＩＣＴインフラストラクチャを「ＩＣＴインフラ」と略称する。ＩＣＴインフラ１１０は、コンピュータやネットワーク機器などの各種の情報処理機器を含む。例えば、ＩＣＴインフラ１１０がクラウドサービスを提供するものである場合、ＩＣＴインフラ１１０には、クラウドサーバとして動作するサーバ装置や、サーバ装置間を接続するネットワーク機器などが含まれる。

運用管理装置１００は、ＩＣＴインフラ１１０に含まれる各情報処理機器に対する、運用管理に関する各種のイベント（運用イベント）を実行する。運用イベントは、ＩＣＴインフラ１１０における各種の構成変更や設定変更を行う処理であり、例えば、サーバ装置上で動作する仮想マシンの作成、削除、マイグレーションや、ドライバなどのプログラムの更新などがある。監視装置２００は、運用イベントを実行するとともに、実行した運用イベントに関するログをデータベースに記録する。

また、運用管理装置１００は、ＩＣＴインフラ１１０に含まれる各情報処理機器の稼働状態を監視し、各情報処理機器からリソースに関するメトリックを収集する。メトリックは、プロセッサやメモリなどの監視対象のリソースの動作状態を示す情報であり、例えば、リソースの動作状態を評価するための尺度を与える。

監視装置２００は、運用管理装置１００を介してＩＣＴインフラ１１０の稼働状態を監視し、異常が検知された場合にはその発生要因を解析する。具体的には、監視装置２００は、運用管理装置１００によって収集されたメトリックを取得し、動作の正常性を判定する。異常が検知された場合、監視装置２００は、運用管理装置１００から運用イベントのログを取得し、異常発生の契機となり得る運用イベントを特定する、監視装置２００は、特定された運用イベントに基づいて異常発生要因を判定する。

図３は、監視装置のハードウェア構成例を示す図である。監視装置２００は、例えば、図３に示すようなコンピュータとして実現される。
図３に示す監視装置２００は、プロセッサ２０１、ＲＡＭ（Random Access Memory）２０２、ＨＤＤ（Hard Disk Drive）２０３、ＧＰＵ（Graphics Processing Unit）２０４、入力インタフェース（Ｉ／Ｆ）２０５、読み取り装置２０６および通信インタフェース（Ｉ／Ｆ）２０７を備える。

プロセッサ２０１は、監視装置２００全体を統括的に制御する。プロセッサ２０１は、例えば、ＣＰＵ、ＭＰＵ（Micro Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）またはＰＬＤ（Programmable Logic Device）である。また、プロセッサ２０１は、ＣＰＵ、ＭＰＵ、ＤＳＰ、ＡＳＩＣ、ＰＬＤのうちの２以上の要素の組み合わせであってもよい。

ＲＡＭ２０２は、監視装置２００の主記憶装置として使用される。ＲＡＭ２０２には、プロセッサ２０１に実行させるＯＳ（Operating System）プログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ２０２には、プロセッサ２０１による処理に必要な各種データが格納される。

ＨＤＤ２０３は、監視装置２００の補助記憶装置として使用される。ＨＤＤ２０３には、ＯＳプログラム、アプリケーションプログラム、および各種データが格納される。なお、補助記憶装置としては、ＳＳＤ（Solid State Drive）などの他の種類の不揮発性記憶装置を使用することもできる。

ＧＰＵ２０４には、表示装置２０４ａが接続されている。ＧＰＵ２０４は、プロセッサ２０１からの命令にしたがって、画像を表示装置２０４ａに表示させる。表示装置としては、液晶ディスプレイや有機ＥＬ（ElectroLuminescence）ディスプレイなどがある。

入力インタフェース２０５には、入力装置２０５ａが接続されている。入力インタフェース２０５は、入力装置２０５ａから出力される信号をプロセッサ２０１に送信する。入力装置２０５ａとしては、キーボードやポインティングデバイスなどがある。ポインティングデバイスとしては、マウス、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。

読み取り装置２０６には、可搬型記録媒体２０６ａが脱着される。読み取り装置２０６は、可搬型記録媒体２０６ａに記録されたデータを読み取ってプロセッサ２０１に送信する。可搬型記録媒体２０６ａとしては、光ディスク、半導体メモリなどがある。

通信インタフェース２０７は、ネットワーク２０７ａを介して、運用管理装置１００などの他の装置との間でデータの送受信を行う。
以上のようなハードウェア構成によって、監視装置２００の処理機能を実現することができる。なお、運用管理装置１００についても、例えば、図３に示すような構成のコンピュータとして実現することができる。

図４は、運用管理装置および監視装置が備える処理機能の構成例を示す図である。
まず、運用管理装置１００は、イベント実行部１０１、イベントログ検索部１０２およびメトリック収集部１０３を備える。イベント実行部１０１、イベントログ検索部１０２およびメトリック収集部１０３の処理は、例えば、運用管理装置１００が備える図示しないプロセッサが所定のプログラムを実行することで実現される。また、運用管理装置１００の図示しない記憶装置（例えばＲＡＭ）には、イベントログデータベース（ＤＢ）１０４とメトリックデータベース（ＤＢ）１０５とが記憶される。

イベント実行部１０１は、ＩＣＴインフラ１１０に含まれる各情報処理機器に対する運用イベントを実行する。イベント実行部１０１は、実行された運用イベントに関するログをイベントログデータベース１０４に登録する。運用イベントのログには、実行された処理内容を示す情報や、実行の成否を示す情報、実行された時刻などの情報が含まれる。

イベントログ検索部１０２は、例えば監視装置２００からの検索依頼に応じて、イベントログデータベース１０４を検索し、検索された運用イベントのログを返信する。
メトリック収集部１０３は、ＩＣＴインフラ１１０に含まれる各情報処理機器からメトリックを収集し、収集されたメトリックをメトリックデータベース１０５に登録する。メトリックとしては、例えば、サーバ装置におけるＣＰＵ待ち時間、ＣＰＵ使用率、メモリスワップアウト量、パケットロス数、ネットワーク使用率などが収集される。

次に、監視装置２００は、メトリック取得部２１１、正常性判定部２１２および要因判定部２１３を備える。メトリック取得部２１１、正常性判定部２１２および要因判定部２１３の処理は、例えば、監視装置２００が備えるプロセッサ２０１が所定のプログラムを実行することで実現される。また、監視装置２００の記憶装置（例えばＲＡＭ２０２）には、メトリックデータベース（ＤＢ）２２１、判定ルールデータベース（ＤＢ）２２２および判定結果データベース（ＤＢ）２２３が記憶される。

メトリック取得部２１１は、運用管理装置１００のメトリックデータベース１０５に登録されたメトリックを取得して、メトリックデータベース２２１に登録する。
正常性判定部２１２は、メトリックデータベース２２１に登録されたメトリックに基づいて、メトリックに関する正常性判定処理を定期的に実行する。この正常性判定処理、直近の一定時間内に運用管理装置１００によって収集されたメトリックを用いて実行される。正常性判定部２１２は、メトリックの異常が検知されると、そのメトリック（異常検知メトリック）を要因判定部２１３に通知する。

判定ルールデータベース２２２には、異常検知メトリックと、そのメトリックの異常発生の要因となり得る運用イベントと、異常発生要因とが、あらかじめ対応付けて登録されている。要因判定部２１３は、判定ルールデータベース２２２に基づいて、正常性判定部２１２から通知された異常検知メトリックについての異常発生の要因となり得る運用イベント（要因イベント）を特定する。

要因判定部２１３は、現時刻から所定時間だけ前の時刻までの期間に実行された要因イベントのログをイベントログデータベース１０４から検索するように、イベントログ検索部１０２に依頼する。要因判定部２１３は、イベントログデータベース１０４から要因イベントのログが検索された場合、判定ルールデータベース２２２から、検索されたログが示す運用イベントに対応する異常発生要因を抽出し、異常発生要因の判定結果を判定結果データベース２２３に登録する。

図５は、メトリックデータベースのデータ構成例を示す図である。この図５では監視装置２００のメトリックデータベース２２１について示すが、運用管理装置１００のメトリックデータベース１０５も同様のデータ構成を有する。

メトリックデータベース２２１には、メトリックが収集された収集時刻に対して、メトリックの種別（監視項目）ごとのメトリックの値が対応付けて登録される。図５の例では、メトリックの項目として、ホスト＃１のＣＰＵ使用率、ホスト＃１のＮＩＣ（Network Interface Card）＃１におけるネットワーク使用率、ホスト＃１のＮＩＣ＃２におけるネットワーク使用率が登録されている。この例では、少なくとも、仮想マシンが動作するサーバ装置であるホスト＃１が、ＣＰＵや２つのＮＩＣ＃１，＃２を備えているものとする。

図６は、判定ルールデータベースのデータ構成例を示す図である。判定ルールデータベース２２２は、異常が検知されたメトリック（異常検知メトリック）から、異常発生要因を推定するために参照されるデータベースである。判定ルールデータベース２２２には、異常検知メトリックに対して、異常発生の要因となり得る運用イベントである要因イベントと、異常発生の要因とが対応付けて登録される。これらの情報は、判定ルールデータベース２２２にあらかじめ登録される。

図６の例では、異常検知メトリックがＣＰＵ待ち時間の場合に、要因イベントとして仮想マシン（Virtual Machine：ＶＭ）のマイグレーションが考えられ、そのマイグレーションによるＣＰＵの競合が異常発生要因になり得ることが登録されている。また、異常検知メトリックがメモリスワップアウト量の場合に、要因イベントとして仮想マシンのマイグレーションが考えられ、そのマイグレーションによるメモリの競合が異常発生要因になり得ることが登録されている。

さらに、異常検知メトリックがパケットロス数の場合に、要因イベントとして仮想マシンのマイグレーションが考えられ、そのマイグレーションによるネットワークの競合が異常発生要因になり得ることが登録されている。また、異常検知メトリックがパケットロス数の場合には他の例として、要因イベントとしてＮＩＣドライバの更新が考えられ、そのＮＩＣドライバの不具合が異常発生要因になり得ることが登録されている。

図７は、判定結果データベースのデータ構成例を示す図である。判定結果データベース２２３には、判定結果を示す情報として、異常検知時刻、監視ホスト名、監視箇所、異常検知メトリックおよび要因が対応付けて登録されている。異常検知時刻は、異常が検知された時刻を示す。監視ホスト名は、監視対象のホストを示す。監視箇所は、そのホストにおける監視対象の箇所を示す。異常検知メトリックは、異常が検知されたメトリックを示す。要因は、判定された異常発生要因を示す。

次に、図８、図９を用いて、異常発生の要因判定処理についての比較例を説明する。
図８は、異常発生の要因判定処理についての比較例を示す第１の図である。
監視装置２００の正常性判定部２１２は、運用管理装置１００によって収集されたメトリックに基づいて、ＩＣＴインフラ１１０の稼働状況の正常性を判定する。このような正常性の判定時刻は一定時間間隔で設定され、正常性判定部２１２は、判定時刻を基準とした直近の一定時間に収集されたメトリックに基づいて、正常性の判定を行う。図８では例として、３分間隔で正常性の判定時刻が設定されている。

収集された複数項目のメトリックの中には、正常性判定のために使用される１以上の特定のメトリックがあらかじめ決められている。図８では、正常性判定のために使用されるメトリックとして、ＣＰＵ使用率、メモリスワップアウト量、パケットロス数が例示されている。なお、メモリスワップアウト量は、一定期間（前回の判定時刻から現在の判定時刻までの期間）においてメモリからＨＤＤやＳＳＤに退避されたデータの量を示し、パケットロス数は、一定期間に発生したパケットロスの回数を示す。

正常性判定部２１２は、例えば、メトリックごとに設定された判定閾値に基づき、メトリックの値が判定閾値を超えた場合、あるいは判定閾値未満になった場合に、そのメトリックについての異常が検知されたと判定する。例えば、図８に示したＣＰＵ使用率やメモリスワップアウト量、パケットロス数の場合、値が判定閾値を超えた場合に異常検知と判定される。なお、実際には、互いに関連する複数項目のメトリックの値に基づいて正常性（および異常検知）が判定されてもよい。例えば、一定期間でのパケットロス数と、一定期間での送信パケット数の相関関係に基づいて、正常か異常かが判定されてもよい。

正常性判定部２１２によってあるメトリックについて異常が検知されると、要因判定部２１３は、判定ルールデータベース２２２を参照して、異常が検知されたメトリックについての異常発生の要因となり得る運用イベント（要因イベント）を特定する。図８の例では、１０時９分においてパケットロス数についての異常が検知されたとする。ここで、図６に示した判定ルールデータベース２２２の例では、パケットロス数に対して要因イベントとしてＶＭマイグレーションとＮＩＣドライバ更新とが登録されている。したがって、図８の例では要因イベントとしてＶＭマイグレーションとＮＩＣドライバ更新が特定される。

また、要因判定部２１３は、現在の判定時刻から前回の判定時刻までの期間（１０時６分から１０時９分までの期間）に実行された要因イベントのログの検索を、運用管理装置１００のイベントログ検索部１０２に依頼する。図８の例では、ＮＩＣドライバを更新したことを示すログＬＧ１が検索されたとする。この場合、要因判定部２１３は、判定ルールデータベース２２２からパケットロス数およびＮＩＣドライバ更新に対応付けられた異常発生の要因を抽出する。図６の判定ルールデータベース２２２に基づく場合、要因としてＮＩＣドライバの不具合が抽出される。要因判定部２１３は、このような異常発生要因の判定結果を判定結果データベース２２３に登録する。

ここで、ＩＣＴインフラ１１０で発生する異常は、ＩＣＴインフラ１１０の運用管理において実行される構成変更や設定変更のイベント（運用イベント）を契機として発生することが多い。上記処理によれば、異常が検知されたメトリックに関連する運用イベントのログに基づいて異常発生要因が判定されるので、要因判定精度を高めることができる。

ところが、上記の方法では、次の図９に例示するような場合に、適切な要因イベントのログを検索により取得できず、異常判定要因を正確に判定できないという問題がある。
図９は、異常発生の要因判定処理についての比較例を示す第２の図である。異常の事象中には、要因イベントの実行に伴って異常が発生したときに、すぐには異常が検知されず、時間が経過してから異常が検知されるものがある。その例として、要因イベントの実行によりあるリソースに異常が発生したが、その時点でリソースが使用されておらず、その後にリソースが使用された時点で異常が検知される、というものがある。

図９の例では、１０時９分から１２分までの期間に、ＮＩＣ＃１のドライバを更新するという要因イベントが実行され、これに伴ってＮＩＣ＃１のドライバ（またはＮＩＣ＃１）の動作に異常が発生したとする。ただし、この時点でＮＩＣ＃１のドライバは使用されていなかった（ＮＩＣ＃１で通信が行われていなかった）とする。この場合、ＮＩＣ＃１による通信ではパケットロスが発生しないので、パケットロス数というメトリックからは異常は検知されない。

しかし、その後の１０時１５分から１８分までの期間においてＮＩＣ＃１による通信が開始されたとする。ＮＩＣ＃１のドライバ（またはＮＩＣ＃１）には異常が発生しているので、ＮＩＣ＃１によって開始された通信ではパケットロスが発生する。このため、１０時１８分における正常性判定処理で、パケットロス数から異常が検知される。このように、要因イベントの実行から長い時間遅れて異常が検知されるケースがある。

ここで、図８で説明したように、イベントログデータベース１０４から運用イベントのうち要因イベントのログを検索する期間を、正常性の判定周期に相当する時間とする。この場合、図９において１０時１８分にパケットロス数から異常が検出されると、その直前の３分間がログの検索期間（Ｐ１とする）となる。しかし、検索期間Ｐ１においてはＮＩＣ＃１のドライバ更新を示すログＬＧ２を取得できないので、異常発生要因を判定できない。

このような問題を解決する方法としては、要因イベントのログの検索期間を長くする方法が考えられる。例えば図９に示すように、より長い検索期間Ｐ２を設定することで、ＮＩＣ＃１のドライバ更新を示すログＬＧ２を取得できるようになる。しかし、検索期間を長くするほど、イベントログデータベース１０４における検索対象のイベントログ数が多くなり、大量のイベントログの中から検索条件に合致する要因イベントのログを検索しなければならなくなる。このため、運用管理装置１００における検索処理にかかる時間が長くなり、それによって監視装置２００による異常発生要因の判定処理全体にかかる時間も長くなってしまう。また、運用管理装置１００における検索処理負荷が増大することで、場合によっては運用管理装置１００による運用イベントの実行処理に支障が出る可能性もある。

図１０は、第２の実施の形態における異常発生の要因判定処理を示す図である。本実施の形態において、監視装置２００の要因判定部２１３は、次のような手順で要因イベントログの検索期間を決定する。この図１０では、図９と同様にＮＩＣ＃１のドライバ更新に起因する異常がパケットロス数から検知されたものとする。

１０時１８分にパケットロス数から異常が検知されると、要因判定部２１３は、その時刻を要因イベントログの検索期間の終了時刻Ｔｅとする。また、要因判定部２１３は、メトリックデータベース２２１を参照し、パケットロス数とは異なる他のメトリックの中から、直前の正常性判定時刻において対応するリソースが使用されていないことを示すメトリックを特定する。図１０の例では、他のメトリックとして、リソースの使用量を示すメトリックであるＣＰＵ使用率およびネットワーク使用率が存在するとする。これらのメトリックは、数値が０の場合にリソースが使用されていないことを示す。このため、図１０の例では、数値が０であるメトリックとして、ＮＩＣ＃１のネットワーク使用率と、ＮＩＣ＃２のネットワーク使用率が特定される。

次に、要因判定部２１３は、特定されたメトリックのそれぞれについて過去に遡って数値を取得し、数値が０より大きい値に転じた時刻を特定する。これにより、メトリックに対応するリソースが使用状態であった期間の終端が特定される。図１０の例では、１０時６分においてＮＩＣ＃１のネットワーク使用率が０％から３０％に転じており、１０時９分においてＮＩＣ＃２のネットワーク使用率が０％から２０％に転じている。したがって、数値が０より大きい値に転じた時刻として、ＮＩＣ＃１のネットワーク使用率については１０時６分が特定され、ＮＩＣ＃２のネットワーク使用率については１０時９分が特定される。

要因判定部２１３は、このようにして特定された時刻の中から最も古い時刻を特定し、その時刻を要因イベントログの検索期間の開始時刻Ｔｓとする。図１０の例では、ＮＩＣ＃１のネットワーク使用率についての時刻である１０時６分が、検索期間の開始時刻Ｔｓと特定される。これにより、開始時刻Ｔｓから前述の終了時刻Ｔｅまでの期間が検索期間に決定される。このような検索期間から要因イベントログが検索されることで、要因判定部２１３は、ＮＩＣ＃１のドライバ更新を示すログＬＧ２を取得でき、異常発生要因を正確に判定できる。

前述のように、あるリソースに関する異常の発生から検知までに時間がかかる場合、その異常は、リソースが使用されていない期間に実行された運用イベントを契機として発生した可能性がある。上記の処理では、メトリックの値が０より大きい値に転じた時刻のうち、最も古い時刻が検索期間の開始時刻とされる。これにより、異常が検知される直前まで使用されていない状態になっていたリソースに関係する運用イベントのログを、すべて検索対象に含めることができる。すなわち、要因イベントログの検索期間を必要最小限の長さに設定できる。このため、検索期間の長さを抑制しながら、検知された異常の発生の契機となった運用イベントのログを取得できる可能性が高まる。したがって、運用管理装置１００における検索処理時間を短縮し、それによって監視装置２００による異常発生要因の判定処理にかかる時間を短縮しつつ、その判定精度を高めることができる。また、異常発生要因の判定精度を高めつつ、運用管理装置１００における検索処理負荷を抑制できる。

なお、図１０では、異常の発生から検知までに時間がかかる例として、パケットロス数の異常検知に応じて、他のメトリックとしてネットワーク使用率の数値変化が解析される例を示した。他の例としては、メトリックとしてＣＰＵ待ち時間から異常が検知された場合に、他のメトリックとしてＣＰＵ使用量の数値変化が解析される場合が考えられる。

図１１は、第２の実施の形態における監視装置の処理手順を示すフローチャートの例である。図１１の処理は、正常性の判定時刻ごとに実行される。
［ステップＳ１１］メトリック取得部２１１は、運用管理装置１００のメトリックデータベース１０５から、現判定時刻から前回の判定時刻までの期間に収集されたメトリックを取得し、メトリックデータベース２２１に登録する。

［ステップＳ１２］正常性判定部２１２は、ステップＳ１１で登録されたメトリックのうちあらかじめ決められた１以上のメトリックに基づいて、ＩＣＴインフラ１１０の正常性を判定する。メトリックに基づいて異常が検知された場合、処理がステップＳ１３に進められる。この場合、異常が検知されたメトリックが正常性判定部２１２から要因判定部２１３に通知される。そして、ステップＳ１３～Ｓ１７の処理は、通知されたメトリックごとに実行される。一方、いずれのメトリックからも異常が検知されなかった場合、図１１の処理が終了される。

［ステップＳ１３］要因判定部２１３は、判定ルールデータベース２２２に基づいて、異常が検知されたメトリックに対応する要因イベント（異常発生要因の候補となる運用イベント）を特定する。

［ステップＳ１４］要因判定部２１３は、異常が検知されたメトリックとは異なる他のメトリックの中から、異常検知時刻の直前の正常性判定時刻において、対応するリソースが不使用状態であることを示すメトリックを特定する。例えば、リソースの使用量を示すメトリックの中から、異常検知時刻の直前の正常性判定時刻において数値が０であるメトリックを特定する。

［ステップＳ１５］要因判定部２１３は、メトリックデータベース２２１から、ステップＳ１４で特定された各メトリックについて過去に遡って数値を取得する。そして、要因判定部２１３は、各メトリックについて、リソースの使用状態が不使用状態から使用状態に変化した時刻を特定する。上記のようにリソースの使用量を示すメトリックの場合、メトリックの値が０からそれより大きい値に転じた時刻が特定される。

なお、リソースの使用量を示すメトリックを用いた場合、ステップＳ１４，Ｓ１５では、メトリックの値が０か、それより大きいかという判定基準が用いられたが、この判定基準としては０より大きい判定閾値が用いられてもよい。例えば、判定閾値を０．０１とし、ステップＳ１４では数値が０．０１以下のメトリックが特定され、ステップＳ１５ではメトリックの値が０．０１以下から０．０１を超えた時刻が特定されてもよい。

［ステップＳ１６］要因判定部２１３は、ステップＳ１５で特定された時刻の中から最も古い時刻を特定し、その時刻を要因イベントログの検索期間の開始時刻Ｔｓに決定する。

［ステップＳ１７］要因判定部２１３は、現判定時刻（終了時刻Ｔｅ）から上記の開始時刻Ｔｓまでの期間を検索期間とし、この検索期間と、ステップＳ１３で特定された要因イベントの識別情報とを引数で指定して、運用管理装置１００に対してイベントログの検索を依頼する。運用管理装置１００のイベントログ検索部１０２は、指定された検索期間に収集された運用イベントのログの中から、指定された要因イベントのログを抽出して、監視装置２００に返信する。要因判定部２１３は、抽出された要因イベントのログを受信し、取得する。

［ステップＳ１８］要因判定部２１３は、判定ルールデータベース２２２を参照し、異常が検知されたメトリック（異常検知メトリック）と、ステップＳ１７で取得されたログが示す要因イベントとに対応付けられた要因を取得する。要因判定部２１３は、取得された要因を異常発生要因と判定し、その判定結果を出力する。例えば、判定結果は、異常検知時刻、監視ホスト名、監視箇所、異常検知メトリック、および取得された要因の組み合わせとして判定結果データベース２２３に登録される。

ここで、監視ホスト名および監視箇所は、異常検知メトリック、ステップＳ１７で取得されたログが示す要因イベントの内容、これらに基づく異常発生要因の少なくとも１つ、または２つ以上の組み合わせから特定される。例えば、要因イベントがＮＩＣドライバ更新の場合、更新されたＮＩＣドライバに対応するＮＩＣが監視箇所として特定され、そのＮＩＣが搭載されたホスト（サーバ装置）の名前が監視ホスト名として特定される。また、異常検知メトリックがＣＰＵ待ち時間、要因イベントがＶＭマイグレーションの場合、監視箇所はＣＰＵ待ち時間の検出対象とされたＣＰＵとして特定され、そのＣＰＵが搭載されたホストの名前が監視ホスト名として特定される。

なお、ステップＳ１７の検索で複数の要因イベントのログが取得された場合、ステップＳ１８では、各要因イベントに基づく異常発生要因が、それぞれ可能性のある異常発生要因として出力されればよい。

〔第２の実施の形態の変形例〕
第２の実施の形態における監視装置２００の処理の一部は、以下のように変形されてもよい。

図１２は、変形例における異常発生の要因判定処理を示す図である。この図１２では、図９、図１０と同様にＮＩＣ＃１のドライバ更新に起因する異常がパケットロス数から検知されたものとする。

図９、図１０、図１２のように異常の発生から検知までに時間がかかるケースでは、使用されていない状態のリソースに関して異常が発生した後、そのリソースの使用が開始されることで異常が検知される。そこで、要因判定部２１３は、メトリックの異常が検知されると、それとは異なる他のメトリックの中から、メトリックの値に基づき、その直前の正常性判定時刻から現判定時刻までの期間に対応するリソースの使用が開始されたメトリックを特定する。そして、要因判定部２１３は、特定されたメトリックについて過去に遡って数値を取得し、取得した数値に基づき、対応するリソースが使用状態であった期間の終端を特定して、要因イベントログの検索期間の開始時刻を決定する。

図１２の例では、１０時１８分にパケットロス数から異常が検知されると、要因判定部２１３は、パケットロス数とは異なる、リソースの使用量を示す他のメトリックの中から、直前の正常性判定時刻で数値が０であり、現判定時刻で数値が０を超えたメトリックを特定する。図１２ではこのようなメトリックとして、ＮＩＣ＃１のネットワーク使用率が特定される。すると、要因判定部２１３は、特定されたネットワーク使用率の数値を過去に遡って取得し、数値が０からそれより大きい値に転じた時刻を特定する。図１２では、１０時６分においてＮＩＣ＃１のネットワーク使用率が０％から３０％に転じており、数値が０より大きい値に転じた時刻として１０時６分が特定され、この時刻が検索期間の開始時刻Ｔｓと決定される。

以上の処理によれば、対応するリソースが使用状態であった期間の終端を特定するための数値の変化を解析する対象のメトリックを絞り込むことができ、検索期間の開始時刻を決定するための処理負荷を軽減でき、その処理時間を短縮できる。また、異常検知時刻の直前において対応するリソースの使用が開始されたメトリックを特定することで、検知された異常に関連する可能性の高いメトリックだけを数値変化の解析対象として絞り込むことができる。このため、異常発生要因の判定精度を落とさずに、検索期間の決定処理時間を短縮でき、その結果、異常発生要因の判定処理全体を短縮できる。

図１３は、変形例における監視装置の処理手順を示すフローチャートの例である。本変形例では、図１１に示したフローチャートの処理ステップのうち、ステップＳ１４の処理が次のステップＳ１４ａの処理に変更される。

［ステップＳ１４ａ］要因判定部２１３は、異常が検知されたメトリックとは異なる他のメトリックの中から、異常検知時刻の直前の正常性判定時刻において、対応するリソースが不使用状態であり、かつ、異常検知時刻において使用状態に変化しているメトリックを特定する。例えば、リソースの使用量を示すメトリックの中から、異常検知時刻の直前の正常性判定時刻において数値が０であり、異常検知時刻において数値が０より大きいメトリックを特定する。

次のステップＳ１５では、ステップＳ１４ａで特定された各メトリックが数値取得の対象となる。これにより、第２の実施の形態と比較して、数値取得の対象となるメトリックが絞り込まれる。

なお、上記の各実施の形態に示した装置（例えば、異常要因判定装置１、運用管理装置１００、監視装置２００）の処理機能は、コンピュータによって実現することができる。その場合、各装置が有すべき機能の処理内容を記述したプログラムが提供され、そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、半導体メモリなどがある。磁気記憶装置には、ハードディスク装置（ＨＤＤ）、磁気テープなどがある。光ディスクには、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ブルーレイディスク（Blu-ray Disc：ＢＤ、登録商標）などがある。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムまたはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムにしたがった処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムにしたがった処理を実行することもできる。また、コンピュータは、ネットワークを介して接続されたサーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムにしたがった処理を実行することもできる。

１ 異常要因判定装置
２ メトリックデータベース
３ イベントログデータベース
４ タイムチャート
５ ログ
Ｍ１～Ｍ４ メトリック
Ｓ１～Ｓ５ ステップ
Ｔ１～Ｔ５ 時刻

Claims (6)

1. コンピュータが、
   それぞれ情報処理システムに含まれるリソースの使用状況を示す複数のメトリックのうち、第１のメトリックに基づいて第１の時刻に異常が検知された場合、前記複数のメトリックのうち前記第１のメトリックを除くメトリックの中から、前記第１の時刻の直前において対応するリソースが不使用状態であることを示す１以上の第２のメトリックを特定し、
   前記１以上の第２のメトリックのそれぞれが示す前記使用状況に基づき、前記第１の時刻の直前から過去に遡って対応するリソースが不使用状態から使用状態に変化する第２の時刻を前記１以上の第２のメトリックのそれぞれについて特定し、
   特定された前記第２の時刻のうち最も古い第３の時刻から前記第１の時刻までを検索期間として指定して、前記情報処理システムに対して実行されたイベントのログが蓄積されたデータベースから、前記検索期間において実行された、前記第１のメトリックに基づく異常の要因候補となる候補イベントのログを取得し、
   取得したログが示す前記候補イベントに基づいて前記第１のメトリックに基づく異常の発生要因を判定する、
   異常要因判定方法。
2. 前記１以上の第２のメトリックの特定では、前記複数のメトリックのうち前記第１のメトリックを除くメトリックの中から、前記第１の時刻の直前において値が所定値以下であるメトリックを前記１以上の第２のメトリックとして特定し、
   前記第２の時刻の特定では、前記１以上の第２のメトリックのそれぞれについて、前記第１の時刻の直前から過去に遡って値が前記所定値以下から前記所定値を超えたときの時刻を、前記第２の時刻として特定する、
   請求項１記載の異常要因判定方法。
3. 前記コンピュータは、さらに、前記１以上の第２のメトリックのうち、前記第１の時刻において対応するリソースが不使用状態から使用状態に変化したことを示す１以上の第３のメトリックを特定し、
   前記第２の時刻の特定では、前記１以上の第３のメトリックのそれぞれについて前記第２の時刻を特定する、
   請求項１記載の異常要因判定方法。
4. 前記１以上の第２のメトリックの特定では、前記複数のメトリックのうち前記第１のメトリックを除くメトリックの中から、前記第１の時刻の直前において値が所定値以下であるメトリックを前記１以上の第２のメトリックとして特定し、
   前記１以上の第３のメトリックの特定では、前記１以上の第２のメトリックの中から、前記第１の時刻において値が前記所定値以下から前記所定値を超えたメトリックを前記１以上の第３のメトリックとして特定し、
   前記第２の時刻の特定では、前記１以上の第３のメトリックのそれぞれについて、前記第１の時刻の直前から過去に遡って値が前記所定値以下から前記所定値を超えたときの時刻を、前記第２の時刻として特定する、
   請求項３記載の異常要因判定方法。
5. 前記コンピュータは、前記複数のメトリックのうち複数の特定メトリックのそれぞれに基づいて異常の有無を判定する判定処理を所定時間間隔の判定時刻ごとに実行し、
   前記１以上の第２のメトリックの特定では、前記判定時刻のうちの前記第１の時刻に、前記特定メトリックのうちの前記第１のメトリックに基づいて異常が検知された場合に、前記複数のメトリックのうち前記第１のメトリックを除くメトリックの中から、前記判定時刻のうち前記第１の時刻の直前の判定時刻において対応するリソースが不使用状態であることを示す前記１以上の第２のメトリックを特定する、
   請求項１乃至４のいずれか１項に記載の異常要因判定方法。
6. コンピュータに、
   それぞれ情報処理システムに含まれるリソースの使用状況を示す複数のメトリックのうち、第１のメトリックに基づいて第１の時刻に異常が検知された場合、前記複数のメトリックのうち前記第１のメトリックを除くメトリックの中から、前記第１の時刻の直前において対応するリソースが不使用状態であることを示す１以上の第２のメトリックを特定し、
   前記１以上の第２のメトリックのそれぞれが示す前記使用状況に基づき、前記第１の時刻の直前から過去に遡って対応するリソースが不使用状態から使用状態に変化する第２の時刻を前記１以上の第２のメトリックのそれぞれについて特定し、
   特定された前記第２の時刻のうち最も古い第３の時刻から前記第１の時刻までを検索期間として指定して、前記情報処理システムに対して実行されたイベントのログが蓄積されたデータベースから、前記検索期間において実行された、前記第１のメトリックに基づく異常の要因候補となる候補イベントのログを取得し、
   取得したログが示す前記候補イベントに基づいて前記第１のメトリックに基づく異常の発生要因を判定する、
   処理を実行させる異常要因判定プログラム。

Images