JP2019009726A - 障害切り分け方法および管理サーバ - Google Patents

Abstract

【課題】リソースの消費を抑制しつつネットワーク中の障害原因や箇所を精度よく特定する。【解決手段】監視対象に対して、可能性のある障害を根本原因イベントとして抽出する。監視対象から通知される障害イベントを収集し、収集した障害イベントを障害原因分析ルールに当てはめ、根本原因イベントとその確信度と未通知の障害イベントを特定する第一のステップ、特定した未通知イベントが所定の要件を満たし分析が完了したかどうかを判定する第二のステップ、分析が完了していない場合、監視対象に対して所定の追加アクションを行い、追加アクションの結果である追加の障害イベントを収集し、当該追加の障害イベントを障害原因分析ルールに当てはめて、根本原因イベントを確信度とともに絞り込む第三のステップを備える。第三のステップを第一のステップとして、第二のステップに回帰させ、絞込みが完了するまで処理を継続する。【選択図】図１

Description

本発明は、ネットワークシステム等において発生する障害を特定する技術に関する。

ネットワークシステムにおいて発生する障害を特定する場合、ルールに基づき、障害原因分析を行う技術（Root Cause Analysis : ＲＣＡ)が知られている。例えば、特許文献１には、監視対象に対して所定のアクションを行い、アクションの結果である障害イベントを収集し、障害イベントを障害原因分析ルールに当てはめて、根本原因イベントを確信度とともに絞り込み、絞り込まれた根本原因イベントおよび確信度が、所定の要件を満たし絞り込みが完了したかどうかを判定し、絞り込みが完了していない場合、監視対象に対して所定の追加のアクションを行い、追加のアクションの結果である追加の障害イベントを収集し、当該追加の障害イベントを障害原因分析ルールに当てはめて、根本原因イベントを確信度とともに絞り込むステップを絞り込みが完了するまで継続する技術が記載される。

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

ネットワークシステムにおいて発生した障害の原因を特定する場合、ＲＣＡではネットワークシステムの運用管理を行う管理サーバが、監視対象から異常が発生していることを示す「イベント」を取得し、取得したイベントを所定のルールに当てはめて、障害の原因や個所を推定する。ここでイベントは所定の現象や事象全般を指すが、エラー信号のような具体的な信号の形をとる場合も有る。

ＲＣＡでは、監視対象から通知されたイベントを条件として障害原因を切り分けるため、障害発生時に通常であれば管理サーバに通知されるべき監視対象の異常警報等の情報が、装置の不具合等何らかの原因により通知されなかった場合、正しい障害原因の推定が困難である。

また、特定したい障害原因に対して推定条件となるべき監視対象の異常情報等が、イベントとして定義されていない場合も、ルール化することができないため障害原因の特定が困難となる。イベントとして定義されていない異常情報は、例えば管理サーバが一定周期ごとにネットワーク中の特定の対象に対して操作を行い（この操作を「アクション」という）、アクションに対応して生じる事象を「イベント」として定義し、ルール化する方法が考えられる。

しかし、アクションはネットワーク資源を利用して、特定対象に操作を行うものであり、ネットワーク中の全ての監視対象に対して多種多様な異常の有無を確認するためにアクションを行うことは、トラフィックを圧迫し、リソースを大量に消費することになる。

一方で限定された監視対象、異常のみを対象にアクションを行えば、トラフィックは圧迫しないが、精度の高い障害原因の特定は困難である。

本発明は以上の点を鑑み、ネットワークシステムの障害時にイベントが正しく通知されなかった場合、またはイベントとして定義されていない装置異常を条件とした障害原因分析を行う必要がある場合にも、リソースの消費を抑制しつつ障害原因や箇所を精度よく特定することを目的とする。

本発明の一側面は、入力装置、出力装置、処理装置、および記憶装置を用い、記憶装置に格納された複数の障害原因分析ルールに基づいて、監視対象に対して可能性のある障害を抽出する障害切り分け方法である。障害原因分析ルールの其々は、障害を示す根本原因イベントと、障害に関連するイベントである条件イベントを対応付けたデータである。この方法では、入力装置により、監視対象から通知されるイベントである通知イベントを収集する、通知イベント収集ステップと、処理装置により、通知イベントと障害原因分析ルールに基づいて、根本原因イベントとその確信度を特定する、障害原因分析ステップと、処理装置により、通知イベントと障害原因分析ルールに基づいて、通知されていないイベントを未通知イベントとして特定する、未通知イベント特定ステップと、出力装置により、未通知イベントに対応して、監視対象に対して所定の動作を指示する追加アクションを実行する、追加アクション実行ステップと、を備える。

本発明の他の一側面は、入力装置、出力装置、処理装置、および記憶装置を用い、記憶装置に格納された複数の障害原因分析ルールに基づいて、監視対象に対して可能性のある障害を抽出する障害切り分け方法である。障害原因分析ルールの其々は、障害を示す根本原因イベントと、障害に関連するイベントである条件イベントを対応付けたデータである。この方法では、入力装置により、監視対象から通知されるイベントである通知イベントを収集する、通知イベント収集ステップと、処理装置により、通知イベントと障害原因分析ルールに基づいて、根本原因イベントとその確信度を特定する障害原因分析ステップと、処理装置により、特定した根本原因イベントと確信度に基づいて、監視対象に対して所定の追加アクションを指示し、監視対象のシステムログを収集する追加アクション実行ステップと、収集したシステムログを解析し、監視対象から通知された通知イベント以外のイベントの発生有無を判定するシステムログ解析ステップと、を備える。

本発明の他の一側面は、監視対象に対して可能性のある障害を抽出する管理サーバである。このサーバは、障害を示す根本原因イベントと、障害に関連するイベントである条件イベントを対応付けたデータである障害原因分析ルールを格納する記憶装置と、監視対象から障害と関連するイベントを、通知イベントとして収集する障害監視部と、通知イベントと障害原因分析ルールに基づいて、根本原因イベントを特定する障害原因分析部と、通知イベントと障害原因分析ルールに基づいて、通知イベントに無く条件イベントにあるイベントを、未通知イベントとして特定する未通知イベント管理部と、特定した未通知イベントに基づいて、監視対象に対して所定の動作を指示する追加アクションを実行する追加アクション部と、を備える。

本発明の他の一側面は、監視対象に対して可能性のある障害を抽出する管理サーバである。このサーバは、障害を示す根本原因イベントと、障害に関連するイベントである条件イベントを対応付けたデータである障害原因分析ルールを格納する記憶装置と、監視対象から障害と関連するイベントを、通知イベントとして収集する障害監視部と、通知イベントと障害原因分析ルールに基づいて、根本原因イベントとその確信度を特定する障害原因分析部と、特定した根本原因イベントとその確信度に基づいて、監視対象に対してシステムログの収集を指示する追加アクション部と、を備える。

本発明によれば、リソースの消費を抑制しつつネットワーク中の障害原因や箇所を精度よく特定することが可能となる。上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

実施例１の全体フローの概要を示す流れ図。 実施例１の全体システムの概要を示すブロック図。 実施例１および実施例２の具体的な適用例を説明するブロック図。 実施例１および実施例２のトランシーバ故障について障害原因分析ルールを示す表図。 実施例１の通信装置故障について障害原因分析ルールを示す表図。 実施例１の通知イベント一覧を示す表図。 実施例１および実施例２の根本原因イベント一覧を示す表図。 実施例１の発生イベント一覧を示す表図。 実施例１の発生イベント一覧を示す表図（つづき）。 実施例１の未通知イベント管理テーブルを示す表図。 実施例１の未通知イベント管理テーブルを示す表図（つづき）。 実施例１の追加アクション判定シナリオを示す表図。 実施例１の追加アクション実行シナリオを示す表図。 実施例１の分析結果管理テーブルを示す表図。 実施例１の分析結果管理テーブルを示す表図（つづき）。 実施例１および実施例２のコンポーネント管理テーブルを示す表図。 実施例１の障害原因分析の流れを示す流れ図。 実施例２の全体フローの概要を示す流れ図。 実施例２の全体システムの概要を示すブロック図。 実施例２の通信装置故障について障害原因分析ルールを示す表図。 実施例２の通知イベント一覧を示す表図。 実施例２の発生イベント一覧を示す表図。 実施例２の発生イベント一覧を示す表図（つづき）。 実施例２の追加アクション判定シナリオを示す表図。 実施例２の追加アクション実行シナリオを示す表図。 実施例２のログ解析シナリオを示す表図。 実施例２の分析結果管理テーブルを示す表図。 実施例２の分析結果管理テーブルを示す表図（つづき）。 実施例２の追加アクション管理テーブルを示す表図。 実施例２の障害原因分析の流れを示す流れ図。

