JP2014102661A - 適用判定プログラム、障害検出装置および適用判定方法 - Google Patents

Abstract

【課題】障害の予兆を検出する際に用いる障害予兆パターンの有効性を判定することを課題とする。
【解決手段】障害検出装置は、第１のシステム構成において障害の予兆検出に用いられる障害予兆パターンを、第１のシステムで過去に発生した障害事象に基づいて生成する。障害検出装置は、第１のシステム構成から第２のシステム構成へシステム構成が遷移する際に、システムを構成する構成要素の変更が実行された累積回数である変更回数を用いて、システム構成間の差を示す差分情報を算出する。そして、障害検出装置は、算出した差分情報に応じて、第２のシステム構成における障害の予兆検出への障害予兆パターンの適用可否を判定する。
【選択図】図２

Description

本発明は、適用判定プログラム、障害検出装置および適用判定方法に関する。

情報処理システムで発生する障害を検出する方法として、障害の予兆を示す障害予兆パターンを用いる障害検出装置が知られている。例えば、障害検出装置は、過去のログと障害発生情報とから、障害が起こる共起確率が高いメッセージの組み合わせを抽出する。そして、障害検出装置は、情報処理システムにおいて障害予兆パターンと同じ組み合わせのメッセージが出力された場合に、障害が発生する可能性があると判定する。

また、障害の検出に用いる障害判定ルールを他のシステム等に流用する際に、情報処理システムを構成する構成要素ごとに流用可否の基準を設ける手法が知られている。例えば、ＯＳ（Operating System）の監視項目が閾値以上一致している場合やＯＳのバージョンが一致している場合に、障害判定ルールを流用すると判定する。

特開２００９−１７６２０３号公報 特開２０１２−３７１３号公報

しかしながら、上記の技術では、共起確率に基づいて障害予兆パターンが生成されるので、システム構成の変化が当該パターンに与える影響度が明確ではなく、障害予兆パターンの適用が妥当か否かを判定できないという問題がある。

例えば、クラウドシステムは、システムを構成する構成要素も多く、システム構成も頻繁に変わる。したがって、システム構成が変更されるたびに障害予兆パターンを学習すると、学習時間が短くなるので、生成される障害予兆パターンの信頼性も低下する。

また、構成要素ごとに基準を設ける手法を障害予兆パターンに適用した場合、構成要素ごとに基準を作成し、システム構成が変わるたびに基準に応じて障害予兆パターンを変更することになる。したがって、この手法は、作業負担も多くなり、クラウドシステムには適さない。

このように、上記の技術では、特定の情報処理システムに適用される障害予兆パターンが有効なパターンであるか否かを判定できないので、有効ではない障害予兆パターンが適用されてしまい、障害の予兆を見逃すことが発生する。

１つの側面では、障害の予兆を検出する際に用いる障害予兆パターンの有効性を判定することができる適用判定プログラム、障害検出装置および適用判定方法を提供することを目的とする。

第１の案では、コンピュータに、第１のシステム構成において障害の予兆検出に用いられる障害予兆パターンを、前記第１のシステム構成において過去に発生した障害事象に基づいて生成する処理を実行させる。コンピュータに、前記第１のシステム構成から第２のシステム構成へシステム構成が遷移する際に、システムを構成する構成要素の変更が実行された累積回数である変更回数を用いて、システム構成間の差を示す差分情報を算出する処理を実行させる。コンピュータに、算出した前記差分情報に応じて、前記第２のシステム構成における障害の予兆検出への前記障害予兆パターンの適用可否を判定する処理を実行させる。

本発明の１実施態様によれば、障害の予兆を検出する際に用いる障害予兆パターンの有効性を判定することができる。

図１は、実施例１に係るシステムの全体構成例を示す図である。 図２は、実施例１に係る障害検出装置の機能構成を示す機能ブロック図である。 図３は、構成情報ＤＢに記憶される情報の例を示す図である。 図４は、構成要素の関係性を説明する図である。 図５は、構成変更情報ＤＢに記憶される情報の例を示す図である。 図６は、管理メッセージＤＢに記憶される情報の例を示す図である。 図７は、障害情報ＤＢに記憶される情報の例を示す図である。 図８は、障害予兆パターンＤＢに記憶される情報の例を示す図である。 図９は、障害予兆記録ＤＢに記憶される情報の例を示す図である。 図１０は、障害予兆パターンの学習を説明する図である。 図１１は、構成情報の遷移を説明する図である。 図１２は、障害予兆パターンの有効範囲を説明する図である。 図１３は、障害予兆検出時の構成情報例を示す図である。 図１４は、構成の変更回数を説明する図である。 図１５は、構成の差分数を説明する図である。 図１６は、判定基準を説明する図である。 図１７は、閾値の学習を説明する図である。 図１８は、障害予兆学習処理の流れを示すフローチャートである。 図１９は、障害予兆検出処理の流れを示すフローチャートである。 図２０は、予兆通報判定処理の流れを示すフローチャートである。 図２１は、構成差分算出処理の流れを示すフローチャートである。 図２２は、閾値学習処理の流れを示すフローチャートである。 図２３は、負荷量を説明する図である。 図２４は、負荷パターンを説明する図である。 図２５は、ハードウェア構成例を説明する図である。

以下に、本願の開示する適用判定プログラム、障害検出装置および適用判定方法の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。

［全体構成］
図１は、実施例１に係るシステムの全体構成例を示す図である。図１に示すように、このシステムは、複数のクライアント端末１とデータセンタ２と、ＣＭＤＢ（Configuration Management Database）５と障害検出装置１０とを有し、クラウドシステムによるサービスをクライアント端末１に提供するシステムである。

各クライアント端末１は、データセンタ２にアクセスしてクラウドシステムを利用し、サービスの提供を受ける端末である。データセンタ２には、複数の物理サーバが設置され、複数の仮想マシンが動作し、複数の仮想マシンによって顧客ごとに情報処理システムを構築する。各情報処理システムは、同じテンプレートから生成され、各顧客にサービスを提供する。

ＣＭＤＢ５は、データセンタ２で提供される情報処理システムの構成を統合管理するデータベースである。ＣＭＤＢ５は、各情報処理システムが有する構成要素（CI：Configuration Item）、各構成要素の属性、各構成要素が他の情報処理システムの構成要素との間で有する関係性などを関連付けて管理する。

障害検出装置１０は、ＣＭＤＢ５を用いて、データセンタ２で提供される情報処理システムで発生する障害の予兆を検出するサーバである。このような状態において、障害検出装置１０は、第１のシステム構成において障害の予兆検出に用いられる障害予兆パターンを、第１のシステム構成において過去に発生した障害事象に基づいて生成する。そして、障害検出装置１０は、第１のシステム構成から第２のシステム構成へシステム構成が遷移する際に、システムを構成する構成要素の変更が実行された累積回数である変更回数を用いて、システム構成間の差を示す差分情報を算出する。その後、障害検出装置１０は、算出した差分情報に応じて、第２のシステム構成における障害の予兆検出への障害予兆パターンの適用可否を判定する。

このように、障害検出装置１０は、障害予兆パターンを学習した時のシステム構成と、当該パターンが適用されるシステム構成との異なり具合を定量化し、学習時と異なるシステムへの適用可否を判定することで、障害予兆パターンの有効性を判定することができる。

［障害検出装置の構成］
図２は、実施例１に係る障害検出装置の機能構成を示す機能ブロック図である。なお、図１に示したクライアント端末１は一般的なコンピュータと同様の機能構成を有するので、詳細な説明は省略する。同様に、データセンタ２が有する物理サーバの機能構成についても、一般的なサーバと同様の構成を有するので、詳細な説明は省略する。

図２に示すように、障害検出装置１０は、通信処理部１１、記憶部１２、制御部２０を有する。ここで、通信処理部１１は、ネットワークインターフェースカードなどであり、記憶部１２は、メモリなどの記憶装置であり、制御部２０は、ＣＰＵ（Central Processing Unit）などのプロセッサである。

通信処理部１１は、他の装置との間の通信を制御する処理部である。例えば、通信処理部１１は、データセンタ２からログメッセージを受信する。また、通信処理部１１は、図示しない管理装置に障害の発生や障害の予兆を通知する。また、通信処理部１１は、データセンタ２内の情報処理システムを構成する構成要素の変更や、発生した障害情報などを管理装置などから受け付ける。

記憶部１２は、構成情報ＤＢ１３、構成変更情報ＤＢ１４、管理メッセージＤＢ１５、障害情報ＤＢ１６、障害予兆パターンＤＢ１７、障害予兆記録ＤＢ１８を保持する。

