JP6287154B2 - パケット保存方法、パケット保存プログラム及びパケット保存装置 - Google Patents

Description

本発明は、ネットワークからキャプチャしたＰＤＵ（Protocol Data Unit）の保存技術に関する。

例えばスイッチを通過するパケットをミラーリングによってキャプチャし、ネットワークの状態を監視するネットワーク監視装置がある。

具体的には、逐次パケットを解析し、解析結果に基づきパケットのロス数やＲＴＴ（Round Trip Time）などの統計処理を行うことによってコネクションの状態を即時分析する方法の他に、キャプチャしたパケットを蓄積し、事後的にコネクションの状態を分析する方法がある。

あるコネクションについて異常が生じた場合、当該コネクションに係るパケットが蓄積されていないと事後的に異常の内容を分析できない。しかし、いずれのコネクションについても事後的な分析ができるように、それらのコネクションに係るパケットを蓄積しようとすると、備えるべき記憶容量は大きくなる。

特開２０１０−１７８２９９号公報 特開２００８−０６０６７２号公報

本発明の目的は、一側面では、異常コネクションを事後的に解析する為のデータ保存量を少なくすることである。

一態様に係るパケット保存方法は、ネットワークからキャプチャしたパケットの各々に第１識別子を割り当てると共に、当該パケットの各々をバッファに格納する処理と、第１識別子の各々に、当該第１識別子に係るパケットのコネクションを特定する第２識別子を対応付ける処理と、パケットの解析によって異常が生じているコネクションを検出する処理と、異常が生じているコネクションの第２識別子が対応付けられている複数の第１識別子を特定し、特定した当該複数の第１識別子の各々が割り当てられているパケットをバッファから収集し、収集した複数の当該パケットを記憶部に格納する格納処理とを含む。

一側面としては、異常コネクションを事後的に解析する為のデータ保存量を少なくすることができる。

図１は、ネットワーク監視システムの構成例を示す図である。 図２は、コネクションテーブルの例を示す図である。 図３は、インデックスバッファの例を示す図である。 図４は、インデックスバッファの例を示す図である。 図５は、「ロス増加」に関する異常テーブルの例を示す図である。 図６は、「ＲＴＴ増加」に関する異常テーブルの例を示す図である。 図７は、「サーバ遅延増加」に関する異常テーブルの例を示す図である。 図８は、割り当て処理フローを示す図である。 図９は、解析部のモジュール構成例を示す図である。 図１０は、解析部の処理フローを示す図である。 図１１は、解析部の処理フローを示す図である。 図１２は、異常テーブル生成処理フローを示す図である。 図１３は、「ロス増加」に関する異常テーブルの例を示す図である。 図１４は、格納処理部のモジュール構成例を示す図である。 図１５は、インデックステーブル記憶部の例を示す図である。 図１６は、読取部の処理フローを示す図である。 図１７は、判定部の処理フローを示す図である。 図１８は、収集データ記憶部の例を示す図である。 図１９は、メタデータの例を示す図である。 図２０は、上位メタデータの例を示す図である。 図２１は、保存データの例を示す図である。 図２２は、格納処理部の処理フローを示す図である。 図２３は、保存データ生成処理フローを示す図である。 図２４は、パケット登録処理フローを示す図である。 図２５は、書き込み処理（Ａ）フローを示す図である。 図２６は、異常コネクション取消処理フローを示す図である。 図２７は、実施の形態２に係る格納処理部のモジュール構成例を示す図である。 図２８は、集計データの例を示す図である。 図２９は、書き込み処理（Ｂ）フローを示す図である。 図３０は、実施の形態２に係る格納処理部の処理フローを示す図である。 図３１は、実施の形態２に係る格納処理部の処理フローを示す図である。 図３２は、ポリシー判定処理フローを示す図である。 図３３は、ポリシーデータの例を示す図である。 図３４は、実施の形態３に係るインデックスバッファの例を示す図である。 図３５は、実施の形態３に係る解析部の処理フローを示す図である。 図３６は、実施の形態３に係る解析部の処理フローを示す図である。 図３７は、実施の形態３に係る読取部の処理フローを示す図である。 図３８は、コンピュータの機能ブロック図である。

［実施の形態１］
図１に、ネットワーク監視システムの構成例を示す。ネットワーク監視装置１０１は、ネットワークタップ１０５を介して監視対象ネットワーク１０３に接続している。監視対象ネットワーク１０３は、例えばＬＡＮ（Local Area Network）である。ネットワーク監視装置１０１は、監視対象ネットワーク１０３を伝送されているパケットをキャプチャする。例えば、監視対象ネットワーク１０３のスイッチを通過するパケットをミラーポートに複製してキャプチャする。あるいは、タップを使用してキャプチャするようにしてもよい。尚、パケットは、ＰＤＵの例である。

ネットワーク監視装置１０１は、ＮＩＣ（Network Interface Card）１１１、ドライバ１１３、パケットバッファ１１５、解析部１１７、統計部１１９、コネクションテーブル記憶部１２１、インデックスバッファ１２３、異常テーブル記憶部１２５及び格納処理部１２７を有している。

ＮＩＣ１１１は、ネットワークに接続するためのインターフェースカードである。ドライバ１１３は、パケットを抽出し、抽出したパケットをパケットバッファ１１５に格納すると共に、抽出したパケットにＩＤを割り当てる。パケットバッファ１１５は、パケットを格納する。

解析部１１７は、主にパケットを解析し、異常が発生したコネクションを特定するとともに、パケットをコネクション毎に分別するためのインデックスレコードを生成する。インデックスレコードを設けることによって、パケットを収集する処理の負荷が軽減される。解析部１１７は、Ｌ４解析部１３１とＬ７解析部１３３とを有している。Ｌ４解析部１３１は、ＩＳＯ（International Organization for Standardization ）のＯＳＩ（Open Systems Interconnection）参照モデルにおける第４層（以下、Ｌ４という。）に関する解析を行う。Ｌ７解析部１３３は、ＩＳＯのＯＳＩ参照モデルにおける第７層（以下、Ｌ７という。）に関する解析を行う。

統計部１１９は、解析結果に基づき統計処理を行う。統計部１１９は、Ｌ４統計部１３５とＬ７統計部１３７とを有している。Ｌ４統計部１３５は、Ｌ４に関する統計処理を行う。具体的には、Ｌ４統計部１３５は、送受信パケット数及びバイト数、パケットのロス数、ＲＴＴ等の統計的な解析情報によりネットワーク状態をほぼリアルタイムに診断する。Ｌ７統計部１３７は、Ｌ７に関する統計処理を行う。

コネクションテーブル記憶部１２１は、パケットから抽出したコネクションに関するコネクションテーブルを記憶する。インデックスバッファ１２３は、パケットとコネクションとを対応付けるインデックスレコードを記憶する。尚、本実施の形態では、リングバッファ形式でインデックスレコードを管理する例を示す。また、後述する実施の形態では、２つのバッファテーブル形式でインデックスレコードを管理する例を示す。異常テーブル記憶部１２５は、異常が発生しているコネクションを特定するための異常テーブルを記憶する。本実施の形態では、異常種別毎に異常テーブルが設けられる例について説明するが、異常テーブルは複数の異常種別をまとめて管理するようにしてもよい。

ネットワーク監視装置１０１は、伝送ネットワーク１０７を介してストレージ装置１０９に接続している。ストレージ装置１０９は、統計データ記憶部１４１と保存データ記憶部１４３とを有している。統計データ記憶部１４１は、統計部１１９における統計処理の結果を記憶する。保存データ記憶部１４３は、ネットワーク監視装置１０１から送られる保存データを記憶する。伝送ネットワーク１０７は、監視対象ネットワーク１０３と同じネットワークであってもよい。

ドライバ１１３、パケットバッファ１１５、解析部１１７、統計部１１９、コネクションテーブル記憶部１２１、インデックスバッファ１２３、異常テーブル記憶部１２５、格納処理部１２７、Ｌ４解析部１３１、Ｌ７解析部１３３、Ｌ４統計部１３５及びＬ７統計部１３７は、例えば図３８に示すハードウエア資源によって実現される。また、ドライバ１１３、解析部１１７、統計部１１９、格納処理部１２７、Ｌ４解析部１３１、Ｌ７解析部１３３、Ｌ４統計部１３５及びＬ７統計部１３７は、当該モジュールの処理の一部又は全部を、メモリ２５０１（図３８）にロードされたプログラムをＣＰＵ（Central Processing Unit）２５０３（図３８）で順次実行することにより実現するようにしてもよい。以上で、ネットワーク監視システムの構成についての説明を終える。

次に、コネクションテーブル記憶部１２１に記憶されるコネクションテーブルについて説明する。図２に、コネクションテーブルの例を示す。コネクションテーブルには、コネクション毎に、コネクションを定義するデータが設定されている。

コネクションテーブルは、コネクション毎のレコードを有している。レコードは、コネクションＩＤを設定するためのフィールドと、送信元ＩＰ（Internet Protocol）アドレスを設定するためのフィールドと、送信元ポート番号を設定するためのフィールドと、送信先ＩＰアドレスを設定するためのフィールドと、送信先ポート番号を設定するためのフィールドと、プロトコル番号を設定するためのフィールドとを有している。

コネクションＩＤは、コネクションを特定するために解析部１１７が割り振る識別子である。送信元ＩＰアドレスは、当該パケットの送信元であるホスト装置のＩＰアドレスである。送信元ポート番号は、当該パケットの送信元であるホスト装置において当該パケットを送出するポートの番号である。送信先ＩＰアドレスは、当該パケットの送信先に相当するホスト装置のＩＰアドレスである。送信先ポート番号は、当該パケットの送信先に相当するホスト装置において当該パケットを受け入れるポートの番号である。プロトコル番号は、ＩＳＯのＯＳＩ参照モデルにおける第４層のプロトコルを識別する番号である。プロトコル番号「６」は、ＴＣＰ（Transmission Control Protocol）を示し、プロトコル番号「１７」は、ＵＤＰ（User Datagram Protocol）を示している。

この例における第１レコードは、コネクションＩＤ「ＣＮ−０００１」が割り振られたコネクションについて、ＩＰアドレス「１０．２０．３０．４０」のホスト装置におけるポート番号「２０００」が送信元に相当し、ＩＰアドレス「１０．２０．３０．５０」のホスト装置におけるポート番号「２０」が送信先に相当することを示している。また、第１レコードは、このコネクションにおける第４層のプロトコルは、ＴＣＰであることも示している。