実施の形態について、図面を用いて詳細に説明する。ただし、本発明は以下に示す実施の形態の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。

以下に説明する発明の構成において、同一部分又は同様な機能を有する部分には同一の符号を異なる図面間で共通して用い、重複する説明は省略することがある。

本明細書等における「第１」、「第２」、「第３」などの表記は、構成要素を識別するために付するものであり、必ずしも、数または順序を限定するものではない。また、構成要素の識別のための番号は文脈毎に用いられ、一つの文脈で用いた番号が、他の文脈で必ずしも同一の構成を示すとは限らない。また、ある番号で識別された構成要素が、他の番号で識別された構成要素の機能を兼ねることを妨げるものではない。

図面等において示す各構成の位置、大きさ、形状、範囲などは、発明の理解を容易にするため、実際の位置、大きさ、形状、範囲などを表していない場合がある。このため、本発明は、必ずしも、図面等に開示された位置、大きさ、形状、範囲などに限定されない。

以下の実施例では、監視対象に対して、可能性のある障害を根本原因イベントとして抽出する障害切り分け手法を開示している。この手法では監視対象から通知される障害イベントを収集し、収集した障害イベントを障害原因分析ルールに当てはめ、根本原因イベントとその確信度と未通知の障害イベントを特定する第一のステップ、第一のステップの結果、特定した未通知イベントが所定の要件を満たし分析が完了したかどうかを判定する第二のステップ、第二のステップの結果、分析が完了していない場合、監視対象に対して所定の追加アクションを行い、追加アクションの結果である追加の障害イベントを収集し、当該追加の障害イベントを前記障害原因分析ルールに当てはめて、根本原因イベントを確信度とともに絞り込む第三のステップを備え、第三のステップを第一のステップとして、第二のステップに回帰させ、前記絞込みが完了するまで処理を継続する。

サーバなどを含むコンピュータ、スイッチ等のネットワーク装置、およびストレージ装置等から構成されるネットワークシステムでは、通常、障害の発生時に装置の異常を示す情報が管理サーバへ通知される。このような障害管理方法を実現する具体的な例としては、ネットワークシステムを監視し、管理するためのプロトコルの一つであるＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｗｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）を利用したものが知られている。ＳＮＭＰを利用した監視システムでは、障害発生時に監視対象となる機器に常駐するＳＮＭＰエージェントから管理サーバのＳＮＭＰマネージャへ装置状態が変化したことを通知することで監視対象の障害情報を一元的に管理可能である。

また、このようなネットワークシステムで多数の障害が発生した場合、障害の根本原因を特定する手段として、障害原因分析ルールに基づき、根本原因の特定を行う技術であるＲＣＡが知られている。ＲＣＡを利用する障害原因分析システムではＳＮＭＰなどにより障害発生を示すイベントを検知すると、そのイベントの組み合わせから障害を解析して原因を特定可能である。さらに、障害原因分析システムは特定した根本原因の信頼度を表す指標である確信度を算出する。確信度は原因特定に使用した分析ルールに登録された条件イベントの個数と、発生した条件イベントの割合として算出される。例えば、５つの条件イベントから障害原因を特定する分析ルールにおいて、３つの条件イベントが発生し、障害原因分析を行ったのであれば確信度は３／５と算出される。

しかし監視対象装置のＳＮＭＰプロトコルエラーや、監視対象と管理サーバ間の通信障害が発生した場合、監視対象から管理サーバへのイベント通知が正しく行われない可能性がある。この場合障害原因分析システムでは解析に必要な条件イベントを十分に収集することができず、誤った確信度を算出してしまうため、高精度の障害原因解析を行うことが困難となる。

以下で詳しく述べるように、本実施例では、障害原因分析時に使用した分析ルールに登録された条件イベントのうち、通知されなかったイベントを未通知イベントと定義し、未通知イベントの発生有無を判定するようなアクションを監視対象に対し行うことで、リソースの消費を抑制しつつ障害原因分析システムの分析精度を向上させる効果をもつ。

＜１−１．全体フロー＞
図１は本実施例の全体フローの概要を示す流れ図である。フロー中に記載される各処理部は障害原因分析システムが備える機能部であり、システム構成は後に図２で説明するが、システムと動作の対応の理解のために、図1の説明でも図２以降の参照符号をあわせて記載することがある。

まず分析を開始する（Ｓ１０１）。これは監視対象２０１から管理サーバ２００へのイベント通知を契機としてもよいし、オペレータの指示、または所定時刻に自動的に行ってもよい。

次に障害原因分析部２０９は通知されたイベントと障害原因分析ルール２１６に基づき障害原因分析を行い、障害の根本原因（の候補）イベントを絞り込む（Ｓ１０２）。

そして、障害原因分析部２０９は、絞り込んだ全ての根本原因イベントについて、障害の根本原因の絞込みに用いた障害原因分析ルール２１６のＩＦ部４０２に記載される条件イベントのうち、通知されたイベント以外の条件イベントを、未通知イベントとして絞り込む（Ｓ１０３）。

その後、分析完了判定部２０３は、絞り込んだ全ての未通知イベントに対して追加アクションを実施したかどうか判定する（Ｓ１０４）。追加アクションは絞り込んだ未通知イベントに応じて、管理サーバ２００または外部の装置から監視対象２０１に対して行われるものである。そして絞りこんだ全ての未通知イベントに対して、追加アクションを実施済みであれば分析完了し（Ｓ１０８）、追加アクションを未実施の未通知イベントがある場合は、Ｓ１０５の処理に進む。

Ｓ１０５では追加アクション判定部２０４が、追加アクション判定シナリオ２１１から未通知イベントに対応する追加アクションを決定する。追加アクション判定シナリオは未通知イベントと追加アクションの組み合わせを示す表であり、詳細は図９で説明する。そして追加アクション実行部２０５は追加アクション実行シナリオを参照し、未通知イベントに対応して決定した追加アクションを実行する（Ｓ１０６）。

次に分析完了判定部２０３は、追加アクションの結果、いままで通知されていなかった未通知イベントが、監視対象装置で発生していることが確認できたかどうか判定する（Ｓ１０７）。未通知イベントの発生を確認できなかった場合、分析完了となり（Ｓ１０８）、未通知イベントの発生を確認した場合はＳ１０２へと戻り、分析完了となるまで同様の処理を続行する。

＜１−２．全体システム＞
図２は実施例１における全体システムの概要を示すブロック図である。本実施例では、管理サーバ２００を用いて障害原因分析を実行する。監視対象２０１は、例えばネットワークシステムその他のシステムのコンポーネント（要素）である。監視対象２０１は物理的なものでも仮想的なものでもよい。また粒度も、装置単位（例えばサーバ装置）、装置に実装されるボード単位、ボード内の回路単位等任意である。

管理サーバは、通常のサーバ同様に、入力装置、出力装置、処理装置（ＣＰＵ）、記憶装置等の要素を有する。管理サーバは障害分析結果出力部２０２、分析完了判定部２０３、追加アクション判定部２０４、追加アクション実行部２０５、未通知イベント管理部２０６、障害多段分析管理部２０７、障害監視部２０８、障害分析部２０９、障害詳細情報収集部２１０を備える。障害監視部２０８は図示しない管理サーバの入力装置および出力装置を介して、監視対象２０１と通信可能である。

