特許 5853465 ネットワーク分析システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5853465

(24)【登録日】2015年12月18日

(45)【発行日】2016年2月9日

(54)【発明の名称】ネットワーク分析システム

(51)【国際特許分類】

   H04L 12/70 20130101AFI20160120BHJP

   H04L 12/26 20060101ALI20160120BHJP

【ＦＩ】

   H04L12/70 100Z

   H04L12/26

【請求項の数】4

【全頁数】28

(21)【出願番号】特願2011-164674(P2011-164674)

(22)【出願日】2011年7月27日

(65)【公開番号】特開2013-30927(P2013-30927A)

(43)【公開日】2013年2月7日

【審査請求日】2014年5月15日

【前置審査】

(73)【特許権者】

【識別番号】000000295

【氏名又は名称】沖電気工業株式会社

(74)【代理人】

【識別番号】100180275

【弁理士】

【氏名又は名称】吉田 倫太郎

(74)【代理人】

【識別番号】100161861

【弁理士】

【氏名又は名称】若林 裕介

(74)【代理人】

【識別番号】100090620

【弁理士】

【氏名又は名称】工藤 宣幸

(72)【発明者】

【氏名】中村 信之

(72)【発明者】

【氏名】伊加田 恵志

(72)【発明者】

【氏名】村谷 正之

【審査官】 衣鳩 文彦

(56)【参考文献】

【文献】 特開２０００−０６９００２（ＪＰ，Ａ）

【文献】 特開２００７−０６７８３３（ＪＰ，Ａ）

【文献】 特開平０８−０６５３０１（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ １２／００〜１２／９５５

(57)【特許請求の範囲】

【請求項1】

ネットワークに関する分析を行うネットワーク分析システムにおいて、
１又は複数のデータ処理モジュールと、上記データ処理モジュールを収容し、上記データ処理モジュールを用いて、上記ネットワークに関する分析処理を行うネットワーク分析装置とを備え、
上記ネットワーク分析装置は、
上記データ処理モジュールを収容するデータ処理モジュール収容手段と、
上記ネットワークに関する分析対象データを保持する分析対象データ保持手段と、
上記分析対象データ保持手段が保持した分析対象データの処理を、一部又は全部の上記データ処理モジュールを用いて行う工程を定義したデータ処理定義情報を格納するデータ処理定義情報格納手段と、
上記データ処理定義情報格納手段に格納されたデータ処理定義情報に基づいて上記分析対象データ保持手段が生成した所定のデータ処理モジュールに対してデータ処理を実行させるための所定の形式のデータ処理フレームを用いて、上記データ処理を、上記データ処理モジュールに実行させて、そのデータ処理結果を得るデータ処理実行手段とを有し、
それぞれの上記データ処理モジュールは、
上記ネットワーク分析装置と接続する接続手段と、
上記ネットワーク分析装置からの要求に応じたデータ処理を上記データ処理フレームに基づいて行うデータ処理手段とを有し、
上記ネットワーク分析装置が上記データ処理モジュールを複数収納しており、
上記分析対象データ保持手段は上記複数のデータ処理モジュールを利用したデータ処理を定義した一つのデータ処理フレームを生成し、
上記データ処理実行手段が上記一つのデータ処理フレームに基づいて、上記複数のデータ処理モジュールを用いたデータ処理を実行させ、
上記分析対象データ保持手段が生成する上記データ処理フレームには、データ処理に利用する上記複数のデータ処理モジュール、上記複数のデータ処理モジュールにデータ処理させる場合の処理順序及び、各データ処理モジュールにデータ処理をさせる際に指定するパラメータが記述されており、
それぞれの上記データ処理モジュールは、上記データ処理フレームに基づいて所定のデータ処理を行う場合、対象の上記データ処理モジュールの上記データ処理手段が当該データ処理を実行後、当該データ処理フレームのデータを当該データ処理後のデータに置換したうえで、当該データ処理フレームに記述された処理順序中の当該データ処理モジュールの要素を削除する
ことを特徴とするネットワーク分析システム。

【請求項2】

上記ネットワーク分析装置は、
上記データ処理モジュール収容手段に収容されている上記データ処理モジュールを管理するデータ処理モジュール管理手段と、
上記データ処理定義情報格納手段に格納されているデータ処理定義情報に関する情報を管理するデータ処理定義情報管理手段とをさらに備える
ことを特徴とする請求項１に記載のネットワーク分析システム。

【請求項3】

上記分析対象データ保持手段は、上記収容されているデータ処理モジュールのアンインストールの要求があった場合、上記データ処理モジュール管理手段に登録されている当該データ処理モジュールのデータ処理利用情報に基づいてアンインストールの可否を判断することを特徴とする請求項２に記載のネットワーク分析システム。

【請求項4】

複数のデータ処理エンジンと、ネットワークに接続され、上記データ処理エンジンを収容し、上記データ処理エンジンを用いて、上記ネットワークに関する分析処理を行うネットワーク分析装置とを備えるネットワーク分析システムにおいて、
上記ネットワーク分析装置は、
上記ネットワークに関する分析対象データと、上記分析対象データの処理を一部又は全部の上記データ処理エンジンを用いて行う工程を定義したデータ処理定義情報に基づいて、所定のデータ処理エンジンに対してデータ処理を実行させるための所定の形式のデータ処理フレームを生成するエンジン連携処理部と、
上記データ処理フレームに基づいて、上記データ処理を上記データ処理エンジンに実行させて、そのデータ処理結果を得るエンジン共通駆動部とを有し、
それぞれの上記データ処理エンジンは、
上記ネットワーク分析装置と接続するインタフェース部と、
上記ネットワーク分析装置からの要求に応じたデータ処理を上記データ処理フレームに基づいて行うデータ処理部とを有し、
上記エンジン連携処理部は上記複数のデータ処理エンジンを利用したデータ処理を定義した一つのデータ処理フレームを生成し、
上記エンジン共通駆動部が上記一つのデータ処理フレームに基づいて、上記複数のデータ処理エンジンを用いたデータ処理を実行させ、
上記エンジン連携処理部が生成する上記データ処理フレームには、データ処理に利用する上記複数のデータ処理エンジン、上記複数のデータ処理エンジンにデータ処理させる場合の処理順序及び、各データ処理エンジンにデータ処理をさせる際に指定するパラメータが記述されており、
それぞれの上記データ処理エンジンは、上記データ処理フレームに基づいて所定のデータ処理を行う場合、対象の上記データ処理エンジンの上記データ処理部が当該データ処理を実行後、当該データ処理フレームのデータを当該データ処理後のデータに置換したうえで、当該データ処理フレームに記述された処理順序中の当該データ処理エンジンの要素を削除する
ことを特徴とするネットワーク分析システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ネットワーク分析システムに関し、例えば、ネットワークの利用状況や動作状態に関する分析を行い、その分析結果に基づいてネットワークを監視するシステムに適用することができる。

【背景技術】

【0002】

ネットワークの利用状況や動作状態に関して分析し、その分析結果に基づいて異常の有無を監視することが必要であることは従来から知られている。

【0003】

従来、ＩＰネットワークの利用状況や動作状態に関する分析を行うアルゴリズムは、さまざまな物が開発されており、具体的には、例えば、特許文献１〜４の記載技術がある。

【0004】

特許文献１に記載されたアルゴリズムは、ＩＰネットワーク上を流れるＩＰパケットについて、データ系列中の各値の出現頻度を計数（ＩＰアドレス毎にエラー検出数を集計）し、さらに、ＩＰアドレス毎にエラー検出数を集計し、一定割合以上のエラーの要因となっているＩＰアドレスもしくは経路を得るものである。

【0005】

また、特許文献２に記載されたアルゴリズムは、ＩＰネットワーク上を流れるＩＰパケットについて、統計的な分析を行った統計量を算出し、その統計量について過去の統計量と比較したときの乖離度合いから異常を検出するものである。

【0006】

さらに、特許文献３に記載されたアルゴリズムは、ＩＰネットワーク上を流れるＩＰパケットについて、ＲＦ法（Ｒａｎｄｏｍ Ｆｏｒｅｓｔ法）を用いた判定により、ネットワークの品質劣化を検知するものである。そして、特許文献３の記載技術では、事前に複数のパラメータについて、正常状態の値を判定正解値（教師入力）として検知装置入力して学習させておき、学習結果に基づき、現在のＩＰネットワークに関するパラメータから品質劣化を検知する。

【0007】

さらにまた、特許文献４に記載されたアルゴリズムは、時系列情報（例えば、ＩＰネットワークのトラフィック量の遷移等）を多重解像度解析し、さらに、その解像度成分をニューラルネットワーク（ニューロ）を用いた学習機に入力して学習を行い、その学習結果に基づき、時系列情報を予測するものである。

【先行技術文献】

【特許文献】

【0008】

【特許文献1】特開２００９−１７１２５２号公報

【特許文献2】特開２００６−１４８６８６号公報

【特許文献3】特開２０１０−１８３２２０号公報

【特許文献4】特開２０１０−２０４９７４号公報

【発明の概要】

【発明が解決しようとする課題】

【0009】

しかしながら、従来、ＩＳＰ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）事業者等が、自社のネットワーク設備について、利用状況や動作状態に関して上述の従来技術（例えば、特許文献１〜特許文献４の記載技術）を用いて分析するネットワーク分析システムを構築した場合、以下のような問題があった。

【0010】

特許文献１〜４に示されるように、ネットワーク分析システムで用いられる処理アルゴリズムは複雑な処理が必要であり、さらに、短時間に大量の処理を行う必要があるため（特に、広帯域のネットワークについてリアルタイムに監視を行う場合）、従来は、分析したい内容に特化したシステム開発が必要とされていた。

【0011】

そのため、従来のネットワーク分析システムでは、後から柔軟な仕様変更（例えば、処理アルゴリズムの方式変更や処理工程の追加等）を行うことや、既に構築したシステムのリソースを流用して別仕様のシステム構築を行うこと等が困難であった。

【0012】

上述のような問題に鑑みて、ネットワークの利用状況や動作状態に関する分析処理において、容易に構成を変更することができるネットワーク分析システムが望まれている。

【課題を解決するための手段】

【0013】