この例における第２レコードは、コネクションＩＤ「ＣＮ−０００２」が割り振られたコネクションについて、ＩＰアドレス「２０．３０．４０．５０」のホスト装置におけるポート番号「３０００」が送信元に相当し、ＩＰアドレス「１０．２０．３０．６０」のホスト装置におけるポート番号「８０」が送信先に相当することを示している。また、第２レコードは、このコネクションにおける第４層のプロトコルは、ＴＣＰであることも示している。

この例における第３レコードは、コネクションＩＤ「ＣＮ−０００３」が割り振られたコネクションについて、ＩＰアドレス「３０．４０．５０．６０」のホスト装置におけるポート番号「４０００」が送信元に相当し、ＩＰアドレス「４０．５０．６０．７０」のホスト装置におけるポート番号「３０００」が送信先に相当することを示している。また、第３レコードは、このコネクションにおける第４層のプロトコルは、ＵＤＰであることも示している。以上で、コネクションテーブルについての説明を終える。

次に、インデックスバッファ１２３について説明する。図３に、インデックスバッファ１２３の例を示す。インデックスバッファ１２３は、リングバッファ３０１を記憶している。リングバッファ３０１は、ヘッダ部を有している。ヘッダ部には、周期番号を設定するためのフィールドと、開始レコード番号を設定するためのフィールドと、終了レコード番号を設定するためのフィールドと、が設けられている。周期番号は、当該周期を特定する番号である。周期番号は、シーケンシャルに付与される。開始レコード番号は、当該周期における先頭のインデックスレコードを特定する。終了レコード番号は、当該周期における末尾のインデックスレコードを特定する。

リングバッファ３０１のデータ本体は、パケット毎のインデックスレコードを有している。レコードは、パケットＩＤを設定するためのフィールドと、コネクションＩＤを設定するためのフィールドとを有している。パケットＩＤは、キャプチャされたパケットにシーケンシャルに付与される識別子である。この例におけるコネクションＩＤは、当該パケットの特性に係る識別子の例である。これらのインデックスレコードは、最後のインデックスレコードの次に最初のインデックスレコードへ続くように環状で管理される。

この例は、第１周期の途中の状態を示している。周期番号「１」で特定される周期におけるインデックスレコードは、１番目から始まり、この時点において６番目まで設定されている。

この例は、第１レコードにおいて、パケットＩＤ「ＰＣ−０００００１」が割り振られたパケットに係るコネクションは、コネクションＩＤ「ＣＮ−０００１」によって特定されることを示している。

同様にこの例は、第２レコードにおいて、パケットＩＤ「ＰＣ−０００００２」が割り振られたパケットに係るコネクションは、コネクションＩＤ「ＣＮ−０００２」によって特定されることを示している。

同様にこの例は、第３レコードにおいて、パケットＩＤ「ＰＣ−０００００３」が割り振られたパケットに係るコネクションは、コネクションＩＤ「ＣＮ−０００２」によって特定されることを示している。

同様にこの例は、第４レコードにおいて、パケットＩＤ「ＰＣ−０００００４」が割り振られたパケットに係るコネクションは、コネクションＩＤ「ＣＮ−０００３」によって特定されることを示している。

同様にこの例は、第５レコードにおいて、パケットＩＤ「ＰＣ−０００００５」が割り振られたパケットに係るコネクションは、コネクションＩＤ「ＣＮ−０００３」によって特定されることを示している。

同様にこの例は、第６レコードにおいて、パケットＩＤ「ＰＣ−０００００６」が割り振られたパケットに係るコネクションは、コネクションＩＤ「ＣＮ−０００１」によって特定されることを示している。

図４は、第２周期の途中の状態を示している。周期番号「２」で特定される周期におけるインデックスレコードは、１００００１番目から始まり、この時点において１００００３番目まで設定されている。

この例は、第１００００１レコードにおいて、パケットＩＤ「ＰＣ−１００００１」が割り振られたパケットに係るコネクションは、コネクションＩＤ「ＣＮ−０００３」によって特定されることを示している。

同様にこの例は、第１００００２レコードにおいて、パケットＩＤ「ＰＣ−１００００２」が割り振られたパケットに係るコネクションは、コネクションＩＤ「ＣＮ−０００２」によって特定されることを示している。

同様にこの例は、第１００００３レコードにおいて、パケットＩＤ「ＰＣ−１００００３」が割り振られたパケットに係るコネクションは、コネクションＩＤ「ＣＮ−０００４」によって特定されることを示している。以上で、インデックスバッファ１２３についての説明を終える。

次に、異常テーブル記憶部１２５に記憶される異常テーブルについて説明する。この例では、異常テーブルは、異常種別毎に設けられる。図５に、「ロス増加」に関する異常テーブルの例を示す。この異常テーブルは、「ロス増加」が発生しているコネクション毎のレコードを有している。レコードは、「ロス増加」が発生しているコネクションに係るコネクションＩＤ（以下、「ロス増加」のコネクションＩＤという。）を設定するためのフィールドと、異常解消タイミングを設定するためのフィールドとを有している。異常解消タイミングを設定するためのフィールドには、「ロス増加」が解消したタイミングを特定する周期番号が設定される。

この例における第１レコードは、コネクションＩＤ「ＣＮ−０００１」で特定されるコネクションにおいて「ロス増加」が発生し、未だその「ロス増加」が解消していないことを示している。

同様にこの例における第２レコードは、コネクションＩＤ「ＣＮ−０００４」で特定されるコネクションにおいても「ロス増加」が発生し、未だその「ロス増加」が解消していないことを示している。

図６に、「ＲＴＴ増加」に関する異常テーブルの例を示す。この異常テーブルは、「ＲＴＴ増加」が発生しているコネクション毎のレコードを有している。レコードは、「ＲＴＴ増加」が発生しているコネクションに係るコネクションＩＤ（以下、「ＲＴＴ増加」のコネクションＩＤという。）を設定するためのフィールドと、異常解消タイミングを設定するためのフィールドとを有している。異常解消タイミングを設定するためのフィールドには、「ＲＴＴ増加」が解消したタイミングを特定する周期番号が設定される。

この例における第１レコードは、コネクションＩＤ「ＣＮ−０００３」で特定されるコネクションにおいて「ＲＴＴ増加」が発生し、未だその「ＲＴＴ増加」が解消していないことを示している。

図７に、「サーバ遅延増加」に関する異常テーブルの例を示す。この異常テーブルは、「サーバ遅延増加」が発生しているコネクション毎のレコードを有している。レコードは、「サーバ遅延増加」が発生しているコネクションに係るコネクションＩＤ（以下、「サーバ遅延増加」のコネクションＩＤという。）を設定するためのフィールドと、異常解消タイミングを設定するためのフィールドとを有している。異常解消タイミングを設定するためのフィールドには、「サーバ遅延増加」が解消したタイミングを特定する周期番号が設定される。この例は、いずれのコネクションにおいても「サーバ遅延増加」が発生してないことを示している。以上で、異常テーブル記憶部１２５に記憶される異常テーブルについての説明を終える。

以下、ネットワーク監視装置１０１における処理について説明する。まず、ドライバ１１３による割り当て処理について説明する。図８に、ドライバ１１３による割り当て処理フローを示す。ドライバ１１３は、監視対象ネットワーク１０３からキャプチャしたパケットの各々にパケットＩＤを割り当てると共に、当該パケットの各々をパケットバッファ１１５に格納する。

ドライバ１１３は、待機して、ＮＩＣ１１１からパケットを受ける（Ｓ８０１）。ＮＩＣ１１１からパケットを受けると、ドライバ１１３は受けたパケットにパケットＩＤを割り当てる（Ｓ８０３）。パケットＩＤは、シーケンシャルに割り当てられる。そして、ドライバ１１３は、パケットバッファ１１５にパケットを格納する（Ｓ８０５）。また、ドライバ１１３は、パケットＩＤとパケットヘッダのアドレスとを含む通知を解析部１１７に渡す（Ｓ８０７）。そして、Ｓ８０１の処理に戻る。以上で、ドライバ１１３による割り当て処理についての説明を終える。

次に、解析部１１７のモジュール構成について説明する。図９に、解析部１１７のモジュール構成例を示す。解析部１１７は、Ｌ４解析部１３１とＬ７解析部１３３との他に、記憶部９０１、受付部９０３、コネクションテーブル生成部９０５、インデックス生成部９０７及び異常テーブル生成部９０９を有している。

記憶部９０１は、解析部１１７の内部で用いるデータを記憶する。受付部９０３は、ドライバ１１３から通知を受け付ける。コネクションテーブル生成部９０５は、コネクションテーブルを生成する。インデックス生成部９０７は、インデックスレコードを生成する。異常テーブル生成部９０９は、異常テーブルを生成する。

記憶部９０１、受付部９０３、コネクションテーブル生成部９０５、インデックス生成部９０７及び異常テーブル生成部９０９は、例えば図３８に示すハードウエア資源によって実現される。また、受付部９０３、コネクションテーブル生成部９０５、インデックス生成部９０７及び異常テーブル生成部９０９は、当該モジュールの処理の一部又は全部を、メモリ２５０１（図３８）にロードされたプログラムをＣＰＵ２５０３（図３８）で順次実行することにより実現するようにしてもよい。以上で、解析部１１７のモジュール構成についての説明を終える。

次に、解析部１１７の処理について説明する。図１０及び図１１に、解析部１１７の処理フローを示す。受付部９０３がドライバ１１３から通知を受けると（Ｓ１００１）、インデックス生成部９０７は、通知から得られるパケットＩＤを、リングバッファ３０１の新しいインデックスレコードに書く（Ｓ１００３）。最終のインデックスレコードに至った場合には、先頭のインデックスレコードが次のインデックスレコードとなる。

Ｌ４解析部１３１は、通知に含まれるアドレスによってパケットヘッダを特定する（Ｓ１００５）。Ｌ４解析部１３１は、当該パケットのプロトコルが所定のプロトコルに該当するか否かを判定する（Ｓ１００７）。所定のプロトコルは、例えばＴＣＰとＵＤＰとである。所定のプロトコルは、例えば記憶部９０１に記憶されるプロトコルテーブルに設定されるようにしてもよい。当該パケットのプロトコルが所定のプロトコルに該当しないと判定した場合には、端子Ｂを介して図１１のＳ１０１７の処理に移る。このとき、新しいレコードにおけるコネクションＩＤのフィールドは、未設定のままとなる。

