JP5958348B2 - 分析方法、分析装置、及び分析プログラム - Google Patents

Description

本発明は、分析方法、分析装置、及び分析プログラムに関する。

アプリケーションプログラムやネットワークサービス等において、遅延個所や異常個所を発見することが試みられている（例えば、下記の特許文献１及び２参照）。

通常、遅延や個所や異常個所を発見するためには、その箇所の前後のログを採取して、状態を監視し続ける必要がある。例えばstart-A-B-C-D-endという処理シーケンスの場合、Aの直前、A-Bの中間、B-Cの中間、C-Dの中間、Dの直後、でタイムスタンプが付いたログを採取することで、A〜Dの各処理の遅延を見つけることができる。例えばBが遅延している場合、A-B間のログ（Bの直前）とB-C間のログ（Bの直後）＝Bの前後のログ、を使うことで遅延を発見することができる。

その一方で、アプリケーションプログラムやネットワークコンポーネントにおいて異常個所を発見するためには多数の監視箇所で大量のログを採取する必要がある。

このため、異常個所の絞り込み、特定には多大な実行オーバーヘッド及びネットワーク負荷が発生する。

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

こうしたアプリケーションプログラムやネットワークコンポーネントでは、複数の処理で共通のモジュールを使用した処理を行なう。

ここで、特定のモジュールの遅延は、関連する複数の処理で遅延を引き起こす原因となる。遅延しているモジュールの特定は、例示的に、一定の時間間隔でレスポンス時間の平均をとり、その平均値を正常又は異常の閾値と比較し、その比較結果に基づいて正常動作している処理と遅延している処理とを分類することで実施できる。

しかしながら、処理時間を平均する区間の長さやタイミング等の取り方によって、本来異常と診断したい処理が正常な処理に分類されてしまったり、問題を特定するために必要な情報が得られない等、分析の基礎となる適切なデータを得られない場合がある。

１つの側面では、本発明は、計算量を抑えて分析可能なデータを見つけることを可能にすることで、分析精度を向上することを目的とする。

分析方法の一態様は、共用するモジュールが存在する複数の処理それぞれについて、正常及び異常のステートをログデータより算出し、前記ステートの変化のタイミングを算出し、算出した前記タイミングに基づき、前記複数の処理それぞれについて正常及び異常のステートが混在しない時間区間を区切り、前記時間区間において、前記複数の処理と前記モジュールとの関係の情報に基づき、異常モジュールを検出する。

一態様によれば、計算量を抑えて分析可能なデータを見つけることを可能にすることで、分析精度を向上することができる。

一実施形態に係るネットワークシステムの一例を示すブロック図である。 一実施形態に係る機能とコンポーネントとの関係の一例を示す図である。 （Ａ）〜（Ｄ）は一実施形態に係る機能とコンポーネントとの関係をマトリクスで表現した例を示す図である。 一実施形態に係る分析フェーズの動作例を説明するフローチャートである。 一実施形態に係る運用フェーズの動作例を説明するフローチャートである。 図４に例示する紐付け処理を一例を説明するフローチャートである。 図４に例示する紐付け処理の一例を模式的に説明する図である。 一実施形態に係る運用フェーズの分析結果の通知画面例を示す図である。 一実施形態に係る遅延検知時の通知画面例を示す図である。 一実施形態に係る機能毎の集計区間に正常と異常なデータとが混在する様子を模式的に示す図である。 図１０において集計区間を極小化する場合の問題例を模式的に説明する図である。 図１０において正常区間と異常区間とを分離して、重なりで判定する様子を模式的に説明する図である。 一実施形態に係る事務処理システムの事例を説明する図である。 図１３に例示する事務処理システムでの異常発症例を模式的に説明する図である。 一実施形態に係る分析方法を事務処理システムに適用した場合を模式的に説明する図である。 一実施形態に係る事前準備処理を説明するフローチャートである。 一実施形態に係る運用フェーズでの動作例を説明するフローチャートである。 一実施形態においてリクエスト−レスポンスデータ（ＲＲデータ）の単位を判定区間とする様子を例示する図である。 一実施形態において正常のＲＲデータをまとめて正常区間とし、異常のＲＲデータをまとめて異常区間とする様子を例示する図である。 一実施形態において正常区間及び異常区間の切り替わりのＲＲデータがない区間をデータなしとして扱う様子を例示する図である。 一実施形態において正常区間及び異常区間の切り替わりのＲＲデータがない区間をデータなしとして扱う様子を例示する図である。 一実施形態において正常区間及び異常区間の切り替わりの次のＲＲデータが出現したタイミングで区間を切り替える様子を例示する図である。 一実施形態において同一種別のＲＲデータの最後のＲＲデータの終了タイミングで区間を切り替える様子を例示する図である。 一実施形態において正常ＲＲデータ群及び異常ＲＲデータ群の中間地点で切り替える様子を例示する図である。 一実施形態においてＲＲデータが重なり合う場合の様子を例示する図である。 一実施形態において同一種別のＲＲデータの開始から終了までを１つの正常区間または異常区間とする様子を例示する図である。 一実施形態において異なる種別の次のＲＲデータの開始時点（出現タイミング）で区間を区切る様子を例示する図である。 一実施形態において異なる種別のＲＲデータの出現時に、前の種別の最後のＲＲデータの終了タイミングで区間を区切る様子を例示する図である。 一実施形態において正常のＲＲデータの開始時に正常区間として切り、正常のＲＲデータの終了時に区間を区切る様子を例示する図である。 （Ａ）及び（Ｂ）は一実施形態において異なるタイミングで一部の機能のＲＲデータが出現しない様子を比較して例示する図である。 （Ａ）及び（Ｂ）は一実施形態において異なるタイミングでＲＲデータが１つのみ出現する場合と複数出現する場合を比較して例示する図である。 （Ａ）〜（Ｃ）は一実施形態に係る具体的な競合と暗黙の競合とを模式的に説明する図である。 一実施形態に係る機能とコンポーネントとの関係の一例を示す図である。 一実施形態において補完テーブル（排他ポイントテーブル）を作成するフローチャートである。 （Ａ）及び（Ｂ）は一実施形態に係るパス情報テーブル及び排他ポイントテーブルの一例を示す図である。 一実施形態に係る補完フローチャートである。 一実施形態に係る機能とコンポーネントとの関係の一例を示す図である。 一実施形態に係る頻度情報（テーブル）の一例を示す図である。 一実施形態に係る機能選別処理の一例を説明するフローチャートである。 一実施形態に係る機能とコンポーネントとの関係の一例を示す図である。 一実施形態に係る頻度情報（テーブル）の一例を示す図である。 一実施形態に係る頻度情報（テーブル）の一例を示す図である。

以下、図面を参照して本発明の実施の形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、以下に明示しない種々の変形や技術の適用を排除する意図はない。なお、以下の実施形態で用いる図面において、同一符号を付した部分は、特に断らない限り、同一若しくは同様の部分を表す。