構成情報ＤＢ１３は、データセンタ２内の情報処理システムの構成情報を記憶する。具体的には、構成情報ＤＢ１３は、情報処理システムごとに、情報処理システムを構成する構成要素と、各構成要素間の関係性とを記憶する。この構成情報ＤＢ１３は、ＣＭＤＢ５そのものであってもよく、ＣＭＤＢ５から取得したデータを記憶する記憶部であってもよい。図３は、構成情報ＤＢに記憶される情報の例を示す図である。なお、図３には、一例としてＸＭＬ（Extensible Markup Language）形式で構成情報を管理する例を図示したが、これに限定されるものではなく、他の形式であってもよい。

図３に示すように、構成情報ＤＢ１３は、構成要素の情報を管理する「CIs」と、構成要素間の関係性を示す「Relations」とを記憶する。ここで設定される情報は、管理者等によって変更される。「CIs」は、「CI id」と「item」と「type」と「ip」等を含むレコードで構成要素を定義して管理する。「CI id」には、構成要素を識別する識別子が設定される。「item」には、構成要素の情報処理システム上での役割が設定される。「type」は、構成要素の名称等が設定される。「ip」は、構成要素に割当てるアドレスが設定される。

例えば、図３の「CIs」の１行目は、「type＝PC1」の構成要素が、情報処理システム上で「Pc」として動作し、「CI id＝0SOIW3SH」で識別されることを定義する。同様に、図３の「CIs」の３行目は、「type＝OS（A）」の構成要素が、情報処理システム上で「Os」として動作し、「CI id＝H38FHZ0S」で識別されるとともに、「ip＝192.168.1.10」が設定されることを定義する。また、図３の「CIs」の５行目は、「type＝AP1」の構成要素が、情報処理システム上で「APP」すなわちアプリケーションとして動作し、「CI id＝2H9JIIHY」で識別されることを定義する。また、図３の「CIs」の７行目は、「type＝table＿a」の構成要素が、情報処理システム上で「Instance」すなわち記憶部として動作し、「CI id＝HREIO928」で識別されることを定義する。

また、「Relations」は、「Relations id」、「src」、「dst」、「type」等を含むレコードで構成要素間の関係性を定義する。「Relations id」には、関係性を識別する識別子が設定される。「src」には、関係元の構成要素の識別子が設定され、「dst」には、関係先の構成要素の識別子が設定される。「tyep」には、関係性を特定する情報が設定される。

図３の「Relations」の１行目は、「src」側の「CI id＝0SOIW3SH」である「PC1」が、「dst」側の「CI id＝H38FHZ0S」である「OS（A）」を保持していることを定義する。「type」に設定される「Has」は、関係元が関係先を保持している関係、すなわち、関係先が関係元で動作している関係を示す。また、「InstalledOn」は、関係先が関係元にインストールされている関係を示す。「ConnectedTo」は、関係元と関係先とが相互に接続されている関係を示す。「Use」は、関係元が関係先を使用や参照する関係を示す。「DeployedOn」は、関係元が関係先を利用可能にする関係、すなわち、関係元を用いて関係先を利用する関係を示す。

ここで、図３で説明した構成要素の関係性を図４に図示する。図４は、構成要素の関係性を説明する図である。図４では、四角が構成要素で、矢印が関係性を示す。図４に示すように、構成要素「PC1」が構成要素「OS（A）」を保持し、構成要素「OS（A）」が構成要素「AP1」を保持し、構成要素「AP1」が構成要素「table＿a」を保持する。また、構成要素「table＿a」が構成要素「AP1」で利用可能に制御され、構成要素「AP1」が構成要素「OS（A）」にインストールされ、構成要素「OS（A）」が構成要素「PC1」にインストールされている。

同様に、構成要素「PC2」が構成要素「OS（B）」を保持し、構成要素「OS（B）」が構成要素「AP2」を保持し、構成要素「AP2」が構成要素「servlet＿a」を保持する。また、構成要素「servlet＿a」が構成要素「AP2」で利用可能に制御され、構成要素「AP2」が構成要素「OS（B）」にインストールされ、構成要素「OS（B）」が構成要素「PC2」にインストールされている。また、構成要素「OS（A）」と構成要素「OS（B）」とが接続されており、構成要素「servlet＿a」が構成要素「table＿a」を参照している。

また、図４に示した全構成要素で１つの情報処理システムとして動作し、テナントとして顧客にサービスを提供する。なお、「PC1」と「OS（A）」と「AP1」と「table＿a」とがテナント１として顧客にサービスを提供し、「PC2」と「OS（B）」と「AP2」と「servlet＿a」とがテナント２として顧客にサービスを提供するようにすることもできる。

図２に戻り、構成変更情報ＤＢ１４は、情報処理システムの構成変更を記憶する。ここで記憶される情報は、後述する構成変更学習部２１によって更新されてもよく、管理者等によって更新されてもよい。図５は、構成変更情報ＤＢに記憶される情報の例を示す図である。

図５に示すように、構成変更情報ＤＢ１４は、「時刻、変更種別、対象、パラメータ」を記憶する。「時刻」は、構成変更が実行された日時を示す。「変更種別」は、変更された内容を示し、削除された場合には「DEL」、追加された場合には「ADD」、設定変更された場合には「MOD」が設定される。「対象」は、変更された構成要素を示す。「パラメータ」は、変更されたパラメータを示す。なお、構成変更情報ＤＢ１４は、これらの情報以外にも、例えば変更が実行された情報処理システムやテナントを特定する情報等を記憶してもよい。

図５の場合、「日本標準時の2012年3月13日10：31：02」に、構成要素「2H9JIIHY」が情報処理システムから削除されたことを示す。また、「日本標準時の2012年3月13日10：35：28」に、構成要素「22OGEANA」が情報処理システムに追加されたことを示す。また、「日本標準時の2012年3月25日21：00：18」に、構成要素「93H6SK8A」の設定として「OSのバージョン」が「SP3」に変更されたことを示す。

管理メッセージＤＢ１５は、情報処理システムの各構成要素等から出力されるログメッセージを記憶する。ここで記憶される情報は、後述するメッセージ収集部２２によって更新されてもよく、管理者等によって更新されてもよい。図６は、管理メッセージＤＢに記憶される情報の例を示す図である。

図６に示すように、管理メッセージＤＢ１５は、フィールド１５ａから１５ｅで構成される各メッセージを記憶する。時刻フィールド１５ａには、ログメッセージが出力された日時が出力される。ホスト名フィールド１５ｂには、ログメッセージを出力した構成要素のホスト名が出力される。モジュール名フィールド１５ｃには、ログメッセージを出力したモジュール名が出力される。メッセージ種別フィールド１５ｄには、ログメッセージの種別を識別するメッセージＩＤが出力される。メッセージフィールド１５ｅには、出力されたログメッセージの詳細な内容が出力される。

ホスト名フィールド１５ｂと、モジュール名フィールド１５ｃとを用いて、構成情報を特定することができる。具体的には、図６のホスト名フィールド１５ｂが図３の「item」に対応し、図６のモジュール名フィールド１５ｃが図３の「type」に対応する。

障害情報ＤＢ１６は、発生した障害の情報を記憶する。ここで記憶される情報は、管理者等によって更新されてもよく、制御部２０が管理者端末から取得して更新してもよい。図７は、障害情報ＤＢに記憶される情報の例を示す図である。なお、図７には、一例としてＸＭＬ形式で障害情報を管理する例を図示したが、これに限定されるものではなく、他の形式であってもよい。

図７に示すように、障害情報ＤＢ１６は、「Trouble uid」と「type」と「date」と「title」等を含むレコードで障害情報を記憶する。「Trouble uid」は、障害情報を識別する識別子である。「tyep」は、障害の種別を特定する情報である。「date」は、障害が発生した日時である。「title」は、障害の内容である。

図７を例にして説明すると、「Web Down」の障害を示す「T001」が「日本標準時の2012年3月13日の10：51：02」に発生し、この障害が「201203130001」で識別されることを示す。また、「Web Down」の障害を示す「T001」が「日本標準時の2014年4月12日の16：31：08」にも発生し、この障害が「201204120001」で識別されることを示す。同様に、「DB Slow Down」の障害を示す「T003」が「日本標準時の2012年3月18日の03：25：22」に発生し、この障害が「201203180025」で識別されることを示す。