これらの部分は、記憶装置に格納されたプログラムが処理装置によって実行されることで、定められた処理を他のハードウェアと協働して行うことができる。本明細書では計算機などが実行するプログラムまたはその機能を実現する手段を、「機能」、「手段」、「部」、「モジュール」等と呼ぶ場合がある。また、処理装置は、厳密には演算装置と制御装置を含み、記憶装置のデータを用いてプログラムを処理するが、処理を実行する主語を制御装置として説明する場合がある。

また、管理サーバは追加アクション判定シナリオ２１１、追加アクション実行シナリオ２１２、未通知イベント管理テーブル２１３、コンポーネント管理テーブル２１４、分析結果管理テーブル２１５、障害原因分析ルール２１６、障害詳細情報２１７の情報を利用可能である。これらの情報は、記憶装置、例えば磁気記憶装置に格納しておく。

以後の説明では「〜テーブル」、「〜リスト」、「〜ＤＢ（Ｄａｔａｂａｓｅ）」、「〜キュー」「表」等の表現にて本実施例で使用する情報を説明する場合があるが、これら情報はテーブル、リスト、ＤＢ、キュー、等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「〜テーブル」、「〜リスト」、「〜ＤＢ」、「〜キュー」等について「〜情報」、「〜データ」と呼ぶことがある。また、実施例で例示される上記テーブル類は、必ずしも１つのファイルである必要はなく、識別子で関連付けされた複数のテーブルでもよい。あるいは、複数のテーブルが合体した1つのテーブルでもよい。

また、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ（ＩＤｅｎｔｉｆｉｃａｔｉｏｎ）」という表現を用いるが、これらについてはお互いに置換が可能である。

また、以後の説明では「プログラム」を主語として説明を行う場合があるが、プログラムはプロセッサによって実行されることで定められた処理をメモリ及び通信ポート（通信制御デバイス）を用いながら行うため、プロセッサを主語とした説明とする場合がある。また、プログラムを主語として開示された処理は管理サーバ等の計算機、情報処理装置が行う処理としてもよい。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。

また、各種プログラムは、プログラム配布サーバや、計算機が読み取り可能な記憶メディアによって各計算機にインストールされてもよい。この場合、プログラム配布サーバは、プロセッサと記憶資源を含み、記憶資源はさらに配布プログラムと配布対象であるプログラムを記憶する。そして、配布プログラムをプロセッサが実行することで、プログラム配布サーバのプロセッサは、配布対象のプログラムを他の計算機に配布する。

また、入力装置や出力装置の例としてはディスプレイとキーボードとポインタデバイスが考えられるが、これ以外のデバイスであってもよい。また、入出力デバイスの代替としてシリアルインタフェースやイーサーネットインタフェースを入出力デバイスとし、当該インタフェースにディスプレイ又はキーボード又はポインタデバイスを有する表示用計算機を接続し、表示用情報を表示用計算機に送信したり、入力用情報を表示用計算機から受信することで、表示用計算機で表示を行ったり、入力を受け付けることで入出力デバイスでの入力及び表示を代替してもよい。

＜１−３．適用ネットワーク構成＞
図３は、本実施例の具体的な監視対象の例を説明するブロック図である。図３では適用例として通信装置３０１〜３０３、通信路３０９〜３１１から構成されるネットワークシステムを想定する。本例のネットワークシステムとは複数の通信装置、通信路からなるシステムである。また、通信装置とは他の装置とデータ交換をするためのデータ送受信機能を有するものであり、例えばクラウドサービス提供を目的にデータセンターに設置されるサーバであってもよいし、通信サービス提供を目的に通信施設に設置されるルータであってもよい。

さらに、通信路とは装置同士がデータ交換を行うための通信媒体であり、本実施例において通信路３０９〜３１１は例えば、１０ギガビット・イーサネット（登録商標、以下同じ）の光ファイバを使用するが、いかなる帯域および規格の通信路を用いてもよい。

通信装置３０１〜３０３はトランシーバ３０５を備え、また、トランシーバ３０５は受信部３０７、送信部３０８を備える。通信装置３０１〜３０３は他装置からのデータを受信部３０７で終端し、他装置へのデータを送信部３０８から発信する。

本実施例の障害切り分け方法および管理サーバでは、これらの構成と通信が可能であり、発生するイベントの情報を収集する。ただし、イベントの収集は通信路３０９〜３１１の輻輳や障害等により阻害される場合がある。また、各通信装置３０１〜３０３の不具合や電源遮断等で阻害されることがあり得る。

＜１−４．分析ルール＞
図４Ａ、図４Ｂは障害原因分析ルール２１６の例を示す表図である。図３のネットワークシステム構成例においては、通信障害を検討する場合に、コンポーネントとしてトランシーバ３０６の故障と、通信装置３０１〜３０３の故障を想定し、これらの故障を根本原因イベントと定義している。

障害原因分析ルール２１６は複数のルール４０１から構成され、各ルール４０１はＩＦ部４０２およびＴＨＥＮ部４０３を備える。ＴＨＥＮ部には分析によって推定される根本原因イベントが記載され、ＩＦ部にはＴＨＥＮ部に記載される根本原因イベントを推定するためのイベントである条件イベントが定義される。監視対象２０１で生じるイベントは、監視対象２０１から管理サーバ２００へ通知イベントとして通知される。

図４Ａはトランシーバ３０６の故障を推定するためのルール、また図４Ｂは通信装置３０１〜３０３を特定するためのルールである。

＜１−５：イベント一覧表＞
図５は監視対象２０１が異常を検知した際に管理サーバ２００へ通知する可能性のあるイベント一覧表５００の例を示す表図である。イベント一覧表５００は、イベント番号５０１、イベント名５０２、イベント内容５０３を含む。また、イベント一覧表５００は障害詳細情報２１７に含まれ、障害詳細情報収集部２１０は障害監視部２０８が監視対象２０１から収集した通知イベントのイベント番号５０１をキーとして、イベント一覧表５００を検索することで発生したイベントの詳細を特定可能である。

＜１−６．根本原因イベント一覧表＞
図６は本実施例において想定する根本原因イベント一覧表６００の例を示す表図である。根本原因イベント一覧表６００は根本原因イベント番号６０１、根本原因イベント名６０２、根本原因イベント内容６０３を含む。

＜１−７．発生イベント一覧表＞
図７Ａ，図７Ｂは本実施例において発生するイベント一覧の例を示す発生イベント一覧表７００を示す表図である。発生イベント一覧表７００は、発生イベント番号７０１、通知イベントのイベント番号７０２、イベント名７０３を含む。また、発生イベント一覧表７００は障害詳細情報２１７に含まれ、監視対象２０１から管理サーバ２００へ通知された通知イベントの、イベント番号やイベント名が記載される。障害分析部２０９は発生イベント一覧表７００および障害原因分析ルール２１６を参照することで障害分析を行い、根本原因イベントを特定する。

＜１−８．未通知イベント管理テーブル＞
図８Ａ，図８Ｂは本実施例において特定する未通知イベント一覧の例および特定した未通知イベントを管理するための未通知イベント管理テーブル２１３の例を示す表図である。

未通知イベント管理テーブル２１３は、未通知イベント番号８０１、イベント番号８０２、イベント名８０３、実施フラグ８０４、結果フラグ８０５を含む。

未通知イベント管理部２０６は障害原因分析時に参照されたルール４０１のＩＦ部４０２に記載される条件イベントのうち、通知されなかったイベントを未通知イベントとして、未通知イベントのイベント番号を未通知イベント管理テーブル２１３に登録する。また、実施フラグ８０４、結果フラグ８０５は障害原因分析の終了判定のために障害原因分析部２０９に参照される。未通知イベントの登録、および実施フラグ８０４、結果フラグ８０５の参照の方法について、具体的な説明は後述に記載する。