図１は、一実施形態に係るネットワークシステムの一例を示すブロック図である。図１に示すネットワークシステムは、例示的に、インターネット等のネットワーク１０、ネットワーク１０に接続されたサーバ群２０，３０及び４０、並びに、ネットワークスイッチ５０等を備える。サーバ群２０，３０及び４０には、例示的に、Ｗｅｂサーバ３０や、アプリケーション（ＡＰ）サーバ４０、その他のサーバ２０等が含まれる。

ＡＰサーバ４０には、例示的に、事前分析ブロック４０１、運用ブロック４０２、ユーザリクエストデータベース４０３、及び、パス情報データベース４０４が備えられる。オプション的に、ＡＰサーバ４０には、出現確率データベース４０５が備えられてもよい。

ＡＰサーバ４０は、図示しないＣＰＵ、メモリ、及び、ハードディスク装置等の記憶装置、表示装置、印刷装置等を備えている。ＣＰＵがメモリや記憶装置から所定のプログラムを読み取って動作することにより、必要な機能部が具現される。例示的に、プログラムには、事前分析ブロック４０１や運用ブロック４０２の機能を具現するプログラムの一例としての分析プログラムが含まれる。表示装置や印刷装置には、例えばＣＰＵによる演算結果等を出力することができる。なお、他のサーバ２０やＷｅｂサーバ３０についても、ハードウェア的には、ＣＰＵ、メモリ、及び、ハードディスク装置等の記憶装置、表示装置、印刷装置等が備えられる。

分析プログラムとしての機能（各手段の全部又は一部の機能）は、ＣＰＵ等のコンピュータが所定のアプリケーションプログラムを実行することによって実現される。

そのプログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＣＤ−ＲＷ，ＭＯ，ＤＶＤ、ブルーレイディスク、ポータブルハードディスク、ＵＳＢメモリ等のコンピュータ読取可能な記録媒体に記録された形態で提供される。この場合、コンピュータはその記録媒体から上記プログラムを読み取って内部記憶装置または外部記憶装置に転送し格納して用いる。また、そのプログラムを、例えば磁気ディスク，光ディスク，光磁気ディスク等の記憶装置（記録媒体）に記録しておき、その記憶装置から通信回線を介してコンピュータに提供するようにしてもよい。

ここで、コンピュータとは、ハードウェアとＯＳ（オペレーティングシステム）とを含む概念であり、ＯＳの制御の下で動作するハードウェアを意味している。また、ＯＳが不要でアプリケーションプログラム単独でハードウェアを動作させるような場合には、そのハードウェア自体がコンピュータに相当する。ハードウェアは、少なくとも、ＣＰＵ等のマイクロプロセッサと、記録媒体に記録されたプログラムを読み取るための手段とをそなえている。

上記アプリケーションプログラムは、上述のようなコンピュータに、分析プログラムとしての機能を実現させるプログラムコードを含んでいる。また、その機能の一部はアプリケーションプログラムではなくＯＳによって実現されてもよい。

さらに、上記記録媒体としては、上述したフレキシブルディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＣＤ−Ｒ，ＣＤ−ＲＷ，ＤＶＤ，磁気ディスク，光ディスク，光磁気ディスクのほか、ＩＣカード，ＲＯＭカートリッジ，磁気テープ，パンチカード，コンピュータの内部記憶装置（ＲＡＭやＲＯＭ等のメモリ），外部記憶装置等や、バーコード等の符号が印刷された印刷物等の、コンピュータ読取可能な種々の媒体を利用することもできる。

ユーザリクエストデータベース４０３や、パス情報データベース４０４、出現確率データベース４０５は、例示的に、ＡＰサーバ４０のメモリや記憶装置において具現される。

事前分析ブロック４０１は、例示的に、事前データ採取部４１０及びパス分析部４２０を備える。

事前データ採取部４１０は、ユーザリクエストデータベース４０３のデータ（リクエスト等）を仮想ユーザのデータとしてネットワーク１０へ投入（送信）する。なお、事前データ採取部４１０は、実運用時の実際のリクエスト及び状態等を保存しておいて、実運用時の運用状態を再現するようにしてもよい。

パス分析部４２０は、例示的に、仮想ユーザのデータ投入による結果として各サーバ２０，３０，４０に流れるメッセージデータを採取して、パス分析を行ない、その分析結果を例えばパス情報としてパス情報データベース４０４に格納する。

運用ブロック４０２は、例示的に、運用データ採取部４３０、機能選別部４４０、データスライス分割部４５０、及び問題箇所特定部４６０を備える。

運用データ採取部４３０は、運用フェーズにおいて実運用でサーバ２０，３０，４０に流れるデータから例えばＵＲＬ（Uniform Resource Locator）＋ＣＧＩ（Common Gateway Interface）パラメータ等を例えばログデータとして採取する。なお、実運用では「前面のサーバ」の情報のみ採取するようにしてよい。「前面のサーバ」とは、事前分析フェーズにおける「全サーバ」と対比して、ユーザからのリクエストを受け付ける、最もユーザ側のサーバを意味する。図１に例示する構成ではＷｅｂサーバ３０が「前面のサーバ」サーバに相当し得る。ただし、構成によっては、負荷分散サーバ（ロードバランサ；図示省略）が「前面のサーバ」に相当することもあれば、ＡＰサーバ４０が「前面のサーバ」に相当することもある。

機能選別部４４０は、採取したログデータをパス情報データベース４０４のパス情報と照らして、ログデータの機能選別（分類）を行なう。

データスライス分割部４５０は、選別した各機能で正常と異常とが混在しない時間区間を切り出す処理（ステートの変化タイミングを演算する処理）を実施する。詳細については後述する。

問題個所特定部４６０は、データスライス分割部４５０によって切り出された時間区間について遅延の検知を行い、遅延を検知した場合はパス情報と照らして問題個所を絞り込みあるいは特定する。

ここで、「機能」（あるいは「処理」）は、次のように分類される。
まず、予めキャプチャ済みの実データや事前データ採取部４１０がテストデータを再現（リプレイ）するなどしてデータを採取し、システムの各機能のパスをパス分析部４２０が分類する。

例えば図２に示すように、ｐ１〜ｐ５をネットワークコンポーネントとした場合、各コンポーネントｐ１〜ｐ５を流れるメッセージデータを分析し、ＵＲＬ＋ＣＧＩパラメータで機能（Ｆｉ：ｉは自然数）を分類する。すると、各機能は次のようなパスを通ることが分かる。なお、コンポーネントｐ１〜ｐ５はプログラムのメソッド単位、ブロック単位として処理することもできる。「コンポーネント」という用語は、「モジュール」あるいは「チェックポイント」という用語に置き換えて使用する場合がある。また、「パス」は、「コンポーネント」の集合として位置付けられる。