障害予兆パターンＤＢ１７は、障害の予兆を特定するログメッセージのパターンである障害予兆パターンと、当該パターンが生成されたときの構成情報とを対応付けて記憶する。ここで記憶される情報は、後述する障害予兆学習部２３によって更新される。図８は、障害予兆パターンＤＢに記憶される情報の例を示す図である。図８に示すように、障害予兆パターンＤＢ１７は、障害予兆パターン１７ａと、学習時の構成情報１７ｂとを対応付けて記憶する。

障害予兆パターン１７ａは、「障害、メッセージパターン、発生総数、障害前発生数、共起確率」で構成される。「障害」は、障害の種別を特定する情報であり、図７に示した「type」に対応する。「メッセージパターン」は、障害が実際に検出される前に発生するメッセージの組み合わせであり、図６に示したメッセージ種別フィールド１５ｄに出力された識別子の組み合わせである。「発生総数」は、当該メッセージパターンが発生した回数である。「障害前発生数」は、当該メッセージパターンが発生した後に、障害が実際に検出された回数である。「共起確率」は、メッセージパターンが発生した際に障害が発生する確率であり、障害前発生数／発生総数で算出された値である。

図８の場合、障害予兆パターン「0005、0007、0012」は、今までに572回発生し、そのうち534回で実際に障害「T001」が発生しており、当該パターンが発生した際に障害「T001」が起こる共起確率が「0.93」であることを示している。同様に、障害予兆パターン「0005、0007、0012」は、今までに572回発生し、そのうち501回で実際に障害「T002」が発生しており、当該パターンが発生した際に障害「T002」が起こる共起確率が「0.88」であることを示している。また、障害予兆パターン「0008、0036、0041、0108」は、今までに72回発生し、そのうち62回で実際に障害「T001」が発生しており、当該パターンが発生した際に障害「T001」が起こる共起確率が「0.86」であることを示している。

学習時の構成情報１７ｂは、障害予兆パターンごとに「学習時刻、構成情報（時刻、メッセージ種別ＩＤ、メッセージ発信ＣＩ）」を対応付けて記憶する。図８に示した学習時の構成情報１７ｂの「パターン」は、障害予兆パターンに該当し、「学習時刻」は、障害予兆パターンを学習したときの時刻である。また、構成情報内の「時刻」は、メッセージが発信された時刻である。「メッセージ種別ＩＤ」は、発信されたメッセージの識別子であり、図６に示したメッセージ種別フィールド１５ｄに出力された識別子に該当する。「メッセージ発信ＣＩ」は、メッセージを発信した構成要素であり、図３に示した「CI id」に対応する。

図８の場合、障害予兆パターン「0005、0007、0012」を学習した日時が「日本標準時の2012年3月8日10：20：00」である。このときに、構成要素「029KKZHE」がメッセージ「0005」を出力し、構成要素「029KKZHE」と構成要素「2H9JIIHY」とがメッセージ「0007」を出力し、構成要素「0SOIW3SH」がメッセージ「0012」を出力したことを示す。

障害予兆記録ＤＢ１８は、検出された障害予兆を記憶する。ここで記憶される情報は、予兆通報判定部２６等によって更新される。図９は、障害予兆記録ＤＢに記憶される情報の例を示す図である。図９に示すように、障害予兆記録ＤＢ１８は、「時刻、障害種別、検出パターン、検出構成、共起確率、構成変更量」を記憶する。

「時刻」は、障害の予兆が検出された時刻である。「障害種別」は、予兆があるとして検出された障害を識別する識別子であり、図８の「障害」に対応する。「検出パターン」は、検出された障害予兆パターンであり、図８の「メッセージパターン」に対応する。「検出構成」は、障害予兆が検出されたときのシステム構成であり、構成要素「Ci id」の組み合わせである。「共起確率」は、検出された障害予兆パターンが「障害種別」の障害を共起させる確率であり、図８の「共起確率」に対応する。「構成変更量」は、検出された障害予兆パターンの学習時の構成情報と、当該障害予兆パターンの検出時の構成情報との異なり具合を示す情報であり、後述する構成差分算出部２５によって算出される。

図９の場合、「日本標準時の2012年4月12日の16：16：00」に、障害「T001」の共起確率が「0.93」である障害予兆パターン「0005、0007、0012」が検出されたことを示す。さらに、この障害予兆パターン「0005、0007、0012」を検出したときのシステム構成が「0SOIW3SH、029KKZHE、00OGEANA」であり、この検出時の構成情報と当該障害予兆パターンの学習時の構成情報との構成変更量が「10、2」であることを示す。

図２に戻り、制御部２０は、構成変更学習部２１、メッセージ収集部２２、障害予兆学習部２３、障害予兆検出部２４、構成差分算出部２５、予兆通報判定部２６、閾値学習部２７を有し、これらによって障害予兆の検出を実行する処理部である。

構成変更学習部２１は、情報処理システムのシステム構成の変更を検出して構成変更情報ＤＢ１４を更新し、構成情報の変更を学習する処理部である。具体的には、構成変更学習部２１は、構成情報ＤＢ１３を監視し、構成情報ＤＢ１３が更新されたことを検出すると、更新された内容を構成変更情報ＤＢ１４に格納する。

例えば、「2012年5月12日11：00：00」にテナント１の「H38FHZ0S」のOSが「OS（A）」から「OS（C）」に変更されたとする。この場合、構成変更学習部２１は、「時刻（2012-05-12T11：00：00-09：00）、変更種別（MOD）、対象（H38FHZ0S）、パラメータ（TARGET＝OS、VALUE＝OS（C））」を構成変更情報ＤＢ１４に格納する。

メッセージ収集部２２は、データセンタ２内の情報処理システムから出力されたログメッセージを各情報処理システムから収集して、収集したメッセージを管理メッセージＤＢ１５に格納する処理部である。

障害予兆学習部２３は、障害の予兆を示すログメッセージのパターンである障害予兆パターンを、過去に発生した障害事象に基づいて生成し、所定の間隔で学習する処理部である。具体的には、障害予兆学習部２３は、障害予兆パターンの生成、障害予兆パターンの抽出、障害予兆パターンの共起確率の学習などを定期的に実行して、障害予兆パターンＤＢ１７を更新する処理部である。

例えば、障害予兆学習部２３は、過去一定期間のログメッセージを管理メッセージＤＢ１５から抽出し、抽出したログメッセージ群からメッセージパターンを生成する。また、障害予兆学習部２３は、生成した各メッセージパターンを構成するメッセージを出力した構成要素を特定する。そして、障害予兆学習部２３は、生成したメッセージパターンの組み合わせが障害予兆パターンＤＢ１７に記憶されている場合に、「発生総数」をインクリメントし、記憶されていない場合には、新たにエントリを生成する。

その後、障害予兆学習部２３は、メッセージの発生時刻から所定時間内に障害が発生している場合には、当該障害を特定する識別子とメッセージパターンと組み合わせに該当する「障害前発生数」をインクリメントした後、共起確率を更新する。一方、障害予兆学習部２３は、障害が発生していない場合には、当該障害を特定する識別子とメッセージパターンと組み合わせに該当する「障害前発生数」をインクリメントすることなく、共起確率を更新する。

ここで、図１０を用いて具体的に説明する。図１０は、障害予兆パターンの学習を説明する図である。図１０に示すように、障害予兆学習部２３は、任意に設定された学習タイミングに到達すると、障害予兆学習期間（Ｐ分間）内のＷ分の間に出力されたメッセージを管理メッセージＤＢ１５から抽出する。なお、Ｐ分は任意に設定してもよく、障害発生時刻（Ｓ分）を基準として、Ｓ分から所定時間前までと設定してもよい。続いて、障害予兆学習部２３は、各メッセージのメッセージ種別フィールド１５ｄを参照し、Ｗ分の間に、「0005、0007、0012」の組み合わせを抽出したとする。

すると、障害予兆学習部２３は、障害予兆パターンＤＢ１７を参照し、「障害」に関係なく「0005、0007、0012」に対応する「発生回数」をインクリメントする。図８の例では、障害予兆学習部２３は、「0005、0007、0012」に対応する「T001」と「T002」の両方の「発生回数」とをインクリメントする。また、障害予兆学習部２３は、抽出したメッセージパターン「0005、0007、0012」の各メッセージについて、ホスト名フィールド１５ｂとモジュール名フィールド１５ｃとから構成情報ＤＢ１３に記憶される「item」と「type」とを特定し、これらに対応する「CI id」を特定する。その後、障害予兆学習部２３は、抽出したメッセージパターン「0005、0007、0012」と、特定した「CI id」とを対応付けて、学習時の構成情報１７ｂとして障害予兆パターンＤＢ１７に格納する。

