JP2007235897A - ネットワーク監視装置及び方法 - Google Patents

Abstract

【課題】 ネットワーク管理者を効果的に支援できるネットワーク監視ツールの提供。
【解決手段】 監視装置は、ネットワークにおいて動的に設定されるパケット転送経路の情報を収集する収集手段と、前記ネットワークの構成要素についてイベントが生じたことを示す通知を受信する受信手段と、前記収集手段により収集されたパケット転送経路の情報に基づいて、前記受信手段により受信された複数の通知の相関関係を分析する分析手段を備えており、ラベルスイッチパス等の動的に変化する論理パスについて生じるイベントを含めて、同一の原因から生じる複数のイベントを関連付けることができる。
【選択図】 図１

Description

本発明は、インターネット等のネットワークを監視する装置及び方法に係り、特に、当該ネットワークにおいて発生したイベントに起因して、関連するネットワーク構成要素についてのイベント通知が、連鎖的に多数受信される場合に、それらの間の相関関係を分析するための技術に関する。

ネットワーク管理者は、ネットワークの障害を早期に検出し、故障した部位の補修や交換等の適切な処置を行うために、通常、ネットワーク監視ツールを使用する。このツールでは、ネットワークを構成する多数のノード（ルータ、ゲートウェイ、ホスト、ターミナルサーバ、イーサネットスイッチ等のネットワーク機器）が、状態変化（イベント）を検出すると、そのイベント発生を示す通知を送信し、ネットワーク管理者のコンピュータ（監視装置）が、この通知を受信する。ここでいうイベントには、例えば、障害、障害の回復等がある。このようなイベント発生の通知は、例えば、ＳＮＭＰ（Simple Network Management Protocol）のマネージャプログラムを監視装置に搭載し、ＳＮＭＰエージェントプログラムをネットワーク内の必要なノードに常駐させる場合、ＳＮＭＰトラップにより実装することができる。他にも、ｓｙｓｌｏｇや、ＯＳＰＦ（Open Shortest Path First）、ＢＧＰ（Border Gateway Protocol）等の経路制御プロトコルの監視によっても、実装できる。

上記のようなネットワーク監視では、１つの障害によって複数の障害通知（アラーム）が発生する。例えば、ルータ内のボードが故障すると、ボードの障害通知だけではなく、そのボードに接続するポートの障害通知も送信され、１つの障害によって複数の障害通知が監視装置に到着する。そうすると、ネットワーク管理者（監視装置のユーザ）は、まずは、取り除くべき１つの障害がネットワークのどの部位に生じているのか、複数の障害通知の内容から推測しなければならず、この作業の負担は大きい。

上記の障害部位の特定を自動的に行う方法として、例えば、多数のアラームの発生履歴の同期性から相関のあるアラームをグループに分け、グループ化されたアラームの発生パターンとその中で発生事象に最も密接なアラームとを関連付ける学習を行っておき、既学習のパターンに該当する複数のアラームが発生したときには、事象に最も密接なアラームのみを選別し、他のアラームを抑制するという方法（特許文献１）が提案されている。また、ノード間で時刻同期ができていなくても相関関係を解析することができるように、多数のアラームを複数のカテゴリに分類し、一方のカテゴリに属するアラームが発生してから他のカテゴリに属するアラームが発生するまでの時間間隔を解析して、各アラームが発生する際の規則性を抽出することにより、多数のアラームから代表アラームを抽出するという方法（特許文献２）も提案されている。さらに、ネットワークの物理的接続や経験上の知識に基づいたアルゴリズム等を使用して、多数のアラーム間の関連付けを行い、問題の原因を見出す際、そのコリレーション処理を高速化する手法（特許文献３）も提案されている。

ネットワーク管理者は、また、ネットワークを運用しながら、その一部の動作を停止して、設定の変更やデバイスの追加、交換等の工事作業を実施する。この工事作業の実施は、上記のネットワーク監視ツールによって、障害として検出され、アラームが監視装置に受信される。そうすると、監視装置によりユーザ（ネットワーク管理者）に提示されるアラームには、計画的な工事によるものと、計画されたのではない障害発生によるものとが、区別されずに混在することになる。その場合、ネットワーク管理者は、前者については、対処する必要がないが、後者については、障害を復旧させるための処置を実施する必要があるため、計画工事の一覧と照らし合わせて、対応しなくてはならない障害の発生なのかどうかを判断しなければならなくなる。そこで、工事作業の予定時間帯と工事対象装置とを管理しておき、その時間帯のその装置からのアラームイベントはオペレータ（ネットワーク管理者）に知らせないようにすること（特許文献４）が提案されている。
特開平７−１９２１８８号 特開平９−３０７５５０号 特開平９−６４９７１号 特開平９−１６８０１０号