＜１−９．追加アクション判定シナリオ＞
図９は本実施例における追加アクション判定シナリオ２１１の例を示す表図である。追加アクション判定シナリオ２１１はイベント番号９０１、追加アクション番号９０２、追加アクション内容９０３を含む。追加アクション判定シナリオ２１１はイベント番号に応じて実行する追加アクションの一覧が記載され、追加アクション判定部２０４は、障害原因分析部２０９による未通知イベントの特定後、追加アクション判定シナリオ２１１を参照し、未通知イベントのイベント番号９０１をキーとして、実行すべき追加アクション内容９０３を判定する。追加アクション判定の具体的な説明は後述に記載する。

＜１−１０．追加アクション実行シナリオ＞
図１０は追加アクション実行シナリオ２１２の例を示す表図である。追加アクション実行シナリオ２１２は追加アクション番号１００１、追加アクション内容１００２、実施方法例１００３を含む。また、追加アクション実行シナリオ１００３には追加アクション内容に応じた具体的な実施方法例が記載され、追加アクション実行部２０５は追加アクション実行シナリオ２１２の情報を参照し、追加アクションを実行する。

＜１−１１．分析結果管理テーブル＞
図１１Ａ，図１１Ｂは分析結果管理テーブル２１５の例を示す表図である。分析結果管理テーブル２１５は分析結果管理番号１１０１、根本原因イベント番号１１０２、根本原因イベント名１１０３、確信度１１０４を含む。

障害原因分析部２０９は障害原因分析ルール２１６より特定した根本原因イベントおよび確信度を算出し、分析結果管理テーブル２１５に登録する。障害原因分析部２０９は参照したルール４０１のうち、ＩＦ部４０２に記載される通知イベントの数を分母に、ＩＦ部４０２に記載される通知イベントのうち発生イベント一覧表にも記載される通知イベントの個数を分子として確信度１１０４を算出する。確信度１１０４の具体的な算出方法の説明は後述に記載する。

＜１−１２．コンポーネント管理テーブル＞
図１２はコンポーネント管理テーブル２１４の例を示す表図である。コンポーネント管理テーブル２１４は追加アクション実行部２０５が追加アクション実行シナリオ２１２を基に監視対象２０１に対して追加アクションを実行するために必要な情報が記載される。本実施例においては、管理サーバ２００が通信装置３０１〜３０３に対して、遠隔ログインをするために必要となるＩＰアドレスやＩＤ、パスワード等が内容１３０１、項目１３０２としてコンポーネント管理テーブル２１４に予め登録されている。

コンポーネント管理テーブル２１４は図１２のように複数のテーブルの集合であってもよいし、他の形式でもよい。また、コンポーネントの粒度は任意であり、例えば通信装置の下位にトランシーバが位置する。さらに大きな粒度としてもよいし、小さな粒度としてもよい。また、コンポーネントが物理的なものでもよいし、仮想的なものでもよい。

＜１−１３．分析シーケンス＞
図１３は本実施例で想定する障害および障害根本原因の判定実行処理の流れを示す流れ図である。図１３について具体的な例をもとに説明する。なお、障害多段分析管理部２０７は処理の全体を管理しており、各部（モジュール）の処理を順次実行しているが、以下の説明では障害多段分析管理部２０７の説明を省略することがある。

まず図３に示す本実施例のネットワーク構成において、図７Ａの発生イベント一覧表７００に記載されるイベントが発生し、監視対象２０１から管理サーバ２００へ通知イベントとしてイベント番号ＥＶ−１３、ＥＶ−１、ＥＶ−７、ＥＶ−１１、ＥＶ−８を持つイベントが通知されていることを想定する。

（Ｓ１２０１）障害原因分析部２０９は障害原因分析ルール２１６に登録された図４Ａまたは図４Ｂのルール４０１から、ＩＦ部４０２に図７Ａの発生イベント一覧表に記載される通知イベントのイベント番号ＥＶ−１３、ＥＶ−１、ＥＶ−７、ＥＶ−１１、ＥＶ−８の内少なくとも一つ以上が含まれるルール１、ルール２、ルール３、ルール４、ルール６、ルール７、ルール８を抽出する。

（Ｓ１２０２）次に抽出した各ルールのＴＨＥＮ部から、根本原因イベント番号ＣＥ−１、ＣＥ−２、ＣＥ−３、ＣＥ−４、ＣＥ−６、ＣＥ−７、ＣＥ−８を特定し確信度を算出する。確信度算出は分母にルール内のＩＦ部に記載される条件イベントの個数を、分子にＩＦ部に記載される条件イベントのうち、発生しているイベント（すなわち、通知イベント）の個数を入力することで行われる。例えば、ルール１に記載される根本原因イベント番号ＣＥ−１の確信度は、ＩＦ部のイベント数が３、ＩＦ部のイベントのうち発生しているイベント数が１（ＥＶ−１）のため、確信度は１／３と算出する。他の根本原因イベントに対しても同様に確信度を算出し、根本原因イベント番号ＣＥ−２は１／３、ＣＥ−３は１／３、ＣＥ−４は２／３、ＣＥ−６は１／３、ＣＥ−７は１／２、ＣＥ−８は１／２となる。以上の処理によって障害原因分析部２０９は、分析結果管理テーブル２１５に根本原因イベントおよびそれぞれの確信度を登録し、この時分析結果管理テーブル２１５の内容は図１１Ａと等しくなる。

（Ｓ１２０３）また、障害原因分析部２０９は、発生イベントおよび抽出したルール４０１の条件イベントから未通知イベント（すなわち、発生が検出されていない、あるいは発生が通知されていないイベント等）のイベント番号を特定する。例えば抽出したルール１については、ＩＦ部に記載される３つのイベントのうち、ＥＶ−２、ＥＶ−１４は未通知イベントのイベント番号である。他の抽出したルールについても同様に未通知イベントのイベント番号を特定し、ルール２はＥＶ−３、ＥＶ−４を、ルール３はＥＶ−５、ＥＶ−６を、ルール４はＥＶ−１５を、ルール６はＥＶ−１２、ＥＶ−１５を、ルール７はＥＶ−１４を、ルール８はＥＶ−１５を特定する。障害原因分析部２０９は特定した未通知イベントのイベント番号を未通知イベント管理部２０６へ通知する。

（Ｓ１２０４）そして、未通知イベント管理部２０６は障害原因分析部２０９から通知されたイベント番号を未通知イベント管理テーブル２１３に登録する。実施フラグ８０４には未通知イベントに対して追加アクションが実施ずみであれば１が、未実施であれば０を入力する。現段階では全ての未通知イベントに対して追加アクションは未実施であるため全て０を入力する。結果フラグ８０５は、未通知イベントに対して実施した追加アクションによって、イベントが発生していることを確認したのであれば１を、これ以外の場合には０を入力する。現段階では全ての未通知イベントに対して追加アクションは未実施であるため全て０を入力する。この時、未通知イベント管理テーブル２１３の内容は図８Ａに等しくなる。

（Ｓ１２０５）次に未通知イベント管理部２０６は，未通知イベント管理テーブル２１３に登録された未通知イベントの実施フラグ８０４が０であるレコードが一つ以上存在するか否かを判定する。未通知イベント管理テーブル２１３に登録された全ての未通知イベントの実施フラグ８０４が１である場合、Ｓ１２０６の処理に進み、分析は完了する。現段階では、実施フラグ８０４には全て０が登録されているため、未通知イベント管理部２０６は、未通知イベント管理テーブル２１３に登録されたイベントＥＶ−２、ＥＶ−３、ＥＶ−４、ＥＶ−５、ＥＶ−６、ＥＶ−１２、ＥＶ−１４、ＥＶ−１５を追加アクション判定部２０４に通知する。