その後、障害予兆学習部２３は、障害情報ＤＢ１６を参照し、Ｗ分後からＰ分までの間に障害「T001」が発生していれば、「T001」と「0005、0007、0012」との組に対応する「障害前発生数」をインクリメントする。一方、障害予兆学習部２３は、障害情報ＤＢ１６を参照し、Ｗ分後からＰ分までの間に障害「T002」が発生していれば、「T002」と「0005、0007、0012」との組に対応する「障害前発生数」をインクリメントする。その後、障害予兆学習部２３は、現時点で格納されている、更新済みの「発生総数」および「障害前発生数」を用いて共起確率を算出して更新する。

図２に戻り、障害予兆検出部２４は、障害予兆パターンＤＢ１７に記憶される障害予兆パターンを用いて、障害の予兆を検出する処理部である。具体的には、障害予兆検出部２４は、管理メッセージＤＢ１５に随時格納されるログメッセージを監視し、障害予兆パターンＤＢ１７に記憶される障害予兆パターンと同じパターンの発生を検出した場合に、障害の予兆を検出する。そして、障害予兆検出部２４は、検出した障害の予兆や障害予兆パターンを構成差分算出部２５や予兆通報判定部２６に通知する。

例えば、障害予兆検出部２４は、管理メッセージＤＢ１５に「0005、0007、0012」のパターンが検出された場合に、障害「T001」と「T002」の障害の予兆を検出し、構成差分算出部２５や予兆通報判定部２６に通知する。このとき、障害予兆検出部２４は、障害予兆パターンと一致したメッセージを出力した構成要素を、障害予兆学習部２３と同様の手法で特定して、構成差分算出部２５や予兆通報判定部２６に通知する。

構成差分算出部２５は、障害予兆パターン学習時のシステム構成と障害の予兆検出時のシステム構成との間で構成が異なることを特徴づける複数の指標を用いて、システム構成間の差を示す差分距離を算出する処理部である。

例えば、構成差分算出部２５は、障害予兆パターン学習時の構成情報から障害の予兆検出時の構成情報へ構成が遷移する際に、構成要素の変更が実行された累積回数である変更回数を算出する。また、構成差分算出部２５は、障害予兆パターン学習時の構成要素と障害の予兆検出時の構成要素とで相違する構成要素の数である差分数を算出する。そして、構成差分算出部２５は、変更回数と差分数とを用いて、学習時と検出時との構成情報の差分距離を算出する。なお、構成差分算出部２５は、適用されている障害予兆パターンの学習時間を保持しておき、当該学習時間に対応する学習時の構成情報を障害予兆パターンＤＢ１７から特定する。このようにすることで、構成差分算出部２５は、最新の障害予兆パターンが未適用であっても、学習時と検出時との構成情報の差分距離を正確に算出することができる。

具体的には、構成差分算出部２５は、障害の予兆が検出されたことが障害予兆検出部２４から通知されると、障害予兆パターンＤＢ１７から検出された予兆に対応するエントリを抽出し、予兆が検出された障害に対応するエントリを障害予兆記録ＤＢ１８に生成する。このとき、構成差分算出部２５は、予兆検出時の構成情報を障害予兆検出部２４から受信して、障害予兆記録ＤＢ１８に生成したエントリの「検出構成」に格納する。そして、構成差分算出部２５は、検出された障害予兆パターンの学習時の構成情報を障害予兆パターンＤＢ１７から取得し、学習時の構成情報と検出時の構成情報とからシステム構成間の構成変更量を算出する。その後、構成差分算出部２５は、障害予兆記録ＤＢ１８に生成したエントリの「構成変更量」に、算出した構成変更量を格納する。

ここで、構成情報の遷移について説明する。図１１は、構成情報の遷移を説明する図である。図１１に示すように、システムＡ１に着目にした場合、Ａ１の構成は時間によって一部ずつ更新されていく。これを時間的連続性と呼ぶ。また、クラウドシステムは、同じテンプレートから複数のシステムを生成されるので、同じ時間帯で、完全に均一ではなく部分的に異なる他のシステムが存在する。これを空間的連続性と呼ぶ。

この時間的連続性に着目して算出した変更量が上記「変更回数」であり、空間的連続性に着目して算出した変更量が上記「差分数」である。つまり、「変更回数」は、変更の回数のみで算出され、変更の内容や変更の結果、システム構成がどのようにかわったかは見ていない値であり、システム構成に依存しない特徴量である。また、「差分数」は、システム構成同士の差分のみで算出され、システム構成が過去に何度の変更を経て現在の構成になったか見ておらず、システム変更履歴に依存しない特徴量である。このように、構成差分算出部２５は、互いに関連性のない、独立した特徴量を用いて、学習時と検出時の構成情報の構成変更量を算出する。

予兆通報判定部２６は、検出された予兆が妥当であるか否かを判定する処理部である。具体的には、予兆通報判定部２６は、構成差分算出部２５により算出された構成変更量が閾値未満の場合には、適用される障害予兆パターンが有効であると判定し、当該障害予兆パターンを用いて検出された障害の予兆を管理者等に通報する。

例えば、図９を例にすると、予兆通報判定部２６は、図９の１行目の障害予兆パターン「0005、0007、0012」と一致するとして検出された障害の予兆について、構成変更量「10、2」を障害予兆記録ＤＢ１８から取得する。そして、予兆通報判定部２６は、構成変更量「10、2」によって特定される差分距離が閾値未満であれば、障害「T001」が発生する可能性があることを管理者等に通報する。このとき、予兆通報判定部２６は、構成変更量「10、2」によって特定される差分距離が閾値未満であっても、共起確率が所定値未満であれば、通報しないように制御することもできる。

ここで、障害予兆の有効範囲を説明する。図１２は、障害予兆パターンの有効範囲を説明する図である。図１２に示すように、障害予兆パターンを学習したときから、図１１と同様、システムの構成は、時間軸および空間軸で変更されていく。具体的には、システムＡは、時間とともにソフトウェアのバージョンアップなどのマイナーチェンジが実行されるので、Ａ１、Ａ２、Ａ３、Ａ４と構成変更が実行される。この場合に、システムＡがＡ１に構成変更されたタイミングで障害検出パターンが学習されて、構成変更が短時間で発生したとすると、この障害検出パターンを用いてＡ１、Ａ２、Ａ３、Ａ４の各々で障害予兆の検出が実行される。

一方で、クラウドシステムの特性上、システムＡと似た構成のシステムＢ１、Ｃ１、Ｄ１が同時期に存在する。この場合も、システムＡがＡ１に構成変更されたタイミングで学習された障害検出パターンを用いて、同時期に存在するＢ１、Ｃ１、Ｄ１の各々で障害予兆の検出が実行される。

このように、あるタイミングで学習された障害予兆パターンが、時間的または空間的に異なるシステム、すなわち、構成が異なるシステムで利用される。一方、障害予兆パターンは、共起確率に基づいて生成されるので、システム構成の変化が当該パターンに与える影響度が明確ではない。そこで、予兆通報判定部２６は、構成差分算出部２５により算出された構成変更量を用いて、適用される障害予兆パターンの有効性を判定する。つまり、予兆通報判定部２６は、学習された障害予兆パターンがどの時間、どの空間まで有効であるかを定量的に判定する。そして、予兆通報判定部２６は、有効ではないと判定された場合には、共起確率が高くても、誤検出の可能性が高いとして、検出された障害の予兆を通報しないように制御する。

閾値学習部２７は、障害の予兆が検出された後に、実際に障害が発生したか否か判定し、判定した結果に基づいて、障害予兆パターンの適用可否を判定する差分距離の閾値を決定する。つまり、閾値学習部２７は、障害予兆パターンを用いて検出された複数の障害予兆各々が正解なのか誤検出なのかを統計的に判断し、予兆通報判定部２６が障害予兆パターンの有効性の判定に用いる閾値を更新する。

［有効性判定の具体例］
次に、図１３から図１６を用いて、適用される障害予兆パターンの有効性を判定する具体例を説明する。図１３は、障害予兆検出時の構成情報例を示す図である。図１４は、構成の変更回数を説明する図である。図１５は、構成の差分数を説明する図である。図１６は、判定基準を説明する図である。なお、ここでは、障害検出パターンとして「0005、0007、0012」が検出され、学習時の構成が図８に示す「0SOIW3SH、2H9JIIHY、029KKZHE」であるものとする。