Ｆ１＝http://foo.com/appli1.cgi?flag=exec パス＝ｐ１−ｐ２−ｐ４−ｐ５
Ｆ２＝http://foo.com/appli1.cgi?flag=calc パス＝ｐ１−ｐ３−ｐ５
Ｆ３＝http://foo.com/appli1.cgi?data=true パス＝ｐ１−ｐ２
Ｆ４＝http://foo.com/appli2.cgi?feature=3 パス＝ｐ３−ｐ４

ここで、通常時に比べてＦ１及びＦ２が遅延した場合、問題個所特定部４６０は、分析したパス情報に照らすことでＦ１とＦ２とが通過するパス（チェックポイント）であるｐ１，ｐ２，ｐ３，ｐ４，ｐ５（つまり、この例の場合は全てのチェックポイント）が問題（異常）の可能性をもつと判断することができる。

さらに、例えば、Ｆ３及びＦ４は遅延していないという情報と、Ｆ３及びＦ４のパス情報により、Ｆ１，Ｆ２及びＦ３の共通パスであるｐ１，ｐ２，ｐ３，ｐ４には問題がないと判断できる。その結果、残ったｐ５を遅延の原因と診断することができる。

なお、分析対象がプログラムの場合、ｐ１〜ｐ５は、例示的に以下のように、メソッド（関数）呼出し単位や、ブロック単位、利用者指定のログ出力箇所単位、あるいはこれらのいずれかの組み合わせを単位として処理することができる。

・メソッド（関数）呼出し単位
ｐ１＝method1()→ｐ２＝method2()→ｐ４＝method3()等
・ブロック単位（ｉｆ文や｛｝などで区分けされたブロック）
ｐ１＝while(..)→ｐ２＝if ()...→ｐ４=else...等
・利用者指定のログ出力箇所
ｐ１＝{file=foo.java,line=35}→ｐ２＝{file=foo.java,line=55}→ｐ４＝{file=boo.java,line=20}等

パス情報は、単純な例としては図３（Ａ）に示すように各機能Ｆ１〜Ｆ４とチェックポイントｐ１〜ｐ５とをマトリクスで表現することができる。なお、マトリクス表現は分析フェーズでの処理の一例である。

図３（Ｂ）に例示するように、悪化した機能（図２の例でＦ１及びＦ２）のチェックポイントを論理和（ＯＲ）で検出する。次いで、図３（Ｃ）に例示するように、悪化していない機能（図２の例でＦ３及びＦ４）のチェックポイントをＯＲで検出する。

さらに、図３（Ｄ）に例示するように、図３（Ｂ）の結果と図３（Ｃ）の結果とで排他的論理和（ＸＯＲ）をとる。次いで、図３（Ｂ）の結果と図３（Ｄ）の結果とで論理積（ＡＮＤ）をとる。本例において当該ＡＮＤの結果は図３（Ｄ）と同じである。図３（Ｄ）に例示するように、ＡＮＤの結果により、「１」が残っているｐ５が問題個所と特定できる。

（分析フェーズ）
図４に例示するように、分析フェーズ（分析ブロック４０１）では、２つの機能を並行して実行することができる。

まず、分析ブロック４０１では、事前データ採取部４１０により、ユーザリクエストデータベース４０３において予め用意したリクエストデータを再生することでサーバ２０，３０及び４０にリクエストメッセージを投入する（データ再生：処理P１０）。当該処理は、所定の終了条件が満たされるまで（処理P２０でＹｅｓと判定されるまで）、繰り返される（処理Ｐ２０のＮｏルート）。なお、リクエストデータとしては、実運用時に採取したものや、テストデータとして生成したもの等を用いることができる。

事前データ採取部４１０は、データ再生でのデータ投入により呼び出されるネットワークデータをキャプチャしたり、サーバ２０，３０，４０のログデータを取得したりする等して、データを取得する（処理Ｐ３０）。

次いで、分析ブロック４０１は、例えばパス分析部４２０により、取得したデータを紐付け処理して、パス情報を生成する（処理Ｐ４０）。ここで、紐付け処理の一例を図６及び図７に示す。

図６に例示するように、パス分析部４２０は、紐付け処理対象のデータの有無をチェックし（処理Ｐ４１０）、データが無ければデータが出現するまで待機し（処理Ｐ４１０のＮｏルート）、データが有ればデータの種別（アプリケーションやデータベース等）を選別する（処理Ｐ４１０のＹｅｓルートから処理Ｐ４２０）。

次いで、パス分析部４２０は、選別した種別毎に一次紐付け処理を実施する（処理Ｐ４３０）。さらにパス分析部４２０は、トランザクション終了か否かをチェックする（処理Ｐ４４０）。ここで、構成する全データ種別のデータが揃った場合はトランザクション終了と判定し（処理Ｐ４４０のＹｅｓルート）、パス分析部４２０は、構成する全データ種別のデータを、識別キーを使って二次紐付け処理する（処理Ｐ４５０）。なお、トランザクション終了と判定されるまでは、処理Ｐ４１０以降の処理が繰り返される（処理Ｐ４４０のＮｏルート）。

図７に、一次紐付け処理及び二次紐付け処理の一例を示す。図７の下段左には、アプリケーション（ＡＰ）のデータ例として、タイムスタンプ、トランザクションＩＤ及びその他の情報を含むデータ構造を示している。また、図７の下段右には、データベース（ＤＢ）のデータ例として、タイムスタンプ、セッションＩＤ、その他の情報及びトランザクションＩＤを含むデータ構造を示している。

図７の上段には、図７の下段に例示するデータがデータの種別毎に選別された様子を例示している。また、図７の上段に例示するように、ＡＰのデータは、ＡＰに固有の選別キー（例えばトランザクションＩＤ（ｔ０１，ｔ０２等））にて一次紐付けされ、ＤＢのデータは、ＤＢに固有の選別キー（例えばセッションＩＤ（ｓ３４，ｓ３５等））にて一次紐付けされる。

そして、異なる種別のデータどうしは、識別キー（例えばトランザクションＩＤ（ｔ０１，ｔ０２等））にて二次紐付けされる。なお、全てのデータが二次紐づけに必要な識別キーを有しているとは限らない。

二次紐付けが完了すると、パス分析部４２０は、紐付け結果を登録（記憶）する（処理Ｐ４６０）。

このような紐付け処理が完了すると、パス分析部４２０は、図４に例示するように、機能抽出処理を実施する（処理Ｐ５０）。機能抽出処理は、上述した紐付け結果とＵＲＬ＋ＣＧＩパラメータとから機能を抽出し分類する処理の一例である。

そして、パス分析部４２０は、分類結果をパス情報としてパス情報データベース４０４に登録する（処理Ｐ６０）。なお、後述するように、問題個所特定の精度向上のために出現確率（頻度）情報を使う方法が考えられる。その場合、パス分析部４０５は、出現確率情報を出現確率情報データベース４０５（図１参照）に格納する。