第１の本発明は、ネットワークに関する分析を行うネットワーク分析システムにおいて、（１）１又は複数のデータ処理モジュールと、上記データ処理モジュールを収容し、上記データ処理モジュールを用いて、上記ネットワークに関する分析処理を行うネットワーク分析装置とを備え、（２）上記ネットワーク分析装置は、（２−１）上記データ処理モジュールを収容するデータ処理モジュール収容手段と、（２−２）上記ネットワークに関する分析対象データを保持する分析対象データ保持手段と、（２−３）上記分析対象データ保持手段が保持した分析対象データの処理を、一部又は全部の上記データ処理モジュールを用いて行う工程を定義したデータ処理定義情報を格納するデータ処理定義情報格納手段と、（２−４）上記データ処理定義情報格納手段に格納されたデータ処理定義情報に基づいて上記分析対象データ保持手段が生成した所定のデータ処理モジュールに対してデータ処理を実行させるための所定の形式のデータ処理フレームを用いて、上記データ処理を、上記データ処理モジュールに実行させて、そのデータ処理結果を得るデータ処理実行手段とを有し、（３）それぞれの上記データ処理モジュールは、（３−１）上記ネットワーク分析装置と接続する接続手段と、（３−２）上記ネットワーク分析装置からの要求に応じたデータ処理を上記データ処理フレームに基づいて行うデータ処理手段とを有し、（４）上記ネットワーク分析装置が上記データ処理モジュールを複数収納しており、（５）上記分析対象データ保持手段は上記複数のデータ処理モジュールを利用したデータ処理を定義した一つのデータ処理フレームを生成し、（６）上記データ処理実行手段が上記一つのデータ処理フレームに基づいて、上記複数のデータ処理モジュールを用いたデータ処理を実行させ、（７）上記分析対象データ保持手段が生成する上記データ処理フレームには、データ処理に利用する上記複数のデータ処理モジュール、上記複数のデータ処理モジュールにデータ処理させる場合の処理順序及び、各データ処理モジュールにデータ処理をさせる際に指定するパラメータが記述されており、（８）それぞれの上記データ処理モジュールは、上記データ処理フレームに基づいて所定のデータ処理を行う場合、対象の上記データ処理モジュールの上記データ処理手段が当該データ処理を実行後、当該データ処理フレームのデータを当該データ処理後のデータに置換したうえで、当該データ処理フレームに記述された処理順序中の当該データ処理モジュールの要素を削除することを特徴とする。

【0017】

第２の本発明は、（１）複数のデータ処理エンジンと、ネットワークに接続され、上記データ処理エンジンを収容し、上記データ処理エンジンを用いて、上記ネットワークに関する分析処理を行うネットワーク分析装置とを備えるネットワーク分析システムにおいて、（２）上記ネットワーク分析装置は、（２−１）上記ネットワークに関する分析対象データと、上記分析対象データの処理を一部又は全部の上記データ処理エンジンを用いて行う工程を定義したデータ処理定義情報に基づいて、所定のデータ処理エンジンに対してデータ処理を実行させるための所定の形式のデータ処理フレームを生成するエンジン連携処理部と、（２−２）上記データ処理フレームに基づいて、上記データ処理を上記データ処理エンジンに実行させて、そのデータ処理結果を得るエンジン共通駆動部とを有し、（３）それぞれの上記データ処理エンジンは、（３−１）上記ネットワーク分析装置と接続するインタフェース部と、（３−２）上記ネットワーク分析装置からの要求に応じたデータ処理を上記データ処理フレームに基づいて行うデータ処理部とを有し、（４）上記エンジン連携処理部は上記複数のデータ処理エンジンを利用したデータ処理を定義した一つのデータ処理フレームを生成し、（５）上記エンジン共通駆動部が上記一つのデータ処理フレームに基づいて、上記複数のデータ処理エンジンを用いたデータ処理を実行させ、（６）上記エンジン連携処理部が生成する上記データ処理フレームには、データ処理に利用する上記複数のデータ処理エンジン、上記複数のデータ処理エンジンにデータ処理させる場合の処理順序及び、各データ処理エンジンにデータ処理をさせる際に指定するパラメータが記述されており、（７）それぞれの上記データ処理エンジンは、上記データ処理フレームに基づいて所定のデータ処理を行う場合、対象の上記データ処理エンジンの上記データ処理部が当該データ処理を実行後、当該データ処理フレームのデータを当該データ処理後のデータに置換したうえで、当該データ処理フレームに記述された処理順序中の当該データ処理エンジンの要素を削除することを特徴とする。

【発明の効果】

【0018】

本発明によれば、ネットワークの利用状況や動作状態に関する分析処理において、容易に構成を変更することができるネットワーク分析システムを提供することができる。

【図面の簡単な説明】

【0019】

【図1】実施形態に係るネットワーク分析システムの全体構成について示した説明図である。

【図2】実施形態に係る処理ルール格納部に格納される処理ルールの具体的な定義内容の例について示した説明図である。

【図3】実施形態に係る処理ルール管理テーブル内容例について示した説明図である。

【図4】実施形態に係るエンジン管理テーブルの内容例について示した説明図である。

【図5】実施形態に係るエンジンの機能的構成について示した説明図である。

【図6】実施形態に係るネットワーク分析システムで、新規にエンジンがインストールされる場合の動作について示したシーケンス図である。

【図7】実施形態に係るネットワーク分析システムで、新規にエンジンがインストールされる場合の各テーブルの遷移について示した説明図である。

【図8】実施形態に係るネットワーク分析システムで、エンジンがアンインストールされる場合の動作（アンインストールが可の場合）について示したシーケンス図である。

【図9】実施形態に係るネットワーク分析システムで、エンジンがアンインストールされる場合の動作（アンインストールが不可の場合）について示したシーケンス図である。

【図10】実施形態に係るネットワーク分析システムで、第１の処理ルールについてデータ処理を実行する場合の動作について示したシーケンス図である。

【図11】実施形態に係るネットワーク分析システムで、第１の処理ルールについてデータ処理を実行する場合に生成される各データ処理フレームの内容について示した説明図である。

【図12】実施形態に係るネットワーク分析システムで、第２の処理ルールについてデータ処理を実行する場合の動作について示したシーケンス図である。

【図13】実施形態に係るネットワーク分析システムで、第２の処理ルールについてデータ処理を実行する場合に生成される各データ処理フレームの内容について示した説明図である。

【発明を実施するための形態】

【0020】

（Ａ）主たる実施形態
以下、本発明によるネットワーク分析システムの一実施形態を、図面を参照しながら詳述する。なお、この実施形態のデータ処理モジュールはエンジンである。

【0021】

（Ａ−１）実施形態の構成
図１は、この実施形態のネットワーク分析システム１０の機能的構成を示すブロック図である。

【0022】

この実施形態のネットワーク分析システム１０は、内部ネットワークＮ１と外部ネットワークＮ２との間に配置されたルータ４００に流れるトラフィックに基づいて、ネットワークに関する分析（例えば、利用状況や動作状況等の分析）を行い、その分析結果を出力する。なお、ネットワーク分析システム１０が分析の対象とするトラフィックは限定されないものである。そして、ネットワーク分析システム１０は、分析結果について、必要に応じてオペレーティングサーバ（ＯＰＳ）３０へ出力する。内部ネットワークＮ１は、例えば、通信キャリア（例えば、ＩＳＰ事業者等）のネットワークが該当し、外部ネットワークＮ２はインターネット等のグローバルなネットワークが該当する。そして、ネットワーク分析システム１０が、分析に必要なトラフィックのデータを取得する対象となるルータ４００は、内部ネットワークＮ１を外部ネットワークＮ２に接続させるためのネットワーク装置であるものとする。そして、ＯＰＳ３００としては、例えば、内部ネットワークＮ１について運用・監視等を行うオペレータが使用する端末が該当する。

【0023】

次に、ルータ４００の構成について説明する。

【0024】

ルータ４００は、インタフェース４１０、インタフェース４２０、パケット処理部４３０、及びエクスポート処理部４４０を有している。

【0025】

インタフェース４２０は、内部ネットワークＮ１と接続するためのインタフェースであるものとする。また、インタフェース４１０は、外部ネットワークＮ２に接続するためのインタフェースであるものとする。内部ネットワークＮ１及び外部ネットワークＮ２のインタフェースの種類は限定されないものであるが、例えば、１０ギガビット・イーサネット（登録商標）や、ギガビット・イーサネット等のインタフェースを適用することができる。

【0026】

そして、パケット処理部４３０は、インタフェース４１０、４２０で送受信するパケットの処理（ルーティング処理等）を行うものである。なお、パケット処理部４３０は、既存のルータと同様の構成を提供することができる。なお、ネットワーク分析システム１０では、インタフェース４１０で送受信及び観測されるトラフィック（ＩＰパケット）に関する分析が行われるものとして説明する。

【0027】

エクスポート処理部４４０は、ネットワーク分析システム１０からの制御に応じて、分析に必要なデータを収集し、必要に応じて加工してから転送するエクスポータ（エージェント）の機能を担っている。エクスポート処理部４４０では、ネットワーク分析システム１０に出力するデータに関するルール（以下、「出力ルール」と呼ぶ）を定義した情報を格納する出力ルール格納部４４１を備えている。エクスポート処理部４４０は、ネットワーク分析システム１０からの制御に応じて、出力ルール格納部４４１の定義内容を変更する。そして、エクスポート処理部４４０は、出力ルール格納部４４１に格納された情報に従って、データ収集を行って、必要に応じて加工してネットワーク分析システム１０に供給する。以下では、ネットワーク分析システム１０で、ルータ４００（エクスポート処理部４４０）から供給されるデータを、「レポートデータ」と呼ぶものとする。また、ルータ４００（エクスポート処理部４４０）から送出されるレポートデータが挿入されたパケットをレポートパケットと呼ぶものとする。

【0028】

エクスポート処理部４４０の具体的な処理構成としては、例えば、ＮｅｔＦｌｏｗ（参考文献１（ＩＥＴＦ ＲＦＣ３９５４）参照）、ＩＰＦＩＸ（参考文献２（ＩＥＴＦ ＲＦＣ５１０１）参照）、ｓＦｌｏｗ（参考文献３（ＩＥＴＦ ＲＦＣ３１７６）参照）等の従来技術における、エクスポータ（エージェント）の処理構成を適用することができるので詳しい説明を省略する。