まず、障害予兆検出部２４は、管理メッセージＤＢ１５に格納されるログメッセージから障害検出パターン「0005、0007、0012」と一致するメッセージが発生したことを検出する。すると、障害予兆検出部２４は、障害検出パターン「0005、0007、0012」を出力した構成要素を抽出する。具体的には、障害予兆検出部２４は、障害検出パターン「0005、0007、0012」を検出した時刻、メッセージ種別ＩＤ、メッセージ発信ＣＩを、検出したメッセージから抽出し、図１３に示す構成情報を生成する。なお、障害予兆検出部２４は、図６に示したメッセージ種別フィールド１５ｄから「メッセージ種別ＩＤ」を抽出する。また、障害予兆検出部２４は、図６に示したホスト名フィールド１５ｂとモジュール名フィールド１５ｃとから、図３に示した「item」と「type」とを特定し、これらに対応する「CI id」を「メッセージ発信ＣＩ」として抽出する。

また、障害予兆検出部２４は、検出された障害の予兆に関する情報が格納されるエントリを障害予兆記録ＤＢ１８に生成する。具体的には、障害予兆検出部２４は、障害予兆パターンＤＢ１７から、障害検出パターン「0005、0007、0012」、「障害」、「共起確率」を抽出し、それぞれを「検出パターン、障害種別、共起確率」とするレコードを障害予兆記録ＤＢ１８に生成する。また、障害予兆検出部２４は、生成したエントリの「時刻」に、予兆を検出した時刻を格納し、上述した手法で特定した「メッセージ発信ＣＩ」を「検出構成」に格納する。

その後、構成差分算出部２５は、障害予兆記録ＤＢ１８に格納されたエントリから検出パターン「0005、0007、0012」を特定し、特定した検出パターンに対応する構成情報「0SOIW3SH、029KKZHE、22OGEANA」および「学習時刻」を障害予兆パターンＤＢ１７から抽出する。すなわち、構成差分算出部２５は、検出されたメッセージパターン「0005、0007、0012」の学習時の構成情報を抽出する。

続いて、構成差分算出部２５は、構成変更情報ＤＢ１４を参照し、「学習時刻」より後の時間で構成変更が実行された回数を計数する。つまり、構成差分算出部２５は、学習時から検出時までの構成変更の回数を計数する。

具体的には、構成差分算出部２５は、構成変更情報ＤＢ１４を参照することで、図１４に示すように「0SOIW3SH」が学習時から検出時まで４回設定変更されたことを検出する。同様に、構成差分算出部２５は、学習時の「2H9JIIHY」が１回設定変更された後に削除されたことを検出し、学習時の「029KKZHE」が検出時まで２回設定変更されたことを検出する。同様に、構成差分算出部２５は、学習時にはなかった「22OGEANA」が学習時以降に追加された後に１回設定変更されたことを検出する。以上から、構成差分算出部２５は、学習時から検出時まで１０回の構成変更があったことを検出する。すなわち、構成差分算出部２５は、変更が実行された累積回数である変更回数として１０を算出する。

さらに、構成差分算出部２５は、構成変更情報ＤＢ１４を参照し、学習時の構成要素の種類と、検出時の構成要素の種類の相違数を計数する。つまり、構成差分算出部２５は、学習時と検出時とで構成要素が相違する数を計数する。

具体的には、構成差分算出部２５は、学習時の構成情報「0SOIW3SH、2H9JIIHY、029KKZHE」の各構成要素について、構成情報ＤＢ１３を参照して、「CI id」を「type」に変換する。つまり、構成差分算出部２５は、「0SOIW3SH」を「PC1」、「2H9JIIHY」を「OS（A）」、「029KKZHE」を「AP2」に変換する。同様に、構成差分算出部２５は、検出時の構成情報「0SOIW3SH、029KKZHE、22OGEANA」の各構成要素について、「0SOIW3SH」を「PC1」、「029KKZHE」を「AP2」、「22OGEANA」を「OS（B）」に変換する。そして、構成差分算出部２５は、学習時の構成情報「PC1、OS（A）、AP2」と検出時の構成情報「PC1、AP2、OS（B）」とを比較し、一致する構成要素の数が「２個」であると特定する。すなわち、構成差分算出部２５は、相違する構成要素の差分数として２を算出する。

その後、構成差分算出部２５は、障害予兆記録ＤＢ１８に生成したレコードの「構成変更量」に、時間軸の構成差分である変更回数「１０」と空間軸の構成差分である差分数「２」とを格納する。続いて、予兆通報判定部２６は、構成変更量「１０、２」に基づいて、検出された予兆の精度すなわち障害予兆パターンの有効性を判定する。具体的には、予兆通報判定部２６は、図１６に示すように、横軸を変更回数、縦軸を差分数として、構成変更量「１０、２」をプロットする。このとき、プロットされた構成変更量「１０、２」で特定される点と、原点（０、０）とを結ぶ直線の長さが、差分距離として表される。そして、予兆通報判定部２６は、この差分距離が閾値の範囲内である場合に、検出された障害予兆パターンは有効であると判定し、予兆を通報する。一方で、予兆通報判定部２６は、この差分距離が閾値の範囲外である場合に、検出された障害予兆パターンは有効ではないと判定し、予兆を通報しないように制御する。

［閾値学習の具体例］
次に、予兆通報判定部２６が予兆の有効性を判定する際に用いる閾値の学習例を説明する。図１７は、閾値の学習を説明する図である。図１７に示すように、閾値学習部２７は、横軸を変更回数、縦軸を差分数として、障害予兆記録ＤＢ１８に記憶される各レコードの「構成変更量」をプロットする。そして、閾値学習部２７は、予兆を有効と判定したか無効と判定したかによって、プロットした各構成変更量を「正解群」と「誤検出群」とにグループ分けする。その後、閾値学習部２７は、プロットした状態から「正解群」が多く含まれるように境界を決定し、決定した境界を新たな閾値とする。なお、境界の決定手法は、マハラノビス距離などの統計学の様々な手法を用いることができる。

［処理の流れ］
続いて、障害検出装置１０が実行する処理の流れについて説明する。ここでは、障害予兆学習処理、障害予兆検出処理、予報通報判定処理、構成差分算出処理、閾値学習処理について説明する。

（障害予兆学習処理）
図１８は、障害予兆学習処理の流れを示すフローチャートである。この処理は定期的に実行される。図１８に示すように、障害予兆学習部２３は、学習タイミングに到達すると、管理メッセージＤＢ１５から過去一定期間（Ｗ分）のメッセージを抽出し、様々なパターンを生成する（Ｓ１０１）。

続いて、障害予兆学習部２３は、生成した各パターンについて、構成情報ＤＢ１３や管理メッセージＤＢ１５を参照し、各パターンを構成するメッセージの発信元のＣＩ（構成要素）を抽出する（Ｓ１０２）。

そして、障害予兆学習部２３は、生成した各パターンのうち、障害予兆パターンＤＢ１７の障害予兆パターン１７ａに記憶される障害予兆パターンと一致するパターンについては、該当する障害予兆パターンの「発生総数」を更新する（Ｓ１０３）。具体的には、障害予兆学習部２３は、当該パターンに対応するエントリの「発生総数」をインクリメントする。このとき、障害予兆学習部２３は、障害予兆パターンＤＢ１７に記憶される障害予兆パターン１７ａと一致しないパターンについては、新たなエントリを障害予兆パターンＤＢ１７に生成する。

その後、障害予兆学習部２３は、管理メッセージＤＢ１５から抽出したメッセージ群の時刻から一定期間（Ｐ分）以内の障害を、障害情報ＤＢ１６から取り出す（Ｓ１０４）。そして、障害予兆学習部２３は、障害予兆パターンＤＢ１７の障害予兆パターン１７ａに記憶される各エントリの「障害」と一致する障害が発生している場合には、当該エントリの「障害」に対応する「障害前発生数」を更新する（Ｓ１０５）。

さらに、障害予兆学習部２３は、障害予兆パターンＤＢ１７の障害予兆パターン１７ａに記憶される各エントリに対応付けられる学習時の構成情報１７ｂを、Ｓ１０２で抽出した構成要素を組み合わせた構成情報で更新する（Ｓ１０６）。その後、障害予兆学習部２３は、障害予兆パターンＤＢ１７の障害予兆パターン１７ａの各エントリについて、共起確率を再計算して更新する（Ｓ１０７）。その後は、Ｓ１０１に戻って以降の処理が繰り返される。