（Ｓ１２０７）追加アクション判定部２０４は、未通知イベント管理部２０６から通知されたイベント番号と図９の追加アクション判定シナリオ２１１から、実行すべき追加アクション番号９０２を抽出する。未通知イベント管理部２０６からはイベント番号ＥＶ−２、ＥＶ−３、ＥＶ−４、ＥＶ−５、ＥＶ−６、ＥＶ−１２、ＥＶ−１４、ＥＶ−１５が通知されたため、追加アクション番号ＡＣ−２、ＡＣ−３、ＡＣ−４、ＡＣ−５、ＡＣ−６、ＡＣ−１２、ＡＣ−１４、ＡＣ−１５を抽出し、追加アクション実行部２０５へ通知する。

（Ｓ１２０８）追加アクション実行部２０５は追加アクション判定部２０４から通知された追加アクション番号と、図１０の追加アクション実行シナリオ２１２を参照し追加アクションを実行する。例えば、追加アクション番号ＡＣ−２の追加アクション内容は送信部１１Ｚの異常警報収集であり、具体的な実施方法としては実施方法例１００３に記載されるように、Ｔｅｌｎｅｔによる管理サーバからの遠隔操作により、トランシーバ１１送信部１１Ａの異常警報の有無を確認する。この際に追加アクション実行部２０５は、コンポーネント管理テーブル２１４を参照することで追加アクション実行に必要な情報を取得する。他の追加アクションについても同様に実行し、追加アクション実行部２０５は追加アクション結果を未通知イベント管理部２０６へ通知する。本実施例では、追加アクション番号ＡＣ−１４の追加アクションのみ、疑われる事象が発生していることを確認したことを想定する。すなわち通信装置１−通信装置３間におけるｐｉｎｇ到着が確認できなかったという結果を得たことを想定する。

（Ｓ１２０９）未通知イベント管理部２０６は、追加アクション実行部２０５から追加アクション実行結果を受け取り、未通知イベント管理テーブル２１３の実施フラグ８０４および結果フラグ８０５の内容を更新する。実施フラグ８０４には、登録済みの全ての未通知イベントに対して、追加アクションを実行済みであるため全て１を登録する。また、結果フラグ８０５には、イベント番号ＥＶ−１４にのみ疑われる事象が発生している結果を得たため１を登録する。この時、未通知イベント管理テーブル２１３の内容は図８Ｂに等しくなる。

（Ｓ１２１０）次に未通知イベント管理部２０６は、未通知イベント管理テーブル２１３に登録された未通知イベントの結果フラグ８０５が１であるレコードが一つ以上存在するか否かを判定する。未通知イベント管理テーブル２１３に登録された全ての未通知イベントの実施フラグ８０４が０である場合、Ｓ１２１１の処理に進み、分析は完了する。ここでは、図８Ｂに記載される通り、未通知イベント番号ＮＯＥ−７の結果フラグが１であるため、未通知イベント管理部２０６はイベント番号ＥＶ−１４を障害詳細情報収集部２１０に通知する。

（Ｓ１２１２）障害詳細情報収集部２１０は通知されたイベント番号ＥＶ−１４を発生イベント一覧表に登録する。この時、発生イベント一覧表は図７Ｂの内容に等しくなる。次に処理はＳ１２０１へと戻る。

（Ｓ１２０１：２回目）障害原因分析部２０９は障害原因分析ルール２１６に登録された図４Ａまたは図４Ｂのルール４０１から、ＩＦ部４０２に図７Ｂの発生イベント一覧表に記載されるイベント番号の内少なくとも一つ以上が含まれるルール４０１を抽出する。発生イベント一覧表には１回目の処理時には発生していなかったイベント番号ＥＶ−１４のイベントが発生しているため、１回目の処理時に抽出されたルール１、ルール２、ルール３、ルール４、ルール６、ルール７、ルール８に加え、ルール５およびルール９が抽出される。

（Ｓ１２０２：２回目）次に抽出した各ルールのＴＨＥＮ部から、根本原因イベント番号を特定し確信度を算出する。確信度の算出方法は１回目の処理時と同様であり、ここでは詳細な説明は省略する。障害原因分析部２０９は１回目の処理時には抽出しなかったルール５およびルール９を抽出しているため、分析結果管理テーブル２１５には根本原因イベント番号ＣＥ−５、ＣＥ−９を新たに登録する。既に登録済みの根本原因イベントについて再登録は行わず、確信度の更新のみを行う。ＣＥ−１、ＣＥ−７の確信度についてはルール１およびルール７のＩＦ部に記載されるＥＶ−１４がＳ１２１１で新たに発生イベント一覧表に追加されたため、確信度がそれぞれ２／３、２／２へと更新される。この結果、分析結果管理テーブル２１５は図１１Ｂに示す状態になる。

Ｓ１２０３〜Ｓ１２０９までの処理は１回目と同様の手順であり、詳細な説明は省略する。また、Ｓ１２０８では実行した全ての追加アクションについて疑われる事象が発生していることは確認できなかったと想定する。

（Ｓ１２１０：２回目）未通知イベント管理部２０６は未通知イベント管理テーブル２１３の全ての結果フラグ８０５に０を登録する。よって処理はＳ１２１０へ進み分析が完了する。

障害原因分析結果は障害分析結果出力部２０２によって実行されるが、結果出力のタイミングはＳ１２１０の分析完了判定を契機としても良いし、システム管理者からの要求を契機としてもよい。本実施例においてはＳ１２１０の分析完了判定時に結果を出力した場合、図１１Ｂに記載される根本原因イベントの一覧および確信度が出力される。

＜１−１４．実施例の効果＞
以上説明した実施例は、監視対象に対して、可能性のある障害を根本原因イベントとして抽出する障害切り分け方法である。この方法では、監視対象から通知される障害を示すイベントを収集するイベント収集ステップと、収集したイベントと予め定められた障害原因分析ルールに基づいて根本原因イベントと確信度を特定する障害原因分析ステップと、収集したイベントと障害原因分析ルール、また特定した根本原因イベントに基づいて監視対象の不具合により通知されなかったイベントを未通知イベントとして特定する未通知イベント特定ステップと、未通知イベントから監視対象に対して所定の動作を指示する追加アクションを実行する追加アクション実行ステップと、追加アクション実行結果に基づいて分析完了判定を行う分析完了判定ステップを備える。

本実施例では例えば通知されるべきイベントＥＶ−１４（通信路１３で通信断発生）が何らかの原因により通知されなかった場合でも、正しい障害原因の推定が可能となる。すなわち、障害発生時に通常であれば管理サーバに通知されるべき監視対象の異常警報等のイベントが、装置や通信回線の不具合等何らかの原因により通知されなかった場合でも、通知されなかった可能性のあるイベントを抽出し、これを能動的にチェックすることができ、高い信頼性で障害原因の推定が可能となる。

装置異常には様々なものがあり、ＳＮＭＰ等の監視制御のためのプロトコルで規定されない異常も数多くある。このような場合、管理サーバへ通知されない種類の装置異常を条件イベントとする分析ルールを作成することができず、障害原因特定の精度向上が困難である。管理システムへ通知する規定を持たない種類の装置異常に対しては、一般的には管理サーバから監視対象へＴｅｌｎｅｔなどによる遠隔ログインを行い、システムログを収集し分析することで装置異常の有無を確認する。

以下で詳しく述べるように本実施例ではシステムログから判別可能な装置異常を分析ルールの条件イベントとして予め定義しておくことで、リソースの消費を抑制しつつ障害原因分析システムの分析精度を向上させる効果をもつ。以下、表図中、実施例１と同じ符号をもつ処理、または機能部は実施例１と同様の処理、または機能を備えるものであり、本実施例では説明を省略することがある。

＜２−１．全体フロー＞
図１４は本実施例の概要を示す流れ図である。（Ｓ１４０１）分析開始後、障害原因分析部２０９は通知イベントと障害原因分析ルール２１６に基づき、障害原因分析を行い、根本原因イベントを絞り込んだ後（Ｓ１０２）、追加アクション判定部２０４が、根本原因イベントに対応する追加アクションを決定する。

（Ｓ１４０２）次に決定した追加アクションをすべて実施したか否かを判定する。判定の結果、全て実施したのであれば、Ｓ１０７の処理に進み、分析完了となる。