【0029】

次に、ネットワーク分析システム１０の構成について説明する。

【0030】

ネットワーク分析システム１０は、システムのプラットフォームとして機能するネットワーク分析装置１００と、ネットワーク分析装置１００(プラットフォーム)上で動作し、データ処理を行うエンジン２００（２００−１〜２００−６）とを有している。なお、エンジン２００の数は限定されないものである。

【0031】

ネットワーク分析装置１００は、ルータ４００から供給されたトラフィックに関するデータ（レポートデータ）を、一部又は全部のエンジン２００を用いて処理し、主として、ネットワーク（内部ネットワークＮ１及び外部ネットワークＮ２）に関する利用状況や動作状態に関する分析処理を行う。すなわち、ネットワーク分析システム１０において、各エンジン２００は、レポートデータ等のデータ処理を行うためのデータ処理モジュールとして機能するものである。そして、ネットワーク分析装置１００は、一部又は全部のエンジン２００を組み合わせて利用し、ネットワークに関する利用状況や動作状態に関する分析を行う。

【0032】

ネットワーク分析装置１００は、エンジン連携処理部１１０、エンジン共通駆動部１２０、処理ルール格納部１３０、出力ルール設定部１４０及びログ蓄積部１５０を有している。

【0033】

ネットワーク分析装置１００は、例えば、ＣＰＵ、ＲＯＭ、ＲＡＭ、ＥＥＰＲＯＭ、ハードディスクなどのプログラムの実行構成、及び、ネットワークに接続するためのインタフェースを有する装置に、実施形態のネットワーク分析プログラム等をインストールすることにより構築するようにしても良く、その場合でも、機能的構成は図１のように示すことができる。また、ネットワーク分析装置１００について、一部又は全部をハードウェア（例えば、専用チップ等）により構築するようにしても良い。

【0034】

エンジン連携処理部１１０は、ルータ４００から送出されたレポートパケットを受信してレポートデータを抽出する。なお、エンジン連携処理部１１０がレポートパケットを受信してレポートデータを抽出する処理構成としては、例えば、上述の参考文献１〜参考文献３等の従来技術におけるエクスポータ（エージェント）に対応するコレクタ（マネージャ）と同様の構成を適用することができる。

【0035】

そして、エンジン連携処理部１１０は、抽出したレポートデータについて、処理ルール格納部１３０に格納された処理ルールに従って、そのレポートデータの処理を、エンジン２００に実行させる。エンジン連携処理部１１０は、エンジン２００に対する制御や処理を依頼する等、エンジン２００に対する入出力を行う場合には、エンジン共通駆動部１２０を介した通信を行う。

【0036】

エンジン共通駆動部１２０は、各エンジン２００、エンジン連携処理部１１０及びログ蓄積部１５０と接続し、各構成要素の間の通信処理（スイッチ処理）等を行う機能を担っている。すなわち、エンジン共通駆動部１２０は、ネットワーク分析装置１００において、各エンジン２００を収容する機能を担っている。

【0037】

また、ここでは、エンジン２００−１〜２００−６に対してそれぞれ１〜６という識別子（以下、「エンジンＩＤ」と呼ぶ）が付与されているものとして以下の説明を行う。例えば、エンジン２００−１の識別子は１となり、エンジン２００−２の識別子は２となる。

【0038】

処理ルール格納部１３０には、エンジン連携処理部１１０がエンジン２００を用いたデータ処理を行う場合の処理工程等に関するルール（以下、「処理ルール」と呼ぶ）を定義したデータが格納されている。処理ルールの詳細については後述する。

【0039】

そして、処理ルール格納部１３０に格納された各処理ルールについては、エンジン連携処理部１１０の処理ルール管理テーブル１１１で管理されている。処理ルール管理テーブル１１１には、各処理ルールに関する情報（例えば、入力するレポートデータの形式や、処理に用いるエンジン２００等）が管理されている。処理ルール管理テーブル１１１の詳細については後述する。

【0040】

出力ルール設定部１４０は、処理ルール管理テーブル１１１で管理されている情報に従って、各処理ルールで必要とするレポートデータが取得できるように、ルータ４００（エクスポート処理部４４０）へ、レポートデータの送信内容・条件設定を依頼する。出力ルール設定部１４０が、ルータ４００（エクスポート処理部４４０）へ、レポートデータの送信内容・条件設定を依頼する構成については、例えば、上述の参考文献１〜参考文献３に記載されたエクスポータ（エージェント）に対応するコレクタ（マネージャ）と同様の構成を適用することができる。

【0041】

そして、ルータ４００（エクスポート処理部４４０）から送出されたレポートデータは、上述の通り、エンジン連携処理部１１０で取得されることになる。すなわち、ネットワーク分析装置１００では、出力ルール設定部１４０及びエンジン連携処理部１１０により、ルータ４００（エクスポート処理部４４０）から、レポートデータ（ネットワーク分析装置１００で分析対象となるデータ）を保持する処理が行われる。

【0042】

ログ蓄積部１５０は、エンジン共通駆動部１２０に接続しており、各エンジン２００の処理に関するログを蓄積するものである。ログ蓄積部１５０には、エンジン２００ごとの、入力データ及び又は出力データや、データ処理の中間データ等が格納される。エンジン共通駆動部１２０は、例えば、各エンジン２００で入出力されるデータや、各エンジン２００からの依頼に基づくデータを、ログ蓄積部１５０に供給し、ログ蓄積部１５０では供給されたデータを、エンジン２００ごとに分類して蓄積するものとする。

【0043】

次に、処理ルール格納部１３０に格納される処理ルールの具体的な内容について説明する。ここでは、処理ルール格納部１３０には、２つの処理ルールＲ１、Ｒ２が格納されているものとする。

【0044】

図２は、処理ルール格納部１３０に格納される処理ルールの定義内容の例について示した説明図である。

【0045】

図２（ａ）は、処理ルールＲ１の内容について示しており、図２（ｂ）は、処理ルールＲ２の内容について示している。

【0046】

処理ルールを定義する記述形式については限定されないものであるが、ここでは、図２に示すような、Ｃ言語タイプのスクリプト形式で記述されるものとする。

【0047】

処理ルールは、おおまかに、入力データとして用いるレポートデータに関する定義を行うステップ（以下、「入力データ定義ステップ」とよぶ）（図２（ａ）のステップＳ１０１、図２（ｂ）のステップＳ２０１）と、エンジン２００を用いたデータ処理を定義するステップ（以下、「データ処理定義ステップ」と呼ぶ）（図２（ａ）のステップＳ１０２、図２（ｂ）のステップＳ２０２）と、当該処理ルールで出力するデータに関する定義を行うステップ（以下、「出力データ定義ステップ」と呼ぶ）（図２（ａ）のステップＳ１０３、図２（ｂ）のステップＳ２０３）の３つのステップを有している。

【0048】

まず、入力データ定義ステップ（ステップＳ１０１、ステップＳ２０１）について説明する。この実施形態では、処理ルールで用いられる入力データ（レポートデータ）の形式は、インタフェースで観測されるトラフィックをダンプしたpcap形式のようなトラフィックデータ（所定のインターバルの間に発生したＩＰパケット列のバイナリーデータ）、又はインタフェースで観測されたトラフィックを設定されたサンプリング間隔で抽出してnetflow/sflo/ipfixなどのようなフロー情報として出力するフローレコード（所定のインターバルの間に発生したＩＰパケット列に係る所定項目の統計情報）のいずれか，あるいは双方であるものとする。入力データ（レポートデータ）の形式については、さらに細かく分類して定義するようにしても良いが、この実施形態では説明を簡易にするための上述の２種類のみであるものとして説明する。

【0049】

そして、処理ルールＲ１の入力データ定義ステップ（ステップＳ１０１）では、「input1＝trafficdata;」と記述されており、「input1」（処理ルールＲ１の第１の入力データの形式）は、「trafficdata」（トラフィックデータ）の形式であることを示している。

【0050】

一方、処理ルールＲ２の入力データ定義ステップ（ステップＳ１０２）では、「input1＝flow_record;」と記述されており、「input1」（処理ルールＲ２の第１の入力データの形式）は、「flow_record」（フローレコード）の形式であることを示している。なお、入力データ定義ステップでは、例えば「input2＝…」というような記述で、複数の入力データに関する定義を行うようにしても良い。

【0051】

次に、処理ルールを構成するデータ処理定義ステップ（ステップＳ１０２、ステップＳ２０２）について説明する。図２に示すように、処理ルールＲ１のデータ処理定義ステップ（ステップＳ１０２）は、３つのサブステップＳ１０２−１〜Ｓ１０２−３を有している。また、処理ルールＲ２のデータ処理定義ステップ（ステップＳ２０２）は、３つのサブステップＳ２０２−１〜Ｓ２０２−３を有している。

【0052】

データ処理定義ステップでは、「EngineN」（Nは、当該エンジン２００の識別子（１〜６のいずれか））を名称（クラス名）とした関数（クラス）を用いて、各エンジン２００に実行させる処理を定義するものとする。データ処理定義ステップで、任意のエンジン２００（識別子がEngineNのエンジン２００）に、任意の入力データ（inputdata）について、任意のパラメータ（parameter）（例えば、データ処理を行う際の閾値等）を指定して処理を実行させ、任意の出力形式（output_type）でデータを出力させる場合には、「EngineN(inputdata,output_type,parameter)」という記述で表すことができるものとする。データ処理定義ステップの記述形式は限定されないものであり、複数の記述形式に対応するようにしても良いが、ここでは説明を簡易にするために、ネットワーク分析装置１００では、上述の形式について対応するものとして説明する。なお、データ処理定義ステップにおいて、inputdata以外のパラメータ（output_type及びparameter）については、明示的に指定する必要が無い場合には、記述を省略するようにしても良い。なお、以下では、inputdata以外のパラメータについて「付加パラメータ」と呼ぶものとする。また、図２では、「output_type」及び「parameter」について、説明を簡易にするために「output_type1」や「parameter1」といった記述をしているが、実際にはエンジン連携処理部１１０でそれらのパラメータに対して、具体的な内容を定義（ｄｅｆｉｎｅ）したデータ（図示せず）が保持されているものとする。

【0053】