（障害予兆検出処理）
図１９は、障害予兆検出処理の流れを示すフローチャートである。この処理は定期的に実行される。図１９に示すように、障害予兆検出部２４は、管理メッセージＤＢ１５から最新一定時間（Ｗ分）のメッセージを抽出して、様々なパターンを生成する（Ｓ２０１）。

続いて、障害予兆検出部２４は、生成した各パターンについて、構成情報ＤＢ１３や管理メッセージＤＢ１５を参照し、各パターンを構成するメッセージの発信元のＣＩ（構成要素）を抽出する（Ｓ２０２）。

その後、障害予兆検出部２４は、生成した各パターンのうち、障害予兆パターンＤＢ１７の障害予兆パターン１７ａに記憶される障害予兆パターンと一致するパターンを検索する（Ｓ２０３）。

そして、障害予兆検出部２４は、一致するパターンが検索された場合（Ｓ２０４：Ｙｅｓ）、一致したパターンと当該パターンの構成要素等を用いて、障害予兆記録ＤＢ１８にエントリを生成する（Ｓ２０５）。その後、障害予兆検出部２４は、予兆通報判定部２６に予兆通報判定処理の実行を依頼した後（Ｓ２０６）、Ｓ２０１以降を繰り返す。なお、障害予兆検出部２４は、一致するパターンが検索されなかった場合も（Ｓ２０４：Ｎｏ）、Ｓ２０１以降を繰り返す。

（予兆通報判定処理）
図２０は、予兆通報判定処理の流れを示すフローチャートである。図２０に示すように、予兆通報判定部２６は、障害予兆検出部２４から処理の実行開始が依頼されると（Ｓ３０１：Ｙｅｓ）、障害予兆検出部２４によって障害予兆記録ＤＢ１８に格納されたエントリ、すなわち、障害予兆通報の内容を取得する（Ｓ３０２）。

その後、予兆通報判定部２６は、構成差分算出部２５に構成差分算出処理の開始を依頼する（Ｓ３０３）。このとき、予兆通報判定部２６は、Ｓ３０２で取得した障害予兆通報の内容を構成差分算出部２５に出力してもよい。

そして、予兆通報判定部２６は、構成差分算出部２５から構成差分算出処理の算出結果を取得し（Ｓ３０４）、取得した算出結果である構成変更量と閾値とを比較する（Ｓ３０５）。

予兆通報判定部２６は、構成変更量が閾値以下であると判定した場合（Ｓ３０６：Ｙｅｓ）、予兆を通報する（Ｓ３０７）。一方、予兆通報判定部２６は、構成変更量が閾値より大きいと判定した場合（Ｓ３０６：Ｎｏ）、処理を終了する。

（構成差分算出処理）
図２１は、構成差分算出処理の流れを示すフローチャートである。図２１に示すように、構成差分算出部２５は、予兆通報判定部２６から処理の実行開始が依頼されると（Ｓ４０１：Ｙｅｓ）、障害予兆検出部２４によって障害予兆記録ＤＢ１８に格納されたエントリ、すなわち、障害予兆通報の内容を取得する（Ｓ４０２）。

そして、構成差分算出部２５は、Ｓ４０２で取得した障害予兆通報の内容から予兆検出時の構成情報を取得する（Ｓ４０３）。具体的には、構成差分算出部２５は、障害予兆パターンの各メッセージの出力元の構成要素を抽出する。

続いて、構成差分算出部２５は、障害予兆に該当するパターンの学習時の構成情報を取得する（Ｓ４０４）。具体的には、構成差分算出部２５は、検出されたパターンに対応するエントリを障害予兆パターンＤＢ１７から検索し、検索された障害予兆パターンに対応付けられる学習時の構成情報を特定する。さらに、構成差分算出部２５は、特定した構成情報を構成する構成要素「メッセージ発信ＣＩ」を取得する。

その後、構成差分算出部２５は、構成変更量を算出し（Ｓ４０５）、その算出結果を予兆通報判定部２６に応答する（Ｓ４０６）。具体的には、構成差分算出部２５は、学習時から検出時までの構成要素の変更が実行された累積回数である変更回数と、学習時と検出時とで構成要素が相違する数を示す差分数とを算出する。また、構成差分算出部２５は、算出した構成変更量（変更回数、差分数）を、障害予兆記録ＤＢ１８の該当するエントリに格納してもよい。

（閾値学習処理）
図２２は、閾値学習処理の流れを示すフローチャートである。この処理は定期的に実行される。図２２に示すように、閾値学習部２７は、閾値の学習タイミングに到達すると、障害予兆記録ＤＢ１８から、１種類の障害について予兆通報を抽出する（Ｓ５０１）。具体的には、閾値学習部２７は、障害予兆記録ＤＢ１８から、「障害種別」が一致するエントリを取得する。

続いて、閾値学習部２７は、抽出した予兆通報について、予兆が正解であったか誤検出であったかを判定する（Ｓ５０２）。具体的には、閾値学習部２７は、抽出した予兆通報が検出された時刻から所定時間が経過するまでに、当該予兆通報に対応する「障害」が発生したか否かを判定する。

その後、閾値学習部２７は、各予兆通報の判定した結果から正解群と誤検出群の構成変更量について、マハラノビス距離を算出する（Ｓ５０３）。そして、閾値学習部２７は、マハラノビス距離の算出結果から閾値となる判別式を求め（Ｓ５０４）、閾値を更新する（Ｓ５０５）。その後は、Ｓ５０１に戻って以降の処理が繰り返される。

このように、実施例１に係る障害検出装置１０は、互いに独立する指標を用いて、学習時の構成と検出時の構成との異なり具合を定量化し、使用される障害検出パターンの有効性を判定することができる。したがって、障害検出装置１０は、システム構成がどの程度変わると学習した障害予兆パターンが使用できなくなるのかを定量的に評価することができる。

また、障害検出装置１０は、実際に障害の予兆が検出された場合に、当該予兆に対応する障害予兆パターンの有効性を判定することができるので、検出された予兆の信頼性を判定することができる。つまり、障害検出装置１０は、信頼性の低い予兆、すなわち、構成変更量が閾値より大きい障害予兆パターンで検出された予兆については、管理者等への通報を抑制できる。したがって、障害検出装置１０は、適用が妥当ではない障害予兆パターンによって検出される、予兆の誤検出を抑制することができる。

また、障害検出装置１０は、予兆の検出と障害の実績とから、障害予兆パターンの有効性を判定する基準を更新することができるので、実績を考慮した基準で有効性を判定することができ、判定精度を向上させることができる。

実施例１では、構成変更量（変更回数、差分数）を用いて、学習時と検出時との構成情報の差分距離を算出する例を説明したが、差分距離の算出には他の指標を用いることもできる。そこで、実施例２では、構成変更量の１つとして負荷量を用いる例と、負荷パターンを用いる例とを説明する。

（負荷量）
図２３は、負荷量を説明する図である。図２３は、該当システムの負荷量が時間によって変化する例を図示し、縦軸が負荷、横軸が時間である。図２３に示す負荷量は、単位時間当たりの処理数、利用者の同時接続数など、システムに対する外部からの負荷量である。なお、単位時間当たりの処理数としては、例えば１日あたりのページ閲覧数などが該当し、利用者の同時接続数としては、ある時刻に接続しているユーザ数などが該当する。

図２３に示すように、時間が経過するに連れてシステムの構成が変更されると、システムの負荷量も変化する。つまり、学習時「ｔ０」時の負荷量「Ｆ（ｔ０）」と、検出時「ｔ１」の負荷量「Ｆ（ｔ１）」とが異なっていれば、システムの変更が行われている可能性が高い。そこで、この例では、Ｆ（ｔ０）とＦ（ｔ１）との比を算出し、算出した負荷量の比を構成変更量として用いる。具体的には、構成差分算出部２５は、負荷量の比「Ｄ」を「Ｄ＝｜Ｆ（ｔ１）−Ｆ（ｔ０）｜／Ｆ（ｔ０）」と算出する。

このように、障害検出装置１０は、実施例１で説明した構成変更量の１つ、または、３つ目の構成変更量として、負荷量の比を用いることもできる。この結果、システムの内部構成に直接的には依存しない、システムの外部からの影響を客観的に用いることができるので、判定精度の向上が期待できる。

（負荷パターン）
図２４は、負荷パターンを説明する図である。図２４は、該当システムがユーザに対してサービス等を提供することで発生する負荷の変化を図示し、縦軸が負荷、横軸が時間である。つまり、負荷パターンは、該当システムを所有するテナントの業務パターンである。