（運用フェーズ）
次に、図５を参照して運用フェーズでの処理例について説明する。

運用フェーズ（運用ブロック４０２）では、運用データ採取部４３０により、実運用データのうちＵＲＬ＋ＣＧＩパラメータ、レスポンス時間等の情報をネットワークスイッチ５０やＷｅｂサーバ３０から採取する（処理Ｐ１００）。

次いで、運用ブロック４０２は、機能選別部４４０により、採取したデータからＵＲＬ、ＣＧＩ等のパラメータを基に機能単位を選別する（処理Ｐ１１０）。

さらに、運用ブロック４０２は、データスライス分割部４５０により、機能の抽出処理、すなわち、選別した各機能で正常と異常とが混在しない時間区間を切り出す処理（ステートの変化タイミングを演算する処理）を実施する（処理Ｐ１２０）。なお、選別した機能がパス情報に含まれない場合は、パス情報の機能に当てはめる。

その後、データスライス分割部４５０は、機能及びレスポンス情報を集計情報として分析対象データテーブル（図示省略）に登録（記憶）する（処理Ｐ１３０）。登録形式の一例は次表１に例示するとおりである。

上記表１の例では区間ＩＤで識別される区間にデータが出現したエントリが登録されている。Ｆ３はその区間にデータが存在しなかったことを表現している。なお、区間ＩＤと対応する区間情報は、例示的に、次表２に例示するような別のテーブル（区間テーブル）で管理することができる。区間の長さは、スライス毎に異なり得る。

次いで、運用ブロック４０２は、問題個所特定部４６０によって、レスポンスが悪化しているかを判定する（処理Ｐ１４０）。判定は、単独レスポンスや集計単位毎等の単位で行なうことができる。

レスポンスが悪化していなければ、運用ブロック４０２は、処理Ｐ１００以降の処理を繰り返す（処理Ｐ１４０のＮｏルート）。一方、レスポンスが悪化していれば（処理Ｐ１４０でＹｅｓの場合）、問題個所特定部４６０は、集計情報とパス情報とを突き合わせることで問題個所の特定を行なう（処理Ｐ１５０）。

問題個所の特定ができれば（処理Ｐ１６０のＹｅｓルート）、問題個所特定部４６０は、特定した問題個所の情報を表示装置等に出力する（処理Ｐ１７０）。このとき、複数の候補がある場合は例えば優先順位付で複数個出力してよい。ただし、優先順位がつかない場合もある。

出力データの一例を図８に示す。図８の左側には、実運用フェーズでの分析結果の通知画面５００の一例が示されている。通知画面５００には、例示的に、遅延が発生した日時、推定される遅延個所等の情報が表示される。

ここで、遅延個所についてのより詳細な情報が知りたい場合には、例えば通知画面５００に設けられた詳細表示ボタン５０１を選択することで、図８の右側に例示するような詳細表示画面５１０を表示できる。詳細表示画面５１０にも、表示する情報に対応して詳細表示ボタン５１１〜５１５を配置することができる。詳細表示画面５１０において更に詳細な情報が知りたい場合に対応する詳細表示ボタン５１１〜５１５を選択することで、更に詳細な情報を表示させることができる。

問題個所の特定ができなかった場合（処理Ｐ１６０のＮｏルート）、問題個所特定部４６０は、悪化を検知したことを表示装置等に出力する（処理Ｐ１８０）。図９に、遅延検知時の通知画面５２０の一例を示す。通知画面５２０には、例示的に、遅延発生を検知した日時、遅延発生を検知した機能（ＵＲＬ等）等の情報が表示される。

通知画面５２０には、遅延発生を検知した機能に対応して詳細表示ボタン５２１及び５２２を配置することができる。詳細表示ボタン５２１又は５２２を選択することで、より詳細な情報、例えば、レスポンス時間の平均等を表示させることができる。

次に、正常と異常のデータが混在する場合の問題について図１０及び図１１を参照して説明する。

図１０及び図１１において、「異常区間」は異常なデータの時間区間を例示し、「正常区間」は正常なデータの時間区間を例示している。「異常なデータ」は、例えばレスポンス時間が正常範囲よりも長いことを示すデータを意味し、「正常なデータ」は、例えばレスポンス時間が正常範囲にあることを示すデータを意味する。

ここで、同じ機能でもタイミングによって正常なデータと異常なデータとが混在する場合があり、その場合には、既述のマトリックスを使った絞り込みを行なえない。

例えば、レスポンス時間の閾値が１秒（１秒以上なら異常、１秒未満なら正常）の場合、平均すると丁度１秒、を異常と判定（例えば図１０の矢印６０１参照）しても正確な分析であるとはいえない。このように、微妙なタイミングによる問題がある場合に、平均では正常及び異常のいずれかの判定結果となってしまい正しく判定できない。また、複数の機能（Ｆ１，Ｆ２，…）のレスポンス時間が全て閾値近傍にある場合は分析結果が全く信用できないものになる。

なお、特許文献１の手法は、ネットワーク機器異常の検知なので、正常時と異常時とがはっきり分かれる（正常／異常データの混在を考えない)。

そこで、本実施形態では、正常及び異常のステートが混在しない領域（時間区間）を自動的に切り出すことで絞り込みを可能にする。

基本的な処理の一例としては、まず、各ＵＲＬで正常及び異常のステートの変化のタイミングを演算し、当該タイミングに基づき、各ＵＲＬで正常及び異常のステートが混在しない時間区間を区切る。そして、各時間区間が重なり合う範囲で、マトリックスを作って演算（複数の処理（あるいは機能）とモジュールとの「関係の情報」に基づき、問題個所となっている異常モジュールを算出（検出））する。

なお、「関係の情報」は、適宜に更新されてよい。例えば、実運用フェーズにおけるリクエストデータをユーザリクエストデータベース４０３に保存しておき、事前分析フェーズで出現しなかった未知のデータが実運用フェーズで出現した場合は、保存しておいたリクエストデータを用いて再事前分析を実施することで、「関係の情報」を更新する。

ところで、１つのＵＲＬで正常及び異常のステートが混在しない区間を複数のＵＲＬで切り出すと、細切れになり過ぎて組み合わせ（計算時間）が膨大になってしまう。そこで、以下の（ａ）〜（ｃ）に例示する処理のうち、（ａ）のみ、または（ａ）＋（ｂ）、（ａ）＋（ｃ）、若しくは（ａ）＋（ｂ）＋（ｃ）により異常個所の絞り込みを行なう。

（ａ）異常を含まないスライスを除外する。
（ｂ）より多くのポイント（コンポーネント）を含むスライスを選択して演算〔例えば、ＵＲＬが利用するコンポーネントは既知（分析済み）なので、組み合わせにより、より多くのコンポーネントを網羅するスライスを選択する。どのＵＲＬの組合せを抑えておけば大部分のコンポーネントを網羅できるか、ということを予め計算して組合せの候補を用意しておく〕。
（ｃ）より多くのＵＲＬを網羅するスライスを選択して演算する。