上記特許文献１〜３に開示された技術によれば、監視装置が受信した複数の障害通知（アラーム）の相関関係(コリレーション）を解析することにより、同一の原因から生じた複数のアラームをまとめることは可能である。しかし、これらの従来技術は、既に生じた多数のアラームを統計的に解析することで相関関係を得るものであるから、せいぜい、ノード・リンク・ポートのような物理的に関連性のある障害について、遡って障害原因を特定することができるだけであろうと考えられる。

一方で、ネットワーク監視ツールは、原因となる一つの障害が発生したとき、監視装置が、ノードやリンク等の物理的なネットワーク構成要素についてのアラームを受信するだけでなく、これらの物理的な構成要素を利用する論理的なパス（パケット転送経路）についてのアラームも受信するように構成されることが、より細やかな監視のためには望ましい。このような監視の対象とすることのできる論理パスには、例えば、ラベルスイッチパス（ＬＳＰ）が設定された経路や、インターネットプロトコル（ＩＰ）によりパケットが転送される経路等がある。本発明者らは、前者の監視については特開２００５−２８６８１８号公報に示されるように、後者の監視については特開２００５−３１１４５８号公報に示されるように、その監視機構を既に提案している。

ＬＳＰは、ＭＰＬＳ（Multi Protocol Label Switching）方式でパケット転送が行われるネットワークにおいて設定され、その経路上のルータが、パケットのネットワークレイヤのアドレスを調べて転送先を決めるのではなく、パケットに付与されたラベルにより高速にスイッチングすることにより、高速なパケット転送が実現されるものである。ＭＰＬＳ方式のネットワークにおいては、始点ノードと終点ノードとの間で、あるいは、始点から終点までの経路上の隣接ノード間で、ＲＳＶＰ（Resource reSerVation Protocol）あるいはＬＤＰ（Label Distribution Protocol）等のメッセージが交換されることにより、複数のノード及びリンクを経由して、論理パス（パケット転送経路）であるＬＳＰが設定される。

ＩＰネットワークの場合は、ネットワークを構成する多数のルータ間で、ＯＳＰＦやＩＳ−ＩＳ（Intermediate System−to−Intermediate System）等のメッセージが交換されることにより形成されるルーティング情報に基づいて、どのノード及びリンクを経由してパケットが転送されるか、すなわちパケット転送経路（論理パス）が計算される。なお、ＯＳＰＦやＩＳ−ＩＳは、ＡＳ（Autonomous System）と呼ばれる、共通のポリシーや同じ管理下で運用されているネットワークの内部で動作するものであるため、ＡＳ間については、ＢＧＰ等で交換されるルーティング情報に基づいて、パケット転送経路を求めることになる。

このように動的に変化する論理的なパスを含めて、アラーム間の相関関係を解析することは、上記の従来技術では難しい。よって、そのままでは、論理パスについてのアラームは、相関関係のあるものもないものも区別されずに、多数のアラームがネットワーク管理者に提示されることになり、混乱してしまう。同様に、計画工事により生じた障害についても、上記の従来技術では、工事対象として予め登録された装置についてのアラームは抑制することができるが、動的に変化する論理パスについてのアラームは、そのままネットワーク管理者に提示されてしまう。

さらに、上記の従来技術では、一連のアラームの原因となったアラームを特定することは可能であるが、ＩＰやＭＰＬＳのようなパケットネットワーク環境で、原因となる障害から、その障害が影響を及ぼす範囲を求めることはできない。例えば、１つの物理的な障害を原因として、どの論理パスについて派生的にアラームが生じるはずであるかを求めることができないし、また、各論理パスを使用する顧客もしくはサービスが予め定められている場合に、その論理パスに障害が生じることにより、最終的にどの顧客もしくはサービスに影響があったのかを知ることができない。影響範囲を知ることができれば、ネットワーク管理者は、それに応じた対策、例えば、影響のあった顧客にパケット転送がされていなかった期間を教えて注意を促す等の対策を採ることが可能になる。

本発明は、以上のような事情を考慮して、ネットワーク管理者を効果的に支援できるツールを提供することを目的とする。例えば、動的に変化する論理パス（パケット転送経路）を含めて、各構成要素についてのアラーム（イベント通知）間の相関関係を分析できるようにすることや、１つのイベントの発生を原因として、派生的に他の構成要素について生じることになるイベントを求めたり、影響を受ける顧客又はサービス等を特定したりできるようにすることが、本発明が解決しようとする課題となる。

本発明に係るネットワーク監視装置は、ネットワークにおいて動的に設定されるパケット転送経路の情報を収集する収集手段と、前記ネットワークの構成要素についてイベントが生じたことを示す通知を受信する受信手段と、前記収集手段により収集されたパケット転送経路の情報に基づいて、前記受信手段により受信された複数の通知の相関関係を分析する分析手段とを備えたことを特徴とする。前記受信手段により受信される通知が示すイベントの種類には、例えば、前記構成要素についての障害、障害の回復がある。前記構成要素に、パケット転送経路又はラベルスイッチパス等の論理パスが含まれる場合、同じ始点から終点までの経路が変更されたことを示す変更というイベントの種類もあり得る。なお、経路の途中の物理的な要素で障害が発生した後、その障害自体が回復することにより同じ経路で論理パスが回復する場合と、別の経路が設定されることにより論理パスが回復する場合と、経路が変更されることにより論理パスの障害が回避される場合とがあり得る。新たな構成要素がネットワークに追加されたり、既存の構成要素がネットワークから除去されたりというイベントを、監視の対象とすることもあり得る。

前記分析手段は、前記収集手段により収集された複数の時点におけるパケット転送経路の情報のうち、前記受信手段により受信された通知により特定される時点に基づいてイベント発生時点におけるパケット転送経路であると推定できるものの情報を用いて、前記相関関係の分析を行うことができる。このため、動的に変化するパケット転送経路を含めて、各構成要素についてのイベント通知間の相関関係を分析することができるようになる。

前記分析手段は、複数の通知のそれぞれが前記受信手段により受信された時点の前後関係とは関係なく、前記相関関係の分析を行うこともできる。このため、ＩＰ等のパケットが送信された順序とは異なる順序で受信されることがあるネットワークにおいても、適切な分析、監視が行えるようになる。

前記収集手段は、前記ネットワークを構成するノード間で交換されているルーティング情報を収集し、前記分析手段は、前記ルーティング情報（例えば、ＯＳＰＦ、ＩＳ−ＩＳ、ＢＧＰ等で交換されるメッセージにより形成される情報）を用いて計算によりパケット転送経路を求め、求めたパケット転送経路に基づいて、前記相関関係の分析を行うようにしてもよい。

前記収集手段は、前記ネットワークに設定されているラベルスイッチパスに関する情報（例えば、ＲＳＶＰ、ＬＤＰ等で交換されるメッセージにより形成される情報であり、ラベルスイッチングを行うノードが有している情報であってもよい）を収集し、前記分析手段は、ラベルスイッチパスについてのイベントと、該ラベルスイッチパスが経由するリンクについてのイベントとの間に、相関関係があると分析するようにしてもよい。

本発明に係るネットワーク監視装置は、前記受信手段により受信された通知が示すイベントの情報を履歴として記憶する記憶手段を更に備え、前記分析手段は、ユーザからの指示に応じて、前記記憶手段に履歴として記憶されたイベントの相関関係を分析し、分析結果をユーザに提示するように構成してもよい。例えば、ユーザが、ある範囲で生じたイベントの表示を指示すると、該当するイベントを履歴記憶手段から検索することになるが、このイベント検索時に、検索されたイベント間の相関関係を分析する。

本発明に係るネットワーク監視装置は、前記受信手段により受信された通知が示すイベントの情報を履歴として記憶する記憶手段を更に備え、前記分析手段は、前記受信手段による受信に応じて、受信された通知が示すイベント及び前記記憶手段に記憶されたイベントの相関関係を分析し、分析結果を前記記憶手段に記憶させるように構成してもよい。例えば、イベント受信時に、所定期間内に受信されたイベント間の相関関係を分析し、イベントともに相関関係を履歴記憶手段に記憶しておくため、ユーザの指示に応じて履歴記憶手段を参照する時は、ともに記憶してある相関関係を読み出して表示することができる。

上記構成において、前記分析手段は、前記パケット転送経路の情報に基づいて、前記複数の通知から、相関関係を有する一連のイベント通知の原因となるイベントの発生を示す通知を、特定する手段と、前記パケット転送経路の情報に基づいて、前記原因となるイベントの発生によって派生的に他の構成要素に生じるイベントを求める手段とを含むことができる。このため、一連のイベント通知の原因となったイベントを特定するだけでなく、原因となるイベントから、そのイベントが影響を及ぼす範囲を求めることが可能になる。ここでは、１つのイベントの発生を原因として、派生的に他の構成要素について生じることになるイベントを求めることができるため、例えば、これらのイベントをまとめて表示したり、生じるはずの派生イベントについて通知が受信されない場合にこれを検出したり、計画工事を原因として生じた派生イベントを、真の障害によるイベントと区別して表示したりすることが可能になる。

上記構成において、前記収集手段は、前記パケット転送経路の情報に加えて、該パケット転送経路を使用する主体（例えば、顧客、サービス等）を示す情報を収集する手段を含み、前記分析手段は、前記主体を示す情報に基づいて、前記原因となるイベントの発生によって影響を受ける主体を特定する手段を含むことができる。このため、１つのイベントの発生を原因として派生イベントが発生する構成要素（例えば、パケット転送経路）を使用している主体を特定することができ、ユーザは、イベント発生により影響を受ける顧客又はサービス等を知ることができるようになる。

上記構成において、前記原因となるイベントが障害である場合に、前記原因となる障害の発生を示す通知により特定される時点に基づいて、派生的にイベントが生じる前記他の構成要素についてのパケット不転送期間を推定する手段を更に備えるようにしてもよい。例えば、前記原因となる障害の発生を示す通知により、パケット不転送期間の開始時点を推定し、前記他の構成要素について障害が回復したことを示す通知もしくは障害回避のための変更が行われたことを示す通知を受信することにより、パケット不転送期間の終了時点を推定してもよい。これにより、ユーザは、例えば、最初の物理的な障害発生から、注目するパケット転送経路やこれを利用するサービスが回復もしくは変更されて障害が除去されるまでの時間を、パケット不転送期間（ダウンタイム）として把握することができ、影響を受ける顧客に、これを知らせることができる。

上記構成において、前記派生的に他の構成要素に生じるイベントの深刻度に応じて、該イベントの通知をユーザに提示する形態を異ならせる手段を更に備えるようにしてもよい。これにより、一連の派生イベントを複数のレベルに分け、例えば、障害等の致命的なイベントは、赤色で表示し、変更等の注意喚起で足りるイベントは、黄色で表示するようなことが可能になる。

本発明に係るネットワーク監視装置は、前記分析手段により求められた派生的に他の構成要素に生じるイベントが実際に生じたことを示す通知が、前記受信手段により受信されなかった場合に、ユーザに異常として提示する手段を更に備えるように構成することができる。これにより、例えば、派生イベントの通知を監視装置へ送信すべきネットワークの構成要素自体に障害が生じていたり、送信された派生イベントの通知が途中で紛失して監視装置に受信されなかったりした場合に、そのような事態の発生を検出することが可能になる。この場合、ある障害について通知（アラーム）を実際に受信しなくても、その障害の発生を監視装置側で予測していることになる。

本発明に係るネットワーク監視装置は、前記分析手段により求められた派生的に他の構成要素に生じるイベントが実際に生じたことを示す通知が、前記受信手段により受信されなかった場合に、該他の構成要素についてポーリングを行う手段を更に備えるように構成することもできる。これにより、派生イベントの通知を監視装置へ送信すべき構成要素自体に障害が生じているのか、それとも、送信された派生イベントの通知が途中で紛失しただけであるのか、区別することも可能になる。また、ネットワークの多くの構成要素に対して、定期的にポーリングして、状況を調査することは、頻度を高くするほどネットワークの負荷が高くなってしまうが、監視装置側で予測したイベント通知が受信されない場合に、選択的にポーリングをすることにより、ネットワークの負荷を低減しつつ、適切な状況調査が可能になる。

本発明にかかる別のネットワーク監視装置は、ネットワークにおいて動的に設定されるパケット転送経路の情報を収集する収集手段と、前記ネットワークの構成要素についてイベントが生じたことを示す通知を受信する受信手段と、前記ネットワークの構成要素について工事作業が計画されていることを作業開始の予定時点の情報とともに登録する登録手段と、前記収集手段により収集されたパケット転送経路の情報に基づいて、前記登録手段に登録された工事作業の実施と前記受信手段により受信されたイベント通知との相関関係を分析する分析手段とを備えたことを特徴とする。これにより、動的に変化するパケット転送経路についてのイベントを含めて、計画工事を原因として生じたイベントなのか、真の障害を原因として生じたイベントなのかを、区別することが可能になる。

前記分析手段は、前記受信手段によるイベント通知の受信に応じて、該受信により特定される時点における前記パケット転送経路の情報に基づき、前記通知が示すイベントの原因となるイベントが、前記工事作業の実施であるか否かを判断する手段を含むようにしてもよい。この場合、例えば、イベント受信時に、通知されたイベントが発生する原因となったイベントを、履歴検索手段から検索し、その原因イベントが計画工事と一致する否かを判断する。

前記分析手段は、前記工事作業の開始に応じて、該開始により特定される時点における前記パケット転送経路の情報に基づき、前記工事作業の実施によって派生的に他の構成要素に生じるイベントを求めて記憶しておき、前記受信手段によりイベント通知が受信された場合に、該通知が示すイベントが記憶された前記イベントであるか否かを判断する手段を含むようにしてもよい。この場合、例えば、工事作業開始時に、その工事を原因として生じる一連のイベントを求めておき、イベント受信時には、通知されたイベントが、求めておいた一連のイベントのうちの一つであるか否かを判断する。

本発明にかかる更に別のネットワーク監視装置は、ネットワークを構成する要素同士の関係を表す情報を収集する収集手段と、前記ネットワークの構成要素についてイベントが生じたことを示す通知を受信する受信手段と、前記収集手段により収集された情報に基づいて、前記受信手段により受信された通知が示すイベントが生じた場合に受信されるべき他の構成要素についての通知を求める分析手段と、前記分析手段により求められた他の構成要素についての通知が、所定時間内に前記受信手段により受信されたか否かを検出する管理手段とを備えたことを特徴とする。これにより、通知を受信したイベントに基づいて、関連するイベントの発生を監視装置側で予測することができ、発生が予測されたイベントの通知が受信されない場合を、何らかの異常が発生した可能性がある場合として検出することが可能になる。

前記収集手段により収集される情報は、前記ネットワークにおいて直接接続されている要素の組の情報と、前記ネットワークにおいて動的に設定されるパケット転送経路の情報のうち、少なくともいずれかとすることができる。前者の場合、例えば、一つのリンクに障害が生じると、そのリンクの両端のノードがそれぞれ、そのリンクに接続するポートについての障害イベントを監視装置へ通知するはずであるから、一方のノードから通知を受信したのに、他方のノードから通知を受信しないということから、通知が途中で紛失したかもしくは他方のノードが正常に動作していない可能性があることを検出できる。後者の場合、例えば、一つのリンクに障害が生じると、そのリンクについての障害イベントが監視装置へ通知されるだけでなく、そのリンクを経由するラベルスイッチパス（複数あり得る）についての障害イベントも監視装置へ通知されるはずであるから、ラベルスイッチパスについての通知が受信されなければ、通知が途中で紛失したかもしくは当該通知を行うべきノードが正常に動作していない可能性があることを検出できる。

上記構成において、前記管理手段により、他の構成要素についての通知が所定時間内に受信されなかったと判断された場合に、ユーザに異常として提示するようにしてもよい。これにより、ユーザは、通知を行うべきノードの動作を調査し、必要であれば修理を施すことが可能になる。

上記構成において、前記管理手段により、他の構成要素についての通知が所定時間内に受信されなかったと判断された場合に、該他の構成要素について検査をするためのメッセージを前記ネットワークへ送信する検査手段を更に備えるようにしてもよい。これにより、通知が途中で紛失しただけなのか、通知を行うべきノードが正常に動作していないのかを検査することが可能になる。よって、前記検査手段により送信されたメッセージに対する応答に基づいて異常が検出された場合にユーザに異常を報知するようにすれば、受信されるべき通知が受信されない場合にユーザに異常として提示するよりも、ユーザに知らせる場合をより真に必要な場合に絞り込むことができることになる。

また、上記検査手段を備えた構成によれば、ネットワークの多くの構成要素の全てに対して定期的にポーリング（検査メッセージの送信と応答の受信）をするのではなく、異常が生じている可能性のある構成要素に対して選択的にポーリングをすることにより、ネットワークの負荷を低減しつつ、適切な状況調査が可能になる。

本発明に係るネットワーク監視方法は、ネットワークにおいて動的に設定されるパケット転送経路の情報を収集し、前記ネットワークの構成要素についてイベントが生じたことを示す通知を複数受信し、収集された前記パケット転送経路の情報に基づいて、受信された複数の前記通知の相関関係を分析することを特徴とする。

上記方法において、前記ネットワークの構成要素について工事作業が計画されていることを作業開始の予定時点の情報とともに登録しておき、前記分析の際に、登録された計画工事に対応するイベントが生じたことを示す通知と、その他のイベントが生じたことを示す通知との相関関係を分析するようにしてもよい。

本発明に係る別のネットワーク監視方法は、ネットワークを構成する要素同士の関係を表す情報を収集し、前記ネットワークの構成要素についてイベントが生じたことを示す通知を受信し、収集された前記関係を表す情報に基づいて、受信された前記通知が示すイベントが生じた場合に受信されるべき他の構成要素についての通知を求め、求められた前記他の構成要素についての通知が、所定時間内に受信されたか否かを検出することを特徴とする。

上記方法において、他の構成要素についての通知が所定時間内に受信されなかったと判断された場合に、該他の構成要素について検査をするためのメッセージを前記ネットワークへ送信するようにしてもよい。

なお、上述した本発明は、コンピュータを上記のネットワーク監視装置として機能させるためのプログラムの発明や、コンピュータに上記のネットワーク監視方法を実行させるためのプログラムの発明としても、また、このようなプログラムを記録した記録媒体の発明としても、勿論成立するものである。

以上のとおり、本発明の一つの発明によれば、動的に変化するパケット転送経路について生じるイベントを含めて、同一の原因から生じる複数のイベントを関連付けることができる。その同一の原因が、計画工事であるか、予期しない障害であるかを区別する構成を加えることもできる。また、本発明の別の発明によれば、通知を受信したイベントに関連するイベントの発生を予測して、通知が受信されない場合を検出することにより、異常の可能性を予め知ったり、ポーリングによるネットワークの負荷を低減したりすることができる。なお、上記二つの発明を組み合せて実施することもできる。

以下、本発明の実施の形態について図面を用いて説明する。

図１は、本発明の一実施形態に係る監視装置１００の内部構成例を示す図である。監視装置１００は、監視すべきネットワーク３００に接続されている。ここでは、一つのネットワークに一つの監視装置が設けられている場合を例示するが、監視すべきネットワークが大規模であれば、ネットワークを複数のエリアに分割し、複数の監視装置のそれぞれが、自装置の担当するエリアの監視を行うようにしてもよい。各エリアの監視を行う監視装置から情報を収集して、ネットワーク全体の監視を行う統合監視装置を更に設けてもよい。

監視装置１００のユーザインタフェース（ネットワーク管理者が使用する表示画面や指示入力デバイス）は、監視装置１００内に組み込んで設けても、別体の装置として設けてもよい、後者の場合、一つの監視装置１００を、複数のユーザインタフェース装置（リモートコンソール、又は、ネットワーク３００経由で監視装置１００にアクセスできるコンピュータ）から利用できるよう、構成することも可能である。

ネットワーク３００は、図２、図７、図１１及び図２１に例示されるように、多数のノード（図中、「Ｒ」で示す）、隣接するノード間を接続するリンク（図中、「Ｌ」で示す）、複数のリンクをラベルスイッチングで接続することにより１つ以上のノードを経由して隣接しないノード間の高速転送を実現するラベルスイッチパス（以下、「ＬＳＰ」という）等の構成要素を含んでいる。ＬＳＰは、そのＬＳＰを使用する顧客又はサービスを限定して、専用にすることができ、図７の例では、ＬＳＰの両端に接続されたＶＰＮ（Virtual Private Network）１の専用となっている。ノードは、通常、複数のポート（図中、「ｐ」で示す）を有するため、リンクは、より具体的には、図２１に例示するように、あるノードのあるポートと、別のノードのあるポートを接続するものとなる。よって、ノード（Ｒ）から延びるリンク（Ｌ）という形式（図４，９，１０，１３，１４の例）でリンクを特定することもできるし、リンクに接続するノード（Ｒ）のポート（ｐ）という形式（図２３，２６の例）でリンクを特定することもできる。

監視装置１００は、ネットワーク３００に接続するためのネットワークＩ／Ｆ１１０と、ネットワークからイベント通知を受信するイベント通知受信部１２０と、ネットワークから論理パス情報を収集する論理パス情報取得部１３０とを備える。ＬＳＰの経路情報や、ＩＰパケット転送経路を計算するためのＯＳＰＦ，ＩＳ−ＩＳ等の情報が、論理パス情報に相当する。論理パスを使用する主体の情報をも、論理パス情報取得部１３０が収集するようにしてもよい。

論理パス情報取得部１３０は、収集した論理パス情報を論理パス情報記憶部１４０に記憶する。論理パス情報の収集は、定期的にネットワーク３００内のノード等に対し問合せをして返送されてくる情報を受信してもよいし、変更があった場合にネットワーク３００内のノード等から送信されてくる情報を受信するのでもよい。さらに、論理パスの経路が変更された可能性を示すイベント通知が、イベント通知受信部１２０で受信された場合に、論理パス情報取得部１３０が、そのイベント通知の送信元のノードや関連するノードに問合せて、新たな論理パス情報を取得するようにしてもよい。

イベント通知受信部１２０により受信された通知が示すイベントの情報は、イベント履歴記憶部１５０に蓄積される。記憶されるイベントが、論理パスについてのイベントである場合、その論理パスの経路情報を、論理パス情報記憶部１４０から読み出してイベント履歴記憶部１５０に記憶してもよい。本例において、イベント履歴記憶部１５０に記憶されるイベントの種類には、障害、回復、変更がある。イベント履歴記憶部１５０に記憶されるイベントのうち、ネットワークのある構成要素に障害が発生した後、その障害が回復していないイベントを、特に、アクティブイベントと呼ぶ。

相関関係分析部１６０は、ユーザ提示情報作成部１７０から指示を受けた場合、あるいは、イベント通知受信部１２０からイベントの受信を知らされた場合に、イベント履歴情報記憶部１５０に記憶されたイベント間の相関関係を分析する。分析されるイベントが、論理パスについてのイベントである場合、その論理パスを使用する主体の情報を、論理パス情報記憶部１４０から読み出して、分析に用いてもよい。

ユーザ提示情報作成部１７０は、図示しないユーザインタフェースから指示を入力し、作成した情報を出力して表示画面に表示させる。ユーザ提示情報作成部１７０は、イベント履歴記憶部１５０から読み出されたイベントの情報や、そのイベントが発生した構成要素のネットワークトポロジーにおける位置や経路等に加えて、相関関係分析部１６０で求められたイベント間の相関関係を、ユーザに提示することができる。ユーザ提示情報作成部１７０は、ユーザにイベント情報を表示するときには、イベント履歴記憶部１５０から提示するイベントを読み出し、相関関係を表示するときには、相関関係記憶部１６０に指定されたイベントを伝えることによりそれに関連するイベントの情報を得る。

監視装置１００は、一般的には、上記各部の機能を実現するためのソフトウェアプログラムを、十分なストレージ容量とプログラム実行性能を有するコンピュータにインストールすることにより実装されるが、上記の機能の一部を専用ハードウェア化して実装してもかまわない。ネットワーク３００における論理パスは、動的に経路が変更されるが、監視装置１００は、その経路を逐次取得して記憶するため、動的に経路が変更される論理パスに関する相関関係を求めることができる。よって、ＭＰＬＳ方式やＩＰ方式のネットワークでのイベント間の相関関係が、適切に求められることになる。

以下には、相関関係分析部１６０の具体的な動作を、幾つかの例を挙げて説明する。まず、ネットワーク３００の構成要素として、リンク（ポート）と、ＲＳＶＰを用いて設定されたＬＳＰとを対象にし、ユーザ提示情報作成部１７０からイベント履歴記憶部１５０を検索するよう指示を受けたことをトリガとして、相関関係の分析を行う例を、図２〜図４を参照しながら説明する。

図２に示すように、ルータＲ４とＲ５を接続するＬ６のリンクに障害が発生した場合を考える。ＬＳＰ１が、Ｒ１→Ｒ４→Ｒ５→Ｒ６の経路で設定されているため、Ｌ６は、ＬＳＰ１に利用されている。原因となる障害が発生すると、ルータＲ４は、Ｌ６に障害があることを監視装置１００に、ＳＮＭＰトラップで送出（通知）する。これは、イベント通知受信部１２０により受信され、イベント履歴記憶部１５０に、イベント履歴番号１として記憶される（図４を参照）。

実際には、図５〜６に示すように、Ｌ６の障害（回復も同じ）は、リンクの両端のノードから通知されるため、ノードＲ４からポートｐ１のイベントが通知され、ノードＲ５からポートｐ２のイベントが通知される。監視装置１００は、ネットワークトポロジーの情報として、図２２（ａ）に示すようなリンク−ポート対応表を記憶しているため、これら二つのイベント通知が、同一のリンクのイベントを表していることを知ることができる。図４の例では、同一のリンクのイベントを一つにまとめて（両端のノードのうちの一方であるＲ４を代表として）記憶しているが、受信した二つのイベントをそのまま記憶しても構わない。

また、図４のイベント履歴情報記憶部１５０には、受信したイベント通知の送信元のノードが「イベント通知ルータ」として、イベントの種類（障害／回復／変更）が「深刻度」として、イベントがどの種類の構成要素（リンク（ポート）／ＬＳＰ）について生じたものであるかが「対象種別」として、構成要素を特定するための識別子が「対象番号」として、記憶される。ここでの構成要素は、「イベント通知ルータ」と「対象番号」の組により、ネットワーク３００内で（監視装置１００において）一意に特定される。ＲＳＶＰにより設定されるＬＳＰの場合は、「イベント通知ルータ」はＬＳＰの始点ルータとし、「対象番号」はトンネルＩＤとして規定されているＬＳＰ識別子とすればよい。ＬＳＰについては、更に、ＬＳＰ名（例えば「Tokyo-Osaka」のようにＩＳＰ管理者により便宜上付けられた名前）と経路（始点→中継→終点までの各ルータ及びルータ間のリンク）が、記憶される。

図４のイベント履歴情報記憶部１５０には、受信した通知により特定される「イベント発生時刻」も記憶される。例えば、通知を監視装置１００において受信したときの現在時刻を、イベント発生時刻として記憶してもよいし、各ルータで時刻同期がとれているならば、各ルータが送信する通知の中にイベント発生時刻を書き込み、監視装置１００でこれを読み出して記憶するようにしてもよい。各ルータが書き込む時刻は、通知を送信するときの現在時刻としてもよいし、イベントを検出したときの現在時刻としてもよい。監視装置１００は、イベント通知の送信元のルータ毎に、受信したときの時刻をイベント発生時刻とするか、通知の中に書き込まれた時刻をイベント発生時刻とするかを、設定することも可能である。

さて、障害が生じたＬ６を利用しているＬＳＰ１の始点ルータであるＲ１が、ＬＳＰ１に障害が生じたことを検出すると、この障害発生を監視装置１００に、ＳＮＭＰトラップで送出（通知）する。この通知も、イベント通知受信部１２０により受信され、イベント履歴記憶部１５０に、イベント履歴番号２として記憶される（図４を参照）。ここで、監視装置１００は、予めＬＳＰ１の経路情報を収集して、図３に示すように、論理パス情報記憶部１４０に記憶してある。このＬＳＰの経路情報の収集の具体的な方法としては、本発明者らが提案した特開２００５−２８６８１８号公報に示される方法を使うことができる。

イベント履歴記憶部１５０は、上述したように履歴番号２のＬＳＰ１に関するイベントを記憶する際、ＬＳＰ１の経路を論理パス情報記憶部１４０から読み込んで一緒に記憶する（図４を参照）。通知されたイベントの種類がＲＳＶＰ−ＬＳＰの回復や変更の場合には、ルータＲ１が、ＬＳＰ１の有効な経路情報を有しているため、論理パス情報取得部１３０が、ルータＲ１に問合せて経路情報を取得するが、通知されたイベントの種類が障害の場合には、ルータＲ１は、ＬＳＰ１の有効な経路情報を有していないため、監視装置１００が論理パス情報記憶部１４０に予め記憶してあるＬＳＰの経路情報を、イベント履歴記憶部１５０に記憶することになる。

履歴番号２のイベントを指定して、その派生元のイベントを検索するように、相関関係分析部１６０がユーザ提示情報作成部１７０から指示を受けたとすると、履歴番号２のイベントは、ＬＳＰに関するイベントなので、このイベントに記録されているＬＳＰ経路上のリンクあるいはルータに障害が発生していないか、このイベントの前後一定時間内のイベントを調べることにより、派生元のイベントを導き出す。図４のイベント履歴では、履歴番号１のイベントが、ＬＳＰ１の経路に含まれるＬ６についての障害であることが発見される。つまり、このイベント履歴番号１のポート障害が、イベント履歴番号２のＬＳＰ障害の派生元のイベントであることが分かる。この例では、イベント履歴番号１のポート障害が、原因として特定されるが、派生元のイベントの更に派生元のイベントが辿れる場合には、派生元のイベントを導き出す処理を続け、それ以上辿れなくなったときのイベントが、一連のイベント発生の原因となったイベントとして特定される。なお、一つのＬＳＰの経路上の複数のリンクで障害が同時期に発生した場合等、原因となるイベントが複数になることもあり得る。

履歴番号１のイベントを指定して、その派生先のイベント群を検索するように、相関関係分析部１６０がユーザ提示情報作成部１７０から指示を受けたとすると、履歴番号１のイベントは、リンクに関するイベントなので、このリンクを経路に含むＬＳＰ等の論理パスについて障害が発生していないか、この前後一定時間内のイベントを調べることにより、派生先のイベント群を導き出す。図４のイベント履歴では、履歴番号２のイベントが、Ｌ６を経路に含むＬＳＰ１についての障害として、発生していることが発見される。この例では、障害の生じたリンクを利用しているＬＳＰ等の論理パスが１つであったが、複数存在する場合もあり、また、派生先のイベントの更に派生先のイベントまで辿れる場合もある。このように、派生先のイベント群を求めることで、イベントの影響範囲を特定することができる。

以上は、イベントの種類が障害であった場合の説明であるが、回復イベントや変更イベントに関しても、同様に相関関係を分析することができる。すなわち、ルータＲ４は、Ｌ６の障害が回復すると、これを監視装置１００に通知し（図４のイベント履歴番号３として記憶される）、ルータＲ１は、ＬＳＰ１の障害が回復すると、これを監視装置に通知する（図４のイベント履歴番号４として記憶される）。相関関係分析部１６０は、Ｌ６の回復イベントとＬＳＰ１の回復イベントとが、原因と派生先の関係にあることを求めることができる。

なお、ＲＳＶＰ−ＬＳＰの回復イベントを受信したときには、そのＬＳＰの始点ルータからそのときの経路情報を取得し、論理パス情報記憶部１４０及びイベント履歴記憶部１５０に書き込み、この経路情報を相関関係の分析に用いる（図４のイベント履歴番号４のエントリを参照）。論理パス情報記憶部１４０には、新しい経路情報が上書きされるが、イベント履歴記憶部１５０では、障害のイベントに対応して記憶された古い経路情報はそのままで、回復のイベントに対応して新しい経路情報が記憶されるため、イベント毎に、そのイベントが発生した時点の経路情報が保存されることになる。この例では、一連の障害の原因であったＬ６の回復により、ＬＳＰ１は、以前の経路のままで、障害が回復しているが、ＬＳＰ１の障害が発生したときの経路と、ＬＳＰ１の障害が回復したときの経路が、異なる場合もあり得る。

変更イベントは、Ｌ６に障害が発生した後、ＬＳＰ１についての障害発生が通知されることなく、障害を回避する新たな経路が設定された場合に、通知される。すなわち、ルータＲ４が、Ｌ６の障害の発生を検出して、これを監視装置１００に通知し（図４のイベント履歴番号５として記憶される）、ルータＲ１が、ＬＳＰ１がこのＬ６の障害を回避すべく経路を変えて設定されたことを検出して、これを監視装置１００に通知する（図４のイベント履歴番号６として記憶される）場合がある。相関関係分析部１６０は、ＬＳＰの変更イベントに対しては、そのＬＳＰの旧経路上のリンクあるいはルータに障害イベントが発生していないか、もしくは、そのＬＳＰの新経路上のリンクあるいはルータに回復イベントが発生していないか、このイベントの前後一定時間内のイベントを調べることにより、派生元（原因）のイベントを導き出すことができる。さらに、リンクの障害イベントに対しては、そのリンクを経路に含むＬＳＰについて障害もしくは変更イベントが発生していないか、この前後一定時間内のイベントを調べることにより、派生先のイベント群を導き出すことができる。

なお、ＲＳＶＰ−ＬＳＰの変更イベントを受信したときには、旧経路としては、論理パス記憶部１４０にあるそのＬＳＰの経路情報を読み出して、新経路としては、そのＬＳＰの始点ルータから現在の経路情報を取得して、イベント履歴記憶部１５０に書き込み、この経路情報を相関関係の分析に用いる（図４のイベント履歴番号６のエントリを参照）。取得した新経路の情報は、論理パス情報記憶部１４０にも書き込まれる。論理パス情報記憶部１４０には、現在の経路情報（新経路の情報）が上書きされるが、イベント履歴記憶部１５０には、変更のイベントに対応して新旧の両方の経路情報が記憶されるため、イベント毎に、そのイベントが発生した時点の経路情報が保存されていることになる。

図４の例では、各イベント通知は、実際に生じた順番で受信され、記憶されている。しかし、イベントの通知が転送されるネットワーク３００においては、例えば、イベントの発生を先に検出したノード（原因イベントを検出したノード）の方が、後に検出したノード（派生先イベントを検出したノード）よりも、監視装置１００から見て遠くに存在する（監視装置１００への転送経路が長い）等の事情により、受信の順序が逆になり、原因となるイベントの通知が、派生先のイベントの通知よりも、後に受信される事態も起こり得る。また、原因イベントと派生先イベントを同じノードが通知する場合であっても、ネットワーク３００が、ＩＰ等のパケットの送信順序が転送途中で変わることがあるものであれば、やはり受信の順序が逆になることがある。そこで、相関関係分析部１６０は、上述したように、指定されたイベントの派生元（原因）のイベントを探索するときも、派生先のイベントを探索するときも、指定されたイベントの前後一定時間内のイベントを調べるようにして、受信順序にかかわらず、適切に相関関係を求められるようにしている。

図５は、指定された論理的な構成要素（図の例では「ＲＳＶＰ−ＬＳＰ」）に生じたイベント及びその派生元イベントをユーザに提示するために、ユーザ提示情報作成部１７０により作成され表示画面に表示される内容の一例を示す。この例で指定されたイベントは障害であるので、ユーザの目に確実に留まるようにするため、「レベル：障害（致命的）」や「イベント内容：ＬＳＰ（パス）がダウンしました」という表示の色を赤くする等してもよい。イベントの情報として、他にも、イベント発生に関する時刻やイベントが発生した構成要素の名前等を表示できる。

そして、図５の表示画面で、「コリレーション」として「派生元」をクリックして「表示」を指示すると、上記ＲＳＶＰ−ＬＳＰの障害の原因となったリンク（上記ＲＳＶＰ−ＬＳＰが経由しているリンク）の障害というイベントが表示される。この例では、ポートまで表示するため、障害が発生したリンクの両端のポート（SapporoのL2PORTとTokyoのL2PORT）についてのイベント（図中、丸に白抜きのバツの印は「障害」を示し、致命的レベルを示す赤色で表示されている）が、派生元のイベントとして表示されている。また、この派生元のイベントの更に派生元となるイベントも表示されている。

図６は、指定された物理的な構成要素（図の例では「リンク」）に生じたイベント及びその派生先イベント群をユーザに提示するために、ユーザ提示情報作成部１７０により作成され表示画面に表示される内容の一例を示す。この例で指定されたイベントは障害であるので、ユーザの目に確実に留まるようにするため、「レベル：障害（致命的）」や「イベント内容：リンクがダウンしました」という表示の色を赤くする等してもよい。イベントの情報として、他にも、イベント発生に関する時刻やイベントが発生した構成要素の名前等を表示できる。

そして、図６の表示画面で、「コリレーション」として「派生先」をクリックして「表示」を指示すると、上記リンクの障害を原因として引き起こされた派生先のイベント群（上記リンクを利用しているＬＳＰの障害もしくは経路変更）が表示される。この例では、リンクＬ１を利用している複数のＲＳＶＰ−ＬＳＰのうち、Sapporo-to-Fukuoka-p001については、障害（図中、丸に白抜きのバツの印は「障害」を示し、致命的レベルを示す赤色で表示されている）が生じ、Fukuoka-to-Sapporo-001については、経路変更（図中、三角にエクスクラメーションマークの印は「変更」を示し、注意喚起レベルを示す黄色で表示されている）が生じている。これにより、ユーザは、同一の原因から生じる一連のイベントのうち、緊急に対処の必要なレベルのものを、それ以外のものから区別して認識することができる。なお、図５〜６のイベント情報の表示は、図２のようなネットワークトポロジーのマップ表示を利用して行うようにもできる。

図５〜６では、イベント履歴記憶部に記憶されたイベントが、アクティブイベント（現在まだ障害が残っているイベント）か、解決済みのイベント（障害発生後に回復が通知されたイベント）かを区別せずに、ある一つの指定されたイベントと相関関係を有する一連のイベントを全て表示する例を示したが、これ以外にも、様々な表示方法が可能である。

例えば、イベント履歴記憶部に記憶されたイベントから、アクティブイベントを抽出して、アクティブイベントリストとして表示し、リスト中のイベントの派生元（原因）イベントを表示したり、リスト中のイベントの派生先イベントを表示したりすることができる。この場合の表示画面は、例えば、後述する図１８における計画工事が原因イベントに置き換わったようなものになる。あるいは、イベント履歴記憶部に記憶されたイベントから、解決済みの原因イベントを抽出して、抽出されたイベントの派生先イベントの一覧を表示することにより、ユーザが、その原因イベントによって一連のイベントがどのように引き起こされ、どのように解決していったかを検討できるようにすることも可能である。この場合の表示画面は、例えば、後述する図１９における計画工事が原因イベントに置き換わったようなものになる。また、逆に、イベント履歴記憶部に記憶されたイベントから、ある範囲内の解決済みの派生先イベントを抽出してリスト表示し、リスト中のイベントの原因イベントを表示することも可能である。

ここで、イベント履歴記憶部に記憶されたイベントから、アクティブイベントを抽出するには、ある構成要素の障害イベントと組になる同一の構成要素の回復イベントが、イベント履歴中に存在するかどうかを調べ、存在しなければ、その障害イベントはアクティブイベントであると判断すればよい。この抽出処理には、例えば、次の二通りの方法があり得る。一つは、ユーザからアクティブリストの表示を要求されたときに、イベント履歴記憶部に記憶されているイベントに対してまとめて行う方法である。もう一つは、イベントを受信する毎に行う方法であり、障害イベントを受信したら、これにアクティブイベントの印を付加して、イベント履歴として記憶し、回復イベントを受信したら、これと組になる同一の構成要素の障害イベントをイベント履歴から検索して、そこに付加されているアクティブイベントの印を消去すればよい。

次には、ネットワーク３００の構成要素として、リンク（ポート）と、ＲＳＶＰを用いて設定されたＬＳＰとを対象にし、ＬＳＰを使用する主体として、ＶＰＮが存在する場合に、相関関係分析部１６０が、ユーザ提示情報作成部１７０からイベント履歴記憶部１５０を検索するよう指示を受けたことをトリガとして、相関関係の分析を行う例を、図７〜図９を参照しながら説明する。

図７に示すように、ルータＲ４とＲ５を接続するＬ６のリンクに障害が発生した場合を考える。ＬＳＰ１が、Ｒ１→Ｒ４→Ｒ５→Ｒ６の経路で設定されているため、Ｌ６は、ＬＳＰ１に利用されている。原因となる障害が発生すると、ルータＲ４は、Ｌ６に障害があることを監視装置１００に、ＳＮＭＰトラップで送出する。これは、イベント通知受信部１２０により受信され、イベント履歴記憶部１５０に、イベント履歴番号１として記憶される（図９を参照）。

ＬＳＰ１の始点ルータであるＲ１は、ＬＳＰ１に障害があることを監視装置１００に、ＳＮＭＰトラップで送出する。これも、イベント通知受信部１２０により受信され、イベント履歴記憶部１５０に、イベント履歴番号２として記憶される（図９を参照）。ここで、監視装置１００は、予めＬＳＰ１の経路情報を収集して、図８（ａ）に示すように、論理パス情報記憶部１４０に記憶してある。イベント履歴記憶部１５０は、履歴番号２のＬＳＰ１に関するイベントを記憶する際、ＬＳＰ１の経路を論理パス情報記憶部１４０から読み込んで一緒に記憶する（図９を参照）。

ＬＳＰの始点ルータには、設定されたＬＳＰにどのパケットを流すかを制御する機能が備えられている（図７の例では、ＶＰＮ１に属するパケットがＬＳＰ１に流される）ため、図８（ｂ）のような対応関係が記憶されている。監視装置１００は、ＬＳＰ１の始点ルータＲ１が有する上記対応関係の情報も、論理パス情報取得部１３０を介して取得し、論理パス使用ＶＰＮ情報として論理パス情報記憶部１４０に予め記憶している。

図９に履歴番号１で示されたイベントを指定して、その派生先のイベント群を検索するように、相関関係分析部１６０がユーザ提示情報作成部１７０から指示を受けたとすると、図２〜４の場合と同様に、履歴番号２のイベントが発見される。更に、この例では、履歴番号２のイベントの派生先のイベントまで辿ることができる。すなわち、相関関係分析部１６０は、論理パス情報記憶部１４０に記憶された図８（ｂ）の論理パス使用ＶＰＮ情報を参照することにより、履歴番号２のイベントが発生したＬＳＰ１を使用しているＶＰＮが、ＶＰＮ１であることを知る。そこで、相関関係分析部１６０は、ＶＰＮ１についてのイベントが、履歴番号２のイベントの前後一定時間内に存在するかを調べる。

図９のイベント履歴では、ＶＰＮ１について障害が発生したことが、始点ルータＲ１から通知され、履歴番号３のイベントとして記憶されている。このように、イベントの派生先を順番に検索することにより、あるイベントから派生するすべてのイベントを求めることができる。

なお、上記の例では、ルータがＶＰＮについてのイベントも通知する機能を有しているものとして説明したが、ルータにこの機能がなくても、監視装置１００では、論理パス使用ＶＰＮ情報が取得されているため、ＬＳＰについて通知されたイベントから、影響を受けるＶＰＮを特定することができる。よって、ＶＰＮについてのイベントが通知されなくても、ユーザに対して、ＬＳＰについてのイベントによって影響を受けるＶＰＮを知らせることができる。このとき、監視装置１００は、ＬＳＰについてイベントの通知を受信したことを契機として、論理パス情報記憶部１４０を参照し、そのＬＳＰを使用しているＶＰＮを特定したら、図９のイベント履歴記憶部１５０に、ＶＰＮについてのイベントとして書き込むようにしてもよい。つまり、図９の履歴番号３のイベントは、始点ルータから通知を受けなくとも、相関関係分析部１６０の判断で新しいエントリを作成することにより、記憶されることができるものである。

図９に履歴番号３で示されたイベントを指定して、その派生元のイベントを検索するように、相関関係分析部１６０がユーザ提示情報作成部１７０から指示を受けたとすると、相関関係分析部１６０は、論理パス情報記憶部１４０に記憶された図８（ｂ）の論理パス使用ＶＰＮ情報を逆引きすることにより、履歴番号３のイベントが発生したＶＰＮ１が使用するＬＳＰが、ＬＳＰ１であることを知る。そして、相関関係分析部１６０は、ＬＳＰ１についてのイベントが、履歴番号３のイベントの前後一定時間内に存在するかを調べ、履歴番号２のイベントが発見される。履歴番号２のイベントの更に派生元となるイベントは、図２〜４の場合と同様に探索され、履歴番号１のイベントが発見される。

図９の例では、省略して、障害イベントだけを記述したが、回復イベントについても、図４と同様に、イベント履歴として記憶される。ここで、図７〜９のようにＬＳＰ１の顧客がＶＰＮ１であるとして、図４のイベント履歴が得られたときに、サービスのダウンタイムを顧客に教えるための例を説明する。Ｌ６の障害を原因としてＬＳＰ１に障害が生じた場合、又は、Ｌ６の障害を原因としてＬＳＰ１に経路変更が生じた場合に、ＶＰＮ１がＬＳＰ１に流したパケットが宛先まで転送されずに紛失した可能性が生じる。そこで、前者の場合、原因となるＬ６の障害（図４のイベント履歴番号１）の発生時刻から、ＬＳＰ１が回復（図４のイベント履歴番号４）した時刻までを、パケット紛失の可能性がある時間（ダウンタイム）として、顧客であるＶＰＮ１に知らせる。後者の場合、原因となるＬ６の障害（図４のイベント履歴番号５）の発生時刻から、ＬＳＰ１の経路変更（図４のイベント履歴番号６）の発生時刻までを、ダウンタイムとしてＶＰＮ１に教える。

以上に説明した例では、相関関係分析部１６０は、ユーザ提示情報作成部１７０から依頼されたことをトリガとして、相関関係を分析していたが、イベント通知受信部１２０がイベント通知を受信したことをトリガとして、相関関係を分析することも可能である。この場合は、図１０に示すように、各イベントの情報として、派生先や派生元のイベントの履歴番号をも記憶することが可能である。

イベント履歴記憶部１５０に、図１０のような派生先及び派生元のイベント履歴番号を書き込むために、相関関係を分析する方法は、図２〜４で説明したものと同様である。なお、図１０では、ＶＰＮについてのイベントも分析の対象とする場合を省略してあるが、図７〜９と同様に、実施することができる。また、イベント通知の受信をトリガとして相関関係を分析する場合の分析の方法としては、例えば、次の二通りがあり得る。

一つは、イベント通知が受信されたときに、そのイベントの派生元及び派生先のイベントを、過去に受信され既にイベント履歴記憶部１５０に記憶されているイベントの中から探索するというものである。該当するイベントが存在する場合には、その過去のイベントのエントリに、今受信されたイベントの履歴番号を派生先又は派生元として書き込むとともに、今受信されたイベントのエントリを作成して、派生元又は派生先のイベントとして探索で発見されたイベントの履歴番号を書き込む。

しかし、上記の方法は、現時点で受信されたイベントについては、派生先か派生元のいずれかのイベントが、まだ受信されていない状態にあることから、二重の処理負荷がかかる可能性がある。そこで、もう一つの方法は、現時点よりも多少過去に遡った時点を終了時点とするそれより過去の所定期間のイベントについて、派生元及び派生先についてまとめて相関関係を分析し、結果として求められたイベントの履歴番号をイベント履歴記憶部１５０の既存エントリに書き込むという作業を、所定期間毎に繰り返すというものである。どの程度過去に遡った時点までとするかは、原因イベントが受信されてから派生先のイベントが受信されるまでに通常かかる時間に基づいて定めればよい。

図２〜４で説明したユーザ提示情報作成部１７０から依頼されたときに分析する方法は、依頼に関係するイベントを対象に実行されるため、トータルでの負荷は比較的少ないが、依頼されてから分析を開始するので、結果をユーザに返すまでにある程度時間がかかることになる。一方、図１０で説明したイベント通知受信部１２０によりイベント通知を受信しながらすべてのイベントについて相関関係を分析して、結果を記憶しておく方法は、ユーザに対するレスポンスは早くなるが、常時相関関係を分析する負荷がかかることになる。いずれの方法を採用するかは、ユーザ（ネットワーク管理者）が状況に応じて決めてもよいし、監視装置１００の設計者が決めた一つの方法を装置に予め作り込んでおいてもよい。

次には、ネットワーク３００の構成要素として、リンク（ポート）と、ＩＰの経路と、ＬＤＰを用いて設定されたＬＳＰとを対象にし、ユーザ提示情報作成部１７０からイベント履歴記憶部１５０を検索するよう指示を受けたことをトリガとして、相関関係の分析を行う例を、図１１〜１４を参照しながら説明する。なお、イベント通知受信部１２０がイベント通知を受信したことをトリガとして、相関関係を分析する場合も、同様に実施できることはいうまでもない。

まず、リンク（ポート）と、ＩＰの経路（論理パスの一種）とを対象にする例を、図１２（ａ）と図１３を参照しながら説明する。この例でのネットワークトポロジーは、図１１において、ＬＳＰが設定されていないとしたものである。

図１１〜１４の例では、ＯＳＰＦやＩＳ−ＩＳ等の経路制御プロトコルで交換される情報が、ネットワーク内のノードから収集され、論理パス情報記憶部１４０に記憶される。ＯＳＰＦやＩＳ−ＩＳの情報には、ネットワークトポロジーの情報が含まれている。ＯＳＰＦの場合には、ＬＳＡ（Link State Advertisement）情報がこれに当たり、図１２（ａ）に例示されるように、隣接ノードの組と、その隣接ノードを接続するリンクのコストの情報が含まれている。図１２（ａ）では省略してあるが、図１１に示されたリンク（Ｌ１〜Ｌ１０）の全てについて、コストの情報が記憶される。このようなトポロジー情報に基づいて、ＩＰ経路を計算によって求める方法としては、例えば、ダイクストラの計算方法や、特開２００５−３１１４５８号公報に開示された方法がある。同公報には、ＯＳＰＦやＩＳ−ＩＳの情報を収集するために、ネットワークに収集装置を設置することも説明されており、この収集装置は、監視装置１００がかねてもよい。

図１１に示すように、ルータＲ４とＲ５を接続するリンクＬ６に障害が発生した場合を考える。まず、ルータＲ４が、リンクＬ６の障害イベントを、監視装置１００に通知することにより、図１３の履歴番号１のイベントが記憶される。

リンクの障害イベントの通知を受信すると、相関関係分析部１６０は、その時点で論理パス情報記憶部１４０に記憶されている図１２（ａ）のトポロジー情報に基づいて、あり得る全ての始点ルータと全ての終点ルータの組について、それぞれ経路を計算し、その経路が上記障害の生じたリンクを含んでいれば、ＩＰ経路についての何らかのイベントが生じたと判断して、このＩＰ経路の（始点ルータ、終点ルータ）の組を、図１３のようなイベント履歴表とは別に設けた影響リスト（図示せず）に追加する。そして、イベント履歴記憶部１５０に新たにエントリを作成し、障害イベントが生じたと判断したＩＰ経路について、計算した経路等のイベント情報を書き込む。また、上記影響リストへのポインタを、リンクの障害イベントのエントリに書き込むようにしてもよい。

図１１の例において、説明の便宜上、始点／終点ルータになり得るのが、例えばＲ１，Ｒ５，Ｒ６，Ｒ８，Ｒ９であるとして、全ての組合せについてそれぞれ経路を計算し、障害の発生したＬ６を含むＩＰ経路をイベント履歴記憶部１５０に書き込むと、図１３の履歴番号２〜９のようになる（図１３では、書き込まれるＩＰ経路のうちの一部を示している）。図１３では、ＩＰ経路の始点ルータを「イベント通知ルータ」として便宜的に登録してあるが、ＩＰ経路の障害／変更イベントは、始点ルータから通知されるわけではなく、監視装置１００が収集したトポロジー情報に基づいて検出するものである。また、「イベント発生時刻」も、通知を受信した時刻又は通知に記入された時刻ではなく、監視装置１００における計算により、そのＩＰ経路が障害の発生したリンクを含むことが判明した時刻が、書き込まれる。対象種別は、ＯＳＰＦ−ＬＳＡと表してあり、監視装置１００の内部処理であるため、対象番号や対象名は、付けられていない。

ネットワーク構成上、途中のリンクがダウンしたときの迂回経路が用意されている場合は、新しいＯＳＰＦやＩＳ−ＩＳの情報が論理パス情報取得部１３０により取得される。この場合、取得された新たなトポロジー情報に基づき、上記影響リストに登録された（始点ルータ、終点ルータ）の組について、それぞれ迂回経路を計算する。迂回経路が求められなかったＩＰ経路については、既述のとおり、イベントの種類は「障害」であり、旧経路の情報が、イベント履歴記憶部１５０のエントリに書き込まれる（図１３のイベント履歴番号２，３，５，６）。迂回経路が求められたＩＰ経路については、イベントの種類を「変更」とし、旧経路の情報に加えて、新経路の情報も、イベント履歴記憶部１５０のエントリに書き込む（図１３のイベント履歴番号４）。但し、リンクの障害が回復すると、迂回経路から元の経路に戻ることも多いため、迂回経路に変更されるというイベントを「障害」、元の経路に戻るというイベントを「回復」ととらえれば、迂回経路が求められたＩＰ経路についても、イベントの種類を「障害」としても構わない（後述する図１４の例では「障害」としている）。

その後、Ｌ６の障害が回復すると、ルータＲ４が、Ｌ６の回復イベントを、監視装置１００に通知することにより、図１３の履歴番号１０のイベントが記憶される。そして、新しいＯＳＰＦやＩＳ−ＩＳの情報が論理パス情報取得部１３０により取得される。相関関係分析部１６０は、上記影響リストに登録された（始点ルータ、終点ルータ）の組について、論理パス情報記憶部１４０に記憶された新たな図１２（ａ）のトポロジー情報に基づき、それぞれ経路を計算する。そして、イベント履歴記憶部１５０に新たにエントリを作成し、回復イベントが生じたと判断したＩＰ経路について、計算した経路等のイベント情報を書き込む。障害が生じたと判断されたＩＰ経路が、同一経路で回復されることもあれば（図１３のイベント履歴番号２と１１、３と１２、６と１３）、別の経路で回復されることもある（図１３のイベント履歴番号５と１４）。図１３の例では、Ｌ６の障害発生時に変更されたＲ８→Ｒ６のＩＰ経路（図１３のイベント履歴番号４）は、Ｌ６の障害回復時に行った経路計算で、元に戻っていない（変更後の経路のままである）ため、回復イベントが生じたとは判断されず、イベント履歴記憶部１５０に書き込まれない。上記影響リストに登録された（始点ルータ、終点ルータ）の全ての組について上記の処理が終わると、上記影響リストは消去される（アクティブイベントがなくなる）。

なお、リンクについて障害イベントの通知を受信した後、新しいＯＳＰＦやＩＳ−ＩＳの情報が論理パス情報取得部１３０により取得される。障害の生じたリンクについて回復イベントの通知を受信したかどうかにかかわらず、この新たなトポロジー情報が取得されたときに、上記影響リストに登録された（始点ルータ、終点ルータ）の組について、新たなトポロジー情報に基づき、それぞれ経路を計算し、経路が変更されていたら、イベント履歴記憶部１５０に新たにエントリを作成し、変更又は回復イベントとして、新たに計算した経路等のイベント情報を書き込むようにしてもよい。取得された新たなトポロジー情報は、論理パス情報記憶部１４０に上書きされる。イベント履歴記憶部１５０では、障害のイベントに対応して古い経路情報が記憶され、回復のイベントに対応して新しい経路情報が記憶され、変更のイベントに対応して新旧両方の経路情報が記憶されるため、イベント毎に、そのイベントが発生した時点の経路情報が保存されることになる。

以上のようにして、図１３のような内容がイベント履歴記憶部１５０に記憶されれば、相関関係の分析とユーザへの提示は、図２〜９で説明したのと同様に、行うことができる。図１３には、論理パスのイベントとして、ＩＰ経路のみを例示したが、ＲＳＶＰ−ＬＳＰについてのイベント通知を受信すれば、これも一緒にイベント履歴として記憶し、相関関係分析の対象とすることは、勿論可能である。また、上記の例では、リンク（ポート）にイベントが発生したことが通知されると、監視装置１００において、ＩＰ経路を計算して、どのＩＰ経路に派生的にイベントが発生したかを調べるため、イベント履歴記憶部１５０に、ＩＰ経路のイベント発生を書き込む際に、図１０の例のように、派生元及び派生先のイベント履歴番号をも書き込むことは、容易に実行できる。

次に、リンク（ポート）と、ＬＤＰを用いて設定されたＬＳＰ（論理パスの一種）とを対象にする例を、図１２（ａ）（ｂ）と図１４を参照しながら説明する。この例でのネットワークトポロジーは、図１１のようにＬＳＰが設定されたものである。

図２〜４（ＲＳＶＰ−ＬＳＰ）の場合と、図１１〜１４（ＬＤＰ−ＬＳＰ）の場合との相違は、ＬＤＰ−ＬＳＰの場合、通常、ＬＳＰの始点ルータからは、ＬＳＰについてのイベント情報が監視装置１００へ通知されないという点である。また、ＬＤＰ−ＬＳＰの場合、通常、ＬＳＰの始点ルータは、ＬＳＰの経路情報も有していない。

上記の相違は、ＬＤＰ−ＬＳＰの設定方法に起因している。すなわち、ＲＳＶＰでは、各ＬＳＰの始点ノードと終点ノードとの間で制御メッセージが交換されるのに対し、ＬＤＰでは、隣接ノード間で複数のＬＳＰについての制御メッセージが一つのセッションで交換される。ＬＤＰのメッセージでは、ＬＳＰの情報として、終点ノードを表すＦＥＣ（Forwarding Equivalence Class）が交換されるため、このＦＥＣをＬＳＰ識別子として、イベント履歴記憶部１５０の「対象番号」の欄に記憶することができる。また、ＬＤＰでは、複数の始点ノードから一つの終点ノードへ向かうMultipoint-to-pointのＬＳＰが設定可能であるため、ＬＳＰの始点ノードは一意に定まらず、イベント履歴記憶部１５０の「イベント通知ルータ」の欄は空欄となる。

ＬＤＰ−ＬＳＰの経路は、ＯＳＰＦやＩＳ−ＩＳ等の経路制御プロトコルで交換されるＩＰ経路情報（例えば、図１１（ａ）に示される情報）によって決まるため、ＩＰの経路制御プロトコルで交換される情報の変更に注目することで、ＬＤＰ−ＬＳＰの経路変更を検出することができる。そして、ＬＤＰ−ＬＳＰの場合、始点ノードから終点ノードまでのＩＰ経路上の全ての隣接ノード間において、制御用のセッション（ＬＤＰセッション）が確立していることが、その始点ノードから終点ノードまでのＬＳＰが設定されているといえるための条件である。よって、上記のように求められるＩＰ経路上の隣接ノード間のＬＤＰセッションを監視することで、ＬＳＰの障害や回復のイベントを検出することができる。また、ＬＤＰ又はＢＧＰ等で交換される情報を収集することにより、ＬＳＰの情報（例えば、図１１（ｂ）に示される情報）を得ることができる。図１１（ｂ）の例では、各ＬＳＰをどのＶＰＮが使用するかの情報も、収集されている。上記のＩＰ経路情報やＬＳＰの情報は、論理パス情報取得部１３０により収集されて、論理パス記憶部１４０に記憶される。なお、ＬＤＰ−ＬＳＰの情報の収集については、特開２００５−２８６８１８号公報に説明された方法が採用できる。

図１１に示すように、ルータＲ４とＲ５を接続するリンクＬ６に障害が発生した場合を考える。この例では、Ｌ６を利用しているＬＤＰ−ＬＳＰ１（Ｒ１→Ｒ４→Ｒ５→Ｒ６）とＬＤＰ−ＬＳＰ２（Ｒ８→Ｒ４→Ｒ５→Ｒ９）に障害もしくは経路変更が生じるはずである。

まず、ルータＲ４が、リンクＬ６の障害イベントを、監視装置１００に通知することにより、図１４の履歴番号１のイベントが記憶される。リンクの障害イベントの通知を受信すると、相関関係分析部１６０は、その時点で論理パス情報記憶部１４０に記憶されている図１２（ａ）のトポロジー情報に基づいて、少なくとも図１２（ｂ）のＬＳＰ情報が示す（始点ルータ，終点ルータ）の組について、経路を計算する。図１２（ｂ）の例では、（Ｒ１，Ｒ６）（Ｒ３，Ｒ６）（Ｒ８，Ｒ９）（Ｒ４，Ｒ９）について、ＩＰ経路を計算する。ここで、使用ＶＰＮの情報が収集されていなくても、ＬＳＰは設定されている可能性もあるため、あり得る全ての始点ルータと全ての終点ルータの組のそれぞれについて、ＩＰ経路を計算し、各経路上の全ての隣接ルータ間でＬＤＰセッションが確立されている（始点ルータ，終点ルータ）の組をリストアップしてもよい。例えば、（Ｒ１，Ｒ６）であれば、Ｒ１−Ｒ４，Ｒ４−Ｒ５，Ｒ５−Ｒ６間の全てでＬＤＰセッションが確立されていれば、Ｒ１からＲ６までのＬＳＰが設定されていることになる。

上記のようにして求めた各（始点ルータ，終点ルータ）間の経路が上記障害の生じたリンクを含んでいれば、ＬＤＰ−ＬＳＰについての何らかのイベントが生じたと判断して、イベント履歴記憶部１５０に新たにエントリを作成し、まず、その経路（ＯＳＰＦ−ＬＳＡ）について障害イベントを記録する（図１４のイベント履歴番号２，３）。ここで、実際に通知を受信するわけではないが、ＩＰ経路の始点ルータを「イベント通知ルータ」として便宜的に登録し、監視装置１００における計算ないし判断の時刻を「イベント発生時刻」として便宜的に書き込むことは、図１３と同様である。

ネットワーク構成上、途中のリンクがダウンしたときの迂回経路が用意されている場合は、新しいＯＳＰＦやＩＳ−ＩＳの情報が論理パス情報取得部１３０により取得される。この場合、取得された新たなトポロジー情報に基づき、上記障害の生じたリンクを含んでいる（始点ルータ、終点ルータ）の組について、それぞれ迂回経路を計算する。迂回経路が求められたＩＰ経路については、旧経路の情報に加えて、新経路の情報も、イベント履歴記憶部１５０のエントリに書き込む（図１４のイベント履歴番号２，３）。

迂回経路が求められなかったＩＰ経路については、それに沿って設定されていたＬＤＰ−ＬＳＰについても障害が生じたものと判断して、イベント履歴記憶部１５０に新たにエントリを作成し、そのＬＤＰ−ＬＳＰについて障害イベントを記録する。迂回経路が求められたＩＰ経路については、新たな経路上の全ての隣接ノード間でＬＤＰセッションが確立されている状態であるか否かを調べる。ＬＤＰセッションが確立されていない部分があれば、新経路に沿ってはＬＤＰ−ＬＳＰは設定されないので、そのＬＤＰ−ＬＳＰについて障害イベントを記録する（図１４のイベント履歴番号４）。ＬＤＰセッションが全部分で確立されていれば、新経路に沿ってＬＤＰ−ＬＳＰが設定されるので、そのＬＤＰ−ＬＳＰについては障害イベントを記録しない（変更イベントとして記録してもよい）。図１１の例では、ＬＳＰ１の迂回経路Ｒ１→Ｒ２→Ｒ３→Ｒ６では、Ｒ１−Ｒ２間でＬＤＰセッションが確立されていないためにＬＳＰは設定されず、ＬＳＰ２の迂回経路Ｒ８→Ｒ２→Ｒ３→Ｒ９では、ＬＳＰが設定されると判断される。

その後、Ｌ６の障害が回復すると、ルータＲ４が、Ｌ６の回復イベントを、監視装置１００に通知することにより、図１４の履歴番号５のイベントが記憶される。そして、新しいＯＳＰＦやＩＳ−ＩＳの情報が論理パス情報取得部１３０により取得される。相関関係分析部１６０は、障害イベントが記録されているＩＰ経路（ＯＳＰＦ−ＬＳＡ）について、論理パス情報記憶部１４０に記憶された新たな図１２（ａ）のトポロジー情報に基づき、それぞれ経路を計算し、イベント履歴記憶部１５０に新たにエントリを作成して、回復イベントを記録する（図１４のイベント履歴番号６，８）。障害がアクティブであった間に迂回経路ができていた場合は、旧経路が存在するため、新旧両方の経路の情報が、イベント履歴記憶部１５０のエントリに書き込まれる。

そして、回復イベントが生じたＩＰ経路（ＯＳＰＦ−ＬＳＡ）について、新たな経路上の全ての隣接ノード間でＬＤＰセッションが確立されている状態であるか否かを調べる。ＬＤＰセッションが確立されていない部分があれば、新経路に沿ってはＬＤＰ−ＬＳＰは設定されないので、そのＬＤＰ−ＬＳＰについて障害イベントを記録する。ＬＤＰセッションが全部分で確立されていれば、新経路に沿ってＬＤＰ−ＬＳＰが設定されるので、同一ＬＤＰ−ＬＳＰについて障害イベントが記録されていれば（図１４のイベント履歴番号４）、そのＬＤＰ−ＬＳＰについては回復イベントを記録する（図１４のイベント履歴番号７）。同一ＬＤＰ−ＬＳＰについて障害イベントが記録されていなくても、経路が変わっていれば、変更イベントとして記録してもよい。

次に、ルータＲ４−Ｒ５間のＬＤＰセッションに障害が生じたとすると、ルータＲ４が、対象種別がＬＤＰセッション、対象番号がＬ６の障害イベントを、監視装置１００に通知することにより、図１４の履歴番号９のイベントが記憶される。

ＩP経路上のＬＤＰセッションがダウンすると、そこを経由する全てのＬＤＰ−ＬＳＰの通信が途絶えるものと、監視装置１００において判断される。障害の生じたリンクを利用するＬＤＰ−ＬＳＰは、上述したように、図１２（ａ）のトポロジー情報を用いて計算されるＩＰ経路とＬＤＰセッションが確立しているか否かとに基づいて、求めることができる。この例では、監視装置１００は、イベント履歴記憶部１５０に新たにエントリを作成し、Ｌ６を通る全てのＬＤＰ−ＬＳＰについて障害イベントを記録する（図１４のイベント履歴番号１０，１１）。

その後、リンクＬ６のＬＤＰセッションが回復したとすると、ルータＲ４が、対象種別がＬＤＰセッション、対象番号がＬ６の回復イベントを、監視装置１００に通知することにより、図１４の履歴番号１２のイベントが記憶される。

ＩP経路上のＬＤＰセッションがアップすると、監視装置１００は、そこを経由する全てのＩＰ経路を、上述したように、図１２（ａ）のトポロジー情報を用いて計算する。そして、求められたＩＰ経路上で、アップした区間以外の区間でのＬＤＰセッションが全て確立しているか調べ、確立していれば、そのＩＰ経路に沿ったＬＤＰ−ＬＳＰが回復したものと判断する。この例では、監視装置１００は、イベント履歴記憶部１５０に新たにエントリを作成し、Ｌ６を通るＩＰ経路であって経路上の全ての隣接ノード間でＬＤＰセッションがアップになっているものを、ＬＤＰ−ＬＳＰの回復イベントとして記録する（図１４のイベント履歴番号１３，１４）。

このように、ＯＳＰＦ等のＩＰ経路情報とＬＤＰセッション情報の両方を用いて、ＬＤＰ−ＬＳＰについてのイベント発生を検出することができる。そうすると、この結果と、図１１（ｂ）の論理パス使用情報を比べれば、影響が及ぶＶＰＮを特定することができる。図１４の例では、ＬＤＰ−ＬＳＰ１の障害イベント（履歴番号４）や、その原因であるリンクの障害イベント（履歴番号１）の発生時刻からＬＤＰ−ＬＳＰ１の回復（履歴番号７）までのダウンタイム等を、ＶＰＮ１に知らせたり、ＬＤＰ−ＬＳＰ２の障害イベント（履歴番号１１）や、その原因であるＬＤＰセッションの障害イベント（履歴番号９）の発生時刻からＬＤＰ−ＬＳＰ２の回復（履歴番号１４）までのダウンタイム等を、ＶＰＮ２に知らせたりすることができる。

以上のようにして、図１４のような内容がイベント履歴記憶部１５０に記憶されれば、相関関係の分析とユーザへの提示は、図２〜９で説明したのと同様に、行うことができる。その他、図１３について説明したことは、図１４についても同様に行うことができる。また、ＬＤＰ−ＬＳＰのイベントは、ＯＳＰＦ−ＬＳＡについてのイベント履歴とＬＤＰセッションについてのイベント履歴が保存してあれば、それらを基に、後で相関関係を分析するときにでも求めることができるから、イベント履歴記憶部１５０に記憶しなくても構わない。

以上詳述してきたように、監視装置１００を用いれば、物理Ｉ／Ｆ（ポート）→リンク→ＬＳＰ→ＶＰＮの順に、物理的から論理的に移行する構成要素を対象として、原因イベント（物理的な構成要素）から派生するイベント（影響の出るＶＰＮ（顧客／サービス）まで）を探索したり、派生先イベント（論理的な構成要素）から派生元（原因）イベントを特定したりすることが、可能になる。

図１５は、本発明の一実施形態に係る計画工事管理機能付き監視装置２００の内部構成例を示す図である。図１の監視装置１００に対して、計画工事管理部２８０と、計画工事記憶部２９０が付加されている。以下では、監視装置２００について、監視装置１００と相違する部分を中心に説明するが、それ以外の部分の動作や機能は、監視装置１００について説明したのと同様になる。

計画工事管理部２８０は、図１７に示す計画工事の事前投入画面により、ユーザが予め入力する計画工事情報を、図１６に示されるように、計画工事記憶部２９０に記憶する。計画工事記憶部２９０に記憶される計画工事は、物理的な構成要素についてのものとする。物理的とは、例えば、ノード（ネットワーク機器）やリンク（回線）、ネットワーク機器内のポートやボードを意味する。つまり、図１７に示す計画工事の事前投入画面では、物理オブジェクトを選び、それとともに工事の開始予定日時と終了予定日時を入力する。

計画工事記憶部２９０には、物理的な計画工事の情報のみが記憶されているが、イベント通知受信部２２０では、論理的なパスに関するイベント通知も受信される。この論理的なパスに関するイベント通知が、計画工事を原因とするものであるかどうかを、物理的な計画工事の情報と、論理パス情報記憶部２４０に記憶されている論理パスの情報とを用いて、決定する。例えば、計画工事の場所を「リンク」で登録した場合、登録されたリンクの障害を計画工事によるものと判断するとともに、そのリンクを経由するＬＳＰ等のＩＰ経路や、そのＩＰ経路を使用するＶＰＮ等のサービスの関連する構成要素の障害を、計画工事を原因とするものと分類する。

この分類は、相関関係分析部２６０によりなされる。一つの方法としては、イベント通知受信部２２０がイベント通知を受信すると、相関関係分析部２６０が、相関関係を分析することによりその受信されたイベントの派生元を求め、その受信されたイベントあるいは求められた派生元のイベントが、計画工事記憶部２９０に計画工事として登録されているか確認する。もし、計画工事として登録されていた場合には、ユーザ提示情報作成部２７０がユーザに提示するイベント情報、及び／又は、イベント履歴記憶部２５０に記憶されるイベント情報に、計画工事イベントであることを示す印をつける。

もう一つの方法としては、計画工事管理部２８０が、計画工事が予定通りに開始されたことを相関関係分析部２６０に伝えると、相関関係分析部２６０が、相関関係を分析することにより計画工事として登録されたイベントの派生先を求めて、一時的に保持しておく。そして、イベント通知受信部２２０が、一時的に保持されているイベントについての通知を受信した場合には、その受信されたイベントに、計画工事イベントであることを示す印をつける。なお、計画工事開始後に、論理パス情報に変更があった場合には、イベントの派生先が変わる可能性があるため、その分については相関関係を再分析して、一時的に保持しておくイベントを変更する。

図１８は、通知されたイベント群及びその原因となる計画工事、もしくは、計画工事及びそれから派生して通知されたイベント群をユーザに提示するために、ユーザ提示情報作成部２７０により作成され表示画面に表示される内容の一例を示す図である。計画工事を予め投入することで、現時点で発生している（障害が解決されていない）イベント（アクティブイベント）が、どの計画工事に起因するものかが表示される。逆に、計画工事に関わるアクティブイベントが、どれになるかも表示される。図１８の例では、アクティブイベントを基礎にして表示する場合、計画工事に関連しないアクティブイベントも含めて表示し、計画工事に関連するアクティブイベントについては原因となる計画工事を表示している。計画工事を基礎にして表示する場合は、それぞれの計画工事に関連するアクティブイベントを表示している。

図１８の例では、アクティブイベントと計画工事の対応関係を表示しているが、過去のイベントと計画工事の対応関係も同様に表示することができる。図１９は、計画工事に関連するイベントを表示する別の例を示すものであり、既に開始されて終了したある計画工事に関連してイベント履歴記憶部に記憶されたイベントをまとめてユーザに提示するために、ユーザ提示情報作成部２７０により作成され表示画面に表示される内容の一例を示している。図１９の例とは逆に、イベント履歴記憶部に記憶されたイベントのリストを表示し、リスト中のイベントの原因となる計画工事を表示することも可能である。

図１６〜１７の例では、計画工事の情報として、工事の開始予定日時及び終了予定日時を入力、記憶しているが、終了予定日時はなくても構わない。工事の開始は予定どおりに行われることが多いのに比べて、工事の終了する時点は実際の作業内容によって予定を前後することが多いことから、終了予定日時の管理は、例えば、次の三通りのいずれかの方法により行う。一つ目は、終了予定日時を入力、記憶しておき、実際の工事の作業もその日時に終了したものとみなして管理する方法であり、ユーザの入力処理が一度で済む利点がある。二つ目は、終了予定日時を入力、記憶するが、実際の工事の作業が終了するときにもユーザが日時を入力する方法であり、実際の終了日時を用いることによって、イベントと計画工事との対応関係を、より正確に求めることができる利点がある。三つ目は、終了予定時刻は入力、記憶せず、実際の工事の作業が終了するときにユーザが日時を入力する方法である。ユーザが日時を入力する方法としては、例えば、キーボードやマウス等で日時を入れる方法や、計画工事完了ボタンを押すと、そのときの時刻が登録される方法がある。

以下には、障害予測についての実施形態を記述する。例えば、1つのリンクが故障すると、その両端のノードのポートについて障害通知があるはずであり、同様に、１つのリンクが故障すると、そのリンクを経由しているＬＳＰについて障害通知があるはずである。さらに、ＬＳＰが故障すると、そのＬＳＰを使用しているサービスについて障害通知があるはずである。この障害通知を受信しない場合には、ルータのバグ等により正常な動作が起こらなかった可能性がある。

そこで、特定の障害があった場合にあるはずのそれに関連する障害通知が受信されない場合には、ユーザに、ルータのバグ等により正常動作が行われなかった可能性があること（異常）を知らせるというのが、一つの方式である。そして、関連する障害通知が受信されない場合に、その障害通知を送信すべきノードに対して、ポーリングして確認するというのが、もう一つの方式である。これら二つの方式の方式を組み合わせ、ポーリングしてもなお返答が来ない場合に、ユーザに異常を知らせるように実施することも可能である。

図２０は、本発明の一実施形態に係る障害予測機能付き監視装置４００の内部構成例を示す図である。図１の監視装置１００に対して、ポートイベント管理部４８０と、ポーリング実行部４９０が付加されている。但し、ユーザに異常を知らせるだけでよければ、ポーリング実行部４９０はなくても構わない。また、監視装置４００では、ポートについての障害予測を行うだけであれば、ＬＳＰ等の論理パスの情報は取得、記憶しなくてもよいため、単にパス情報取得部４３０、パス情報記憶部４４０と表記してあるが、勿論、監視装置１００と同様に論理パスの情報を取得、記憶してもよい。監視装置４００の相関関係分析部４６０は、受信されるべきイベント通知を予測するものであるが、監視装置１００の相関関係分析部１６０の受信されたイベント通知間の相関関係を分析する機能を含んでいてもよい。以下では、監視装置４００について、監視装置１００と相違する部分を中心に説明するが、それ以外の部分の動作や機能は、監視装置１００について説明したのと同様になる。

図２１に示すように、リンクは、ルータに接続する二つのポートで構成される。一方のポートについての障害通知が受信されれば、基本的に、もう一方のポートについても障害通知が受信されるはずである。一方しか障害通知が受信されないときには、障害通知が途中で紛失して届かなかった（ＳＮＭＰトラップが、信頼性のない通信プロトコルであるＵＤＰ上で動作している場合、届かなくても再送されない）か、障害通知を送出すべきルータの障害であることの推測ができる。回復通知についても同様である。

図２２〜２４には、ポートについての障害予測を行う例を示す。図２２（ａ）は、監視装置４００のパス情報記憶部４３０に記憶されるリンク−ポート対応情報の一例であり、図２３は、イベント履歴記憶部４５０に記憶されるイベント情報の一例である。パス情報記憶部４３０に記憶される情報は、パス情報取得部４３０又はイベント通知受信部４２０によりネットワーク３００から収集され、例えば、リンクＬ６の両端のノードのポートが（Ｒ４，ｐ１）と（Ｒ５，ｐ２）であることを示す。イベント履歴記憶部４５０に記憶される情報は、イベント通知受信部４２０がネットワーク３００内のノードから受信した通知が示すイベントの情報であり、ポートの障害／回復イベントのほか、ＲＳＶＰ−ＬＳＰのイベントを記憶してもよい。

監視装置４００の相関関係分析部４６０とポートイベント管理部４８０は、例えば、図２４のフローチャートに示されるように、障害予測に関する処理を定期的に繰り返す。初期化処理として、イベント履歴ポインタの値を０にする（Ｓ３００）。相関関係分析部４６０は、イベント履歴ポインタが示す履歴番号を有するイベント情報を、イベント履歴記憶部４５０から検索する機能を有する。

まず、イベント履歴ポインタを１つ増加して、そのポインタが示す履歴番号のイベントを探索する（Ｓ３０５）。イベント履歴記憶部４５０（図２３）にそのイベントが存在すれば（Ｓ３１０Ｙｅｓ）、「対象種別」の欄を参照することにより、ポートについてのイベントかどうか調べる。ポートについてのイベントであれば（Ｓ３２０Ｙｅｓ）、ポートイベント管理部４８０で管理される管理表を参照する（Ｓ３２５）が、最初は何も登録されていないため（Ｓ３３０Ｎｏ）、ポートイベント管理表に、現在のイベント履歴ポインタが示しているイベントの履歴番号とポートの識別子（「イベント通知ルータ」と「対象番号」）を登録する（Ｓ３４０）。図２２（ｂ）は、ポートイベント管理表の一例を示し、ポートについての障害イベントである履歴番号１のイベントのポート識別子（Ｒ４，ｐ１）が登録されている。

次に、イベント履歴ポインタを１つ増加して、そのポインタが示す履歴番号のイベントを探索する（Ｓ３０５）。イベント履歴記憶部４５０（図２３）にそのイベントが存在し（Ｓ３１０Ｙｅｓ）、それがポートについてのイベントであれば（Ｓ３２０Ｙｅｓ）、ポートイベント管理部４８０で管理される管理表を参照する（Ｓ３２５）。すなわち、ポートイベント管理表（図２２（ｂ））に登録されているポート（例えばＲ４，ｐ１）をキーにして、パス情報記憶部４４０に記憶されているリンク−ポート対応表（図２２（ａ））を検索し、ポートイベント管理表（図２２（ｂ））に登録されているポートに対応するポート（例えばＲ５，ｐ２）を得る。このとき、現在のイベント履歴ポインタが示しているイベントが障害イベントであれば、ポートイベント管理表に登録されているポートのうち、その履歴番号のイベントが障害イベントであるポートをキーにし、現在のイベント履歴ポインタが示しているイベントが回復イベントであれば、ポートイベント管理表に登録されているポートのうち、その履歴番号のイベントが回復イベントであるポートをキーにする。

そして、リンク−ポート対応表の検索により得られたポートが、現在のイベント履歴ポインタが示しているイベントのポート識別子と一致すれば（Ｓ３３０Ｙｅｓ）、一方のポートについての障害（又は回復）通知が受信された後、正常に、もう一方のポートについても障害（又は回復）通知が受信されたことが分かるので、ポートイベント管理表（図２２（ｂ））に登録されている対応ポートのエントリを削除する（Ｓ３３５）。例えば、イベント履歴ポインタが２のときは、履歴番号２のイベントのポート識別子が（Ｒ５，ｐ２）で、リンク−ポート対応表の検索により得られたポートと一致するので、ポートイベント管理表に登録されている対応ポート（Ｒ４，ｐ１）のエントリを削除する。

リンク−ポート対応表の検索により得られたポートが、現在のイベント履歴ポインタが示しているイベントのポート識別子と異なる場合は（Ｓ３３０Ｎｏ）、新たなポートについての障害（又は回復）通知が受信されたことが分かるので、ポートイベント管理表に、現在のイベント履歴ポインタが示しているイベントの履歴番号とポート識別子を登録する（Ｓ３４０）。つまり、この例では、ポートイベント管理表にポート識別子が登録されていることが、未だ対応ポートのイベント通知が受信されていない状態であることを意味する。

上記の処理を、そのときまでにイベント履歴記憶部４５０に蓄積された全てのイベントについて行うと、イベント履歴ポインタを１つ増加して、そのポインタが示す履歴番号のイベントを探索しても（Ｓ３０５）、イベントが存在しなくなる（Ｓ３１０Ｎｏ）ため、イベント履歴ポインタを１つ戻し（Ｓ３１５）、ポートイベント管理表の各エントリを検査する（Ｓ３４５）。図２３の例では、履歴番号３で示されるポート（Ｒ４，ｐ１）の回復イベントについて、対応ポート（Ｒ５，ｐ３）の回復イベントが受信されていないので、ポートイベント管理表には、履歴番号３、ポート（Ｒ４，ｐ１）のエントリが残っている。

具体的には、ポートイベント管理表にポートが登録されているイベントのうち、その発生時刻が処理開始時刻（もしくは現在時刻）から所定時間以上前になっているものを、イベント履歴記憶部４５０を参照して探索する。そのようなイベントのエントリが発見されたら、未だ対応ポートのイベント通知が受信されていない状態が所定時間以上続いているということを意味しているので、ユーザに、対応ポートについての異常の可能性を知らせる。ユーザに知らせる方法は、直接ユーザ提示情報作成部４７０を起動して、警告を表示してもよいし、後述する図２８のように、異常の可能性を「障害（予測による）」という種別のイベントとして、イベント履歴記憶部４５０に記憶することにより、図５〜６や図１８〜１９のように表示してもよい。なお、障害イベントの通知が受信されない場合も、回復イベントの通知が受信されない場合も、同じ「障害（予測による）」という種別のイベントとして扱って構わない。

ユーザに知らせるための処理が終了したら、所定時間待機し（Ｓ３５０）、その後また、待機している間に新たにイベント履歴記憶部４５０に蓄積されたイベントについて、上記の処理を開始する。

図２１の例では、リンクＬ６を通るＲＳＶＰ−ＬＳＰが２つ設定されている。ポート（リンク）についての障害通知が受信されれば、基本的に、そのリンクを通る全てのＬＳＰについても障害通知（又は変更通知）が受信されるはずである。これらのうち、いずれかの障害通知が受信されないときには、障害通知が途中で紛失して届かなかったか、障害通知を送出すべきルータの障害であることの推測ができる。回復通知についても同様であり、ポート（リンク）についての回復通知が受信されれば、基本的に、そのリンクを通っていたＬＳＰであって経路が変更されていないもの全てについても回復通知が受信されるはずである。

図２５〜２７には、ＬＳＰについての障害予測を行う例を示す。図２５（ａ）は、監視装置４００のパス情報記憶部４３０に記憶されるＬＳＰ経路情報の一例であり、図２６は、イベント履歴記憶部４５０に記憶されるイベント情報の一例である。パス情報記憶部４３０に記憶される情報は、パス情報取得部４３０又はイベント通知受信部４２０によりネットワーク３００から収集され、例えば、ＲＳＶＰ−ＬＳＰ１の経路がＲ１→Ｒ４→Ｒ５→Ｒ６であり、ＲＳＶＰ−ＬＳＰ２の経路がＲ４→Ｒ５→Ｒ６であることを示す。イベント履歴記憶部４５０に記憶される情報は、イベント通知受信部４２０がネットワーク３００内のノードから受信した通知が示す、ポートの障害／回復イベントや、ＲＳＶＰ−ＬＳＰの障害／回復イベントである。

監視装置４００の相関関係分析部４６０とポートイベント管理部４８０は、例えば、図２７のフローチャートに示されるように、障害予測に関する処理を定期的に繰り返す。初期化処理として、イベント履歴ポインタの値を０にする（Ｓ６００）。相関関係分析部４６０は、イベント履歴ポインタが示す履歴番号を有するイベント情報を、イベント履歴記憶部４５０から検索する機能を有する。

まず、イベント履歴ポインタを１つ増加して、そのポインタが示す履歴番号のイベントを探索する（Ｓ６０５）。イベント履歴記憶部４５０（図２６）にそのイベントが存在すれば（Ｓ６１０Ｙｅｓ）、「対象種別」の欄を参照することにより、ＬＳＰについてのイベントかどうか調べる。ＬＳＰについてのイベントでなければ（Ｓ６２０Ｎｏ）、ポートについてのイベントであるかどうか調べる。ポートについてのイベントであれば（Ｓ６３０Ｙｅｓ）、ポートイベント管理部４８０で管理される管理表に、現在のイベント履歴ポインタが示しているイベントの履歴番号とポートの識別子（「イベント通知ルータ」と「対象番号」）を登録する（Ｓ６３５）。

ポートイベント管理表にポートを登録するとき、パス情報記憶部４４０に記憶されているＬＳＰ経路表（図２５（ａ））を検索することにより、そのポート（リンク）を経由している全てのＬＳＰを得て、そのＬＳＰ識別子を登録する。図２５（ｂ）は、ポートイベント管理表の一例を示し、イベント履歴番号１と、ポート識別子（Ｒ４，ｐ１）と、そのポート（リンク）を利用するＬＳＰ１，ＬＳＰ２が登録されている。

次に、イベント履歴ポインタを１つ増加して、そのポインタが示す履歴番号のイベントを探索する（Ｓ６０５）。イベント履歴記憶部４５０（図２６）にそのイベントが存在し（Ｓ６１０Ｙｅｓ）、それがＬＳＰについてのイベントであれば（Ｓ６２０Ｙｅｓ）、ポートイベント管理表において、そのＬＳＰ識別子が記入されているエントリを検索する（Ｓ６２５）。このとき、現在のイベント履歴ポインタが示しているイベントが障害（又は変更）イベントであれば、ポートイベント管理表に登録されている履歴番号のポートイベントが障害イベントであるエントリを、現在のイベント履歴ポインタが示しているイベントが回復イベントであれば、ポートイベント管理表に登録されている履歴番号のポートイベントが回復イベントであるエントリを、検索する。

そして、現在のイベント履歴ポインタが示しているイベントのＬＳＰ識別子を、検索されたポートイベント管理表のエントリから削除する。ポートイベント管理表の一つのエントリに記入されていたＬＳＰ識別子が全て削除されたら、そのエントリを削除する。例えば、イベント履歴ポインタが３のときは、履歴番号３のイベントのＬＳＰ識別子がＬＳＰ１なので、ポートイベント管理表に登録されているＬＳＰ１，ＬＳＰ２のうち、ＬＳＰ１を削除する。図２６では、受信されていない例が示されているが、ＬＳＰ２についての障害イベントの通知が、始点ノードであるＲ４から受信されれば、ポートイベント管理表に残っているＬＳＰ２も削除され、ＬＳＰの欄が空欄となった履歴番号１のエントリが、ポートイベント管理表から削除されることになる。

上記の処理を、そのときまでにイベント履歴記憶部４５０に蓄積された全てのイベントについて行うと、イベント履歴ポインタを１つ増加して、そのポインタが示す履歴番号のイベントを探索しても（Ｓ６０５）、イベントが存在しなくなる（Ｓ６１０Ｎｏ）ため、イベント履歴ポインタを１つ戻し（Ｓ６１５）、ポートイベント管理表の各エントリを検査する（Ｓ６４０）。

具体的には、ポートイベント管理表に登録されているイベントのうち、その発生時刻が処理開始時刻（もしくは現在時刻）から所定時間以上前になっているものを、イベント履歴記憶部４５０を参照して探索する。そのようなイベントのエントリが発見されたら、そのエントリに記入されたＬＳＰのイベント通知が未だ受信されていない状態が所定時間以上続いているということを意味しているので、ユーザに異常の可能性を知らせる。ユーザに知らせる方法は、直接ユーザ提示情報作成部４７０を起動して、警告を表示してもよいし、後述する図２８のように、異常の可能性を「障害（予測による）」という種別のイベントとして、イベント履歴記憶部４５０に記憶することにより、図５〜６や図１８〜１９のように表示してもよい。

ユーザに知らせるための処理が終了したら、所定時間待機し（Ｓ６４５）、その後また、待機している間に新たにイベント履歴記憶部４５０に蓄積されたイベントについて、上記の処理を開始する。

図２８には、上記のように検出された異常の可能性が、「障害（予測による）」という種別のイベントとして、イベント履歴記憶部４５０に記憶された例を示す。図２６の例では、履歴番号１，２で示されるリンクＬ６（ポートＲ４，ｐ１又はＲ５，ｐ２）の障害イベントについて、ＬＳＰ１の障害イベントは受信されている（履歴番号３）が、ＬＳＰ２の障害イベントは受信されていないため、ＬＳＰ２の「障害（予測による）」イベントが、履歴番号１０１として記憶される（図２８）。ここで、「イベント通知ルータ」としては、このイベントの通知を送信すべきルータ（ＲＳＶＰ−ＬＳＰの始点ノード）Ｒ４が記入される。「イベント発生時刻」は、図２７の処理（例えばＳ６４０）が実行された時刻でも、障害予測の元となったイベント（履歴番号１）の発生時刻から所定時間経過した時刻でもよく、便宜的に記入される。また、障害予測の元となったイベントの履歴番号も記憶される。イベントの内容（図５，６の表示参照）は、「未取得のＲＳＶＰ−ＬＳＰダウンイベントが検出されました」となる。

図２６の例では、また、履歴番号４で示されるポートＲ４，ｐ１（リンクＬ６）の回復イベントについて、もう一方のポートＲ５，ｐ２の回復イベントが受信されていないため、ポートＲ５，ｐ２の「障害（予測による）」イベントが、履歴番号１０２として記憶される（図２８）。「イベント通知ルータ」としては、このイベントの通知を送信すべきルータＲ５が記入され、障害予測の元となったイベントとして、履歴番号４が記憶される。イベントの内容（図５，６の表示参照）は、「未取得のポートアップイベントが検出されました」となる。

図２８のようにイベント履歴記憶部４５０に記憶された「障害（予測による）」イベントは、図２６のように記憶されたイベントや、イベント履歴記憶部１５０、２５０に記憶されたイベントと同様に、ユーザ提示情報作成部４７０を介して、表示画面に表示できる。「障害（予測による）」イベントに対応する回復イベントが通知もしくは入力されれば、解決済みのイベントになるが、それまではアクティブイベントとして扱われ、図５〜６及び図１８〜１９に関して説明したいずれの表示方法でも適用できる。イベント内容にいう「未取得のＲＳＶＰ−ＬＳＰ」や「未取得のポート」は、「対象番号」により特定され、図２のようなネットワークトポロジーのマップ表示上に可視化することもできる。

上記の例では、ポートのイベント通知が受信された場合に、関連するＬＳＰについてのイベント通知が受信されたか否かを調べているが、同様な手法で、ＬＳＰのイベント通知が受信された場合に、原因となるポートのイベント通知が受信されたか否か、引いてはそのポートのイベントに関連する他のＬＳＰのイベント通知が受信されたか否かを調べることも可能である。また、上記では、ＲＳＶＰ−ＬＳＰの例を説明したが、ＬＤＰ−ＬＳＰやＩＰ経路（ＯＳＰＦ−ＬＳＡ）についても、同様に処理可能である。さらに、ＬＳＰ等の論理パスを使用する主体（ＶＰＮ）についてもイベント通知を受信する構成の場合は、関連するＶＰＮについてのイベント通知が受信されたか否かを調べることによっても、異常の可能性を検出できる。

最後に、障害予測を応用して、ネットワークの負荷を低減しつつ、ポーリングによりネットワークの現在の状況を的確に把握するための実施形態を記述する。一般に、ネットワーク機器の障害は、ＳＮＭＰトラップにより、障害が生じたときに、ネットワーク機器から通知される。但し、ＳＮＭＰトラップは、上述したようにＵＤＰ上で動作している場合、必ず届くとは限らないため、従来の方式では、監視装置から定期的にポーリングすることで、これを補完している。

しかし、ポーリングを定期的に行うと、ネットワーク機器および監視装置の両方に負荷がかかるため、ポーリング間隔を短くすることは難しく、一方、ポーリング間隔を長くすると、障害の検出が遅くなってしまう。そこで、以上に説明してきた障害予測に基づいて、受信されるはずの障害通知が受信されないときに、そのネットワーク機器に対してポーリングすれば、上記の問題を解決することができる。そのための監視装置４００の構成としては、図２０に示したものを用いることができる。

この処理は、例えば、図２９に示すフローチャートにより行なうことができる。定期的に、図２４及び／又は図２７で説明した処理が実行されるところ（Ｓ８００）、イベント履歴記憶部４５０に「障害（予測による）」イベントが書き込まれたことをトリガとして（Ｓ８０５Ｙｅｓ）、ポートイベント管理部４８０が、ポーリング実行部４９０を起動する。そして、受信されるべきなのに受信されていない障害又は回復イベントの通知を送信すべきネットワーク構成要素に対して、ポーリングを行う（Ｓ８１０）。

ポートについての障害通知が受信されないときには、そのポートのノードに対してポーリングし、ＬＳＰについての障害通知が受信されないときは、そのＬＳＰについてのポーリングを行う（ＲＳＶＰ−ＬＳＰであれば、始点ノードに対してポーリングする）。ポーリングは、例えば、監視装置からネットワーク構成要素に対してＳＮＭＰ要求を送り、その応答を受けることにより実装できるが、ＳＮＭＰのほかにも、ＣＬＩ（Command Line Interface）、ＸＭＬ（eXtensible Markup Language）等によっても実装できる。

ポーリングに対して応答が返ってこないか、返ってきた応答がエラーを示していた場合、ポーリング結果が正常でなかったものと判断し（Ｓ８１５Ｎｏ）、障害通知として処理する（Ｓ８２０）。具体的には、直接ユーザ提示情報作成部４７０を起動して、警告を表示してもよいし、「障害」イベントとしてイベント履歴記憶部４５０に改めて記憶し、アクティブイベントとして図５〜６や図１８〜１９のように表示してもよい。

以上、本発明の実施形態について説明したが、上述の実施形態を本発明の範囲内で当業者が種々に変形、応用して実施できることは勿論である。

本発明を利用することにより、例えば、ネットワーク管理者は、ある構成要素について生じた１つのイベントを原因として派生的に他の構成要素についてイベントが生じる場合に、これら一連のイベントをまとめて把握することができ、影響を受ける顧客又はサービス等についても知ることができる。また、計画工事を原因として生じた関連イベントを、それ以外のイベントはと一見して区別することも可能になる。さらに、生じるはずの関連イベントについて通知が受信されないことを知り、新たな潜在的障害に対して適切な処置を施すことも可能になる。

本発明の一実施形態に係る監視装置１００の内部構成例を示す図。 本発明の一実施形態に係るネットワーク３００の構成要素と障害発生の一例を示す図。 論理パス情報記憶部１４０に記憶される論理パス情報の一例を示す図。 イベント履歴記憶部１５０に記憶されるイベント履歴情報の一例（ＲＳＶＰにより設定されるＬＳＰについてのイベントを扱う例）を示す図。 論理的な構成要素に生じたイベント及びその派生元イベントをユーザに提示するために、ユーザ提示情報作成部１７０により作成され表示画面に表示される内容の一例を示す図。 物理的な構成要素に生じたイベント及びその派生先イベント群をユーザに提示するために、ユーザ提示情報作成部１７０により作成され表示画面に表示される内容の一例を示す図。 本発明の一実施形態に係るネットワーク３００の構成要素と障害発生の別の例を示す図。 論理パス情報記憶部１４０に記憶される論理パス情報の別の例（ＬＳＰ経路表及び論理パス使用ＶＰＮ表）を示す図。 イベント履歴記憶部１５０に記憶されるイベント履歴情報の別の例（ＶＰＮについてのイベントを扱う例）を示す図。 イベント受信時に相関関係を分析する場合にイベント履歴記憶部１５０に記憶されるイベント履歴情報の内容の例を示す図。 本発明の一実施形態に係るネットワーク３００の構成要素と障害発生の更に別の例を示す図。 論理パス情報記憶部１４０に記憶される論理パス情報の更に別の例（ＯＳＰＦトポロジー及び論理パス使用ＶＰＮ表）を示す図。 イベント履歴記憶部１５０に記憶されるイベント履歴情報の更に別の例（ＯＳＰＦのＩＰ経路についてのイベントを扱う例）を示す図。 イベント履歴記憶部１５０に記憶されるイベント履歴情報の更に別の例（ＬＤＰにより設定されるＬＳＰについてのイベントを扱う例）を示す図。 本発明の一実施形態に係る計画工事管理機能付き監視装置２００の内部構成例を示す図。 計画工事記憶部２９０に記憶される計画工事情報の一例を示す図。 計画工事管理部２８０を介して計画工事情報を監視装置２００に入力するために、ユーザが使用する表示画面に表示される内容の一例を示す図。 通知されたイベント群及びその原因となる計画工事、もしくは、計画工事及びそれから派生して通知されたイベント群をユーザに提示するために、ユーザ提示情報作成部２７０により作成され表示画面に表示される内容の一例を示す図。 計画工事に関連する過去のイベント群をユーザに提示するために、ユーザ提示情報作成部２７０により作成され表示画面に表示される内容の一例を示す図。 本発明の一実施形態に係る障害予測機能付き監視装置４００の内部構成例を示す図。 本発明の一実施形態に係るネットワーク３００の構成要素と障害発生の更に別の例を示す図。 パス情報記憶部に記憶される情報の一例（リンク−ポート対応表）及びポートイベント管理部に記憶される情報の一例を示す図。 図２２に対応してイベント履歴記憶部に記憶されるイベント履歴情報の一例を示す図。 図２２の場合に障害予測を行うための処理手順の一例を示すフローチャート。 パス情報記憶部に記憶される情報の一例（ＬＳＰ経路表）及びポートイベント管理部に記憶される情報の一例を示す図。 図２５に対応してイベント履歴記憶部に記憶されるイベント履歴情報の一例を示す図。 図２５の場合に障害予測を行うための処理手順の一例を示すフローチャート。 図２７の障害予測に基づいてイベント履歴記憶部に記憶されるイベント履歴情報の一例を示す図。 障害予測を用いて選択的にポーリングを行うための処理手順の一例を示すフローチャート。

符号の説明

１００、２００、４００ 監視装置
３００ ネットワーク
１１０、２１０、４１０ ネットワークＩ／Ｆ
１２０、２２０、４２０ イベント通知受信部
１３０、２３０ 論理パス情報取得部
１４０、２４０ 論理パス情報記憶部
１５０、２５０、４５０ イベント履歴記憶部
１６０、２６０、４６０ 相関関係分析部
１７０、２７０、４７０ ユーザ提示情報作成部
２８０ 計画工事管理部
２９０ 計画工事記憶部
４３０ パス情報取得部
４４０ パス情報記憶部
４８０ ポートイベント管理部
４９０ ポーリング実行部

Claims (28)

1. ネットワークにおいて動的に設定されるパケット転送経路の情報を収集する収集手段と、
   前記ネットワークの構成要素についてイベントが生じたことを示す通知を受信する受信手段と、
   前記収集手段により収集されたパケット転送経路の情報に基づいて、前記受信手段により受信された複数の通知の相関関係を分析する分析手段とを備えたことを特徴とするネットワーク監視装置。
2. 前記受信手段により受信される通知が示すイベントの種類として、前記構成要素についての障害、障害の回復、及び変更のうちの少なくとも一つが存在することを特徴とする請求項１記載のネットワーク監視装置。
3. 前記分析手段は、前記収集手段により収集された複数の時点におけるパケット転送経路の情報のうち、前記受信手段により受信された通知により特定される時点に基づいてイベント発生時点におけるパケット転送経路であると推定できるものの情報を用いて、前記相関関係の分析を行うものであることを特徴とする請求項１記載のネットワーク監視装置。
4. 前記分析手段は、複数の通知のそれぞれが前記受信手段により受信された時点の前後関係とは関係なく、前記相関関係の分析を行うものであることを特徴とする請求項１記載のネットワーク監視装置。
5. 前記収集手段は、前記ネットワークを構成するノード間で交換されているルーティング情報を収集するものであり、
   前記分析手段は、前記ルーティング情報を用いて計算によりパケット転送経路を求め、求めたパケット転送経路に基づいて、前記相関関係の分析を行うものであることを特徴とする請求項１記載のネットワーク監視装置。
6. 前記収集手段は、前記ネットワークに設定されているラベルスイッチパスに関する情報を収集するものであり、
   前記分析手段は、ラベルスイッチパスについてのイベントと、該ラベルスイッチパスが経由するリンクについてのイベントとの間に、相関関係があると分析するものであることを特徴とする請求項１記載のネットワーク監視装置。
7. 前記受信手段により受信された通知が示すイベントの情報を履歴として記憶する記憶手段を更に備え、
   前記分析手段は、ユーザからの指示に応じて、前記記憶手段に履歴として記憶されたイベントの相関関係を分析し、分析結果をユーザに提示するものであることを特徴とする請求項１記載のネットワーク監視装置。
8. 前記受信手段により受信された通知が示すイベントの情報を履歴として記憶する記憶手段を更に備え、
   前記分析手段は、前記受信手段による受信に応じて、受信された通知が示すイベント及び前記記憶手段に記憶されたイベントの相関関係を分析するものであり、分析結果を前記記憶手段に記憶させるものであることを特徴とする請求項１記載のネットワーク監視装置。
9. 前記分析手段は、
   前記パケット転送経路の情報に基づいて、前記複数の通知から、相関関係を有する一連のイベント通知の原因となるイベントの発生を示す通知を、特定する手段と、
   前記パケット転送経路の情報に基づいて、前記原因となるイベントの発生によって派生的に他の構成要素に生じるイベントを求める手段とを含むことを特徴とする請求項１記載のネットワーク監視装置。
10. 前記収集手段は、前記パケット転送経路の情報に加えて、該パケット転送経路を使用する主体を示す情報を収集する手段を含み、
    前記分析手段は、前記主体を示す情報に基づいて、前記原因となるイベントの発生によって影響を受ける主体を特定する手段を含むことを特徴とする請求項９記載のネットワーク監視装置。
11. 前記原因となるイベントが障害である場合に、前記原因となる障害の発生を示す通知により特定される時点に基づいて、派生的にイベントが生じる前記他の構成要素についてのパケット不転送期間を推定する手段を更に備えたことを特徴とする請求項９記載のネットワーク監視装置。
12. 前記派生的に他の構成要素に生じるイベントの深刻度に応じて、該イベントの通知をユーザに提示する形態を異ならせる手段を更に備えたことを特徴とする請求項９記載のネットワーク監視装置。
13. 前記分析手段により求められた派生的に他の構成要素に生じるイベントが実際に生じたことを示す通知が、前記受信手段により受信されなかった場合に、ユーザに異常として提示する手段を更に備えたことを特徴とする請求項９記載のネットワーク監視装置。
14. 前記分析手段により求められた派生的に他の構成要素に生じるイベントが実際に生じたことを示す通知が、前記受信手段により受信されなかった場合に、該他の構成要素についてポーリングを行う手段を更に備えたことを特徴とする請求項９記載のネットワーク監視装置。
15. ネットワークにおいて動的に設定されるパケット転送経路の情報を収集する収集手段と、
    前記ネットワークの構成要素についてイベントが生じたことを示す通知を受信する受信手段と、
    前記ネットワークの構成要素について工事作業が計画されていることを作業開始の予定時点の情報とともに登録する登録手段と、
    前記収集手段により収集されたパケット転送経路の情報に基づいて、前記登録手段に登録された工事作業の実施と前記受信手段により受信されたイベント通知との相関関係を分析する分析手段とを備えたことを特徴とするネットワーク監視装置。
16. 前記分析手段は、前記受信手段によるイベント通知の受信に応じて、該受信により特定される時点における前記パケット転送経路の情報に基づき、前記通知が示すイベントの原因となるイベントが、前記工事作業の実施であるか否かを判断する手段を含むことを特徴とする請求項１５記載のネットワーク監視装置。
17. 前記分析手段は、前記工事作業の開始に応じて、該開始により特定される時点における前記パケット転送経路の情報に基づき、前記工事作業の実施によって派生的に他の構成要素に生じるイベントを求めて記憶しておき、前記受信手段によりイベント通知が受信された場合に、該通知が示すイベントが記憶された前記イベントであるか否かを判断する手段を含むことを特徴とする請求項１５記載のネットワーク監視装置。
18. ネットワークを構成する要素同士の関係を表す情報を収集する収集手段と、
    前記ネットワークの構成要素についてイベントが生じたことを示す通知を受信する受信手段と、
    前記収集手段により収集された情報に基づいて、前記受信手段により受信された通知が示すイベントが生じた場合に受信されるべき他の構成要素についての通知を求める分析手段と、
    前記分析手段により求められた他の構成要素についての通知が、所定時間内に前記受信手段により受信されたか否かを検出する管理手段とを備えたことを特徴とするネットワーク監視装置。
19. 前記管理手段により、他の構成要素についての通知が所定時間内に受信されなかったと判断された場合に、ユーザに異常として提示する手段を更に備えたことを特徴とする請求項１８記載のネットワーク監視装置。
20. 前記管理手段により、他の構成要素についての通知が所定時間内に受信されなかったと判断された場合に、該他の構成要素について検査をするためのメッセージを前記ネットワークへ送信する検査手段を更に備えたことを特徴とする請求項１８記載のネットワーク監視装置。
21. 前記検査手段により送信されたメッセージに対する応答に基づいて異常が検出された場合に、ユーザに異常を報知する手段を更に備えたことを特徴とする請求項２０記載のネットワーク監視装置。
22. 前記収集手段により収集される情報は、前記ネットワークにおいて直接接続されている要素の組の情報と、前記ネットワークにおいて動的に設定されるパケット転送経路の情報のうち、少なくともいずれかであることを特徴とする請求項１８記載のネットワーク監視装置。
23. ネットワークにおいて動的に設定されるパケット転送経路の情報を収集し、
    前記ネットワークの構成要素についてイベントが生じたことを示す通知を複数受信し、
    収集された前記パケット転送経路の情報に基づいて、受信された複数の前記通知の相関関係を分析することを特徴とするネットワーク監視方法。
24. ネットワークにおいて動的に設定されるパケット転送経路の情報を収集するための第１のプログラムコードと、
    前記ネットワークの構成要素についてイベントが生じたことを示す通知を受信するための第２のプログラムコードと、
    前記第１のプログラムコードを用いて収集されたパケット転送経路の情報に基づいて、前記第２のプログラムコードを用いて受信された複数の通知の相関関係を分析するための第３のプログラムコードとを含むことを特徴とするネットワーク監視プログラム。
25. 前記ネットワークの構成要素について工事作業が計画されていることを作業開始の予定時点の情報とともに登録するための第４のプログラムコードと、
    前記第３のプログラムコードに、前記第４のプログラムコードを用いて登録された計画工事に対応するイベントが生じたことを示す通知と、その他のイベントが生じたことを示す通知との相関関係を分析させるための第５のプログラムコードとを更に含むことを特徴とする請求項２４記載のネットワーク監視プログラム。
26. ネットワークを構成する要素同士の関係を表す情報を収集し、
    前記ネットワークの構成要素についてイベントが生じたことを示す通知を受信し、
    収集された前記関係を表す情報に基づいて、受信された前記通知が示すイベントが生じた場合に受信されるべき他の構成要素についての通知を求め、
    求められた前記他の構成要素についての通知が、所定時間内に受信されたか否かを検出することを特徴とするネットワーク監視方法。
27. ネットワークを構成する要素同士の関係を表す情報を収集するための第１のプログラムコードと、
    前記ネットワークの構成要素についてイベントが生じたことを示す通知を受信するための第２のプログラムコードと、
    前記第１のプログラムコードを用いて収集された情報に基づいて、前記第２のプログラムコードを用いて受信された通知が示すイベントが生じた場合に受信されるべき他の構成要素についての通知を求めるための第３のプログラムコードと、
    前記第３のプログラムコードを用いて求められた他の構成要素についての通知が、所定時間内に受信されたか否かを検出するための第４のプログラムコードとを含むことを特徴とするネットワーク監視プログラム。
28. 前記第４のプログラムコードを用いて、他の構成要素についての通知が所定時間内に受信されなかったと判断された場合に、該他の構成要素について検査をするためのメッセージを前記ネットワークへ送信するための第５のプログラムコードを更に含むことを特徴とする請求項２７記載のネットワーク監視プログラム。