ここでは、負荷のピーク周期ｔと、負荷のピーク時の値であるピーク負荷ｌｐと、平均負荷ｌａとを用いて負荷パターンＬをＬ（ｔ、ｌｐ、ｌａ）と定義する。なお、学習時の負荷パターンは、Ｌ０（ｔ０、ｌｐ０、ｌａ０）と定義でき、検出時の負荷パターンは、Ｌ１（ｔ１、ｌｐ１、ｌａ１）と定義できる。

そして、学習時のシステムの負荷パターンと、検出時のシステムの負荷パターンとの差分Ｄは、「Ｄ＝（｜ｔ１−ｔ０｜／ｔ０）＋（｜ｌｐ１−ｌｐ０｜／ｌｐ０）＋（ｌａ１−ｌａ０｜／ｌａ０）」と算出することができる。

学習時のテナントと検出時のテナントとが同一であれば、利用方法や業務の負荷パターンが類似すると考えられる。したがって、負荷パターンの差分「Ｄ」は０に近いほど、学習した障害予兆パターンの有効性は高い。一方、学習時のテナントと検出時のテナントとが異なれば、利用方法や業務の負荷パターンが異なると考えられる。したがって、負荷パターンの差分「Ｄ」は、例えば３０のように大きな値ほど、学習した障害予兆パターンの有効性は低い。

このように、障害検出装置１０は、実施例１で説明した構成変更量の１つ、または、３つ目の構成変更量として、負荷パターンの差分を用いることもできる。この結果、システムの内部構成に直接的には依存しない、システムの負荷状態の変化を客観的に用いることができるので、判定精度の向上が期待できる。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。

（適用システム）
実施例１や実施例２で説明した障害予兆パターンの適用判定方法は、学習時と検出時とが同じシステムであってもよく、異なるシステムであっても同様に処理することができる。上述したように、クラウドシステムは、同じテンプレートを用いて複数のシステムから構成されることが多い。このため、システムＡで障害予兆パターンを学習し、システムＢに当該障害予兆パターンを適用することもある。つまり、障害予兆パターン学習時は、システムＡとシステムＢとは同様の構成であり、時間経過とともに、各々でシステム構成の変更が行われる。

したがって、障害検出装置１０は、システムＡで学習された障害予兆パターンをシステムＢに適用し、システムＢにおける構成変更を管理する。そして、障害検出装置１０は、システムＢで障害の予兆が検出された場合に、学習時のシステムＡと現在のシステムＢとの差分数と、学習時のシステムＡから現在のシステムＢに変更されるまでの変更回数とを算出する。こうして、障害検出装置１０は、当該障害予兆パターンの適用が有効か否かをでき、各実施例と同様の効果を得ることができる。

（指標の組み合わせ）
実施例１では、変更回数と差分数とを用いて差分距離を算出する例を説明し、実施例２では、負荷量比または負荷パターンの比を用いる例を説明したが、これらは任意に組み合わせることができる。例えば、変更回数と負荷パターンの比とを用いる場合には、横軸を変更回数、縦軸を負荷パターンの比として、構成変更量をプロットし、差分距離が閾以下か否かを判定することもできる。また、変更回数、差分数、負荷量比、負荷パターンを用いた四次元で差分距離が閾以下か否かを判定することもできる。なお、負荷量比や負荷パターンを用いる場合には、これらを用いることを予め決定しておき、学習時から負荷量比や負荷パターンを計測する。

（共起確率）
実施例１等で示した障害予兆パターンＤＢ１７は、共起確率が所定値以上のパターンを記憶するようにすることもできる。このような状態で、障害検出装置１０は、障害予兆を検出した場合に、障害予兆パターンの有効性を判定する。この結果、障害検出装置１０は、共起確率が高い障害予兆パターンで障害の予兆が検出され、障害予兆パターンが有効ではない場合には、信頼性の低い予兆が検出されたとして、予兆の通報を抑制することができる。

障害予兆パターンＤＢ１７は、共起確率が低いパターンを記憶してもよい。このような状態で、障害検出装置１０は、障害予兆を検出した場合に、障害予兆パターンの有効性を判定する。この結果、障害検出装置１０は、学習時と検出時のシステム構成の違いによっては、共起確率が低く信頼性の低い障害予兆パターンで障害の予兆が検出されるが、障害予兆パターンを有効であると判定する場合もある。この場合、障害検出装置１０は、信頼性の高い予兆が検出されたとして、予兆の通報を実行することができる。

（システム）
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともできる。あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散や統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

（ハードウェア）
図２５は、ハードウェア構成例を示す図である。ここで示したハードウェア構成は、障害検出装置１０のハードウェア構成である。図２５に示すように、コンピュータ１００は、ＣＰＵ１０１、メモリ１０２、ＨＤＤ（Hard Disk Drive）１０３、通信インタフェース１０４、入力装置１０５、表示装置１０６を有する。また、図２５に示した各部は、バス１００ａで相互に接続される。

入力装置１０５は、例えばキーボードなどであり、表示装置１０６は、例えばディスプレイなどであり、通信インタフェース１０４は、例えばＮＩＣ（Network Interface Card）などである。ＨＤＤ１０３は、図２等に示した機能を実行するプログラムや図２に示した各ＤＢを記憶する。記録媒体の例としてＨＤＤ１０３を例に挙げたが、ＲＯＭ（Read Only Memory）、ＲＡＭ、ＣＤ−ＲＯＭ等の他のコンピュータが読み取り可能な記録媒体に各種プログラムを格納しておき、コンピュータに読み取らせることとしてもよい。なお、記録媒体を遠隔地に配置し、コンピュータが、その記憶媒体にアクセスすることでプログラムを取得して利用してもよい。また、その際、取得したプログラムをそのコンピュータ自身の記録媒体に格納して用いてもよい。

ＣＰＵ１０１は、図２に示した各処理部と同様の処理を実行するプログラムをＨＤＤ１０３等から読み出してメモリ１０２に展開することで、図２等で説明した各機能を実行するプロセスを動作させる。すなわち、このプロセスは、障害検出装置１０が有する各処理と同様の機能を実行する。具体的には、ＣＰＵ１０１は、構成変更学習部２１、メッセージ収集部２２、障害予兆学習部２３、障害予兆検出部２４、構成差分算出部２５、予兆通報判定部２６、閾値学習部２７と同様の機能を有するプログラムをＨＤＤ１０３等から読み出す。そして、ＣＰＵ１０１は、各処理部と同様の処理を実行するプロセスを実行する。このようにコンピュータ１００は、プログラムを読み出して実行することで適用判定方法を実行する情報処理装置として動作する。

また、コンピュータ１００は、媒体読取装置によって記録媒体から上記プログラムを読み出し、読み出された上記プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、コンピュータ１００によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。

以上の各実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）コンピュータに、
第１のシステム構成において障害の予兆検出に用いられる障害予兆パターンを、前記第１のシステム構成において過去に発生した障害事象に基づいて生成し、
前記第１のシステム構成から第２のシステム構成へシステム構成が遷移する際に、システムを構成する構成要素の変更が実行された累積回数である変更回数を用いて、システム構成間の差を示す差分情報を算出し、
算出した前記差分情報に応じて、前記第２のシステム構成における障害の予兆検出への前記障害予兆パターンの適用可否を判定する
処理を実行させることを特徴とする適用判定プログラム。

（付記２）前記差分情報を算出する処理は、前記第１のシステム構成を構成する構成要素と前記第２のシステム構成を構成する構成要素とで相違する構成要素の数である差分数をさらに用いて、前記差分情報を算出することを特徴とする付記１に記載の適用判定プログラム。

（付記３）前記差分情報を算出する処理は、さらに、前記第１のシステム構成時におけるシステムの負荷量と前記第２のシステム構成時におけるシステムの負荷量との比である負荷量比を用いて、前記差分情報を算出することを特徴とする付記２に記載の適用判定プログラム。

（付記４）前記差分情報を算出する処理は、さらに、前記第１のシステム構成時におけるシステムの負荷の傾向を示す負荷パターンと前記第２のシステム構成時におけるシステムの負荷傾向を示す負荷パターンとの差である負荷パターン差を用いて、前記差分情報を算出することを特徴とする付記２または３に記載の適用判定プログラム。