例えば、処理ルールＲ１のデータ処理定義ステップ（ステップＳ１０２）を構成するステップＳ１０２−１では、「Engine1(input1,output_type1,parameter1)」と記述されているが、これは、「Engine1」（エンジン２００−１）に対して、「input1」（ステップＳ１０１で定義された入力データ）について、「parameter1」というパラメータを指定して処理を実行させ、「output_type1」の出力形式の出力データを得ることを意味している。

【0054】

次に、処理ルールＲ１のデータ処理定義ステップ（ステップＳ１０２）の内容について説明する。

【0055】

ステップＳ１０２−１の内容については、上述の通りである。

【0056】

そして、ステップＳ１０２−１に続くステップＳ１０２−２では、「Analyze2 = Engine2(analyze1, output_type2, parameter2);」と記述されているので、「Engine2」（エンジン２００−２）に対して、ステップＳ１０２−１で得た「Analyze1」を入力としたデータ処理を実行させ、その結果を「Analyze2」という変数に代入させる処理を意味している。

【0057】

さらに、ステップＳ１０２−２に続くステップＳ１０２−３では、「Analyze3 = Engine3(analyze2, output_type3, parameter3);」と記述されているので、「Engine3」（エンジン２００−３）に対して、ステップＳ１０２−１で得た「Analyze2」を入力としたデータ処理を実行させ、その結果を「Analyze3」という変数に代入させる処理を意味している。

【0058】

すなわち、処理ルールＲ１のデータ処理定義ステップ（ステップＳ１０２）では、入力データ（input1）について、まず、エンジン２００−１（Engine1）に処理させ、さらにその処理結果をエンジン２００−２（Engine2）に処理させ、さらにその処理結果をエンジン２００−３（Engine3）に処理させるという入れ子の構造（構文）で記述されている。言い換えると、処理ルールＲ１のデータ処理定義ステップ（ステップＳ１０２）では、エンジン２００−１（Engine1）、エンジン２００−２（Engine2）、エンジン２００−３（Engine3）の順で直列的に、入力データ（input1）を処理させる構造（構文）となっている。

【0059】

次に、処理ルールＲ１のデータ処理定義ステップ（ステップＳ１０２）の具体的な処理（エンジン２００−１〜２００−３の具体的な処理）の例について説明する。

【0060】

処理ルールＲ１では、ルータ４００を流れる音声や動画等のリアルタイム通信に関するトラフィックを分析するものとする。具体的には、処理ルールＲ１は、ＲＴＰ／ＲＴＣＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ／ＲＴＰ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）通信のパケット（特にＲＴＣＰのパケット）を抽出した分析を行うものとする。

【0061】

まず、ステップＳ１０２−１で、エンジン２００−１（Engine1）に入力データ（input1）として、トラフィックデータ（全てのＩＰパケットのデータ）を入力し、ＲＴＣＰパケットだけを抽出させたデータ（Analyze1）を得る。そして、エンジン２００−１（Engine1）で得た、ＲＴＣＰパケットのデータ（Analyze1）を、エンジン２００−２（Engine2）に入力して、ＲＴＣＰパケットに含まれる品質値（遅延，パケットロス等）をもとに通信品質が有意に劣化していると考えられるフローのＩＰアドレスの組合せ（ＲＴＣＰパケットの送信元及び送信先のＩＰアドレスの組合せ）から，所定の回数（Parameter2で指定）以上出現しているIPアドレスの組み合わせを抽出し、それらのＩＰアドレスの組合せのデータ及び、当該組合せに係るＲＴＣＰパケットに含まれる通信品質に関するパラメータ値のデータ（複数存在する場合には平均値を用いるようにしても良い）を含むデータ（Analyze2）を得る。そして、エンジン２００−２（Engine2）で得た、ＩＰアドレスの組合せ及び、当該組合せに係るパラメータ値のデータ（Analyze2）を、エンジン２００−３（Engine3）に入力して、一定時間内に発生した品質劣化の回数が閾値を越えた場合にネットワーク異常と判定し、その判定結果とIPアドレスの組み合わせをAnalyze3として得る。エンジン２００−３（Engine3）から出力される判定結果（Analyze3）は、一定時間内にネットワーク品質劣化が発生したと判断されたIPアドレスの対を返すか，品質劣化が無い場合は０を返す。この実施形態において、処理ルールＲ１では、以上のような流れで、入力データ（input1：trafficdata）について、エンジン２００−１〜２００−３に直列的にデータ処理を実行させ、ネットワーク異常の有無を判定することができる。

【0062】

次に、処理ルールＲ２のデータ処理定義ステップ（ステップＳ２０２）の内容について説明する。

【0063】

処理ルールＲ１では、上述の通り、入力データ（input1）を複数のエンジンで直列的に処理させているが、処理ルールＲ２では並列的に処理を行う。

【0064】

具体的には、処理ルールＲ２のステップＳ２０２−１では、入力データ（input1）についてエンジン２００−４（Engine4）で処理を行わせて、その結果を、「Analyze1」という変数に代入させている。また、処理ルールＲ２のステップＳ２０２−２では、入力データ（input1）についてエンジン２００−５（Engine5）で処理を行わせて、その結果を、「Analyze2」という変数に代入させている。さらに、処理ルールＲ２のステップＳ２０２−３では、入力データ（input1）についてエンジン２００−６（Engine6）で処理を行わせて、その結果を、「Analyze3」という変数に代入させている。

【0065】

次に、処理ルールＲ２のデータ処理定義ステップ（ステップＳ２０２）の具体的な処理（エンジン２００−４〜２００−６の具体的な処理）の例について説明する。

【0066】

エンジン２００−４〜２００−６は、フローレコードの形式の入力データを蓄積し、過去に蓄積したデータと、最新に取得したフローレコード形式のデータとに基づいて、それぞれ異なるアルゴリズムで、現在のネットワーク異常の有無を判定する処理を行い、その判定結果をAnalyze1〜Analyze3として得る。ここでは、例として、エンジン２００−４は、特許文献１の記載技術のように傾向変化度を利用して、一定割合以上（parameter1で指定）のエラー要因となっているＩＰアドレス若しくは経路を得た場合に、ネットワーク異常が発生したと判定するものとする。また、エンジン２００−５は、特許文献３の記載技術のように、ＲＦ法を用いた判定により、現在のネットワークの異常（ネットワークの品質劣化）の有無を判定するものとする。さらに、エンジン２００−６は、特許文献４の記載技術のように、ニューラルネットワーク（ニューロ）を用いた学習機を利用して、現在のネットワークの異常（ネットワークの品質劣化）の有無を判定するものとする。

【0067】

エンジン２００−４〜２００−６（Engine4〜Engine6）から出力される判定結果（Analyze1〜Analyze3）は、ネットワーク異常と判定した場合には「１」、ネットワーク異常はないと判定した場合は「０」の値を取るものとする。この実施形態において、処理ルールＲ２では、以上のような流れで、入力データ（input1：flow_record）について、エンジン２００−４〜２００−６に並列的にデータ処理を実行させ、それぞれ異なるアルゴリズムで、ネットワーク障害に関する判定結果を取得することができる。

【0068】

次に、処理ルールを構成する出力データ定義ステップ（ステップＳ１０３、ステップＳ２０３）について説明する。

【0069】

処理ルールＲ１の出力データ定義ステップ（ステップＳ１０３）では、図２（ａ）に示すように、単に「Return analyze3;」と記述されており、処理ルールＲ１の処理結果として「analyze3」という変数を戻り値のデータとして出力することを示している。エンジン連携処理部１１０では、各処理ルールについて、「Return」という関数により、戻り値として出力されたデータを取得し、当該処理ルールによる分析結果として、出力する処理を行う。

【0070】

この実施形態の処理ルールを構成する出力データ定義ステップでは、分析処理の結果、ネットワークの利用状況や動作状態に関して異常を検知した場合には戻り値として「１」を出力し、異常が無い場合（正常の場合）には戻り値として「０」を出力するものとする。

【0071】

一方、処理ルールＲ２の出力データ定義ステップ（ステップＳ１０３）では、図２（ａ）に示すように、「If((analyze1+analyze2+analyze3)>2)return 1;Else return 0;」と記述されており、Ｉｆ文を用いた構文となっている。ここでは、「analyze1」、「analyze2」、「analyze3」のそれぞれは、上述の通り、０又は１が代入される。そうすると、上述のＩｆ文を用いた構文では、「analyze1」、「analyze2」、「analyze3」のうち２つ以上で１が代入された場合に、Ｉｆの条件が成立し処理ルールＲ２の戻り値として１が出力されることになる。一方、If文の条件が成立しなかった場合（「１」を出力したエンジン２００が２つ未満だった場合）には、処理ルールＲ２の戻り値として０が出力されることになる。

【0072】

上述の通り、エンジン２００−４〜２００−６では、それぞれ異なるアルゴリズムで、ネットワークに関する障害の有無を判定している。したがって、処理ルールＲ２の出力データ定義ステップ（ステップＳ２０３）では、エンジン２００−４〜２００−６のうち２つ以上でネットワーク異常が検知された場合（多数決でネットワーク異常を検知したエンジン２００が多かった場合）にのみ、最終的な判定結果をネットワーク異常有りと判定していると言える。以上のように、処理ルールＲ２では、複数のエンジン２００の判定結果を総合して、最終的なネットワーク異常の判定を行っている。

【0073】

以上の通り、エンジン連携処理部１１０では、各処理ルールのスクリプトが実行される。そして、エンジン連携処理部１１０は、各処理ルールのスクリプトを実行した結果、異常検出を意味する「１」が戻り値として取得された場合、当該処理ルールにより異常を検知したことをＯＰＳ３００に対して通知する処理（例えば、ＳＮＭＰのＴｒａｐ等を用いた通知処理）を行う。エンジン連携処理部１１０が、ネットワーク異常の発生を通知する際には、処理ルールごとに対応するメッセージ（例えば、異常の原因を示すメッセージ）を合わせて通知するようにしても良い。エンジン連携処理部１１０が、ＯＰＳ３００に対して通知するメッセージについては、例えば、処理ルール管理テーブル１１１管理で、項目を追加して管理するようにしても良いし、出力データ定義ステップの中で記述するようにしても良い。

【0074】