（集計区間を極小化する解決方法）
集計区間を調整することで当該演算を適用可能にしたいが、単に集計区間を短くするだけでは、有効なデータを見つけることができない。なぜなら、集計区間を短くしすぎると同時に出現する機能（ＵＲＬ）が少ないために有効な分析にならず、また、時間幅を変えながら様々な時間幅で分析に適したデータを探すと、組み合わせが爆発して計算量の見積もりができない状態になるからである。

例えば図１１に符号６０２で示すように、集計区間を短くした場合、判定に必要なデータ（この場合、Ｆ１，Ｆ２，Ｆ３及びＦ４）のデータが揃わない。また、図１１に符号６０３で示すように、更に集計区間を短くして、当該集計区間をスライドしながら探索すれば、タイミングによっては分析に必要な区間が偶然見つかることもある。しかし、組み合わせは無限になり、計算時間が足りない。

（正常区間と異常区間とを分離して重なりで判定）
そこで、本実施形態では、例えば図１２に示すように、機能（例えばＵＲＬ）毎に正常区間と異常区間とを分けて、その区間を重ね合わせた領域を分析に使う、という工夫をする。これにより、計算量を抑えて分析可能なデータを見つけることが可能になり、分析精度が向上する。なお、図１２において、機能Ｆ１及びＦ４は時間的前後に同様な異常あるいは正常データが存在しているものとする。また、図１２には、機能Ｆ３のデータにより区間（判定区間）が２分割された様子を例示している。

（事務処理システムにおける事例）
事務処理システムの新サービス（航空券予約システム）提供で問題が発生した場合について図１３及び図１４を参照して説明する。

図１３には、以下のように機能（Ｆ１，Ｆ２及びＦ３）とパスとが設定された様子を例示している。
Ｆ１＝前清算パス＝ｐ１（旅費）−ｐ２（清算）−ｐ４（ＤＢ１）
Ｆ２＝後清算パス＝ｐ１（旅費）−ｐ３（予約照会）−ｐ５（ＤＢ２）−ｐ２（清算）−ｐ４（ＤＢ１）
Ｆ３＝航空券予約状況 パス＝ｐ１（旅費）−ｐ３（予約照会）−ｐ５（ＤＢ２）

システム運用当初は問題なかったが、１か月後にシステムのスローダウンが発生したとする。直接の原因は、予約照会（ｐ３）では全件探索を実行しており、また旅費の後清算（Ｆ３）では航空券予約の有無に関わらず予約照会（ｐ３）を実行しているため、航空券予約状況（Ｆ３）と後清算（Ｆ２）により予約照会（ｐ３）の負荷が上がったことであった。

運用者は後清算で航空券の予約照会（ｐ３）の負荷が急増することは想像できず、問題の切分けに長時間を要した。

（事務処理システムでの発症）
例えば図１４に例示するように、通常の集計区間では、Ｆ１＝正常、Ｆ２＝正常、Ｆ３＝異常、と分類されるため、分析が正しく行なわれない。仮に、Ｆ１＝正常、Ｆ２＝異常、Ｆ３＝異常、であれば判定することが可能である。

（本実施形態による診断）
・事前準備
まず、事前分析ブロック４０１のパス分析部４２０（図１参照）は、ＵＲＬ（＋引数)で業務及び／又は機能を分類（Ｆ１〜Ｆ３）し、分類した業務及び／又は機能毎にパス情報を設定する（図１６の処理P２１１及びP２１２）。例えば、以下のように、機能Ｆ１〜Ｆ３毎にコンポーネントｐ１〜ｐ５を設定する。

Ｆ１＝http://foo/... 前清算：ｐ１−ｐ２−ｐ３
Ｆ２＝http://boo/... 後清算：ｐ１−ｐ２−ｐ３−ｐ４−ｐ５
Ｆ３＝http://bar/... 航空券予約状況：ｐ１−ｐ３−ｐ５

・診断概要
Ｆ１が正常、Ｆ２及びＦ３が遅延の場合の異常コンポーネントを診断する。Ｆ２及びＦ３が異常の場合、Ｆ２及びＦ３のパス情報から、ｐ１，ｐ２，ｐ３，ｐ４，ｐ５（つまり、本例の場合は全てのコンポーネント）に異常の可能性をあると判断することができる。ここで、Ｆ１は正常なので、Ｆ１のパス情報からｐ１，ｐ２，ｐ４が異常の可能性を除外する。

その結果、ｐ３（予約照会）とｐ５（ＤＢ２）とが遅延の原因であると診断する。なお、診断により一次切分けした異常コンポーネントに対して、さらなる監視や分析等を自動実行することで、迅速な対応が可能になる。

図１７に実運用フェーズでの処理フローの一例を示す。
まず、データスライス分割部４５０が、パス毎に正常区間及び異常区間を分類し（処理P２２１）、各パスで正常区間と異常区間とが混在しない範囲で全区間のスライスを作成する（処理P２２２）。

次いで、問題個所特定部４６０（図１参照）が、スライスを順に処理する（処理P２２３）。まず、問題個所特定部４６０は、次のスライスがあるか否かをチェックし（処理P２２４）、次のスライスがあれば（処理P２２４でＹｅｓの場合）、当該スライスに異常区間があるか否かを判定する（処理Ｐ２２５）。異常区間があれば（処理Ｐ２２５でＹｅｓの場合）、問題個所特定部４６０は、異常区間を含むスライスのうち、コンポーネント網羅性の高いスライスを選択し（処理Ｐ２２６）、異常個所の絞込処理を実施する（処理Ｐ２２７）。

そして、問題個所特定部４６０は、絞込み度を更新し、より絞り込んだスライスを記録する（処理Ｐ２２８）。次いで、問題個所特定部４６０は、異常個所を特定できたか否かを判定し（処理Ｐ２２９）、特定できた場合（処理Ｐ２２９でＹｅｓの場合）、特定した異常個所の情報を表示装置等に表示する等の、通知処理を行なう（処理Ｐ２３０）。

なお、スライスに異常区間が含まれていない場合（処理Ｐ２２５でＮｏの場合）や、異常個所が特定できない場合（処理Ｐ２２９でＮｏの場合）は、いずれも処理は処理Ｐ２２３に移行する。また、次のスライスがなければ（処理Ｐ２２４でＮｏの場合）、通知処理が実施される。

（事務処理システムへの適用）
例えば図１５に示すように、正常区間と異常区間とを分類し、各機能の区間を重ね合わせて判定区間毎に判定を行なう。図１５の場合、「判定区間１」＝「正常，正常，異常」、「判定区間２」＝「正常，異常，異常」、「判定区間３」＝「正常，正常，異常」となる。この場合、「判定区間２」の領域（範囲）についての分析により、ｐ３（予約照会）及びｐ５（ＤＢ２）が問題個所として絞り込まれる。

