(57)【要約】【課題】監視対象システムの異常状態を判別するためのルールを事前に登録することなく、また、システムに異常が発生しているがトラップできないサイレント状態においても、異常を検知する。【解決手段】１つ以上の物理的または仮想的な装置を含む監視対象システムの状態を監視する分析装置であって、装置が出力する、装置の状態を示すメトリクス情報を、複数種類収集する収集部と、複数種類のメトリクス情報の任意の二つの時系列を用いた演算を行い、一つ以上の演算結果を取得し、一つ以上の演算結果が、予め定めたしきい値を超えたことを検出した場合に、装置に状態変化が生じた、と判定する状態分析部と、を備えることを特徴とする。【選択図】  図１
2017224181.tif 000002
【特許請求の範囲】
【請求項１】
１つ以上の物理的または仮想的な装置を含む監視対象システムの状態を監視する分析装置であって、
前記装置が出力する、前記装置の状態を示すメトリクス情報を、複数種類収集する収集部と、
前記複数種類のメトリクス情報の任意の二つの時系列を用いた演算を行い、一つ以上の演算結果を取得し、
前記一つ以上の演算結果が、予め定めたしきい値を超えたことを検出した場合に、前記装置に状態変化が生じた、と判定する状態分析部と、を備える
ことを特徴とする分析装置。
【請求項２】
請求項１に記載の分析装置であって、
前記状態分析部は、「前記装置の状態変化」に最も関連する、他のメトリクス情報への影響度が最も大きい、前記メトリクス情報を、前記状態変化の第一の原因情報とする
ことを特徴とする分析装置。
【請求項３】
請求項１または２に記載の分析装置であって、
前記状態分析部は、
前記演算として、
前記二つの時系列の相関係数を算出し、
前記相関係数の値が所定の値以上であれば、相関関係があるとみなし、
前記相関関係がある前記二つの時系列について、前記演算結果として、データのばらつき度を計算する
ことを特徴とする分析装置。
【請求項４】
請求項１または２に記載の分析装置であって、
前記状態分析部は、
前記演算として、前記二つの時系列のいずれか一つの時系列を演算し、
前記演算により得られる情報が、前記しきい値を超えた場合に、前記装置に状態変化が生じた、と判定する
ことを特徴とする分析装置。
【請求項５】
請求項２に記載の分析装置において、
前記「状態変化に最も関連する前記メトリクス情報」とは、前記しきい値を超えた演算結果を複数得る際に最多に用いられるメトリクス情報である
ことを特徴とする分析装置。
【請求項６】
請求項２に記載の分析装置において、
前記状態分析部は、前記第一の原因情報が関係する前記状態変化の中で、前記第一の原因情報による影響度が所定の値以上である前記メトリクス情報を、第一の結果情報とする、
ことを特徴とする分析装置。
【請求項７】
請求項６に記載の分析装置において、
前記状態分析部は、前記装置が複数の場合、前記状態変化の発生箇所である前記装置を識別する情報を、第一の装置識別情報とする
ことを特徴とする分析装置。
【請求項８】
請求項７に記載の分析装置において、
前記分析装置は、さらに、事象分析部を備え、
前記収集部は、前記装置が出力する、前記装置で発生した事象に関するイベント情報を収集し、
当該状態変化との関係の強さが大きい１つ以上のイベント情報を抽出し、各々の前記抽出したイベント情報について、当該状態変化に対する関連度を評価し、
前記収集したイベント情報のうち、前記状態変化との前記関連度が最も高い前記イベント情報を、第二の原因情報と特定し、
前記事象分析部は、当該第二の原因情報に起因して発生したと推定できる他の１つ以上の前記イベント情報を、第二の結果情報とする
ことを特徴とする分析装置。
【請求項９】
請求項８に記載の分析装置において、
前記イベント情報は、当該イベント情報が示す事象が発生した第二の日時情報と、前記事象が発生した装置を識別する第二の装置識別情報と、を含み、
前記事象分析部は、
前記第一の装置識別情報、および、前記状態変化が発生した第一の日時情報と、
前記第二の装置識別情報、および、前記第二の日時情報との近さを、前記状態変化との関係の強さとして評価する
ことを特徴とする分析装置。
【請求項１０】
請求項９に記載の分析装置において、
前記イベント情報の識別情報と、前記関連度を算出するための情報と、を対応付けて記憶する、第一の記憶部と、
前記状態変化の、前記第一または前記第二の原因情報と、前記第一または前記第二の結果情報と、を対応付けた因果関係と、
当該因果関係の発生確率を算出するための情報と、を対応付けて、第二の記憶部に記憶する、登録部と、
前記イベント情報を検出すると、当該イベント情報を前記第二の原因情報とする１つ以上の前記因果関係を、第二の記憶部から取得し、取得した各々の前記因果関係について、前記発生確率を算出する影響分析部と、を備える
ことを特徴とする分析装置。
【請求項１１】
請求項１０に記載の分析装置において、
前記第一の記憶部は、
前記イベント情報の識別情報である第一のイベント識別情報と、前記第一または前記第二の装置識別情報と、前記イベント情報を検出した検出回数と、前記状態変化を検出した回数である第一の状態変化回数と、対応付けて記憶し、
前記事象分析部は、前記関連度を、
前記第一のイベント識別情報および前記第一の装置識別情報とで識別される前記イベント情報に対する、前記第一の状態変化回数を、前記検出回数に対する割合として算出する
ことを特徴とする分析装置。
【請求項１２】
請求項１１に記載の分析装置において、
前記第二の記憶部は、
前記第一または前記第二の原因情報である前記イベント情報の、識別情報である第二のイベント識別情報と、前記第一または前記第二の装置識別情報と、前記第一または前記第二の結果情報と、前記状態変化を検出した回数である第二の状態変化回数と、対応付けて記憶し、
前記影響分析部は、前記発生確率を、
前記第二のイベント識別情報および前記第二の装置識別情報で識別される前記第一または前記第二の原因情報と、前記結果情報とで識別される、前記因果関係に対する、前記第二の状態変化回数を、前記検出回数に対する割合として算出する
ことを特徴とする分析装置。
【請求項１３】
請求項１０に記載の分析装置において、
前記影響分析部は、前記イベント情報を検出すると、前記算出した発生確率を、当該イベント情報の発生による、前記監視対象システムへの影響度として出力する
ことを特徴とする分析装置。
【請求項１４】
請求項２に記載の分析装置において、
前記メトリクス情報における、前記『他のメトリクス情報への影響度』は、当該メトリクス情報が影響を与えた前記他のメトリクス情報の数であり、
相関係数が所定の値以上である任意の２種類の前記メトリクス情報の組は、相関関係にあり、
前記状態分析部は、
複数種類の前記メトリクス情報における前記相関係数を算出し、
前記相関関係にある前記『組』を抽出し、
前記状態変化における、前記メトリクス情報ごとの、前記『他のメトリクス情報への影響度』を算出し、
前記『他のメトリクス情報への影響度』が最も大きい前記メトリクス情報を、第一の原因情報とする
ことを特徴とする分析装置。
【請求項１５】
請求項６に記載の分析装置において、
前記メトリクス情報における、前記『他のメトリクス情報への影響度』は、当該メトリクス情報が影響を与えた他の前記メトリクス情報の数であり、
相関係数が所定の値以上である任意の２種類の前記メトリクス情報の組は、相関関係にあり、
前記状態分析部は、
複数種類の前記メトリクス情報における前記相関係数を算出し、
前記相関関係にある前記『組』を抽出し、
前記状態変化における、前記メトリクス情報ごとの、前記『他のメトリクス情報への影響度』を算出し、
前記第一の原因情報による影響度が所定の値以上である、１つ以上の前記メトリクス情報を、第一の結果情報とする
ことを特徴とする分析装置。
【請求項１６】
請求項７に記載の分析装置において、
前記状態分析部は、前記第一の原因情報と特定した前記メトリクス情報を出力する装置を、前記状態変化の発生箇所と推定する
ことを特徴とする分析装置。
【請求項１７】
請求項８に記載の分析装置において、
前記事象分析部は、前記抽出した状態変化との関係の強さが大きいイベント情報のうち、前記第二の原因情報以外の前記イベント情報を、前記第二の結果情報と特定する
ことを特徴とする分析装置。
【請求項１８】
請求項８に記載の分析装置において、
前記事象分析部は、収集した前記複数種類のイベント情報の中で、前記状態変化との前記関連度が最も高い前記イベント情報を、前記第二の原因情報と特定する
ことを特徴とする分析装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書で開示される主題は、監視対象システムを監視する分析装置に関する。
【背景技術】
【０００２】
近年、インターネットアクセス機能を有する携帯電話などの急激な発展に伴い、様々な商用または公共サービスが通信ネットワークを介して提供されている。このようなネットワークサービスが発展し重要性が増す一方で、サービスを提供する基盤であるコンピュータシステム（以下、システム）の障害が社会に与える影響は、その重要性に比例して大きくなってきている。システムの一例として、携帯電話のパケット交換システムがある。パケット交換システムは、様々な機能を有する機器（以下ノードという）群により構成されている。
【０００３】
これらのノードで故障や輻輳などが発生すると、利用者（エンドユーザ）に十分な通信サービスを提供できなくなる状態、即ち障害となる。また、場合によっては、事前に取り決めたサービスレベル契約に違反したとして、システム運営者が損害を被る恐れがある。
【０００４】
よって、システムの異常を早期に検知する監視システムが望まれている。また、検知した異常が深刻化した場合にシステムにどのような影響が生じるか、を事前に把握できれば、その内容に応じて異常対応の優先度を判断できるため、そのような機能を持つ監視システムが望まれている。
【０００５】
特許文献１には、異常時の相関関係のモデルの崩れの分布を予め運用管理装置に登録しておいた上で、運用管理装置が、システム運用時に、相関関係の崩れの分布が、異常時の崩れの分布に近似していく傾向があると判断すると、障害の予兆とみなす技術について記載されている。
【０００６】
また、特許文献２には、ルールに基づいて障害原因分析を行う障害解析システムにおいて、管理対象装置で発生したイベントの発生履歴に基づいて、他のイベントの発生原因となる結論イベントと、結論イベントによって発生した条件イベントを推定し、結論イベントと条件イベントのルールを自動的に作成する技術について記載されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開第２０１３−２００８９９号公報
【特許文献２】国際公開第２０１３−１４０６０８号
【発明の概要】
【発明が解決しようとする課題】
【０００８】
特許文献１が開示する技術は、相関関係の崩れの分布モデルを予め登録しておく必要がある。しかし、構成の新しいネットワークを監視したい場合や、過去に事例のない障害を検知したい場合は、異常時の相関関係の崩れの分布が事前に分からない場合がある。
【０００９】
また、特許文献２が開示する技術では、システムで生じた事象（イベント）を対象にして、ルールを自動的に作成する。しかしながら、特許文献２には、システムに潜在的な異常が発生しているがイベントを生成するほどには顕在化していないケースや、システムに明らかな異常が発生しているが、その状態をトラップできないケースといった、イベントが生成されないサイレント状態の異常に対応するための技術は開示されていない。
【００１０】
以上のように、事前に検知方法が定められていない場合であっても、および／または、顕在化していなくても、異常を検知できる方法が望まれている
【課題を解決するための手段】
【００１１】
本明細書で開示されるのは、１つ以上の物理的または仮想的な装置を含む監視対象システムの状態を監視する分析装置であり、上記分析装置は、装置が出力する、装置の状態を示すメトリクス情報を、複数種類収集する収集部と、複数種類のメトリクス情報の任意の二つの時系列を用いた演算を行い、一つ以上の演算結果を取得し、一つ以上の演算結果が、予め定めたしきい値を超えたことを検出した場合に、装置に状態変化が生じた、と判定する状態分析部と、を備えることを特徴とする。
【００１２】
さらに、状態分析部は、「装置の状態変化」に最も関連する、他のメトリクス情報への影響度が最も大きい、メトリクス情報を、状態変化の第一の原因情報とする、ように構成しても良い。
【００１３】
また、状態分析部は、演算として、二つの時系列の相関係数を算出し、相関係数の値が所定の値以上であれば、相関関係があるとみなし、相関関係がある二つの時系列について、演算結果として、データのばらつき度を計算する、ように構成しても良い。
【００１４】
また、状態分析部は、演算として、二つの時系列のいずれか一つの時系列を演算し、演算により得られる情報が、しきい値を超えた場合に、装置に状態変化が生じた、と判定する、ように構成しても良い。
【００１５】
また、「状態変化に最も関連するメトリクス情報」として、しきい値を超えた演算結果を複数得る際に最多に用いられるメトリクス情報である、と定義しても良い。
【００１６】
また、状態分析部は、第一の原因情報が関係する状態変化の中で、第一の原因情報による影響度が所定の値以上であるメトリクス情報を、第一の結果情報とする、ように構成しても良い。
【００１７】
また、メトリクス情報における、『他のメトリクス情報への影響度』は、当該メトリクス情報が影響を与えた他のメトリクス情報の数であり、相関係数が所定の値以上である任意の２種類のメトリクス情報の組は、相関関係にある、と定義し、状態分析部、複数種類のメトリクス情報における相関係数を算出し、相関関係にある『組』を抽出し、状態変化における、メトリクス情報ごとの、『他のメトリクス情報への影響度』を算出し、『他のメトリクス情報への影響度』が最も大きいメトリクス情報を、第一の原因情報とする、ように構成しても良い。
上記態様によれば、過去に事例のないような新しい構成のネットワークを監視したい場合や、過去に事例のないような障害を検知したい場合などにおいても、異常やその予兆を検知することができる。
【００１８】
また、システムに潜在的な異常が発生しているがイベントを生成するほどには顕在化していないケースや、システムに明らかな異常が発生しているが、その状態をトラップできないケースといった、サイレント状態の異常を検知することができる。
【００１９】
さらに、検知した異常がシステムにどのような影響が生じるかを、影響範囲とその発生予想確率を出力することができる。
【発明の効果】
【００２０】
開示によれば、事前に検知方法が定められていない場合であっても、および／または、顕在化していなくても、異常を検知できる技術を提供できる。
【００２１】
上記した以外の課題、構成および効果は、以下の実施形態の説明により明らかにされる。
【図面の簡単な説明】
【００２２】
【図１】監視システムの構成を例示するブロック図。
【図２】関連度テーブルの構成例を示す構成図。
【図３】因果関係テーブルの構成例を示す構成図。
【図４】分析部の処理手順の一例を示すフローチャート。
【図５】分析部の処理手順における、収集処理の一例を示すフローチャート。
【図６】分析部の処理手順における、状態分析処理の一例を示すフローチャート。
【図７】分析部の処理手順における、事象分析処理の一例を示すフローチャート。
【図８】分析部の処理手順における、登録処理の一例を示すフローチャート。
【図９】分析部の処理手順における、影響分析処理の一例を示すフローチャート。
【図１０】実施例に係る各装置の構成の一例を示すブロック図。
【発明を実施するための形態】
【００２３】
以下、実施例を、図面を用いて説明する。
【実施例１】
【００２４】
（システムの構成要素）
図１から図４および図１０を参照して、各実施例の前提となる監視システムの構成および動作を説明する。
【００２５】
図１は、情報処理や通信処理を実行する監視対象システム１の運用状態を監視する、本実施例を適用した監視システム２の構成要素を示すブロック図である。
監視対象システム１は、物理的または仮想的な装置１０を１つ以上備える。装置１０は、ネットワーク９０を経由して、他の装置１０や監視システム２と相互に通信を行う。
【００２６】
ネットワーク９０は、ＬＡＮ（Local Area Network）に代表されるコンピュータネットワークである。一般的には有線ＬＡＮであるが、無線ＬＡＮを用いても良い。また、ＷＡＮ（Wide Area Network）を経由しても良い。
【００２７】
監視システム２は、分析装置２０を有する。
【００２８】
分析装置２０は、装置１０が出力するログ情報を収集し、その内容を分析して、監視対象システム１の状態に異常が発生したことを検知する。分析装置２０は、収集部２００と、状態分析部２０１と、事象分析部２０２と、登録部２０３と、影響分析部２０４と、関連度記憶部２１と、因果関係記憶部２２と、を有する。
【００２９】
収集部２００は、監視対象システム１が出力する、監視対象システムの内部状態の評価指標であるメトリクス情報１０１を経時的に収集し、その時系列を作成する。メトリクス情報１０１は、主に装置１０の性能情報であり、たとえば、ＣＰＵ使用率や、ネットワークインタフェースにおける送信や受信パケット数である。
【００３０】
収集部２００は、また、監視対象システム１が出力する、監視対象システム１または装置１０で発生した、監視システム２に通知すべき事象に関する情報であるイベント情報１０２を収集する。
【００３１】
イベント情報１０２は、例えば、装置１０でハードウェア故障が発生したという事象のシスログやエラーログである。
【００３２】
別の例では、イベント情報１０２は、キーボードなどの入力装置１００５（図１０参照）から装置１０に入力されたコマンドのログ（操作ログ）である。この操作ログは、主に装置１０が自動的に記録したログであるが、装置１０の動作試験における手順書の記載内容（コマンド内容とコマンド入力日時を含む）から生成しても良い。
【００３３】
さらに別の例では、イベント情報１０２は、装置１０の外部から、ネットワーク９０経由で装置１０に送信されたコマンドの情報を記録したログ（通信ログ）である。
【００３４】
状態分析部２０１は、監視対象システム１の内部状態に状態変化が発生したことを検出する。また、当該状態変化に最も関連するメトリクス情報１０１を、監視対象システム１や、監視対象システム１を構成する装置１０の内部状態に状態変化が発生した第一の原因情報、と推定する処理を行う。
【００３５】
また、第一の原因情報が関係する状態変化の中で、第一の原因によって引き起こされた影響内容を推定する処理を行う。
【００３６】
事象分析部２０２は、状態変化の発生箇所に基づいて、状態変化との関係の強さが大きいイベント情報１０２を抽出し、抽出したイベント情報１０２のそれぞれについて、状態変化に対する関連度を評価する。そして、抽出したイベント情報１０２のうち、状態変化との関連度が最も高いイベント情報１０２を推定する。
さらに、第二の原因に引き起こされた影響内容を推定する。
【００３７】
登録部２０３は、状態変化の原因と、原因によって引き起こされた影響内容と、を対応付けて因果関係とし、当該因果関係を記憶する処理を行う。
【００３８】
影響分析部２０４は、イベント情報１０２を検出すると、当該イベント情報１０２を原因とする因果関係を、後述の因果関係記憶部２２から取得し、さらに、取得した因果関係のそれぞれについて、発生確率を算出する処理を行う。
【００３９】
関連度記憶部２１は、イベント情報１０２の識別情報と、上述の関連度を算出するための情報と、を対応付けて記憶するための記憶領域である。
【００４０】
因果関係記憶部２２は、登録部２０３が因果関係を記憶するための記憶領域である。
【００４１】
監視システム２は、分析装置２０で分析した結果を、管理サーバ２９に通知しても良い。
（装置の構成要素）
図１０に一例を示すように、装置１０や分析装置２０など、各実施例に係る各装置は、一般的なコンピュータ１０００上に実現できる。
【００４２】
コンピュータ１０００は、ＣＰＵ１００１、主記憶装置１００２、ＨＤＤなどの二次記憶装置１００３、ネットワーク１０２０に接続するためのＮＩＣ（Network Interface Card）等のネットワークインタフェース装置１００４、キーボードやマウスなどの入力装置１００５、ディスプレイなどの出力装置１００６、および、それらの装置間を接続するバスなどの内部通信線１０１０を備える。
【００４３】
例えば、分析装置２０が備える関連度記憶部２１や因果関係記憶部２２は、主記憶装置１００２の一部の領域を用いて実現できる。
【００４４】
また、各装置は、それぞれの補助記憶装置１００３に記憶されている各種プログラムを主記憶装置１００２にロードしてＣＰＵ１００１で実行し、必要に応じて、ネットワークインタフェース装置１００４を用いてネットワーク１０２０に接続して、他の装置とのネットワーク通信を行うことにより、各実施例における各種処理を実現できる。
【００４５】
各プログラムは、あらかじめ、上記二次記憶装置１００３に格納されていても良いし、必要なときに、インタフェース装置１００４と上記コンピュータ１０００が利用可能な記憶媒体、または通信媒体を介して、他の装置から導入されてもよい。
また、分析装置２０が有する各処理部は、ハードウェアのモジュールとして実装してもよい。
（関連度記憶部の構成）
図２は、関連度テーブル２１０の構成を示す図である。関連度記憶部２１は、イベント情報１０２の識別情報と、上述の関連度を算出するための情報と、を対応付けた関連度情報を、例えばテーブル化した関連度テーブル２１０として記憶する。
【００４６】
関連度テーブル２１０は、イベント情報１０２の識別情報１０２１を記憶するための、装置識別情報フィールド２１００およびイベント識別情報フィールド２１０１と、関連度を算出するための情報２１１を記憶するための、検出回数フィールド２１０２と、状態変化回数フィールド２１０３と、を構成項目として含む。テーブルの取り扱い単位（１行）は、エントリと呼称される。
装置識別情報フィールド２１００は、イベント情報１０２が発生した装置を識別する情報（装置識別情報１０２１１）を記憶する領域である。
【００４７】
イベント識別情報フィールド２１０１は、イベント情報１０２の識別情報（イベント識別情報１０２１２）を記憶する領域である。
【００４８】
検出回数フィールド２１０２は、イベント情報１０２を検出した回数（検出回数２１１１）を記憶する領域である。
【００４９】
状態変化回数フィールド２１０３は、状態変化を検出した回数（状態変化回数２１１２）を記憶する領域である。
【００５０】
例えば、図２の関連度テーブル２１０の１行目（第１エントリ）には、装置識別情報として『装置Ｂ』、イベント識別情報として『８３４５』、検出回数として『１４』、状態変化回数として『１３』という値が記憶されている。
（因果関係記憶部の構成）
図３は、因果関係記憶部２２の記憶内容である因果関係情報をテーブル化した、因果関係テーブル２２０を示す構成図である。
【００５１】
因果関係テーブル２２０は、状態変化の原因と推定される情報（原因情報２２１１）と、状態変化の影響と推定される情報（結果情報２２１３）と、を対応付けた因果関係情報２２１と、当該因果関係情報２２１に示される状態変化の発生確率を算出するための情報２２２と、を対応付けて記憶するテーブルである。
【００５２】
因果関係テーブル２２０は、原因情報２２１１を記憶するための、装置識別情報フィールド２２００およびイベント識別情報フィールド２２０１と、結果情報２２１３を記憶するための、結果情報フィールド２２０２と、因果関係の発生確率を算出するための情報２２２を記憶するための、状態変化回数フィールド２２０３と、を構成項目として含む。
【００５３】
装置識別情報フィールド２２００は、状態変化の発生箇所と推定した装置を識別する情報（装置識別情報１０２１１）を記憶する領域である。
【００５４】
イベント識別情報フィールド２２０１は、原因情報２２１１と推定されるイベント情報１０２の識別情報（イベント識別情報１０２１２）を記憶する領域である。
【００５５】
結果情報フィールド２２０２は、結果情報２２１３と推定される、メトリクス情報１０１またはイベント情報１０２を、少なくとも１つ以上記憶する領域である。
【００５６】
状態変化回数フィールド２２０３は、因果関係情報２２１に起因する状態変化を検出した回数（状態変化回数２２０３）を記憶する領域である。
【００５７】
例えば、図３の因果関係テーブル２２０の１行目（第１エントリ）には、装置識別情報として『装置Ｂ』、イベント識別情報として『８３４５』、結果情報として３種類の結果情報、状態変化回数として『１２』という値が記憶されている。
（分析部の処理フロー）
図４は、本実施例における、分析装置２０の処理フローを示す図である。
【００５８】
図４の処理フロー図に基づく動作は以下のとおりである。
【００５９】
分析装置２０は、収集処理Ｓ１０と、状態分析処理Ｓ２０と、事象分析処理Ｓ３０と、登録処理Ｓ４０と、影響分析処理Ｓ５０と、を行う。
【００６０】
収集処理Ｓ１０では、収集部２００は、監視対象システム１が出力する、監視対象システムの内部状態の評価指標であるメトリクス情報１０１を収集する。
【００６１】
また、収集部２００は、監視対象システム１が出力する、監視対象システム１または装置１０で発生した、監視システム２に通知すべき事象に関する情報であるイベント情報１０２を収集する。
【００６２】
状態分析処理Ｓ２０では、状態分析部２０１は、監視対象システム１の内部状態に状態変化が発生したことを検出する。
【００６３】
また、状態分析部２０１は、当該状態変化に最も関連するメトリクス情報１０１を、監視対象システム１や、監視対象システム１を構成する装置１０の内部状態に状態変化が発生した第一の原因と推定する処理を行う。当該メトリクス情報１０１を、第一の原因情報２２１１Ａとする。
【００６４】
また、状態分析部２０１は、原因情報が関係する状態変化の中で、第一の原因情報による影響の度合い（影響度）が大きいメトリクス情報１０１を推定する処理を行う。当該メトリクス情報１０１を、第一の結果情報２２１３Ａとする。
【００６５】
事象分析処理Ｓ３０では、事象分析部２０２は、状態変化の発生箇所に基づいて、状態変化との関係の強さが大きいイベント情報１０２を抽出し、抽出したイベント情報１０２のそれぞれについて、状態変化に対する関連度を評価する。
【００６６】
そして、抽出したイベント情報１０２のうち、状態変化との関連度が最も高いイベント情報１０２を推定する。当該イベント情報１０２を、第二の原因情報２２１１Ｂとする。
さらに、第二の原因に起因して発生したイベント情報１０２を推定する。当該イベント情報１０２を、第二の結果情報２２１３Ｂとする。
【００６７】
登録処理Ｓ４０では、登録部２０３は、状態変化の原因と、原因によって引き起こされた影響内容と、を対応付けて因果関係情報２２１とし、当該因果関係情報２２１を記憶する処理を行う。
【００６８】
影響分析処理Ｓ５０では、影響分析部２０４は、収集処理Ｓ１０でイベント情報１０２を検出した場合に、当該イベント情報１０２を原因情報２２１１とする因果関係情報２２１を、後述の因果関係記憶部２２から取得する。
【００６９】
さらに、取得した因果関係情報２２１のそれぞれについて、発生確率を算出する処理を行う。
【００７０】
実施例１は、監視システム２が、監視対象システム１が出力するメトリクス情報（性能統計情報）を用いて、監視対象システム１の状態変化を検出し、当該状態変化の原因と影響を推定し、当該状態変化の発生箇所を推定する処理に関するものである。
【００７１】
図５から図９を用いて、本実施例における、分析装置２０の各処理の手順の詳細を示す。
（収集部の処理フロー）
図５は、本実施例における、収集処理Ｓ１０の処理手順を示すフローチャートである。図５のフローチャートに基づく動作を以下に示す。
【００７２】
収集処理Ｓ１０は、イベント情報収集ステップ（ステップＳ１０２）と、メトリクス情報収集ステップと（ステップＳ１０１）を含んでいるが、本実施例では、収集処理Ｓ１０は、イベント情報収集ステップＳ１０２をスキップし、メトリクス情報収集ステップＳ１０２を実行する。
【００７３】
メトリクス情報収集ステップＳ１０２の詳細を以下に示す。
収集部２００は、前回にステップＳ１０１２を実行した時刻から所定の時間間隔が経過していればステップＳ１０１２に進み、経過していなければステップＳ１０２１に戻る（ステップＳ１０１１）。また、ステップＳ１０１２が未実行の場合は、処理をステップＳ１０１２に進める。
【００７４】
収集部２００は、監視対象システム１が出力したメトリクス情報１０１を収集する（ステップＳ１０１２）。
【００７５】
例えば、収集部２００は、専用のエージェントプログラムを用いて、装置１０からメトリクス情報１０１を収集する。管理サーバ２９がエージェントプログラムを用いて、メトリクス情報１０１を、定期的に収集しても良い。
【００７６】
メトリクス情報１０１は、少なくとも、評価指標としての値と、装置１０が当該値を計測した日時情報（タイムスタンプ）と、装置１０の識別情報（装置識別情報）と、出力するメトリクス情報１０１の識別情報と、を含む。
【００７７】
メトリクス情報１０１は、一般的にはテキスト形式で出力されるが、バイナリ形式で出力されていても良い。
【００７８】
日時情報は、『23/Jan/2016 12:10:00』や『2016-01-23T12:10:00』のように、年月日と時刻を含む情報である。年や秒など、一部の情報は省略されていても良い。装置識別情報は、『装置Ａ』など、装置名や号機を含み、装置１０を一意に特定できる情報である。
【００７９】
メトリクス情報１０１の識別情報は、『CPU使用率(分析部２０４)』や『NIF分析部２０２1受信バイト数(pps)』など、メトリクスの内容を一意に示す情報である。
【００８０】
評価指標としての値は、『30.8』や『148』など、数値で示される情報である。
【００８１】
装置１０が出力したメトリクス情報１０１に、装置識別情報が含まれていない場合は、収集部２００や他の装置１０が、装置識別情報を追加してメトリクス情報１０１を再出力したものを、改めてメトリクス情報１０１として利用しても良い。
【００８２】
分析装置２０は、収集処理Ｓ１０を終了し、処理を状態分析処理Ｓ２０に進める（ステップＳ１０１３）。
（状態分析部の処理フロー）
図６は、本実施例における、状態分析処理Ｓ２０の処理手順を示すフローチャートである。図６のフローチャートに基づく動作を以下に示す。
【００８３】
状態分析処理Ｓ２０は、状態変化検出ステップ（ステップＳ２０１）と、第一の因果関係判定ステップ（ステップＳ２０２）と、変化箇所推定ステップ（ステップＳ２０３）と、を含んでいる。
【００８４】
状態分析処理Ｓ２０の詳細を以下に示す。
【００８５】
状態分析部２０１は、収集したメトリクス情報１０１の時系列を演算し、演算結果の変化を検出する（ステップＳ２０１１）。
【００８６】
状態分析部２０１が演算結果の変化を検出する方法には、単一のメトリクス情報１０１の変化を検出する方法や、複数のメトリクス情報１０１間の相関関係を解析して相関関係の崩れを検出する方法がある。
【００８７】
相関関係の崩れを検出する方法として、例えば、以下の方法がある。
【００８８】
状態分析部２０１は、データＡとデータＢという２種類のメトリクス情報の時系列を収集した場合、
（ａ）データＡとデータＢのそれぞれで、同一の時間帯（例えば、現在時刻から過去４８時間分）のデータを抽出し、
（ｂ）データＡとデータＢの相関度（相関係数、例えばピアソンの積率相関係数を用いても良い）を算出し、（ｃ）相関度が所定の強さ以上であれば（相関係数の値が所定の値、例えば０．９以上）、相関関係があるとみなし、
（ｄ）相関関係があるデータセット（ここではデータＡとデータＢ）について外れ値（しきい値を超える変化）を検出した場合に、相関関係の崩れが発生したとみなす。
より具体的には、データＡとデータＢのマハラノビス距離を計算し、マハラノビス距離が予め定めた所定の値（しきい値）を超過した場合に、外れ値を検出したとしても良い。
（ｅ）相関関係の崩れの発生を検出した場合に、監視対象システム１の内部状態の変化を検出したと判定する。
【００８９】
単一のメトリクス情報１０１の変化を検出する場合は、その時系列を演算して得られる情報が予め定めたしきい値を超過した場合に、変化を検出したと見做しても良い。
【００９０】
状態分析部２０１が演算結果の変化を複数検出した場合は、状態変化を検出した、と判断して、ステップＳ２０１３に進む。検出しなければ、ステップＳ２０１４に進む（ステップＳ２０１２）。
状態分析部２０１は、状態変化を検出したメトリクス情報１０１の日時情報を記憶し、ステップＳ２０２１に進む（ステップＳ２０１３）。
【００９１】
例えば、上述の例では、状態分析部２０１は、相関関係があるデータセットの中で、全ての、外れ値を計測した日時（タイムスタンプ）を記憶する。
状態分析部２０１は、処理を収集処理Ｓ１０に戻す（ステップＳ２０１４）。
状態分析部２０１は、複数の演算結果の変化に最も関連するメトリクス情報１０１を、システムの状態変化が発生した第一の原因情報と推定する（ステップＳ２０２１）。
【００９２】
例えば、状態分析部２０１は、相関関係がある３つのデータセット（ここではデータＡとデータＢ、データＢとデータＣ、データＣとデータＡ）において、データＡとデータＢ、およびデータＢとデータＣの２つのデータセットで相関関係の崩れを検出した場合、
（ａ）相関関係の崩れが発生したデータセットにおいて、メトリクスごとに登場回数を計算する。ここでは、データＢ＝２回、データＡとデータＣ＝１回となる。
（ｂ）回数が最も多いメトリクス（ここではデータＢ）を、状態変化の第一の原因と推定する。
【００９３】
状態分析部２０１は、状態変化の中で、第一の原因情報との関係性の変化の度合いが大きいメトリクス情報を、第一の結果情報として抽出する（ステップＳ２０２２）。
【００９４】
例えば、上述の例では、第一の原因であるデータＢとの相関関係が崩れたメトリクス、すなわちデータＡとデータＣを、状態変化の第一の結果と推定する。
【００９５】
状態分析部２０１は、第一の原因情報が属する装置１０を、状態変化の発生箇所と推定する（ステップＳ２０３１）。
【００９６】
上述の例では、第一の原因が装置Ｂ１０のメトリクス、例えばそれが、装置Ｂ１０のネットワークインタフェースの受信パケット数であったとすると、状態分析部２０１は、装置Ｂ１０を状態変化の発生箇所と推定する。
【００９７】
状態分析部２０１は、ステップＳ２０３１の後、第一の原因情報と第一の結果情報を、管理サーバ２９に通知しても良い。
その後、状態分析部２０１は、状態分析処理Ｓ２０を終了し、処理を収集理Ｓ１０に進める。
【００９８】
このように、監視システム２は、状態変化（異常状態）を判別するためのルールを（システム管理者などに）事前に登録される必要がなく、システムに状態変化が発生しているがトラップできない、いわゆるサイレント状態においても、状態変化を検知することができる。
【００９９】
さらに、監視システム２は、監視対象システム１の状態変化を検知した時に、当該状態変化の原因と推定されるメトリクスと、当該原因のメトリクスが影響を与えたと推定できるメトリクスとを出力する。それらの情報を参考にする事で、システム管理者によるトラブルシューティングが容易になる。
【実施例２】
【０１００】
実施例２は、監視システム２が、監視対象システム１が出力するメトリクス情報（性能統計情報）とイベント情報（シスログ）を用いて、監視対象システム１の状態変化を検出し、当該状態変化によるシステムへの影響範囲とその発生確率を予想する処理に関するものである。
【０１０１】
前提となる監視システムの構成および動作は、実施例１と同様である。
【０１０２】
以下、図５および図７から図９を用いて、実施例２における、分析装置２０の各処理の手順の詳細を示す。
（収集部の処理フロー）
図５は、本実施例における、収集処理Ｓ１０の処理手順を示すフローチャートである。図５のフローチャートに基づく動作を以下に示す。
【０１０３】
収集処理Ｓ１０は、イベント情報収集ステップ（ステップＳ１０２）と、メトリクス情報収集ステップと（ステップＳ１０１）を含んでいる。
収集処理Ｓ１０の詳細を以下に示す。
【０１０４】
収集部２００は、監視対象システム１が出力したイベント情報１０２を収集する（ステップＳ１０２１）。
【０１０５】
例えば、収集部２００は、専用のエージェントプログラムを用いて、装置１０からイベント情報１０２を収集する。管理サーバ２９がエージェントプログラムを用いて収集したイベント情報１０２を、定期的に収集しても良い。
【０１０６】
イベント情報１０２は、少なくとも、イベント情報１０２を出力した日時情報（タイムスタンプ）と、イベント情報１０２を出力した装置１０の識別情報（装置識別情報）と、イベント情報１０２の識別情報（イベント識別情報）と、イベント内容情報と、を含む。
【０１０７】
イベント情報１０２は、一般的にはテキスト形式で出力されるが、バイナリ形式で出力されていても良い。
【０１０８】
日時情報は、『23/Jan/2016 12:10:00』や『2016-01-23T12:10:00』のように、年月日と時刻を含む情報である。年や秒など、一部の情報は省略されていても良い。
【０１０９】
装置識別情報１０２１１は、『装置Ａ』など、装置名や号機を含み、装置を一意に特定できる情報である。
【０１１０】
イベント識別情報１０２１２は、『12345E』など、イベントを一意に特定できる情報である。当該識別情報が省略されている場合は、イベントの内容情報の文言の一部を識別情報に利用しても良い。
【０１１１】
イベント内容情報は、装置１０で発生した様々な事象の内容がメッセージとして表現されているものである。
【０１１２】
収集した当該イベント情報１０２に、少なくとも１つのイベントが検出できればステップＳ１０２３に進み、存在していなければステップＳ１０１１に進む（ステップＳ１０２２）。
【０１１３】
収集部２００は、処理を影響分析処理Ｓ５０に進める（ステップＳ１０２３）。
【０１１４】
ステップＳ１０１１からＳ１０１３は、実施例１と同様である。
（状態分析部の処理フロー）
本実施例における状態分析処理Ｓ２０の処理手順は、実施例１と同様である。
（事象分析部の処理フロー）
図７は、本実施例における、事象分析処理Ｓ３０の処理手順を示すフローチャートである。図７のフローチャートに基づく動作を以下に示す。
【０１１５】
事象分析処理Ｓ３０は、関連度評価ステップ（ステップＳ３０２）と、第二の因果関係判定ステップ（ステップＳ３０３）と、を含んでいる。事象分析処理Ｓ３０の詳細を以下に示す。
【０１１６】
収集処理Ｓ１０で、収集部２００が、監視対象システム１が出力したイベント情報１０２を検出している場合は、事象分析部２０２は、処理をステップＳ３０２１に進め、検出していない場合は、処理をステップＳ３０４に進める（ステップＳ３０１）。
【０１１７】
事象分析処理Ｓ３０は、当該検出したイベント情報１０２のうち、状態変化との関係の強さが大きいイベント情報１０２に絞り込む（ステップＳ３０２１）。
【０１１８】
例えば、事象分析部２０２は、当該検出したイベント情報１０２のうち、状態分析処理Ｓ２０のステップＳ２０３１で得られた状態変化の発生箇所の情報と、ステップＳ２０１３で記憶した状態変化の日時情報（タイムスタンプ）とを用いて、同じ装置１０でかつ発生日時が近い（予め定めた所定時間以内。例えば５分以内）イベント情報１０２を、状態変化との関係の強さが大きいイベント情報１０２と評価する。
【０１１９】
事象分析部２０２は、状態変化との関係の強さが大きいイベント情報１０２のそれぞれと、状態変化の関連度を、関連度テーブル２１０より評価する（ステップＳ３０２２）。
【０１２０】
例えば、事象分析部２０２は、当該イベント情報１０２の装置識別情報１０２１１とイベント識別情報１０２１２を検索条件として関連度テーブル２１０を検索し、一致したエントリのデータを取得する。
一致したエントリの、状態変化回数フィールド２１０３に記憶された状態変化回数２１１２の、検出回数フィールド２１０２に記憶された検出回数２１１１に対する割合として、関連度を算出する。
【０１２１】
例えば、検出回数２１１１が「１４」で、状態変化回数２１１２が「１３」であれば、関連度は「約０．９３」として算出される。
【０１２２】
本実施例では、事象分析部２０２は、ステップＳ３０２３の処理をスキップする。
【０１２３】
事象分析部２０２は、状態変化との関係の強さが大きいイベント情報１０２のうち、関連度が最も高いイベントを、第二の原因情報２２１１とする（ステップＳ３０３１）。
【０１２４】
事象分析部２０２は、状態変化との関係の強さが大きいイベント情報１０２のうち、第二の原因情報以外のイベント情報１０２を、第二の結果情報２２１３とし、事象分析処理Ｓ３０を終了する（ステップＳ３０３２）。
【０１２５】
事象分析部２０２は、処理を収集処理Ｓ１０に戻す（ステップＳ３０４）。
（登録部の処理フロー）
図８は、本実施例における、登録処理Ｓ４０の処理手順を示すフローチャートである。図８のフローチャートに基づく動作を以下に示す。
【０１２６】
登録部２０３は、収集処理Ｓ１０で収集部２００が検出したイベント情報１０２のそれぞれについて、装置識別情報１０２１１、およびイベント識別情報１０２１２を抽出する（ステップＳ４０１）。
【０１２７】
登録部２０３は、抽出した装置識別情報１０２１１およびイベント識別情報１０２１２を検索条件として、関連度テーブル２１０を検索する（ステップＳ４０２）。
【０１２８】
登録部２０３は、条件に一致するエントリがある場合はステップＳ４０５に進み、一致するエントリがない場合はステップＳ４０４に進む（ステップＳ４０３）。
【０１２９】
登録部２０３は、関連度テーブル２１０にエントリを新規に作成し、検出したイベント情報１０２について、装置識別情報１０２１１を装置識別情報フィールド２１００に、イベント識別情報１０２１２をイベント識別情報フィールド２１０１に、値の「０」を検出回数フィールド２１０２に、値の「０」を状態変化回数フィールド２１０３に記憶する（ステップＳ４０４）。
【０１３０】
登録部２０３は、条件に一致するエントリの検出回数フィールド２１０２に記憶された検出回数２１１１をカウントアップする（ステップＳ４０５）。
【０１３１】
ステップＳ３０２１で、検出したイベント情報１０２が状態変化との関係の強さが大きいと評価されている場合は、登録部２０３は、処理をステップＳ４０７に進め、評価されていない場合は、処理をステップＳ４０８に進める（ステップＳ４０６）。
【０１３２】
登録部２０３は、当該エントリの状態変化回数フィールド２１０３の状態変化回数２１１２をカウントアップする（ステップＳ４０７）。
【０１３３】
ステップＳ３０３１で第二の原因情報２２１１がある場合は、登録部２０３は、処理をステップＳ４０９に進め、ない場合は登録処理Ｓ４０を終了する（ステップＳ４０８）。
【０１３４】
登録部２０３は、第二の原因情報２２１１における装置識別情報１０２１１およびイベント識別情報１０２１２と、第二の結果情報２２１３を検索条件として、因果関係テーブル２２０を検索する（ステップＳ４０９）。
【０１３５】
条件に一致するエントリがある場合は、登録部２０３は、処理をステップＳ４１２に進め、エントリがない場合はステップＳ４１１に進める（ステップＳ４１０）。
【０１３６】
登録部２０３は、因果関係テーブル２２０にエントリを新規に作成し、第二の原因情報２２１１となっているイベント情報１０２について、装置識別情報１０２１１を装置識別情報フィールド２２００に、イベント識別情報１０２１２をイベント識別情報フィールド２２０１に、第二の結果情報２２１３の全てを結果情報フィールド２２０２に、値の「０」を状態変化回数フィールド２２０３に記憶する（ステップＳ４１１）。
【０１３７】
登録部２０３は、当該エントリの状態変化回数フィールド２２０３の状態変化回数２２２１をカウントアップする（ステップＳ４１２）。
（影響分析部の処理フロー）
図９は、本実施例における、影響分析処理Ｓ５０の処理手順を示すフローチャートである。図９のフローチャートに基づく動作を以下に示す。
【０１３８】
影響分析部２０４は、ステップＳ１０２２で検出したイベント情報１０２のそれぞれについて、装置識別情報１０２１１およびイベント識別情報１０２１２を検索条件として、関連度テーブル２１０を検索する（ステップＳ５０１）。
【０１３９】
条件に一致するエントリがある場合は、影響分析部２０４は、処理をステップＳ５０３に進め、ない場合はステップＳ５０９に進める（ステップＳ５０２）。
【０１４０】
影響分析部２０４は、該当するエントリの検出回数フィールド２１０２の検出回数２１１１を取得する（ステップＳ５０３）。
【０１４１】
影響分析部２０４は、検出したイベント情報のそれぞれについて、装置識別情報１０２１１およびイベント識別情報１０２１２を抽出する（ステップＳ５０４）。
【０１４２】
影響分析部２０４は、当該装置識別情報１０２１１および当該イベント識別情報１０２１２を検索条件として、因果関係テーブル２２０を検索する（ステップＳ５０５）。
【０１４３】
条件に一致する情報がある場合は、影響分析部２０４は、処理をステップＳ５０７に進め、ない場合はステップＳ５０９に進める（ステップＳ５０６）。
【０１４４】
影響分析部２０４は、該当する全エントリの、結果情報フィールド２２０２の結果情報２２１３、および状態変化回数フィールド２２０３の状態変化回数２２２１を取得する（ステップＳ５０７）。
【０１４５】
影響分析部２０４は、検出回数２１１１と状態変化回数２２２１から、各結果情報に対する発生確率を算出する（ステップＳ５０８）。
【０１４６】
例えば、状態変化回数２２２１の、検出回数２１１１対する割合を、当該発生確率とする。
【０１４７】
例えば、検出回数２１１１が「１４」で、状態変化回数２２２１が「１２」であれば、当該結果情報の発生確率は「約０．８６」として算出される。
【０１４８】
影響分析部２０４は、各結果情報及び発生確率を、管理サーバ２９の管理画面に出力する（ステップＳ５０９）。
【０１４９】
このように、監視システム２は、検知した状態変化による、監視対象システム１への影響範囲およびその発生予想確率を出力することで、システムの運用者が、システムにどのような影響が生じるかを事前に把握できるようになり、その内容に応じて異常対応の優先度を判断することができる。
【実施例３】
【０１５０】
実施例３は、監視システム２が、監視対象システム１が出力するメトリクス情報と２種類のイベント情報（シスログと操作ログ）とを用いて、監視対象システム１の状態変化を検出し、当該状態変化によるシステムへの影響範囲とその発生確率を予想する処理に関するものである。
【０１５１】
前提となる監視システムの構成および動作は、実施例１および実施例２と同様である。
【０１５２】
以下、図７を用いて、実施例３における、分析装置２０の各処理の手順の詳細を示す。
（事象分析部の処理フロー）
図７は、本実施例における、事象分析処理Ｓ３０の処理手順を示すフローチャートである。図７のフローチャートに基づく動作を以下に示す。
【０１５３】
ステップＳ３０１、Ｓ３０４、Ｓ３０２１、Ｓ３０２２、Ｓ３０３１、Ｓ３０３２の処理については、実施例２と同様である。
【０１５４】
事象分析部２０２は、ステップＳ３０２２の後に、処理をステップＳ３０２３に進める。
【０１５５】
事象分析部２０２は、イベント情報が複数種類ある場合は、それぞれについて関連度評価ステップＳ３０２を行う（ステップＳ３０２３）。
【０１５６】
例えば、監視対象システム１が、イベント情報１０２として、シスログと操作ログの２種類を出力する場合は、事象分析部２０２は、シスログと操作ログのそれぞれについて、関連度評価ステップＳ３０２を行う。
【０１５７】
関連度評価ステップＳ３０２が完了後は、事象分析部２０２は、処理をステップＳ３０３１に進める。
【０１５８】
このように、監視システム２は、監視対象システム１が、シスログと操作ログのように、異なる種類のイベント情報１０２を複数出力する場合でも統一的に分析を行うことができる。
【０１５９】
よって、実施例２と同様に、検知した状態変化による、監視対象システム１への影響範囲およびその発生予想確率を出力することで、システムの運用者が、システムにどのような影響が生じるかを事前に把握できるようになり、その内容に応じて異常対応の優先度を判断することができる。
【符号の説明】
【０１６０】
１：監視対象システム、２：監視システム、１０：装置、２０：分析部、２１：関連度記憶部、２２：影響度記憶部、２９：管理サーバ、９０：ネットワーク、１０１：メトリクス情報、１０２：イベント情報、２００：収集部、２０１：状態分析部、２０２：事象分析部、２０３：登録部、２０４：影響分析部、２１０：関連度テーブル、２２０：因果関係テーブル
【図１】
2017224181.tif 000003
【図２】
2017224181.tif 000004
【図３】
2017224181.tif 000005
【図４】
2017224181.tif 000006
【図５】
2017224181.tif 000007
【図６】
2017224181.tif 000008
【図７】
2017224181.tif 000009
【図８】
2017224181.tif 000010
【図９】
2017224181.tif 000011
【図１０】
2017224181.tif 000012