（付記５）前記差分情報を算出する処理は、前記変更回数とさらに、前記第１のシステム構成を構成する構成要素と前記第２のシステム構成を構成する構成要素とで相違する構成要素の数である差分数と、前記第１のシステム構成時におけるシステムの負荷量と前記第２のシステム構成時におけるシステムの負荷量との比である負荷量比と、前記第１のシステム構成時におけるシステムの負荷の傾向を示す負荷パターンと前記第２のシステム構成時におけるシステムの負荷の傾向を示す負荷パターンとの差である負荷パターン差とのうち、少なくとも１つを用いて、前記差分距離を算出することを特徴とする付記１に記載の適用判定プログラム。

（付記６）前記生成した障害予兆パターンを用いて障害の予兆を検出する処理を前記コンピュータにさらに実行させ、
前記差分情報を算出する処理は、前記障害の予兆が検出された際のシステム構成を前記第２のシステム構成として抽出し、前記システム構成間の差分情報を算出することを特徴とする付記１から５のいずれか一つに記載の適用判定プログラム。

（付記７）前記障害予兆パターンを用いて障害の予兆を検出し、
前記障害の予兆が検出された後に、実際に障害が発生したか否か判定し、
判定した結果に基づいて、前記第２のシステム構成への前記障害予兆パターンの適用可否を判定する前記差分情報の閾値を決定する処理を前記コンピュータにさらに実行させることを特徴とする付記１から６のいずれか一つに記載の適用判定プログラム。

（付記８）第１のシステム構成において障害の予兆検出に用いられる障害予兆パターンを、前記第１のシステム構成において過去に発生した障害事象に基づいて生成する生成部と、
前記第１のシステム構成から第２のシステム構成へシステム構成が遷移する際に、システムを構成する構成要素の変更が実行された累積回数である変更回数を用いて、システム構成間の差を示す差分情報を算出する算出部と、
前記算出部によって算出された前記差分情報に応じて、前記第２のシステム構成における障害の予兆検出への前記障害予兆パターンの適用可否を判定する判定部と
を有することを特徴とする障害検出装置。

（付記９）コンピュータが、
第１のシステム構成において障害の予兆検出に用いられる障害予兆パターンを、前記第１のシステム構成において過去に発生した障害事象に基づいて生成し、
前記第１のシステム構成から第２のシステム構成へシステム構成が遷移する際に、システムを構成する構成要素の変更が実行された累積回数である変更回数を用いて、システム構成間の差を示す差分情報を算出し、
算出した前記差分情報に応じて、前記第２のシステム構成における障害の予兆検出への前記障害予兆パターンの適用可否を判定する
処理を含んだことを特徴とする適用判定方法。

（付記１０）メモリと、
前記メモリに接続されるプロセッサと、を有し、
前記プロセッサは、
第１のシステム構成において障害の予兆検出に用いられる障害予兆パターンを、前記第１のシステム構成において過去に発生した障害事象に基づいて生成し、
前記第１のシステム構成から第２のシステム構成へシステム構成が遷移する際に、システムを構成する構成要素の変更が実行された累積回数である変更回数を用いて、システム構成間の差を示す差分情報を算出し、
算出した前記差分情報に応じて、前記第２のシステム構成における障害の予兆検出への前記障害予兆パターンの適用可否を判定する
処理を実行することを特徴とする障害検出装置。

（付記１１）第１のシステム構成において障害の予兆検出に用いられる障害予兆パターンを、前記第１のシステム構成において過去に発生した障害事象に基づいて生成し、
前記第１のシステム構成から第２のシステム構成へシステム構成が遷移する際に、システムを構成する構成要素の変更が実行された累積回数である変更回数を用いて、システム構成間の差を示す差分情報を算出し、
算出した前記差分情報に応じて、前記第２のシステム構成における障害の予兆検出への前記障害予兆パターンの適用可否を判定する処理をコンピュータに実行させる適用判定プログラムを記憶する、コンピュータ読み取り可能な記憶媒体。

１ クライアント端末
２ データセンタ
５ ＣＭＤＢ
１０ 障害検出装置
１１ 通信処理部
１２ 記憶部
１３ 構成情報ＤＢ
１４ 構成変更情報ＤＢ
１５ 管理メッセージＤＢ
１６ 障害情報ＤＢ
１７ 障害予兆パターンＤＢ
１８ 障害予兆記録ＤＢ
２０ 制御部
２１ 構成変更学習部
２２ メッセージ収集部
２３ 障害予兆学習部
２４ 障害予兆検出部
２５ 構成差分算出部
２６ 予兆通報判定部
２７ 閾値学習部

Claims (9)

1. コンピュータに、
   第１のシステム構成において障害の予兆検出に用いられる障害予兆パターンを、前記第１のシステム構成において過去に発生した障害事象に基づいて生成し、
   前記第１のシステム構成から第２のシステム構成へシステム構成が遷移する際に、システムを構成する構成要素の変更が実行された累積回数である変更回数を用いて、システム構成間の差を示す差分情報を算出し、
   算出した前記差分情報に応じて、前記第２のシステム構成における障害の予兆検出への前記障害予兆パターンの適用可否を判定する
   処理を実行させることを特徴とする適用判定プログラム。
2. 前記差分情報を算出する処理は、前記第１のシステム構成を構成する構成要素と前記第２のシステム構成を構成する構成要素とで相違する構成要素の数である差分数をさらに用いて、前記差分情報を算出することを特徴とする請求項１に記載の適用判定プログラム。
3. 前記差分情報を算出する処理は、さらに、前記第１のシステム構成時におけるシステムの負荷量と前記第２のシステム構成時におけるシステムの負荷量との比である負荷量比を用いて、前記差分情報を算出することを特徴とする請求項２に記載の適用判定プログラム。
4. 前記差分情報を算出する処理は、さらに、前記第１のシステム構成時におけるシステムの負荷の傾向を示す負荷パターンと前記第２のシステム構成時におけるシステムの負荷傾向を示す負荷パターンとの差である負荷パターン差を用いて、前記差分情報を算出することを特徴とする請求項２または３に記載の適用判定プログラム。
5. 前記差分情報を算出する処理は、前記変更回数とさらに、前記第１のシステム構成を構成する構成要素と前記第２のシステム構成を構成する構成要素とで相違する構成要素の数である差分数と、前記第１のシステム構成時におけるシステムの負荷量と前記第２のシステム構成時におけるシステムの負荷量との比である負荷量比と、前記第１のシステム構成時におけるシステムの負荷の傾向を示す負荷パターンと前記第２のシステム構成時におけるシステムの負荷の傾向を示す負荷パターンとの差である負荷パターン差とのうち、少なくとも１つを用いて、前記差分情報を算出することを特徴とする請求項１に記載の適用判定プログラム。
6. 前記生成した障害予兆パターンを用いて障害の予兆を検出する処理を前記コンピュータにさらに実行させ、
   前記差分情報を算出する処理は、前記障害の予兆が検出された際のシステム構成を前記第２のシステム構成として抽出し、前記システム構成間の差分情報を算出することを特徴とする請求項１から５のいずれか一つに記載の適用判定プログラム。
7. 前記障害予兆パターンを用いて障害の予兆を検出し、
   前記障害の予兆が検出された後に、実際に障害が発生したか否か判定し、
   判定した結果に基づいて、前記第２のシステム構成への前記障害予兆パターンの適用可否を判定する前記差分情報の閾値を決定する処理を前記コンピュータにさらに実行させることを特徴とする請求項１から６のいずれか一つに記載の適用判定プログラム。
8. 第１のシステム構成において障害の予兆検出に用いられる障害予兆パターンを、前記第１のシステム構成において過去に発生した障害事象に基づいて生成する生成部と、
   前記第１のシステム構成から第２のシステム構成へシステム構成が遷移する際に、システムを構成する構成要素の変更が実行された累積回数である変更回数を用いて、システム構成間の差を示す差分情報を算出する算出部と、
   前記算出部によって算出された前記差分情報に応じて、前記第２のシステム構成における障害の予兆検出への前記障害予兆パターンの適用可否を判定する判定部と
   を有することを特徴とする障害検出装置。
9. コンピュータが、
   第１のシステム構成において障害の予兆検出に用いられる障害予兆パターンを、前記第１のシステム構成において過去に発生した障害事象に基づいて生成し、
   前記第１のシステム構成から第２のシステム構成へシステム構成が遷移する際に、システムを構成する構成要素の変更が実行された累積回数である変更回数を用いて、システム構成間の差を示す差分情報を算出し、
   算出した前記差分情報に応じて、前記第２のシステム構成における障害の予兆検出への前記障害予兆パターンの適用可否を判定する
   処理を含んだことを特徴とする適用判定方法。

Images