（正常区間及び異常区間の分類方法）
正常区間及び異常区間は、まばらに存在する場合と互いに重なり合った場合とが考えられる。

（まばらな場合）
まばらな場合、以下の方式による分類が考えられる。

（方式１）リクエスト−レスポンスデータ（以下「ＲＲデータ」と表記する。）の単位を判定区間とする（図１８参照）。別言すると、ＲＲデータの区間＝正常区間または異常区間とする。なお、図１８において、矩形で示される正常区間あるいは異常区間のデータがＲＲデータに相当する。

（方式２）正常のＲＲデータをまとめて正常区間とし、異常のＲＲデータをまとめて異常区間とする（図１９参照）。方式１に比して、区間数を抑えることができるので、処理時間を軽減できる。ここで、図１９において、正常区間及び異常区間の切り替わりのＲＲデータなし区間をどちらに組み入れるかを判定する方式も幾つか考えられる（設定次第）。

（方式２−１）正常区間及び異常区間の切り替わりのＲＲデータがない区間は、正常でも異常でもなく「データなし」として扱う（図２０参照）。正常／異常を厳密に見つけたい場合は本方式２−１を使うとよい。

（方式２−１′）上記の方式２−１と同様であるが、正常区間及び異常区間の閾値を超えるＲＲデータなし期間については「データなし」として扱う（図２１参照）。「データなし」として扱う場合の閾値は、正常／異常ＲＲデータの平均値を使ってもよいし、正常／異常と判断する閾値時間を使ってもよい。

（方式２−２）正常区間及び異常区間の切り替わり（異なる種別（正常／異常））の次のＲＲデータが出現したタイミングで区間を切り替える（図２２参照）。

（方式２−３）同一種別の（正常／異常の種別が同じ）ＲＲデータの最後のＲＲデータの終了タイミングで区間を切り替える（図２３参照）。

（方式２−４）正常ＲＲデータ群及び異常ＲＲデータ群の中間地点で切り替える（図２４参照）。なお、中間地点は、非限定的な一例として、データなし区間の中央や、正常ＲＲデータの平均値で区切った地点等とすることができる。

基本的には、方式２−１または方式２−１′を使い、ＲＲデータの存在しない区間が長い場合は「データなし」、として扱うのが良い。なぜなら、あいまいな情報（データが存在しないのに正常として扱う）を元にマトリックスを使った特定処理を行なっても、正しい結果が得られないからである。ただし、あまりにＲＲデータが少なく、分析のために必要な区間情報が揃わない場合は、例えば閾値をゆるくすることにより、精度を犠牲にして特定処理を行なうようにしてもよい。

（重なり合った場合）
図２５に例示するように、ＲＲデータが重なり合う場合、基本的には、図２６に例示するように、同一種別のＲＲデータの開始から終了までを１つの正常区間または異常区間とする。

（方式１）異なる種別（正常／異常）の次のＲＲデータの開始時点（出現タイミング）で区間を区切る（図２７参照）。通常想定される事例では、何らかの原因（例えばＤＢのロック）により１つの処理に遅延が発生し、他の処理もその処理によって待たされることで同様に遅延する。本方式１は、元となった処理の遅延原因が解消されれば、残りの処理もすぐに終了し、その後のＲＲデータは正常になるとの想定に基づいている。

（方式２）異なる種別（正常／異常）のＲＲデータの出現時に、前の種別の最後のＲＲデータの終了タイミングで区間を区切る（図２８参照）。

（方式３）正常のＲＲデータの開始時に正常区間として切り、正常のＲＲデータの終了時に区間を区切る（図２９参照）。通常はこの方式３を使うとよい。正常のＲＲデータの終了時に区間を区切る理由は、異常はどの部分にあるか分からないが正常ＲＲデータの終了は、そこまで正常であったことの証左となるからである。正常ＲＲデータの開始時に区間を区切る理由は、正常ＲＲデータの開始は、そこから正常であったことの証左となるからである。

（バリエーション）
できるだけ多数のコンポーネントを網羅するタイミングを探すとよい。多数のコンポーネントが出現するほど絞り込みの度合いが高いからである。また、できるだけ多数の機能（例えばＵＲＬ種別）が集まるタイミングを探すとよい。パターンが多いほど絞り込みしやすいからである。

例えば、図３０（Ａ）に例示する或るタイミングＡでは一部の機能（Ｆ２）のＲＲデータが出現しないが、図３０（Ｂ）に例示する或るタイミングＢでは全ての機能（Ｆ１，Ｆ２，Ｆ３）のＲＲデータが出現する。この場合、タイミングＡよりもタイミングＢのＲＲデータを判定に用いるとよい。

また、同じ機能（例えばＵＲＬ）のＲＲデータが複数個出現するまで待つとよい。１つだけだと偶然かもしれないからである。例えば図３１（Ａ）に例示するタイミングＡでは、各機能Ｆ１，Ｆ２，Ｆ３のＲＲデータがそれぞれ１つだけ出現するが、図３１（Ｂ）に例示するタイミングＢでは各機能Ｆ１，Ｆ２，Ｆ３それぞれのＲＲデータが複数出現する。この場合、タイミングＡよりもタイミングＢのＲＲデータを用いるとよい。

（競合の可能性のある場所を通知する分析装置）
図３２（Ａ）に模式的に例示するように、遅延ＲＲデータと時間的に重なるＲＲデータを切り出して、切り出した範囲で問題個所の絞り込みを行なう。これは、統計値を使ったのでは瞬間的な競合の発生が検知できない、という考えに基づいている。

（具体的な競合を検知）
実際に問題個所として絞り込みができたものを通知する。図３２（Ｂ）には、ｐ５が具体的な競合個所である例を示している。

（暗黙の競合の検知）
共通の問題個所としては現れないが、問題発生時には高確率で同じように問題が発生する、という場所を暗黙の競合（競合していないはずだが裏で何かしら競合している）として通知する。これは、ある意味で短期分析と長期分析との組み合せに相当する。図３２（Ｃ）には、ｐ２及びｐ３が暗黙の競合個所である例を示している。

（競合可能性箇所の通知）
具体的な競合及び／又は暗黙の競合を含めて、競合可能性のある箇所として通知する。絞り込み度、同時発生確率等から確度をランク付けしてもよい。

（分析時の情報で補完し精度を向上）
分析フェーズの情報では絞り込みができない場合、このチェックポイントで問題なし（または悪化）が証明されれば特定できる、というポイントを抽出する。例えば図３３において、ｐ４及びｐ５のどちらが原因か特定したい場合、事前分析フェーズで使ったデータから、そのポイントを通るリクエストを投入する。ここで、ポイントから「候補リクエスト」を抽出する補完テーブル（インデックス）を用意しておくとより効率的である。