なお、エンジン連携処理部１１０が分析結果を出力する方式は限定されないものであり、例えば、内部にログ（履歴）として蓄積するようにしても良いし、ＯＰＳ３００ではなく自装置でディスプレイ等に表示出力するようにしても良い。

【0075】

そして、ＯＰＳ３００では、エンジン連携処理部１１０から異常通知があった場合（例えば、ＳＮＭＰによりＴｒａｐ通知等があった場合）には、その旨の警報を発して、オペレータにネットワークで異常が発生したことを知らせる。ＯＰＳ３００により警報を発生させる方式は限定されないものであるが、例えば、図示しないディスプレイに表示出力したり、図示しないスピーカによりアラーム音を音声出力したり、図示しないランプを発光させる等の種々の方式を適用することができる。ＯＰＳ３００の具体的な構成については限定されないものであるが、例えば既存のＳＮＭＰに対応したネットワーク監視装置（ＳＮＭＰマネージャ）等を適用することができる。

【0076】

次に、エンジン連携処理部１１０で保持される処理ルール管理テーブル１１１の内容例について説明する。

【0077】

図３は、処理ルール管理テーブル１１１の内容例について示した説明図である。図３では、上述の図２の処理ルールＲ１、Ｒ２が、処理ルール格納部１３０に格納された場合の処理ルール管理テーブル１１１の内容について示している。

【0078】

図３に示すように、処理ルール管理テーブル１１１には、ルールＩＤ、使用エンジン、インターバル、入力データ形式の項目の情報が登録されている。図３では、１行で、一つの処理ルールに関する情報が管理されている。

【0079】

「ルールＩＤ」の項目は、各処理ルールの識別子を示す項目である。ここでは、処理ルールＲ１のルールＩＤを「１」、処理ルールＲ２のルールＩＤを「２」であるものとして説明する。

【0080】

「使用エンジン」の項目は、当該処理ルールの「データ処理定義ステップ」で使用されるエンジン２００について管理するための項目である。使用エンジンの項目では、図３に示すように各エンジンのエンジンＩＤごとに「１」又は「０」の値が設定される。使用エンジンの項目において、エンジンＩＤに対する値が０の場合は、当該処理ルールではそのエンジンＩＤのエンジン２００は使用されないことを意味している。一方、使用エンジンの項目において、エンジンＩＤに対する値が１の場合は、当該処理ルールではそのエンジンＩＤのエンジン２００は使用されることを意味している。例えば、処理ルールＲ１（ルールＩＤ：１）では、エンジンＩＤが１〜３のエンジン２００−１〜２００−３が使用されることを示している。

【0081】

「インターバル」の項目は、当該処理ルールのスクリプトを実行するインターバル（間隔）について示している。インターバルは、時間を単位として示しても良いし、パケットの発生数（ルータ４００から供給されるレポートデータに含まれるパケットの数）で示しても良い。また、「入力データ形式」の項目は、当該処理ルールの入力データ定義ステップで定義される入力データの形式を示している。

【0082】

図３では、処理ルールＲ１（ルールＩＤ：１）のインターバルは「１００００パケット」、入力データ形式は「trafficdata」となっている。したがって、エンジン連携処理部１１０は、前回処理ルールＲ１を実行してから、パケットの発生数（ルータ４００から供給されるレポートデータに含まれるパケットの数）が１００００個に達した時点で、その１００００個分のパケットのデータを含むトラフィックデータ形式のレポートデータを入力として、処理ルールＲ１の実行を開始することを示している。

【0083】

また、図３では、処理ルールＲ２（ルールＩＤ：２）のインターバルは「１０秒」、入力データ形式は「flow_record」となっている。したがって、エンジン連携処理部１１０は、前回処理ルールＲ２を実行してから、１０秒経過すると、その間に供給されたフローレコードの形式のレポートデータを入力として、処理ルールＲ２の実行を開始することを示している。

【0084】

処理ルール管理テーブル１１１の内容は、ユーザの操作に応じた内容を登録するようにしても良いし、エンジン連携処理部１１０が、処理ルール格納部１３０に追加された処理ルールの内容に応じて更新するようにしても良い。

【0085】

エンジン連携処理部１１０が、各処理ルールについて、処理ルール管理テーブル１１１の各項目の情報を把握する手段については限定されないものである。例えば、処理ルール格納部１３０で処理ルールのデータと共に、処理ルール管理テーブル１１１の各項目の情報についても格納しておき、エンジン連携処理部１１０に読み込ませるようにしても良い。また、エンジン連携処理部１１０が、処理ルール格納部１３０に格納された処理ルールのスクリプトの内容を参照して、処理ルール管理テーブル１１１に反映させるようにしても良い。例えば、処理ルール格納部１３０に新たな処理ルールが追加された場合に、エンジン連携処理部１１０が、その処理ルールを構成する入力データ定義ステップの内容を読み取って、当該処理ルールの入力データの形式を確認（trafficdata又はflow_record）を把握して、入力データ形式の項目に反映するようにしても良い。また、例えば、処理ルール格納部１３０に新たな処理ルールが追加された場合に、エンジン連携処理部１１０が、その処理ルールを構成するデータ処理定義ステップの内容を読み取って、当該処理ルールで使用するエンジン２００（エンジンＩＤ）を把握して、使用エンジンの項目に反映するようにしても良い。

【0086】

次に、エンジン連携処理部１１０で保持されるエンジン管理テーブル１１２の内容例について説明する。

【0087】

図４は、エンジン管理テーブル１１２の内容例について示した説明図である。図４では、エンジン２００−１〜２００−６（エンジンＩＤ：１〜６）が、エンジン共通駆動部１２０に接続されている場合のエンジン管理テーブル１１２の内容について示している。

【0088】

図４に示すように、エンジン管理テーブル１１２には、エンジンＩＤ、ＩＦ番号、エンジン名、処理概要の項目の情報が登録されている。図４では、１行で、一つの処理ルールに関する情報が管理されている。

【0089】

エンジンＩＤの項目は、当該エンジン２００に付与されているエンジンＩＤ（処理ルールの定義等で用いられるＩＤ）を示している。

【0090】

ＩＦ番号の項目は、当該エンジン２００が、エンジン共通駆動部１２０上でインストールされているインタフェースの番号（論理的又は物理的なインタフェースの識別子）を示している。図４では、それぞれのエンジン２００について、エンジンＩＤとＩＦ番号は別項目として記述しているが、内容が一致する場合には一つの項目にまとめて記述するようにしても良い。

【0091】

エンジン名の項目は当該エンジン２００の名称について示している。また、処理概要の項目は、当該エンジン２００の処理の概要について示している。なお、エンジン名及び処理概要の項目については、エンジン管理テーブル１１２において必須の項目ではなく省略するようにしても良い。

【0092】

エンジン連携処理部１１０は、新たにエンジン２００がインストール（エンジン共通駆動部１２０に接続）された場合や、既にインストールされているエンジン２００がアンインストール（エンジン共通駆動部１２０から切断）された場合に、エンジン管理テーブル１１２の内容を更新するが、その処理については、後述する動作説明の項で説明する。

【0093】

次に、エンジン２００（２００−１〜２００−６）の内部構成について説明する。

【0094】

ここでは、各エンジン２００の基本的な構成（フレームワーク）については、全て同じであり、実行するデータ処理の内容が異なっているだけであるものとして説明する。

【0095】

図５は、各エンジン２００の機能的構成について示したブロック図である。

【0096】

各エンジン２００は、ネットワーク分析装置１００とは別個のハードウェア（コンピュータ）に、実施形態のデータ処理プログラムをインストールすることにより構築しても良いし、ネットワーク分析装置１００のコンピュータ上で動作する１つのプログラム（実施形態のデータ処理プログラム）として構築するようにしても良い。そして、いずれの場合でもネットワーク分析装置１００の機能的構成は、図５のように示すことができる。

【0097】

エンジン２００は、インタフェース部２１０、データ処理部２２０、及びインストール処理部２３０を有している。

【0098】

インタフェース部２１０は、エンジン共通駆動部１２０と接続するためのインタフェースの機能を担っている。エンジン２００がエンジン共通駆動部１２０とは別個のハードウェア（コンピュータ）を用いて構築されている場合には、インタフェース部２１０は、物理的にネットワーク分析装置１００（エンジン共通駆動部１２０）へ接続するためのインタフェースを備える必要がある。エンジン２００がエンジン共通駆動部１２０とハードウェア的に接続する場合のインタフェースについては限定されないものであるが、例えば、イーサネット等のＬＡＮインタフェースや、ファイバチャネル等の種々のインタフェースを適用することができる。

【0099】

データ処理部２２０は、エンジン連携処理部１１０からの依頼に基づいてデータ処理を行う機能を担っている。データ処理部２２０が行う具体的なデータ処理の内容については、当該エンジン２００の仕様によって異なっている。データ処理部２２０が、データ処理を行う場合のワークメモリや、詳細な動作ログについては、内部で管理するようにしても良いし、一部又は全部について、ログ蓄積部１５０上に確保された領域に記憶するようにしても良い。その場合、各エンジン２００は、エンジン共通駆動部１２０を介してログ蓄積部１５０に蓄積されたデータの読み書きが可能な構成とする必要がある。

【0100】

インストール処理部２３０は、ネットワーク分析装置１００へ接続して当該エンジン２００をインストールさせる処理や、ネットワーク分析装置１００へ接続（インストール）された状態から切断（アンインストール）させる処理を行うものである。インストール処理部２３０のインストール処理、及び、アンインストール処理については、例えば、ユーザの操作に応じて実行するようにしても良い。エンジン２００が、ソフトウェア的にプログラム（実施形態のデータ処理プログラム）により構成されている場合には、そのプログラムを構成するサブプログラムとして、インストール処理部２３０は構成されることになる。そして、ユーザによりインストール処理部２３０に相当するサブプログラムの実行（例えば、所定のコマンド操作等）が行われた場合に、インストール又はアンインストールの処理が開始される。エンジン２００が、ネットワーク分析装置１００とは別個のハードウェアである場合には、ユーザにエンジン２００（インストール処理部２３０）を直接操作（例えば、図示しないボタン等のインタフェースによる操作）させるようにしても良いし、ネットワーク分析装置１００を介してエンジン２００（インストール処理部２３０）を操作させるようにしても良い。

【0101】

