(57)【要約】  監視システムは、監視対象システムの内部の処理負荷が異なる数種類の通信トラフィックが対象システムに入力されている場合に、限られた計測情報から、対象システムの応答特性を比較的少ない計算量で計算する状態計算処理部（分析ユニット）と、監視対象システムの内部の処理負荷が異なる数種類の通信トラフィックを、それぞれ個別の通信トラフィックに仕分ける前処理部（前処理ユニット）と、を備える。また、監視システムは、監視対象システムの障害発生を検知するため、対象システムの内部状態を示す値を計算する状態計算部と、当該値の変化を検出することで、対象システムの内部状態や構成が変化したことを判定しアラートを出力する状態判定部を備える。
2015182629.tif 000002
【特許請求の範囲】
【請求項１】
監視システムであって、
計測ユニットと、分析ユニットと、を備え、
前記計測ユニットは、対象装置に入力されるメッセージ及び該対象装置から出力されるメッセージに関するトラフィック情報を計測し、
前記分析ユニットは、
所定の関係式と、計測したトラフィック情報と、に基づき、１つ以上の指標を計算し、
前記指標、もしくは、前記指標の変化と、閾値と、の比較に基づいて、該対象装置が特定の状態に変化したことを検知する
ことを特徴とする監視システム。
【請求項２】
請求項１に記載の監視システムであって、
計測した該対象装置毎のトラフィック情報を、該対象装置での処理種別に応じて１つもしくは複数の論理ノードに仕分ける処理ユニットをさらに備え、
前記分析ユニットは、該論理ノード毎に、１つもしくは複数の前記指標が変化したと判断した場合に、該論理ノードが特定の状態に変化したことを検知する
ことを特徴とする監視システム。
【請求項３】
請求項１に記載の監視システムであって、
前記分析ユニットは、
該対象装置のバッファサイズの予測値を求め、
計測するトラフィック情報に基づくメッセージ数が、求められたバッファサイズの予測値を超えると、メッセージ廃棄のアラートを出力する
ことを特徴とする監視システム。
【請求項４】
請求項３に記載の監視システムであって、
前記分析ユニットは、
計測したトラフィック情報に基づきメッセージの廃棄を判断し、
メッセージが廃棄されたときの前記対象装置におけるメッセージ滞留数をバッファサイズの予測値とする
ことを特徴とする監視システム。
【請求項５】
請求項２に記載の監視システムであって、
前記分析ユニットは、
該論理ノードのバッファサイズの予測値を求め、
計測するトラフィック情報に基づくメッセージ数が、求められたバッファサイズの予測値を超えると、メッセージ廃棄のアラートを出力する
ことを特徴とする監視システム。
【請求項６】
請求項５に記載の監視システムであって、
前記分析ユニットは、
計測したトラフィック情報に基づきメッセージの廃棄を判断し、
メッセージが廃棄されたときの該対象装置の論理ノードにおけるメッセージ滞留数をバッファサイズの予測値とする
ことを特徴とする監視システム。
【請求項７】
請求項１に記載の監視システムであって、
前記分析ユニットは、
前記対象装置又は該対象装置の前記論理ノードが特定の状態に変化したことを検知すると、該対象装置から予め定められたネットワーク上の距離内にある他の対象装置のトラフィック情報計測頻度を上げる
ことを特徴とする監視システム。
【請求項８】
請求項１に記載の監視システムであって、
前記関係式は、単位時間あたりの到着メッセージ数である、該対象装置へのメッセージ到着率と、該対象装置でのメッセージ滞留時間と、該対象装置の性能又は状態を表す指標と、の関係式である
ことを特徴とする監視システム。
【請求項９】
請求項８に記載の監視システムであって、
前記関係式は、待ち行列理論に基づき予め定められ、以下の関係を満たす
ことを特徴とする監視システム：
Mu=Lambda+1/W
ここで、Muは対象装置の性能又は状態を表す指標、Lambdaは単位時間内のメッセージ数に基づく対象装置への平均メッセージ到着率、Wは単位時間内のメッセージについての対象装置での平均滞留時間である。
【請求項１０】
請求項１に記載の監視システムであって、
前記分析ユニットは、
前記計測ユニットが計測した前記トラフィック情報から前記閾値を生成する
ことを特徴とする監視システム。
【請求項１１】
請求項１に記載の監視システムであって、
前記分析ユニットは、
前記指標それぞれの履歴を記憶し、
前記履歴を用いて、前記指標のそれぞれの変化量を計算し、
当該変化量と予め記憶している前記閾値とを比較する
ことを特徴とする監視システム。
【請求項１２】
請求項１に記載の監視システムであって、
前記特定の状態への変化は、対象装置の障害の発生である
ことを特徴とする監視システム。
【請求項１３】
請求項２に記載の監視システムであって、
前記特定の状態への変化は、該論理ノードの障害の発生である
ことを特徴とする監視システム。
【請求項１４】
監視装置であって、
計測部と、分析部と、を備え、
前記計測部は、対象装置に入力されるメッセージ及び該対象装置から出力されるメッセージに関するトラフィック情報を計測し、
前記分析部は、
所定の関係式と、計測したトラフィック情報と、に基づき、１つ以上の指標を計算し、
前記指標、もしくは、前記指標の変化と、閾値と、の比較に基づいて、該対象装置が特定の状態に変化したことを検知する
ことを特徴とする監視装置。
【請求項１５】
計算機に実行させることにより、前記計算機を監視装置として機能させる監視プログラムであって、
前記監視装置は、
対象装置に入力されるメッセージ及び該対象装置から出力されるメッセージに関するトラフィック情報を計測し、
所定の関係式と、計測したトラフィック情報と、に基づき、１つ以上の指標を計算する処理と、
前記指標、もしくは、前記指標の変化と、閾値と、の比較に基づいて、該対象装置が特定の状態に変化したことを検知する処理と、を実行する
ことを特徴とする監視プログラム。
【発明の詳細な説明】
【参照による取り込み】
【０００１】
本出願は、２０１４年５月３０日に出願された日本特許出願第２０１４−１１３２２５号の優先権を主張し、その内容を参照することにより、本出願に取り込む。
【技術分野】
【０００２】
開示される主題は、監視装置及びそのための監視プログラムに関する。
【背景技術】
【０００３】
近年、複数の通信ノード（以下、ノードという）が接続されたネットワークにおいて、装置仕様や運用基準等により、ノードがブラックボックス化されＣＰＵ利用率などのノードの内部情報が利用できないシステムが知られている。【０００４】
一方、ノードの障害を検出するシステムとして、ノードの内部情報を利用するシステムが知られている。【０００５】
特許文献１には、ネットワークで発生した障害の検出及び診断のためのネットワークトラブルシューティングフレームワークに関する技術について開示されている。開示された技術によれば、概略次のように、ネットワークで発生した障害を検出する。まず、それぞれの間で通信を行うノードが、ノード群によって構成されているネットワークの挙動や構成を記述したデータを、マネージャノードに送信する。マネージャノードはネットワークシミュレーション機能を備えており、受信したデータを基に、ネットワークパフォーマンスを推測する。そして、推測したネットワークパフォーマンスが、各ノードで計測したネットワークパフォーマンスと異なっているかどうかを判定する。異なっていれば、その原因と考えられる１つ又は複数の障害を判定する。【０００６】
また、特許文献２には、出生死滅過程をベースとした数理モデルを用いて、対象システムのモデリングを行う“Ｄａｔａ  Ｐｒｏｃｅｓｓｉｎｇ  Ｓｙｓｔｅｍ  Ｍｏｄｅｌｌｉｎｇ  Ｕｎｉｔ”と、対象システムへの負荷量に対する性能値を、上記数理モデル及び対象システムのサービス応答時間の計測値を基に計算して通知する“Ｐｅｒｆｏｒｍａｎｃｅ  Ｍｅａｓｕｒｅ  Ｃａｌｃｕｌａｔｉｏｎ  Ｕｎｉｔ”と、を有する“Ｐｅｒｆｏｒｍａｎｃｅ  Ｃａｌｃｕｌａｔｉｏｎ”装置について開示されている（例えば、請求項３２参照）。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特許第４７８６９０８号公報
【特許文献２】ＵＳ２０１３／０１８５０３８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
特許文献１が開示する技術によれば、マネージャノードは、ノードから送信されるネットワーク設定情報を利用してネットワークシミュレーションを行う（例えば段落［０００７］、［０００８］、［０００９］、［００１０］参照）。ネットワーク設定情報は、各ノードで動作するエージェントモジュールが計測するノード内部の情報であり、例えば信号強度、トラフィック統計量、ルーティングテーブル情報を含む（例えば段落［００１１］、［００１２］、［００１３］、［００１４］参照）。【０００９】
しかし、特許文献１では、ネットワーク設定情報を各ノードで計測又は送信することができない場合にネットワークの障害を検出する方法については、開示されていない。上述のように、例えば、ノードの装置仕様やネットワークの運用基準等により、ノードがブラックボックス化されている場合がある。この場合、ノードにエージェントモジュールをインストールすることができず、マネージャノードは、ノードの持つネットワーク設定情報を取得できない。そのため、マネージャノードは、ネットワーク設定情報を利用したネットワークシミュレーションを行うことが困難である。【００１０】
上述のように内部情報がブラックボックス化されたノードを用いてネットワークシステムを構築した場合、従来技術では、監視システムがノードから取得した内部情報に基づいてネットワークシステムの障害を検出することが困難である。よって、例えばノードから内部情報を取得しなくても、ネットワークシステムの通信障害を検出するための技術が望まれている。
【課題を解決するための手段】
【００１１】
開示されるのは、ネットワークシステムを構成する装置に入力される情報及び装置から出力される情報から、ノードの障害又はノードの状態の変化を検出する監視システム、監視装置及び監視プログラムである。【００１２】
開示される一態様では、一つ以上のノードの送受信トラフィックを計測し、分析することにより、各ノード性能を推測する。【００１３】
一つの態様では、さらに、各ノードの性能を複数回推測し、それらの変化を調べる。あるノードについて、所定の範囲を超える変化を検出した時、当該ノードの障害として検知する。【００１４】
これにより、ネットワーク通信の計測データを用いて、ノードの内部情報を用いずに、ノードの通信障害を検出することが可能になる。【００１５】
トラフィックの計測には、例えば、ネットワークＴＡＰ装置（以下、ＴＡＰ装置）を用いる。ＴＡＰ装置とは、ネットワーク信号を複製して計測機器に送信する装置である。ＴＡＰ装置は、ネットワークの一つ以上の箇所に設置する。【００１６】
また、他の態様では、ノードの性能の一つとして、例えばノードのバッファ量を推測する。その他、ノード外部の状態、例えば、トラフィック量を計測する。推測したバッファ量を超過するトラフィック量を検出したときに、これらの情報を併せて、ノードに輻輳の発生を予測するように構成しても良い。これにより、バーストトラフィック到着時の呼損もしくは再送による輻輳発生を予測できる。【００１７】
さらに他の態様では、計測箇所の段階的な絞り込みにより、障害が発生しているノードを特定するように構成しても良い。これにより、ＴＡＰ装置の少ない台数で、効率的かつ高精度な監視システムを構成できる。【００１８】
より具体的な態様の一つは、監視システムであって、
当該監視システムは、計測ユニットと、分析ユニットと、を備え、
計測ユニットは、対象装置に入力されるメッセージ及び該対象装置から出力されるメッセージを監視する装置を用いて該メッセージに関するトラフィック情報を計測し、
分析ユニットは、所定の関係式と、計測したトラフィック情報と、に基づき、１つ以上の指標を計算し、１つの指標、もしくは、複数の指標の変化と、閾値と、の比較に基づいて、該対象装置が特定の状態に変化したことを検知する、という特徴を備える。【００１９】
他の態様は、監視装置であって、
当該監視装置は、計測部と、分析部と、を備え、
計測部は、対象装置に入力されるメッセージ及び対象装置から出力されるメッセージを監視する装置を用いて該メッセージに関するトラフィック情報を計測し、
分析部は、所定の関係式と、計測したトラフィック情報と、に基づき、１つ以上の指標を計算し、１つの指標、もしくは、複数の指標の変化と、閾値と、の比較に基づいて、該対象装置が特定の状態に変化したことを検知する、という特徴を備える。【００２０】
他の態様は、計算機に実行させることにより、計算機を上記監視装置として機能させる監視プログラムである。
【発明の効果】
【００２１】
開示によると、ネットワークを構成する装置に入力される情報及び装置から出力される情報から、ノードの状態を検出し、さらに、検出した状態を利用する監視システム、監視装置及び監視プログラムを提供することができる。【００２２】
本明細書において開示される主題の、少なくとも一つの実施の詳細は、添付されている図面と以下の記述の中で述べられる。開示される主題のその他の特徴、態様、効果は、以下の開示、図面、請求項により明らかにされる。
【図面の簡単な説明】
【００２３】
【図１】各実施の形態の、ネットワークシステムと監視システムの構成例を示すブロック図である。
【図２】実施の形態１の、関連付け設定情報の構成例を示す図である。
【図３】実施の形態１の、セッションテーブルの構成例を示す図である。
【図４】実施の形態１の、状態履歴情報の構成例を示す図である。
【図５】監視システムの各装置のハードウェア構成例を示す図である。
【図６】実施の形態１の、トラフィック解析処理を例示するフローチャートである。
【図７】実施の形態１の、論理ノード仕分け処理を例示するフローチャートである。
【図８】実施の形態１の、呼損抽出処理を例示するフローチャートである。
【図９】実施の形態１及び２の、システム状態計算処理を例示するフローチャートである。
【図１０】実施の形態１及び２の、システム状態判定処理を例示するフローチャートである。
【図１１】実施の形態３の、システム構成情報の構成例を示す図である。
【図１２】実施の形態３の、計測優先度制御処理を例示するフローチャートである。
【図１３】実施の形態３の、選択的信号処理を例示するフローチャートである。
【図１４】監視システムにおける概略フローチャートを示す。
【発明を実施するための形態】
【００２４】
（概要）
まず、各実施の形態の概要を説明する。本明細書で開示するネットワーク監視システムは、ネットワークシステムを監視するネットワーク監視システムであって、ネットワークシステムは複数のノードを備え、ノードは、ネットワークを経由して、他のノードと相互に通信を行う。
【００２５】
一実施形態におけるネットワーク監視システムは、監視対象システムの内部の処理負荷が異なる数種類の通信トラフィックが対象システムに入力されている場合に、限られた計測情報から、低負荷から高負荷となる様々な負荷に対する、対象システムの応答特性を少ない計算量で計算するための、状態計算処理を行う。また、ネットワーク監視システムは、上記状態計算処理において、モデリング処理を行わなくてすむように、監視対象システムの内部の処理負荷が異なる、数種類の通信トラフィックを、それぞれ個別の通信トラフィックに仕分けるための、前処理を行う。
【００２６】
また、ネットワーク監視システムは、監視対象システムの障害発生を検知するため、対象システムの内部状態、例えば最大処理性能など、を示す値を計算する、上記状態計算処理を行う。また、ネットワーク監視システムは、当該値の変化を検出することで、対象システムの内部状態や構成が変化したことを判定し、アラートを出力する、状態判定処理を行う。
【００２７】
また、他の実施形態における上記ネットワーク監視システムは、監視対象システムに対して、バースト的な大量メッセージが送信され、対象システムが受信したメッセージをバッファに記憶しきれずに、送信されたメッセージが廃棄されたことを早期に予測する。そのために、ネットワーク監視システムは、対象システムにあるメッセージが送信されたことを計測した際に、対象システムで処理待ちになっている滞留メッセージ数を記憶しておき、対象システムがそのメッセージを処理した後に本来送信するであろうメッセージが計測されなかった場合に、対象システムでメッセージ廃棄が発生したことを判定して、さらに、記憶した滞留メッセージ数も合わせて上記状態計算処理に報告する、上記前処理を行う。また、ネットワーク監視システムは、上記前処理から報告された、メッセージ廃棄の発生時の滞留メッセージ数を用いて、対象システムの物理的な状態、例えばバッファサイズなど、を推測する、上記状態計算処理を行う。ネットワーク監視システムは、上記状態計算処理によって推測されたバッファサイズを超過する量の通信トラフィックが対象システムに送信された場合に、バッファ溢れによるメッセージ廃棄が発生すると予測し、アラートを出力する、上記状態判定処理を行う。
【００２８】
また、さらに他の実施形態における上記ネットワーク監視システムは、上記状態判定処理が、ある対象システムのノードの状態が変化したことを検出した際に、予め記憶している対象システムの構成情報を用いて、状態変化を検出したノードに論理的に近い距離に位置するノードの近辺の通信トラフィックの計測頻度を増加し、それ以外の通信トラフィックの計測頻度を減少させるように、上記計測装置に指示を送信する、計測優先度制御処理を行う。また、ネットワーク監視システムは、上記計測優先度制御処理から指示を受信すると、指示に従って、計測頻度を変化させる、選択的信号受信処理を行う。
【００２９】
（実施の形態１）
次に、実施の形態１を、図面を参照して説明する。ここでは、ネットワークシステムの障害発生を検知する例を用いて実施の形態を開示する。
【００３０】
まず、図１から図４を用いて、監視システム２０を構成する各要素の構成例を説明する。
【００３１】
図１は、ネットワークシステム１０と、監視システム２０の構成例を示すブロック図である。ネットワークシステム１０は、例えば、ネットワークを形成する複数のノード１１（図１では例として１１ａ〜１１ｅで示す）とシステムマネージャ１２を備える。ノード１１は、ネットワークを経由して、他のノード１１と相互に通信する。システムマネージャ１２は、ノード１１群を管理する。
【００３２】
また、ネットワークシステム１０は、複数台のＴＡＰ装置（ネットワークタップ）１３（図１では例として１３ａ〜１３ｄで示す）をさらに備える。ＴＡＰ装置１３は、ネットワークを介して伝送されるパケットを、ネットワークシステム１０の所定の計測箇所にて複製し、例えばネットワークケーブル１４（図１では例として１４ａ〜１４ｄで示す）を媒体として、複製されたパケットを監視システム２０の計測ユニット２１に伝送する装置である。
【００３３】
監視システム２０は、例えば計測ユニット２１と、前処理ユニット（トラフィック報告作成部）２２と、分析ユニット２３とを、それぞれ１台又は複数台備える。なお、本実施の形態では、計測ユニット２１、前処理ユニット２２及び分析ユニット２３は別々の装置として説明するが、ひとつの物理的な装置（監視装置）内に各ユニットが物理的又は論理的に備えられてもよい。この場合、計測ユニット２１、前処理ユニット２２及び分析ユニット２３はそれぞれ、監視装置の計側部、前処理部及び分析部と称する場合がある。計測ユニット及び分析ユニットは、それぞれ、装置の中の、例えばハードウェアの１デバイスとして実装される可能性もある。例えば、分析機能付ＤＰＩ装置などとして実装されることができる。
【００３４】
計測ユニット２１は、ネットワークを監視して、ネットワークシステム１０の各ノード１１間で送受信される通信データ（メッセージ）をＴＡＰ装置１３等を利用して傍受し、信号検査処理２１２により、当該通信データの内容を検査し、前処理ユニット２２に検査報告データを送信する。
【００３５】
検査報告データは、例えば、プロトコル情報（例えばメッセージの宛先ＩＰアドレス、送信元ＩＰアドレス、インタフェース情報、及び、プロシージャ情報を含む）、計測時刻（例えばメッセージを傍受した日時情報）、及び、関連付け用属性情報（ＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｏｂｉｌｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｉｄｅｎｔｉｔｙ）など）を含む。インタフェース情報やプロシージャ情報については、関連付け設定情報２２１の説明にて後述する。
【００３６】
前処理ユニット２２は、計測ユニット２１から検査報告データを受信し、当該検査報告データを解析して、１台又は複数台のノード１１を備えるネットワークシステム１０の通信トラフィックの状況を計算し、計算した通信トラフィックの状況を、トラフィック報告データとして分析ユニット２３に送信する。
【００３７】
ここで、通信トラフィックとは、ノード１１が送受信する通信データ（メッセージ）を指す。例えば、複数台のノード１１間で通信する制御信号や、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）などのアプリケーションプロトコルの要求及び応答メッセージである。以降、ノード１１が送受信する通信トラフィックのデータの単位を、メッセージと呼称して説明する。なお、ノード１１が受信するメッセージを到着メッセージ、送信するメッセージを出発メッセージと呼称する。また、メッセージはＩＰパケットでも良い。
【００３８】
トラフィック報告データは、ノード１１が送受信したメッセージに関するサマリ情報であり、あるノード１１がメッセージを受信してから別のノード１１に送信するまでの滞留時間や、再送、呼損に関する補足情報を含む。トラフィック報告データの内容の詳細は、後述する。
【００３９】
前処理ユニット２２は、関連付け設定情報２２１を記憶する記憶部と、セッションテーブル２２２を含む記憶部を備える。関連付け設定情報２２１とセッションテーブル２２２のいずれか又は双方は、前処理ユニット２２の外部にあってもよく、図１ではセッションテーブル２２２が、前処理ユニット２２の外部にある例を示している。関連付け設定情報２２１とセッションテーブル２２２の各記憶部は、ひとつの記憶装置の別々の記憶領域でもよい。
【００４０】
図２は、実施の形態１の、関連付け設定情報２２１の構成例を示す図である。関連付け設定情報２２１は、論理ノード仕分け処理２２４に用いる設定情報である。論理ノード仕分け処理２２４は、ネットワークシステム１０の各ノード１１での、到着メッセージと出発メッセージとを関連付け、ノード１１が到着メッセージを受信してから出発メッセージを送信するまでの、処理負荷や処理フローの違いを区別し、関連付けした到着メッセージと出発メッセージとのセッションを、処理負荷や処理フローに応じて異なる論理ノードに仕分ける処理である。論理ノード、および、論理ノード仕分け処理２２４については後述する。関連付け設定情報２２１は、管理者又は運用者によって予め設定される。
【００４１】
関連付け設定情報２２１は、例えば、到着メッセージのインタフェース情報２２１１とプロシージャ情報２２１２（まとめて到着メッセージ情報と呼ぶ）と、出発メッセージのインタフェース情報２２１３とプロシージャ情報２２１４（まとめて出発メッセージ情報と呼ぶ）と、関連付け情報として属性情報２２１５と、ノードモデルとして処理種別２２１６と、を含む。
【００４２】
インタフェース情報（２２１１、２２１３）は、ノード１１間の通信規格の種別を示す情報である。また、プロシージャ情報（２２１２、２２１４）は、到着メッセージや出発メッセージに含まれる、処理内容を示す情報である。関連付け情報の属性情報２２１５は、到着メッセージと出発メッセージとの関連付けに使う情報である。
【００４３】
例えば、ＬＴＥ（登録商標、Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）と呼ばれる携帯電話等の無線通信規格における、ＥＰＣ（Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｃｏｒｅ）アーキテクチャに本システムを適用する場合は、インタフェース情報（２２１１、２２１３）は、「Ｓ１ＡＰ」や「Ｓ６ａ」といった情報を含む。また、プロシージャ情報（２２１２、２２１４）は、”Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ”や”Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ”といった情報を含む。また、属性情報２２１５は、例えばＩＭＳＩと呼ばれる、携帯電話ユーザの識別番号を示す情報を含む。
【００４４】
また、処理種別２２１６は、ノード１１で、到着メッセージを受信してから出発メッセージを送信するまでの、処理負荷や処理フローの違いを区別するための識別情報である。例えば、到着メッセージを受信し、ノード１１内で処理して出発メッセージを送信する処理に対する処理種別を「ＹＹＹ＿Ｑ１」（第１処理種別）とし、到着メッセージを受信し、ＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）サーバなどの別のノード１１に問い合わせてから出発メッセージを送信する処理に対する処理種別を「ＹＹＹ＿Ｑ２」（第２処理種別）とする。なお、問い合わせるノードが異なる場合は、「ＹＹＹ＿Ｑ２」を更に複数に分けて「ＹＹＹ＿Ｑ２−１」、「ＹＹＹ＿Ｑ２−２」のようにしてもよい。ここで、ＹＹＹはノード１１の種類を示す文字列、例えば「ＭＭＥ」などが入る。なお、これ以外にも、例えば遅延時間の大小に応じて分類して別々の処理種別をつけてもよいし、ノードでの処理内容に応じた適宜の粒度で分類して処理種別をつけてもよい。
【００４５】
図３は、セッションテーブル２２２の構成例を示す図である。セッションテーブル２２２は、前処理ユニット２２で、到着メッセージと出発メッセージとを関連付けしたものの状況を、セッションとして管理するためのテーブルである。
【００４６】
セッションテーブル２２２は、１つ以上のエントリ（セッションエントリ）を含む。セッションテーブル２２２の各エントリは、到着メッセージ情報として、計測時刻２２２０と、インタフェース情報２２２１と、プロシージャ情報２２２２と、再送フラグ２２２３と、到着時滞留数２２２４と、を含む。また、セッションテーブル２２２の各エントリは、出発メッセージ情報として、計測時刻２２２５と、インタフェース情報２２２６と、プロシージャ情報２２２７と、属性情報２２２８と、呼損フラグ２２２９とを含む。さらに、セッションテーブル２２２の各エントリは、論理ノード情報として、物理ノード情報２２３０と、処理種別２２３１とを含む。
【００４７】
まず、セッションテーブル２２２の到着メッセージ情報と出発メッセージ情報の各要素について説明する。計測時刻（２２２０及び２２２５）は、検査報告データに含まれる計測時刻情報を記憶する領域である。インタフェース情報（２２２１及び２２２６）は、関連付け設定情報２２１のインタフェース情報（２２１１又は２２１３）を記憶する領域である。プロシージャ情報（２２２２及び２２２７）は、関連付け設定情報２２１のプロシージャ情報（２２１２又は２２１４）を記憶する領域である。
【００４８】
再送フラグ２２２３は、計測ユニット２１が同一の内容の到着メッセージを複数回計測した場合（すなわち、前処理ユニット２２が、内容が同一の到着メッセージの検査報告データを複数回受信した場合）に、２回目以降の到着メッセージは再送されたメッセージであると判断し、フラグ情報として記憶する領域である。到着時滞留数２２２４は、到着メッセージを計測した時点での、同一論理ノード内に滞留しているメッセージの数である。すなわち、到着メッセージを計測したが出発メッセージを計測できていない、メッセージの組の数である。一例では、到着時滞留数２２２４は、セッションテーブル２２２内の、同一の論理ノード情報を持つエントリ数をカウントした値である。
【００４９】
属性情報２２２８は、関連付け設定情報２２１の属性情報２２１５を記憶する領域である。呼損フラグ２２２９は、前処理ユニット２２が、到着メッセージの検査報告データを受信したにもかかわらず、対応する出発メッセージの検査報告データを、予め定められた時間（タイムアウト時間）内に受信しなかった場合に、到着メッセージの宛先のノード１１（到着メッセージの受信ノード）で呼損が発生したと判断し、フラグ情報として記憶する領域である。なお、再送フラグ２２２３及び呼損フラグ２２２９のフラグ情報は、例えば真（ＴＲＵＥ）を示す値、又は偽（ＦＡＬＳＥ）を示す値のどちらかである。
【００５０】
次に、論理ノード情報について説明する。本実施の形態では、物理的なノード１１での処理を、処理種別に応じてひとつ又は複数の論理的なノードに分類して管理する。例えば、論理ノード情報は、到着メッセージを処理して出発メッセージを出力するノードを識別するための情報である。論理ノード情報は、物理ノード情報２２３０と、処理種別２２３１を含む。
【００５１】
物理ノード情報２２３０は、ノード１１の装置（ハードウェア）を物理的に識別するための情報であり、例えば、ノード１１のＩＰアドレスを用いる。ここで、ノード１１のＩＰアドレスは、例えば、到着メッセージの宛先ＩＰアドレスを用いる。別の例では、出発メッセージの送信元ＩＰアドレスでも良い。処理種別２２３１は、関連付け設定情報２２１の処理種別２２１６と同じ情報である。詳細は後述するが、前処理ユニット２２は、関連付け設定情報２２１から検索されたエントリの処理種別２２１６の値を、処理種別２２３１として記憶する。
【００５２】
前処理ユニット２２は、物理ノード情報２２３０と処理種別２２３１の組を用いて、論理ノードを識別する。例えば、ある２種類の到着メッセージを同じノード１１が受信した場合に、それぞれ処理種別２２３１が異なるならば、前処理ユニット２２は、その２種類の到着メッセージを論理的に別々の論理ノードが受信したものとみなす。分析ユニット２３も、論理ノード情報を用いて同様に判断する。
【００５３】
分析ユニット２３は、前処理ユニット２２からトラフィック報告データを受信し、受信した当該トラフィック報告データと所定のアルゴリズムとを用いて、ネットワークシステム１０の性能及び／又は内部状態を示す１つ又は複数の値を、状態情報として計算する。分析ユニット２３は、当該状態情報の履歴を記憶し、状態情報の当該履歴から、当該状態情報の１つ又は複数の値の変化量を計算し、当該変化量と所定の閾値とを比較する。分析ユニット２３は、比較した結果、変化量が閾値以上であれば、ネットワークシステム１０が特定の状態に変化した、と判断する。なお、分析ユニット２３のより詳細の処理は後述する。
【００５４】
また、分析ユニット２３は、トラフィック報告バッファ２３１と、状態履歴情報２３３の記憶部を備える。トラフィック報告バッファ２３１は、トラフィック報告データを記憶する。
【００５５】
状態履歴情報２３３について、図４を用いて説明する。
【００５６】
状態履歴情報２３３は、例えば、管理情報２３３１と、論理ノード情報として物理ノード情報２３３２及び処理種別２３３３と、トラフィック情報としてメッセージ到着数情報２３３４と、推測状態情報として最大処理性能情報２３３５、バッファサイズ２３３６及び予測呼損数情報２３３７とを含む情報を記憶する。
【００５７】
一例では、分析ユニット２３は、論理ノードごとの推測状態情報を参照しやすくするため、状態履歴２３３の記憶領域を、論理ノード情報（物理ノード情報と処理種別の組）の単位で別々に備える。
【００５８】
管理情報の計測時刻２３３１は、トラフィック報告データから抽出した計測時刻が記憶される。論理ノード情報の物理ノード情報２３３２と処理種別２３３３は、トラフィック報告データから抽出した論理ノード情報の物理ノード情報と処理種別が記憶される。トラフィック情報のメッセージ到着数２３３４は、トラフィック報告データに基づきカウントされるメッセージ到着数である。推測状態情報の最大処理性能２３３５、バッファサイズ２３３６及び予測呼損数２３３７は、分析ユニット２３で求められた推測値が記憶される。なお、メッセージ到着数に加えて、又はその代わりに、メッセージ到着率を記憶してもよい。
【００５９】
図５に、計測ユニット２１、前処理ユニット２２、分析ユニット２３などの各装置のハードウェア構成の一例を示す。
【００６０】
これらの装置は、ＣＰＵ（処理部）１００１、主記憶装置１００２、ＨＤＤ等の外部記憶装置１００５、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等の可搬性を有する記憶媒体１００８から情報を読み出す読取装置１００３、ディスプレイ、キーボードやマウスなどの入出力装置１００６、ネットワーク１９に接続するためのＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）等の通信装置１００４、及び、それらの装置間を接続するバスなどの内部通信線１００７を備えたコンピュータ１０００により実現できる。なお、構成要素の一部を省略してもよい。
【００６１】
例えば、セッションテーブル２２２、関連付け設定情報２２１の記憶部及び状態履歴情報２３３の記憶部は、主記憶装置１００２の一部の領域を用いて実現できる。
【００６２】
また、各装置は、それぞれの外部記憶装置１００５に記憶されている各種プログラムを主記憶装置１００２にロードしてＣＰＵ１００１で実行し、必要に応じて、通信装置１００４を用いてネットワーク１９に接続して、他の装置とのネットワーク通信を行い、又は、ネットワークＴＡＰ装置１３からのパケットを受信することにより、各実施の形態における各種処理と各種記憶を実現できる。
【００６３】
また、上記プログラムは予め外部記憶装置１００５に格納されていても良いし、必要に応じて、ネットワーク１９、または、記憶媒体１００８を介して、他の装置から導入しても良い。
【００６４】
例えば、前処理ユニット２０のＣＰＵは、図１に示すトラフィック解析処理２２３、論理ノード仕分け処理２２４、呼損抽出処理２２５及び報告処理２２６の各処理を実行する。また、例えば分析ユニット２３のＣＰＵは、図１に示すシステム状態計算処理２３２、システム状態判定処理２３４及び計測優先度制御処理２３６の各処理を実行する。なお、実施の形態１では計測優先度制御処理２３６は省略し、実施の形態３で説明する。
【００６５】
以下、図６から図１０を用いて、実施の形態１での、監視システム２０における監視処理について説明する。
【００６６】
（トラフィック解析処理２２３）
トラフィック解析処理２２３は、前処理ユニット２２において、計測ユニット２１から検査報告データを受信すると、セッションテーブル２２２でセッション管理を行うのに必要な情報を抽出し、当該情報をセッションテーブル２２２に記憶し、分析ユニット２３での分析処理のための情報からトラフィック報告データを作成し、分析ユニット２３に当該トラフィック報告データを送信する処理である。
【００６７】
図６は、前処理ユニット２２がトラフィック解析処理２２３で行う処理を例示するフローチャートである。
【００６８】
まず、前処理ユニット２２は、計測ユニット２１から受信した検査報告データから、プロトコル情報（メッセージの宛先ＩＰアドレス、送信元ＩＰアドレス、インタフェース種別、及び、プロシージャ情報）、計測時刻、及び、関連付け用属性情報（ＩＭＳＩなど）を抽出する（ステップＳ１１）。
【００６９】
次に、前処理ユニット２２は、抽出したプロトコル情報を検索条件として、既存のセッションテーブル２２２を参照し、プロトコル情報と出発メッセージ情報が一致するセッションエントリを検索する（ステップＳ１２）。例えば、インタフェース種別とプロシージャ情報が一致するエントリを特定する。なお、セッションテーブル２２２の新規登録については後述する。
【００７０】
一致するセッションエントリがある場合は（Ｓ１３、Ｙｅｓ）、前処理ユニット２２は、到着メッセージと出発メッセージの各計測時刻の差を、滞留時間として計算する（ステップＳ１４）。なお、ステップＳ１３で該当するセッションエントリがある場合とは、例えば、あるノード１１が受信した到着メッセージを処理して、対応する出発メッセージを出力した場合に相当する。ここで到着メッセージの計測時刻２２２０は、該当するセッションエントリに記憶されており、出発メッセージの計測時刻は、検査報告データ内の計測時刻を用いることができる。前処理ユニット２２は、検査報告データ内の計測時刻をセッションテーブル２２２の出発メッセージ情報の計測時刻２２２５の領域に記憶してもよい。計算された滞留時間は、例えば論理ノード情報と対応付けて適宜記憶し、トラフィック報告の際に読み出される。
【００７１】
そして、前処理ユニット２２は、セッションが終了したエントリに関するトラフィック報告データを分析ユニット２３に送信し、該当するセッションエントリを削除し、処理を終了する（ステップＳ１５）。
【００７２】
トラフィック報告データは、ノード１１が送受信したメッセージに関するサマリ情報である。トラフィック報告データの内容は、例えば、計測時刻と、論理ノード情報と、滞留時間と、到着時滞留数と、再送フラグと、呼損フラグとを含む。
【００７３】
トラフィック報告データの計測時刻は、セッションテーブル２２２で管理する、出発メッセージ情報の計測時刻２２２５と同じ情報を含む。なお、呼損時は、出発メッセージが無いため、トラフィック報告データを生成した時刻を含む。トラフィック報告データの論理ノード情報は、セッションテーブル２２２で管理する、物理ノード情報２２３０及び処理種別２２３１と同じ情報を含む。トラフィック報告データの滞留時間は、ノード１１がメッセージを受信してから別のノード１１に送信するまでの、メッセージがノード１１に滞留している時間であり、ステップＳ１４の計算結果である。トラフィック報告データの到着時滞留数は、セッションテーブル２２２で管理する、到着時滞留数２２２４と同じ情報である。トラフィック報告データの再送フラグは、セッションテーブル２２２で管理する、再送フラグ２２２３と同じ情報である。トラフィック報告データの呼損フラグは、セッションテーブル２２２で管理する、呼損フラグ２２２９と同じ情報である。
【００７４】
一方、ステップＳ１３で一致するセッションエントリがない場合（Ｓ１３：Ｎｏ）、前処理ユニット２２は、検査報告データから抽出したプロトコル情報を検索条件として、既存のセッションテーブル２２２を参照し、検査報告データから抽出したプロトコル情報と到着メッセージ情報が一致するセッションエントリを検索する（ステップＳ１６）。なお、ステップＳ１３で該当するエントリが無い場合とは、例えば、ノード１１が到着メッセージを受信した後、対応する出発メッセージを送信していない状態で、同じ内容の到着メッセージを受信した場合、換言すると再送メッセージを受信した場合に相当する。
【００７５】
ステップＳ１７において一致するセッションエントリがある場合は（ステップＳ１７）、前処理ユニット２２は、該当するセッションエントリの再送フラグ２２２３にＴＲＵＥを記憶し（ステップＳ１８）、処理を終了する。
【００７６】
また、一致するセッションエントリがない場合は（ステップＳ１７）、前処理ユニット２２は、セッションテーブル２２２に新規のセッションエントリを作成する（ステップＳ１９）。前処理ユニット２２は、検査報告データから抽出した計測時刻、インタフェース種別及びプロシージャ情報を、新規のセッションエントリの到着メッセージ情報の対応する領域（２２２０〜２２２２）にそれぞれ記憶する。
【００７７】
そして、前処理ユニット２２は、論理ノード仕分け処理２２４での処理フローに進む（ステップＳ２０）。
【００７８】
（論理ノード仕分け処理２２４）
論理ノード仕分け処理２２４は、前処理ユニット２２において、ノード１１が到着メッセージを受信してから出発メッセージを送信するまでの、処理負荷や処理フローの違いを区別し、関連付けした到着メッセージと出発メッセージのセッションを、処理負荷や処理フローに応じて異なる論理ノードに仕分ける処理である。
【００７９】
図７は、前処理ユニット２２が論理ノード仕分け処理２２４で行う処理を例示するフローチャートである。
【００８０】
まず、前処理ユニット２２は、新規のセッションエントリ作成ステップＳ１９の完了を確認する（ステップＳ３１）。
【００８１】
次に、前処理ユニット２２は、検査報告データから抽出したプロトコル情報の、インタフェース情報とプロシージャ情報の組を検索条件として、関連付け設定情報２２１から、到着メッセージ情報のインタフェース情報２２１１及びプロシージャ情報２２１２が一致するエントリを検索する（ステップＳ３２）。
【００８２】
前処理ユニット２２は、一致した関連付け設定情報２２１のエントリの出発メッセージのプロトコル情報（インタフェース情報２２１３、プロシージャ情報２２１４を含む）を、新規セッションエントリの出発メッセージ情報のインタフェース情報２２２６及びプロシージャ情報２２２７に設定する（ステップＳ３３）。これにより、以降に出発メッセージによる検査報告データを受信したときにステップＳ１２及びＳ１３で、出発メッセージ情報と一致するセッションエントリがある、と判断できる。
【００８３】
さらに、前処理ユニット２２は、一致した関連付け設定情報２２１のエントリの関連付け情報に指定された属性情報２２１５（一例ではＩＭＳＩを示す種別情報）に該当する情報（具体的な識別番号）を、検査報告データのメッセージの関連付け用属性情報から抽出し、新規セッションエントリの出発メッセージ情報の属性情報２２２８に追加記憶する（ステップＳ３４）。
【００８４】
さらに、前処理ユニット２２は、一致した関連付け設定情報２２１のエントリの処理種別２２１６を、新規セッションエントリの論理ノード情報の処理種別２２３１に記憶する（ステップＳ３５）。
【００８５】
そして、前処理ユニット２２は、検査報告データのプロトコル情報に含まれる宛先ＩＰアドレスを、新規セッションエントリの論理ノード情報の物理ノード情報２２３０に記憶する（ステップＳ３６）。
【００８６】
前処理ユニット２２は、セッションテーブル２２２から、同一の論理ノード情報（物理ノード情報２２３０と処理種別２２３１の組を含む）を持つセッションエントリ数をカウントし、その値を新規セッションエントリの到着時滞留数２２２４に記憶し（ステップＳ３７）、処理を終了する。なお、新規エントリの再送フラグ２２２３、呼損フラグ２２２９は、ＦＡＬＳＥに初期設定されてもよい。
【００８７】
（呼損抽出処理２２５）
呼損抽出処理２２５は、前処理ユニット２２において、到着メッセージの検査報告データを受信したにもかかわらず、対応する出発メッセージの検査報告データを、所定の時間（タイムアウト時間）内に受信しなかった場合に、到着メッセージの宛先のノード１１で呼損が発生したと判断し、セッションテーブル２２２の該当するセッションエントリに判断基準を記憶する処理である。
【００８８】
図８は、前処理ユニット２２が呼損抽出処理２２５で行う処理を例示するフローチャートである。
【００８９】
前処理ユニット２２は、セッションテーブル２２２の最初のセッションエントリから、最後のセッションエントリまで、次の処理を繰り返す（ステップＳ４１、Ｓ４４）。前処理ユニット２２は、現在時刻が、到着メッセージ情報の計測時刻２２２０に所定のタイムアウト時間を加えた時刻を超過しているかを判断する（ステップＳ４２）。ここで、一例では、所定のタイムアウト時間として、設定ファイルに予め記載されている値を用いる。超過しているならば、前処理ユニット２２は、該当するセッションエントリの呼損フラグ２２２９にＴＲＵＥを記憶し、分析ユニット２３にトラフィック報告データを送信する（ステップＳ４３）。超過していないならば、処理をスキップし、次のセッションエントリに進む。
【００９０】
次に、分析ユニット２３における処理を説明する。分析ユニット２３は、前処理ユニット２２からトラフィック報告データを受信すると、トラフィック報告バッファ２３１に記憶する。
【００９１】
（システム状態計算処理２３２）
システム状態計算処理２３２は、分析ユニット２３において、論理ノード毎の障害発生を検知するため、前処理ユニット２２からトラフィック報告データを受信し、当該トラフィック報告データに含まれる情報から、論理ノードの内部状態、一例では最大処理性能を計算する処理である。
【００９２】
図９は、分析ユニット２３がシステム状態計算処理２３２で行う処理を例示するフローチャートである。ここでは、分析ユニット２３は、状態情報を、一時的な記憶領域に格納する。なお、本実施の形態では、図９中のステップＳ５４及びステップＳ５５は省略する。ステップＳ５４及びＳ５５については、実施の形態２で述べる。
【００９３】
まず分析ユニット２３は、予め定められた単位時間毎に、トラフィック報告バッファ２３１から、バッファリングされている複数のトラフィック報告データを読み出す（ステップＳ５１）。ここで、単位時間は、一例では、秒〜数１０秒オーダの値であり、設定ファイルに予め記載されている値を用いる。
【００９４】
次に、分析ユニット２３は、トラフィック報告データに含まれている論理ノード情報（物理ノード情報と処理種別の組）別にトラフィック報告データを仕分け、論理ノード情報毎に、対応するトラフィック報告データに基づき以下の（ａ）及び（ｂ）の計算を行う（ステップＳ５２）。
【００９５】
（ａ）対応するトラフィック報告データのメッセージ到着数をカウントし、単位時間で割り算して平均値を算出し、得られた平均値を状態情報のメッセージ到着率Lambdaとして記憶する。併せて、カウントしたメッセージ到着数も状態情報に記憶してもよい。メッセージ到着数は、例えばトラフィック報告の数に対応するが、トラフィック報告データの送信方法に応じて適宜カウントできる。なお、ここでの、対応するトラフィック報告データとは、所定の論理ノード情報についての上述の単位時間内におけるトラフィック報告データを示す。
【００９６】
（ｂ）対応するトラフィック報告データに含まれている滞留時間の合計をメッセージ到着数で割り算して平均値を算出し、得られた平均値を平均滞留時間Wとして記憶する。
【００９７】
次に、分析ユニット２３は、トラフィック報告データの論理ノード情報毎に、最大処理性能Muを、以下の関係式に基づいて計算し、状態情報の最大処理性能Muとして記憶する（ステップＳ５３）。
【００９８】
Mu=Lambda+1/Wここで、Lambdaは平均メッセージ到着率、Wは平均滞留時間であり、それぞれステップＳ５２で算出した値を用いる。上述の関係式は、待ち行列理論に基づき予め定められたものである。なお、論理ノード情報毎の最大処理性能Muを求める以外にも、装置の性能又は状態を表す適宜の指標を求めてもよい。
【００９９】
次に、分析ユニット２３は、トラフィック報告データから抽出した計測時刻と、状態情報に含まれるメッセージ到着数（及び／又は平均メッセージ到着率Lambda）と、トラフィック報告データから抽出した論理ノード情報の物理ノード情報と処理種別と、状態情報の最大処理性能Muの値を、それぞれ状態履歴情報２３３の計測時刻２３３１（単位時間単位で丸めた時刻）と、メッセージ到着数（率）２３３４と、論理ノード情報の物理ノード情報２３３２と処理種別２３３３と、推測状態情報の最大処理性能２３３５に記憶し（ステップＳ５６）、処理を終了する。
【０１００】
（システム状態判定処理２３４）
システム状態判定処理２３４は、分析ユニット２３において、システム状態計算処理２３２で算出した、論理ノードの内部状態を示す値の変化を検出することで、論理ノードの内部状態や構成が変化したことを判定し、例えば障害発生とみなしてアラートを出力する処理である。
【０１０１】
図１０は、分析ユニット２３がシステム状態判定２３４で行う処理を例示するフローチャートである。
【０１０２】
まず、分析ユニット２３は、状態履歴情報２３３から、論理ノード情報（物理ノード情報２３３２と処理種別２３３３の組）毎に、推測状態情報の最大処理性能２３３５の値の変化量を計算する（ステップＳ６１）。状態履歴情報２３３には、単位時間毎の状態情報が記憶されていくため、分析ユニット２３は例えば対象の論理ノードに対する直近の２つのエントリから最大処理性能２３３５の値の変化量を計算することができる。なお、直近の２つのエントリ以外にも、適宜のエントリを用いても良い。
【０１０３】
次に、分析ユニット２３は、当該変化量と、予め定められた閾値とを比較する（ステップＳ６２）。ここで、一例では、閾値として、設定ファイルに予め記載されている値を用いる。
【０１０４】
当該変化量が予め定められた閾値以上であれば（ステップＳ６３）、分析ユニット２３は、論理ノードの状態が変化したと判定し、システムマネージャ１２にシステムアラートを出力する（ステップＳ６４）。実施の形態１では、ステップＳ６５〜Ｓ６７は省略する。ステップＳ６５〜Ｓ６７については、実施の形態２で述べる。一方、当該変化量が予め定められた閾値以上でない場合（ステップＳ６３）及びステップＳ６４の実行の後、システム状態判定処理を終了する。なお、上述の説明では変化量を用いたが、変化率を用いてもよい。
【０１０５】
本実施の形態によると、対象システムの内部での処理負荷が異なる数種類の通信トラフィックが対象システムに入力された場合に、それぞれの通信トラフィックの処理に対する、対象システムの応答特性を作成することができる。また、時間を要するモデリング作業を行わずに、限られた計測情報を用いて、対象システムの汎用的な応答特性を作成することができる。さらに、計測情報から、ノードの通信障害等を検出することができる。
【０１０６】
（実施の形態２）
次に、瞬間的に大量のバースト的通信トラフィックが対象システムに入力された場合に、対象システムのパケット廃棄の状況を推測する実施の形態について、図９及び図１０を用いて説明する。例えば、対象システム（対象ノード）のバッファサイズなどの物理的な構成を推測してパケット廃棄を推測する。
【０１０７】
実施の形態２では、トラフィック報告データに、再送フラグと呼損フラグを含む。また、分析ユニット２３の処理が実施の形態１と異なる。他の構成及び処理は実施の形態１と同様であり、説明を省略する。
【０１０８】
（システム状態計算処理２３２の説明）
本実施の形態のシステム状態計算処理２３２は、分析ユニット２３において、前処理ユニット２２から受信したトラフィック報告データに含まれる、呼損フラグ及び到着時滞留数を用いて、ノード１１（の論理ノード）の物理的な状態、例えばバッファサイズなど、を推測する処理である。また、ある論理ノードにバースト的な大量メッセージが送信され、論理ノードが受信したメッセージをバッファに記憶しきれずに、送信されたメッセージが廃棄されたことを予測し、アラートを出力する処理である。
【０１０９】
図９を参照して、分析ユニット２３がシステム状態計算処理２３２で行う、実施の形態２の処理を説明する。ここでは、分析ユニット２３は、状態情報を、一時的な記憶領域に格納する。
【０１１０】
ステップＳ５１ないしステップＳ５３の処理は、実施の形態１と同じため、説明は省略する。
【０１１１】
ステップＳ５３の処理に続いて、分析ユニット２３は、トラフィック報告データから、論理ノード情報（物理ノード情報と処理種別の組）と呼損フラグと到着時滞留数とを抽出する。そして、分析ユニット２３は、呼損フラグ＝ＴＲＵＥとなっているトラフィック報告データから、論理ノード情報ごとに、到着時滞留数の最小値を求める。呼損フラグ＝ＴＲＵＥとなっている状態はメッセージが到着したが出力されていない状態であり、到着時滞留数の一部はパケット廃棄されている可能性がある。ここで求められる到着時滞留数の最小値であってもパケット廃棄が生じていると想定して、この値をバッファサイズの予測値として用いる。そして、分析ユニット２３は、当該最小値を、状態情報のバッファサイズに記憶する（ステップＳ５４）。なお、ここでのバッファサイズはメッセージ数で表されるが、他の単位で表してもよい。
【０１１２】
次に、分析ユニット２３は、トラフィック報告データの論理ノード情報（物理ノード情報と処理種別の組）ごとに、メッセージ到着数が、状態情報に記憶されているバッファサイズの値を超えているか判断し、超えている場合、超過数を状態情報の予測呼損数に記憶する（ステップＳ５５）。
【０１１３】
次に、分析ユニット２３は、トラフィック報告データから抽出した計測時刻（単位時間単位で丸めた時刻）と、状態情報に含まれるメッセージ到着数（及び／又は平均メッセージ到着率Lambda）と、論理ノード情報の物理ノード情報及び処理種別と、状態情報の最大処理性能Muの値と、バッファサイズの値と、予測呼損数の値とを、それぞれ、状態履歴情報２３３の計測時刻２３３１と、メッセージ到着数（率）２３３４と、論理ノード情報の物理ノード情報２３３２と処理種別２３３３と、推測状態情報の最大処理性能２３３５と、バッファサイズ２３３６と、予測呼損数２３３７に記憶し（ステップＳ５６）、処理を終了する。
【０１１４】
図１０を参照して、分析ユニット２３がシステム状態判定処理２３４で行う、実施の形態２の処理を説明する。ステップＳ６１からステップＳ６４までは、実施の形態１と同じである。
【０１１５】
続けて、分析ユニット２３は、状態履歴情報２３３の記憶部から、論理ノード情報（物理ノード情報２３３２と処理種別２３３３の組）ごとに、メッセージ到着数２３３４を、ある所定の微小単位時間で割り算することで、微小時間単位でのメッセージ到着数を算出し、算出した値と、バッファサイズ２３３６とを比較する（ステップＳ６５、Ｓ６６）。ここで、微小単位時間は、ステップＳ５１の単位時間よりも短い時間であり、一例では１００マイクロ秒から１秒程度の時間であり、設定ファイルに予め記載されている値を用いる。微小時間単位でのメッセージ到着数の方がバッファサイズ２３３６よりも大きければ、分析ユニット２３は、物理ノード情報２３３２と処理種別２３３３の組で示される論理ノードにて、マイクロバーストによるメッセージ廃棄が発生する（又は発生した）可能性が高い旨のシステムアラートを、システムマネージャ１２に出力する（ステップＳ６７）。なお、システムマネージャ１２に出力されるシステムアラートは、予測呼損数２３３７を含んでも良い。
【０１１６】
本実施の形態によると、受信側ノードへのバースト性トラフィックによる輻輳の発生を、できるだけ早く検出することができる。また、瞬間的に大量のバースト的通信トラフィックが対象システムに入力された場合に、対象システムのパケット廃棄の状況を推測するために必要な、対象システムの物理的な構成を推測することができる。
【０１１７】
（実施の形態３）
実施の形態３では、実施の形態１又は２の構成及び処理に加えて、ネットワークシステムのある計測地点で障害を検出した際に、障害を検出した計測地点の近辺の通信トラフィックの計測頻度を増加し、それ以外の通信トラフィックの計測頻度を減少させることで、障害の発生箇所を、効率的に絞り込む。本実施の形態について、図１２、図１３及び図１１を用いて説明する。
【０１１８】
本実施の形態の分析ユニット２３は、システム構成記憶部２３５をさらに備える（図１参照）。システム構成記憶部２３５は、ネットワークシステム１０の構成を管理する記憶領域である。また、分析ユニット２３のＣＰＵは、計測優先度制御２３６をさらに実行する。他の構成及び処理は、実施の形態１と同様であり、説明を省略する。
【０１１９】
システム構成記憶部２３５の一構成例について、図１１を用いて説明する。
【０１２０】
システム構成記憶部２３５は、ネットワークシステム１０のシステム構成（ノードの接続関係）を、木構造によって管理する。木構造を構成するノード（データノード２３５０）は、ノード１１に関する情報を含む。各データノード２３５０は、物理ノード情報２３５１と、ＴＡＰ装置情報２３５２と、ネットワークインタフェース番号２３５３とを含む。
【０１２１】
物理ノード情報２３５１は、ノード１１の装置を物理的に識別するための情報（物理ノード情報２２３０と同様）である。ＴＡＰ装置情報２３５２は、ノード装置１１に対応するＴＡＰ装置１３を識別するための情報である。ネットワークインタフェース番号２３５３は、ＴＡＰ装置と接続している計測ユニット２１のネットワークインタフェース番号を記憶する領域である。
【０１２２】
なお、本実施の形態では、ネットワークシステム１０の構成情報は、ネットワークシステム１０の管理者又は運用者によって、予めシステム構成記憶部２３５に設定（記憶）されているものとする。
【０１２３】
図１２は、分析ユニット２３が計測優先度制御処理２３６で行う、実施の形態３の処理を例示するフローチャートである。
【０１２４】
まず、分析ユニット２３は、上述の実施の形態で説明したシステム状態判定処理２３４において、ある論理ノードの状態の変化（例えば障害の発生）を検出したことを確認する（ステップＳ７１）。検出手法は、実施の形態１又は２と同様の手法を用いることができる。
【０１２５】
次に、分析ユニット２３は、システム構成記憶部２３５に記憶されているネットワークシステム１０の構成を用いて、状態変化を検出した論理ノードが属するノード１１に対する、各ＴＡＰ装置１３の距離を計算する。さらに、各ＴＡＰ装置１３が接続している計測ユニット２１のネットワークインタフェース番号を、ネットワークインタフェース番号２３５３から抽出する（ステップＳ７２）。
【０１２６】
各ＴＡＰ装置１３の距離の計算方法について、図１１の構成例を用いて説明する。例えば、分析ユニット２３は、ＳＧＷ＃１で状態変化を検出したとすると、データノード２３５０ｄと各データノード２３５０とのホップ数を計算する。この例では、ＳＧＷ＃１はホップ数＝０、ＰＧＷ＃１はホップ数＝１、ＨＳＳ＃１はホップ数＝２となる。ホップ数が小さいほどネットワーク上の距離が近く、逆に大きいほど遠いことを意味する。
【０１２７】
そして、分析ユニット２３は、予め定められた距離より近い距離のデータノードに対応するＴＡＰ装置１３をひとつ又は複数特定し、該ＴＡＰ装置１３が接続している、計測ユニット２１のネットワークインタフェース番号に対する計測処理の優先度（計測優先度）を上げ、予め定められた距離より遠い距離のＴＡＰ装置１３が接続している計測ユニット２１のネットワークインタフェース番号に対する計測処理の優先度を下げる指示を含む制御指示を計測ユニット２１に送信（ステップＳ７３）し、処理を終了する。
【０１２８】
図１３は、計測ユニット２１が選択的信号受信処理２１１で行う、実施の形態３の処理を例示するフローチャートである。
【０１２９】
まず、計測ユニット２１は、分析ユニット２３より制御指示を受信する（ステップＳ８１）。次に、計測ユニット２１は、選択的信号受信２１１において計測優先度の高いネットワークインタフェース番号に対する計測頻度を増やす。また、計測優先度の低いネットワークインタフェース番号に対する計測頻度を減らす（ステップＳ８２）。例えば、計測ユニット２１は、ＴＡＰ装置１３から受信したデータを、上述の制御指示に応じた計測頻度で適宜選択してもよい（図３１１）。なお、計測ユニット２１は、該当するＴＡＰ装置１３へ計測頻度の変更指示を出力してＴＡＰ装置１３からの送信頻度が変更されるようにしてもよい。以上の処理を順次繰り返すことで、障害の発生箇所を徐々により正確に絞り込むことができる。
【０１３０】
本実施の形態によると、監視対象システムのある計測地点で障害を検出した際に、障害を検出した計測地点の近辺の通信トラフィックの計測頻度を増加し、それ以外の通信トラフィックの計測頻度を減少させることで、障害の発生箇所を、効率的に、かつ高精度に絞り込むことができる。
【０１３１】
上記で挙げた各実施の形態は一例であり、開示に限定されず、種々の変形や応用が可能である。
【０１３２】
（構成例）
以下、上述の監視システムの構成例を例示する。
【０１３３】
構成例１：
図１４は、監視システムにおける概略フローチャートを示す。
【０１３４】
ステップＳ９１において、計測ユニット２１は、対象装置（図１の例ではノード１１）に入力されるメッセージ及び対象装置から出力されるメッセージを監視する装置（図１の例ではＴＡＰ装置１３）を用いて該メッセージに関するトラフィック情報を計測する。
【０１３５】
ステップＳ９２において、分析ユニット２３は、計測したトラフィック情報に基づき、単位時間あたりの到着メッセージ数である、対象装置へのメッセージ到着率と、該対象装置でのメッセージ滞留時間と、該装置の性能又は状態を表す指標との関係式を用いて指標（上述の例では最大処理性能Mu）を求める。
【０１３６】
ステップＳ９３において、分析ユニット２３は、求められた指標の変化に基づいて対象装置が特定の状態に変化したことを検知する。
【０１３７】
構成例２：
ネットワークシステムを監視する監視システムは、
上記ネットワークシステムは複数のノードを備え、
上記ノードは、ネットワークを経由して、他のノードと相互に通信を行うものであり、
上記監視システムは、計測ユニットと、前処理ユニットと、分析ユニットと、を備え、
上記計測ユニットは、上記ネットワークを監視して、上記ネットワークシステムが送受信する通信データを傍受し、当該通信データの内容を検査し、上記前処理ユニットに、検査報告データを送信し、
上記前処理ユニットは、上記計測ユニットから検査報告データを受信し、当該検査報告データを解析して、ノード、及び／又は、複数ノードを備える上記ネットワークシステムの、通信トラフィックの状況を計算し、計算した通信トラフィックの状況を、トラフィック報告データとして上記分析ユニットに送信し、
上記分析ユニットは、
上記前処理ユニットからトラフィック報告データを受信し、受信した当該トラフィック報告データと、所定のアルゴリズムと、を用いて、上記ネットワークシステムの性能及び／又は内部状態を示す、１つ又は複数の値を、状態情報として計算し、
当該状態情報の履歴を記憶し、状態情報の当該履歴から、当該状態情報の１つ又は複数の値の変化量を計算し、当該変化量と所定の閾値とを比較し、比較した結果、変化量が閾値以上であれば、上記ネットワークシステムが特定の状態に変化したことを検知する。
【０１３８】
構成例３：
上記ネットワークシステム内での処理負荷が異なる数種類の通信トラフィックが、上記ネットワークシステムに入力されている場合に、分析ユニットは、限られた計測情報から、低負荷から高負荷となる様々な負荷に対する、対象システムの応答特性を比較的少ない計算量で計算する。前処理ユニットは、上記ネットワークシステムの内部の処理負荷が異なる数種類の通信トラフィックを、それぞれ個別の通信トラフィックに仕分ける。
【０１３９】
構成例４：
上記分析ユニットは、上記ネットワークシステムの障害発生を検知するため、上記ネットワークシステムの内部状態を示す１つ又は複数の値を計算し、当該値の変化を検出することで、上記ネットワークシステムの内部状態や構成が変化したことを判定し、アラートを出力する。
【０１４０】
構成例５：
上記前処理ユニットは、上記ネットワークシステムにあるメッセージが送信されたことを計測した際に、上記ネットワークシステムで処理待ちになっている滞留メッセージ数を記憶しておき、上記ネットワークシステムが当該メッセージを処理した後に本来送信するであろうメッセージが計測されなかった場合に、上記ネットワークシステムでメッセージ廃棄が発生したことを判定して、記憶した上記滞留メッセージ数も合わせて上記分析ユニットに報告する。
【０１４１】
上記分析ユニットは、上記前処理ユニットから報告された、メッセージ廃棄の発生時の滞留メッセージ数を用いて、上記ネットワークシステムの物理的な状態（例えば、バッファサイズ）を推測し、推測されたバッファサイズを超過する量の通信トラフィックが上記ネットワークシステムに送信された場合に、バッファ溢れによるメッセージ廃棄が発生すると予測し、アラートを出力する。
【０１４２】
構成例６：
上記分析ユニットは、上記ネットワークシステムの上記ノードの状態が変化したことを検出した際に、予め記憶している上記ネットワークシステムの構成情報を用いて、状態変化を検出した上記ノードの近辺の通信トラフィックの計測頻度を増加し、それ以外の通信トラフィックの計測頻度を減少させるように、上記計測装置に指示を送信する。
【０１４３】
上記計測ユニットは、上記分析ユニットから指示を受信すると、当該指示に従って計測頻度を変化させる。
【０１４４】
（実施の形態の効果）
以下、従来技術と比較した本実施の形態の効果について説明する。
【０１４５】
上述の特許文献２が開示する技術では、“Ｄａｔａ  Ｐｒｏｃｅｓｓｉｎｇ  Ｓｙｓｔｅｍ  Ｍｏｄｅｌｌｉｎｇ  Ｕｎｉｔ”は、対象システムへの通信トラフィック全体に対する性能モデルの作成を行っている。ここで、対象システムの内部での処理負荷などが異なる、数種類の通信トラフィックが対象システムに入力された場合に、種類ごとのトラフィック量や比率が変化すると、性能モデルを再作成する必要が生じる。しかし、対象システムの内部での処理負荷が異なる数種類の通信トラフィックが対象システムに入力された場合に、種類ごとのトラフィック量や比率が変化しても良いように、それぞれの通信トラフィックの処理に対して個別に性能モデル作成を行う技術については、特許文献２には開示されていない。
【０１４６】
一方、上述の各実施の形態によれば、対象システムの内部での処理負荷が異なる数種類の通信トラフィックが対象システムに入力された場合でも、それぞれの通信トラフィックの処理に対する、対象システムの応答特性を作成することができる。
【０１４７】
また、“Ｐｅｒｆｏｒｍａｎｃｅ  Ｍｅａｓｕｒｅ  Ｃａｌｃｕｌａｔｉｏｎ  Ｕｎｉｔ”は、“Ｄａｔａ  Ｐｒｏｃｅｓｓｉｎｇ  Ｓｙｓｔｅｍ  Ｍｏｄｅｌｌｉｎｇ  Ｕｎｉｔ”がモデリングした、対象システムの数理モデルを用いて、対象システムへの負荷量に対する性能値を計算する。ここで、対象システムの数理モデルは、通信トラフィック全体に対する負荷量に応じて異なる応答特性のモデルである。そのため、“Ｐｅｒｆｏｒｍａｎｃｅ  Ｃａｌｃｕｌａｔｉｏｎ”装置は、対象システムに対して低負荷から高負荷となる様々な負荷の通信トラフィック量に対して、サービス応答時間を計測する必要がある。しかし、輻輳などのシステム障害を事前に検知する用途でこの開示技術を用いる場合、対象システムに対して高負荷がかかるような通信トラフィックを、必ずしも事前に計測できない場合がある。
【０１４８】
一方、上述の各実施の形態によれば、対象システムが高負荷にならない程度の通信トラフィック量から、対象システムの応答特性を推測できる。
【０１４９】
また、別の観点では、上述の特許文献２が開示する技術では、様々な負荷に対する対象システムの数理モデルを作成するため、ある程度のモデルの作成が完了するまでに、非常に長い時間を要する。しかし、システム管理者の視点では、対象システムの監視ができるようになるまでに長い時間を要することは望ましくない。
【０１５０】
一方、上述の各実施の形態によれば、できる限り短い準備時間でシステム監視を行うため、対象システムが高負荷にならない程度の量の通信トラフィックからでも、対象システムの応答特性を把握することができる。換言すると、時間を要するモデリング作業を行わずに、限られた計測情報を用いて、対象システムの汎用的な応答特性を推測できる。
【０１５１】
また、通常のネットワークシステムにおいては、あるノードに対して、他のノード又はノード群から、ネットワークを経由して瞬間的にバースト性トラフィック（ｂｕｒｓｔｙ  ｔｒａｆｆｉｃ）が送信されることがある。ここで、受信側ノードのバッファが溢れてしまうと、受信側ノードは、多量のトラフィックを受信しきれずに廃棄する。その後、送信側ノードからの再送トラフィックにより、受信側ノードに更に大量のトラフィックが到着すると、受信側ノードが高負荷のため輻輳状態に陥る場合がある。輻輳が悪化した場合、受信側ノードがダウンすることもある。
【０１５２】
特許文献２に開示された技術では、“Ｄａｔａ  Ｐｒｏｃｅｓｓｉｎｇ  Ｓｙｓｔｅｍ  Ｍｏｄｅｌｌｉｎｇ  Ｕｎｉｔ”は、数理モデルによって対象システムの性能モデル作成を行っている。瞬間的に大量のバースト的通信トラフィックが対象システムに入力された場合に、対象システムでのパケット廃棄の確率をモデルに組み込むためには、対象システムの通信バッファサイズなどの物理的な状態のモデルを作成する必要が生じる。しかし、特許文献２には、対象システムの通信バッファサイズなどの物理的な状態のモデルを作成する技術については、開示されていない。
【０１５３】
一方、上述の各実施の形態によれば、受信側ノードへのバースト性トラフィックによる輻輳の発生を、できるだけ早く検出することができる。また、瞬間的に大量のバースト的通信トラフィックが対象システムに入力された場合に、対象システムのパケット廃棄の状況を推測するために必要な、対象システムの物理的な構成を推測できる。
【０１５４】
また、ネットワークを流れる通信トラフィックのデータを計測する技術として、ＤＰＩ（Ｄｅｅｐ  Ｐａｃｋｅｔ  Ｉｎｓｐｅｃｔｉｏｎ）と呼ばれる方法がある。ただし、監視の対象となるシステムが大規模な場合、ＤＰＩ装置が大量に必要になる。しかし、ＤＰＩ装置は非常に高価である。よって、ＤＰＩ装置の台数をできるだけ少なくする技術が望まれる。
【０１５５】
上述の各実施の形態によれば、例えば、１台のＤＰＩ装置で複数点の計測を行えるように、ネットワークと接続しておき、監視対象システムのある計測地点で障害を検出した際に、障害を検出した計測地点の近辺の通信トラフィックの計測頻度を増加し、それ以外の通信トラフィックの計測頻度を減少させることで、障害の発生箇所を、効率的に、かつ高精度に絞り込むことができる。
【０１５６】
上記開示は、代表的実施形態に関して記述されているが、当業者は、開示される主題の趣旨や範囲を逸脱することなく、形式及び細部において、様々な変更や修正が可能であることを理解するであろう。
【０１５７】
例えば、上記した実施例は分かりやすい説明のために詳細に記載したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加、削除及び置換をすることが可能である。
【０１５８】
また、上記の各構成、機能、処理部等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
【０１５９】
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
【符号の説明】
【０１６０】
１０：ネットワークシステム１１：ノード１２：ネットワークマネージャ１３：ＴＡＰ装置１４：ネットワークケーブル１９：ネットワーク２０：監視システム２１：計測ユニット２１１：選択的信号受信処理２１２：信号検査処理２２：前処理ユニット２２１：関連付け設定情報２２２：セッションテーブル２２３：トラフィック解析処理２２４：論理ノード仕分け処理２２５：呼損抽出処理２２６：報告処理２３：分析ユニット２３１：トラフィック報告バッファ２３２：システム状態計算処理２３３：状態履歴情報２３４：システム状態判定２３５：システム構成記憶領域２３６：計測優先度制御処理１０００：コンピュータ１００１：ＣＰＵ１００２：主記憶装置１００３：読取装置１００４：通信装置１００５：外部記憶装置１００６：入出力装置１００７：内部通信線１００８：可搬記憶媒体２２１１：到着メッセージのプロトコル情報のインタフェース情報２２１２：到着メッセージのプロトコル情報のプロシージャ情報２２１３：出発メッセージのプロトコル情報のインタフェース情報２２１４：出発メッセージのプロトコル情報のプロシージャ情報２２１５：関連付け情報の属性情報２２１６：ノードモデルの処理種別２３３１：管理情報２３３２：論理ノード情報の物理ノード情報２３３３：論理ノード情報の処理種別２３３４：トラフィック情報のメッセージ到着数情報２３３５：推測状態情報の最大処理性能情報２３３６：推測状態情報のバッファサイズ２３３７：推測状態情報の予測呼損数情報
【図１】
2015182629.tif 000003
【図２】
2015182629.tif 000004
【図３】
2015182629.tif 000005
【図４】
2015182629.tif 000006
【図５】
2015182629.tif 000007
【図６】
2015182629.tif 000008
【図７】
2015182629.tif 000009
【図８】
2015182629.tif 000010
【図９】
2015182629.tif 000011
【図１０】
2015182629.tif 000012
【図１１】
2015182629.tif 000013
【図１２】
2015182629.tif 000014
【図１３】
2015182629.tif 000015
【図１４】
2015182629.tif 000016
【国際調査報告】
2015182629.tif 000017
2015182629.tif 000018