補完テーブルを作成するフローを図３４に例示する。
例えば、パス分析部４２０（図１参照）は、パス情報データベース４０４におけるパス情報（例えば図３５（Ａ）参照）に含まれるポイント（ｐ１，ｐ２，ｐ４，ｐ５）を全て走査し（処理Ｐ３１１）、ポイントが存在するか否かをチェックする（処理Ｐ３１２）。

チェックの結果、ポイントが存在すれば（処理Ｐ３１２でＹｅｓの場合）、パス分析部４２０は、現在注目しているポイント（キーポイント）（ｘ）を通る機能ＩＤを全て抽出する（処理Ｐ３１３）。例えば、図３３及び図３５（Ａ）において、キーポイントがｐ４であれば、機能Ｆ１及びＦ３が通るので、機能Ｆ１及びＦ３が抽出される。また、キーポイントがｐ１であれば、機能Ｆ１，Ｆ２，Ｆ２，Ｆ３及びＦ４が通るので、機能Ｆ１，Ｆ２，Ｆ２，Ｆ３及びＦ４が抽出される。

次いで、パス分析部４２０は、抽出した機能ＩＤ群が使うポイント（Ｙ）を全て抽出する（処理Ｐ３１４）。例えば、抽出された機能がＦ１及びＦ３であれば、ｐ１，ｐ２，ｐ３，ｐ４，ｐ５が抽出される。また、抽出された機能がＦ１，Ｆ２，Ｆ２，Ｆ３及びＦ４であれば、ｐ１，ｐ２，ｐ４及びｐ５が抽出される。

そして、パス分析部４２０は、機能ＩＤ（ａ）毎にポイントの組合せ（ｘ）−（Ｙ）で自機能（ａ）を通らないポイント（排他ポイント）（ｚ）があれば、（ｘ）との組み合わせをテーブルに出力し（処理Ｐ３１５）、処理Ｐ３１１に戻る。

例えば、機能Ｆ１で（Ｙ）＝ｐ１，ｐ２，ｐ４，ｐ５を通らないものはなく、機能Ｆ３で（Ｙ）＝ｐ１，ｐ２，ｐ４，ｐ５を通らないものはｐ５である。この場合、パス分析部４２０は、ｐ４，ｐ５，Ｆ３のレコードをテーブルに出力する。当該レコードは、ｐ４を通るがｐ５を通らないものは機能Ｆ３であることを意味する（図３５（Ｂ）参照）。

また、機能Ｆ１で通らないポイントはない。機能Ｆ２で通らないポイントはｐ４及びｐ５である。したがって、パス分析部４２０は、（ｐ１，ｐ４，Ｆ２）及び（ｐ１，ｐ５，Ｆ２）のレコードをテーブルに出力する。さらに、機能Ｆ３で通らないポイントはｐ５であるから、パス分析部４２０は、ｐ１，ｐ５，（Ｆ２），Ｆ３のレコードをテーブルに出力する。また、Ｆ４で通らないポイントはｐ４であるから、パス分析部４２０は、ｐ１，ｐ４，（Ｆ２），Ｆ４のレコードをテーブルに出力する。

以上のようにして、図３５（Ａ）に例示するパス情報に対して、図３５（Ｂ）に例示するような補完テーブル（排他ポイントテーブル）が作成される。なお、上述した処理Ｐ３１２において、ポイントが存在しなければ（処理Ｐ３１２のＮｏルート）、パス分析部４２０は、処理を終了する。

なお、問題なし（または悪化）の「候補リクエスト」を絞って抽出できるようにテーブル（インデックス）を用意しておくとより効率的である。データが足りない時にデータを補完するフローを図３６に例示する。

パス分析部４２０は、分析を実施し（処理Ｐ３２１）、複数の候補が存在するか否かをチェックする（処理Ｐ３２２）。例えば、実運用フェーズにおいて、機能Ｆ１が異常、機能Ｆ２が正常というデータが存在し、機能Ｆ３及びＦ４についてのデータが存在しない場合、ｐ４及びｐ５が遅延候補になる。

複数の候補が存在すれば（処理Ｐ３２２でＹｅｓの場合）、パス分析部４２０は、候補のポイントを分割する（処理Ｐ３２３）。例えば、候補がｐ４及びｐ５であれば、ｐ４とｐ５とに分割する。

次いで、パス分析部４２０は、分割したポイントの組合せ全てで排他ポイントテーブル（例えば図３５（Ｂ）参照）を検索する（処理Ｐ３２４）。例えば、検索キー＝ｐ４及び排他ポイントキー＝ｐ５で図３５（Ｂ）に例示する排他ポイントテーブルを検索すると、機能Ｆ３が見つかる。また、検索キー＝ｐ５及び排他ポイントキー＝ｐ４で図３５（Ｂ）に例示する排他ポイントテーブルを検索すると、機能Ｆ４が見つかる。

パス分析部４２０は、排他ポイントが存在するか否かをチェックし（処理Ｐ３２５）、排他ポイントが存在すれば（処理Ｐ３２５でＹｅｓの場合）、見つかった機能群を事前分析フェーズのデータから探して再投入して、再分析を行なう（処理Ｐ３２６）。例えば、処理Ｐ３２４及びＰ３２５で見つかった機能Ｆ３及びＦ４に対応するデータを再投入して分析する。

「候補リクエスト」を再投入することで、欠落していた目的のチェックポイントの情報を補完することができて、かつ、問題個所の絞り込み（特定）ができればよい。例えば、機能Ｆ３に対応するリクエストを再投入して問題なしなら悪化原因はｐ５であると判定（特定）できる。

なお、絞り込み（特定）ができなかった場合は他の「候補リクエスト」を使えばよい。例えば、機能Ｆ４に対応するリクエストを再投入して悪化した場合なら、悪化原因としてｐ４が疑わしいと判定できる。複数のリクエストを再投入することで信頼度を高めるようにしてもよい。

（出現確率を利用した精度の向上１）
問題個所特定の精度向上のために、出現確率（頻度）を使う方法が考えられる。

（事前分析フェーズ）
例えば図３７に示すように、Ｆ１＝ｐ１−ｐ２−ｐ３及びｐ１−ｐ２−ｐ３−ｐ４の2種類のパスを通る場合、Ｆ１のパラメータ等の外部情報ではどちらを通るか識別できない。

ここで、ｐ１−ｐ２−ｐ３のパスをＦ１−１、ｐ１−ｐ２−ｐ３−ｐ４のパスをＦ１−２とする。Ｆ１のパラメータではＦ１−１及びＦ１−２のどちらを通るか分類できないが、事前分析フェーズではどちらのパスを通るか識別できるので、パス分析部４２０それぞれの頻度をカウントする。この結果、Ｆ１の場合の出現確率は、例示的に、Ｆ１−１が７０％、Ｆ１−２が３０％のように準備できる。