一方、当該パケットのプロトコルが所定のプロトコルに該当すると判定した場合には、Ｌ４解析部１３１は、パケットヘッダからコネクションデータを抽出する（Ｓ１００９）。コネクションデータには、送信元ＩＰアドレス、送信元ポート番号、送信先ＩＰアドレス、送信先ポート番号及びプロトコル番号が含まれる。コネクションテーブル生成部９０５は、コネクションデータが既にコネクションテーブル（図２）に登録されているか否かを判定する（Ｓ１０１１）。コネクションデータが既にコネクションテーブルに登録されていると判定した場合には、端子Ａを介して図１１のＳ１０１５の処理に移る。

コネクションデータが未だコネクションテーブルに登録されていないと判定した場合には、コネクションテーブル生成部９０５は、コネクションテーブルにレコードを追加する（Ｓ１０１３）。新たなレコードには、新たなコネクションＩＤと当該コネクションデータが設定される。具体的には、コネクションＩＤ、送信元ＩＰアドレス、送信元ポート番号、送信先ＩＰアドレス、送信先ポート番号及びプロトコル番号が設定される。Ｓ１０１３の処理を終えると、端子Ａを介して図１１のＳ１０１５の処理に移る。

図１１の処理に移って、インデックス生成部９０７は、当該インデックスレコードにコネクションＩＤを書く（Ｓ１０１５）。コネクションＩＤは、コネクションテーブルに基づいて特定される。

インデックス生成部９０７は、終了レコード番号をインクリメントする（Ｓ１０１７）。最終のインデックスレコードに至った場合には、次の最終レコード番号は先頭のレコード番号となる。

続いて、Ｌ４解析部１３１は、Ｌ４解析処理を実行する（Ｓ１０１９）。Ｌ４解析処理において、Ｌ４解析部１３１は、異常が生じているコネクションを検出する。この例のＬ４解析部１３１は、「ロス増加」が生じたコネクション、「ＲＴＴ増加」が生じたコネクション及び「サーバ遅延増加」が生じたコネクションを検出する。Ｌ４解析部１３１は、例えば異常種別毎の検出結果として異常が生じているコネクションのＩＤを出力する。Ｌ４解析処理は、従来の処理と同様であるので、これ以上説明しない。

この例では、Ｌ４解析部１３１によるＬ４解析処理によって異常を検出するが、Ｌ７解析部１３３によるＬ７解析処理によって異常を検出するようにしてもよい。また、Ｌ４統計部１３５によるＬ４統計処理によって異常を検出するようにしてもよい。あるいは、Ｌ７統計部１３７によるＬ７統計処理によって異常を検出するようにしてもよい。

異常テーブル生成部９０９は、異常テーブル生成処理を実行する（Ｓ１０２１）。図１２に、異常テーブル生成処理フローを示す。異常テーブル生成部９０９は、異常テーブルに登録されている異常コネクションのうち、未処理の異常コネクションを１つ特定する（Ｓ１２０１）。このとき、異常テーブル生成部９０９は、例えば図５乃至図７に示した各異常テーブルに設定されているコネクションＩＤを順次特定する。

異常テーブル生成部９０９は、当該異常コネクションが解消したか否かを判定する（Ｓ１２０３）。具体的には、異常テーブル生成部９０９は、Ｓ１２０１で特定したコネクションＩＤがＬ４解析処理されたコネクションのＩＤと一致し、且つ異常が起きていないければ、異常は解消したと判定する。

当該異常コネクションが解消したと判定した場合には、異常テーブル生成部９０９は、当該コネクションＩＤに対応する異常解消タイミングを設定する（Ｓ１２０５）。この例では、現在の周期番号によって、異常の解消を検出した時が特定される。具体的には、異常テーブルのレコードにおける異常解消タイミングのフィールドに、現在の周期番号が設定される。現在の周期番号は、記憶部９０１に記憶されている。そして、Ｓ１２０７の処理に移る。

異常解消タイミングが設定された異常テーブルの例を、図１３に示す。この例における第１レコードは、コネクションＩＤ「ＣＮ−０００１」で特定されるコネクションにおいて発生した「ロス増加」が、第１０周期において解消したことを示している。

当該異常コネクションが解消していないと判定した場合には、従って、そのままＳ１２０７の処理に移る。

異常テーブル生成部９０９は、Ｓ１２０３について未処理の異常コネクションがあるか否かを判定する（Ｓ１２０７）。Ｓ１２０３について未処理の異常コネクションがあると判定した場合には、Ｓ１２０１に戻って、異常テーブル生成部９０９は上述の処理を繰り返す。

Ｓ１２０３について未処理の異常コネクションがないと判定した場合には、異常テーブル生成部９０９は、検出された異常コネクションが登録されているか否かを判定する（Ｓ１２０９）。異常テーブル生成部９０９は、例えば異常コネクションのＩＤが既に異常テーブルに設定されている場合に、当該異常コネクションが登録されていると判定し、異常テーブル生成処理を終える。

当該異常コネクションが登録されていないと判定した場合には、異常テーブル生成部９０９は、当該異常コネクションを登録する（Ｓ１２１１）。具体的には、異常テーブル生成部９０９は、検出された異常種別に関する異常テーブルの新しいレコードのコネクションＩＤのフィールドに当該異常コネクションのＩＤを設定する。そして、異常テーブル生成処理を終え、図１１に示したＳ１０２３の処理に移る。

図１１の説明に戻って、Ｌ７解析部１３３は、Ｌ７解析処理を実行する（Ｓ１０２３）。Ｌ７解析処理は、従来の処理と同様であるので、これ以上説明しない。

インデックス生成部９０７は、以下の処理で周期管理を行う。インデックス生成部９０７は、現在の周期を経過したか否かを判定する（Ｓ１０２５）。インデックス生成部９０７は、例えば現在の周期が開始した時点から所定時間を経過した場合に、現在の周期を経過したと判定する。現在の周期を経過したと判定した場合には、インデックス生成部９０７は、周期番号をインクリメントする（Ｓ１０２７）。更に、インデックス生成部９０７は、開始レコード番号を設定する（Ｓ１０２９）。設定される開始レコード番号は、現時点の終了レコードの次のレコードを指す。

この例では、インデックス生成部９０７において周期管理を行うが、周期管理部を設けて、インデックス生成部９０７の処理とは別個に周期管理を行うようにしてもよい。

図１１に示した処理を終えると、端子Ｃを介して図１０に示したＳ１００１の処理に戻り、上述の処理を繰り返す。以上で解析部１１７の処理についての説明を終える。

続いて、格納処理部１２７について説明する。格納処理部１２７のモジュール構成について説明する。図１４に、格納処理部１２７のモジュール構成例を示す。格納処理部１２７は、読取部１４０１、インデックステーブル記憶部１４０３、判定部１４０５、保存データ生成部１４０７、一時記憶部１４０９、収集データ記憶部１４１１、メタデータ記憶部１４１３及び書込部１４１５を有している。

読取部１４０１は、インデックスバッファ１２３からインデックスレコードを読み取り、読み取ったインデックスレコードを含むインデックステーブルをインデックステーブル記憶部１４０３に記憶させる。インデックステーブル記憶部１４０３は、周期毎に分けられたインデックステーブルを記憶する。判定部１４０５は、周期番号に基づいて、インデックステーブルを保存対象とするか否かを判定する。保存データ生成部１４０７は、保存対象となったインデックステーブルに基づいて保存データを生成する。一時記憶部１４０９は、パケットバッファ１１５からまとめて読み込まれたパケット群を一時的に記憶する。収集データ記憶部１４１１は、保存データの一部である収集データを記憶する。メタデータ記憶部１４１３は、保存データの一部であるメタデータを記憶する。書込部１４１５は、保存データをストレージ装置１０９の保存データ記憶部１４３に書き込む。

読取部１４０１、インデックステーブル記憶部１４０３、判定部１４０５、保存データ生成部１４０７、一時記憶部１４０９、収集データ記憶部１４１１、メタデータ記憶部１４１３及び書込部１４１５は、例えば図３８に示すハードウエア資源によって実現される。また、読取部１４０１、判定部１４０５、保存データ生成部１４０７及び書込部１４１５は、当該モジュールの処理の一部又は全部を、メモリ２５０１（図３８）にロードされたプログラムをＣＰＵ２５０３（図３８）で順次実行することにより実現するようにしてもよい。以上で、格納処理部１２７のモジュール構成についての説明を終える。

次に、インデックステーブルについて説明する。図１５に、インデックステーブル記憶部１４０３の例を示す。インデックステーブル記憶部１４０３は、周期毎のインデックステーブル１５０１を記憶している。インデックステーブル１５０１ａは、第１周期において受け付けたパケットに係るインデックスレコードを含んでいる。インデックステーブル１５０１ｂは、第２周期において受け付けたパケットに係るインデックスレコードを含んでいる。インデックステーブル１５０１ｃは、第３周期において受け付けたパケットに係るインデックスレコードを含んでいる。

インデックステーブル１５０１は、ヘッダ部を有している。ヘッダ部には、周期番号を設定するためのフィールドと、保存フラグを設定するためのフィールドとが設けられている。保存フラグは、当該インデックステーブル１５０１で特定されるパケットを保存する時機に至った場合にＯＮに設定される。

この例で、インデックステーブル１５０１ａ乃至インデックステーブル１５０１ｃのいずれも、未だパケットを保存する時機に至っていない。

リングバッファ３０１のデータ本体は、パケット毎のインデックスレコードを有している。インデックスレコードは、パケットバッファ１１５の場合と同様の構成を有する。

インデックステーブル１５０１ａの第１レコードは、第１周期において１番目に受け付けたパケットがパケットＩＤ「ＰＣ−０００００１」によって特定され、そのパケットのコネクションがコネクションＩＤ「ＣＮ−０００１」によって特定されることを示している。

同様にインデックステーブル１５０１ａの第２レコードは、第１周期において２番目に受け付けたパケットがパケットＩＤ「ＰＣ−０００００２」によって特定され、そのパケットのコネクションがコネクションＩＤ「ＣＮ−０００２」によって特定されることを示している。

