(57)【特許請求の範囲】
【請求項１】
管理ネットワークに接続された複数のノードを含むネットワークにおいて、前記複数のノードの各々を構成する計算機により実施されるネットワーク分散監視方法であって、
前記複数のノードのうちの第１プローブノードの各々において、予め決められた複数の第１のアプリケーションのうちの対応する第１アプリケーションの対象ネットワーク上の第１トラヒックを検出して第１検出メッセージを生成することと、
前記対応する第１アプリケーションの種類を示す第１機能識別子だけに対する、あるいは前記第１機能識別子と前記第１トラヒックのアドレス情報とに対する第１ハッシュ値を決定することと、
前記第１ハッシュ値と前記第１トラヒックの第１ＤＡＴとから決定されるノード、前記第１ハッシュ値と前記管理ネットワークとに関して予め決められたノード、あるいは前記第１ハッシュ値と前記管理ネットワークとに関して動的に決定されるノードのうちのいずれかのノードに、前記第１検出メッセージを送信することと、
前記複数のノードのうちの第１メディエーションノードにおいて前記複数の第１の予め決められたアプリケーションに対する前記検出メッセージに第１機能識別子に対応するエントリに含まれるメディエーションタイプによって指定された処理を行う第１メディエーション処理をして第１メディエーション処理結果を生成することと、
前記複数のノードのうちの第１コレクタノードにおいて前記第１メディエーション処理結果を格納することと
を含む
ネットワーク分散監視方法。
【請求項２】
請求項１に記載のネットワーク分散監視方法であって、
前記第１検出メッセージを送信する際に、前記第１ハッシュ値から前記第１コレクタノードのノードＩＤを決定することと、
前記第１コレクタノードのノードＩＤと前記第１ＤＡＴとから送信先ノードを決定することと、
前記第１検出メッセージに、前記第１コレクタノードのノードＩＤを挿入することと
を更に含む
ネットワーク分散監視方法。
【請求項３】
請求項２に記載のネットワーク分散監視方法であって、
前記第１検出メッセージに含まれる前記第１コレクタノードのノードＩＤと、前記第１メディエーションノードが有するＤＡＴとに基づいて決まるノードに前記第１メディエーション処理結果を含む第１処理結果メッセージを送信することと、
前記第１メディエーション処理結果を格納する際に、前記第１メディエーションノードから受信される前記第１処理結果メッセージの処理結果を格納することと
を更に含む
ネットワーク分散監視方法。
【請求項４】
請求項１乃至３のいずれか一項に記載のネットワーク分散監視方法であって、
前記第１メディエーションノードは、前記第１コレクタノードと同一である
ネットワーク分散監視方法。
【請求項５】
請求項１乃至４のいずれか一項に記載のネットワーク分散監視方法であって、
前記複数のノードのうちの第２プローブノードの各々において、予め決められた複数の第２のアプリケーションのうちの対応する第２アプリケーションの前記対象ネットワーク上の第２トラヒックを検出して第２検出メッセージを生成することと、
前記対応する第２アプリケーションの種類を示す第２機能識別子だけに対応する、あるいは第２機能識別子と前記第２トラヒックのアドレス情報とに対応する第２ハッシュ値を決定することと、
前記第２ハッシュ値と前記管理ネットワークの第２ＤＡＴとから決定されるノードに、前記第２検出メッセージを送信することと、
前記複数のノードのうちの第２メディエーションノードにおいて前記複数の第２の予め決められたアプリケーションに対する前記検出メッセージに第２メディエーション処理をして第２メディエーション処理結果を生成することと、
前記複数のノードのうちの第２コレクタノードにおいて前記第２メディエーション処理結果を格納することと
を更に含む
ネットワーク分散監視方法。
【請求項６】
請求項５に記載のネットワーク分散監視方法であって、
前記第２検出メッセージを送信する際に、前記第２ハッシュ値から前記第２コレクタノードのノードＩＤを決定することと、
前記第２コレクタノードのノードＩＤと前記第２ＤＡＴとから送信先ノードを決定することと、
前記第２検出メッセージに、前記第２コレクタノードのノードＩＤを挿入することと
を更に含む
ネットワーク分散監視方法。
【請求項７】
請求項６に記載のネットワーク分散監視方法であって、
前記第２検出メッセージに含まれる前記第２コレクタノードのノードＩＤと、前記第２メディエーションノードが有するＤＡＴとに基づいて決まるノードに前記第２メディエーション処理結果を含む第２処理結果メッセージを送信することと、
前記第２メディエーション処理結果を格納する際に、前記第２メディエーションノードから受信される前記第２処理結果メッセージの処理結果を格納することと
を更に含む
ネットワーク分散監視方法。
【請求項８】
請求項５乃至７のいずれか一項に記載のネットワーク分散監視方法であって、
前記第２コレクタノードは、前記第１コレクタノードと同一である
ネットワーク分散監視方法。
【請求項９】
請求項５乃至８のいずれか一項に記載のネットワーク分散監視方法であって、
前記複数の第１のアプリケーションと前記複数の第２のアプリケーションが前記管理ネットワークを共有することと、
前記管理ネットワークを介して、前記複数の第１のアプリケーションと前記複数の第２のアプリケーションを監視することと
を更に含む
ネットワーク分散監視方法。
【請求項１０】
請求項１乃至９のいずれか一項に記載のネットワーク分散監視方法であって、
前記複数の第１のアプリケーションを、フィルタリング条件のデータに基づいて予め決めること
を更に含む
ネットワーク分散監視方法。
【請求項１１】
請求項１乃至１０のいずれか一項に記載のネットワーク分散監視方法であって、
前記対象ネットワーク上の各トラヒックのアドレス情報は、当該トラヒックの送信元ＩＰアドレス、送信先ＩＰアドレス、送信元ＵＲＩ、及び送信先ＵＲＩの少なくとも１つを含む
ネットワーク分散監視方法。
【請求項１２】
請求項１乃至１１のいずれか一項に記載のネットワーク分散監視方法であって、
ＤＨＴ／ＤＡＴでネットワークを構成することと、
ハッシュ値でコレクタを決定することと、
スケーラブルでありフォールトトレラントであるネットワークにおいて、異なる監視アプリケーションをサポートすることと
を更に含む
ネットワーク分散監視方法。
【請求項１３】
請求項１乃至１２のいずれか一項に記載のネットワーク分散監視方法であって、
前記第１ハッシュ値を、ハッシュ関数により決定することと、
前記第１メディエーション処理と該ハッシュ関数の入力を選択することにより、スケーラビリティを動的に制御することと
を更に含む
ネットワーク分散監視方法。
【請求項１４】
請求項１乃至１３のいずれか一項に記載のネットワーク分散監視方法であって、
前記複数のノードのうちのコレクタノードに、あるイベントに関係するパケットをキャプチャした全てのプローブノードに対して、ＤＡＴ上のノードを辿って詳細情報を問い合わせる機能を持たせること
を更に含む
ネットワーク分散監視方法。
【請求項１５】
請求項１４に記載のネットワーク分散監視方法であって、
前記複数のノードのうち、あるイベントに関係するパケットをキャプチャした全てのプローブノードに、ＤＡＴ上のノードを辿って詳細情報を前記複数のノードのうちのコレクタノードまで送信する機能を持たせること
を更に含む
ネットワーク分散監視方法。
【請求項１６】
請求項１４又は１５に記載のネットワーク分散監視方法であって、
各ノードに、イベントの種類、下位ノードＩＤ、イベントのカウント、イベントを受信した最初の時刻、イベントを受信した最後の時刻、の情報を持たせること
を更に含む
ネットワーク分散監視方法。
【請求項１７】
管理ネットワークに接続された複数のノードを含むネットワークにおいて、前記複数のノードの各々として計算機を機能させるための計算機読み取り可能なプログラムであって、
プローブノードとして計算機を機能させる際に、予め決められた複数のアプリケーションのうちの対応するアプリケーションの対象ネットワーク上のトラヒックを検出して検出メッセージを生成するステップと、
前記対応するアプリケーションの種類を示す機能識別子だけに対する、あるいはそれと前記トラヒックのアドレス情報とに対するハッシュ値を決定するステップと、
前記ハッシュ値と前記管理ネットワークの前記トラヒックのＤＡＴとから決定されるノード、前記ハッシュ値と前記管理ネットワークに関して予め決められた、あるいは動的に決定されるノードのうちのいずれかのノードに、前記検出メッセージを送信するステップと、
メディエーションノードとして前記計算機を機能させる際に、
前記複数の予め決められたアプリケーションに対する前記検出メッセージに機能識別子に対応するエントリに含まれるメディエーションタイプによって指定された処理を行うメディエーション処理をしてメディエーション処理結果を生成するステップと、
前記複数のノードのうちのコレクタノードに前記メディエーション処理結果を転送するステップと
を計算機に実行させるための
プログラム。
【請求項１８】
請求項１７に記載のプログラムであって、
前記アドレス情報は、前記トラヒックの送信元ＩＰアドレス、送信先ＩＰアドレス、送信元ＵＲＩ、及び送信先ＵＲＩの少なくとも１つを含む
プログラム。
【請求項１９】
請求項１７又は１８に記載のプログラムであって、
前記検出メッセージを送信する際に、前記ハッシュ値からコレクタノードのノードＩＤを決定するステップと、
前記コレクタノードのノードＩＤと前記ＤＡＴとから送信先ノードを決定するステップと、
前記検出メッセージに、前記コレクタノードのノードＩＤを挿入するステップと
を更に計算機に実行させるための
プログラム。
【請求項２０】
請求項１９に記載のプログラムであって、
前記コレクタノードとして前記計算機を機能させる際に、前記メディエーション処理結果を格納するステップ
を更に計算機に実行させるための
プログラム。
【請求項２１】
請求項２０に記載のプログラムであって、
前記検出メッセージに含まれる前記コレクタノードのノードＩＤと、前記メディエーションノードが有するＤＡＴとに基づいて決まるノードとして前記計算機を機能させる際に、前記メディエーション処理結果を含む処理結果メッセージを受信するステップと、
前記処理結果メッセージの前記メディエーション処理結果を格納するステップと
を更に計算機に実行させるための
プログラム。
【請求項２２】
請求項１７乃至２１のいずれか一項に記載のプログラムであって、
ＤＨＴ／ＤＡＴでネットワークを構成するステップと、
ハッシュ値でコレクタを決定するステップと、
スケーラブルでありフォールトトレラントであるネットワークにおいて、異なる監視アプリケーションをサポートするステップと
を更に計算機に実行させるための
プログラム。
【請求項２３】
請求項１７乃至２２のいずれか一項に記載のプログラムであって、
前記ハッシュ値を、ハッシュ関数により決定するステップと、
前記メディエーション処理と該ハッシュ関数の入力を選択することにより、スケーラビリティを動的に制御するステップと
を更に計算機に実行させるための
プログラム。
【請求項２４】
請求項１７乃至２３のいずれか一項に記載のプログラムであって、
前記複数のアプリケーションを、フィルタリング条件のデータに基づいて予め決めるステップ
を更に計算機に実行させるための
プログラム。
【請求項２５】
請求項１７乃至２４のいずれか一項に記載のプログラムであって、
前記複数のアプリケーションと他のノード上にある複数のアプリケーションとが前記管理ネットワークを共有するステップと、
前記管理ネットワークを介して、前記複数のアプリケーションと他のノード上にある複数のアプリケーションとを監視するステップと
を更に計算機に実行させるための
プログラム。
【請求項２６】
請求項１７乃至２５のいずれか一項に記載のプログラムであって、
前記コレクタノードとして計算機を機能させる際に、あるイベントに関係するパケットをキャプチャした全てのプローブノードに対して、ＤＡＴ上のノードを辿って詳細情報を問い合わせるステップ
を更に計算機に実行させるための
プログラム。
【請求項２７】
請求項２６に記載のプログラムであって、
あるイベントに関係するパケットをキャプチャした全てのプローブノードの各々として計算機を機能させる際に、ＤＡＴ上のノードを辿って詳細情報を前記複数のノードのうちのコレクタノードまで送信するステップ
を更に計算機に実行させるための
プログラム。
【請求項２８】
請求項２６又は２７に記載のプログラムであって、
各ノードに、イベントの種類、下位ノードＩＤ、イベントのカウント、イベントを受信した最初の時刻、イベントを受信した最後の時刻、の情報を持たせるステップと
を更に計算機に実行させるための
プログラム。
【請求項２９】
管理ネットワークと、
前記管理ネットワークに接続された複数のノードと
を具備し、
前記複数のノードは、
予め決められた複数のアプリケーションのうちの対応する第１アプリケーションの対象ネットワーク上のトラヒックを検出して検出メッセージを生成し、前記対応するアプリケーションの種類を示す機能識別子だけに対する、あるいはそれと前記トラヒックのアドレス情報とに対するハッシュ値を決定し、前記ハッシュ値と前記トラヒックのＤＡＴとから決定されるノード、前記ハッシュ値と前記管理ネットワークとに関して予め決められたノード、あるいは前記ハッシュ値と前記管理ネットワークとに関して動的に決定されるノードのうちのいずれかのノードに、前記検出メッセージを送信するプローブノードと、
前記複数の予め決められたアプリケーションに対する前記検出メッセージに第１機能識別子に対応するエントリに含まれるメディエーションタイプによって指定された処理を行うメディエーション処理をしてメディエーション処理結果を生成するメディエーションノードと、
前記メディエーション処理結果を格納するコレクタノードと
を含む
ネットワーク分散監視システム。
【請求項３０】
請求項２９に記載のネットワーク分散監視システムであって、
前記アドレス情報は、前記トラヒックの送信元ＩＰアドレス、送信先ＩＰアドレス、送信元ＵＲＩ、及び送信先ＵＲＩの少なくとも１つを含む
ネットワーク分散監視システム。
【請求項３１】
請求項２９又は３０に記載のネットワーク分散監視システムであって、
前記プローブノードは、前記ハッシュ値から前記コレクタノードのノードＩＤを決定し、前記コレクタノードのノードＩＤと前記ＤＡＴとから送信先ノードを決定し、
前記検出メッセージは、前記コレクタノードのノードＩＤを含んでいる
ネットワーク分散監視システム。
【請求項３２】
請求項３１に記載のネットワーク分散監視システムであって、
前記メディエーションノードは、前記検出メッセージに含まれる前記コレクタノードのノードＩＤと、前記メディエーションノードが有するＤＡＴとに基づいて決まるノードに前記メディエーション処理結果を含む処理結果メッセージを送信し、
前記コレクタノードは、前記メディエーションノードから受信される前記処理結果メッセージの前記メディエーション処理結果を格納する
ネットワーク分散監視システム。
【請求項３３】
請求項２９乃至３２のいずれか一項に記載のネットワーク分散監視システムであって、
前記メディエーションノードは、前記コレクタノードと同一である
ネットワーク分散監視システム。
【請求項３４】
請求項２９乃至３３のいずれか一項に記載のネットワーク分散監視システムであって、
前記プローブノードは、
複数の予め決められたアプリケーションのうちの対応する第１アプリケーションの対象ネットワーク上のトラヒックを検出してトラヒック検出メッセージを生成する検知ノードと、
前記対応するアプリケーションの種類を示す機能識別子だけの、あるいはそれと前記トラヒックのアドレス情報とのハッシュ値と前記管理ネットワークの前記トラヒックのＤＡＴとから決定されるノードに前記検出メッセージを送信する処理ノードと
を含む
ネットワーク分散監視システム。
【請求項３５】
請求項２９乃至３４のいずれか一項に記載のネットワーク分散監視システムであって、
前記複数のノードの各々は、スケーラブルでありフォールトトレラントであるネットワークにおいて、異なる監視アプリケーションをサポートする
ネットワーク分散監視システム。
【請求項３６】
請求項２９乃至３５のいずれか一項に記載のネットワーク分散監視システムであって、
前記ハッシュ値は、ハッシュ関数により定まり、
前記各メディエーションノードは、前記メディエーション処理と該ハッシュ関数の入力を選択することにより、スケーラビリティを動的に制御する
ネットワーク分散監視システム。
【請求項３７】
請求項２９乃至３６のいずれか一項に記載のネットワーク分散監視システムであって、
前記各プローブノードは、フィルタリング条件のデータに基づいて複数のアプリケーションを予め決める
ネットワーク分散監視システム。
【請求項３８】
請求項２９乃至３７のいずれか一項に記載のネットワーク分散監視システムであって、
前記複数のアプリケーションと他のノード上にある複数のアプリケーションとは、前記管理ネットワークを共有し、
前記各プローブノードは、前記管理ネットワークを介して、前記複数のアプリケーションと他のノード上にある複数のアプリケーションとを監視する
ネットワーク分散監視システム。
【請求項３９】
請求項２９乃至３８のいずれか一項に記載のネットワーク分散監視システムであって、
前記コレクタノードは、あるイベントに関係するパケットをキャプチャした全てのプローブノードに対して、ＤＡＴ上のノードを辿って詳細情報を問い合わせる機能を持つ
ネットワーク分散監視システム。
【請求項４０】
請求項３９に記載のネットワーク分散監視システムであって、
前記複数のノードのうち、あるイベントに関係するパケットをキャプチャした全てのプローブノードは、ＤＡＴ上のノードを辿って詳細情報を前記複数のノードのうちのコレクタノードまで送信する機能を持つ
ネットワーク分散監視システム。
【請求項４１】
請求項３９又は４０に記載のネットワーク分散監視システムであって、
各ノードは、イベントの種類、下位ノードＩＤ、イベントのカウント、イベントを受信した最初の時刻、イベントを受信した最後の時刻、の情報を持つ
ネットワーク分散監視システム。
【請求項４２】
請求項２９乃至４１のいずれか一項に記載のネットワーク分散監視システムにおいて、
メディエーションノードとして使用される計算機。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散監視システム、分散監視方法、及びプログラムに関する。
【背景技術】
【０００２】
トラヒック量や回線帯域が増加するにつれて、大規模なネットワークの監視は容易ではなくなる。監視対象のネットワーク全体を把握するには、複数の監視場所においてトラヒックを監視し、発生した複数のイベントの相互関係を比較したり、同種の複数イベントを集約したり、異なる種類の複数イベントを１つのイベントにまとめる（調停）ことが必要となる。特に大量のトラヒックは、スケーラビリティの問題をもたらす。例えば、ユーザに高信頼サービスを提供するために、大規模なＩＳＰ（Ｉｎｔｅｒｎｅｔ  Ｓｅｒｖｉｃｅｓ  Ｐｒｏｖｉｄｅｒ）は、重要なイベント（障害、コンフィギュレーションの誤り、攻撃、シグナリング設定（課金を想定））を監視している。イベントを検知したとき、イベントに応じた対応をいかに迅速に行うかは、ＩＳＰにとって大変重要である。従って、大規模ネットワークの大量のトラフィックを監視可能な高スケーラビリティで高効率な分散監視方式が求められている。【０００３】
大規模なネットワークの分散監視の方式として、集中型、または階層化した集中型が提案されている。これらの方式は、監視ノードで得られた監視データを全て中央ノードに直接送信するか、中央ノードに送信される前に中間ノードで一旦、集約し調停する。しかし、集中型または階層化した集中型監視方式は、スケーラビリティや信頼性の問題があり、多くの監視アプリケーションには向いていない。【０００４】
これらの問題を解決するために、“ＷｏｒｍＳｈｉｅｌｄ：  Ｆａｓｔ  Ｗｏｒｍ  Ｓｉｇｎａｔｕｒｅ  Ｇｅｎｅｒａｔｉｏｎ  ｗｉｔｈ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｆｉｎｇｅｒｐｒｉｎｔ  Ａｇｇｒｅｇａｔｉｏｎ”  （ＩＥＥＥ  Ｔｒａｎｓａｃｔｉｏｎｓ  ｏｎ  Ｄｅｐｅｎｄａｂｌｅ  ａｎｄ  Ｓｅｃｕｒｅ  Ｃｏｍｐｕｔｉｎｇ，  Ｖｏｌ．  ４，  Ｎｏ．  ２，  ｐｐ．８８−１０４，  Ａｐｒ−Ｊｕｎ，  ２００７）  ｂｙ  Ｍｉｎ  Ｃａｉ，  Ｋａｉ  Ｈｗａｎｇ，  Ｊｉａｎｐｉｎｇ  Ｐａｎ，  Ｃｈｒｉｓｔｏｓ  Ｐａｐａｄｏｐｏｕｌｏｓ  （非特許文献１）が提案されている。【０００５】
また、“Ｄｉｓｔｒｉｂｕｔｅｄ  Ａｇｇｒｅｇａｔｉｏｎ  Ａｌｇｏｒｉｔｈｍｓ  ｗｉｔｈ  Ｌｏａｄ−Ｂａｌａｎｃｉｎｇ  ｆｏｒ  Ｓｃａｌａｂｌｅ  Ｇｒｉｄ  Ｒｅｓｏｕｒｃｅ  ｍｏｎｉｔｏｒｉｎｇ”    （Ｐａｒａｌｌｅｌ  ａｎｄ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｐｒｏｃｅｓｓｉｎｇ  Ｓｙｍｐｏｓｉｕｍ，  ２００７．  ＩＰＤＰＳ２００７．  ＩＥＥＥ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｖｏｌｕｍｅ，  Ｉｓｓｕｅ，  ２６−３０，  Ｍａｒｃｈ  ２００７  ｐｐ．１−１０）  ｂｙ  Ｃａｉ，  Ｍ．，  Ｈｗａｎｇ，  Ｋ．  （非特許文献２）が提案されている。【０００６】
非特許文献１では、監視アプリケーションは、ワームのシグナチャ生成のためにイベントの合計を計算する処理を行っている。非特許文献２では、監視アプリケーションは、多数ノードの平均のＣＰＵ使用率を監視する処理を行っている。非特許文献１、非特許文献２では、Ｐ２Ｐ（Ｐｅｅｒ  ｔｏ  Ｐｅｅｒ）ネットワーク技術を用いて処理の負荷分散とスケーラビリティやフォールトトレランスを考慮し、監視情報を受け渡し、集約する方式であるＤＡＴ（Ｄｉｓｔｒｉｂｕｔｅｄ  Ａｇｇｒｅｇａｔｉｏｎ  Ｔｒｅｅ）を提案している。【０００７】
ＤＡＴは、ツリー構造であり、ＤＨＴ（Ｄｉｓｔｒｉｂｕｔｅｄ  Ｈａｓｈ  Ｔａｂｌｅ）のアルゴリズムの１つであるＣｈｏｒｄ上で動作する。ノードからノードへ情報を集約しながら、集約結果は最終的にはＤＡＴ上に存在するルートノードに渡される。なお、ＤＨＴは、構造化Ｐ２Ｐネットワークの一つである。構造化Ｐ２Ｐネットワークとは、ネットワーク構成（検索要求、経路）を数式で記述できるものである。ＤＨＴのアルゴリズムとして良く知られているのは、Ｃｈｏｒｄ、Ｐａｓｔｒｙ、ＣＡＮ（Ｃｏｎｔｅｎｔ  Ａｄｄｒｅｓｓａｂｌｅ  Ｎｅｔｗｏｒｋ）などである。これらのＤＨＴのアルゴリズムを用いると、高スケーラビリティやフォールトトレランスが考慮されるので、高信頼でデータを保存したり、データ検索を行うことが可能になる。【０００８】
各ノードからルートノードに直接情報を送信するのではなく、ノードからノードへ情報を送信することを繰り返した後にルートノードへ情報を送信することで、各ノードから直接ルートノードへ情報を送信するよりも、ルートノードの処理負荷とネットワーク帯域を削減することができる。更に、ツリーの深さができるだけ均一になるようにノードを配置することで、負荷分散を実現している。【０００９】
しかしながら、非特許文献１、非特許文献２に示される方法は、イベントをカウントするような単純な監視機能であり、非特許文献１、非特許文献２に記載の方式を適用可能な監視対象は限られており、柔軟性がない。【００１０】
例えば、ＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  ＩＰ）、ＩＰＴＶ、ＶＯＤ（Ｖｉｄｅｏ  Ｏｎ  Ｄｅｍａｎｄ）のようなインターネットのアプリケーションは、制御プレーン（シグナリングプレーン）とデータプレーン（ユーザプレーン）で構成されている。そのため、ＶｏＩＰは、シグナリングを行うプロトコルとしてＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を、音声信号を送信するプロトコルとしてＲＴＰ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）を使用し、ＳＩＰとＲＴＰはネットワーク上の異なる経路を通過する場合がある。このため、非特許文献１、非特許文献２に提案されている技術では、イベントを効率良く関連付けることができない。【００１１】
従って、制御プレーンとデータプレーンで発生するイベントを効率良く相互に関連付ける技術が求められている。【００１２】
上記の説明と関連して、特開２００３−１５８５４９号公報（特許文献１）には、トラヒック情報収集装置が開示されている。この技術の要求受付ノードでは、ＩＰ通信網における特定の２点間のトラヒック情報収集の要求を行うユーザ端末もしくはネットワーク管理端末からのトラヒック情報収集の要求が受信され、受信された要求にしたがって隣接する他通信装置へ該要求を含む情報要求パケットが送信される。隣接する他通信装置から自装置以外の複数の通信装置のトラヒック情報が書込まれた情報回答パケットが受信され、自装置内のトラヒック情報及び受信した情報回答パケットに書込まれたトラヒック情報はとりまとめられる。トラヒック情報収集を要求した端末に、とりまとめられた統括的なトラヒック情報を含む情報回答パケットが送信される。要求中継ノードでは、情報要求パケットが受信され、受信された情報要求パケットに含まれる要求にしたがって自装置内のトラヒック情報により情報回答パケットを作成して要求受付ノードへこの作成された情報回答パケットが送信される。情報要求パケットの送信元以外の隣接する他通信装置へ要求を含む情報要求パケットが転送される。要求終端ノードでは、情報要求パケットが受信され、受信された情報要求パケットに含まれる要求にしたがって自装置内のトラヒック情報により情報回答パケットが作成されて要求受付ノードへこの作成された情報回答パケットが送信される。受信された情報要求パケットは廃棄される。【００１３】
特開２００７−０１３５９０号公報（特許文献２）には、ネットワーク監視システムが開示されている。この技術では、それぞれの監視回線を流れる通信信号の通信情報が常時収集され、通信信号が有するヘッダ情報に基づいて、パケット情報と、送信元及び又は送信先を関連付けたフロー統計情報とが求められ、予め設定された物理的な集約対象でグループ化してトラフィック情報が集計される。【００１４】
また、収集するイベント属性を指定して監視機能を提供する仕組みとして、“Ａ  Ｓｃａｌａｂｌｅ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ”  Ｐｒａｖｅｅｎ  Ｙａｌａｇａｎｄｕｌａ，Ｍｉｋｅ  Ｄａｈｌｉｎ  （ＡＣＭ  ＳＩＧＣＯＭＭ  Ｃｏｍｐｕｔｅｒ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｒｅｖｉｅｗ  Ｖｏｌｕｍｅ３４，  Ｉｓｓｕｅ４  （Ｏｃｔｏｂｅｒ２００４）Ｐａｇｅｓ：３７９−３９０  Ｙｅａｒ  ｏｆ  Ｐｕｂｌｉｃａｔｉｏｎ：２００４）  （非特許文献３）が提案されている。【００１５】
しかしながら、非特許文献３に示される方法は、ノードが構成するツリー自体で負荷分散を考慮することはしていない。【００１６】
ネットワークの広域監視において、管理者はネットワークから情報を収集するが、収集した情報の内容によっては、更に詳細な情報を得たい場合がある。例えば、ワームが発生したというイベントが発生した場合に、実パケットの情報を参照することがある。【００１７】
このようなオペレーションを実現するためには、ネットワーク全体からイベントを収集するだけではなく、イベントに関連した情報の詳細を把握する機能（以下、バックトラッキング機能と呼ぶ）が広域監視の仕組みとして必要である。【００１８】
しかしながら、非特許文献１、２、３では、バックトラッキング機能はもたないため、収集した情報の詳細を後から管理者が参照することは困難である。
【先行技術文献】
【特許文献】
【００１９】
【特許文献１】特開２００３−１５８５４９号公報
【特許文献２】特開２００７−０１３５９０号公報
【非特許文献】
【００２０】
【非特許文献１】“ＷｏｒｍＳｈｉｅｌｄ：  Ｆａｓｔ  Ｗｏｒｍ  Ｓｉｇｎａｔｕｒｅ  Ｇｅｎｅｒａｔｉｏｎ  ｗｉｔｈ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｆｉｎｇｅｒｐｒｉｎｔ  Ａｇｇｒｅｇａｔｉｏｎ，”  ｂｙ  Ｍｉｎ  Ｃａｉ，  Ｋａｉ  Ｈｗａｎｇ，  Ｊｉａｎｐｉｎｇ  Ｐａｎ，  Ｃｈｒｉｓｔｏｓ  Ｐａｐａｄｏｐｏｕｌｏｓ  （ＩＥＥＥ  Ｔｒａｎｓａｃｔｉｏｎｓ  ｏｎ  Ｄｅｐｅｎｄａｂｌｅ  ａｎｄ  Ｓｅｃｕｒｅ  Ｃｏｍｐｕｔｉｎｇ，  Ｖｏｌ．  ４，  Ｎｏ．  ２，  ｐｐ．８８−１０４，  Ａｐｒ−Ｊｕｎ，  ２００７）
【非特許文献２】“Ｄｉｓｔｒｉｂｕｔｅｄ  Ａｇｇｒｅｇａｔｉｏｎ  Ａｌｇｏｒｉｔｈｍｓ  ｗｉｔｈ  Ｌｏａｄ−Ｂａｌａｎｃｉｎｇ  ｆｏｒ  Ｓｃａｌａｂｌｅ  Ｇｒｉｄ  Ｒｅｓｏｕｒｃｅ  ｍｏｎｉｔｏｒｉｎｇ”  ｂｙ  Ｃａｉ，  Ｍ．，  Ｈｗａｎｇ，  Ｋ．，  （Ｐａｒａｌｌｅｌ  ａｎｄ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｐｒｏｃｅｓｓｉｎｇ  Ｓｙｍｐｏｓｉｕｍ，  ２００７．  ＩＰＤＰＳ２００７．  ＩＥＥＥ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｖｏｌｕｍｅ，  Ｉｓｓｕｅ，  ２６−３０  Ｍａｒｃｈ  ２００７  Ｐａｇｅ（ｓ）：１−１０）
【非特許文献３】“Ａ  Ｓｃａｌａｂｌｅ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ”  Ｐｒａｖｅｅｎ  Ｙａｌａｇａｎｄｕｌａ，Ｍｉｋｅ  Ｄａｈｌｉｎ  （ＡＣＭ  ＳＩＧＣＯＭＭ  Ｃｏｍｐｕｔｅｒ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｒｅｖｉｅｗ  Ｖｏｌｕｍｅ３４，  Ｉｓｓｕｅ４  （Ｏｃｔｏｂｅｒ２００４）Ｐａｇｅｓ：３７９−３９０  Ｙｅａｒ  ｏｆ  Ｐｕｂｌｉｃａｔｉｏｎ：２００４）
【発明の概要】
【００２１】
本発明は、スケーラビリティとフォールトレランスを考慮し、負荷分散しながら、制御プレーンとデータプレーンを使用するアプリケーションの監視のような、高度な機能の監視も可能な分散監視システムを提供する。
【００２２】
更に、本発明では、必要に応じて、上記の分散監視システムにバックトラッキング機能を追加する。
【００２３】
本発明の第１の観点では、ネットワーク分散監視方法は、管理ネットワークに接続された複数のノードを含むネットワークにおいて、複数のノードのうちの第１プローブノードの各々において、複数の第１の予め決められたアプリケーションのうちの対応する第１アプリケーションの対象ネットワーク上の第１トラヒックを検出して第１検出メッセージを生成するステップと、対応する第１アプリケーションの種類を示す第１機能識別子だけ、あるいはそれと第１トラヒックのアドレス情報との第１ハッシュ値と管理ネットワークの第１トラヒックのＤＡＴとから決定されるノードに第１検出メッセージを送信するステップと、複数のノードのうちの第１メディエーションノードにおいて複数の第１の予め決められたアプリケーションに対する検出メッセージに第１メディエーション処理をして第１メディエーション処理結果を生成するステップと、複数のノードのうちの第１コレクタノードにおいて第１メディエーション処理結果を格納するステップとを備える。
【００２４】
本発明の第２の観点では、計算機読み取り可能なプログラムは、管理ネットワークに接続された複数のノードを含むネットワークにおいて、複数の予め決められたアプリケーションのうちの対応するアプリケーションの対象ネットワーク上のトラヒックを検出して検出メッセージを生成するステップと、対応するアプリケーションの種類を示す機能識別子だけ、あるいはそれとトラヒックのアドレス情報とハッシュ値と管理ネットワークのトラヒックのＤＡＴとから決定されるノードに検出メッセージを送信するステップとを実行するプローブノードとして計算機を機能させるためのものである。なお、このプログラムは、記憶媒体（メディア）に記憶することができる。
【００２５】
本発明の第３の観点では、ネットワーク分散監視システムは、管理ネットワークと、管理ネットワークに接続された複数のノードとを備え、複数のノードのうちのプローブノードの各々は、複数の予め決められたアプリケーションのうちの対応する第１アプリケーションの対象ネットワーク上のトラヒックを検出して検出メッセージを生成し、対応するアプリケーションの種類を示す機能識別子だけの、あるいはそれとトラヒックのアドレス情報とのハッシュ値と管理ネットワークのトラヒックのＤＡＴとから決定されるノードに検出メッセージを送信し、複数のノードのうちのメディエーションノードは、複数の予め決められたアプリケーションに対する検出メッセージにメディエーション処理をしてメディエーション処理結果を生成し、複数のノードのうちのコレクタノードは、メディエーション処理結果を格納する。
【００２６】
本発明の他の観点では、ネットワーク分散監視システムにおいて使用されるノードが提供される。
【００２７】
上記の各観点において、複数のノードのうちのコレクタノードは、あるイベントに関係するパケットをキャプチャした全てのプローブノードに対して、ＤＡＴ上のノードを辿って詳細情報を問い合わせする機能を持つ場合がある。また、あるイベントに関係するパケットをキャプチャした全てのプローブノードは、ＤＡＴ上のノードを辿って詳細情報を前記複数のノードのうちのコレクタノードまで送信する機能を持つ。更に、バックトラッキングするために、各ノードは、イベントの種類、下位ノードＩＤ、イベントのカウント、イベントを受信した最初の時刻、イベントを受信した最後の時刻、の情報を持つようにしても良い。
【００２８】
本発明によれば、イベントを計数するような単純な監視アプリケーションだけではなく、制御プレーンとデータプレーンのイベントの関連付けが必要なアプリケーションの監視など、高度な監視を実現できる柔軟な監視システムが提供される。
また、本発明によれば、異なる監視対象アプリケーションが共存することができる。監視対象アプリケーションは異なっていても、監視に使用される機能がそれらに共通である場合、同じ監視機能を用意し、あるいは開発（二重開発）する必要がない。
更に、本発明によれば、バックトラッキング機能を追加することで、管理者がパケットの詳細情報を参照できるようになる。
【図面の簡単な説明】
【００２９】
【図１】図１は、本発明の第１実施形態による分散監視システムを示す図である。
【図２】図２は、本発明の第１実施形態による分散監視システムにおける管理ノードネットワークの構成例を示す図である。
【図３】図３は、本発明の第１実施形態による分散監視システムにおける監視ノードの構成を示すブロック図である。
【図４】図４は、本発明の第１実施形態による分散監視システムにおけるルールテーブルの例を示す図である。
【図５】図５は、本発明の第１実施形態による分散監視システムにおける監視テーブルの例を示す図である。
【図６】図６は、本発明の第１実施形態による分散監視システムにおけるノードテーブルを示す図である。
【図７Ａ】図７Ａは、本発明の第１実施形態による分散監視システムにおける監視ノードの動作を示すフローチャートである。
【図７Ｂ】図７Ｂは、本発明の第１実施形態による分散監視システムにおける監視ノードの動作を示すフローチャートである。
【図８】図８は、本発明の第２実施形態による分散監視システムを示す図である。
【図９】図９は、本発明の第２実施形態における構成を示すブロック図である。
【図１０Ａ】図１０Ａは、本発明による分散監視システムにおける管理ノードネットワークの例を示す図である。
【図１０Ｂ】図１０Ｂは、本発明による分散監視システムにおける管理ノードネットワークに対応するＤＡＴ構成を示す図である。
【図１１】図１１は、本発明の第３実施形態による分散監視システムにおけるバックトラッキング機能を搭載した監視ノードの構成を示すブロック図である。
【図１２】図１２は、本発明の第３実施形態による分散監視システムにおけるバックトラックテーブルの例を示した図である。
【図１３】図１３は、本発明の第３実施形態による分散監視システムにおけるバックトラッキング機能を搭載した監視ノードの動作を示すフローチャートである。
【図１４】図１４は、本発明の各実施形態による分散監視システムを実現するためのハードウェア構成の一例を示すブロック図である。
【発明を実施するための形態】
【００３０】
以下に添付図面を参照して、本発明の分散監視システムが適用される通信システムをＶｏＩＰを例に取って詳細に説明する。
【００３１】
ここでは、プローブまたはプローブノードとは、ネットワークインタフェース（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ）からパケットをキャプチャしパケットに関する情報を提供する役割をするものである。メディエーションは、ノードから得た情報を組み合わせたり、削減したりする機能である。メディエーション機能を持つノードをメディエータと呼ぶ。コレクタは、メディエーションされた全情報を収集するノードである。ノードは、ネットワーク上に存在する装置である。プローブ、メディエータ、コレクタは、ノードの一種である。プローブの機能とメディエータの機能を持つ装置もノードと呼ぶ。
【００３２】
＜第１実施形態＞
図１は、本発明の第１実施形態による分散監視システムを示す図である。図１に示すように、分散監視システムは、管理系ネットワーク５０を備える。管理系ネットワーク５０には、複数の監視ノード５１−ｉ（ｉ＝１，２，・・・，ｎ）とサーバ５３が接続されている。また、複数の監視ノード５１−ｉは、それぞれ監視対象ネットワーク内の所定の位置に配置されており、監視対象ネットワーク内の配置位置を流れるトラヒックを監視している。各監視ノード５１−ｉは、ノードＩＤを有している。各ノード５１−ｉは、トラヒックの監視結果について、管理系ネットワーク５０を介して他のノード５１−ｊ（ｉ≠ｊ）に送信する。この例では本発明の内容を理解し易くするために、サーバ５３を１台としているが、実サービスではサーバは複数台になっても良い。
【００３３】
図２は、本発明の分散監視システムのメッセージの転送例を示している。図１０Ａは、本発明の転送例を詳細に示し、図１０Ｂは、ＤＡＴ構造を示している。管理系ネットワーク５０は、１６個の監視ノードＮ２，Ｎ４，・・・，Ｎ３０と、サーバ５３を有している。サーバ５３は、上記の監視ノードのうち、少なくとも監視ノードＮ２，Ｎ６，Ｎ１６，Ｎ１８，Ｎ２２，Ｎ２４に、ルールテーブルと、監視テーブル（後述する）を配信する。サーバ５３は、ノードテーブル（後述する）を全監視ノードに配信する。
【００３４】
監視ノードＮ２は、それを通るトラヒックを監視してＳＩＰアプリケーションの通話Ａと通話ＢのＳＩＰパケットを検出して、監視ノードＮ１８に送信する。監視ノードＮ６は、それを通るトラヒックを監視して通話ＢのＲＴＰパケットを検出して、監視ノードＮ２２に送信する。監視ノードＮ１６は、それを通るトラヒックを監視して通話ＡのＲＴＰパケットを検出し、監視ノードＮ２４に送信する。監視ノードＮ１８は、監視ノードＮ２からの通話Ａ，ＢのＳＩＰパケットの検出結果を監視ノードＮ２２に転送する。監視ノードＮ２２は、監視ノードＮ６から通話ＢのＲＴＰパケットの検出結果を受信し、監視ノードＮ１８から通話ＢのＳＩＰパケットの検出結果を受信して、それらの検出結果の相関を求めて、その結果を監視ノードＮ２４に送信する。監視ノードＮ２４は、監視ノードＮ２２から通話Ｂの相関処理結果を受信して、格納する。また、監視ノードＮ２４は、監視ノードＮ２２から通話ＡのＳＩＰパケットの検出結果を受信し、監視ノードＮ１６から通話ＡのＲＴＰパケットの検出結果を受信し、それらの検出結果の相関を求めて、その結果を格納する。
【００３５】
この例では、２つの相関の結果が共に監視ノードＮ２４に格納されているが、本発明はこれに限られず、別の監視ノードにそれぞれ格納されても良い。
【００３６】
図３は、本発明における第１実施形態による分散監視システム内の各監視ノード内の構成を示すブロック図である。図３を参照して、第１実施形態による各監視ノード５１−ｉは、主信号系ネットワークインタフェース部１０１、受信部１０２、検知部１０３、管理系ネットワークインタフェース部２０１、受信部２０２、ＤＨＴ／ＤＡＴ部２０３、監視部２０４、送信部２０５、格納部１１０を備えている。格納部１１０には、ルールテーブル１１１、監視テーブル２１１、ノードテーブル２１２、監視結果データバッファ２１３、ＤＡＴバッファ２１４が格納されている。監視ノードの格納部１１０以外の各部は、ハードウェアとして、ソフトウェアとして、あるいは混合型として実現されても良い。ソフトウェアとして実現されるときには、監視ノード内の記憶装置にプログラムが固定的に格納され、あるいは外部の記憶媒体（メディア）からロードされ、ＣＰＵまたはプロセッサがそのプログラムを実行することにより実現される。
【００３７】
受信部１０２は、主信号系ネットワークインタフェース部１０１を介して、監視対象ネットワーク５２からトラヒックデータを受信する。受信部１０２は、トラヒックデータに対して、トラヒック監視のために必要なセッション管理や、ストリーム再構築等を必要に応じて行うことができる。受信部１０２は、トラヒックデータ中に含まれるメッセージを検知部１０３に送る。
【００３８】
検知部１０３は、受信部１０２からメッセージを受け取ると、ルールテーブル１１１に登録されているルールを参照し、メッセージがルールに該当するか否かを確認する。検知部１０３は、メッセージがルールに該当することを検知すると、監視部２０４へ通知メッセージを送る。
【００３９】
図４は、ルールテーブル１１１を示す。ルールテーブル１１１は、複数のエントリを有し、各エントリには、検知されるべきメッセージを特定するためのルールが登録されている。これらのルールは、サーバ５３から、監視ノードに送信され、ルールテーブル１１１に格納される。すなわち、サーバ５３は、これらのルールを監視ノードに送信する。監視ノードは、これらのルールを受信してルールテーブル１１１に格納する。例えば、あるルールでは、プロトコルはＳＩＰである。送信元ＩＰアドレスは１９２．１６８．０．１である。送信先ＩＰアドレスは１９２．１６８．０．１１である。送信元ＳＩＰ−ＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）はｓｅｎｄｅｒ１＠ｓｉｐ．ｃｏｍである。送信先ＳＩＰ−ＵＲＩはｒｅｃｅｉｖｅｒ１＠ｓｉｐ．ｃｏｍである。ＳＩＰメソッドはＩＮＶＩＴＥである。このルールは、そのようなメッセージが、１秒間に１個流れたことを確認するためのものである。
【００４０】
監視部２０４は、検知部１０３から受け取った通知メッセージを、監視テーブルに格納されているデータに従って処理する。
【００４１】
図５は、監視テーブル２１１の一例を示している。監視テーブル２１１は、複数のエントリを示している。監視テーブル２１１の各エントリは、連続番号、監視されるべき機能を示す機能名、監視されるべき機能を特定するための機能識別子（監視されるべきアプリケーションの種類を示す識別子）、ハッシュ関数の引数、メディエーションタイプのデータを有している。これらのエントリは、サーバ５３から、監視ノードに送信され、監視テーブル２１１に格納される。すなわち、サーバ５３は、これらのエントリを監視ノードに送信する。監視ノードは、これらのエントリを受信して監視テーブル２１１に格納する。例えば、番号７のエントリでは、機能名は、ＶｏＩＰ監視である。機能識別子は７である。ハッシュ関数の引数は、機能識別子である。メディエーションタイプはＳＩＰとＲＴＰの相関（ＩＰアドレス、ポート番号）である。また、番号８のエントリでは、機能名は、ＩＰＴＶ監視である。機能識別子は８である。ハッシュ関数の引数は、機能識別子、送信元ＩＰアドレスである。メディエーションタイプはＳＩＰとＲＴＰの相関（ＩＰアドレス、ポート番号）である。この例では、機能識別子と送信元ＩＰアドレスを用いているが、送信先ＩＰアドレスでも良く、あるいは両方のＩＰアドレスを用いても良い。更に、送信元のＵＲＩと送信先ＵＲＩの両方あるいは一方を用いても良い。ハッシュ関数の入力を選択することにより、動的にスケーラビリティを制御できる。
【００４２】
監視部２０４は、検知部１０３から受け取った通知メッセージ内の機能識別子を抽出し、抽出された機能識別子に対応するエントリがあるか否かを確認する。監視部２０４は、エントリが存在するときは、監視結果データバッファ２１３を参照して、監視結果データが格納されているか否かを判断する。また、監視部２０４は、そのエントリのメディエーションタイプのフィールドを参照して、通知メッセージ内の監視結果データと監視結果データバッファ２１３内の監視結果データとを用いてメディエーション処理を行う。この例では、監視部２０４は、抽出された機能識別子が７であるとき、ＩＰアドレスとポート番号を参照し、あるＳＩＰセッションに属するＲＴＰの情報があれば、それらをまとめて、ＶｏＩＰアプリケーションと同じセッションとして関連付けする。監視部２０４は、あるＳＩＰセッションに属するＲＴＰのデータが監視結果データバッファ２１３になければ、何もしない。更に、監視部２０４は、ＲＴＰのデータを含む通知メッセージを他の監視ノードから受信したときは、そのＲＴＰのデータを監視結果データバッファ２１３に格納する。
【００４３】
ハッシュ関数の引数は、機能識別子であるので、監視部２０４は、ハッシュ関数ｈａｓｈ（７）を計算すると２４が得られる。こうして、メッセージが最終的に送り届けられるべき監視ノード（ルート監視ノードまたはコレクタ監視ノード）は、ノードＩＤが２４の監視ノードＮ２４であることがわかる。監視部２０４は、このノードＩＤと、メディエーション処理した結果をイベントとしてＤＨＴ／ＤＡＴ部２０３へ渡す。
【００４４】
なお、ハッシュ関数が出力する値により、どのノードがコレクタノードになるかが決まる。そのため、あるノードがあるときはコレクタノードになり、メディエーションノードになる場合がある。更に、ある監視アプリケーションでコレクタになっているノードが別の監視アプリケーションのコレクタになる場合や、ある監視アプリケーションでメディエータになっているノードが別の監視アプリケーションのメディエータになる場合がある。つまり、複数の監視アプリケーションがネットワークを共有する。
【００４５】
ＤＨＴ／ＤＡＴ部２０３は、図２に示される、予め決められたＤＡＴを格納するＤＡＴバッファ２１４を参照し、監視部２０４から受け取った処理結果をＤＨＴ／ＤＡＴ上の次の監視ノードへの送信準備を行う。ＤＨＴ／ＤＡＴ部２０３は、コレクタ監視ノードのノードＩＤと、自ノードＩＤに基づいてＤＡＴバッファ２１４のＤＡＴを参照し、次の送信先ノードを決定する。図２は、ＤＡＴの例を示した図である。例えば、ＤＨＴ／ＤＡＴ部２０３は、自ノードのＩＤが１８の場合、ノードＩＤ２２の監視ノードＮ２２へ、処理結果を含むメッセージを送れば良いことがわかる。次に、ＤＨＴ／ＤＡＴ部２０３は、送信先監視ノードのノードＩＤ２２に基づいてノードテーブル２１２を参照し、ノードＩＤにより特定されるノードのＩＰアドレスを取得する。図６は、ノードテーブル２１２の例であり、ＤＨＴ／ＤＡＴ部２０３は、ＩＤ２２に該当するＩＰアドレス１９２．１６８．０．２２へデータを送信すれば良いことがわかる。ＤＨＴ／ＤＡＴ部２０３は、メッセージと取得した送信先ＩＰアドレスを送信部２０５へ渡す。この例では、予め決められたＤＡＴに基づいて送信先が決定されているが、他の方法により送信先が決定されても良い。そのとき、送信先はその都度動的に決定されても良いし、予め決定されていても良い。
【００４６】
送信部２０５は、ＤＨＴ／ＤＡＴ部２０３からのメッセージを、管理系ネットワークインタフェース部２０１を介して、送信先ＩＰアドレス宛に送信する。
【００４７】
また、受信部２０２は、管理系ネットワークインタフェース部２０１を介して他の監視ノードからメッセージを受信すると、メッセージをＤＨＴ／ＤＡＴ部２０３を介して監視部２０４に渡す。監視部２０４は、上記と同様の処理を実行して、最終的な宛先監視ノードのノードＩＤを決定し、このノードＩＤと、メディエーション処理した結果をイベントとしてＤＨＴ／ＤＡＴ部２０３へ渡す。ＤＨＴ／ＤＡＴ部２０３は、ＤＡＴバッファ２１４のＤＡＴを参照して、監視部２０４から受け取った処理結果をＤＨＴ／ＤＡＴ上の次の監視ノードへの送信する準備を行う。
【００４８】
次に、本発明の第１実施形態による分散監視システムの全体動作を説明する。ここでは、監視ノードＮ２，Ｎ６，Ｎ１６は、プローブノードであり、監視ノードＮ１６と、Ｎ２２はメディエータノードである。管理ノードＮ２４は、コレクタノードである。
【００４９】
今、監視ネットワーク上に、通話Ａ，通話Ｂの２つのＶｏＩＰの通話が発生したとする。更に、通話Ａ、通話ＢのＳＩＰトラヒックがプローブＮ２を通過し、通話ＡのＲＴＰトラヒックがＮ１６を、通話ＢのＲＴＰトラヒックがＮ６を通過したとする。
【００５０】
まず、通話Ａについて考える。監視ノードＮ２が、図４のルールテーブル１１１を用いて、ＳＩＰパケットを検知する。また、図５の監視テーブル２１１より、ＶｏＩＰ監視の機能識別子は７であることがわかる。ここで、ハッシュ関数ｈａｓｈ（７）＝２４より、コレクタ監視ノードのノードＩＤが２４であることがわかるので、図２のＤＡＴより、監視ノードＮ２は、監視ノードＮ１８に監視結果データと機能識別子を含むメッセージを送信する（ｓｔｏｒｅ（ｈａｓｈ（７））＝＜７，ＤＡＴＡ＞と表現する）。
【００５１】
同様に、監視ノードＮ１６は、ＲＴＰパケットの検知を行い、コレクタ監視ノードＮ２４へ監視結果データと機能識別子を含むメッセージを送信する。
【００５２】
監視ノードＮ２からメッセージを受け取った監視ノードＮ１８は、メッセージ内の機能識別子が、監視ノードＮ１８が持つ監視テーブル２１１に一致する機能識別子が存在するか否かを判定する。監視ノードＮ１８は、一致する機能識別子が存在する場合には、該当する機能識別子のメディエーションタイプに従って処理を行う。また、監視ノードＮ１８は、一致する機能識別子が存在しない場合には、ＤＡＴを参照して、受信されたメッセージを監視ノードＮ２２に転送する。監視ノードＮ１８からメッセージを受け取った監視ノードＮ２２も、監視ノード１８と同様の動作を行い、メッセージをコレクタ監視ノードＮ２４に転送する。このように処理することにより、コレクタである監視ノードＮ２４にメッセージが届く。監視ノードＮ２４は、ＳＩＰとＲＴＰの相関処理を行い、結果を保存する。これにより、ストリームの相関処理が可能になる。
【００５３】
通話Ｂについても同様な処理を行う。監視ノードＮ２が、図４のルールテーブル１１１を用いて、通話ＢのＳＩＰパケットを検知する。また、図５の監視テーブル２１１より、ＶｏＩＰ監視の機能識別子は７であることがわかる。ここで、ハッシュ関数ｈａｓｈ（７）＝２４より、コレクタ監視ノードのノードＩＤが２４であることがわかるので、図２のＤＡＴより、監視ノードＮ２は監視ノードＮ１８に監視結果データと機能識別子を含むメッセージを送信する（ｓｔｏｒｅ（ｈａｓｈ（７））＝＜７，ＤＡＴＡ＞と表現する）。
【００５４】
同様に、監視ノードＮ６は、ＲＴＰパケットの検知を行い、監視結果ノードＮ２２へ監視結果データと機能識別子を含むメッセージを送信する。
【００５５】
監視ノードＮ２からメッセージを受け取った監視ノードＮ１８は、メッセージ内の機能識別子が、監視ノードＮ１８が持つ監視テーブル２１１に一致する機能識別子が存在するか否かを判定する。監視ノードＮ１８は、一致する機能識別子が存在する場合には、該当する機能識別子のメディエーションタイプに従って処理を行う。また、監視ノードＮ１８は、一致する機能識別子が存在しない場合には、ＤＡＴを参照して、受信されたメッセージを監視ノードＮ２２に転送する。
【００５６】
監視ノードＮ２２は、監視ノードＮ１８からメッセージと、監視ノードＮ６から受信されるメッセージとに基づいて定まるメディエーションタイプに規定されたメディエーション処理（相関処理）を行い、その処理結果をコレクタ監視ノードＮ２４に送信する。コレクタ監視ノードＮ２４は、処理結果を受信して、格納する。これにより、ストリームの相関処理が可能になる。
【００５７】
ここで、監視ノードＮ２２でＳＩＰの監視結果データとＲＴＰの監視結果データがそろうと、監視ノードＮ２２は、相関処理を行う。全ての監視結果データの相関がとれると、監視ノードＮ２４は処理結果を保存する。なお、ＤＡＴ上のどのノードでも（ｇｅｔ（ｈａｓｈ（７））＝７）を実行することができる。このｇｅｔ（）要求は、コレクタ監視ノードＮ２４に転送され、監視機能に関する全ての監視結果データをｇｅｔ（）要求元に送り返す。また、ハッシュ関数の引数に例えばＳＩＰユーザ名を指定することで、該当する監視データのみを取り出すことも可能である。
【００５８】
なお、ハッシュにかける対象は、機能識別子だけでなく、機能識別子とアドレス情報でも良い。例えば、機能識別子と送信元ＩＰアドレス、あるいは送信元ＩＰアドレスと送信先ＩＰアドレスである。更に、送信元ＵＲＩと送信先ＵＲＩの両方あるいは一方を用いても良い。ハッシュ関数の入力を選択することにより、動的にスケーラビリティを制御できる。
【００５９】
次に、本発明の第１実施形態による分散監視システムで使用される各監視ノードの動作を図７Ａ、図７Ｂを参照して説明する。
【００６０】
まず、図７Ａを参照して、他のノードから受信したメッセージを他の監視ノードへ送信する動作について説明する。
【００６１】
（１）ステップＳ１
監視ノードＮ２が主信号系ネットワークインタフェース部１０１を介してネットワーク上を流れるパケットを受信すると、受信部１０２は、レイヤーＬ２、Ｌ３、Ｌ４の終端処理を行う。
【００６２】
（２）ステップＳ２
続いて、受信部１０２は、ＩＰアドレスやポート番号をもとにしたセッション管理を行い、ＴＣＰやＳＣＴＰパケットの場合はストリーム再構築を行い、パケットを検知部１０３に転送する。
【００６３】
（３）ステップＳ３
検知部１０３は、ルールテーブル１１１に登録されているルールに、受信パケットがマッチするか否かを確認する。図４の例では、検知部１０３は、パケットにＩＰアドレスやＳＩＰ−ＵＲＩなどが含まれているか否かを検査する。検知部１０３は、検査した結果としてルール（フィルタリング条件）に該当する場合は、監視部２０４へイベントを通知する。ルールテーブル１１１にルール（フィルタリング条件）を登録することで、監視アプリケーションはフィルタリング条件のデータにより予め決められる。
【００６４】
（４）ステップＳ４
監視部２０４は、検知部１０３から受け取ったイベントに関連するイベントを他ノードから受信しているか否かを確認する。
【００６５】
（５）ステップＳ５
監視部２０４は、他ノードからメッセージを受信している場合には、イベントを集約する。
【００６６】
（６）ステップＳ６
その後、監視部２０４は、監視テーブル２１１（図５）のメディエーションタイプに従って処理を行う。この例では、監視ノードＮ２は、他ノードからイベントを受け取っていないので、監視部２０４は、ノードＩＤ２を持つノードが検知したイベントのみをメディエーションタイプに従って処理する。監視部２０４は、コレクタ監視ノードＮ２４のノードＩＤとメディエーション処理した結果をＤＨＴ／ＤＡＴ部２０３へ渡す。
【００６７】
（７）ステップＳ７
続いて、ＤＨＴ／ＤＡＴ部２０３は、ＤＡＴバッファ２１４のＤＡＴを参照して、ＤＨＴ／ＤＡＴ上の次のノードへイベントを送信する準備を行う。ＤＨＴ／ＤＡＴ部２０３は、ＤＡＴバッファ２１４のＤＡＴを参照し、コレクタ監視ノードのノードＩＤから、メッセージの送信先のノードを決定する。図２の例では、ノードＩＤが１８の監視ノードＮ１８に送信することになる。ＤＨＴ／ＤＡＴ部２０３は、ノードテーブル２１２を参照してノードＩＤ１８のＩＰアドレスを取得し、送信部２０５へ渡す。
【００６８】
（８）ステップＳ８
送信部２０５は、管理系ネットワークインタフェース部２０１を介して、ＤＨＴ／ＤＡＴ部２０３より受け取ったイベントを次ノードのＩＰアドレス宛に送信する。
【００６９】
次に、図７Ｂを参照して、他の監視ノードから送信されたメッセージを受信する動作について説明する。
【００７０】
（１）ステップＳ１１
他の監視ノードから送信されたメッセージは、管理系ネットワークインタフェース部２０１を介して受信部２０２により受信される。受信部２０２は、受信したメッセージをＤＨＴ／ＤＡＴ部２０３を介して監視部２０４に転送する。
【００７１】
（２）ステップＳ１２
監視部２０４は、ＤＨＴ／ＤＡＴ部２０３からメッセージを受け取ると、そのメッセージに監視結果データを含んでいるか否かを調べる。このとき、監視部２０４は、メッセージ内の機能識別子が監視テーブル２１１に登録されていれば、その機能識別子に基づいて、監視結果データ（例えば、ＲＴＰデータ）を、コレクタ監視ノードに転送するために必要なデータとともに、監視結果データバッファ２１３に格納する。
【００７２】
（３）ステップＳ１３
ＤＨＴ／ＤＡＴ部２０３から受信されるメッセージが監視結果データ（ＳＩＰデータ）を含んでいるとき、監視部２０４は、機能識別子に基づいて、監視結果データバッファ２１３に格納されているＲＴＰデータとＳＩＰデータの相関を取るメディエーション処理を実行する。その後、監視部２０４は、コレクタ監視ノードＮ２４のノードＩＤとメディエーション処理した結果をＤＨＴ／ＤＡＴ部２０３へ渡す。
【００７３】
（４）ステップＳ１４
続いて、ＤＨＴ／ＤＡＴ部２０３は、ＤＡＴバッファ２１４のＤＡＴを参照して、ＤＨＴ／ＤＡＴ上の次のノードへメッセージを送信する準備を行う。ＤＨＴ／ＤＡＴ部２０３は、ＤＡＴバッファ２１４のＤＡＴを参照し、コレクタ監視ノードのノードＩＤから、メッセージの送信先のノードを決定する。図２の例では、ノードＩＤが１８の監視ノードＮ１８に送信することになる。ＤＨＴ／ＤＡＴ部２０３は、ノードテーブル２１２を参照してノードＩＤ１８のＩＰアドレスを取得し、送信部２０５へ渡す。
【００７４】
（５）ステップＳ１５
送信部２０５は、管理系ネットワークインタフェース部２０１を介して、ＤＨＴ／ＤＡＴ部２０３より受け取ったイベントを次ノードのＩＰアドレス宛に送信する。
【００７５】
＜第２実施形態＞
次に、本発明の第２実施形態による分散監視システムについて説明する。
図１は、各監視ノードが全機能を持っているが、図８に示される第２実施形態による分散監視システムにおけるノードは、検知を行う検知ノード１２０と監視を行う処理ノード２２０の２種類に分けられている。１つのノードに全機能を持つ場合と機能は変わらない。図３に示す各監視ノード５１−ｉを、検知ノード１２０と処理ノード２２０に分けた場合、図８のように１台の処理ノード２２０に１台または複数台の検知ノード１２０を接続することができる。
【００７６】
図９は、検知ノード１２０と処理ノード２２０を示している。第２実施形態の検知ノード１２０において、主信号系ネットワークインタフェース部１０１、受信部１０２、検知部１０３、ルールテーブル１１１は、第１実施形態のそれらと同じである。従って、その構成と動作の説明は省略する。インタフェース部１０４は、送信機能を有し、受信パケットがルールテーブル１１１に登録されているルールにマッチするとき、監視ノードとなる処理ノード２２０にイベントメッセージを送信する。
【００７７】
第１実施形態と同じく、検知部１０３は、ルールテーブル１１１に登録されているルール（フィルタリング条件）にマッチするか否かを確認する。監視対象にするアプリケーションは、フィルタリング条件に基づいて予め決められている。
【００７８】
第２実施形態の処理ノード２２０は、管理系ネットワークインタフェース部２０１、受信部２０２、ＤＨＴ／ＤＡＴ部２０３、監視部２０４、送信部２０５、インタフェース部２０６、監視テーブル２１１、ノードテーブル２１２、監視結果データバッファ２１３、ＤＡＴバッファ２１４を有している。これらの構成要素のうち、インタフェース部２０６とＤＡＴバッファ２１４以外のものは、第１実施形態における対応するものと同じである。従って、それらの構成と動作の説明は省略する。インタフェース部２０６は、受信機能を有し、検知ノード１２０から送信されるイベントメッセージを受信し、監視部２０４に転送する。
【００７９】
第１実施形態と同様に、ハッシュにかける対象は、機能識別子だけでなく、機能識別子とアドレス情報でも良い。例えば、機能識別子と送信元ＩＰアドレス、あるいは送信元ＩＰアドレスと送信先ＩＰアドレスである。更に、送信元ＵＲＩと送信先ＵＲＩの両方あるいは一方を用いても良い。ハッシュ関数の入力を選択することにより、動的にスケーラビリティを制御できる。
【００８０】
第２実施形態による分散監視システムでも、メディエーション結果は、コレクタ監視ノードＮ２４に集められ、格納されている。
【００８１】
第１実施形態と同様に、ハッシュ関数が出力する値により、どのノードがコレクタノードになるかが決まる。そのため、あるノードがあるときはコレクタノードになり、メディエーションノードになる場合がある。更に、ある監視アプリケーションでコレクタになっているノードが別の監視アプリケーションのコレクタになる場合や、ある監視アプリケーションでメディエータになっているノードが別の監視アプリケーションのメディエータになる場合がある。つまり、複数の監視アプリケーションがネットワークを共有する。
【００８２】
上記の実施形態では、例えば、監視ノードＮ２２では、ＳＩＰトラヒックとＲＴＰトラヒックの２つの検出結果を関連付けて、その結果を監視ノードＮ２４に送信している。しかしながら、関連付けられるべきトラヒックの種類は２には限られない。例えば、トラヒックの種類は３以上であっても良い。その場合、１つの監視ノードで全ての種類のトラヒックの検出結果を関連付けているが、例えば第１ノードで、２つの種類のトラヒックの検出結果を関連付け、その結果と残りの種類のトラヒックの検出結果を関連付けても良い。このように、順番に関連付けを行いながら、メッセージが転送されても良い。
【００８３】
また、ＤＡＴの階層の深さが一定になるように、ノードを配置すれば、より一層負荷分散を行うことができる。ＤＡＴに限定されず、他のデータアグリゲーションアルゴリズムを適用しても良い。
【００８４】
また、本発明では、ＶｏＩＰ用通信システムの分散監視システムについて説明したが、この分散監視システムの異なる監視アプリケーションが、例えば通信システムのＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）の監視とセキュリティの監視を同時に行なっても良い。
【００８５】
また、各テーブルの各フィールドのデータを制限することにより、フィルター機能を実現し、望まれるトラヒックを監視することができる。
【００８６】
また、本発明では、監視ノードがプローブノードとしてどのアプリケーションのトラヒックを監視して検出すべきかは、サーバ５３から配布されるルールテーブルで決まり、その検出結果についてのデータが、最終的に送られるべきかコレクタノードは、監視テーブルで決まり、具体的には監視テーブルに規定されたハッシュ関数値を計算してコレクタノードのノードＩＤが決定されている。そのノードＩＤとＤＡＴとから検出結果が次に送信されるべき監視ノードが決定されている。送信先の監視ノードが関連付けノードであれば、そのノードにより受信された複数の検出結果データが関連付けられ、上述と同様にして、次のノードが決定される。
【００８７】
このように、関連付けられるべきアプリケーションごとに動的にサーバ５３から種々のテーブルを監視ノードに配布すれば、ノードに関してばかりでなく、時間的にも負荷を分散することができる。
【００８８】
ルールテーブルや監視テーブルは、管理系ネットワークを介してノードに送付されているとして説明したが、サーバ５３からサーバ用ネットワーク（図示せず）を介して送付しても良い。この場合、監視ノードは、サーバとのインターフェースを、上記構成とは別個に有していることが望ましい。また、第２実施形態のように、監視ノードが検知ノードと処理ノードに分けられるときは、サーバ５３から検知ノードに対してルールテーブルや監視テーブルを送付し、更に、検知ノードのインターフェース部と処理ノードのインターフェース部とを介して、検知ノードから処理ノードに対して監視テーブルを送付するようにしても良い。
【００８９】
第１、２の実施形態は、ＤＨＴ／ＤＡＴでネットワークを構成し、更にハッシュ値でコレクタを決定することにより、スケーラブル、フォールトトレラントでありながら異なる監視アプリケーションをサポートすることができる。
【００９０】
こうして、本発明の監視システムでは、スケーラビリティとフォールトレランスを考慮し、制御プレーンとデータプレーンを使用するアプリケーションの監視のような、高度な機能の監視も可能となる。
【００９１】
＜第３実施形態＞
次に、本発明の第３実施形態による分散監視システムについて説明する。
本実施形態では、更に、上記の各実施形態による分散監視システムにバックトラッキング機能を追加する事例について説明する。
【００９２】
以下、ワーム検知を例に、バックトラッキング機能の構成、及び動作を説明する。
ワーム検知の場合は、プローブがワームが発生するパケットを検知するフィルタを保持しているとする。プローブがワームが発生させたパケットを検知すると、ＤＡＴの仕組みを活用して、パケットの情報をメディエータ、コレクタにわたす。コレクタに、ワームのパケットを検知したというイベントが大量に集まった場合、オペレータは、バックトラッキング機能を使うことで、イベントに関するパケットの情報を確認することができる。
【００９３】
図３の第１実施形態に、バックトラッキング機能のために、バックトラックテーブル５０１が追加した図１１を用いて構成の説明をする。
【００９４】
なお、第２実施形態においても、同様にバックトラックテーブル５０１を図９の処理ノード２２０に追加することでバックトラッキング機能を提供できる。
【００９５】
バックトラックテーブル５０１の例を図１２に示す。バックトラックテーブル５０１には、イベントの種類、下位ノードＩＤ、イベントのカウント、イベントを受信した最初の時刻、イベントを受信した最後の時刻が格納されている。コレクタにイベントが収集されるたびに、各ノードがそれぞれに持つバックトラックテーブル５０１に情報を格納していく。
【００９６】
オペレータがコレクタにバックトラッキングの指示を出すと、コレクタは、該当イベントが経由したＤＡＴ上の下位ノードを確認し、コレクタが該当するＤＡＴ上の各ノードに通知する。監視部２０４が、バックトラックテーブル５０１を参照することで、該当イベントが経由したＤＡＴ上の下位ノードＩＤを確認することができる。また、ＤＨＴ／ＤＡＴ部２０３、送信部２０５、管理系インタフェース２０１を介して監視部２０４から、該当するＤＡＴ上の各ノードへ通知される。
【００９７】
通知を受け取った下位のノードがプローブではない場合は、各ノードは、該当イベント経由したＤＡＴ上の更に下位のノードを確認し、各ノードはＤＡＴ上の該当ノードへ通知する。通知は、下位ノードの管理系インタフェース２０１、受信部２０２、ＤＨＴ／ＤＡＴ部２０３、を介して監視部２０４が受け取る。監視部２０４が自ノードはプローブでないと判断したら、同じように、バックトラックテーブル５０１を参照し、下位ノードのＩＤを確認し、該当するＤＡＴ上の各ノードへ通知される。
【００９８】
各ノードは、上記の処理を、プローブに辿り着くまで繰り返し、自ノードがプローブである場合は、該当イベントに関連するパケットの情報を監視部２０４が検索する。続いて、パケットの情報をＤＡＴ上の上位ノードに送信する。コレクタに辿り着くまでパケット情報を送信し、コレクタに辿り着いたら処理は完了である。
【００９９】
第１の実施例の処理フローを示す図７Ａにバックトラッキング処理を追加した図１３を用いて動作の説明をする。
【０１００】
なお、第２の実施例においても同様にバックトラッキング処理を追加できる。
【０１０１】
（１）ステップＳ５１
オペレータがコレクタにバックトラッキングの指示を出すと、コレクタは、該当イベントが経由したＤＡＴ上の下位ノードを確認する。
【０１０２】
（２）ステップＳ５２
コレクタは、該当するＤＡＴ上の各ノードに通知する。
【０１０３】
（３）ステップＳ５３
コレクタから通知を受け取った各ノードは、自ノードがプローブかどうか確認する。
【０１０４】
（４）ステップＳ５４
各ノードは、自ノードがプローブではない場合は、該当イベントが経由したＤＡＴ上の更に下位のノードを確認する。
【０１０５】
（５）ステップＳ５５
各ノードは、確認されたＤＡＴ上の該当ノードへ通知する。各ノードは、プローブに辿り着くまでこれらの処理を繰り返す。
【０１０６】
（６）ステップＳ５６
各ノードは、自ノードがプローブである場合は、該当イベントに関連するパケットの情報を検索する。
【０１０７】
（７）ステップＳ５７
続いて、プローブであるノードは、パケットの情報をＤＡＴ上の上位ノードに送信する。すなわち、ステップＳ５２〜ステップＳ５５における通知の処理と逆の流れでパケット情報の送信の処理が行われる。
【０１０８】
（８）ステップＳ５８
プローブであるノードは、コレクタに辿り着くまでパケット情報を送信し、コレクタに辿り着いたら処理を完了する。ここでは、プローブであるノードからパケット情報を受け取った各ノードは、自ノードがコレクタかどうか確認する。各ノードは、自ノードがコレクタではない場合は、該当イベントが経由したＤＡＴ上の更に上位のノードを確認する。各ノードは、確認されたＤＡＴ上の該当ノードへパケット情報を送信する。各ノードは、コレクタに辿り着くまでこれらの処理を繰り返す。
【０１０９】
以上のプロセスを踏むことで、オペレータは、イベントを検知したプローブがわかり、イベントに関連する情報を取得することが可能となる。
【０１１０】
最後に、図１４を参照して、本発明の各実施形態による分散監視システムを実現するためのハードウェア構成の一例について説明する。ここでは、各監視ノード５１−ｉの例として、計算機を想定している。この場合、図９に示す第２実施形態の検知ノード１２０及び処理ノード２２０は、それぞれ独立した計算機とする。すなわち、第２実施形態の検知ノード１２０及び処理ノード２２０の各々は、それぞれが各監視ノード５１−ｉと同じハードウェア構成であるものとする。
【０１１１】
本発明の各実施形態による分散監視システムのハードウェア構成は、プログラムの取得経路によって変化する。計算機が記憶媒体（メディア）からプログラムを取得する場合、分散監視システムのハードウェア構成は、記憶媒体１０００と、計算機２０００を含む。計算機がネットワークを介してプログラムを取得する場合、分散監視システムのハードウェア構成は、計算機２０００と、外部記憶装置３０００を含む。なお、どちらでも良い場合、分散監視システムのハードウェア構成は、記憶媒体１０００と、計算機２０００と、外部記憶装置３０００を含む。
【０１１２】
記憶媒体１０００は、各監視ノード５１−ｉとして計算機を機能させるための計算機読み取り可能なプログラム１５００を格納している。記憶媒体１０００の例として、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋ）、ＵＳＢメモリ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ  ｍｅｍｏｒｙ）、ＳＤカード（Ｓｅｃｕｒｅ  Ｄｉｇｉｔａｌ  ｍｅｍｏｒｙ  ｃａｒｄ）、或いは他のメモリカード等が考えられる。なお、記憶媒体１０００は、ＵＳＢケーブル等を介して計算機に接続される電子装置でも良い。本質的に同じだからである。但し、実際には、これらの例に限定されない。
【０１１３】
計算機２０００は、プログラム１５００を実行することで、各監視ノード５１−ｉとして機能する電子装置である。計算機２０００の例として、ＰＣ（パソコン）、シンクライアント端末／サーバ、ワークステーション、メインフレーム、スーパーコンピュータ等のコンピュータを始め、家庭用ゲーム機、双方向テレビ、デジタルレコーダー、情報家電（ｉｎｆｏｒｍａｔｉｏｎ  ｈｏｍｅ  ａｐｐｌｉａｎｃｅ）、ＰＯＳ（Ｐｏｉｎｔ  ｏｆ  Ｓａｌｅ）端末、ＯＡ（Ｏｆｆｉｃｅ  Ａｕｔｏｍａｔｉｏｎ）機器等が考えられる。計算機２０００は、車両や船舶、航空機等の移動体に搭載されていても良い。但し、実際には、これらの例に限定されない。
【０１１４】
計算機２０００は、処理装置２００１と、主記憶装置２００２と、二次記憶装置２００３と、ネットワークインタフェース２００４と、記憶媒体挿入口２００５を備える。ここでは、処理装置２００１、主記憶装置２００２、二次記憶装置２００３、ネットワークインタフェース２００４、及び記憶媒体挿入口２００５は、互いにデータバスで接続されているものとする。なお、特に図示しないが、実際には、計算機２０００は、更に、入力装置や表示装置等を備えていても良い。
【０１１５】
処理装置２００１は、プログラム１５００を読み取り、実際にプログラム１５００を実行する。処理装置２００１の例として、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）、マイクロプロセッサ（ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ）、マイクロコントローラ、或いは、同様の機能を有する半導体集積回路（Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ（ＩＣ））等が考えられる。但し、実際には、これらの例に限定されない。
【０１１６】
主記憶装置２００２は、処理装置２００１が実際にプログラム１５００を実行している時、プログラム１５００や処理中のデータを一時的に記憶する。主記憶装置２００２の例として、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ  Ｅｒａｓａｂｌｅ  ａｎｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、フラッシュメモリ、又はこれらの組み合わせ等が考えられる。但し、実際には、これらの例に限定されない。
【０１１７】
二次記憶装置２００３は、プログラム１５００を記憶し、処理装置２００１にプログラム１５００を提供する。ここでは、二次記憶装置２００３は、プログラム１５００、処理に使用するデータ、及び処理結果のデータを記憶する。なお、処理装置２００１が記憶媒体１０００から直接プログラム１５００をロードし、主記憶装置２００２にプログラム１５００を一時的に記憶して使用する場合、二次記憶装置２００３は、プログラム１５００を記憶しなくても良い。二次記憶装置２００３の例として、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）等が考えられる。二次記憶装置２００３は、必ずしも計算機２０００に内蔵されていなくても良い。例えば、二次記憶装置２００３は、周辺機器（外付けＨＤＤ等）でも良い。但し、実際には、これらの例に限定されない。
【０１１８】
ネットワークインタフェース２００４は、ネットワークを介して、計算機２０００と外部との間で通信を行う。ネットワークインタフェース２００４の例として、ＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）等のネットワークアダプタや、アンテナ等の通信装置、接続口（コネクタ）等の通信ポート等が考えられる。また、ネットワークの例として、インターネット、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、無線ＬＡＮ（Ｗｉｒｅｌｅｓｓ  ＬＡＮ）、バックボーン（Ｂａｃｋｂｏｎｅ）、ケーブルテレビ（ＣＡＴＶ）回線、固定電話網、携帯電話網、専用線（ｌｅａｓｅ  ｌｉｎｅ）、ＩｒＤＡ（Ｉｎｆｒａｒｅｄ  Ｄａｔａ  Ａｓｓｏｃｉａｔｉｏｎ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、シリアル通信回線等が考えられる。但し、実際には、これらの例に限定されない。
【０１１９】
記憶媒体挿入口２００５は、記憶媒体を配置することで、記憶媒体を読み取るための挿入口である。ここでは、記憶媒体挿入口２００５は、記憶媒体１０００が配置された際に、記憶媒体１０００に格納されたプログラム１５００を読み取る。記憶媒体挿入口２００５の例として、ＤＶＤ駆動装置（ＤＶＤドライブ）、ＵＳＢポート、ＳＤメモリーカードスロット、ＵＳＢ以外の規格に準拠した各種ケーブルを差し込む接続口（コネクタ）等が考えられる。但し、実際には、これらの例に限定されない。
【０１２０】
外部記憶装置３０００は、各監視ノード５１−ｉとして計算機を機能させるための計算機読み取り可能なプログラム１５００を格納している。外部記憶装置３０００の例として、外部のサーバ（Ｗｅｂサーバ、ファイルサーバ等）、ＤＡＳ（Ｄｉｒｅｃｔ  Ａｔｔａｃｈｅｄ  Ｓｔｏｒａｇｅ）、ＦＣ−ＳＡＮ（Ｆｉｂｒｅ  Ｃｈａｎｎｅｌ  −  Ｓｔｏｒａｇｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、ＮＡＳ（Ｎｅｔｗｏｒｋ  Ａｔｔａｃｈｅｄ  Ｓｔｏｒａｇｅ）、ＩＰ−ＳＡＮ（ＩＰ  −  Ｓｔｏｒａｇｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等が考えられる。なお、外部記憶装置３０００は、他の監視ノード５１−ｉやサーバ５３でも良い。但し、実際には、これらの例に限定されない。
【０１２１】
ここで、主信号系ネットワークインタフェース部１０１、受信部１０２、インタフェース部１０４、管理系ネットワークインタフェース部２０１、受信部２０２、送信部２０５、及びインタフェース部２０６は、ネットワークインタフェース２００４に該当する。また、検知部１０３、ＤＨＴ／ＤＡＴ部２０３、及び監視部２０４は、処理装置２００１に該当する。格納部１１０は、主記憶装置２００２及び二次記憶装置２００３に該当する。すなわち、主記憶装置２００２及び二次記憶装置２００３には、ルールテーブル１１１、監視テーブル２１１、ノードテーブル２１２、監視結果データバッファ２１３、ＤＡＴバッファ２１４、及びバックトラックテーブル５０１のうち必要なものが格納される。
【０１２２】
なお、処理装置２００１、主記憶装置２００２、二次記憶装置２００３、ネットワークインタフェース２００４、及び記憶媒体挿入口２００５の各々は、それぞれ同系統の装置の集合体でも良い。例えば、主信号系ネットワークインタフェース部１０１と管理系ネットワークインタフェース部２０１（及び、図９のインタフェース部１０４とインタフェース部２０６）には、それぞれ別個のＮＩＣを使用することが考えられる。この場合、個々のＮＩＣをまとめてネットワークインタフェース２００４と呼ぶ。また、計算機２０００がマルチＣＰＵの計算機である場合、個々のＣＰＵをまとめて処理装置２００１と呼ぶ。
【０１２３】
以上、本発明の実施形態を詳述してきたが、実際には、上記の実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の変更があっても本発明に含まれる。
【０１２４】
尚、この出願は、２００９年２月１８日に出願された日本特許出願２００９−０３５９４２号、及び、２００９年９月１日に出願された日本特許出願２００９−２０１３００号を基礎とする優先権を主張し、その開示の全てを引用によりここに組み込む。
【図１】
0005578445.tif 000002
【図２】
0005578445.tif 000003
【図３】
0005578445.tif 000004
【図４】
0005578445.tif 000005
【図５】
0005578445.tif 000006
【図６】
0005578445.tif 000007
【図７Ａ】
0005578445.tif 000008
【図７Ｂ】
0005578445.tif 000009
【図８】
0005578445.tif 000010
【図９】
0005578445.tif 000011
【図１０Ａ】
0005578445.tif 000012
【図１０Ｂ】
0005578445.tif 000013
【図１１】
0005578445.tif 000014
【図１２】
0005578445.tif 000015
【図１３】
0005578445.tif 000016
【図１４】
0005578445.tif 000017