（実運用フェーズ）
実運用フェーズの情報だけでは、パラメータによりＦ１であることが分かっても、それがＦ１−１のパスかＦ１−２のパスか識別できない。ここで、Ｆ１が７０％の確率でレスポンスがよく、３０％の確率でレスポンスが悪い場合、問題個所特定部４６０によりＦ１−１とＦ１−２との差分となるｐ４の個所が悪化の原因箇所であると推定することができる。

（出現確率を利用するフロー）
図４に例示した事前分析フェーズにおけるフローの処理Ｐ６０において、パス分析部４２０は、例えば図３８に示すような頻度情報（テーブル）を出現確率情報データベース４０５に登録しておく。

図３９に例示するように、パス分析部４２０は、データと機能とを対応付ける（処理Ｐ３３１）。例えば、「データ１：Ｆ１＝○」、「データ２：Ｆ１＝○」、「データ３：Ｆ２＝○」、「データ４：Ｆ３＝×」、「データ５：Ｆ１＝×」…のようにデータと機能とを対応付ける。

次いで、パス分析部４２０は、複数のパスをもつ機能のデータ群をまとめる（処理Ｐ３３２）。例えば図３８に例示する頻度情報テーブルより、機能Ｆ１は複数のパス情報をもつことが分かるので、「データ１：Ｆ１＝○」、「データ２：Ｆ１＝○」、及び、「データ５：Ｆ１＝×」の３つデータ群をまとめる。

さらに、パス分析部４２０は、１つの機能に複数のパスがあるデータについて、正常と異常の比率を求める（処理Ｐ３３３）。上述した例の場合、正常は６６．７％、異常は３３．３％となる。

そして、パス分析部４２０は、データの正常と異常の比率が頻度情報と同一とみなせるか否かをチェックする（処理Ｐ３３４）。上述した例の場合、正常は６６．７％、異常は３３．３％となるので、同一とみなせる。同一とみなせる場合（処理Ｐ３３４でＹｅｓの場合）、パス分析部４２０は、頻度情報と適合するパス情報を対応付ける（処理Ｐ３３５）。一方、同一とみなせない場合（処理Ｐ３３４でＮｏの場合）、パス分析部４２０は、頻度が多いパスを代表データとして扱う（処理Ｐ３３６）。

（出現確率を利用した精度の向上２）
図４０に例示するように、機能Ｆ１のパスはＦ１（Ｆ１−１）＝ｐ１−ｐ２−ｐ４−ｐ５とＦ１（Ｆ１−２）＝ｐ１−ｐ３−ｐ５の２種類が存在し、機能Ｆ２のパスはＦ２＝ｐ１−ｐ３−ｐ５、機能Ｆ３のパスはＦ３＝ｐ１−ｐ２−ｐ３であるとする。この場合、機能Ｆ１には、パラメータ等によって分類できない複数のパスが存在していることになる。

事前データ採取部４１０がユーザリクエストデータベース４０３に保存済みのリクエストデータを再現することで、パス分析部４２０が例えば図４１に例示するように各機能をリクエストデータが通る頻度をカウントする（各Ｆｉ、ｐｉ毎に頻度をカウントする）。

実運用フェーズでは、機能選別部４４０が各チェックポイント（ｐｉ）の出現頻度をカウントする（図４２参照）。ただし、どの機能Ｆｉによるものかといった詳細な情報はログ採取量や紐付け処理等により処理量が増えるのでチェックしない。

ここで、図２０において、Ｆ１及びＦ２が悪化し、Ｆ３は正常とする。この場合、ｐ４及びｐ５に悪化原因の可能性が残る。実運用フェーズの機能Ｆ１の集計期間中の全リクエストのうち、例示的に、２８％（＝１４／５０）のリクエストが悪化しているものとする。この場合、図４１に例示した頻度情報テーブルと照らして、Ｆ１−２（ｐ１−ｐ３−ｐ５）のパスが悪化していることが推定されるので、ｐ４（Ｆ１−１）は悪化していないことが分かる。その結果、ｐ５が原因箇所であると判断できる。

１０ ネットワーク
２０ サーバ
３０ Ｗｅｂサーバ
４０ ＡＰ（アプリケーション）サーバ
５０ ネットワークスイッチ（ＮＳ）
４０１ 事前分析ブロック
４０２ 運用ブロック
４０３ ユーザリクエストデータベース
４０４ パス情報データベース
４０５ 出現確率情報データベース
４１０ 事前データ採取部
４２０ パス分析部
４３０ 運用データ採取部
４４０ 機能選別部
４５０ データスライス分割部
４６０ 問題個所特定部
５００，５２０ 通知画面
５０１，５１１〜５１５，５２１，５２２ 詳細表示ボタン
５１０ 詳細表示画面
Ｆ１，Ｆ２，Ｆ３，Ｆ４ 機能
ｐ１，ｐ２，ｐ３，ｐ４，ｐ５ コンポーネント

Claims (8)

1. 共用するモジュールが存在する複数の処理それぞれについて、正常及び異常のステートをログデータより算出し、
   前記ステートの変化のタイミングを算出し、
   算出した前記タイミングに基づき、前記複数の処理それぞれについて正常及び異常のステートが混在しない時間区間を区切り、
   前記時間区間において、前記複数の処理と前記モジュールとの関係情報に基づき、異常モジュールを検出する、分析方法。
2. 異なる種別のステートの開始タイミングが前記時間区間の終了タイミングである、請求項１に記載の分析方法。
3. 同一種別のステートの最後の終了タイミングが前記時間区間の終了タイミングである、請求項１に記載の分析方法。
4. 異なる種別のステートの開始タイミングよりも前に出現した種別のステートの終了タイミングが前記時間区間の終了タイミングである、請求項１に記載の分析方法。
5. 前記異常モジュールの検出に必要十分なデータが存在しない場合に、保存してあるユーザリクエストから必要なデータを再投入することでデータ補完する、請求項１に記載の分析方法。
6. １つの前記処理が前記モジュールの集合である複数のパスを通る場合に、出現確率を用いて前記パスを特定することで、前記異常モジュールの検出を行なう、請求項１に記載の分析方法。
7. 共用するモジュールが存在する複数の処理それぞれについて、正常及び異常のステートをログデータより算出する手段と、
   前記ステートの変化のタイミングを算出する手段と、
   前記算出したタイミングに基づき、前記複数の処理それぞれについて正常及び異常のステートが混在しない時間区間を区切る手段と、
   前記時間区間において、前記複数の処理と前記モジュールとの関係の情報に基づき、異常モジュールを検出する手段と、を備えた分析装置。
8. 共用するモジュールが存在する複数の処理それぞれについて、正常及び異常のステートをログデータより算出し、
   前記ステートの変化のタイミングを算出し、
   前記算出したタイミングに基づき、前記複数の処理それぞれについて正常及び異常のステートが混在しない時間区間を区切り、
   前記時間区間において、前記複数の処理と前記モジュールとの関係の情報に基づき、異常モジュールを検出する、
   処理をコンピュータに実行させる、分析プログラム。

Images