同様にインデックステーブル１５０１ａの第３レコードは、第１周期において３番目に受け付けたパケットがパケットＩＤ「ＰＣ−０００００３」によって特定され、そのパケットのコネクションがコネクションＩＤ「ＣＮ−０００２」によって特定されることを示している。

また、インデックステーブル１５０１ｂの第１レコードは、第２周期において１番目に受け付けたパケットがパケットＩＤ「ＰＣ−１００００１」によって特定され、そのパケットのコネクションがコネクションＩＤ「ＣＮ−０００３」によって特定されることを示している。

同様にインデックステーブル１５０１ｂの第２レコードは、第２周期において２番目に受け付けたパケットがパケットＩＤ「ＰＣ−１００００２」によって特定され、そのパケットのコネクションがコネクションＩＤ「ＣＮ−０００２」によって特定されることを示している。

同様にインデックステーブル１５０１ｂの第３レコードは、第２周期において３番目に受け付けたパケットがパケットＩＤ「ＰＣ−１００００３」によって特定され、そのパケットのコネクションがコネクションＩＤ「ＣＮ−０００４」によって特定されることを示している。

また、インデックステーブル１５０１ｃの第１レコードは、第３周期において１番目に受け付けたパケットがパケットＩＤ「ＰＣ−２０００１１」によって特定され、そのパケットのコネクションがコネクションＩＤ「ＣＮ−０００３」によって特定されることを示している。

同様にインデックステーブル１５０１ｃの第２レコードは、第３周期において２番目に受け付けたパケットがパケットＩＤ「ＰＣ−２０００１２」によって特定され、そのパケットのコネクションがコネクションＩＤ「ＣＮ−０００２」によって特定されることを示している。

同様にインデックステーブル１５０１ｃの第３レコードは、第３周期において３番目に受け付けたパケットがパケットＩＤ「ＰＣ−２０００１３」によって特定され、そのパケットのコネクションがコネクションＩＤ「ＣＮ−０００４」によって特定されることを示している。以上で、インデックステーブルについての説明を終える。

次に、読取部１４０１の処理について説明する。図１６に、読取部１４０１の処理フローを示す。読取部１４０１は、インデックスバッファ１２３のリングバッファ３０１から順次インデックスレコードを読み、読んだインデックスレコードをインデックステーブル記憶部１４０３のインデックステーブル１５０１に格納する。そのため、読取部１４０１は、読み取っていないインデックスレコードがあるか否かを判定する（Ｓ１６０１）。読み取っていないインデックスレコードがないと判定した場合には、読取部１４０１は再びＳ１６０１の処理を行う。

読み取っていないインデックスレコードがあると判定した場合には、読取部１４０１は、当該インデックスレコードを読み取る（Ｓ１６０３）。

読取部１４０１は、現在の周期番号を特定する（Ｓ１６０５）。読取部１４０１は、例えばリングバッファ３０１のヘッダ部に設定されている周期番号を読む。あるいは、読取部１４０１は、解析部１１７から現在の周期番号を取得するようにしてもよい。また、読取部１４０１は、インデックスの生成を開始してからの経過時間を、１周期に相当する時間で割って、その商に１を加えることによって現在の周期番号を特定するようにしてもよい。

そして、読取部１４０１は、周期番号が切り替わったか否かを判定する（Ｓ１６０７）。具体的には、読取部１４０１は、Ｓ１６０５で特定した現在の周期番号が、以前の周期番号よりも１増えた場合に周期番号が切り替わったと判定する。

周期番号が切り替わったと判定した場合には、読取部１４０１は、インデックステーブル記憶部１４０３に新たなインデックステーブル１５０１を生成する（Ｓ１６０９）。新たなインデックステーブル１５０１における周期番号のフィールドには、Ｓ１６０５で特定された現在の周期番号が設定される。また、新たなインデックステーブル１５０１における保存のフィールドは、ＯＦＦに設定される。

読取部１４０１は、インデックスレコードを新しいインデックステーブル１５０１に書く（Ｓ１６１１）。このとき、読取部１４０１は、Ｓ１６０３で読み取ったインデックスレコードを新しいインデックステーブル１５０１の先頭レコードにコピーする。そして、Ｓ１６０１の処理に戻る。

一方、周期番号が切り替わっていないと判定した場合には、読取部１４０１は、インデックスレコードを最新のインデックステーブル１５０１に書く（Ｓ１６１３）。つまり、読取部１４０１は、それまでインデックスレコードが書かれていたインデックステーブル１５０１に、次のインデックスレコードを追加する。そして、Ｓ１６０１の処理に戻る。 ここでは、Ｓ１６０３で１つのインデックスレコードを読み、１つのインデックスレコード毎に、Ｓ１６０５乃至Ｓ１６１３の処理を行う例を示したが、Ｓ１６０３で複数のインデックスレコードを読み、Ｓ１６０５乃至Ｓ１６１３の処理で各インデックスレコードをインデックステーブルに振り分けるようにしてもよい。以上で、読取部１４０１の処理についての説明を終える。

次に、判定部１４０５の処理について説明する。図１７に、判定部１４０５の処理フローを示す。判定部１４０５は、現在の周期よりも所定の周期数だけ遡った周期に係るインデックステーブル１５０１の保存フラグをＯＮにする。この処理によって、異常コネクションを検出した周期より前の周期においてパケットバッファ１１５に格納されたパケットを収集するようにする。

そのため、判定部１４０５は、現在の周期番号を特定する（Ｓ１７０１）。判定部１４０５は、例えばリングバッファ３０１のヘッダ部に設定されている周期番号を読む。あるいは、判定部１４０５は、解析部１１７から現在の周期番号を取得するようにしてもよい。また、判定部１４０５は、インデックスの生成を開始してからの経過時間を、１周期に相当する時間で割って、その商に１を加えることによって現在の周期番号を特定するようにしてもよい。

そして、判定部１４０５は、周期番号が切り替わったか否かを判定する（Ｓ１７０３）。具体的には、判定部１４０５は、Ｓ１７０１で特定した現在の周期番号が、以前の周期番号よりも１増えた場合に周期番号が切り替わったと判定する。周期番号が切り替わっていないと判定した場合には、Ｓ１７０１の処理に戻る。

周期番号が切り替わったと判定した場合には、判定部１４０５は、現在の周期番号から所定数を引いて、保存対象を特定する周期番号を求める（Ｓ１７０５）。例えば所定数が４であれば、現在の周期の４つ前の周期においてパケットバッファ１１５に格納されたパケットが、保存対象となる。尚、この時点で、保存対象となるパケットはまだパケットバッファ１１５に残存している。

判定部１４０５は、インデックステーブル記憶部１４０３における未処理のインデックステーブル１５０１を１つ特定する（Ｓ１７０７）。例えば、判定部１４０５は、インデックステーブル記憶部１４０３におけるインデックステーブル１５０１を古い方から順次特定する。

判定部１４０５は、Ｓ１７０７で特定されたインデックステーブル１５０１が保存対象に関するか否かを判定する（Ｓ１７０９）。具体的には、判定部１４０５は、Ｓ１７０７で特定されたインデックステーブル１５０１における周期番号が、Ｓ１７０５で求めた保存対象の周期番号と一致する場合に、当該インデックステーブル１５０１が保存対象に関すると判定する。

Ｓ１７０７で特定されたインデックステーブル１５０１が保存対象に関すると判定した場合には、判定部１４０５は、当該インデックステーブル１５０１の保存フラグをＯＮに設定する（Ｓ１７１１）。Ｓ１７０７で特定されたインデックステーブル１５０１が保存対象に関しないと判定した場合には、判定部１４０５は、当該インデックステーブル１５０１の保存フラグをＯＦＦに設定する（Ｓ１７１３）。

判定部１４０５は、Ｓ１７０９について未処理のインデックステーブル１５０１があるか否かを判定する（Ｓ１７１５）。Ｓ１７０９について未処理のインデックステーブル１５０１があると判定した場合には、Ｓ１７０７の処理に戻る。Ｓ１７０９について未処理のインデックステーブル１５０１がないと判定した場合には、Ｓ１７０１の処理に戻る。以上で、判定部１４０５の処理についての説明を終える。

次に、保存データ生成部１４０７の処理によって生成される収集データについて説明する。図１８に、収集データ記憶部１４１１の例を示す。異常種別毎に、収集データセット１８０１を記憶するための領域を有している。また、収集データセット１８０１には、当該異常が発生したコネクションに係るパケットを連結した収集データ１８０３が記憶される。

例えば、収集データセット１８０１ａは「ロス増加」に関する。そして、収集データセット１８０１ａは、「ロス増加」が発生したコネクション（コネクションＩＤ：「ＣＮ−０００１」）に係るパケットを連結した収集データ１８０３ａと、同じく「ロス増加」が発生したコネクション（コネクションＩＤ：「ＣＮ−０００４」）に係るパケットを連結した収集データ１８０３ｂとを含んでいる。尚、この例で収集データ１８０３ａにおける１番目のパケットの先頭位置を示すオフセットは「０」であり、同じく収集データ１８０３ａにおける２番目のパケットの先頭位置を示すオフセットは「６２４」である。更に、収集データ１８０３ｂにおける１番目のパケットの先頭位置を示すオフセットは「６２００４」である。

また、収集データセット１８０１ｂは「ＲＴＴ増加」に関する。そして、収集データセット１８０１ｂは、「ＲＴＴ増加」が発生したコネクション（コネクションＩＤ：「ＣＮ−０００３」）に係るパケットを連結した収集データ１８０３ｃを記憶している。

続いて、保存データ生成部１４０７の処理によって生成されるメタデータについて説明する。図１９に、メタデータの例を示す。メタデータは、収集データ１８０３に対応付けて設けられる。図１９に示したメタデータは、図１８に示した収集データ１８０３ａに対応付けられている。メタデータは、ヘッダ部とテーブル部とを有している。

ヘッダ部には、コネクションＩＤを設定するためのフィールドと、送信元ＩＰアドレスを設定するためのフィールドと、送信元ポート番号を設定するためのフィールドと、送信先ＩＰアドレスを設定するためのフィールドと、送信先ポート番号を設定するためのフィールドと、プロトコル番号を設定するためのフィールドとが含まれている。

