(57)【要約】【課題】ネットワークレベルでの障害の検知の有無に関わらず、業務アプリケーション等における利用状況や障害状況の情報に基づいて、ネットワーク上の障害発生の被疑部位の推定や絞り込みを可能とする。【解決手段】ネットワークシステムにおける障害を解析するネットワーク障害解析システムであって、各業務アプリケーションが使用する通信を特定するための通信要件の情報と、各通信要件に係る通信の経路上のネットワーク機器からなるノードの情報である通信経路の情報とを保持し、業務アプリケーションの実行において障害を検知したことを通知された場合に、当該通知の内容に基づいて当該業務アプリケーションが使用する通信要件の情報と当該通信要件に係る第１の通信経路の情報を特定し、当該第１の通信経路と、既に発生している１つ以上の障害に係る第２の通信経路との間で重複するノードが存在する場合に、当該ノードを障害発生の被疑部位として推定する。【選択図】図１
2014239315.tif 000002
【特許請求の範囲】
【請求項１】
業務アプリケーションが稼働する情報処理装置を有するネットワークシステムにおける障害を解析するネットワーク障害解析システムであって、
各業務アプリケーションが使用する通信を特定するための通信要件の情報と、各通信要件に係る通信の経路上のネットワーク機器からなるノードの情報である通信経路の情報と、を保持し、
業務アプリケーションの実行において障害を検知したことを通知された場合に、当該通知の内容に基づいて当該業務アプリケーションが使用する通信要件の情報と当該通信要件に係る第１の通信経路の情報を特定し、当該第１の通信経路と、既に発生している１つ以上の障害に係る第２の通信経路との間で重複するノードが存在する場合に、当該ノードを障害発生の被疑部位として推定する、ネットワーク障害解析システム。
【請求項２】
請求項１に記載のネットワーク障害解析システムにおいて、
前記第１の通信経路と１つ以上の前記第２の通信経路との間で重複する数が多いノードほど、被疑の程度が高い被疑部位として推定する、ネットワーク障害解析システム。
【請求項３】
請求項１または２に記載のネットワーク障害解析システムにおいて、
前記第１の通信経路と１つ以上の前記第２の通信経路との間で重複するノードが存在しない場合、もしくは前記第２の通信経路が存在しない場合は、前記第１の通信経路における各ノードのうち、他の全ての業務アプリケーションがそれぞれ使用する１つ以上の第３の通信経路との間で重複しないノードが存在する場合に、当該ノードを障害発生の被疑部位として推定する、ネットワーク障害解析システム。
【請求項４】
請求項３に記載のネットワーク障害解析システムにおいて、
前記第１の通信経路における各ノードのうち、１つ以上の前記第３の通信経路との間で重複する数が少ないノードほど、被疑の程度が高い被疑部位として推定する、ネットワーク障害解析システム。
【請求項５】
業務アプリケーションが稼働する情報処理装置を有するネットワークシステムにおける障害を解析するネットワーク障害解析システムとしてコンピュータを動作させるネットワーク障害解析プログラムであって、
業務アプリケーションの実行において障害を検知したことを通知された場合に、当該通知の内容に基づいて、当該業務アプリケーションが使用する通信の内容を特定するための通信要件の情報と、当該通信要件に係る通信の経路上のネットワーク機器からなるノードの情報である第１の通信経路の情報を特定し、当該第１の通信経路と、既に発生している１つ以上の障害に係る第２の通信経路との間で重複するノードが存在する場合に、当該ノードを障害発生の被疑部位として推定する処理を実行させる、ネットワーク障害解析プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークの障害監視技術に関し、特に、システムにおける障害検知状況に基づいてネットワーク上の障害部位を推定するネットワーク障害解析システムおよびネットワーク障害解析プログラムに適用して有効な技術に関するものである。
【背景技術】
【０００２】
情報処理システムの運用・管理においては、通常、サーバ機器やネットワーク機器などの各種機器や、これらにより提供される機能やサービス等の動作について監視する仕組みが構築される。
【０００３】
ネットワークの障害監視装置や障害部位を特定するシステムなどにおいては、一般的に、例えば、応答パケットの断や、パケットのレスポンスの低下等、ネットワークレベル（いわゆるＯＳＩ参照モデルの７層のうち第４層まで）の状態を収集し、その情報に基づいて障害部位を特定もしくは推定するという手法がとられている。
【０００４】
これに関連する技術として、例えば、特開２００２−２７１３２８号公報（特許文献１）には、ネットワークシステムにおける障害情報を検知し、前記ネットワークシステムを構成するネットワーク要素を階層的に定義したデータベースと前記障害情報とに基づいて、前記ネットワーク要素のうち障害の原因と推定されるネットワーク要素を抽出する技術が記載されている。
【０００５】
また、特開２００７−１８９６１５号公報（特許文献２）には、障害機器の情報を障害機器情報として収集する機器監視部と、障害機器情報に対応する障害の原因を示す障害原因情報を有する診断ファイルを記憶する診断ファイル記憶部と、上記障害機器情報に基づき上記診断ファイルから障害原因情報を取得して障害の原因を診断する障害原因解析部と、障害機器情報とネットワークトポロジ情報とに基づき障害の影響範囲を特定する障害影響範囲解析部と、上記障害の影響範囲を回避する通信経路である回避経路を機器の負荷情報に基づき算出する障害復旧部とを備えるネットワーク監視支援装置が記載されている。
【０００６】
また、特開２０１２−２１３０５７号公報（特許文献３）には、定期的に映像提供事業者設備を構成する各装置及び通信ネットワーク設備を構成する各装置から接続情報を収集している故障解析装置と、映像サーバから映像信号を受信して復号する際にエラーが発生し、予め取得した評価基準データが示す評価基準を超過していると判断した場合、評価基準超過通知を故障解析装置に送信する映像受信装置とを有する故障解析システムが記載されている。当該システムでは、故障解析装置は、受信した評価基準超過通知が示すノード識別情報により特定される映像受信装置の配信ルートを接続情報から読み出し、読み出した配信ルート上の装置や、評価基準超過通知が示すチャネルの共通性から故障箇所を特定する。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００２−２７１３２８号公報
【特許文献２】特開２００７−１８９６１５号公報
【特許文献３】特開２０１２−２１３０５７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
上述したような従来技術では、ネットワークシステムにおける障害情報と、ネットワークの構成情報や経路情報などに基づいて、障害の場所の特定もしくは推定を行うことが可能である。しかしながら、これらの技術では、ネットワークレベル（例えば、ＯＳＩ参照モデルの第４層まで）で明確な障害を検知した場合や、通信遅延などの障害の兆候となるような事象が発生している場合などにおいて功を奏するにとどまる。
【０００９】
これに対し、例えば、業務アプリケーションにおいて動作上の不具合が発生しているが、ネットワークレベルでは明確に障害を検知していないというような「半死」の状態では、障害の被疑部位の特定や推定、絞り込みを行うことが困難であった。このため、利用者にとって支障が生じているにも関わらず、システムの運用者や事業者においては異常として把握できておらず、利用者に支障を及ぼす状態が長時間継続してしまうという事態が生じる場合があった。このような事態に適切に対応しなければ、運用者や事業者に対する顧客満足度が低下してしまい、その後の事業機会を損失するという場合も生じ得る。
【００１０】
そこで本発明の目的は、ネットワークレベルでの障害の検知の有無に関わらず、業務アプリケーション等における利用状況や障害状況の情報に基づいて、ネットワーク上の障害発生の被疑部位の推定や絞り込みを可能とする、ネットワーク障害解析システムおよびネットワーク障害解析プログラムを提供することにある。
【００１１】
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【００１２】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
【００１３】
本発明の代表的な実施の形態によるネットワーク障害解析システムは、業務アプリケーションが稼働する情報処理装置を有するネットワークシステムにおける障害を解析するネットワーク障害解析システムであって、各業務アプリケーションが使用する通信を特定するための通信要件の情報と、各通信要件に係る通信の経路上のネットワーク機器からなるノードの情報である通信経路の情報と、を保持する。
【００１４】
業務アプリケーションの実行において障害を検知したことを通知された場合に、当該通知の内容に基づいて当該業務アプリケーションが使用する通信要件の情報と当該通信要件に係る第１の通信経路の情報を特定し、当該第１の通信経路と、既に発生している１つ以上の障害に係る第２の通信経路との間で重複するノードが存在する場合に、当該ノードを障害発生の被疑部位として推定するものである。
【００１５】
また、本発明は、コンピュータを上記のようなネットワーク障害解析システムとして動作させるプログラムにも適用することができる。
【発明の効果】
【００１６】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
【００１７】
すなわち、本発明の代表的な実施の形態によれば、ネットワークレベルでの障害の検知の有無に関わらず、業務アプリケーション等における利用状況や障害状況の情報に基づいて、ネットワーク上の障害発生の被疑部位の推定や絞り込みが可能となる。
【図面の簡単な説明】
【００１８】
【図１】本発明の一実施の形態におけるであるネットワーク障害解析システムを有するアプリケーション監視サーバの構成例について概要を示した図である。
【図２】本発明の一実施の形態における業務アプリケーションが稼働する情報処理システムのネットワークの構成例について概要を示した図である。
【図３】本発明の一実施の形態における業務アプリケーションで障害を検知した場合に障害部位を推定する例について概要を示した図である。
【図４】本発明の一実施の形態における通信要件テーブルのデータ構成と具体的なデータの例について概要を示した図である。
【図５】本発明の一実施の形態における経路情報テーブルのデータ構成と具体的なデータの例について概要を示した図である。
【図６】本発明の一実施の形態におけるジョブテーブルのデータ構成と具体的なデータの例について概要を示した図である。
【図７】本発明の一実施の形態におけるアプリケーション経路情報テーブルのデータ構成と具体的なデータの例について概要を示した図である。
【図８】本発明の一実施の形態における障害発生の被疑部位の推定・絞り込みの処理の流れの例について概要を示した図である。
【発明を実施するための形態】
【００１９】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。
【００２０】
＜概要＞
本発明の一実施の形態であるネットワーク障害解析システムは、１つ以上のサーバ機器やネットワーク機器などの情報処理装置により構成される情報処理システムにおいて、各サーバ等で稼働する業務アプリケーションの動作がそれぞれ正常であるか否かを監視し、その結果を解析することによって、ネットワークレベルでの障害の検知の有無に関わらず、当該情報処理システムのネットワーク構成上における障害発生の被疑部位を絞り込みもしくは推定することを可能とするシステムである。
【００２１】
より具体的には、各業務アプリケーションが処理を実行する際に行う通信について、送信元と送信先のＩＰアドレス、およびその間の通信経路（経由するノード）の情報を予め登録しておく。業務アプリケーションの監視等において異常や障害が検知された場合、障害が検知された業務アプリケーションが使用する通信経路上のノードに障害の被疑部位があると推定し、これを絞り込んでいく。
【００２２】
例えば、複数の業務アプリケーションにおいて障害が検知された場合、それぞれの業務アプリケーションが使用する通信経路で重複するノードがある場合には、これらの重複ノードが障害発生の原因となっている蓋然性が高いことから、これらを被疑部位として絞り込む。また、重複するノードがない（もしくは障害が検知された業務アプリケーションが１つしかない）場合には、当該通信経路上の各ノードについて、他の全ての業務アプリケーションが使用する通信経路のいずれとも重複しない場合、すなわち、当該ノードが当該業務アプリケーションにおける通信にしか用いられないような場合に、当該ノードが障害発生の原因となっている蓋然性が高いことから、これらのノードを被疑部位として絞り込む。
【００２３】
図２は、本実施の形態における業務アプリケーションが稼働する情報処理システムのネットワークの構成例について概要を示した図である。図２の例では、業務アプリケーションを稼働させる複数の業務サーバ（業務サーバＡ（２ａ）〜業務サーバＤ（２ｄ））がそれぞれ連携してサービスを提供する構成となっており、それぞれが属するネットワークがルータやレイヤ３スイッチ等のネットワーク機器（ノードＡ（３ａ）〜ノードＥ（３ｅ）その他）によって接続される構成を有している。また、各業務サーバ上で稼働する業務アプリケーションにおける障害や異常を監視するアプリケーション監視サーバ１が接続されている。
【００２４】
ここでは、例えば、業務サーバＡ（２ａ）と業務サーバＣ（２ｃ）上の業務アプリケーションが連携して行う処理について、通信要件として、ノードＡ（３ａ）→ノードＢ（３ｂ）→ノードＣ（３ｃ）の経路で通信が行われることを示している。同様に、例えば、業務サーバＢ（２ｂ）と業務サーバＤ（２ｄ）上の業務アプリケーションが連携して行う処理について、通信要件として、ノードＤ（３ｄ）→ノードＢ（３ｂ）→ノードＥ（３ｅ）の経路で通信が行われることを示している。他にも業務アプリケーションで使用される通信経路は存在し得るが、ここでの説明は省略する。
【００２５】
なお、図２の例では、業務サーバＡ（２ａ）と業務サーバＣ（２ｃ）など、通信経路の両端で連携する業務アプリケーションが稼働する構成としているが、これに限られず、例えば、一端の業務サーバにおいてのみ業務アプリケーションが稼働して、これにより複数のノードを経由する通信が行われるという構成であってもよい。また、通信経路の両端は業務サーバなどのサーバ機器に限られず、例えば、ネットワーク機器や、Ｗｅｂブラウザ等のプログラムが稼働するＰＣ（Personal Computer）等のクライアント端末、銀行のＡＴＭ機（現金自動預け払い機）など、狭義のサーバ機器以外の情報処理装置であってもよい。
【００２６】
図３は、本実施の形態における業務アプリケーションで障害を検知した場合に障害部位を推定する例について概要を示した図である。ここでは、図２と同様のシステム構成およびネットワーク構成において、例えば、業務サーバＣ（２ｃ）と業務サーバＤ（２ｄ）上で稼働する業務アプリケーションにおいてそれぞれ障害が発生したことを、アプリケーション監視サーバ１が同時もしくは近接する時間帯で検知したことを示している。
【００２７】
このとき、ネットワークの監視において明確な障害事象を検知していなくても、ネットワーク構成のいずれかのノードや機器等に問題があって「半死」の状態となっており、これが原因で業務アプリケーションに障害を発生させていると仮定する。そうすると、問題があるノードは、障害が発生している業務アプリケーションが使用している通信経路上のいずれかのノードに存在するであろうことが推測される。従って、複数の業務アプリケーションにおいて同時期に障害が発生している場合は、これらの業務アプリケーションが使用している通信経路において重複する部分（図３の例ではノードＢ（３ｂ））において問題が発生している可能性が高いことが推測される。
【００２８】
一方、例えば、図３の例のように複数の業務アプリケーションにおいて障害を検知するのではなく、１つの業務アプリケーションでのみ障害を検知した場合は、上記のような推測とは逆に、当該業務アプリケーションが使用する通信経路上の各ノードのうち、他の業務アプリケーション（障害を検知しているものに限らず全て）が使用する通信経路のいずれとも重複しないもの（もしくは重複する経路の数が少ないもの）において問題が発生している可能性が高いことが推測される。また、その逆として、他の業務アプリケーションが使用している通信経路と重複しているノード（もしくは重複する経路の数が多いノード）は、問題が発生している可能性が低いことが推測される。
【００２９】
問題が発生しているノードが、他の業務アプリケーションが使用している通信経路と重複している場合は、その業務アプリケーションにおいても障害が発生する蓋然性が高いと考えられることから、このような推測が可能である。なお、このような推測は、複数の業務アプリケーションで障害を検知しているものの、通信経路に重複する部分がない場合についても同様に適用することができる。
【００３０】
本実施の形態のネットワーク障害解析システムでは、上記のような手法をとることにより、例えば、ネットワークの監視装置等において、ネットワーク機器や回線、ケーブル等の物理的な故障の情報や、通信の遅延、パケットロス等の障害の兆候となるような情報を検知できていない場合であっても、業務アプリケーションの利用状況に障害もしくは悪化等の事象が生じた場合に、ネットワーク構成上における障害の被疑部位を推定し、もしくは絞り込み、速やかに復旧もしくは障害を回避させるための適切な措置を講じることを可能とするものである。
【００３１】
＜システム構成＞
図１は、本発明の一実施の形態であるネットワーク障害解析システムを有するアプリケーション監視サーバの構成例について概要を示した図である。図１に示すように、本実施の形態のネットワーク障害解析システムは、例えば、アプリケーション監視サーバ１上にネットワーク障害解析部２０として実装されている。アプリケーション監視サーバ１上には、他に、例えば、１つ以上の業務サーバ２上でそれぞれ稼働する業務アプリケーションの障害や異常を監視する業務アプリケーション監視部１０が実装されている。また、ネットワークの障害や異常を監視する図示しないネットワーク障害監視システム等が実装されていてもよい。これらのシステムは、それぞれ独立したサーバシステムとして構成することも当然可能である。
【００３２】
アプリケーション監視サーバ１は、図２や図３において示したように、１つ以上の業務サーバ２上で稼働する図示しない業務アプリケーションの障害や異常を監視して、障害を検知した場合には障害発生の被疑部位を推定し、もしくは絞り込んで出力する機能を有するサーバシステムである。このアプリケーション監視サーバ１は、例えば、サーバ機器や、クラウドコンピューティング環境における仮想サーバ等により構成され、図示しないＯＳ（Operating System）やＤＢＭＳ（DataBase Management System）などのミドルウェア上で稼働するソフトウェアプログラムとして、業務アプリケーション監視部１０やネットワーク障害解析部２０などの各部（サブシステム）を実装している。
【００３３】
業務アプリケーション監視部１０は、各業務サーバ２上で稼働する業務アプリケーションの障害や異常を監視して、これらを検知した場合にこれを通知等により出力する機能を有する。業務アプリケーションに障害や異常が発生したかの判定は、例えば、業務アプリケーションが実行の際に出力する所定のエラーメッセージや警告メッセージなどを取得して、その内容に基づいて行うことができる。
【００３４】
本実施の形態では、ネットワークの障害被疑部位を推定することが目的であることから、上記の所定のエラーメッセージや警告メッセージとしては、例えば、純粋に業務的・アプリケーション的なエラー（不適切な入力データや操作によるもの、業務アプリケーションのプログラムの不具合等）は除外される。なお、業務アプリケーション監視部１０としては、既存もしくは市販の運用監視ツールやソリューション、パッケージプログラムなどを適宜使用することができる。
【００３５】
ネットワーク障害解析部２０は、業務アプリケーション監視部１０による業務アプリケーションの障害や異常の監視結果の情報に基づいて、上述した手法により、障害が検知された各業務アプリケーションが使用する通信経路上のノード（ネットワーク機器）から１つ以上のノードを障害発生の被疑部位として推定もしくは絞り込んで出力する機能を有し、ネットワーク障害解析システムとして機能するものである。ネットワーク障害解析部２０は、例えば、ソフトウェアプログラムとして実装される障害部位推定部２１と、データベースやファイルテーブル等により構成される通信要件テーブル２２および経路情報テーブル２３の各テーブルを有する。また、障害部位推定部２１の処理結果として出力された障害被疑経路情報２４および障害被疑ノード情報２５の各データをファイルやメモリ上に保持する。
【００３６】
障害部位推定部２１は、上述した手法により、障害が検知された各業務アプリケーションが使用する通信経路上のノードから１つ以上のノードを障害発生の被疑部位として推定もしくは絞り込んで出力する機能を有する。そのために、ネットワーク障害解析部２０では、各業務アプリケーションが使用する通信を特定するための通信要件に係る情報（例えば、送信元および送信先のＩＰアドレスや、通信経路上の各ノードの情報など）を自動もしくは手動により取得して、予め通信要件テーブル２２および経路情報テーブル２３に保持しておく。
【００３７】
障害部位推定部２１では、業務アプリケーション監視部１０により障害が検知された場合に、障害通知メッセージに基づいて、障害が発生した通信経路の情報を通信要件テーブル２２および経路情報テーブル２３の内容に基づいて特定する。さらに、当該通信経路上の各ノードから、上述した手法により障害発生の被疑部位となるノードを推定もしくは絞り込み、この内容を監視用のクライアント端末等の画面上にリスト表示するなどして通知する。
【００３８】
このとき、新たに障害を検知した通信経路の情報を障害被疑経路情報２４に記録しておくとともに、当該通信経路上の各ノードの情報を障害被疑ノード情報２５に記録しておく。なお、障害被疑経路情報２４および障害被疑ノード情報２５に記録された通信経路やノードの各エントリの情報は、対応する障害の復旧や、一定時間の経過等のタイミングで自動もしくは手動で消去し、最新の障害状況に基づく情報に更新されるようにしておくものとする。
【００３９】
＜データ構成＞
図４は、本実施の形態における通信要件テーブル２２のデータ構成と具体的なデータの例について概要を示した図である。通信要件テーブル２２は、各業務アプリケーションによって使用される通信についてその要件の情報を保持するテーブルであり、例えば、Ｎｏ．、送信元アドレス、送信先アドレス、プロトコル、およびポート番号などの各項目を有する。
【００４０】
Ｎｏ．の項目は、各通信要件のエントリに対してユニークに採番されたシーケンス番号などの情報を保持する。送信元アドレスおよび送信先アドレスの各項目は、それぞれ、対象の通信要件における送信元および送信先となる各業務サーバ２等のＩＰアドレスの情報を保持する。プロトコルおよびポート番号の各項目は、それぞれ、対象の通信要件におけるプロトコルおよび用いられるポート番号の情報を保持する。プロトコルとしては、図示するように、例えば“ｔｃｐ”や“ｕｄｐ”などの情報が含まれ得る。なお、通信要件テーブル２２の上記の各項目は、例えば、管理者等が手動で予め登録しておくようにする。
【００４１】
図４の例では、図２の例において矢印で示した２つの通信経路（業務サーバＡ（２ａ）と業務サーバＣ（２ｃ）間、および業務サーバＢ（２ｂ）と業務サーバＤ（２ｄ）間）について、それぞれ、Ｎｏ．の項目が“１”および“７”のエントリにおいて具体的なデータが登録されている例を示している。
【００４２】
図５は、本実施の形態における経路情報テーブル２３のデータ構成と具体的なデータの例について概要を示した図である。経路情報テーブル２３は、通信要件テーブル２２に登録された各通信要件に対応する通信経路に属するノードの情報を保持するテーブルであり、例えば、Ｎｏ．、送信元アドレス、送信先アドレス、ノード番号、ノード、前ノード、および後ノードなどの各項目を有する。
【００４３】
Ｎｏ．の項目は、各ノードのエントリに対してユニークに採番されたシーケンス番号などの情報を保持する。送信元アドレスおよび送信先アドレスの各項目は、それぞれ、対象のノードが属する通信経路における送信元および送信先となる各業務サーバ２等のＩＰアドレスの情報であり、図４に示した通信要件テーブル２２の送信元アドレスおよび送信先アドレスの項目に対応する。
【００４４】
ノード番号の項目は、対象のノードが属する通信経路内で、各ノードに対してユニークに採番されたシーケンス番号などの情報を保持する。図５の例では、送信元に近いノードから順に“１”、“２”、…として割り当てるものとしているが、これに限られない。ノードの項目は、対象のノードを構成するネットワーク機器等を特定するマシン名等の情報を保持する。本実施の形態では、図２の例におけるノードＡ（３ａ）やノードＢ（３ｂ）等に対応して、“ノードＡ”や“ノードＢ”等の名称により特定している。前ノードおよび後ノードの各項目は、それぞれ、対象のノードが属する通信経路において、対象のノードに対して１ホップ前および後ろにあるノードを特定するマシン名等の情報を保持する。
【００４５】
図５の例では、図４の場合と同様に、図２の例において矢印で示した２つの通信経路（業務サーバＡ（２ａ）と業務サーバＣ（２ｃ）間、および業務サーバＢ（２ｂ）と業務サーバＤ（２ｄ）間）上の各ノードについて、それぞれ、Ｎｏ．の項目が“１”〜“３”および“１３”〜“１４”のエントリにおいて具体的なデータが登録されている例を示している。
【００４６】
例えば、送信元アドレスが“１９２．１６８．１．１”で送信先アドレスが“１９２．１６８．１１．２”である通信経路上のノード（Ｎｏ．の項目が“１”〜“３”のエントリ）において、ノード番号の項目が“１”のノード（“ノードＡ”）は、図２の構成例に示すように、当該通信経路上の最初のノードであるため前ノードは存在せず、前ノードの項目の値は設定されないことを示している。同様に、送信元アドレスが“１９２．１６８．１０．１”で送信先アドレスが“１９２．１６８．２９．２”である通信経路上のノード（Ｎｏ．の項目が“１３“〜“１５”のエントリ）において、ノード番号の項目が“３”のノード（“ノードＣ”）は、当該通信経路上で最後のノードであるため後ノードは存在せず、後ノードの項目の値は設定されないことを示している。
【００４７】
なお、経路情報テーブル２３に登録される各通信経路上のノードの情報は、手動で登録することも可能であるが、例えば、各ノードに設定されたルーティングテーブル等を取得・収集して解析し、ネットワーク上の通信経路情報を自動的に算出するような公知の技術を適宜利用することも可能である。また、このような算出処理を日次等のタイミングで定期的に行い、および／またはネットワークの構成変更等をトリガとして適時に行うことで、いわゆるダイナミックルーティングが用いられて、通信経路が自動的に変更もしくは最適化されるような構成であっても、経路情報テーブル２３における各ノードの情報を適宜最新のものに更新して適切に対応することが可能となる。
【００４８】
図４および図５の例では、通信経路を特定するために、図４に示すような通信要件テーブル２２に、送信元と送信先のＩＰアドレスによって特定される通信要件を登録して行っているが、通信経路の特定の手法はこのようなものに限られない。例えば、業務アプリケーション監視部１０が監視対象とする業務アプリケーションのジョブやプロセスなどの識別情報に対して直接通信経路の情報を関連付けて管理することも可能である。
【００４９】
図６は、本実施の形態におけるジョブテーブル２２’のデータ構成と具体的なデータの例について概要を示した図である。ジョブテーブル２２’は、各業務サーバ２上で業務アプリケーションとして実行されるジョブの情報を保持するテーブルであり、例えば、ジョブＩＤ、およびアプリケーション識別ＩＤなどの各項目を有する。ジョブＩＤの項目は、各ジョブを一意に識別するＩＤや番号等の情報を保持する。アプリケーション識別ＩＤの項目は、対象のジョブにおいて実行されるアプリケーションプログラムやモジュール等を識別するＩＤ等の情報を保持する。１つのジョブで複数のアプリケーションプログラムが実行される場合もある。
【００５０】
図７は、本実施の形態におけるアプリケーション経路情報テーブル２３’のデータ構成と具体的なデータの例について概要を示した図である。ここでは、図５に示した経路情報テーブル２３の例における送信元アドレスおよび送信先アドレスの項目に代えて、アプリケーション識別ＩＤの項目を有している。この項目は、対象のノードが属する通信経路を使用する業務アプリケーションを特定する情報であり、図６に示したジョブテーブル２２’のアプリケーション識別ＩＤの項目に対応する。
【００５１】
図６に示したジョブテーブル２２’および図７に示したアプリケーション経路情報テーブル２３’のような構成を有するテーブルを用いることにより、業務サーバ２上で実行されるジョブの識別情報から、使用する通信経路上の各ノードの情報を直接取得することが可能となる。なお、実際に障害が検知されたジョブについて、障害の内容や、業務的な重要度、影響範囲などの情報に基づいて、軽微な場合には障害を無視するようにしてもよいし、直後にジョブをリラン等した際に正常終了したような場合には障害を無視するようにしてもよい。
【００５２】
なお、上述の図４〜図７で示した各テーブルのデータ構成（項目）はあくまで一例であり、同様のデータを保持・管理することが可能な構成であれば、他のテーブル構成やデータ構成であってもよい。
【００５３】
＜処理の流れ＞
図８は、本実施の形態のネットワーク障害解析部２０における障害発生の被疑部位の推定・絞り込みの処理の流れの例について概要を示した図である。ネットワーク障害解析部２０では、予め、通信要件テーブル２２および経路情報テーブル２３に、各業務アプリケーションの通信要件、および各通信要件に対応する通信経路上のノードの情報がそれぞれ登録されているものとする。
【００５４】
処理を開始すると、障害部位推定部２１は、まず、業務アプリケーション監視部１０による各業務アプリケーションの監視結果において障害や異常を検知したか否かを判定する処理を、障害を検知するまで繰り返す（Ｓ０１）。障害を検知すると、障害通知メッセージ等の内容に基づいて、通信要件テーブル２２に登録された各通信要件の中で当該障害に対応する通信要件を特定し、当該通信要件における送信元と送信先のＩＰアドレスの情報を取得する（Ｓ０２）。さらに、当該通信要件に対応する通信経路の情報として、経路情報テーブル２３から通信経路上の各ノード（ネットワーク機器等）の情報を取得する（Ｓ０３）。
【００５５】
さらに、障害被疑経路情報２４を参照し、ここに保持されている既発生の障害に係る通信経路の情報を取得する（Ｓ０４）。上述したように、障害被疑経路情報２４に登録されている情報は、障害を検知してから所定の期間のみ保持されており、当該期間を経過すると削除もしくは無効とされる。すなわち、近接する時間帯に検知した障害に係るもののみが登録されていることになり、これらは新たに検知した障害との関連性があるものと推定される。
【００５６】
次に、ステップＳ０４の処理結果として、既発生の障害が登録されているか否かを判定し（Ｓ０５）、登録されている場合は、ステップＳ０３で取得した、新たに障害を検知した通信経路上の全ノードについて処理を繰り返すループ処理を開始する（Ｓ０６）。ループ処理では、まず、対象のノードが、ステップＳ０４で取得した既発生の障害に係る通信経路上のいずれかに含まれるか、すなわち、新たに障害を検知した通信経路と、既発生の障害に係る通信経路が、対象のノードにおいて重複しているか否かを確認する（Ｓ０７、Ｓ０８）。
【００５７】
ステップＳ０８において、重複していない場合は、対象のノードについての処理を終了し、次のノードの処理に移る（Ｓ１０、Ｓ０６）。一方、重複している場合は、対象のノードを被疑部位として抽出する（Ｓ０９）。複数の障害が検知されている場合に、これらの障害に係る業務アプリケーションがそれぞれ使用する通信経路で重複するノードは、障害発生の原因となっている蓋然性が高いと考えられるからである。なお、このとき、例えば、既発生の障害に係る通信経路との間で重複した数をカウントして、推定の強度を表すパラメータの１つとしてもよい。被疑部位として抽出したノードの情報は、障害被疑ノード情報２５に登録する。その後、対象のノードについての処理を終了し、次のノードの処理に移る（Ｓ１０、Ｓ０６）。
【００５８】
新たに障害を検知した通信経路上の全ノードに対するループ処理が終了すると、障害被疑ノード情報２５を参照して、被疑部位として抽出されたノードがあるか否かを判定する（Ｓ１１）。被疑部位として抽出されたノードがある場合は、これを出力して（Ｓ１７）、処理を終了する。
【００５９】
一方、被疑部位として抽出されたノードが存在しなかった場合、および、ステップＳ０５で、既発生の障害が登録されていない場合（最初に検知した障害である場合）は、ステップＳ０３で取得した、新たに障害を検知した通信経路上の全ノードについて処理を繰り返す別のループ処理を開始する（Ｓ１２）。ループ処理では、まず、対象のノードが、通信要件テーブル２２および経路情報テーブル２３に登録されている他の全ての通信経路（処理の効率上、障害が検知されていないものに限定してもよい）上のいずれかに含まれるか、すなわち、新たに障害を検知した通信経路と、他の通信経路が、対象のノードにおいて重複しているか否かを確認する（Ｓ１３、Ｓ１４）。
【００６０】
ステップＳ１４において、重複している場合は、対象のノードについての処理を終了し、次のノードの処理に移る（Ｓ１６、Ｓ１２）。一方、重複していない場合は、対象のノードを被疑部位として抽出する（Ｓ１５）。障害が検知された業務アプリケーションが１つしかない場合、もしくは、既発生の障害に係る通信経路との間で重複がない場合は、正常な状態のものも含む他の通信経路との間で重複していないノードが、単独での障害発生の原因となっている蓋然性が高いと考えられるからである。
【００６１】
重複がない場合だけでなく、重複が少ない場合も、単独での障害発生の原因となる可能性があるため、ステップＳ１４において、重複している場合であっても、重複した数が所定の数より少ないノード、もしくは重複した数の少ないものから順に上位の所定の数のノードを被疑部位として抽出するようにしてもよい。このとき、例えば、重複した数の少なさを推定の強度を表すパラメータの１つとしてもよい。この場合、重複した数が多いほど被疑部位としての推定の強度は弱くなることになる。
【００６２】
被疑部位として抽出したノードの情報は、障害被疑ノード情報２５に登録する。その後、対象のノードについての処理を終了し、次のノードの処理に移る（Ｓ１６、Ｓ１２）。新たに障害を検知した通信経路上の全ノードに対するループ処理が終了すると、障害被疑ノード情報２５に登録されているノードを、推定された被疑部位として出力して（Ｓ１７）、処理を終了する。なお、処理を終了する前に、ステップＳ０２、Ｓ０３で取得した、新たに障害を検知した通信経路に係る情報を、既発生の障害に係る通信経路の情報として障害被疑経路情報２４に登録しておく。
【００６３】
以上に説明したように、本発明の一実施の形態であるネットワーク障害解析システムによれば、情報処理システムにおいて各業務サーバ２で稼働する業務アプリケーションの動作を監視し、障害を検知した場合に、障害を検知した業務アプリケーションが使用する通信経路と、既発生の障害に係る通信経路もしくは他の正常な通信経路との重複の有無を解析することで、ネットワークレベルでの障害の検知の有無に関わらず、ネットワーク構成上において障害発生の被疑部位となるノードを推定もしくは絞り込むことが可能となる。
【００６４】
これにより、例えば、ネットワークの監視装置等において、ネットワーク機器や回線、ケーブル等の物理的な故障の情報や、通信の遅延、パケットロス等の障害の兆候となるような情報を検知できていない場合であっても、業務アプリケーションの利用状況に障害もしくは悪化等の事象が生じた場合に、ネットワーク構成上における障害の被疑部位を推定し、速やかに復旧もしくは障害を回避させるための適切な措置を講じることが可能となる。
【００６５】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
【００６６】
また、上記の各図において、制御線や情報線は説明上必要と考えられるものを示しており、必ずしも実装上の全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。
【産業上の利用可能性】
【００６７】
本発明は、システムにおける障害検知状況に基づいてネットワーク上の障害部位を推定するネットワーク障害解析システムおよび障害解析プログラムに利用可能である。
【符号の説明】
【００６８】
１…アプリケーション監視サーバ、２…業務サーバ、２ａ〜２ｄ…業務サーバＡ〜業務サーバＤ、３ａ〜３ｅ…ノードＡ〜ノードＥ、
１０…業務アプリケーション監視部、
２０…ネットワーク障害解析部、２１…障害部位推定部、２２…通信要件テーブル、２２’…ジョブテーブル、２３…経路情報テーブル、２３’…アプリケーション経路情報テーブル、２４…障害被疑経路情報、２５…障害被疑ノード情報。
【図１】
2014239315.tif 000003
【図２】
2014239315.tif 000004
【図３】
2014239315.tif 000005
【図４】
2014239315.tif 000006
【図５】
2014239315.tif 000007
【図６】
2014239315.tif 000008
【図７】
2014239315.tif 000009
【図８】
2014239315.tif 000010