（Ｓ１４０３）追加アクション実行部２０５は、監視対象のシステムログを収集する。

（Ｓ１４０４）次にログ内容解析部２１８は、ログ解析シナリオ２１９に基づき監視対象のシステムログの内容を解析する。

（Ｓ１４０５）システムログに装置異常を示す内容が含まれている場合、処理はＳ１０２に戻り、分析が完了するまで同様の処理を継続する。装置異常を示す内容が含まれていない場合、処理はＳ１０７に進み、分析完了となる。

＜２−２．機能ブロック図＞
図１５は本実施例における全体システムの概要を示すブロック図である。管理サーバ２００−２について実施例１と同様の構成は同じ符号を付けて説明を省略する。管理サーバ２００−２はログ内容解析部２１８、ログ解析シナリオ２１９、および追加アクション管理テーブル２２０を備える。

ログ内容解析部２１８は追加アクション実行部２０５が取得した監視対象２０１のシステムログを解析し、システムログに装置異常を示す情報が含まれているか否かを判定する。ログ解析シナリオ２１９はログ内容解析部２１８が解析するために、必要となる情報を登録する。詳細については後述に記載する。また、追加アクション管理テーブル２２０は障害原因分析の結果、実行する追加アクションおよびその結果を管理するものである。

＜２−３．障害原因分析ルール＞
図１６は本実施例における障害原因分析ルール２１６−２の一例を示す表図である。障害原因分析ルール２１６−２は実施例１と同様に各ルール４０１に、ＩＦ部４０２とＴＨＥＮ部４０３を備える。図１６に記載のルール７〜９は本実施例における通信装置故障を根本原因イベントとする分析ルールであり、トランシーバ故障を根本原因イベントとするルール１〜６の内容は図４Ａと等しいのものとする。

ルール７〜９はＩＦ部４０２に何れも通信装置のＨＤＤ書き込みエラーを示すイベントを根本原因イベントの条件イベントとして定義しており、前記条件イベントは本実施例の管理システムの仕様上、監視対象２０１から管理サーバ２００に自動的な異常通知が行われないものとする。

＜２−４．イベント一覧表＞
図１７は本実施例におけるイベントの一覧である、イベント一覧表５００−２を示す。イベント一覧表５００−２は図５に記載のイベントＥＶ−１〜ＥＶ−１５に加え、監視対象２０１から管理サーバ２００へ通知はされないが、追加アクション実行の結果、障害原因分析部２０９から障害詳細情報収集部２１０へ通知される可能性のあるイベントＥＶ−１６〜ＥＶ〜１８が登録される。

＜２−５．発生イベント一覧表＞
図１８Ａ，図１８Ｂは本実施例において用いる発生イベント一覧表７００−２の表図である。基本的な構成は実施例１の図７Ａ，図７Ｂに示したものと同様であり、発生イベント一覧表７００−２が備えるフィールドは実施例１と同様のため詳細な説明は省略する。ただし、本実施例においては、イベント番号およびイベント名の項目に、監視対象２０１から管理サーバ２００へ通知はされないが追加アクション実行の結果、障害原因分析部２０９から障害詳細情報収集部２１０へ通知される可能性のある、図１７に示すイベントＥＶ−１６〜ＥＶ〜１８が登録されることがある。

イベント一覧表５００−２、発生イベント一覧表７００−２は、障害詳細情報２１７−２に含まれる。

＜２−６．追加アクション判定シナリオ＞
図１９は本実施例における追加アクション判定シナリオ２１１−２の例を示す表図である。追加アクション判定シナリオ２１１−２は根本原因イベント番号１５０１、追加アクション番号９０２、確信度条件１５０２、追加アクション内容９０３を備える。本実施例における追加アクション判定の具体例については図２４にて詳細に説明する。

＜２−７．追加アクション実行シナリオ＞
図２０は本実施例における追加アクション実行シナリオ２１２−２の例を示す表図である。追加アクション実行シナリオ２１２−２は追加アクション番号１００１、追加アクション内容１００２、実施方法例１００３を備える。本実施例における追加アクション実行の具体例については図２４にて詳細に説明する。

＜２−８．ログ解析シナリオ＞
図２１は本実施例におけるログ解析シナリオ２１９の例を示す表図である。ログ解析シナリオ２１９は追加アクション番号１６０１、解析キーワード（１）１６０２、解析キーワード（２）１６０３、結果として通知されるべきイベント番号１６０４を備える。ログ内容解析部２１８はログ解析シナリオ２１９を参照することで、監視対象１０１のシステムログを解析し、システムログに装置異常を示す情報が含まれているか否かを判定する。本実施例においてはログ解析シナリオ２１９に予め、システムログを解析するための解析キーワードを登録しておき、システムログに対しこの解析キーワードをキーとした検索を行い、検索結果を基に異常を示す情報が含まれるか否かを判定する。判定結果は、イベント番号１６０４に、例えばイベントＥＶ−１６〜ＥＶ〜１８として反映される。

＜２−９．分析結果管理テーブル＞
図２２Ａ，図２２Ｂは本実施例における分析結果管理テーブル２１５−２の例を示す表図である。基本的な構成は実施例１の図１１Ａ，図１１Ｂに示したものと同様であり、分析結果管理テーブル２１５−２が備えるフィールドは実施例１と同様のため、詳細な説明は省略する。ただし、実施例２の分析結果管理テーブル２１５−２の確信度の判定には、監視対象２０１から管理サーバ２００へ通知はされないが追加アクション実行の結果、障害原因分析部２０９から障害詳細情報収集部２１０へ通知される可能性のあるイベントＥＶ−１６〜ＥＶ〜１８の有無が反映される。

＜２−１０．追加アクション管理テーブル＞
図２３は追加アクション管理テーブル２２０の一例を示す表図である。追加アクション管理テーブル２２０は、追加アクション番号１８０１、アクション内容１８０２、実施フラグ１８０３、結果フラグ１８０４を含む。具体的な説明は後述する。

＜２−１１．分析シーケンス＞
図２４は本実施例で想定する障害および障害根本原因の判定実行処理の流れを示す流れ図である。図２４について具体的な例をもとに説明する。なお、障害多段分析管理部２０７は処理の全体を管理しており、各部（モジュール）の処理を順次実行しているが、以下の説明では障害多段分析管理部２０７の説明を省略することがある。

本実施例の具体的な適用例として、実施例１と同様図３の構成を用いる。まず図３に示すネットワーク構成において、図１８Ａの発生イベント一覧表７００−２に記載されるイベントが発生し、監視対象２０１から管理サーバ２００へイベント番号ＥＶ−１３、ＥＶ−１、ＥＶ−７、ＥＶ−１１、ＥＶ−８、ＥＶ−１４が通知されていることとする。

（Ｓ１２０１）障害原因分析部２０９は障害原因分析ルール２１６に登録された図４Ａおよび図１６のルール４０１から、ＩＦ部４０２に図１８Ａ発生イベント一覧表に記載されるイベント番号ＥＶ−１３、ＥＶ−１、ＥＶ−７、ＥＶ−１１、ＥＶ−８、ＥＶ−１４の内少なくとも一つ以上が条件イベントに含まれるルール１、ルール２、ルール３、ルール４、ルール５、ルール６、ルール７、ルール８、ルール９を抽出する。

（Ｓ１７０１）次に抽出した各ルールのＴＨＥＮ部から、根本原因イベント番号ＣＥ−１、ＣＥ−２、ＣＥ−３、ＣＥ−４、ＣＥ−５、ＣＥ−６、ＣＥ−７、ＣＥ−８、ＣＥ−９を特定し確信度を算出する。確信度算出の方法は実施例１と同様であるため、詳細な説明は省略する。障害原因分析部２０９は分析結果管理テーブル２１５-２に根本原因イベントおよびそれぞれの確信度を登録し、この時、分析結果管理テーブル２１５-２の内容は図２２Ａと等しくなる。