この例のヘッダ部は、このメタデータが、コネクションＩＤ「ＣＮ−０００１」のコネクションに係るパケットの収集データ１８０３ａに対応することを示している。また、この例のヘッダ部は、このコネクションについて、ＩＰアドレス「１０．２０．３０．４０」のホスト装置におけるポート番号「２０００」が送信元に相当し、ＩＰアドレス「１０．２０．３０．５０」のホスト装置におけるポート番号「２０」が送信先に相当することを示している。更に、この例のヘッダ部は、このコネクションにおける第４層のプロトコルは、ＴＣＰであることも示している。

テーブル部には、収集データ１８０３ａに含まれるパケット毎のレコードが設けられている。レコードには、パケットＩＤを設定するためのフィールドと、オフセットを設定するためのフィールドとが設けられている。この例は、１番目のパケットがパケットＩＤ「ＰＣ−０００００１」で特定され、オフセット「０」を先頭に格納されていることを示している。更にこの例は、２番目のパケットがパケットＩＤ「ＰＣ−０００００６」で特定され、オフセット「６２４」を先頭に格納されていることを示している。

図１８に示した収集データ１８０３ｂ及び収集データ１８０３ｃについても、同様にメタデータが設けられる。

次に、メタデータ記憶部１４１３に生成される上位メタデータについて説明する。図２０に、上位メタデータの例を示す。上位メタデータは、異常種別毎に設けられる。上位メタデータは、ヘッダ部とテーブル部とを有している。ヘッダ部には、異常種別を設定するためのフィールドが設けられる。この例では、「ロス増加」が設定されている。

テーブル部のレコードには、コネクションＩＤを設定するためのフィールドと、開始オフセットを設定するためのフィールドとが設けられている。この例のテーブル部の第１レコードは、１番目のメタデータがコネクションＩＤ「ＣＮ−０００１」に関し、１番目の収集データ１８０３ａがオフセット「０」を先頭に格納されていることを示している。同様にこの例のテーブル部の第２レコードは、２番目のメタデータがコネクションＩＤ「ＣＮ−０００４」に関し、２番目の収集データ１８０３ｂがオフセット「６２００４」を先頭に格納されていることを示している。

次に、書込部１４１５によって書き込まれる保存データについて説明する。図２１に、保存データの例を示す。本実施の形態に係る保存データは、図２１に例示したようなオブジェクト２１０１の構成を有している。オブジェクト２１０１は、収集データセット１８０１を含んでいる。この例における収集データセット１８０１ａは、収集データ１８０３ａと収集データ１８０３ｂとを含んでいる。

オブジェクト２１０１は、メタデータセット２１０３を含んでいる。この例におけるメタデータセット２１０３ａは、収集データ１８０３ａに関するメタデータ２１０５ａと、収集データ１８０３ｂに関するメタデータ２１０５ｂと、更にそれらのメタデータ２１０５に関する上位メタデータ２１０７とを含んでいる。

次に、図２２に、格納処理部１２７の処理フローを示す。保存データ生成部１４０７は、保存フラグＯＮのインデックステーブル１５０１があるか否かを判定する（Ｓ２２０１）。保存フラグＯＮのインデックステーブル１５０１がないと判定した場合には、保存データ生成部１４０７はＳ２２０１の処理を繰り返す。

保存フラグＯＮのインデックステーブル１５０１があると判定した場合には、保存データ生成部１４０７は、保存フラグＯＮのインデックステーブル１５０１を特定する（Ｓ２２０３）。図１７において説明したように、保存フラグＯＮのインデックステーブル１５０１は、現在から所定数遡った周期に係るインデックステーブル１５０１である。このインデックステーブル１５０１で管理されているパケットのうちから、収集すべきパケットが選択される。

保存データ生成部１４０７は、現時点において異常コネクションがあるか否かを判定する（Ｓ２２０５）。保存データ生成部１４０７は、例えば図５乃至図７に示した異常テーブルにおいてコネクションＩＤが設定されている場合に、現時点において異常コネクションがあると判定する。

パケットバッファ１１５からのデータ読み取り回数を減らすために、保存データ生成部１４０７は、パケット群を一括して読み取り、読み取ったパケット群を一時記憶部１４０９に記憶させる（Ｓ２２０７）。但し、以下の処理でパケットを１個ずつ読む場合には、Ｓ２２０７の処理は省いてもよい。

保存データ生成部１４０７は、Ｓ２２１１とＳ２２１３について未処理の異常コネクションを１つ特定する（Ｓ２２０９）。例えば、保存データ生成部１４０７は、図５乃至図７に示した異常テーブルに含まれるコネクションＩＤを順次特定する。

保存データ生成部１４０７は、保存データ生成処理を実行する（Ｓ２２１１）。保存データ生成処理において、収集データ記憶部１４１１とメタデータ記憶部１４１３とに新たなデータが生成される。

図２３に、保存データ生成処理フローを示す。保存データ生成部１４０７は、当該異常種別に関する上位メタデータがなければ生成する。そのため、保存データ生成部１４０７は、当該異常種別に関する上位メタデータがあるか否かを判定する（Ｓ２３０１）。当該異常種別は、図２２のＳ２２０９で異常コネクションを特定したときに参照した異常テーブルの異常種別に相当する。

当該異常種別に関する上位メタデータがないと判定した場合には、保存データ生成部１４０７は、当該異常種別に関する上位メタデータを生成する（Ｓ２３０３）。図２０に例示したように、上位メタデータにおける異常種別のフィールドには、当該異常種別が設定される。この時点で、テーブル部にレコードは設定されていない。

保存データ生成部１４０７は、図２２のＳ２２０３で特定されたインデックステーブル１５０１において、Ｓ２３０７について未処理のインデックスレコードを１つ特定する（Ｓ２３０５）。保存データ生成部１４０７は、例えばインデックステーブル１５０１に含まれるインデックスレコードを順次特定する。

保存データ生成部１４０７は、当該インデックスレコードにおけるコネクションＩＤが当該異常コネクションに相当するか否かを判定する（Ｓ２３０７）。当該異常コネクションは、上述したように図２２のＳ２２０９で特定されている。

当該インデックスレコードにおけるコネクションＩＤが当該異常コネクションに相当しないと判定した場合には、当該インデックスレコードで特定されるパケットは登録しない。従って、そのままＳ２３１１の処理に移る。

当該インデックスレコードにおけるコネクションＩＤが当該異常コネクションに相当すると判定した場合には、当該インデックスレコードで特定されるパケットは登録される。そのため、保存データ生成部１４０７は、パケット登録処理を実行する（Ｓ２３０９）。

図２４に、パケット登録処理フローを示す。保存データ生成部１４０７は、当該異常コネクションのＩＤが上位メタデータ２１０７のテーブル部に含まれるか否かを判定する（Ｓ２４０１）。当該異常コネクションは、上述したように図２２のＳ２２０９で特定されている。

当該異常コネクションのＩＤが上位メタデータ２１０７のテーブル部に含まれないと判定した場合には、保存データ生成部１４０７は、上位メタデータのテーブル部にレコードを追加する（Ｓ２４０３）。

追加されたレコードには、図２０を用いて上述したように当該異常コネクションのＩＤと開始オフセットとが設定される。

更に、保存データ生成部１４０７は、当該異常コネクションに関するメタデータを生成する（Ｓ２４０５）。メタデータのヘッダ部には、図１９を用いて上述したように当該異常コネクションに関するデータが設定される。

また、保存データ生成部１４０７は、図１８に示したように、収集データ記憶部１４１１に当該異常コネクションに対応する収集データ１８０３のための領域を設定する（Ｓ２４０７）。そして、Ｓ２４０９の処理に移る。

一方、当該異常コネクションのＩＤが上位メタデータ２１０７のテーブル部に含まれると判定した場合には、そのままＳ２４０９の処理に移る。

保存データ生成部１４０７は、図２３のＳ２３０５において特定したインデックスレコードに含まれるパケットＩＤに対応するパケットを一時記憶部１４０９から読み、そのパケットを当該異常コネクションに対応する収集データに追加する（Ｓ２４０９）。

保存データ生成部１４０７は、更にメタデータのテーブル部にレコードを追加する（Ｓ２４１１）。追加されたレコードには、図１９に示したように、パケットＩＤと、追加されたパケットのオフセットとが設定される。そして、パケット登録処理を終えると、図２３のＳ２３１１の処理に戻る。

図２３の説明に戻って、保存データ生成部１４０７は、Ｓ２３０７について未処理のインデックスレコードがあるか否かを判定する（Ｓ２３１１）。未処理のインデックスレコードがあると判定した場合には、Ｓ２３０５の処理に戻って、上述した処理を繰り返す。一方、未処理のインデックスレコードがないと判定した場合には、保存データ生成処理を終え、図２２に示したＳ２２１３の処理に戻る。

このようにして、保存データ生成部１４０７は、異常が生じているコネクションＩＤに対応する複数のパケットＩＤを特定し、各パケットＩＤに対応するパケットを収集する。

図２２の説明に戻って、書込部１４１５は、書き込み処理を実行する（Ｓ２２１３）。本実施の形態では、書き込み処理（Ａ）が実行される。図２５に、書き込み処理（Ａ）フローを示す。書込部１４１５は、書き込みのタイミングに至ったか否かを判定する（Ｓ２５０１）。書込部１４１５は、例えば所定の間隔が経過すると、書き込みのタイミングに至ったと判定する。

書き込みのタイミングに至ったと判定した場合には、書込部１４１５は、メタデータ記憶部１４１３に記憶されているメタデータセットと、収集データ記憶部１４１１に記憶されている収集データセットとを、伝送ネットワーク１０７を介して保存データ記憶部１４３に書き込む（Ｓ２５０３）。この例では、書込部１４１５は、図２１に示したようにオブジェクト２１０１の形式に従ってこれらのデータを書く。

そして、書込部１４１５は、メタデータ記憶部１４１３に記憶されているメタデータセットと、収集データ記憶部１４１１に記憶されている収集データセットとを削除して（Ｓ２５０５）、書き込み処理（Ａ）を終える。

書き込みのタイミングに至っていないと判定した場合には、そのまま書き込み処理（Ａ）を終える。書き込み処理（Ａ）を終えると、図２２に示したＳ２２１５の処理に戻る。

