ネットワーク管理システムおよび方法
【課題】既知の問題に対する診断のカスタマイズができ、診断知識が用意されていない未知の障害に対しても適切な診断を実行することができる技術を提供する。
【解決手段】ネットワーク管理システムは、自律システムが複数相互接続された広域網上に複数のエージェントを配置し、障害の検知と解析を自動的に行う。各エージェントは、複数の他のエージェントを通じて広域網の状態に関する情報を多地点から収集するエージェント間通信モジュール３０１と、広域網上で発生している現象の推測を行い、推測した内容の正否を複数の診断項目を調査することにより判定する障害解析・推論エンジン３０３と、を有する。障害解析・推論エンジン３０３は、判定の導出に利用する診断項目の種類および実行順序をユーザとの対話的処理を通じて変更する対話手段と、対話手段によりユーザが変更した診断項目および実行順序に基づき判定処理を再実行する再実行手段と、を有する。
【解決手段】ネットワーク管理システムは、自律システムが複数相互接続された広域網上に複数のエージェントを配置し、障害の検知と解析を自動的に行う。各エージェントは、複数の他のエージェントを通じて広域網の状態に関する情報を多地点から収集するエージェント間通信モジュール３０１と、広域網上で発生している現象の推測を行い、推測した内容の正否を複数の診断項目を調査することにより判定する障害解析・推論エンジン３０３と、を有する。障害解析・推論エンジン３０３は、判定の導出に利用する診断項目の種類および実行順序をユーザとの対話的処理を通じて変更する対話手段と、対話手段によりユーザが変更した診断項目および実行順序に基づき判定処理を再実行する再実行手段と、を有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は単一組織等が管理する自律システム（Autonomous System、ＡＳ）が複数相互接続された広域網（例えばインターネット）において、広域網で発生した障害の検知と解析を自動的に行うことにより広域網の安定運用を可能とするネットワーク管理システムおよび方法に関するものである。
【背景技術】
【０００２】
インターネットは複数のルータ、ＬＡＮ、より広域では複数のＡＳ（Autonomous System）から成る広がりを持つ分散システムとして考えられる。このように中央集権的な管理機構を持たないインターネットにおいては、その管理、制御は個々のネットワークを管理する組織の管理者によって行われている。しかし、ＡＳ間の経路障害などの広範囲に渡る問題への対処や管理制御においては単一の箇所からの観測のみでは原因およびその発生箇所を特定するのが非常に難しく複数のネットワークの管理者同士の協調が不可欠である。このような人間同士の協調は電話などのｌｅｇａｃｙなメディアで行われることも多いため、時間とコストがかかり、結果として問題の解決を難しくしていた。
【０００３】
このような問題に対処するためにネットワーク上に配置された複数のコンピュータプログラム（以下、エージェント）の協調によりＡＳ間経路障害の診断、検知を迅速に行う診断システム（以下、ＥＮＣＯＲＥ（Inter-AS Diagnostic Ensemble System using Cooperative Reflector Agents））が提案されている（本出願人による特許文献１参照）。ＥＮＣＯＲＥ中のエージェント（以下、ＥＮＣＯＲＥエージェント）は障害診断の手順などに関する診断知識を持ち、各ＥＮＣＯＲＥエージェントはその知識に基づき必要な情報の観測、他のＥＮＣＯＲＥエージェントとの協調などの動作を随時選択しながら、従来は人間同士の協調により行っていたＡＳ間経路障害の診断を行う。
【０００４】
以下、前記ＥＮＣＯＲＥを例にして従来のエージェントを用いたネットワーク管理システムの動作の概略を説明する。
【０００５】
１．ネットワークの複数の地点にエージェントを配置する。ここで、実際のエージェントの配置はエージェントにより検出・診断すべき問題の種類やネットワークの構成によって異なる。例えばＥＮＣＯＲＥはインターネットの構成単位であるＡＳ（Autonomous System）間での経路障害の診断を主な目的としているので各ＡＳ毎に少なくとも１つのエージェントを配置することを前提としている。そのため、ここでもＡＳ毎にエージェントが配置されているものとして説明を行う。
【０００６】
２．各エージェントはネットワーク内のルータなどのネットワーク機器と適切に通信を行いネットワークの情報を定期的に収集する。例えば、ＡＳ間経路障害の診断のためには、ＡＳ間で経路情報の交換を実際に行っているルータと通信を行いＡＳ間で伝搬されている経路情報の監視を行う。具体的にどの情報をどこから集めるかといった具体的な手順に関してはすべて診断知識あるいはエージェントの設定情報に含まれているものとする。
【０００７】
３．各エージェントは他のＡＳに配置されているエージェントとネットワーク情報の交換を行うことがある。これは、分散システムであるインターネットにおいては、ある地点（ＡＳ）から観測できるネットワーク情報は部分的なものに限られる特性があるからである。例えばあるＡＳから広報された経路情報は複数のＡＳによって適宜修正をされながらインターネット全体に伝搬されていくが、このときどのＡＳを通って伝搬されているか、別のＡＳによって経路情報にどのような修正が施されているかは当該ＡＳからは観測できないため、他ＡＳのエージェントの観測結果を利用するほかない。前ステップと同様にどの情報をどのエージェントと交換するといった具体的な手順は診断知識あるいはエージェントの設定情報に含まれているものとする。
【０００８】
４．各エージェントは自分自身で収集したネットワーク情報の解析結果と診断知識に基づきネットワークにおいて何らかの障害が発生していないかを監視する。エージェントが障害や異常が発生していないと判定した場合はステップ２に戻りネットワーク情報の収集および解析を繰り返す。
【０００９】
５．ステップ４での解析の結果、ＥＮＣＯＲＥ中のあるエージェントが何らかの障害の可能性があると判定した場合、当該エージェントは診断知識を用いてどのような異常・不具合が起きているか、原因は何か、ネットワーク上のどの場所で異常が発生しているかなど障害の詳細を推測することを試みる。この推論の手順の概略を以下に示す。
【００１０】
（ａ）障害の可能性を検知したエージェントは収集したネットワーク情報の解析結果と診断知識中の障害判定用知識を利用して、可能性のある障害を抽出し、診断のための「仮説」を立てる。例えば、「特定のサーバに一定時間接続不能であればサーバに障害が起きている可能性がある」などが「仮説」の例である。
（ｂ）前ステップにおいて設定した「仮説」を検証する。ＥＮＣＯＲＥにおける診断知識中には個々の「仮説」が成立するために検証すべき診断項目の集合およびそれらの実行順序があらかじめ規定されている。ただし、実際に実行される項目およびその順序は各診断項目の結果に依存して変化するため、診断の状況によって動的に変化する。また、「仮説」と診断項目との間にも依存関係が存在し、特定の診断項目の正否によって新たな検証すべき「仮説」が成立するということもある。
（ｃ）すべての「仮説」を検証した結果がエージェントによる推論結果となる。
【００１１】
６．以上の手順によりエージェントが得た推論の結果はメールなどの手段を通じてネットワーク管理者に通知される。
【００１２】
図１にＥＮＣＯＲＥにおける各エージェントの診断手順のフローチャートを示す。図１に示すように、エージェントはネットワーク機器、他のエージェントから情報を収集し（１０１）、現在の状態は障害の可能性があるかどうかを判断し（１０２）、障害の可能性がない場合は、ステップ１０１に戻る。障害の可能性がある場合は、診断知識を用いて、診断「仮説」を作成し（１０３）、診断項目の抽出を行い（１０４）、診断項目を実行する（１０５）。実行すべき診断項目がある場合はステップ１０５に戻る。実行すべき診断項目がなければ、未検証の「仮説」があるかどうか判断し（１０７）、ある場合はステップ１０４に戻る。未検証の「仮説」がない場合は、全「仮説」の検証結果をユーザ（ネットワーク管理者）に通知する（１０８）。
【００１３】
ＥＮＣＯＲＥシステムを用いてエージェントの協調によりＡＳ間での経路障害の原因が診断される例を図２を用いて示す。
【００１４】
図中において、ＡＳｓｅｌｆから広報された経路情報はＡＳ１、ＡＳ２あるいはＡＳ３を経由してＡＳ４に伝搬されるものとする。ここで、ＡＳ１とＡＳ２との間でＡＳｓｅｌｆに関するフィルタの設定に誤りが発生して、ＡＳｓｅｌｆに関する経路情報がＡＳ２に流れなくなった状況を想定する。この状況では診断知識より「ＡＳ１、ＡＳ２間の物理的接続の障害が発生した」あるいは「ＡＳ２の経路フィルタの設定誤りにより経路情報が破棄されている」という仮説が成立するものとする。これらの仮説を検証するためにＡＳｓｅｌｆ中のエージェントＲｓｅｌｆはＡＳ１、ＡＳ２のエージェントＲ１、Ｒ２と通信し、それぞれのＡＳにおいて観測された経路情報を送り返してもらう。その結果、ＡＳ１では自分が広報した経路情報が存在するのに対し、ＡＳ２ではＡＳ１の経路情報はあっても自分の経路情報が含まれていないことを認識する。以上より、２つめの仮説が成立することが分かりＡＳｓｅｌｆではＡＳ１とＡＳ２間でＡＳｓｅｌｆの経路情報に関するフィルタの設定に誤りがあるということが推論できる。
【００１５】
【特許文献１】特許第３４８５７８９号公報
【発明の開示】
【発明が解決しようとする課題】
【００１６】
ＥＮＣＯＲＥは診断知識の種類や内容をユーザが拡充することにより経路情報の伝搬障害以外の障害への対応が容易に行える高い拡張性を有している。しかし、現行のＥＮＣＯＲＥではＥＮＣＯＲＥエージェント内に保存する診断知識はネットワーク管理者の持つ過去の経験や知識に基づいてあらかじめ作成されエージェントの動作以前にエージェント中に組み込む必要がある。しかし、ネットワークにおいて発生する障害はその原因や障害内容が多岐に渡るため、すべての障害に対応できるようにあらかじめ診断知識を作っておくことは不可能である。そのため、現実的にはＥＮＣＯＲＥは限られた障害に対する診断知識しか持ち得ず、ＥＮＣＯＲＥの運用中に診断知識が対象としていない未知の障害が発生した場合は十分な診断ができない可能性がある。
【００１７】
本発明の目的は、既知の問題に対する診断のカスタマイズができ、診断知識が用意されていない未知の障害に対しても適切な診断を実行することができる技術を提供することにある。
【課題を解決するための手段】
【００１８】
本明細書において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
【００１９】
第１の発明は、自律システムが複数相互接続された広域網上に複数のエージェントを配置し、前記広域網で発生した障害の検知と解析を自動的に行うネットワーク管理システムであって、前記各エージェントは、前記広域網上に配置された複数の他のエージェントとの協調動作を通じて広域網の状態に関する情報を多地点から収集するエージェント間通信モジュールと、前記エージェント間通信モジュールが取得した広域網の情報と自エージェント中に含まれる診断知識を用いて広域網上で発生している現象の原因を含む推測を行い、推測した内容の正否を複数の診断項目を調査することにより判定する障害解析・推論エンジンと、を有し、前記障害解析・推論エンジンは、判定の導出に利用する診断項目の種類および実行順序をユーザとの対話的処理を通じて変更する対話手段と、前記対話手段によりユーザが変更した診断項目および実行順序に基づき判定処理を再実行する再実行手段と、を有することを特徴とする。
【００２０】
第２の発明は、前記第１の発明において、前記障害解析・推論エンジンは、診断項目中にユーザとの対話処理が規定されている場合、ユーザに対して入力を求める画面を表示し、ユーザにより入力された値に基づき診断を行う手段を有することを特徴とする。
【００２１】
第３の発明は、前記第１または第２の発明において、前記各エージェントは、経路情報の観測結果を一定期間保管している履歴ＤＢと、前記障害解析・推論エンジンから指示があった場合、前記履歴ＤＢを参照しながら一定期間保管されている経路情報を解析し、経路情報の安定性を前記障害解析・推論エンジンに返答するネットワーク品質解析モジュールと、を有することを特徴とする。
【００２２】
第４の発明は、自律システムが複数相互接続された広域網上に複数のエージェントを配置し、前記広域網で発生した障害の検知と解析を自動的に行うネットワーク管理方法であって、前記各エージェントはエージェント間通信モジュールと障害解析・推論エンジンとを有し、前記エージェント間通信モジュールが、前記広域網上に配置された複数の他のエージェントとの協調動作を通じて広域網の状態に関する情報を多地点から収集するエージェント間通信ステップと、障害解析・推論エンジンが、前記エージェント間通信ステップで取得した広域網の情報と自エージェント中に含まれる診断知識を用いて広域網上で発生している現象の原因を含む推測を行い、推測した内容の正否を複数の診断項目を調査することにより判定する障害解析・推論ステップと、を有し、前記障害解析・推論ステップは、判定の導出に利用する診断項目の種類および実行順序をユーザとの対話的処理を通じて変更する対話ステップと、前記対話ステップによりユーザが変更した診断項目および実行順序に基づき判定処理を再実行する再実行ステップと、を有することを特徴とする。
【発明の効果】
【００２３】
本発明により、診断項目の種類および実行順序を容易に変更でき、また定性的な判断が必要な診断項目を実行する場合等にユーザが判定結果を手動で投入することができるので、既知の問題に対する診断のカスタマイズができ、また診断知識が用意されていない未知の障害に対しても適切な診断を実行することができる。また、経路情報のフラッピングやバーストのような経路情報の安定性（品質）を診断することでトラヒック障害の原因を推定することが可能である。
【発明を実施するための最良の形態】
【００２４】
本発明の実施形態のネットワーク管理システムは、ネットワークの複数の地点に配置されたエージェントの集合によって構成される。実際にネットワーク上にどのようにエージェントを配置するかは検出・診断すべき問題の種類やネットワークの構成によって異なる。個々のエージェントは以下のモジュールから構成される。
【００２５】
図３にエージェントの構成図を示す。３０１はインターネット上に配置された複数の他のエージェントとの協調動作を通じてインターネットの状態に関する情報を多地点から収集するエージェント間通信モジュールであり、３０２はネットワーク機器との間の通信を行うネットワーク機器間通信モジュールであり、３０３はエージェント間通信モジュールが取得したインターネットの情報と自エージェント中に含まれる診断知識を用いて広域網上で発生している現象の原因を含む推測を行い、推測した内容の正否を複数の診断項目を調査することにより判定する障害解析・推論エンジンであり、３０４は障害解析・推論エンジン３０３が使用する診断知識ＤＢであり、３０５はネットワークの品質を解析するネットワーク品質解析モジュールであり、３０６は経路情報の観測結果を一定期間保管している履歴ＤＢであり、３０７はオペレータ（ネットワーク管理者）と障害解析・推論エンジン３０３との対話インタフェースであるオペレータ対話インタフェースである。
【００２６】
上記のうち、エージェント間通信モジュール３０１、ネットワーク機器間通信モジュール３０２、診断知識ＤＢ３０４については既存の技術（例えば特許文献１記載の技術）を利用することで実現できる。また、障害解析・推論エンジン３０３についても、従来技術と共通する障害診断・推論技術に関しては、既存の技術（例えば特許文献１記載の技術）を利用することで実現できる。
【００２７】
本実施形態の障害解析・推論エンジン３０３は、従来の障害解析・推論エンジンと共通する障害診断・推論を行う手段のほかに、判定の導出に利用する診断項目の種類および実行順序をユーザとの対話的処理を通じて変更する対話手段（図示していない）と、対話手段によりユーザが変更した診断項目および実行順序に基づき判定処理を再実行する再実行手段（図示していない）と、を有している。障害解析・推論エンジン３０３は、これらの手段により、オペレータ対話インタフェース３０７を通じてユーザ（ネットワーク管理者）と対話処理を行い、それにより変更された診断項目および実行順序に基づき判定処理を再実行する。また、障害解析・推論エンジン３０３は、診断項目中にユーザとの対話処理が規定されている場合、オペレータ対話インタフェース３０７を通じて、ユーザに対して入力を求める画面を表示し、ユーザにより入力された値（例えば「ネットワークの接続速度が十分に速い」といった入力データ）に基づき診断を行う手段（図示していない）を有する。これらにより、診断項目の種類および実行順序を容易に変更でき、また定性的な判断が必要な診断項目を実行する場合等にユーザが判定結果を手動で投入することができるので、既知の問題に対する診断のカスタマイズができ、また診断知識が用意されていない未知の障害に対しても適切な診断を実行することができる。
【００２８】
ネットワーク品質解析モジュール３０５は、障害解析・推論エンジン３０３から指示があった場合、経路情報の観測結果を一定期間（例えば、１０分、１時間、１日等）保管している履歴ＤＢ３０６を参照しながら一定期間保管されている経路情報を解析し、経路情報の安定性（品質）を障害解析・推論エンジン３０３に返答する手段を有する。これにより、経路情報のフラッピングやバーストのような経路情報の安定性（品質）を診断することでトラヒック障害の原因を推定することが可能である。
【実施例】
【００２９】
自ＡＳからインターネット上の特定のサーバへの接続が不安定（接続できる状態と接続できない状態が頻繁に変化している）場合を例に取り、本発明による診断手順の実施例を説明する。
【００３０】
１．本発明においても事前の情報収集および障害に対する仮説の設定は従来技術と同様の方法で行う。この部分の処理内容については背景技術の項に記載した１ステップから４ステップまでを参照のこと。
【００３１】
２．エージェント中の障害解析・推論エンジン３０３は診断知識ＤＢ３０４中の障害判定用知識と観測した情報を照らし合わせることでサーバの接続性が不安定になっていることを検知したとし、同じく診断知識を元に「サーバ自身か経路情報の安定性に異常がある」という仮説を立てたものとする。
【００３２】
３．次に、当該エージェント中の障害解析・推論エンジン３０３はこの仮説を検証するために実行すべき診断項目の集合および実行順序を導出する。この集合は各「仮説」に関する知識として診断知識ＤＢ３０４にあらかじめ組み込まれている。この診断項目の定義例（一部）を以下に示す。なお、この知識はＬｉｓｐ言語で記述されている。最初の４行について、←の後に各行についての説明を記載した。
;; 診断項目: BGP 経路が広報されているか ←コメント
(def-rule BGP-advertised () ←ルールの定義
(acquire (check-bgp-as-path)) ←記載された関数を実行
(eval (BGP-advertised acq-result))) ←関数の実行結果を評価し、本項目の結果とする
;; 診断項目: BGP経路が10分前に広報されていたか
(def-rule BGP-advertised-10min-ago ()
(acquire (check-bgp-as-path-10min-ago))
(eval (BGP-advertised acq-result)))
;; 診断項目: HTTP GET の返答が時間内にあったか
(def-rule HTTP-GET-in-time ()
(acquire (HTTP-GET-check))
(eval (HTTP-GET-in-time acq-result)))
;; 診断項目: HTTP GET の戻り値が200 であったか
(def-rule HTTP-GET-status-200 ()
(acquire (HTTP-GET-check))
(eval (HTTP-GET-status-200 acq-result)))
その他考えられる診断項目の例を図４の表１に示す。
【００３３】
４．障害解析・推論エンジン３０３は３で導出した診断項目を規定された順番に実行する。この例ではサーバとの接続性が失われた場合は、まずインターネットプロトコルの下位レイヤでの接続性から始めて上位レイヤでの接続性を順番に検証するのが通常行われる作業手順であるので、この例ではＡＳ間で経路情報が正しく伝搬されているかを他エージェントとの協調によって診断する処理が最初に選択されるように知識に記述されていたものとする。そして再び診断知識の記述に従い、個々の項目の診断結果によって次に行うべき診断項目を導出して順番に実行する。
【００３４】
５．この例では、前ステップ、つまりＢＧＰにおける経路情報の到達性には問題がなかったとし、次の診断項目を実行する。このとき、最初の診断項目であるＡＳ間の経路情報の到達性で問題が発見されれば上位レイヤにおける診断を行う必要はないので経路伝搬障害という診断結果をオペレータに提示して診断を終了する。
【００３５】
６．診断項目を実行する過程では任意の時点でユーザの対話処理を行うことが可能である。この対話処理はオペレータ対話インタフェース３０７を通じて実行される。オペレータ対話インタフェース３０７ではあらかじめ知識に記述された時点で必要な画面表示やユーザからの入力を受信する処理を行う。これにより例えば「ネットワークの接続速度が十分に速いか」といった定性的な判断が必要な診断項目を実行する場合にユーザ自身が判定結果を手動で投入することができる。
【００３６】
７．指定された診断項目を実行した後、検証結果を障害解析・推論エンジン３０３からユーザ（ネットワーク管理者）に提示する。この例では残りの診断項目の調査結果もすべて正常であったものとする。そのためエージェントは接続性に異常がない旨および判定に利用したすべての診断項目および調査結果をユーザに提示する。
【００３７】
８．しかし、ユーザは接続が安定していないことを認識しているため、診断を再実行するためにオペレータ対話インタフェース３０７を通じて診断の再実行処理を開始する。ここでの対話処理では実行された診断項目を任意に選択してその時点からの再実行や知識により選択された診断項目とは別の診断項目を選択して実行したりすることができる。この例では、ユーザが経路情報の到達性の診断を最初からやり直すと共に安定性診断を追加して行うことを指示したとする。
【００３８】
９．エージェントはユーザからの指示に従い経路情報の到達性を検証して再度問題がないことを確認するが、ユーザの指示により経路情報の安定性の検証が要求されているので安定性を診断する診断項目を実行する。この安定性の検証はネットワーク品質解析モジュール３０５および履歴ＤＢ３０６により行われる。この例では、ネットワーク上で経路のフラッピングという障害が発生しており、エージェントは安定性の検証によりこの現象が生じていることを検知できたものとする。具体的なフラッピングの検出手順を以下に示す。
【００３９】
（ａ）経路情報のフラッピングとは、短期間において同一の経路に対する変更が頻繁に起こる現象のことを言う。経路情報の変更はルータの負荷を増大させるため、変更が頻繁に起こるとルータが過負荷になり結果としてインターネット全体の接続不良等の障害を引き起こす。
【００４０】
（ｂ）フラッピングはその定義より明らかなとおり、ある程度の期間継続して経路情報を観測してその変更の頻度などを観測しないと判定できない。そのため、単一の測定を繰り返すだけではフラッピングを検出することは難しい。そのため、本実施例では経路情報の観測結果を履歴ＤＢ３０６に格納して一定期間保管する。
【００４１】
（ｃ）診断の過程においてフラッピングの有無を検証するよう障害解析・推論エンジン３０３からネットワーク品質解析モジュール３０５に指示があった場合、ネットワーク品質解析モジュール３０５は履歴ＤＢ３０６を参照しながら経路情報の変更の頻度を解析する。
【００４２】
（ｄ）この変更の頻度があらかじめ定義された閾値より上回っている場合はネットワーク品質解析モジュール３０５はフラッピングが発生しているものとみなし、その旨障害解析・推論エンジン３０３に返答を行う。
【００４３】
１０．エージェントはフラッピングの発生、すなわち経路伝搬における安定性に異常があったのでユーザにその旨を通知する。
【００４４】
１１．以上により、ユーザ（ネットワーク管理者）は生じている接続の不安定性が経路情報のフラッピングによるものと認識できる。
【００４５】
図５に本実施例の各エージェントの診断手順のフローチャートを示す。診断項目の抽出４０１より前の処理については図１の１０１〜１０３と同じである。すなわち、図１に示すように、エージェントはネットワーク機器、他のエージェントから情報を収集し（１０１）、現在の状態は障害の可能性があるかどうかを判断し、障害の可能性がない場合は、ステップ１０１に戻り（１０２）、障害の可能性がある場合は、診断知識を用いて、診断「仮説」を作成する（１０３）。次に、図５に示すように、診断項目を抽出し（４０１）、診断項目を実行する（４０２）。診断項目中にユーザ（ネットワーク管理者）との対話処理が規定されているかどうかを判断し（４０３）、規定されていない場合はそのままステップ４０５に進む。診断項目中にユーザとの対話処理が規定されている場合は、ユーザに対して入力を求める画面を表示し、ユーザにより入力された値（例えば「ネットワークの接続速度が十分に速い」といった入力データ）に基づき診断を行い（４０４）、ステップ４０５に進む。ステップ４０５では、実行すべき診断項目があるかどうかを判断し、ある場合はステップ４０２に戻る。ステップ４０５で、実行すべき診断項目がない場合は、「仮説」の診断結果およびプロセスをユーザに提示する（４０６）。ステップ４０９では、ユーザから診断の再実行の指示があったかどうかを判断する。再実行の指示があった場合は、「仮説」の検証結果中の、指定された診断項目から「仮説」検証を再実行し（４０７）、ステップ４０５に戻る。再実行の指示がない場合は、未検証の「仮説」があるかどうかを判断し（４１０）、ある場合はステップ４０１に戻り、ない場合は、全「仮説」の検証結果をユーザに通知する。
【００４６】
以上、本発明者によってなされた発明を、前記実施例に基づき具体的に説明したが、本発明は、前記実施例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは勿論である。
【図面の簡単な説明】
【００４７】
【図１】従来技術におけるエージェントの診断手順のフローチャートである。
【図２】従来技術におけるエージェントの協調による診断事例を示す図である。
【図３】本発明の実施形態のエージェントの構成図を示す図である。
【図４】表１：診断項目例を示す図である。
【図５】本発明の実施例の診断手順のフローチャートである。
【符号の説明】
【００４８】
３０１…エージェント間通信モジュール、３０２…ネットワーク機器間通信モジュール、３０３…障害解析・推論エンジン、３０４…診断知識ＤＢ、３０５…ネットワーク品質解析モジュール、３０６…履歴ＤＢ、３０７…オペレータ対話インタフェース
【技術分野】
【０００１】
本発明は単一組織等が管理する自律システム（Autonomous System、ＡＳ）が複数相互接続された広域網（例えばインターネット）において、広域網で発生した障害の検知と解析を自動的に行うことにより広域網の安定運用を可能とするネットワーク管理システムおよび方法に関するものである。
【背景技術】
【０００２】
インターネットは複数のルータ、ＬＡＮ、より広域では複数のＡＳ（Autonomous System）から成る広がりを持つ分散システムとして考えられる。このように中央集権的な管理機構を持たないインターネットにおいては、その管理、制御は個々のネットワークを管理する組織の管理者によって行われている。しかし、ＡＳ間の経路障害などの広範囲に渡る問題への対処や管理制御においては単一の箇所からの観測のみでは原因およびその発生箇所を特定するのが非常に難しく複数のネットワークの管理者同士の協調が不可欠である。このような人間同士の協調は電話などのｌｅｇａｃｙなメディアで行われることも多いため、時間とコストがかかり、結果として問題の解決を難しくしていた。
【０００３】
このような問題に対処するためにネットワーク上に配置された複数のコンピュータプログラム（以下、エージェント）の協調によりＡＳ間経路障害の診断、検知を迅速に行う診断システム（以下、ＥＮＣＯＲＥ（Inter-AS Diagnostic Ensemble System using Cooperative Reflector Agents））が提案されている（本出願人による特許文献１参照）。ＥＮＣＯＲＥ中のエージェント（以下、ＥＮＣＯＲＥエージェント）は障害診断の手順などに関する診断知識を持ち、各ＥＮＣＯＲＥエージェントはその知識に基づき必要な情報の観測、他のＥＮＣＯＲＥエージェントとの協調などの動作を随時選択しながら、従来は人間同士の協調により行っていたＡＳ間経路障害の診断を行う。
【０００４】
以下、前記ＥＮＣＯＲＥを例にして従来のエージェントを用いたネットワーク管理システムの動作の概略を説明する。
【０００５】
１．ネットワークの複数の地点にエージェントを配置する。ここで、実際のエージェントの配置はエージェントにより検出・診断すべき問題の種類やネットワークの構成によって異なる。例えばＥＮＣＯＲＥはインターネットの構成単位であるＡＳ（Autonomous System）間での経路障害の診断を主な目的としているので各ＡＳ毎に少なくとも１つのエージェントを配置することを前提としている。そのため、ここでもＡＳ毎にエージェントが配置されているものとして説明を行う。
【０００６】
２．各エージェントはネットワーク内のルータなどのネットワーク機器と適切に通信を行いネットワークの情報を定期的に収集する。例えば、ＡＳ間経路障害の診断のためには、ＡＳ間で経路情報の交換を実際に行っているルータと通信を行いＡＳ間で伝搬されている経路情報の監視を行う。具体的にどの情報をどこから集めるかといった具体的な手順に関してはすべて診断知識あるいはエージェントの設定情報に含まれているものとする。
【０００７】
３．各エージェントは他のＡＳに配置されているエージェントとネットワーク情報の交換を行うことがある。これは、分散システムであるインターネットにおいては、ある地点（ＡＳ）から観測できるネットワーク情報は部分的なものに限られる特性があるからである。例えばあるＡＳから広報された経路情報は複数のＡＳによって適宜修正をされながらインターネット全体に伝搬されていくが、このときどのＡＳを通って伝搬されているか、別のＡＳによって経路情報にどのような修正が施されているかは当該ＡＳからは観測できないため、他ＡＳのエージェントの観測結果を利用するほかない。前ステップと同様にどの情報をどのエージェントと交換するといった具体的な手順は診断知識あるいはエージェントの設定情報に含まれているものとする。
【０００８】
４．各エージェントは自分自身で収集したネットワーク情報の解析結果と診断知識に基づきネットワークにおいて何らかの障害が発生していないかを監視する。エージェントが障害や異常が発生していないと判定した場合はステップ２に戻りネットワーク情報の収集および解析を繰り返す。
【０００９】
５．ステップ４での解析の結果、ＥＮＣＯＲＥ中のあるエージェントが何らかの障害の可能性があると判定した場合、当該エージェントは診断知識を用いてどのような異常・不具合が起きているか、原因は何か、ネットワーク上のどの場所で異常が発生しているかなど障害の詳細を推測することを試みる。この推論の手順の概略を以下に示す。
【００１０】
（ａ）障害の可能性を検知したエージェントは収集したネットワーク情報の解析結果と診断知識中の障害判定用知識を利用して、可能性のある障害を抽出し、診断のための「仮説」を立てる。例えば、「特定のサーバに一定時間接続不能であればサーバに障害が起きている可能性がある」などが「仮説」の例である。
（ｂ）前ステップにおいて設定した「仮説」を検証する。ＥＮＣＯＲＥにおける診断知識中には個々の「仮説」が成立するために検証すべき診断項目の集合およびそれらの実行順序があらかじめ規定されている。ただし、実際に実行される項目およびその順序は各診断項目の結果に依存して変化するため、診断の状況によって動的に変化する。また、「仮説」と診断項目との間にも依存関係が存在し、特定の診断項目の正否によって新たな検証すべき「仮説」が成立するということもある。
（ｃ）すべての「仮説」を検証した結果がエージェントによる推論結果となる。
【００１１】
６．以上の手順によりエージェントが得た推論の結果はメールなどの手段を通じてネットワーク管理者に通知される。
【００１２】
図１にＥＮＣＯＲＥにおける各エージェントの診断手順のフローチャートを示す。図１に示すように、エージェントはネットワーク機器、他のエージェントから情報を収集し（１０１）、現在の状態は障害の可能性があるかどうかを判断し（１０２）、障害の可能性がない場合は、ステップ１０１に戻る。障害の可能性がある場合は、診断知識を用いて、診断「仮説」を作成し（１０３）、診断項目の抽出を行い（１０４）、診断項目を実行する（１０５）。実行すべき診断項目がある場合はステップ１０５に戻る。実行すべき診断項目がなければ、未検証の「仮説」があるかどうか判断し（１０７）、ある場合はステップ１０４に戻る。未検証の「仮説」がない場合は、全「仮説」の検証結果をユーザ（ネットワーク管理者）に通知する（１０８）。
【００１３】
ＥＮＣＯＲＥシステムを用いてエージェントの協調によりＡＳ間での経路障害の原因が診断される例を図２を用いて示す。
【００１４】
図中において、ＡＳｓｅｌｆから広報された経路情報はＡＳ１、ＡＳ２あるいはＡＳ３を経由してＡＳ４に伝搬されるものとする。ここで、ＡＳ１とＡＳ２との間でＡＳｓｅｌｆに関するフィルタの設定に誤りが発生して、ＡＳｓｅｌｆに関する経路情報がＡＳ２に流れなくなった状況を想定する。この状況では診断知識より「ＡＳ１、ＡＳ２間の物理的接続の障害が発生した」あるいは「ＡＳ２の経路フィルタの設定誤りにより経路情報が破棄されている」という仮説が成立するものとする。これらの仮説を検証するためにＡＳｓｅｌｆ中のエージェントＲｓｅｌｆはＡＳ１、ＡＳ２のエージェントＲ１、Ｒ２と通信し、それぞれのＡＳにおいて観測された経路情報を送り返してもらう。その結果、ＡＳ１では自分が広報した経路情報が存在するのに対し、ＡＳ２ではＡＳ１の経路情報はあっても自分の経路情報が含まれていないことを認識する。以上より、２つめの仮説が成立することが分かりＡＳｓｅｌｆではＡＳ１とＡＳ２間でＡＳｓｅｌｆの経路情報に関するフィルタの設定に誤りがあるということが推論できる。
【００１５】
【特許文献１】特許第３４８５７８９号公報
【発明の開示】
【発明が解決しようとする課題】
【００１６】
ＥＮＣＯＲＥは診断知識の種類や内容をユーザが拡充することにより経路情報の伝搬障害以外の障害への対応が容易に行える高い拡張性を有している。しかし、現行のＥＮＣＯＲＥではＥＮＣＯＲＥエージェント内に保存する診断知識はネットワーク管理者の持つ過去の経験や知識に基づいてあらかじめ作成されエージェントの動作以前にエージェント中に組み込む必要がある。しかし、ネットワークにおいて発生する障害はその原因や障害内容が多岐に渡るため、すべての障害に対応できるようにあらかじめ診断知識を作っておくことは不可能である。そのため、現実的にはＥＮＣＯＲＥは限られた障害に対する診断知識しか持ち得ず、ＥＮＣＯＲＥの運用中に診断知識が対象としていない未知の障害が発生した場合は十分な診断ができない可能性がある。
【００１７】
本発明の目的は、既知の問題に対する診断のカスタマイズができ、診断知識が用意されていない未知の障害に対しても適切な診断を実行することができる技術を提供することにある。
【課題を解決するための手段】
【００１８】
本明細書において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
【００１９】
第１の発明は、自律システムが複数相互接続された広域網上に複数のエージェントを配置し、前記広域網で発生した障害の検知と解析を自動的に行うネットワーク管理システムであって、前記各エージェントは、前記広域網上に配置された複数の他のエージェントとの協調動作を通じて広域網の状態に関する情報を多地点から収集するエージェント間通信モジュールと、前記エージェント間通信モジュールが取得した広域網の情報と自エージェント中に含まれる診断知識を用いて広域網上で発生している現象の原因を含む推測を行い、推測した内容の正否を複数の診断項目を調査することにより判定する障害解析・推論エンジンと、を有し、前記障害解析・推論エンジンは、判定の導出に利用する診断項目の種類および実行順序をユーザとの対話的処理を通じて変更する対話手段と、前記対話手段によりユーザが変更した診断項目および実行順序に基づき判定処理を再実行する再実行手段と、を有することを特徴とする。
【００２０】
第２の発明は、前記第１の発明において、前記障害解析・推論エンジンは、診断項目中にユーザとの対話処理が規定されている場合、ユーザに対して入力を求める画面を表示し、ユーザにより入力された値に基づき診断を行う手段を有することを特徴とする。
【００２１】
第３の発明は、前記第１または第２の発明において、前記各エージェントは、経路情報の観測結果を一定期間保管している履歴ＤＢと、前記障害解析・推論エンジンから指示があった場合、前記履歴ＤＢを参照しながら一定期間保管されている経路情報を解析し、経路情報の安定性を前記障害解析・推論エンジンに返答するネットワーク品質解析モジュールと、を有することを特徴とする。
【００２２】
第４の発明は、自律システムが複数相互接続された広域網上に複数のエージェントを配置し、前記広域網で発生した障害の検知と解析を自動的に行うネットワーク管理方法であって、前記各エージェントはエージェント間通信モジュールと障害解析・推論エンジンとを有し、前記エージェント間通信モジュールが、前記広域網上に配置された複数の他のエージェントとの協調動作を通じて広域網の状態に関する情報を多地点から収集するエージェント間通信ステップと、障害解析・推論エンジンが、前記エージェント間通信ステップで取得した広域網の情報と自エージェント中に含まれる診断知識を用いて広域網上で発生している現象の原因を含む推測を行い、推測した内容の正否を複数の診断項目を調査することにより判定する障害解析・推論ステップと、を有し、前記障害解析・推論ステップは、判定の導出に利用する診断項目の種類および実行順序をユーザとの対話的処理を通じて変更する対話ステップと、前記対話ステップによりユーザが変更した診断項目および実行順序に基づき判定処理を再実行する再実行ステップと、を有することを特徴とする。
【発明の効果】
【００２３】
本発明により、診断項目の種類および実行順序を容易に変更でき、また定性的な判断が必要な診断項目を実行する場合等にユーザが判定結果を手動で投入することができるので、既知の問題に対する診断のカスタマイズができ、また診断知識が用意されていない未知の障害に対しても適切な診断を実行することができる。また、経路情報のフラッピングやバーストのような経路情報の安定性（品質）を診断することでトラヒック障害の原因を推定することが可能である。
【発明を実施するための最良の形態】
【００２４】
本発明の実施形態のネットワーク管理システムは、ネットワークの複数の地点に配置されたエージェントの集合によって構成される。実際にネットワーク上にどのようにエージェントを配置するかは検出・診断すべき問題の種類やネットワークの構成によって異なる。個々のエージェントは以下のモジュールから構成される。
【００２５】
図３にエージェントの構成図を示す。３０１はインターネット上に配置された複数の他のエージェントとの協調動作を通じてインターネットの状態に関する情報を多地点から収集するエージェント間通信モジュールであり、３０２はネットワーク機器との間の通信を行うネットワーク機器間通信モジュールであり、３０３はエージェント間通信モジュールが取得したインターネットの情報と自エージェント中に含まれる診断知識を用いて広域網上で発生している現象の原因を含む推測を行い、推測した内容の正否を複数の診断項目を調査することにより判定する障害解析・推論エンジンであり、３０４は障害解析・推論エンジン３０３が使用する診断知識ＤＢであり、３０５はネットワークの品質を解析するネットワーク品質解析モジュールであり、３０６は経路情報の観測結果を一定期間保管している履歴ＤＢであり、３０７はオペレータ（ネットワーク管理者）と障害解析・推論エンジン３０３との対話インタフェースであるオペレータ対話インタフェースである。
【００２６】
上記のうち、エージェント間通信モジュール３０１、ネットワーク機器間通信モジュール３０２、診断知識ＤＢ３０４については既存の技術（例えば特許文献１記載の技術）を利用することで実現できる。また、障害解析・推論エンジン３０３についても、従来技術と共通する障害診断・推論技術に関しては、既存の技術（例えば特許文献１記載の技術）を利用することで実現できる。
【００２７】
本実施形態の障害解析・推論エンジン３０３は、従来の障害解析・推論エンジンと共通する障害診断・推論を行う手段のほかに、判定の導出に利用する診断項目の種類および実行順序をユーザとの対話的処理を通じて変更する対話手段（図示していない）と、対話手段によりユーザが変更した診断項目および実行順序に基づき判定処理を再実行する再実行手段（図示していない）と、を有している。障害解析・推論エンジン３０３は、これらの手段により、オペレータ対話インタフェース３０７を通じてユーザ（ネットワーク管理者）と対話処理を行い、それにより変更された診断項目および実行順序に基づき判定処理を再実行する。また、障害解析・推論エンジン３０３は、診断項目中にユーザとの対話処理が規定されている場合、オペレータ対話インタフェース３０７を通じて、ユーザに対して入力を求める画面を表示し、ユーザにより入力された値（例えば「ネットワークの接続速度が十分に速い」といった入力データ）に基づき診断を行う手段（図示していない）を有する。これらにより、診断項目の種類および実行順序を容易に変更でき、また定性的な判断が必要な診断項目を実行する場合等にユーザが判定結果を手動で投入することができるので、既知の問題に対する診断のカスタマイズができ、また診断知識が用意されていない未知の障害に対しても適切な診断を実行することができる。
【００２８】
ネットワーク品質解析モジュール３０５は、障害解析・推論エンジン３０３から指示があった場合、経路情報の観測結果を一定期間（例えば、１０分、１時間、１日等）保管している履歴ＤＢ３０６を参照しながら一定期間保管されている経路情報を解析し、経路情報の安定性（品質）を障害解析・推論エンジン３０３に返答する手段を有する。これにより、経路情報のフラッピングやバーストのような経路情報の安定性（品質）を診断することでトラヒック障害の原因を推定することが可能である。
【実施例】
【００２９】
自ＡＳからインターネット上の特定のサーバへの接続が不安定（接続できる状態と接続できない状態が頻繁に変化している）場合を例に取り、本発明による診断手順の実施例を説明する。
【００３０】
１．本発明においても事前の情報収集および障害に対する仮説の設定は従来技術と同様の方法で行う。この部分の処理内容については背景技術の項に記載した１ステップから４ステップまでを参照のこと。
【００３１】
２．エージェント中の障害解析・推論エンジン３０３は診断知識ＤＢ３０４中の障害判定用知識と観測した情報を照らし合わせることでサーバの接続性が不安定になっていることを検知したとし、同じく診断知識を元に「サーバ自身か経路情報の安定性に異常がある」という仮説を立てたものとする。
【００３２】
３．次に、当該エージェント中の障害解析・推論エンジン３０３はこの仮説を検証するために実行すべき診断項目の集合および実行順序を導出する。この集合は各「仮説」に関する知識として診断知識ＤＢ３０４にあらかじめ組み込まれている。この診断項目の定義例（一部）を以下に示す。なお、この知識はＬｉｓｐ言語で記述されている。最初の４行について、←の後に各行についての説明を記載した。
;; 診断項目: BGP 経路が広報されているか ←コメント
(def-rule BGP-advertised () ←ルールの定義
(acquire (check-bgp-as-path)) ←記載された関数を実行
(eval (BGP-advertised acq-result))) ←関数の実行結果を評価し、本項目の結果とする
;; 診断項目: BGP経路が10分前に広報されていたか
(def-rule BGP-advertised-10min-ago ()
(acquire (check-bgp-as-path-10min-ago))
(eval (BGP-advertised acq-result)))
;; 診断項目: HTTP GET の返答が時間内にあったか
(def-rule HTTP-GET-in-time ()
(acquire (HTTP-GET-check))
(eval (HTTP-GET-in-time acq-result)))
;; 診断項目: HTTP GET の戻り値が200 であったか
(def-rule HTTP-GET-status-200 ()
(acquire (HTTP-GET-check))
(eval (HTTP-GET-status-200 acq-result)))
その他考えられる診断項目の例を図４の表１に示す。
【００３３】
４．障害解析・推論エンジン３０３は３で導出した診断項目を規定された順番に実行する。この例ではサーバとの接続性が失われた場合は、まずインターネットプロトコルの下位レイヤでの接続性から始めて上位レイヤでの接続性を順番に検証するのが通常行われる作業手順であるので、この例ではＡＳ間で経路情報が正しく伝搬されているかを他エージェントとの協調によって診断する処理が最初に選択されるように知識に記述されていたものとする。そして再び診断知識の記述に従い、個々の項目の診断結果によって次に行うべき診断項目を導出して順番に実行する。
【００３４】
５．この例では、前ステップ、つまりＢＧＰにおける経路情報の到達性には問題がなかったとし、次の診断項目を実行する。このとき、最初の診断項目であるＡＳ間の経路情報の到達性で問題が発見されれば上位レイヤにおける診断を行う必要はないので経路伝搬障害という診断結果をオペレータに提示して診断を終了する。
【００３５】
６．診断項目を実行する過程では任意の時点でユーザの対話処理を行うことが可能である。この対話処理はオペレータ対話インタフェース３０７を通じて実行される。オペレータ対話インタフェース３０７ではあらかじめ知識に記述された時点で必要な画面表示やユーザからの入力を受信する処理を行う。これにより例えば「ネットワークの接続速度が十分に速いか」といった定性的な判断が必要な診断項目を実行する場合にユーザ自身が判定結果を手動で投入することができる。
【００３６】
７．指定された診断項目を実行した後、検証結果を障害解析・推論エンジン３０３からユーザ（ネットワーク管理者）に提示する。この例では残りの診断項目の調査結果もすべて正常であったものとする。そのためエージェントは接続性に異常がない旨および判定に利用したすべての診断項目および調査結果をユーザに提示する。
【００３７】
８．しかし、ユーザは接続が安定していないことを認識しているため、診断を再実行するためにオペレータ対話インタフェース３０７を通じて診断の再実行処理を開始する。ここでの対話処理では実行された診断項目を任意に選択してその時点からの再実行や知識により選択された診断項目とは別の診断項目を選択して実行したりすることができる。この例では、ユーザが経路情報の到達性の診断を最初からやり直すと共に安定性診断を追加して行うことを指示したとする。
【００３８】
９．エージェントはユーザからの指示に従い経路情報の到達性を検証して再度問題がないことを確認するが、ユーザの指示により経路情報の安定性の検証が要求されているので安定性を診断する診断項目を実行する。この安定性の検証はネットワーク品質解析モジュール３０５および履歴ＤＢ３０６により行われる。この例では、ネットワーク上で経路のフラッピングという障害が発生しており、エージェントは安定性の検証によりこの現象が生じていることを検知できたものとする。具体的なフラッピングの検出手順を以下に示す。
【００３９】
（ａ）経路情報のフラッピングとは、短期間において同一の経路に対する変更が頻繁に起こる現象のことを言う。経路情報の変更はルータの負荷を増大させるため、変更が頻繁に起こるとルータが過負荷になり結果としてインターネット全体の接続不良等の障害を引き起こす。
【００４０】
（ｂ）フラッピングはその定義より明らかなとおり、ある程度の期間継続して経路情報を観測してその変更の頻度などを観測しないと判定できない。そのため、単一の測定を繰り返すだけではフラッピングを検出することは難しい。そのため、本実施例では経路情報の観測結果を履歴ＤＢ３０６に格納して一定期間保管する。
【００４１】
（ｃ）診断の過程においてフラッピングの有無を検証するよう障害解析・推論エンジン３０３からネットワーク品質解析モジュール３０５に指示があった場合、ネットワーク品質解析モジュール３０５は履歴ＤＢ３０６を参照しながら経路情報の変更の頻度を解析する。
【００４２】
（ｄ）この変更の頻度があらかじめ定義された閾値より上回っている場合はネットワーク品質解析モジュール３０５はフラッピングが発生しているものとみなし、その旨障害解析・推論エンジン３０３に返答を行う。
【００４３】
１０．エージェントはフラッピングの発生、すなわち経路伝搬における安定性に異常があったのでユーザにその旨を通知する。
【００４４】
１１．以上により、ユーザ（ネットワーク管理者）は生じている接続の不安定性が経路情報のフラッピングによるものと認識できる。
【００４５】
図５に本実施例の各エージェントの診断手順のフローチャートを示す。診断項目の抽出４０１より前の処理については図１の１０１〜１０３と同じである。すなわち、図１に示すように、エージェントはネットワーク機器、他のエージェントから情報を収集し（１０１）、現在の状態は障害の可能性があるかどうかを判断し、障害の可能性がない場合は、ステップ１０１に戻り（１０２）、障害の可能性がある場合は、診断知識を用いて、診断「仮説」を作成する（１０３）。次に、図５に示すように、診断項目を抽出し（４０１）、診断項目を実行する（４０２）。診断項目中にユーザ（ネットワーク管理者）との対話処理が規定されているかどうかを判断し（４０３）、規定されていない場合はそのままステップ４０５に進む。診断項目中にユーザとの対話処理が規定されている場合は、ユーザに対して入力を求める画面を表示し、ユーザにより入力された値（例えば「ネットワークの接続速度が十分に速い」といった入力データ）に基づき診断を行い（４０４）、ステップ４０５に進む。ステップ４０５では、実行すべき診断項目があるかどうかを判断し、ある場合はステップ４０２に戻る。ステップ４０５で、実行すべき診断項目がない場合は、「仮説」の診断結果およびプロセスをユーザに提示する（４０６）。ステップ４０９では、ユーザから診断の再実行の指示があったかどうかを判断する。再実行の指示があった場合は、「仮説」の検証結果中の、指定された診断項目から「仮説」検証を再実行し（４０７）、ステップ４０５に戻る。再実行の指示がない場合は、未検証の「仮説」があるかどうかを判断し（４１０）、ある場合はステップ４０１に戻り、ない場合は、全「仮説」の検証結果をユーザに通知する。
【００４６】
以上、本発明者によってなされた発明を、前記実施例に基づき具体的に説明したが、本発明は、前記実施例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは勿論である。
【図面の簡単な説明】
【００４７】
【図１】従来技術におけるエージェントの診断手順のフローチャートである。
【図２】従来技術におけるエージェントの協調による診断事例を示す図である。
【図３】本発明の実施形態のエージェントの構成図を示す図である。
【図４】表１：診断項目例を示す図である。
【図５】本発明の実施例の診断手順のフローチャートである。
【符号の説明】
【００４８】
３０１…エージェント間通信モジュール、３０２…ネットワーク機器間通信モジュール、３０３…障害解析・推論エンジン、３０４…診断知識ＤＢ、３０５…ネットワーク品質解析モジュール、３０６…履歴ＤＢ、３０７…オペレータ対話インタフェース
【特許請求の範囲】
【請求項１】
自律システムが複数相互接続された広域網上に複数のエージェントを配置し、前記広域網で発生した障害の検知と解析を自動的に行うネットワーク管理システムであって、
前記各エージェントは、
前記広域網上に配置された複数の他のエージェントとの協調動作を通じて広域網の状態に関する情報を多地点から収集するエージェント間通信モジュールと、
前記エージェント間通信モジュールが取得した広域網の情報と自エージェント中に含まれる診断知識を用いて広域網上で発生している現象の原因を含む推測を行い、推測した内容の正否を複数の診断項目を調査することにより判定する障害解析・推論エンジンと、
を有し、
前記障害解析・推論エンジンは、
判定の導出に利用する診断項目の種類および実行順序をユーザとの対話的処理を通じて変更する対話手段と、
前記対話手段によりユーザが変更した診断項目および実行順序に基づき判定処理を再実行する再実行手段と、
を有することを特徴とするネットワーク管理システム。
【請求項２】
請求項１に記載のネットワーク管理システムであって、
前記障害解析・推論エンジンは、診断項目中にユーザとの対話処理が規定されている場合、ユーザに対して入力を求める画面を表示し、ユーザにより入力された値に基づき診断を行う手段を有することを特徴とするネットワーク管理システム。
【請求項３】
請求項１または２に記載のネットワーク管理システムであって、
前記各エージェントは、
経路情報の観測結果を一定期間保管している履歴ＤＢと、
前記障害解析・推論エンジンから指示があった場合、前記履歴ＤＢを参照しながら一定期間保管されている経路情報を解析し、経路情報の安定性を前記障害解析・推論エンジンに返答するネットワーク品質解析モジュールと、
を有することを特徴とするネットワーク管理システム。
【請求項４】
自律システムが複数相互接続された広域網上に複数のエージェントを配置し、前記広域網で発生した障害の検知と解析を自動的に行うネットワーク管理方法であって、
前記各エージェントはエージェント間通信モジュールと障害解析・推論エンジンとを有し、
前記エージェント間通信モジュールが、前記広域網上に配置された複数の他のエージェントとの協調動作を通じて広域網の状態に関する情報を多地点から収集するエージェント間通信ステップと、
障害解析・推論エンジンが、前記エージェント間通信ステップで取得した広域網の情報と自エージェント中に含まれる診断知識を用いて広域網上で発生している現象の原因を含む推測を行い、推測した内容の正否を複数の診断項目を調査することにより判定する障害解析・推論ステップと、
を有し、
前記障害解析・推論ステップは、
判定の導出に利用する診断項目の種類および実行順序をユーザとの対話的処理を通じて変更する対話ステップと、
前記対話ステップによりユーザが変更した診断項目および実行順序に基づき判定処理を再実行する再実行ステップと、
を有することを特徴とするネットワーク管理方法。
【請求項１】
自律システムが複数相互接続された広域網上に複数のエージェントを配置し、前記広域網で発生した障害の検知と解析を自動的に行うネットワーク管理システムであって、
前記各エージェントは、
前記広域網上に配置された複数の他のエージェントとの協調動作を通じて広域網の状態に関する情報を多地点から収集するエージェント間通信モジュールと、
前記エージェント間通信モジュールが取得した広域網の情報と自エージェント中に含まれる診断知識を用いて広域網上で発生している現象の原因を含む推測を行い、推測した内容の正否を複数の診断項目を調査することにより判定する障害解析・推論エンジンと、
を有し、
前記障害解析・推論エンジンは、
判定の導出に利用する診断項目の種類および実行順序をユーザとの対話的処理を通じて変更する対話手段と、
前記対話手段によりユーザが変更した診断項目および実行順序に基づき判定処理を再実行する再実行手段と、
を有することを特徴とするネットワーク管理システム。
【請求項２】
請求項１に記載のネットワーク管理システムであって、
前記障害解析・推論エンジンは、診断項目中にユーザとの対話処理が規定されている場合、ユーザに対して入力を求める画面を表示し、ユーザにより入力された値に基づき診断を行う手段を有することを特徴とするネットワーク管理システム。
【請求項３】
請求項１または２に記載のネットワーク管理システムであって、
前記各エージェントは、
経路情報の観測結果を一定期間保管している履歴ＤＢと、
前記障害解析・推論エンジンから指示があった場合、前記履歴ＤＢを参照しながら一定期間保管されている経路情報を解析し、経路情報の安定性を前記障害解析・推論エンジンに返答するネットワーク品質解析モジュールと、
を有することを特徴とするネットワーク管理システム。
【請求項４】
自律システムが複数相互接続された広域網上に複数のエージェントを配置し、前記広域網で発生した障害の検知と解析を自動的に行うネットワーク管理方法であって、
前記各エージェントはエージェント間通信モジュールと障害解析・推論エンジンとを有し、
前記エージェント間通信モジュールが、前記広域網上に配置された複数の他のエージェントとの協調動作を通じて広域網の状態に関する情報を多地点から収集するエージェント間通信ステップと、
障害解析・推論エンジンが、前記エージェント間通信ステップで取得した広域網の情報と自エージェント中に含まれる診断知識を用いて広域網上で発生している現象の原因を含む推測を行い、推測した内容の正否を複数の診断項目を調査することにより判定する障害解析・推論ステップと、
を有し、
前記障害解析・推論ステップは、
判定の導出に利用する診断項目の種類および実行順序をユーザとの対話的処理を通じて変更する対話ステップと、
前記対話ステップによりユーザが変更した診断項目および実行順序に基づき判定処理を再実行する再実行ステップと、
を有することを特徴とするネットワーク管理方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２００７−３００２４９（Ｐ２００７−３００２４９Ａ）
【公開日】平成１９年１１月１５日（２００７．１１．１５）
【国際特許分類】
【出願番号】特願２００６−１２４６１２（Ｐ２００６−１２４６１２）
【出願日】平成１８年４月２８日（２００６．４．２８）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成１９年１１月１５日（２００７．１１．１５）
【国際特許分類】
【出願日】平成１８年４月２８日（２００６．４．２８）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]