（Ｓ１７０２）そして、追加アクション判定部２０４は分析結果管理テーブル２１５−２および追加アクション判定シナリオ２１１−２から実行すべき追加アクション番号を抽出する。追加アクション判定シナリオ２１１−２は障害原因分析部２０９が判定した根本原因イベント番号および確信度から追加アクション内容を決定するものである。本実施例では図２２Ａ中の分析結果管理番号ＲＡ−７が、図１９中の追加アクション番号ＡＣ−１の条件を満たしているため、追加アクション判定部２０４は、ＡＣ−１を抽出し追加アクション管理テーブル２２０へ登録する。この時、追加アクション管理テーブル２２０の内容は図２３に等しい。

（Ｓ１７０３）次に追加アクション判定部２０４は、追加アクション管理テーブル２２０に登録されたレコードの内、実施フラグ１８０３が「０」であるレコードが一つ以上あるかどうか判定する。該当のレコードが一つもなければ処理はＳ１７０４に進み分析完了となる。ここでは追加アクションＡＣ−１の実施フラグ１８０３が「０」であるため、追加アクション判定部２０４は追加アクションＡＣ−１を追加アクション実行部２０５へ通知する。

（Ｓ１２０７）追加アクション実行部２０５は追加アクション番号、追加アクション実行シナリオ２１２−２に基づき追加アクションを実行する。ここでは図２０中ＡＣ−１の追加アクションが実行される。すなわち、追加アクション実行部２０５はＴｅｌｎｅｔなどにより通信装置１に遠隔ログインし、システムログを収集しログ内容解析部２１８へ実行した追加アクション番号を通知する。

（Ｓ１７０５）そしてログ内容解析部２１８は追加アクション番号、ログ解析シナリオ２１９に基づきログ内容を解析する。本実施例では追加アクションＡＣ−１のログ解析シナリオに基づき、ログ内容を解析する。ＡＣ−１はシステムログ内に、「Ｉ／Ｏ Ｅｒｒｏｒ ｏｎ ｄｅｖｉｃｅ１」または「Currently Unreadable Sector」という用語が含まれているのであればイベントＥＶ−１６を障害原因分析部２０９に通知するものであり、本実施例においては追加アクション実行部２０５が収集した通信装置１のシステムログに「Ｉ／Ｏ Ｅｒｒｏｒ ｏｎ ｄｅｖｉｃｅ１」が含まれていたとする。ログ内容解析部２１８は実行結果を追加アクション判定部２０４に通知する。

（Ｓ１７０６）追加アクション判定部２０４は実行結果を追加アクション管理テーブル２２０に反映し、実施フラグ１８０３および結果フラグ１８０４を更新する。追加アクションＡＣ−１の結果、イベントＥＶ−１６の発生を確認したため、追加アクション管理テーブル２２０のＡＣ−１の実施フラグ１８０３を「１」に、結果フラグ１８０４を「１」に更新する。

（Ｓ１７０７）次に追加アクション判定部２０４は追加アクション管理テーブル２２０に結果フラグ１８０４が「１」であるレコードが１行以上あるか判定する。ここでは追加アクションＡＣ−１の結果フラグ１８０４が「１」であるため、追加アクション判定部２０４はイベントＥＶ−１６を障害詳細情報収集部２１０へ通知する。

（Ｓ１２１１）次に障害詳細情報収集部２１０はイベントＥＶ−１６を発生イベント一覧表に追加する。ここで発生イベント一覧表の内容は図１８Ｂと等しくなる。

（Ｓ１２０１：２回目）障害原因分析部２０９は障害原因分析ルール２１６に登録された図４Ａまたは図１６のルール４０１から、ＩＦ部４０２に図１８Ｂ発生イベント一覧表に記載されるイベント番号ＥＶ−１３、ＥＶ−１、ＥＶ−７、ＥＶ−１１、ＥＶ−８、ＥＶ−１４、ＥＶ−１６の内少なくとも一つ以上が含まれるルール１、ルール２、ルール３、ルール４、ルール５、ルール６、ルール７、ルール８、ルール９を抽出する。

（Ｓ１７０１：２回目）次に抽出した各ルールのＴＨＥＮ部から、根本原因イベント番号を特定し確信度を算出する。確信度の算出方法は１回目の処理時と同様であり、ここでは詳細な説明は省略する。既に登録済みの根本原因イベントについて再登録は行わず、確信度の更新のみを行う。ＣＥ−７の確信度についてはルール７のＩＦ部に記載されるＥＶ−１６がＳ１２１１で新たに発生イベント一覧表に追加されたため、確信度が３／３へと更新される。

（Ｓ１７０２：２回目）そして、追加アクション判定部２０４は分析結果管理テーブル２１５−２および追加アクション判定シナリオ２１１−２から実行すべき追加アクション番号を抽出し、追加アクション管理テーブル２２０へ登録する。追加アクションＡＣ−１が抽出されるが、既に登録済みの追加アクションのため再登録は行わない。

（Ｓ１７０３：２回目）さらに追加アクション判定部２０４は、追加アクション管理テーブル２２０に登録されたレコードの内、実施フラグ１８０３が「０」であるレコードが一つ以上あるかどうか判定する。ここでは追加アクションＡＣ−１の実施フラグ１８０３は「１」であるため、処理はＳ１７０４に進み分析完了となる。

＜２−１２．実施例の効果＞
以上のように、本実施例では監視対象に対して、可能性のある障害を根本原因イベントとして抽出する障害切り分け方法を説明した。この方法では、監視対象から通知されるイベントおよび予め定められた障害原因分析ルールに基づいて根本原因イベントと確信度を特定する障害原因分析ステップと、特定した根本原因イベントと確信度に基づいて監視対象に対して所定の動作を指示し、監視対象のシステムログを収集する追加アクション実行ステップと、収集したシステムログを解析し監視対象から通知された障害イベント以外の障害イベントの発生有無を判定するシステムログ解析ステップと、システムログ解析結果に基づいて、分析完了判定を行う分析完了判定ステップを備える。

以上で詳細に説明したように、本実施例では例えばハードディスクの書き込みエラーのように、監視対象側から通知されるイベントとして定義されていない装置異常を条件とした障害原因分析を行う必要がある場合にも、正しい障害原因の推定が可能となる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

たとえば実施例１の変形例として、図９の追加アクション判定シナリオ２１１の追加アクション内容９０３に、実施例２のようなシステムログ収集のための追加アクションを定義してもよい。このとき、障害原因分析ルール２１６は図４Ａおよび図１６に示すようなものを用い、追加アクション判定シナリオ２１１では、未通知イベントに対する追加アクションとしてシステムログを収集するアクションを定義する。例えば、図９の追加アクション判定シナリオ２１１に、イベント番号「ＥＶ−１６」、追加アクション番号「ＡＣ−１６」、追加アクション内容「通信装置１のシステムログ収集」を含める。このとき、図１６のルール７でイベントＥＶ−１３とＥＶ−１４が通知されている場合、イベントＥＶ−１６を未通知イベントとし、未通知イベントに対応する追加アクションとしてログを収集する。もっともこの場合、仕様上イベントＥＶ−１６は監視対象側からは通知されないので、当初は必ず未通知イベントとなる。システムログ収集のための追加アクションの内容や、ログ解析手法は実施例２と同様でよい。

また、実施例１の変形例として、図９の追加アクション判定シナリオ２１１に代えて、実施例２の図１９の追加アクション判定シナリオ２１１−２を用いることもできる。この場合、図１９の追加アクション判定シナリオ２１１−２の追加アクション内容には、システムログ収集に代えて、あるいは追加して、システムログ収集以外の追加アクション例えば「送信部１１Ａの異常警報収集」を定義することができる。

あるいは、実施例１の変形例として、図９の追加アクション判定シナリオ２１１とともに図１９の追加アクション判定シナリオ２１１−２を使用するようにして、２種類の追加アクション判定シナリオをＯＲ条件で用いてもよい。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記録装置、又はＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