図２２の説明に戻って、保存データ生成部１４０７は、Ｓ２２１１及びＳ２２１３について未処理の異常コネクションがあるか否かを判定する（Ｓ２２１５）。未処理の異常コネクションがあると判定した場合には、Ｓ２２０９の処理に戻って、上述の処理を繰り返す。

一方、未処理の異常コネクションがないと判定した場合には、保存データ生成部１４０７は、異常コネクション取消処理を実行する（Ｓ２２１７）。

図２６に、異常コネクション取消処理フローを示す。異常コネクション取消処理において、パケットの収集を終えた異常コネクションを取り消す。

保存データ生成部１４０７は、当該インデックステーブル１５０１の周期番号を特定する（Ｓ２６０１）。当該インデックステーブル１５０１は、上述したように図２２のＳ２２０３で特定されている。

保存データ生成部１４０７は、Ｓ２６０５について未処理の異常コネクションを１つ特定する（Ｓ２６０３）。例えば、保存データ生成部１４０７は、図５乃至図７に示した異常テーブルに含まれるコネクションＩＤを順次特定する。

保存データ生成部１４０７は、異常テーブルにおいて当該コネクションＩＤに対応する異常解消タイミングを特定し、当該異常解消タイミングが当該インデックステーブル１５０１の周期番号と一致するか否かを判定する（Ｓ２６０５）。

当該異常解消タイミングが当該インデックステーブル１５０１の周期番号と一致すると判定した場合には、保存データ生成部１４０７は、当該異常コネクションを取り消す（Ｓ２６０７）。具体的には、保存データ生成部１４０７は、異常テーブルにおける当該コネクションＩＤのレコードを削除し、あるいは当該レコードのコネクションＩＤのフィールドと、異常解消タイミングのフィールドとを未設定とする。そして、Ｓ２６０９の処理に移る。

当該異常解消タイミングが当該インデックステーブル１５０１の周期番号と一致しないと判定した場合には、未だパケットの収集を終えていないので、そのままＳ２６０９の処理に移る。当該異常解消タイミングが未設定である場合も、そのままＳ２６０９の処理に移る。

保存データ生成部１４０７は、Ｓ２６０５について未処理の異常コネクションがあるか否かを判定する（Ｓ２６０９）。Ｓ２６０５について未処理の異常コネクションがあると判定した場合には、Ｓ２６０３の処理に戻って、上述した処理を繰り返す。

一方、Ｓ２６０５について未処理の異常コネクションがないと判定した場合には、異常コネクション取消処理を終え、図２２に示したＳ２２１９の処理に戻る。

このようにして、保存データ生成部１４０７は、少なくとも異常の解消を検出した周期までにパケットバッファ１１５に格納されたパケットを収集する。例えば、図１３に示した例の場合、「ロス増加」が生じているコネクション（コネクションＩＤ：ＣＮ−０００１）については、第１０周期において「ロス増加」が解消し、第１０周期までのパケットが収集される。

図２２の説明に戻って、保存データ生成部１４０７は、Ｓ２２０３で特定されたインデックステーブル１５０１を削除する（Ｓ２２１９）。そして、Ｓ２２０１の処理に戻り、上述の処理を繰り返す。以上で、格納処理部１２７の処理についての説明を終える。

この実施の形態によれば、異常コネクションを事後的に解析する為のデータ保存量を少なくすることができる。

更に、異常が生じる前にキャプチャしたパケットも保存できる。例えば、異常が発生する前のコネクションの状態を把握することに役立つ。

また、異常が解消するまでにキャプチャしたパケットを保存できる。例えば、コネクションにおける異常解消の過程を把握することに役立つ。

尚、パケット毎に異常の有無を識別しなくてもよいので、処理負荷が小さいという面もある。

［実施の形態２］
上述した実施の形態では、所定の異常種別に関するパケットを収集する例について説明したが、本実施の形態では、パケットを収集すべき異常種別を、ストレージ装置１０９における記憶状態に応じて決める例について説明する。

図２７に、実施の形態２に係る格納処理部１２７のモジュール構成例を示す。本実施の形態に係る格納処理部１２７は、集計データ記憶部２７０１とポリシーデータ記憶部２７０３とを有している。書込部１４１５は、ストレージ装置１０９の記憶状態に関するデータを集計する処理も行う。集計データ記憶部２７０１は、書込部１４１５によって集計されたデータを記憶する。ポリシーデータ記憶部２７０３は、異常種別を決めるためのポリシーに関するデータを予め記憶している。

集計データ記憶部２７０１に記憶される集計データについて説明する。図２８に、集計データの例を示す。集計データは、各記録時間に、書き込み量（Ｇバイト）、書込み時間（秒）及びストレージ残量（Ｇバイト）を対応付けている。

書き込み量（Ｇバイト）は、前回の記録時間から当該記録時間までの間に書き込んだ保存データのサイズを示している。

書込み時間（秒）は、前回の記録時間から当該記録時間までの間に保存データの書き込んだ処理時間を示している。

ストレージ残量（Ｇバイト）は、当該記録時間における残りの記憶容量を示している。

この例では、３０秒の間隔で集計データを記録する。この例は、９時５９分３０秒〜１０時００分００秒において、０．６２６Ｇバイトの保存データを書き込み、その書き込みに６秒要したことを示している。また、この例は、１０時００分００秒に残りの記憶容量が６００２Ｇバイトであることを示している。

更にこの例は、１０時００分００秒〜１０時００分３０秒において、２．５３４Ｇバイトの保存データを書き込み、その書き込みに２４秒要したことを示している。また、この例は、１０時００分３０秒に残りの記憶容量が５９９９Ｇバイトであることを示している。

更にこの例は、１０時００分３０秒〜１０時０１分００秒において、１．２４５Ｇバイトの保存データを書き込み、その書き込みに１２秒要したことを示している。また、この例は、１０時０１分００秒に残りの記憶容量が５９９８Ｇバイトであることを示している。以上で、集計データ記憶部２７０１に記憶される集計データについての説明を終える。

本実施の形態では、書き込み処理（Ａ）に代えて書き込み処理（Ｂ）を行う。図２９に、書き込み処理（Ｂ）フローを示す。書込部１４１５は、図２５に示したＳ２５０１の場合と同様に、書き込みのタイミングに至ったか否かを判定する（Ｓ２９０１）。

書き込みのタイミングに至ったと判定した場合には、書込部１４１５は、図２５に示したＳ２５０３の場合と同様に、メタデータと収集データとを書き込む（Ｓ２９０３）。書込部１４１５は、Ｓ２９０３におけるストレージ装置１０９への書き込み量を算出する（Ｓ２９０５）。更に、書込部１４１５は、Ｓ２９０３におけるストレージ装置１０９への書き込み時間を算出する（Ｓ２９０７）。

そして、書込部１４１５は、図２５に示したＳ２５０５の場合と同様に、メタデータセットと収集データセットとを削除する（Ｓ２９０９）。そして、Ｓ２９１１の処理に移る。

一方、書き込みのタイミングに至っていないと判定した場合には、そのままＳ２９１１の処理に移る。

書込部１４１５は、記録のタイミングに至ったか否かを判定する（Ｓ２９１１）。書込部１４１５は、例えば所定の間隔で、集計データを記録する。書込部１４１５は、収集データ記憶部１４１１及びメタデータ記憶部１４１３に記憶されているデータ量が所定量に達した場合に、記録のタイミングに至ったと判定するようにしてもよい。

記録のタイミングに至ったと判定した場合には、書込部１４１５は、ストレージ装置１０９の残量を特定する（Ｓ２９１３）。書込部１４１５は、例えばストレージ装置１０９から残量を示すデータを取得する。そして、書込部１４１５は、集計データを集計データ記憶部２７０１に記録して（Ｓ２９１５）、書き込み処理（Ｂ）を終える。図２８を用いて上述したように、書込部１４１５は、各記録時間に、書き込み量（Ｇバイト）、書込み時間（秒）及びストレージ残量（Ｇバイト）を対応付ける。集計データにおける書き込み量は、当該期間においてＳ２９０５で算出した書き込み量を合算した値である。集計データにおける書き込み時間は、当該期間においてＳ２９０７で算出した書き込み時間を合算した値である。

一方、記録のタイミングに至っていないと判定した場合には、そのまま書き込み処理（Ｂ）を終える。以上で、書き込み処理（Ｂ）についての説明を終える。

また、本実施の形態では、図２２及び図２３に示した格納処理部１２７の処理に代えて、図３０及び図３１に示した処理を行う。図３０及び図３１に、実施の形態２に係る格納処理部１２７の処理フローを示す。Ｓ２２０１及びＳ２２０３における処理は、図２２の場合と同様である。そして、保存データ生成部１４０７は、ポリシー判定処理を実行する（Ｓ３００１）。

図３２に、ポリシー判定処理フローを示す。ポリシー判定処理では、集計データ記憶部２７０１に記憶されている集計データに基づいて、異常種別を選択するためのポリシーを判定する。

保存データ生成部１４０７は、過去のストレージ残量から最新のストレージ残量を差し引くことによって、ストレージ残量の減少量を算出する（Ｓ３２０１）。保存データ生成部１４０７は、複数の周期に関する減少量の単純平均あるいは加重平均を算出するようにしてもよい。

保存データ生成部１４０７は、最新の書き込み時間が上限の閾値（例えば、２８秒）以上であるか否かを判定する（Ｓ３２０３）。最新の書き込み時間が上限の閾値以上であると判定した場合には、保存データ生成部１４０７は、書き込み量を減らすポリシーを選択する（Ｓ３２０５）。

ここで、ポリシーデータ記憶部２７０３に記憶されているポリシーデータについて説明する。図３３に、ポリシーデータの例を示す。ポリシーデータは、ポリシーに従って保存対象に関する異常種別を定めている。

この例では、ポリシー毎にレコードが設けられている。レコードには、各異常種別を保存対象とするか否かを特定するデータが設定されている。この例で、第１レコードは、第１ポリシーでは「ロス増加」、「ＲＴＴ増加」及び「サーバ遅延増加」が保存対象に関することを示している。第２レコードは、第２ポリシーでは「ロス増加」及び「ＲＴＴ増加」が保存対象に関し、「サーバ遅延増加」が保存対象に関しないことを示している。第３レコードは、第３ポリシーでは「ロス増加」が保存対象に関し、「ＲＴＴ増加」及び「サーバ遅延増加」が保存対象に関しないことを示している。この例では、第１ポリシーにおいて最も書き込み量が多く、第２ポリシーにおいて次に書き込み量が多く、第３ポリシーにおいて書き込み量が最も少ない。