インストール処理部２３０が、インストール又はアンインストールの処理を開始すると、エンジン連携処理部１１０と連携してその処理を行う。インストール処理部２３０の処理の具体的なシーケンスについては、後述する動作説明の項で説明する。

【0102】

（Ａ−２）実施形態の動作
次に、以上のような構成を有するこの実施形態のネットワーク分析システム１０の動作を説明する。

【0103】

（Ａ−２−１）エンジンのインストール
まず、ネットワーク分析システム１０に、新規のエンジンがインストールされる場合の動作について、図６のシーケンス図を用いて説明する。

【0104】

ここでは、図６では、ネットワーク分析装置１００上に、エンジン２００−１〜２００−６がインストールされた状態で、新規にエンジン２００−７がインストールされる動作について示している。また、図６のフローチャートの初期状態として、処理ルール管理テーブル１１１及びエンジン管理テーブル１１２の内容は、それぞれ図３、図４の状態であるものとして説明する。

【0105】

まず、ユーザの操作により、エンジン２００−７が、エンジン共通駆動部１２０にアクセス可能な状態に置かれ、エンジン２００−７のインストール処理部２３０が起動されたものとする（Ｓ３０１）。エンジン２００が、ソフトウェア的にプログラム（実施形態のデータ処理プログラム）により構成されている場合には、例えば、エンジン２００−７を構成するプログラムのファイルが、ネットワーク分析装置１００を構成するコンピュータに展開され実行可能な状態になると、エンジン２００−７はエンジン共通駆動部１２０にアクセス可能な状態になる。また、エンジン２００が、ネットワーク分析装置１００とは別個のハードウェア（コンピュータ）により構築されている場合には、例えば、エンジン２００−７のハードウェア（モジュール）を、ネットワーク分析装置１００に接続（例えば、ケーブルやソケット等のインタフェースにより接続）すると、エンジン２００−７はエンジン共通駆動部１２０にアクセス可能な状態になる。

【0106】

エンジン２００−７のインストール処理部２３０が起動されると、インストール処理部２３０から、エンジン共通駆動部１２０を介して、エンジン連携処理部１１０へ、インストール要求が通知される（Ｓ３０２）。

【0107】

そして、インストール要求の通知を受信すると、エンジン連携処理部１１０は、エンジン２００−７へ、管理情報（エンジン管理テーブル１１２に登録する情報）の送信要求を通知する（Ｓ３０３）。

【0108】

そして、管理情報の送信要求を受信すると、エンジン２００−７のインストール処理部２３０は、自身の管理情報をエンジン連携処理部１１０に返答する（Ｓ３０４）。

【0109】

そして、管理情報を受信すると、エンジン連携処理部１１０は、エンジン２００−７に対してエンジンＩＤを付与する。そして、エンジン連携処理部１１０は、受信した管理情報及び付与したエンジンＩＤに基づいて、エンジン２００−７に関する情報を、エンジン管理テーブル１１２に追加する。さらに、エンジン連携処理部１１０は、エンジン２００−７のエンジンＩＤの項目を、処理ルール管理テーブル１１１の使用エンジンの項目に追加する（Ｓ３０５）。

【0110】

図７は、上述のステップＳ３０５の処理で更新された後の処理ルール管理テーブル１１１及びエンジン管理テーブル１１２の状態について示している。

【0111】

エンジン連携処理部１１０は、新たにインストールされるエンジン２００に対して、エンジンＩＤを付与する場合には、エンジン管理テーブル１１２を確認し、空いているエンジンＩＤを付与する。ここでは、エンジン連携処理部１１０は、エンジン２００−７に対して、空いているエンジンＩＤのうち最も小さい番号を付与するものとする。上述の通り、ステップＳ３０５以前のエンジン管理テーブル１１２の状態は、上述の図４に示す状態であるので、エンジン連携処理部１１０は、エンジン２００−７に対して、エンジンＩＤとして「７」が付与されることになる。なお、新規にインストールするエンジン２００に付与するエンジンＩＤについては、ユーザの操作に応じた番号や、エンジン２００に固定的に設定されているＩＤ等を付与するようにしても良い。そして、エンジン連携処理部１１０は、エンジン２００−７のエンジンＩＤを７として、エンジン管理テーブル１１２に、エンジン２００−７の情報を追加登録し、エンジン管理テーブル１１２は図７（ｂ）に示す状態となる。そして、エンジン連携処理部１１０は、処理ルール管理テーブル１１１の使用エンジンの項目に、エンジン２００−７に対応する項目（エンジンＩＤが７の項目）を追加し、処理ルール管理テーブル１１１は図７（ａ）に示す状態となる。処理ルール管理テーブル１１１において、エンジン２００−７に対応する項目（エンジンＩＤが７の項目）が追加された当初は、エンジン２００−７はいずれの処理ルールにも使用されていないので、「０」の値が設定される。

【0112】

そして、エンジン連携処理部１１０は、各テーブル（処理ルール管理テーブル１１１及びエンジン管理テーブル１１２）の更新が完了すると、インストール終了の通知と共に、付与したエンジンＩＤ（７）を、エンジン２００−７に通知する（Ｓ３０６）。

【0113】

以降、エンジン２００−７は、ネットワーク分析装置１００上で、データ処理を行うことが可能となる。

【0114】

（Ａ−２−２）エンジンのアンインストール
次に、ネットワーク分析システム１０に、既にインストール（接続）されているエンジン２００がアンインストールされる場合の動作について説明する。

【0115】

エンジン連携処理部１１０では、エンジン２００（インストール処理部２３０）からアンインストールの要求があった場合には、当該エンジン２００についてアンインストールによる影響度を確認し、その確認結果に基づいて、当該エンジン２００についてアンインストールの可否を判定する。具体的には、エンジン連携処理部１１０は、エンジン２００（インストール処理部２３０）からアンインストールの要求があった場合には、処理ルール管理テーブル１１１を参照し、当該エンジン２００を利用する処理ルールが無い場合には、当該エンジン２００をアンインストールしても影響が無いと判断し、当該エンジン２００のアンインストールを許可する。一方、当該エンジン２００を利用する処理ルールがあった場合には、エンジン連携処理部１１０は、当該エンジン２００のアンインストールを許可しない。

【0116】

ここでは、まず、エンジン連携処理部１１０が、エンジン２００からのアンインストール要求を可と判定する場合の動作について図８を用いて説明する。

【0117】

図８では、上述の図６で新規にエンジン２００−７がインストールされた直後の状態で、エンジン２００−７のアンインストールを行う動作について示している。すなわち、図８のフローチャートでは、処理ルール管理テーブル１１１及びエンジン管理テーブル１１２の初期状態が、上述の図７に示す状態となっているものとする。

【0118】

まず、エンジン２００−７が、ネットワーク分析装置１００上にインストールされた状態で、ユーザの操作により、エンジン２００−７のインストール処理部２３０が起動されたものとする（Ｓ４０１）。

【0119】

エンジン２００−７のインストール処理部２３０が起動されると、インストール処理部２３０から、エンジン共通駆動部１２０を介して、エンジン連携処理部１１０へ、アンインストール要求が通知される（Ｓ４０２）。

【0120】

そして、アンインストール要求の通知を受信すると、エンジン連携処理部１１０は、処理ルール管理テーブル１１１の内容を確認し、エンジン２００−７のアンインストールの可否を判定する（Ｓ４０３）。

【0121】

処理ルール管理テーブル１１１の内容は、上述の通り、上述の図７の状態となっている。そして、図７に示されるように、エンジン２００−７に対応する項目（エンジンＩＤが７の項目）は、全ての処理ルールについて「０」の値（使用されていないことを示す値）が設定されている。したがって、エンジン連携処理部１１０は、エンジン２００−７は、どの処理ルールにも使用されていないため、アンインストールしても影響が無く、エンジン２００−７のアンインストールは可と判定することになる。

【0122】

そして、エンジン連携処理部１１０は、エンジン２００−７のアンインストールを可と判定すると、最終的なアンインストールの確認（ＡＣＫ）要求を通知する（Ｓ４０４）。

【0123】

そして、アンインストールの確認（ＡＣＫ）要求の通知を受信すると、エンジン２００−７のインストール処理部２３０は、アンインストールの確認（ＡＣＫ）を返答する（Ｓ４０５）。

【0124】

そして、アンインストールの確認（ＡＣＫ）の通知を受信すると、エンジン連携処理部１１０は、処理ルール管理テーブル１１１及びエンジン管理テーブル１１２に対して、エンジン２００−７に関する情報の削除を実行する（Ｓ４０６）。

【0125】

エンジン連携処理部１１０は、エンジン管理テーブル１１２から、エンジン２００−７（エンジンＩＤ：７）の情報を削除し、エンジン管理テーブル１１２は上述の図４に示す状態となる。また、エンジン連携処理部１１０は、処理ルール管理テーブル１１１の使用エンジンの項目から、エンジン２００−７に対応する項目（エンジンＩＤが７の項目）を削除し、処理ルール管理テーブル１１１は上述の図３に示す状態となる。

【0126】

そして、エンジン連携処理部１１０は、エンジン２００−７にアンインストール処理が完了した旨の通知を送信する（Ｓ４０７）。以上のシーケンスの動作で、ネットワーク分析システム１０では、エンジン２００−７のアンインストール処理が終了し、エンジン２００−７について、ファイルの消去や取り外しが可能となる。

【0127】

次に、エンジン連携処理部１１０が、エンジン２００からのアンインストール要求を不可と判定する場合の動作について図９を用いて説明する。図９のフローチャートにおいても、処理ルール管理テーブル１１１及びエンジン管理テーブル１１２の初期状態が、上述の図７に示す状態となっているものとして説明する。

【0128】

まず、エンジン２００−６が、ネットワーク分析装置１００上にインストールされた状態で、ユーザの操作により、エンジン２００−６のインストール処理部２３０が起動されたものとする（Ｓ５０１）。

【0129】

エンジン２００−６のインストール処理部２３０が起動されると、インストール処理部２３０から、エンジン共通駆動部１２０を介して、エンジン連携処理部１１０へ、アンインストール要求が通知される（Ｓ５０２）。

【0130】

そして、アンインストール要求の通知を受信すると、エンジン連携処理部１１０は、処理ルール管理テーブル１１１の内容を確認し、エンジン２００−６のアンインストールの可否を判定する（Ｓ５０３）。