２００：管理サーバ、２０１：監視対象、障害分析結果出力部２０２、分析完了判定部２０３、追加アクション判定部２０４、追加アクション実行部２０５、未通知イベント管理部２０６、障害多段分析管理部２０７、障害監視部２０８、障害分析部２０９、障害詳細情報収集部２１０、追加アクション判定シナリオ２１１、追加アクション実行シナリオ２１２、未通知イベント管理テーブル２１３、コンポーネント管理テーブル２１４、分析結果管理テーブル２１５、障害原因分析ルール２１６、障害詳細情報２１７

Claims (15)

1. 入力装置、出力装置、処理装置、および記憶装置を用い、
   前記記憶装置に格納された複数の障害原因分析ルールに基づいて、監視対象に対して可能性のある障害を抽出する障害切り分け方法であって、
   前記障害原因分析ルールの其々は、前記障害を示す根本原因イベントと、該障害に関連するイベントである条件イベントを対応付けたデータであり、
   前記入力装置により、前記監視対象から通知されるイベントである通知イベントを収集する、通知イベント収集ステップと、
   前記処理装置により、前記通知イベントと前記障害原因分析ルールに基づいて、前記根本原因イベントとその確信度を特定する、障害原因分析ステップと、
   前記処理装置により、前記通知イベントと前記障害原因分析ルールに基づいて、通知されていないイベントを未通知イベントとして特定する、未通知イベント特定ステップと、
   前記出力装置により、前記未通知イベントに対応して、前記監視対象に対して所定の動作を指示する追加アクションを実行する、追加アクション実行ステップと、を備える、
   障害切り分け方法。
2. 請求項１に記載の障害切り分け方法であって、
   前記障害原因分析ルールの其々は、前記根本原因イベントの成立条件として１または複数の前記条件イベントを列挙したデータであり、
   前記障害原因分析ステップは、
   前記通知イベントを条件イベントとして含む前記障害原因分析ルールに基づいて、前記根本原因イベントを特定し、
   前記障害原因分析ルールに列挙された条件イベントの個数、および、前記条件イベントに含まれる前記通知イベントの個数に基づいて、特定した前記根本原因イベントの確信度を算出する、
   障害切り分け方法。
3. 請求項１に記載の障害切り分け方法であって、
   前記未通知イベント特定ステップは、
   前記障害原因分析ルールに列挙された前記条件イベントのうち、前記通知イベント以外を未通知イベントとして特定する、
   障害切り分け方法。
4. 請求項１に記載の障害切り分け方法であって、
   前記追加アクション実行ステップは、
   前記未通知イベントに対して行う追加アクションを定義した対応表を、追加アクション判定シナリオとして予め規定し、
   前記未通知イベント特定ステップで特定した前記未通知イベントに応じて、前記追加アクションを実行する、
   障害切り分け方法。
5. 請求項１に記載の障害切り分け方法であって、
   前記障害原因分析ステップの後に特定した全ての未通知イベントに対して追加アクションが実行済みであれば処理を完了する第１の分析完了判定ステップと、
   前記障害原因分析ステップの後に特定した未通知イベントに対する追加アクションの実行の結果、新たな通知イベントを特定しなかった場合は処理を完了し、新たな通知イベントを特定した場合は、再度前記障害原因分析ステップを実行する、第２の分析完了判定ステップを備える、
   障害切り分け方法。
6. 請求項１に記載の障害切り分け方法であって、
   前記未通知イベントは、前記監視対象の不具合により通知されなかったイベントである、
   障害切り分け方法。
7. 入力装置、出力装置、処理装置、および記憶装置を用い、
   前記記憶装置に格納された複数の障害原因分析ルールに基づいて、監視対象に対して可能性のある障害を抽出する障害切り分け方法であって、
   前記障害原因分析ルールの其々は、前記障害を示す根本原因イベントと、該障害に関連するイベントである条件イベントを対応付けたデータであり、
   前記入力装置により、前記監視対象から通知されるイベントである通知イベントを収集する、通知イベント収集ステップと、
   前記処理装置により、前記通知イベントと前記障害原因分析ルールに基づいて、前記根本原因イベントとその確信度を特定する障害原因分析ステップと、
   前記処理装置により、特定した前記根本原因イベントと確信度に基づいて、前記監視対象に対して所定の追加アクションを指示し、前記監視対象のシステムログを収集する追加アクション実行ステップと、
   収集した前記システムログを解析し、前記監視対象から通知された通知イベント以外のイベントの発生有無を判定するシステムログ解析ステップと、を備える、
   障害切り分け方法。
8. 請求項７に記載の障害切り分け方法であって、
   前記追加アクション実行ステップは、
   前記障害原因分析ステップで特定した前記根本原因イベントとその確信度に応じて行う前記追加アクションを定義した対応表を、追加アクション判定シナリオとして予め規定し、
   前記追加アクション判定シナリオを基に、前記監視対象のシステムログを収集する、
   障害切り分け方法。
9. 請求項７に記載の障害切り分け方法であって、
   前記システムログ解析ステップは、
   前記追加アクションの実行後に収集した前記監視対象のシステムログに対して、予め規定した分析キーワードを用い、前記監視対象から通知された通知イベント以外のイベントを検知して新たな通知イベントとして特定する、
   障害切り分け方法。
10. 請求項７に記載の障害切り分け方法であって、
    前記障害原因分析ステップの後に特定した全ての追加アクションを実行済みであれば処理を完了する第１の分析完了判定ステップと、
    前記追加アクション実行ステップの結果、新たな通知イベントを特定しなかった場合は処理を完了し、新たな通知イベントを特定した場合は再度前記障害原因分析ステップを実行する第２の分析完了判定ステップを備える、
    障害切り分け方法。
11. 監視対象に対して可能性のある障害を抽出する管理サーバであって、
    前記障害を示す根本原因イベントと、該障害に関連するイベントである条件イベントを対応付けたデータである障害原因分析ルールを格納する記憶装置と、
    前記監視対象から前記障害と関連するイベントを、通知イベントとして収集する障害監視部と、
    前記通知イベントと前記障害原因分析ルールに基づいて、前記根本原因イベントを特定する障害原因分析部と、
    前記通知イベントと前記障害原因分析ルールに基づいて、前記通知イベントに無く前記条件イベントにあるイベントを、未通知イベントとして特定する未通知イベント管理部と、
    特定した前記未通知イベントに基づいて、前記監視対象に対して所定の動作を指示する追加アクションを実行する追加アクション部と、を備える、
    管理サーバ。
12. 前記記憶装置は、前記イベントに対応して前記追加アクションを対応付けたデータである追加アクションシナリオを格納し、
    前記追加アクション部は、前記追加アクションシナリオを参照して、前記追加アクションを実行する、
    請求項１１記載の管理サーバ。
13. 監視対象に対して可能性のある障害を抽出する管理サーバであって、
    前記障害を示す根本原因イベントと、該障害に関連するイベントである条件イベントを対応付けたデータである障害原因分析ルールを格納する記憶装置と、
    前記監視対象から前記障害と関連するイベントを、通知イベントとして収集する障害監視部と、
    前記通知イベントと前記障害原因分析ルールに基づいて、前記根本原因イベントとその確信度を特定する障害原因分析部と、
    特定した前記根本原因イベントとその確信度に基づいて、前記監視対象に対してシステムログの収集を指示する追加アクション部と、を備える、
    管理サーバ。
14. 前記記憶装置は、前記根本原因イベントに対応して前記確信度の条件と追加アクションを対応付けたデータである追加アクションシナリオを格納し、
    前記追加アクション部は、前記追加アクションシナリオを参照して、前記追加アクションを実行する、
    請求項１３記載の管理サーバ。
15. 前記記憶装置は、前記追加アクションに対応してシステムログの解析キーワードを対応付けたデータであるログ解析シナリオを格納し、
    収集した前記システムログを前記解析キーワードで解析するログ内容解析部を備える、
    請求項１４記載の管理サーバ。

Images