図３２のＳ３２０５では、例えば図３３に示した例において、現在のポリシーよりも下位のポリシーが選択される。

図３２の説明に戻って、Ｓ３２０３の処理で最新の書き込み時間が上限の閾値以上ではないと判定した場合には、保存データ生成部１４０７は、最新の書き込み時間が下限の閾値（例えば、１２秒）以下であるか否かを判定する（Ｓ３２０７）。

最新の書き込み時間が下限の閾値以下ではないと判定した場合には、保存データ生成部１４０７は、Ｓ３２０１で算出した減少量が上限の閾値（例えば、２．８Ｇバイト）以上であるか否かを判定する（Ｓ３２０９）。

Ｓ３２０１で算出した減少量が上限の閾値以上であると判定した場合には、Ｓ３２０５において書き込み量を減らすポリシーを選択する。

一方、Ｓ３２０１で算出した減少量が上限の閾値以上ではないと判定した場合には、保存データ生成部１４０７は、現状のポリシーを選択する（Ｓ３２１１）。つまり、ポリシーは変更されない。

Ｓ３２０７において最新の書き込み時間が下限の閾値以下であると判定した場合には、保存データ生成部１４０７は、Ｓ３２０１で算出した減少量が下限の閾値（例えば、１．１Ｇバイト）以下であるか否かを判定する（Ｓ３２１３）。

Ｓ３２０１で算出した減少量が下限の閾値以下であると判定した場合には、保存データ生成部１４０７は、書き込み量を増やすポリシーを選択する（Ｓ３２１５）。図３３に示した例の場合には、現在のポリシーよりも上位のポリシーが選択される。

一方、Ｓ３２０１で算出した減少量が下限の閾値以下ではないと判定した場合には、Ｓ３２０９の処理に移って、上述の処理を行う。ポリシー判定処理を終えると、図３０に示したＳ３００３の処理に移る。

図３０の説明に戻って、保存データ生成部１４０７は、Ｓ３００１で判定したポリシーに従って異常種別を特定する（Ｓ３００３）。そして、端子Ｄを介して図３１に示したＳ２２０５の処理に移る。

Ｓ２２０５では、Ｓ３００３で特定された異常種別に係る異常テーブルに、異常コネクションがあるか否かを判定する。以下、Ｓ２２０７乃至Ｓ２２１７においても、同様にＳ３００３で特定された異常種別に係る異常テーブルにおける異常コネクションを処理の対象とする。

Ｓ２２１９は、図２２の場合と同様である。Ｓ２２１９を終えると、端子Ｅを介して図３０に示したＳ２２０１の処理に戻る。

このようにして、ストレージ装置１０９における記憶状態が悪化していると推測される場合には、書き込み量を減らすように異常種別を選択すれば、データ保存の失敗を減らすことができる。また、ストレージ装置１０９における記憶状態が改善していると推測される場合には、書き込み量を増やすように異常種別を選択すれば、多くの異常を解析できる。

この実施の形態によれば、ストレージ装置１０９などの記憶部の記憶状態に応じてデータ保存量を加減できる。

［実施の形態３］
上述の実施の形態では、インデックスバッファ１２３においてリングバッファ３０１を用いる例を説明したが、本実施の形態では、インデックスバッファ１２３において２面のバッファテーブルを用いる例について説明する。

本実施の形態では、周期毎にインデックス生成部９０７がインデックスレコードを書き込むバッファテーブルを切り替える。保存データ生成部１４０７は、インデックスレコードを書き込まれていない方のバッファテーブルからインデックスレコードを読み込む。そのため、保存データ生成部１４０７は、インデックス生成部９０７と同期して、インデックス生成部９０７と反対になるようにバッファテーブルを切り替える。

図３４に、実施の形態３に係るインデックスバッファ１２３の例を示す。インデックスバッファ１２３は、図示するようにバッファテーブル３４０１を２つ含んでいる。バッファテーブル３４０１は、ヘッダ部を有している。ヘッダ部には、周期番号を設定するためのフィールドと、レコード数を設定するためのフィールドとが設けられている。周期番号は、当該周期を特定する番号である。周期番号は、シーケンシャルに付与される。レコード数は、当該周期におけるインデックスレコードの数である。

バッファテーブル３４０１のデータ本体は、パケット毎のインデックスレコードを有している。インデックスレコードの構成は、実施の形態１の場合と同様である。

この例は、第２周期の途中の状態を示している。バッファテーブル３４０１ａは、既に終了した第１周期における１０００００個のインデックスレコードを含んでいる。

この例は、第１レコードにおいて、パケットＩＤ「ＰＣ−０００００１」が割り振られたパケットに係るコネクションは、コネクションＩＤ「ＣＮ−０００１」によって特定されることを示している。

同様にこの例は、第２レコードにおいて、パケットＩＤ「ＰＣ−０００００２」が割り振られたパケットに係るコネクションは、コネクションＩＤ「ＣＮ−０００２」によって特定されることを示している。

同様にこの例は、第３レコードにおいて、パケットＩＤ「ＰＣ−０００００３」が割り振られたパケットに係るコネクションは、コネクションＩＤ「ＣＮ−０００２」によって特定されることを示している。

同様にこの例は、第４レコードにおいて、パケットＩＤ「ＰＣ−０００００４」が割り振られたパケットに係るコネクションは、コネクションＩＤ「ＣＮ−０００３」によって特定されることを示している。

同様にこの例は、第５レコードにおいて、パケットＩＤ「ＰＣ−０００００５」が割り振られたパケットに係るコネクションは、コネクションＩＤ「ＣＮ−０００３」によって特定されることを示している。

同様にこの例は、第６レコードにおいて、パケットＩＤ「ＰＣ−０００００６」が割り振られたパケットに係るコネクションは、コネクションＩＤ「ＣＮ−０００１」によって特定されることを示している。

バッファテーブル３４０１ｂは、進行中の第２周期における３個のインデックスレコードを含んでいる。

この例は、第１レコードにおいて、パケットＩＤ「ＰＣ−１００００１」が割り振られたパケットに係るコネクションは、コネクションＩＤ「ＣＮ−０００３」によって特定されることを示している。

同様にこの例は、第２レコードにおいて、パケットＩＤ「ＰＣ−１００００２」が割り振られたパケットに係るコネクションは、コネクションＩＤ「ＣＮ−０００２」によって特定されることを示している。

同様にこの例は、第３レコードにおいて、パケットＩＤ「ＰＣ−１００００３」が割り振られたパケットに係るコネクションは、コネクションＩＤ「ＣＮ−０００４」によって特定されることを示している。

尚、第３周期に移った場合には、バッファテーブル３４０１ａの周期番号が「３」となり、レコード数が０となる。このように、周期毎にバッファテーブル３４０１ａとバッファテーブル３４０１ｂとが切り替えられる。

また、本実施の形態では、図１０及び図１１に示した解析部１１７の処理に代えて、図３５及び図３６に示した処理を行う。

図３５及び図３６に、実施の形態３に係る解析部１１７の処理フローを示す。Ｓ１００１の処理は、図１０の場合と同様である。

インデックス生成部９０７は、書き込み先のバッファテーブル３４０１の新しいインデックスレコードにパケットＩＤを書く（Ｓ３５０１）。

Ｓ１００５乃至Ｓ１０１３の処理については、図１０の場合と同様である。尚、Ｓ１００７で所定のプロトコルではないと判定した場合には、端子Ｇを介して図３６に示したＳ３５０５の処理に移る。Ｓ３５０５の処理については、後述する。Ｓ１０１１においてコネクションデータが登録されていると判定した場合、あるいはＳ１０１３の処理を終えた場合には、端子Ｆを介して図３６のＳ３５０３の処理に移る。

図３６の処理に移って、インデックス生成部９０７は、Ｓ３５０１でパケットＩＤを書いたレコードに、コネクションＩＤを書く（Ｓ３５０３）。そして、インデックス生成部９０７は、書き込み先のバッファテーブル３４０１におけるレコード数をインクリメントする（Ｓ３５０５）。

Ｓ１０１９乃至Ｓ１０２３の処理については、図１１の場合と同様である。

インデックス生成部９０７は、バッファテーブル３４０１を切り替えるタイミングに至ったか否かを判定する（Ｓ３５０７）。この例では、インデックス生成部９０７は、図１１の場合と同様に所定の周期に従って、バッファテーブル３４０１を切り替えるタイミングに至ったと判定する。インデックス生成部９０７は、レコード数が所定の値に達した場合に、バッファテーブル３４０１を切り替えるタイミングに至ったと判定するようにしてもよい。

バッファテーブル３４０１を切り替えるタイミングに至ったと判定した場合には、インデックス生成部９０７は、書き込み先のバッファテーブル３４０１を切り替える（Ｓ３５０９）。そして、インデックス生成部９０７は、切り替え先のバッファテーブル３４０１における周期番号に２を加える（Ｓ３５１１）。このとき、インデックス生成部９０７は、レコード数を「０」に初期化する。そして、端子Ｈを介して、図３５に示したＳ１００１の処理に戻る。

一方、バッファテーブル３４０１を切り替えるタイミングに至っていないと判定した場合には、端子Ｈを介して、図３５に示したＳ１００１の処理に戻る。以上で、解析部１１７の処理フローについての説明を終える。

また、本実施の形態では、図１６に示した読取部１４０１の処理に代えて、図３７に示した処理を行う。

読取部１４０１は、現在の周期番号を特定する（Ｓ３７０１）。読取部１４０１は、例えば２つのバッファテーブル３４０１のヘッダ部に設定されている周期番号のうち、大きい方の周期番号を特定する。あるいは、読取部１４０１は、解析部１１７から現在の周期番号を取得するようにしてもよい。また、読取部１４０１は、インデックスの生成を開始してからの経過時間を、１周期に相当する時間で割って、その商に１を加えることによって現在の周期番号を特定するようにしてもよい。

読取部１４０１は、周期番号が切り替わったか否かを判定する（Ｓ３７０３）。具体的には、読取部１４０１は、Ｓ３７０１で特定した現在の周期番号が、以前の周期番号よりも１増えた場合に周期番号が切り替わったと判定する。