【0131】

処理ルール管理テーブル１１１の内容は、上述の通り、上述の図７の状態となっている。そして、図７に示されるように、エンジン２００−６に対応する項目（エンジンＩＤが６の項目）では、処理ルールＲ２の行（ルールＩＤが２の行）で「１」の値（使用されていることを示す値）が設定されている。したがって、エンジン連携処理部１１０は、エンジン２００−６は、使用している処理ルールが存在するため、アンインストールをすると影響が有り、エンジン２００−６のアンインストールは不可と判定することになる。

【0132】

そして、エンジン連携処理部１１０が、エンジン２００−６のアンインストールを不可と判定すると、アンインストールを不許可とする通知がエンジン２００−６に送信され（Ｓ５０４）、アンインストールの処理は中止される。

【0133】

（Ａ−２−３）処理ルールに関するデータ処理
次に、エンジン連携処理部１１０が、処理ルールのスクリプト（データ処理定義ステップ）に基づいて、各エンジン２００にデータ処理を実行させる具体的な動作（シーケンス）について説明する。

【0134】

まず、最初に、エンジン連携処理部１１０が、処理ルールＲ１（上述の図２（ａ）参照）のデータ処理定義ステップに基づいて、エンジン２００−１〜２００−３にデータ処理を実行させる動作について図１０、図１１を用いて説明する。

【0135】

まず、エンジン連携処理部１１０は、処理ルールＲ１（上述の図２（ａ）参照）について構文解析を行い、エンジン２００−１〜２００−３に対して解析した構文に基づくデータ処理を実行させるための所定の形式のフレーム（以下、「データ処理フレーム」と呼ぶ）Ｆ１０１を生成して、エンジン共通駆動部１２０に供給する（Ｓ６０１）。

【0136】

ステップＳ６０１で、エンジン連携処理部１１０が生成するデータ処理フレームＦ１０１は、例えば、図１１（ａ）に示すような構成となる。図１１に示すように、それぞれのデータ処理フレームは、処理指定ヘッダ部とデータ部のフィールドを有するフレームである。なお、ここでは、説明を簡易にするために、データ処理フレームは１つのフレームで１つの入力データに関する処理を行うものとして説明するが、１つの入力データに関して複数フレームに分割して処理するようにしても良い。

【0137】

データ部は、当該データ処理フレームで処理の対象となる入力データが挿入されるフィールドである。データ処理フレームＦ１０１のデータ部には、エンジン連携処理部１１０からの入力データ（input1）が設定されることになる。

【0138】

処理指定ヘッダ部は、当該データ処理フレームをエンジン２００にデータ処理させる場合の処理順序及び、データ処理をさせる際に指定するパラメータ（付加パラメータ）について記述するフィールドである。処理指定ヘッダ部は、例えば、図１１（ａ）に示すように、エンジンＩＤと付加パラメータの組が処理順序に従って配列されたリストで示される。

【0139】

処理ルールＲ１のデータ処理定義ステップ（ステップＳ１０２）では、上述の通り、入力データ（input1）について、まず、エンジン２００−１（Engine1）に処理させ、さらにその処理結果をエンジン２００−２（Engine2）に処理させ、さらにその処理結果をエンジン２００−３（Engine3）に処理させるという入れ子の構造（構文）で記述され、直列的な処理が求められる。そのため、処理指定ヘッダ部では、単純な記述で、上述のような直列的な処理を実現するために、エンジンＩＤと付加パラメータの組が処理順序に従って配列されたリストで記述することに対応している。

【0140】