周期番号が切り替わったと判定した場合には、読取部１４０１は、新たなインデックステーブル１５０１を生成し（Ｓ３７０５）、書き込まれていない方のバッファテーブル３４０１のデータをインデックステーブル１５０１にコピーする（Ｓ３７０７）。具体的には、周期番号とインデックスレコードとをコピーする。そして、Ｓ３７０１の処理に戻る。

周期番号が切り替わっていないと判定した場合には、Ｓ３７０１の処理に戻る。

このように、バッファテーブルを切り替えて用いる場合には、同じ周期のパケットについて、保存データを生成する処理が、インデックスを生成する処理よりも一定時間遅れるので、異常を検出した時点ですぐに保存データを生成するようにすると、異常発生前のパケットを収集することになる。

この実施の形態によれば、インデックステーブル１５０１を切り替えれば、解析部１１７がインデックスレコードを書き込む領域と格納処理部１２７がインデックスレコードを読み出す領域とが常に異なり、完全ロックフリーアルゴリズムによって、マルチコアを生かす並列処理が実現される。例えば、ストレージ装置１０９に対する処理待ちで一部のオブジェクトの格納が遅れても、全体処理に対する影響は抑えられ、また復旧されるまでデータを消失しないようにできる。

以上本発明の実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、上述の機能ブロック構成は実際のプログラムモジュール構成に一致しない場合もある。

また、上で説明した各記憶領域の構成は一例であって、上記のような構成でなければならないわけではない。さらに、処理フローにおいても、処理結果が変わらなければ処理の順番を入れ替えることも可能である。さらに、並列に実行させるようにしても良い。

なお、上で述べたネットワーク監視装置１０１は、コンピュータ装置であって、図３８に示すように、メモリ２５０１とＣＰＵ（Central Processing Unit）２５０３とハードディスク・ドライブ（ＨＤＤ：Hard Disk Drive）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。ＣＰＵ２５０３は、アプリケーション・プログラムの処理内容に応じて表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ２５０１に格納されるが、ＨＤＤ２５０５に格納されるようにしてもよい。本発明の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

以上述べた本発明の実施の形態をまとめると、以下のようになる。

本実施の形態に係るパケット保存方法は、ネットワークからキャプチャしたパケットの各々に第１識別子を割り当てると共に、当該パケットの各々をバッファに格納する処理と、第１識別子の各々に、当該第１識別子に係るパケットのコネクションを特定する第２識別子を対応付ける処理と、パケットの解析によって異常が生じているコネクションを検出する処理と、異常が生じているコネクションの第２識別子が対応付けられている複数の第１識別子を特定し、特定した当該複数の第１識別子の各々が割り当てられているパケットをバッファから収集し、収集した複数の当該パケットを記憶部に格納する格納処理とを含む。

このようにすれば、異常コネクションを事後的に解析する為のデータ保存量を少なくすることができる。

上記格納処理において、異常が生じているコネクションを検出した時よりも所定期間遡った時以降にバッファに格納されたパケットのうちから、収集すべきパケットを選択するようにしてもよい。

このようにすれば、異常が生じる前にキャプチャしたパケットも保存できる。例えば、異常が発生する前のコネクションの状態を把握することに役立つ。

上記パケット保存方法は、更に、異常の解消を検出する処理を含むようにしてもよい。また、上記格納処理において、異常の解消を検出した時までにバッファに格納されたパケットのうちから、収集すべきパケットを選択するようにしてもよい。

このようにすれば、異常が解消するまでにキャプチャしたパケットを保存できる。例えば、コネクションにおける異常解消の過程を把握することに役立つ。

上記パケット保存方法は、更に、記憶部における記憶状態に応じて、異常の種別を特定する処理を含むようにしてもよい。

このようにすれば、記憶部の記憶状態に応じてデータ保存量を加減できる。

なお、上記方法による処理をコンピュータに行わせるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納されるようにしてもよい。尚、中間的な処理結果は、一般的にメインメモリ等の記憶装置に一時保管される。

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）
ネットワークからキャプチャしたパケットの各々に第１識別子を割り当てると共に、当該パケットの各々をバッファに格納する処理と、
前記第１識別子の各々に、当該第１識別子に係るパケットのコネクションを特定する第２識別子を対応付ける処理と、
前記パケットの解析によって異常が生じているコネクションを検出する処理と、
前記異常が生じているコネクションの第２識別子が対応付けられている複数の第１識別子を特定し、特定した当該複数の第１識別子の各々が割り当てられているパケットを前記バッファから収集し、収集した複数の当該パケットを記憶部に格納する格納処理と
を含み、コンピュータにより実行されるパケット保存方法。

（付記２）
前記格納処理において、
前記異常が生じているコネクションを検出した時よりも所定期間遡った時以降に前記バッファに格納されたパケットのうちから、収集すべき前記パケットを選択する
付記１記載のパケット保存方法。

（付記３）
更に、前記異常の解消を検出する処理を含み、
前記格納処理において、前記異常の解消を検出した時までに前記バッファに格納された前記パケットのうちから、収集すべき前記パケットを選択する
付記１又は２記載のパケット保存方法。

（付記４）
更に、前記記憶部における記憶状態に応じて、前記異常の種別を特定する処理
を含む付記１乃至３のいずれか１つ記載のパケット保存方法。

（付記５）
ネットワークからキャプチャしたパケットの各々に第１識別子を割り当てると共に、当該パケットの各々をバッファに格納する処理と、
前記第１識別子の各々に、当該第１識別子に係るパケットのコネクションを特定する第２識別子を対応付ける処理と、
前記パケットの解析によって異常が生じているコネクションを検出する処理と、
前記異常が生じているコネクションの第２識別子が対応付けられている複数の第１識別子を特定し、特定した当該複数の第１識別子の各々が割り当てられているパケットを前記バッファから収集し、収集した複数の当該パケットを記憶部に格納する格納処理と
をコンピュータに実行させるためのパケット保存プログラム。

（付記６）
ネットワークからキャプチャしたパケットの各々に第１識別子を割り当てると共に、当該パケットの各々をバッファに格納する第１格納処理部と、
前記第１識別子の各々に、当該第１識別子に係るパケットのコネクションを特定する第２識別子を対応付ける対応付け部と、
前記パケットの解析によって異常が生じているコネクションを検出する検出部と、
前記異常が生じているコネクションの第２識別子が対応付けられている複数の第１識別子を特定し、特定した当該複数の第１識別子の各々が割り当てられているパケットを前記バッファから収集し、収集した複数の当該パケットを記憶部に格納する第２格納処理部と
を含み、コンピュータにより実行されるパケット保存装置。

１０１ ネットワーク監視装置 １０３ 監視対象ネットワーク
１０５ ネットワークタップ １０７ 伝送ネットワーク
１０９ ストレージ装置 １１１ ＮＩＣ
１１３ ドライバ １１５ パケットバッファ
１１７ 解析部 １１９ 統計部
１２１ コネクションテーブル記憶部 １２３ インデックスバッファ
１２５ 異常テーブル記憶部 １２７ 格納処理部
１３１ Ｌ４解析部 １３３ Ｌ７解析部
１３５ Ｌ４統計部 １３７ Ｌ７統計部
１４１ 統計データ記憶部 １４３ 保存データ記憶部
３０１ リングバッファ ９０１ 記憶部
９０３ 受付部 ９０５ コネクションテーブル生成部
９０７ インデックス生成部 ９０９ 異常テーブル生成部
１４０１ 読取部 １４０３ インデックステーブル記憶部
１４０５ 判定部 １４０７ 保存データ生成部
１４０９ 一時記憶部 １４１１ 収集データ記憶部
１４１３ メタデータ記憶部 １４１５ 書込部
１５０１ インデックステーブル １８０１ 収集データセット
１８０３ 収集データ ２１０１ オブジェクト
２１０３ メタデータセット ２１０５ メタデータ
２１０７ 上位メタデータ ２７０１ 集計データ記憶部
２７０３ ポリシーデータ記憶部 ３４０１ バッファテーブル

Claims (4)

1. ネットワークからキャプチャしたパケットの各々に第１識別子を割り当てると共に、当該パケットの各々をバッファに格納する処理と、
   前記第１識別子の各々に、当該第１識別子に係るパケットのコネクションを特定する第２識別子を対応付ける処理と、
   前記パケットの解析によって現在異常が生じているコネクションを検出する処理と、
   逐次、現在から所定時間遡った過去において前記バッファに格納された前記パケットを、保存対象であると判定する処理と、
   前記保存対象であって、前記現在異常が生じているコネクションの第２識別子に対応する前記第１識別子で特定されるパケットを、記憶部に格納する格納処理と
   を含み、コンピュータにより実行されるパケット保存方法。
2. 更に、前記記憶部における記憶状態に応じて、前記異常の種別を特定する処理
   を含む請求項１記載のパケット保存方法。
3. ネットワークからキャプチャしたパケットの各々に第１識別子を割り当てると共に、当該パケットの各々をバッファに格納する処理と、
   前記第１識別子の各々に、当該第１識別子に係るパケットのコネクションを特定する第２識別子を対応付ける処理と、
   前記パケットの解析によって現在異常が生じているコネクションを検出する処理と、
   逐次、現在から所定時間遡った過去において前記バッファに格納された前記パケットを、保存対象であると判定する処理と、
   前記保存対象であって、前記現在異常が生じているコネクションの第２識別子に対応する前記第１識別子で特定されるパケットを、記憶部に格納する格納処理と
   をコンピュータに実行させるためのパケット保存プログラム。
4. ネットワークからキャプチャしたパケットの各々に第１識別子を割り当てると共に、当該パケットの各々をバッファに格納する第１格納処理部と、
   前記第１識別子の各々に、当該第１識別子に係るパケットのコネクションを特定する第２識別子を対応付ける対応付け部と、
   前記パケットの解析によって現在異常が生じているコネクションを検出する検出部と、
   逐次、現在から所定時間遡った過去において前記バッファに格納された前記パケットを、保存対象であると判定する判定部と、
   前記保存対象であって、前記現在異常が生じているコネクションの第２識別子に対応する前記第１識別子で特定されるパケットを、記憶部に格納する第２格納処理部と
   を含むパケット保存装置。

Images