例えば、データ処理フレームＦ１０１の処理指定ヘッダ部は、「1（output_type1,parameter1）,2（output_type2,parameter2），3(output_type3,parameter3）；」と記述されている。データ処理フレームＦ１０１の処理指定ヘッダ部のリストの先頭に「1（output_type1,parameter1）」が、記述されているということは、データ処理フレームＦ１０１については、最初にエンジンＩＤが１のエンジン２００−１で処理されることを示している。すなわち、「1（output_type1,parameter1）」という記述は、上述の図２（ａ）に示すステップＳ１０２−１と対応する内容となっている。また、データ処理フレームＦ１０１の処理指定ヘッダ部のリストの２番目には、上述の図２（ａ）に示すステップＳ１０２−２と対応する「2（output_type2,parameter2）」が記述されている。さらに、データ処理フレームＦ１０１の処理指定ヘッダ部のリストの３番目には、上述の図２（ａ）に示すステップＳ１０２−３と対応する「3(output_type3,parameter3)」が記述されている。さらにまた、データ処理フレームＦ１０１の処理指定ヘッダ部の最後尾にはリストの末尾を示す記号として「；」が記述されている。

【0141】

エンジン連携処理部１１０は、データ処理定義ステップの構文解析で、上述のような入れ子の構造（構文）を検出した場合には、上述のように、データ処理定義ステップを構成するサブステップの内容に基づいて、処理指定ヘッダ部に投入するリストを作成する。

【0142】

次に、以上のような構造のデータ処理フレームＦ１０１が引き渡されると、エンジン共通駆動部１２０は、データ処理フレームＦ１０１を構成する処理指定ヘッダ部のリストの先頭の要素である「1（output_type1,parameter1）」を参照し、データ処理フレームＦ１０１の転送先がエンジン２００−１（エンジンＩＤ：１）であることを認識する。そして、エンジン共通駆動部１２０は、データ処理フレームＦ１０１を、エンジン２００−１に引き渡す（Ｓ６０２）。

【0143】

そして、エンジン２００−１は、データ処理フレームＦ１０１のデータ部の入力データ（input1）と、処理指定ヘッダ部のリストの先頭の要素に付加された付加パラメータ（output_type1,parameter1）を抽出する。そして、エンジン２００−１は、抽出した入力データ（input1）について、付加パラメータ（output_type1,parameter1）を用いたデータ処理を行って、処理後のデータ（Analyze1）を得る。そして、エンジン２００−１は、データ処理フレームＦ１０１について、データ部を処理後のデータ（Analyze1）に置換え、さらに、処理指定ヘッダ部のリストの先頭の要素「1（output_type1,parameter1）」を削除したデータ処理フレームＦ１０２（図１１（ｂ）参照）を生成する（Ｓ６０３）。

【0144】

そして、エンジン２００−１は、データ処理フレームＦ１０２を、エンジン共通駆動部１２０に引き渡す（Ｓ６０４）。

【0145】

次に、データ処理フレームＦ１０２が引き渡されると、エンジン共通駆動部１２０は、データ処理フレームＦ１０２を構成する処理指定ヘッダ部のリストの先頭の要素である「2（output_type2,parameter2）」を参照し、データ処理フレームＦ１０２の転送先がエンジン２００−２（エンジンＩＤ：２）であることを認識する。そして、エンジン共通駆動部１２０は、データ処理フレームＦ１０２を、エンジン２００−２に引き渡す（Ｓ６０５）。

【0146】

そして、エンジン２００−２は、データ処理フレームＦ１０２のデータ部の入力データ（Analyze1）と、処理指定ヘッダ部のリストの先頭の要素に付加された付加パラメータ（output_type2,parameter2）を抽出する。そして、エンジン２００−２は、抽出した入力データ（Analyze1）について、付加パラメータ（output_type2,parameter2）を用いたデータ処理を行って、処理後のデータ（Analyze2）を得る。そして、エンジン２００−２は、データ処理フレームＦ１０２について、データ部を処理後のデータ（Analyze2）に置換え、さらに、処理指定ヘッダ部のリストの先頭の要素「2（output_type2,parameter2）」を削除したデータ処理フレームＦ１０３（図１１（ｃ）参照）を生成する（Ｓ６０６）。

【0147】

そして、エンジン２００−２は、データ処理フレームＦ１０３を、エンジン共通駆動部１２０に引き渡す（Ｓ６０７）。

【0148】

次に、データ処理フレームＦ１０３が引き渡されると、エンジン共通駆動部１２０は、データ処理フレームＦ１０３を構成する処理指定ヘッダ部のリストの先頭の要素である「3(output_type3,parameter3）」を参照し、データ処理フレームＦ１０３の転送先がエンジン２００−３（エンジンＩＤ：３）であることを認識する。そして、エンジン共通駆動部１２０は、データ処理フレームＦ１０３を、エンジン２００−３に引き渡す（Ｓ６０８）。

【0149】

そして、エンジン２００−３は、データ処理フレームＦ１０３のデータ部の入力データ（Analyze2）と、処理指定ヘッダ部のリストの先頭の要素に付加された付加パラメータ（output_type3,parameter3）を抽出する。そして、エンジン２００−３は、抽出した入力データ（Analyze2）について、付加パラメータ（output_type3,parameter3）を用いたデータ処理を行って、処理後のデータ（Analyze3）を得る。そして、エンジン２００−３は、データ処理フレームＦ１０３について、データ部を処理後のデータ（Analyze3）に置換え、さらに、処理指定ヘッダ部のリストの先頭の要素「3（output_type3,parameter3）」を削除したデータ処理フレームＦ１０４（図１１（ｄ）参照）を生成する（Ｓ６０９）。

【0150】

そして、エンジン２００−３は、データ処理フレームＦ１０４を、エンジン共通駆動部１２０に引き渡す（Ｓ６１０）。

【0151】

次に、データ処理フレームＦ１０４が引き渡されると、エンジン共通駆動部１２０は、データ処理フレームＦ１０４を構成する処理指定ヘッダ部を参照する。この時点で、データ処理フレームＦ１０４を構成する処理指定ヘッダ部のリストは空（リストの末尾を示す記号である「；」のみが記述された状態）となるため、エンジン共通駆動部１２０は、データ処理フレームＦ１０４については、エンジン２００ではなくエンジン連携処理部１１０へ送信する（Ｓ６１１）。

【0152】

上述のように、データ処理フレームを構成する処理指定ヘッダ部のリストが空の場合には、エンジン共通駆動部１２０は、当該データ処理フレームをエンジン連携処理部１１０に送信するものとする。このように、処理指定ヘッダ部のリストを用いてデータ処理フレームを流通させることにより、各エンジン２００で処理が終了するたびに、中継処理のためだけにエンジン連携処理部１１０へ処理が戻されることが無くなり、効率的な処理を行うことができる。また、エンジン共通駆動部１２０の処理については、処理指定ヘッダ部のリストを参照して送信先を判断するという単純な処理（スイッチング処理）だけで良いため、高速処理を実現しやすくなる（例えば、構築する際のハードウェア比率を高めることが容易となる）。

【0153】

以上のように、エンジン連携処理部１１０では、処理ルールＲ１のデータ処理定義ステップに従って、データ処理フレームＦ１０１を生成して、エンジン共通駆動部１２０に引き渡すだけで、エンジン２００−１〜２００−３の処理を経た結果（Analyze3）を取得することができる。

【0154】

次に、エンジン連携処理部１１０が、処理ルールＲ２（上述の図２（ｂ）参照）のデータ処理定義ステップに基づいて、エンジン２００−４〜２００−６にデータ処理を実行させる動作について図１２、図１３を用いて説明する。

【0155】

まず、エンジン連携処理部１１０は、処理ルールＲ２（上述の図２（ｂ）参照）について構文解析を行い、エンジン２００−４〜２００−６に対して解析した構文に基づくデータ処理フレームＦ２２１、Ｆ２２１、Ｆ２３１（図１３（ａ）、図１３（ｂ）、図１３（ｃ）参照）を生成して、エンジン共通駆動部１２０に引き渡す（Ｓ７０１〜Ｓ７０３）。

【0156】

処理ルールＲ２のデータ処理定義ステップ（ステップＳ２０２）では、処理ルールＲ１とは異なり、複数のエンジン２００に対して直列的にデータ処理をさせる入れ子の構造にはなっていないため、個別にエンジン２００−４〜２００−６のそれぞれにデータ処理を依頼するデータ処理フレームＦ２１１、Ｆ２２１、Ｆ２３１が生成される。

【0157】

そして、データ処理フレームＦ２１１、Ｆ２２１、Ｆ２３１が引き渡されると、エンジン共通駆動部１２０は、それぞれのデータ処理フレームについて、送信先のエンジン２００−４〜２００−６へ引き渡す（Ｓ７０４〜Ｓ７０６）。

【0158】

そして、データ処理フレームＦ２１１が引き渡されたエンジン２００−４は、データ処理フレームＦ２１１のデータ部の入力データ（input1）を処理して、処理後のデータ（Analyze1）を得る。そして、エンジン２００−４は、データ処理フレームＦ２１１について、データ部を処理後のデータ（Analyze1）に置換え、さらに、処理指定ヘッダ部のリストの先頭の要素を削除したデータ処理フレームＦ２１２（図１３（ｄ）参照）を生成して（Ｓ７０７）、エンジン共通駆動部１２０に引き渡す（Ｓ７１０）。

【0159】

そして、データ処理フレームＦ２２１が引き渡されたエンジン２００−５は、データ処理フレームＦ２２１のデータ部の入力データ（input1）を処理して、処理後のデータ（Analyze2）を得る。そして、エンジン２００−５は、データ処理フレームＦ２２１について、データ部を処理後のデータ（Analyze2）に置換え、さらに、処理指定ヘッダ部のリストの先頭の要素を削除したデータ処理フレームＦ２２２（図１３（ｅ）参照）を生成して（Ｓ７０８）、エンジン共通駆動部１２０に引き渡す（Ｓ７１１）。

【0160】

そして、データ処理フレームＦ２３１が引き渡されたエンジン２００−６は、データ処理フレームＦ２３１のデータ部の入力データ（input1）を処理して、処理後のデータ（Analyze3）を得る。そして、エンジン２００−６は、データ処理フレームＦ２３１について、データ部を処理後のデータ（Analyze3）に置換え、さらに、処理指定ヘッダ部のリストの先頭の要素を削除したデータ処理フレームＦ２３２（図１３（ｆ）参照）を生成して（Ｓ７０９）、エンジン共通駆動部１２０に引き渡す（Ｓ７１２）。

【0161】

そして、データ処理フレームＦ２１２、Ｆ２２２、Ｆ２３２（全て処理指定ヘッダ部の内容は空）が引き渡されると、エンジン共通駆動部１２０は、データ処理フレームＦ２１２、Ｆ２２２、Ｆ２３２のそれぞれを、エンジン連携処理部１１０に引き渡す（Ｓ７１３〜７１５）。

【0162】

以上のように、エンジン連携処理部１１０では、処理ルールＲ２のデータ処理定義ステップに従って、データ処理フレームＦ２１１、Ｆ２２１、Ｆ２３１を生成して、エンジン共通駆動部１２０に引き渡すだけで、エンジン２００−４〜２００−６の処理を経た結果（Analyze1、Analyze2、Analyze3）を取得することができる。

【0163】

（Ａ−３）実施形態の効果
この実施形態によれば、以下のような効果を奏することができる。

【0164】

ネットワーク分析システム１０では、ネットワーク分析装置１００上に、エンジン２００を搭載し、さらに、ネットワーク分析装置１００とエンジン２００との間のデータ処理プロトコル（データ処理フレームを用いたやりとり）を明確にしている。これにより、ネットワーク分析装置１００上で、エンジン２００の単位で差し替えや仕様変更（バージョンアップ）等を行うことが容易となる。

【0165】

また、ネットワーク分析装置１００では、処理ルール管理テーブル１１１及びエンジン管理テーブル１１２を設けて、処理ルールごとに使用する各エンジン２００を管理している。これにより、エンジン２００についてアンインストールした場合でも、システム全体の正常動作を保つことができる。

【0166】

さらに、エンジン連携処理部１１０と、各エンジン２００の間では、データ処理フレームを用いた単純なやりとりのみで通信しているため、より高速なデータ処理を実現することができる。

【0167】

さらにまた、ネットワーク分析システム１０では、複数の処理ルール間でエンジン２００を共有することも可能であるため、効率的なシステム構築を行うことが容易となる。

【0168】

（Ｂ）他の実施形態
本発明は、上記の実施形態に限定されるものではなく、以下に例示するような変形実施形態も挙げることができる。

【0169】

（Ｂ−１）上記の実施形態では、ログ蓄積部１５０は、単にログデータを蓄積するだけであるが、ＯＰＳ３００等からアクセス可能なデータベースとして構成するようにしても良い。例えば、ネットワーク分析装置１００からＯＰＳ３００へネットワーク異常発生が通知された場合に、オペレータがＯＰＳ３００を用いて、データベース（ログ蓄積部１５０）にアクセスし、発生したネットワーク異常の詳細について確認が可能なインタフェースをネットワーク分析装置１００上に設けるようにしても良い。具体的には、例えば、ＯＰＳ３００からの操作に応じて、データベース（ログ蓄積部１５０）の内容の検索を行うことができるエンジン２００を別途備えるようにしても良い。

【0170】

（Ｂ−２）上記の実施形態では、ネットワーク分析装置１００は、ルータを流れるトラフィックを分析しているが、ルータに限定されずその他のネットワーク装置（例えば、各種サーバやファイアウォール等）に流れるトラフィックを取得して分析するようにしても良い。

【0171】

（Ｂ−３）上記の実施形態では、各エンジン２００は全てことなるデータ処理を行うものとして説明したが、同一のデータ処理を行うエンジン２００を複数備えて、不可分散させるように構成しても良い。その場合には、エンジン連携処理部１１０で、データ処理フレームを生成する際に、複数のエンジン２００に同一内容の処理を振り分ける（例えば、ラウンドロビン方式等により振り分ける）処理を行わせる必要がある。

【0172】

（Ｂ−４）上記の実施形態では、エンジン連携処理部１１０と各エンジン２００との間のデータの授受はデータ処理フレームを用いて行っているが、データの授受を行うことができれば、そのデータの構造については限定されないものである。

【0173】

（Ｂ−５）上記の実施形態では、特定のエンジン２００のアンインストールの要求があった場合に、当該エンジン２００を利用する処理ルールが無いことを確認することができるが、新規な処理ルールを登録した際に、その処理ルールがすでに備えられているエンジン２００のみで実行可能か判断し、実行できない場合は、実行すべき処理の属性等を定義して、適切なエンジン２００をＯＰＳ３００等からインスルトールするような構成とすることもできる。

【0174】

（Ｂ−６）上記の実施形態では、ＯＰＳ３００に1つのネットワーク分析システム１０が接続されているが、ＯＰＳ３００に複数のネットワーク分析システム１０を接続してコントロールすることも可能である。このような構成の場合、たとえばＯＰＳ３００が、各ネットワーク分析システム１０が備えているエンジン２００の種別を識別して、各ネットワーク分析システム１０が実行可能な処理ルールに基づいて各ネットワーク分析システム１０の役割分担を決定して、連携処理を行わせることも考えられる。

【0175】

（Ｂ−７）上記の実施形態では、ルータ４００のエクスポート処理部４４０から送出されるレポートデータは、内部ネットワークＮ１を介して、レポートパケットとしてネットワーク分析システム１０に入力される構成となっているが、エクスポート処理部４４０とネットワーク分析システム１０を、内部ネットワークＮ１を介さずに直接接続する構成としても良い。

【0176】

（Ｂ−８）上記の実施形態で、ではルータ４００に設けられたエクスポート処理部４４０からレポートデータを取得する構成となっているが、ネットワーク内に別途フローエクスポータ（エクスポート処理部４４０の機能のみを備えたネットワーク装置）を付加して、レポートデータを取得する構成としても良い。

【0177】

（Ｂ−９）上記の実施形態では、データ処理定義情報に関する情報の管理とデータ処理モジュールの管理を、テーブル形式の処理ルール管理テーブル１１１及びエンジン管理テーブル１１２を用いて行っているが、同様の機能を実行することができる構成であるなら、テーブル形式である必要は無く、例えば、データベースの形式等他の形式としても良い。

【符号の説明】

【0178】

１０…ネットワーク分析システム、１００…ネットワーク分析装置、１１０…エンジン連携処理部、１１１…処理ルール管理テーブル、１１２…エンジン管理テーブル、１２０…エンジン共通駆動部、１３０…処理ルール格納部、１４０…出力ルール設定部、１５０…ログ蓄積部、２００、２００−１〜２００−６…エンジン、２１０…インタフェース部、２２０…データ処理部、２３０…インストール処理部。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】