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

Abstract

【課題】複数の処理の各々が経由するモジュールの情報が正しくない場合でも異常モジュールを特定する。
【解決手段】コンピュータに、共用するモジュール（ｐｊ（ｊは自然数））が存在する複数の処理（Ｆｉ（ｉは自然数））それぞれについて、各処理が経由するモジュールの情報を記憶し、所定期間に実行した複数の処理に関するログ情報に基づき、前記所定期間に実行した各処理の正常又は異常のステートを判定し、前記正常又は異常のステートの判定結果と前記所定期間に実行した各処理に係る前記モジュールの情報とを用いて異常モジュールの特定を行なう処理において、異常モジュールが特定されない場合、前記所定期間に実行した各処理に係る前記モジュールの情報を、所定の条件に基づき修正し、前記正常又は異常のステートの判定結果と前記修正したモジュールの情報とを用いて異常モジュールを特定する、処理を実行させる。
【選択図】図４４

Description

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

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

アプリケーションプログラムやネットワークコンポーネントが行なう処理は、例えばstart-A-B-C-D-endという処理シーケンスのように、複数のモジュール（A〜D）を経由して実現され、各モジュールは、複数の処理で用いられ得る。このように、アプリケーションプログラムやネットワークコンポーネントは、複数の処理で共通のモジュールを使用した処理を行なう。

特定のモジュールの遅延は、関連する複数の処理で遅延を引き起こす原因となる。遅延しているモジュールを特定する手法としては、以下の手法が知られている（例えば、下記の特許文献２参照）。

例示的に、分析装置が、複数の処理を実行した結果から各々の処理が使用するモジュールを特定したパス情報を記憶し、処理と処理時間とを含むログ情報から処理時間の遅延を検出した時刻を含む所定の時間区間に出力されたログ情報を抽出する。これにより、分析装置は、抽出したログ情報とパス情報とに基づいて処理遅延の原因となるモジュールを特定できる。

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

上記の技術において、複数の処理の各々が経由するモジュールの情報（パス情報）は、事前に処理を実行した結果から作成される。

分析装置では、事前に作成したパス情報が正しいことを前提としているが、作成したパス情報が正しくない、つまりパス情報で特定されるモジュールが、抽出したログ情報に含まれる処理で使用されたモジュールと異なる可能性もある。このような状況が生じるのは、例えば、条件分岐で異なるモジュールが実行された場合等、パス情報及びログ情報に係るそれぞれの処理の実行タイミングや指定されたパラメータ等の条件が異なる場合などである。

分析装置では、パス情報が正しくないと、抽出したログ情報に含まれる処理で使用されたモジュールを特定することができず、処理遅延の原因となるモジュールを特定することが困難となる場合がある。

１つの側面では、本発明は、複数の処理の各々が経由するモジュールの情報が正しくない場合でも異常モジュールを特定することを目的とする。

分析プログラムの一態様は、コンピュータに、以下の処理を実行させる。前記処理は、共用するモジュールが存在する複数の処理それぞれについて、各処理が経由するモジュールの情報を記憶し、所定期間に実行した複数の処理に関するログ情報に基づき、前記所定期間に実行した各処理の正常又は異常のステートを判定する処理を含む。また、前記処理は、前記正常又は異常のステートの判定結果と前記所定期間に実行した各処理に係る前記モジュールの情報とを用いて異常モジュールの特定を行なう処理において、異常モジュールが特定されない場合、前記所定期間に実行した各処理に係る前記モジュールの情報を、所定の条件に基づき修正する処理を含む。さらに、前記処理は、前記正常又は異常のステートの判定結果と前記修正したモジュールの情報とを用いて異常モジュールを特定する処理を含む。

一態様によれば、複数の処理の各々が経由するモジュールの情報が正しくない場合でも異常モジュールを特定することができる。

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

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

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

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

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

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

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

なお、ＡＰサーバ４０等のコンピュータは、記録媒体に記録されたプログラムを読み取るための手段をそなえることができる。

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

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

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

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

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

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

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

運用データ採取部４３０は、運用フェーズにおいて実運用でサーバ２０，３０，４０に流れるデータから例えばＵＲＬ（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２１２）。例えば、以下のように、機能Ｆ１〜Ｆ３毎にコンポーネントｐ１〜ｐ５を設定する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次に、図５の処理Ｐ１５０〜Ｐ１９０（図１７の処理Ｐ２２７〜Ｐ２３０）に関連して、事前分析フェーズにおいて作成されたパス情報が運用フェーズにおける処理の実行内容と異なる（矛盾する）場合の問題について図４３（Ａ）及び（Ｂ）を参照して説明する。

運用フェーズにおいて、事前分析フェーズで用いられたコンポーネントとは異なるコンポーネントが用いられる場合がある。この場合、問題個所特定部４６０は問題個所を特定することが困難となる。

一例として、図４３（Ａ）及び（Ｂ）に示すように、事前分析フェーズにおいて、機能Ｆ１〜Ｆ４の全てがコンポーネントｐ１，ｐ２，ｐ３を経由した場合、パス情報ではＦ１〜Ｆ４のいずれについてもｐ１，ｐ２，ｐ３が対応付けられる。このとき、Ｆ１＝異常、Ｆ２＝正常、Ｆ３＝異常、Ｆ４＝正常となった場合を考える。

図４３（Ａ）は、運用フェーズにおいて、Ｆ２で、事前分析フェーズで使われた（経由した）ｐ１，ｐ２，ｐ３のうちのｐ３が使用されず、且つこのｐ３が問題個所である場合を示す。このとき、パス情報ではＦ２のパスにもｐ３が含まれているためＦ２のｐ３によって問題個所である（Ｆ１の）ｐ３が隠蔽されてしまう。このため、問題個所特定部４６０は、問題個所としてＦ１のｐ３を特定することが困難となる。

また、図４３（Ｂ）は、運用フェーズにおいて、Ｆ３で、ｐ１，ｐ２，ｐ３に加えて事前分析フェーズでは使われなかった（経由しなかった）ｐ４が使用され、且つこのｐ４が問題個所である場合を示す。このとき、パス情報ではＦ３のパスにｐ４が含まれていないため、問題個所特定部４６０は、問題個所としてＦ３のｐ４を特定することが困難となる。

図４３（Ａ）及び（Ｂ）に示すような状況が生じるケースとしては、内部的な状態（時刻，ＤＢから取得した値等）や外面からは識別できないパラメータ等により機能Ｆｉでの処理内容が分岐するような場合が挙げられる。この場合において、事前分析フェーズで当該機能Ｆｉの条件分岐を網羅できなかった場合に、機能Ｆｉでは事前分析フェーズと運用フェーズとで異なるコンポーネントが用いられ得る。なお、図４３（Ａ）及び（Ｂ）のいずれのパターンでも、正常・異常の機能はそれぞれ１つの機能に限定されず、複数の機能の組み合わせで上記のパターンが構成されることもある。

以下、本実施形態においては、異常な機能Ｆｉ中に問題個所となるコンポーネントｐｊ（ｊは自然数）を発見できない場合を、パス情報とシステム状態（ログ情報に記録された際の機能Ｆｉのパス）との「矛盾状態」と捉えるものとする。矛盾状態は、異常な機能Ｆｉのコンポーネントを正常な機能のコンポーネントが打ち消している状態であるといえる。

（矛盾状態を検出した場合の処理）
以下、問題個所特定部４６０による図５の処理Ｐ１６０で問題個所が特定されず、矛盾状態が検出された場合の処理について説明する。

基本的な処理の一例としては、問題個所特定部４６０は、問題個所の特定（図５の処理Ｐ１５０及びＰ１６０）において矛盾状態を検出すると、パス情報の修正を行なう（図４４〜図４７参照）。そして、問題個所特定部４６０は、問題個所の特定処理を再実施することで、矛盾状態からの問題個所の特定を可能にする。

なお、図４４〜図４７の上段は、機能とコンポーネントとの対応関係を示すパス情報と、所定期間に実行された各機能のログ情報から得られた各機能のあるタイミング（スライス）での正常又は異常のステートとを組み合わせた表である。この表には、遅延機能が利用するコンポーネント毎に、当該コンポーネントを使用する正常機能の数が設定されている。図４４〜図４７の下段は問題個所特定部４６０による補正後のパス情報を示すものである。

パス情報の修正の手法としては、以下の方式が挙げられる。

（方式Ｉ）正常機能及び異常機能が混在する複数の機能から、所定の条件に基づき少なくとも１つの機能を削除する。

この方式では、図４４及び図４５に例示するように、パス情報及び各機能の正常・異常のステートに応じて、正常機能及び異常機能の少なくとも１つを削除する。

（方式Ｉ−１）図４４の例では、上段に示すように、異常機能Ｆ１が使うコンポーネント（ｐ１，ｐ２，ｐ３，ｐ４）、つまり異常候補のコンポーネントを正常機能Ｆ２〜Ｆ４の組み合わせが全て打ち消している。このような場合、問題個所特定部４６０は、パス情報において、異常機能Ｆ１が使うコンポーネントを打ち消すコンポーネントを持つ正常機能Ｆ２〜Ｆ４から、信頼度が最も低いコンポーネント（この場合ｐ４）を使う全ての正常機能（この場合Ｆ２）を削除する。

ここで、信頼度は、異常候補のモジュールを正常機能が経由する可能性を示す評価値の一例であり、図４４（及び図４５〜図４７）の例では、信頼度として異常機能と重なる正常機能のコンポーネントの数を用いている。
削除後のパス情報は、図４４の下段に示すように、正常機能Ｆ２が削除されたものとなるため、問題個所特定部４６０は、問題個所としてｐ４を特定できる。

なお、図４４の上段の例は、特定された結果から、事前分析フェーズでは機能Ｆ２がｐ４を使ったが運用フェーズでは使わなかったパターン（図４３（Ａ）のパターン）であると推測される。

（方式Ｉ−２）図４５の例では、上段に示すように、異常機能Ｆ５については問題個所をｐ６と特定できる。一方、異常機能Ｆ１についてはＦ１が使うコンポーネント（ｐ１，ｐ２，ｐ３，ｐ４）を正常機能Ｆ２〜Ｆ６の組み合わせが全て打ち消している。このような場合、問題個所特定部４６０は、パス情報において、問題個所を特定できない異常機能Ｆ１を削除する。これにより、結果（既に問題個所として特定されている異常機能Ｆ５のｐ６）に影響を与えずに矛盾状態を解消できる。

削除後のパス情報は、図４５の下段に示すように、異常機能Ｆ１が削除されたものとなるため、問題個所特定部４６０は、異常機能Ｆ５の問題個所としてｐ６を特定できる。

なお、図４５の上段の例は、特定された結果から、事前分析フェーズでは機能Ｆ１がｐ６を使わなかったが運用フェーズでは使ったパターン（図４３（Ｂ）のパターン）であると推測される。

ここまで、図４４及び図４５について、それぞれ上述した（方式Ｉ−１）及び（方式Ｉ−２）の手法により問題個所が特定される例を示したが、問題個所特定部４６０は、矛盾状態を検出した場合、（方式Ｉ−１）及び（方式Ｉ−２）のいずれの手法によっても問題個所を特定することができる。

例えば、図４５の上段において、異常機能Ｆ１が使うコンポーネント（ｐ１，ｐ２，ｐ３，ｐ４）を打ち消すコンポーネントを持つ正常機能Ｆ２〜Ｆ６のうち、信頼度が最も低いコンポーネント（この場合ｐ３又はｐ４）を使う全ての正常機能を削除してもよい。

一例として、問題個所特定部４６０は、ｐ３を使う全ての正常機能（この場合Ｆ３及びＦ４）を削除し、異常機能Ｆ１についてはｐ３を問題個所として特定してもよい。この特定された結果から、事前分析フェーズでは機能Ｆ３及びＦ４がｐ３を使ったが運用フェーズでは使わなかったパターン（図４３（Ａ）のパターン）であると推測される。

あるいは、問題個所特定部４６０は、ｐ４を使う全ての正常機能（この場合Ｆ２及びＦ６）を削除し、異常機能Ｆ１についてはｐ４を問題個所として特定してもよい。この場合、事前分析フェーズでは機能Ｆ２及びＦ６がｐ４を使ったが運用フェーズでは使わなかったパターン（図４３（Ａ）のパターン）であると推測される。

問題個所特定部４６０は、矛盾状態を検出した場合、方式（Ｉ）の（Ｉ−１），（Ｉ−２），若しくは以下の方式（II）の（II−１），（II−２）のいずれを用いるかを、後述する手法により決定することができる。又は、問題個所特定部４６０は、これらの２以上の方式を用いて特定された結果から最適な結果（例えば絞り込んだコンポーネントの数）を選択してもよい。

なお、（方式Ｉ）では、複数の機能から少なくとも１つの機能を削除するものとして説明したが、機能全体（パス情報のレコード）を削除するのではなく、機能が使用する全てのコンポーネント（パス情報のレコード内の全コンポーネント）を削除してもよい。

（方式II）正常機能及び異常機能が混在する複数の機能から、所定の条件に基づき少なくとも１つのコンポーネントを変更する。

この方式では、図４６及び図４７に例示するように、パス情報及び各機能の正常・異常のステートに応じて、正常機能又は異常機能に対して、一部のコンポーネントの削除又は少なくとも１つのコンポーネントの追加を行なう。なお、図４６及び図４７の上段では、それぞれ図４４及び図４５の上段と同様の状況を想定している。

（方式II−１）図４６の上段に示すように、問題個所特定部４６０は、パス情報において、異常機能Ｆ１が使うコンポーネントを打ち消すコンポーネントを持つ正常機能Ｆ２〜Ｆ４から、信頼度が最も低いコンポーネント（この場合ｐ４）を削除する。

削除後のパス情報は、図４６の下段に示すように、正常機能Ｆ２からｐ４が削除されたものとなるため、問題個所特定部４６０は、問題個所としてｐ４を特定できる。これにより、パス情報の修正を最小限に留め、正常機能Ｆ２も問題個所の絞り込みに利用することができるため、分析精度を向上させることができる。

なお、このタイミング（スライス）ではリクエストの発生していない他の機能（例えばＦ５）がパス情報に存在し、当該機能Ｆ５がｐ４を使う場合、Ｆ５については矛盾状態とは無関係であるため、ｐ４を削除しなくてよい。

（方式II−２）図４７の上段に示すように、異常機能Ｆ１についてはＦ１が使うコンポーネント（ｐ１，ｐ２，ｐ３，ｐ４）を正常機能Ｆ２〜Ｆ６の組み合わせが全て打ち消している。このような場合、問題個所を特定できない異常機能Ｆ１に、コンポーネントｐ６を追加する。これにより、結果（既に問題個所として特定されている異常機能Ｆ５のｐ６）に影響を与えずに矛盾状態を解消できる。

削除後のパス情報は、図４７の下段に示すように、Ｆ１のパスがｐ１−ｐ２−ｐ３−ｐ４−ｐ６となるため、問題個所特定部４６０は、異常機能Ｆ１及びＦ５に共通する問題個所としてｐ６を特定できる。

図４６及び図４７についても、問題個所特定部４６０は、矛盾状態を検出した場合、（方式II−１）及び（方式II−２）のいずれの手法によっても問題個所を特定することができる。

例えば、図４７の上段において、異常機能Ｆ１が使うコンポーネント（ｐ１，ｐ２，ｐ３，ｐ４）を打ち消すコンポーネントを持つ正常機能Ｆ２〜Ｆ６から、信頼度が最も低いコンポーネント（この場合ｐ３又はｐ４）を削除してもよい。

一例として、問題個所特定部４６０は、ｐ３を使う全ての正常機能（この場合Ｆ３及びＦ４）からｐ３を削除し、異常機能Ｆ１についてはｐ３を問題個所として特定してもよい。この特定された結果から、事前分析フェーズでは機能Ｆ３及びＦ４がｐ３を使ったが運用フェーズでは使わなかったパターン（図４３（Ａ）のパターン）であると推測される。

あるいは、問題個所特定部４６０は、ｐ４を使う全ての正常機能（この場合Ｆ２及びＦ６）からｐ４を削除し、異常機能Ｆ１についてはｐ４を問題個所として特定してもよい。この場合、事前分析フェーズでは機能Ｆ２及びＦ６がｐ４を使ったが運用フェーズでは使わなかったパターン（図４３（Ａ）のパターン）であると推測される。

図４７の例のように、コンポーネントの追加でも削除でも矛盾状態を解消できる場合、問題個所特定部４６０は、所定の基準に基づき追加及び削除のいずれかを選択してよい。このとき、問題個所特定部４６０は、例えば信頼度が低いコンポーネントの削除を優先としてよく、信頼度が（十分）低いコンポーネントの削除で矛盾状態を解消できる場合は、当該コンポーネントを削除してよい。

なお、削除候補のコンポーネントの信頼度が他のコンポーネントの信頼度よりも十分低いとはいえない場合、問題個所特定部４６０は、コンポーネントの追加を優先してもよい。「信頼度が十分低い」とは、例えば削除対象のコンポーネントについて、正常機能のコンポーネント数が１以下であり且つ他のコンポーネントの信頼度の１／２以下、である場合が挙げられる。図４７の例では、ｐ３，ｐ４の信頼度（この場合正常機能のコンポーネント数＝２）が１以下ではなく、他のコンポーネントの信頼度（ｐ１，ｐ２＝３）の１／２である１．５よりも大きいため、ｐ３，ｐ４の信頼度は十分低いとはいえない。この場合、問題個所特定部４６０は、ｐ６の追加を優先してもよい。

なお、上述の手法によりパス情報の修正を行ない問題個所を特定した後の運用では、問題個所特定部４６０は、修正後のパス情報及び修正していないパス情報の少なくとも一方を用いて分析を行ない、分析結果を出力してよい。例えば、問題個所特定部４６０は、図４４の例でパス情報を修正した後の運用において、図５の処理Ｐ１５０では、修正後のパス情報（Ｆ１，Ｆ３，Ｆ４）及び修正していないパス情報（Ｆ１〜Ｆ４）の少なくとも一方を用いてよい。また、問題個所特定部４６０は、図４６の例でパス情報を修正した後の運用において、図５の処理Ｐ１５０では、修正後のパス情報（Ｆ１，Ｆ２（ｐ４は削除），Ｆ３，Ｆ４）及び修正していないパス情報（Ｆ１〜Ｆ４）の少なくとも一方を用いてよい。

次に、図４８〜図５５を参照して運用フェーズにおいて矛盾状態を検出した場合の処理例について説明する。

なお、以下の説明では、事前分析ブロック４０１により以下の情報が生成されているものとする。

・パス情報（基準情報）例
Ｆ１， ｐ１：ｐ２：ｐ３：ｐ４， http://foo.com/?tab=
Ｆ２， ｐ１：ｐ２：ｐ４：ｐ５， http://foo.com/?col=5
Ｆ３， ｐ１：ｐ２：ｐ３：ｐ５， http://foo.com/?col=4
Ｆ４， ｐ１：ｐ２：ｐ３， http://foo.com/?ui

・コンポーネント定義情報例
com/foo/pkg/servlet，ｐ１，Servlet
com/foo/pkg/kernel，ｐ２，Kernel
com/foo/pkg/log，ｐ３，Log
org/hibernate/Session，ｐ４，Hibernate
・・・

・パラメータ表例
use，col
delvalue，tab
delvalue，ui
・・・

・遅延判定閾値例
Ｆ１＝１２００ｍｓ
Ｆ２＝１８００ｍｓ
ｄｅｆａｕｌｔ＝１５００ｍｓ

なお、パラメータ表は機能選別においてアクセスログのＵＲＬに含まれるパラメータの扱いを示す情報である。図４９に例示するアクセスログが採取された場合、例えば、“use，col”はＵＲＬ中の“col=5”のパラメータをそのまま用いることを示し、“delvalue，tab”はＵＲＬ中の“tab=stop”のパラメータの値を削除し“tab=”のみを用いることを示す。運用ブロック４０２は、このパラメータ表により図４９に示すログの各レコードをパス情報の機能と対応付けることができる。

図４９に示す例において、rec1〜rec4の入力時点で処理時間は遅延判定閾値と比較し全て正常値であるが、rec5（Ｆ１）の処理時間はＦ１の閾値１２００ｍｓよりも大きい２１２３ｍｓであるため、運用ブロック４０２は遅延（状態変化）を検知する。

図４９に示すアクセスログの情報をパス情報に照らすと、図５０に示す状態であることがわかる。図５０は図４４の上段と同様の状態を示しており、問題個所特定部４６０は、図５０の状態では問題個所を特定することができない、つまり矛盾状態を検出する。

上述のように、図５の処理Ｐ１６０において問題個所の特定ができなかった場合（処理Ｐ１６０のＮｏルート）、問題個所特定部４６０はパス情報の修正及び問題個所特定の再実施を行なう（処理Ｐ１８０）。このとき、問題個所特定部４６０は、処理Ｐ１８０として以下の処理を行なうことにより、問題個所（原因コンポーネント）の特定を可能とする。

まず、図４８に示すように、問題個所特定部４６０は、上述した（方式Ｉ）及び（方式II）のいずれかからパス情報の修正方法を選択する（処理Ｓ１８１）。選択の手法は、例えばパス情報に含まれる機能数とコンポーネント数とを比較し、機能数の方が多ければ（方式Ｉ）を、コンポーネント数の方が多ければ（方式II）を選択するようにしてよい。図５０の例では機能（Ｆ１〜Ｆ４）数＝４、コンポーネント（ｐ１〜ｐ５）数＝５であるため、問題個所特定部４６０は（方式II）を選択することとする。

他の例として、例えばコンポーネント数が特定の値（例えば１０）よりも多ければ（方式II）を選択し、コンポーネント数が特定の値以下であれば（方式Ｉ）を選択するようにしてもよい。

あるいは、例えば機能数が特定の値（例えば２０）よりも多ければ（方式Ｉ）を選択し、機能数が特定の値以下であり、コンポーネント数が特定の値（例えば３０）又は機能数×特定の値（例えば１．５）よりも多ければ（方式II）を選択するようにしてもよい。このとき、いずれの条件も満たさなければ（方式Ｉ）を選択するようにしてもよい。

このような条件は、分析装置の管理者により任意に設定可能としてよい。また、パス情報の修正方法は上記のような条件による選択ではなく、いずれかを固定的に用いるようにしてもよい。

さらに、問題個所特定部４６０は、いずれかの修正方法を用いてパス情報の修正及び問題個所の分析を行なった後、分析結果に応じて他方の修正方法で再分析を行ない、分析結果の良い方（例えば絞り込んだコンポーネント数が少ない方）を採用するようにしてもよい。例えば、問題個所特定部４６０は、いずれかの修正方法を選択した際に、分析結果として多数のコンポーネントが問題個所として特定されることが続く場合等、問題個所の特定が不十分な（十分な絞り込みができない）場合に、他方の修正方法で再分析を行なうことができる。

なお、修正処理の一度の実行により矛盾状態は解消できるため、問題個所特定部４６０は、矛盾状態を検出した際に、同じ修正方法を繰り返し何度も実行しなくてよい。

次に、問題個所特定部４６０は、選択した修正方法（例えば図５０の例では機能数：４＜コンポーネント数：５であるため（方式II））を用いてパス情報の修正を行なう（処理Ｐ１８２）。例えば、問題個所特定部４６０は、図４６の下段に示すように、機能Ｆ２のコンポーネントｐ４を削除する。

そして、問題個所特定部４６０は、修正後のパス情報を用いて分析を行ない、問題個所を特定する（処理Ｐ１８３）。図５０の例では、問題個所特定部４６０は、図４６の下段に示すように問題個所としてコンポーネントｐ４を特定する。

また、問題個所特定部４６０は、原因コンポーネントの特定後、修正を行なったパス情報の管理を行なうことができる（図５の処理Ｐ１９０参照）。

例えば、問題個所特定部４６０は、図５１に示すように、修正したパス情報をＲＡＭ等のメモリやハードディスク装置等の記憶装置に蓄積する（処理Ｐ１９１）。このとき、問題個所特定部４６０は、同じパターンで修正したパス情報毎に修正頻度（例えば修正回数）を記録してよい。図５２の例では、Ｆ２からｐ４を削除したパターンの修正回数は２０回、Ｆ３及びＦ４からｐ３を削除したパターンの修正回数は２回、Ｆ２からｐ５を削除したパターンの修正回数は１回である。

次いで、問題個所特定部４６０は、蓄積する修正後のパス情報が置き換え条件を満たすか否かを判断し（処理Ｐ１９２）、置き換え条件を満たす場合（処理Ｐ１９２のＹｅｓルート）、パス情報を置き換え（処理Ｐ１９３）、処理が図５の処理Ｐ１７０に移行する。一方、置き換え条件を満たさない場合（処理Ｐ１９２のＮｏルート）、パス情報の置き換えを行なわず、処理が図５の処理Ｐ１７０に移行する。

パス情報の置き換え条件としては、例えば、修正回数の最も多いパターンの修正回数が、所定回数（例えば１５回）以上、且つ次に修正回数の多いパターンの修正回数の所定倍（例えば１０倍）以上である場合が挙げられる。図５２の例では、修正回数２０回のパターンが、１５回以上且つ次に多い２回のパターンの１０倍以上であるため、置き換え条件を満たすと判断される。そして、問題個所特定部４６０は、修正回数２０回のパターンにより、パス情報データベース４０４に記憶されたパス情報の対応する個所（少なくとも機能Ｆ２のコンポーネント）を置き換える。

なお、パス情報の置き換え条件は、上述したものに限定されるものではなく、種々の手法を用いることができる。

また、問題個所特定部４６０は、問題個所を特定（又は絞り込んだ）場合、図５の処理Ｐ１７０において、図９に例示する態様で問題個所を出力する。図５０の例では、問題個所特定部４６０は、図５３に例示するように、特定したコンポーネントｐ４を詳細表示画面５１０に出力することができる。

なお、パス情報の修正があった場合でも、問題個所特定部４６０は、修正があったことを必ずしも通知する必要はなく、詳細表示画面５１０に修正の有無を示さなくてもよい。

問題個所の他の出力例を図５４に示す。図５４の左側に示す表について、問題個所特定部４６０は、異常機能Ｆ５についてはｐ６を問題個所として特定するものの、異常機能Ｆ１については問題個所を特定できない。この場合において、（方式II−１）によるパス情報の修正が行なわれ、正常機能Ｆ２のｐ４が削除された場合、異常機能Ｆ１についてｐ４が問題個所と特定される。なお、このとき、異常機能Ｆ５にもｐ４が含まれているため、Ｆ５の問題個所はｐ４が追加されてｐ４，ｐ６となる。

このような場合、問題個所特定部４６０は、図５４の右側の詳細表示画面５１０に示すように、パス情報の修正の有無による問題個所の特定（絞り込み）結果を併記してもよい。なお、図５４の例では、特定した原因コンポーネントを利用する機能（異常機能）についても詳細表示画面５１０に出力してよい。

（パス情報の修正に用いる信頼度の他の例１）
上述した（方式Ｉ）又は（方式II）では、遅延機能と重なる正常機能のコンポーネントの数（遅延機能が利用するコンポーネント毎の、当該コンポーネントを使用する正常機能の数）を信頼度として用いて、パス情報を修正する例を説明した。信頼度としては、上述したものに限定されるものではなく、例えば以下の情報としてもよい。

図５５の上段右側は、事前分析フェーズにおいて使用されたコンポーネントの頻度（回数，例えば総数）を機能毎に示す情報である。問題個所特定部４６０は、パス情報と各機能の正常・異常のステートとを表す表（図５５の上段左側）に対して、頻度（回数）情報に基づき重み付けを行なう。これにより、図５５の下段に示すように、異常機能が使用するコンポーネント毎に正常機能が使用する頻度を加算した信頼度を得ることができる。一例として、ｐ１は９５（Ｆ２）＋１８（Ｆ３）＋１９（Ｆ４）＝１３２の信頼度となる。

事前分析ブロック４０１は、事前分析フェーズにおいて、機能が呼び出される都度、使用するコンポーネントの頻度（回数）を機能毎・コンポーネント毎にカウントし、頻度情報として保存してよい。

図４６の例（方式II）に基づくパス情報の修正では、コンポーネントの数を信頼度として用い、Ｆ２のｐ４を削除する結果となった。これに対し、図５５の例では、事前分析フェーズにおける頻度情報を重みとして考慮した場合、Ｆ３及びＦ４のｐ３の信頼度が３であり最も低い（有意に低い）結果となる。なお、「有意に低い」とは、次に低い信頼度（又は全体の信頼度の平均等）よりも所定値（例えば１５）又は所定割合（例えば１／１０）以上低い、つまり誤差とはいえない程度に低いこととしてよい。

この場合、問題個所特定部４６０は、正常機能Ｆ３及びＦ４からそれぞれｐ３を除去したＦ３＝ｐ１−ｐ２−ｐ５，Ｆ４＝ｐ１−ｐ２を修正後のパス情報とし、異常機能Ｆ１についてはｐ４ではなくｐ３を問題個所として特定することができる。この特定された結果から、事前分析フェーズでは機能Ｆ３及びＦ４がｐ３を使ったが運用フェーズでは使わなかったパターン（図４３（Ａ）のパターン）であると推測される。

以上のように、異常機能が使用するコンポーネントを、正常機能がどの程度の頻度で使用するのかという頻度情報を用いて信頼度に重み付けを行なうことにより、より信頼性の高い分析を行なうことができ、分析の精度を向上させることができる。

なお、図５５の例において、仮にｐ４の信頼度についても８５ではなく５といった有意に低い値の場合、問題個所特定部４６０は、問題個所をｐ３及びｐ４と特定し、これらの信頼度の低さに応じて問題個所を順位付けて通知してもよい。

また、図５５の例は、（方式II）ではなく（方式Ｉ）についても適用することが可能である。図５５の例を（方式Ｉ）に適用する場合、問題個所特定部４６０は、信頼度に基づき、ｐ３を使用する機能Ｆ３及びＦ４を削除すればよい。

（パス情報の修正に用いる信頼度の他の例２）
図５５の例では、事前分析フェーズにおける機能Ｆｉの呼び出し毎のコンポーネントの使用有無を頻度情報として用いたが、図５６に例示するように、機能Ｆｉを１回呼び出す際にコンポーネントを何回使うかを頻度情報として用いてもよい。

システムによっては、機能が１回呼び出される際に、同じコンポーネントが複数回使用される場合がある。事前分析ブロック４０１は、この頻度（回数）を機能毎・コンポーネント毎にカウントし、頻度情報として保存してよい。

なお、図５６に示す頻度情報に基づく信頼度の算出及びパス情報の修正の手法は、図５５を用いて説明した手法と同様であるため、説明を省略する。

図５６の例によっても、図５５の例と同様に、より信頼性の高い分析を行なうことができ、分析の精度を向上させることができる。

（パス情報の修正処理の他の例１）
問題個所特定部４６０は、削除候補（修正候補）となるコンポーネントの信頼度に有意な差がない場合、削除候補の全てのコンポーネントを削除してもよい。

例えば図５７に示すように、Ｆ２のｐ４，Ｆ３のｐ６，Ｆ４のｐ７のいずれもｐ１〜ｐ３と比較すれば有意に低いといえるが、ｐ４，ｐ６，ｐ７間では有意な差があるとはいえない。この場合、問題個所特定部４６０は、ｐ４，ｐ６，ｐ７を全て削除してよい。

なお、問題個所として絞り込んだ複数のコンポーネントの信頼度に有意な差がない場合には、問題個所特定部４６０は、図５８に例示するように、信頼度が低い順、つまり遅延原因である尤度が高い順に出力してもよい。

信頼度が低いコンポーネントは、本来使用されていない可能性が高く、遅延原因である可能性が高いため、図５８の例のように原因コンポーネントを信頼度に応じて順位付けをして出力することで、妥当性の高い分析結果を出力することができる。

また、削除候補のコンポーネントの信頼度に有意な差がない場合であっても、削除するコンポーネントの上限を予め指定しておくことで、削除対象を制限することもできる。図５７の例の場合、削除候補はＦ２のｐ４，Ｆ３のｐ６，Ｆ４のｐ７であるが、削除上限を２と設定していた場合、問題個所特定部４６０は、信頼度が低い順にＦ３のｐ６，Ｆ２のｐ４を削除すればよい。

なお、削除するコンポーネントの上限を指定しておく以外にも、有意な差があるか否かを判断する基準や削除数を判断する基準等、削除の条件を設定しておくことで、削除対象の制限を行なうことが可能である。

また、ここまで（方式II）による例を説明したが、（方式Ｉ）についても同様に、削除候補のコンポーネントの信頼度に有意な差がない場合でも、削除候補の全ての機能を削除してもよく、あるいは削除対象の機能の制限を行なってもよい。

（パス情報の修正処理の他の例２）
問題個所特定部４６０は、修正前後のパス情報の修正比率が指定値を超えた場合、矛盾状態を検出してもパス情報の修正処理を抑止してよい。

ここで、修正比率は、例えば以下のようにして算出することができる。

・全体での算出
修正数／延べコンポーネント数

・各機能Ｆｉでの算出
Ｆｉでの修正数／Ｆｉのコンポーネント数

問題個所特定部４６０は、例えば、全体での算出を行ない、算出結果の割合（修正比率）が指定値（例えば１０％）を超える場合、全体のパス情報の修正処理を行なわなくてよい。図５７の例では、修正数＝３（Ｆ２のｐ４，Ｆ３のｐ６，Ｆ４のｐ７），延べコンポーネント数＝１９であり、修正比率は１５．８％となる。この場合、修正比率が指定値を超えるため、問題個所特定部４６０は全体（Ｆ２のｐ４，Ｆ３のｐ６，Ｆ４のｐ７）の修正処理（削除）を抑止する。

また、問題個所特定部４６０は、例えば、各機能Ｆｉでの算出を行ない、算出結果の割合が指定値（例えば２０％）を超える場合、当該機能についてのパス情報の修正処理を行なわなくてよい。図５７の例では、Ｆ２について、修正数＝１（ｐ４），コンポーネント数＝４であり、修正比率は２５％となる。また、Ｆ３について、修正数＝１（ｐ６），コンポーネント数＝５であり、修正比率は２０％となる。さらに、Ｆ４について、修正数＝１（ｐ７），コンポーネント数＝４であり、修正比率は２５％となる。この場合、Ｆ３については修正比率が指定値を超えず、Ｆ２及びＦ４の修正比率が指定値を超えるため、問題個所特定部４６０は、Ｆ３についてｐ６を削除する一方、Ｆ２及びＦ４の修正処理（削除）を抑止する。

上記いずれの例についても、修正比率が指定値を超えるほど大きい場合、パス情報の修正が基準情報としてのパス情報に与える影響も大きくなる。また、全ての修正対象のコンポーネントが実際に問題個所である可能性は、修正対象のコンポーネントの数（絞り込めないコンポーネントの数）が多いほど低くなる。

そこで、修正比率が指定値を超える場合に修正処理を抑止し、不正確な（ミスリードとなり得る）分析結果が出力される可能性を低減させることで、分析結果の精度を向上させることができる。

なお、上記いずれの例についても、説明に用いた（方式II）ではなく（方式Ｉ）に適用することも可能である。

（パス情報の修正処理の他の例３）
上記の例において修正比率が指定値を超えた場合でも、このときの修正対象のコンポーネント（修正パターン）が妥当であるか否か、つまり全て問題個所であるといえるか否かを、修正後のパス情報の蓄積及び修正頻度（修正回数）の記録により明らかにしてもよい。

すなわち、問題個所特定部４６０は、修正比率が指定値を超えた場合でも、パス情報の修正処理自体は実行し、修正後のパス情報をメモリや記憶装置等に蓄積してもよい。修正比率が指定値を超えた場合の修正パターンが妥当である場合には、運用ブロック４０２の運用が進むにつれて当該修正パターンの修正回数が増加し、パス情報と置き換えられるからである。

なお、この場合、問題個所特定部４６０は、修正後のパス情報による問題個所の特定及び特定結果の出力は抑止し、修正前のパス情報による絞り込み結果のみを出力することとしてよい。

（パス情報の修正処理の他の例４）
上述した（方式Ｉ）又は（方式II）によるパス情報の修正に代えて、以下の（方式III）を用いることもできる。

（方式III）問題個所を特定できず矛盾状態を検出したタイミングを含む所定の時間区間に発生したユーザリクエストを、検証環境に再投入することでパス情報を再生成（修正）する。

例えば、運用ブロック４０２は、運用フェーズにおいても常にリクエストパケットをキャプチャしておく。また、事前分析ブロック４０１は、運用ブロック４０２が矛盾状態を検知したタイミング周辺のキャプチャデータを用いて、検証環境（事前分析フェーズ）においてアクセスを再現して詳細ログを取得し、パス情報を再生成する。

なお、問題個所特定部４６０は、再生成したパス情報によってパス情報データベース４０４のパス情報を更新してもよいし、上述したようにメモリや記憶装置等に蓄積してもよい。

これにより、矛盾状態を発生させた機能が実際に使用したコンポーネントについてのパス情報が再生成されるため、問題個所特定部４６０は、再生成されたパス情報を用いて問題個所を確実に且つ容易に特定することができる。

このように、矛盾状態を検知したときのアクセスを再現してパス情報を再生成することによっても、問題個所を特定することができ、分析結果の精度を向上させることができる。

なお、ここまで説明した各例は、（方式Ｉ）〜（方式III）に対して任意に組み合わせてよい。

以上のように、一実施形態に係る問題個所特定部４６０は、問題個所特定処理において問題個所が特定されない場合でも、所定期間に実行した各処理に係るパス情報を、所定の条件に基づき修正する。そして、問題個所特定部４６０は、正常又は異常のステートの判定結果と修正したパス情報とを用いて異常コンポーネントを特定する。これにより、複数の処理の各々が経由するコンポーネントの情報が正しくない場合でも異常コンポーネントを特定することができ、障害・トラブル発生時の問題解決の迅速化を図ることができる。

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

Claims (10)

1. コンピュータに、
   共用するモジュールが存在する複数の処理それぞれについて、各処理が経由するモジュールの情報を記憶し、
   所定期間に実行した複数の処理に関するログ情報に基づき、前記所定期間に実行した各処理の正常又は異常のステートを判定し、
   前記正常又は異常のステートの判定結果と前記所定期間に実行した各処理に係る前記モジュールの情報とを用いて異常モジュールの特定を行なう処理において、異常モジュールが特定されない場合、前記所定期間に実行した各処理に係る前記モジュールの情報を、所定の条件に基づき修正し、
   前記正常又は異常のステートの判定結果と前記修正したモジュールの情報とを用いて異常モジュールを特定する、
   処理を実行させることを特徴とする、分析プログラム。
2. 前記修正は、前記所定期間に実行した各処理に係る前記モジュールの情報から、少なくとも一つの処理に関する情報を削除することを含む、
   ことを特徴とする、請求項１記載の分析プログラム。
3. 前記修正は、前記所定期間に実行した各処理に係る前記モジュールの情報から、少なくとも一つの処理について、当該処理が経由するモジュールのうちの一部のモジュールの情報を削除することを含む、
   ことを特徴とする、請求項１記載の分析プログラム。
4. 前記修正は、前記所定期間に実行した各処理に係る前記モジュールの情報から、少なくとも一つの処理について、当該処理が経由するモジュールの情報に少なくとも一つのモジュールを追加することを含む、
   ことを特徴とする、請求項１記載の分析プログラム。
5. 前記コンピュータに、
   前記所定期間に実行した各処理に係る前記モジュールの情報に基づいて、前記判定で異常のステートと判定された処理が経由する異常候補のモジュールごとに、当該異常候補のモジュールを前記判定で正常のステートと判定された処理が経由する可能性を示す評価値を算出し、
   前記所定期間に実行した各処理に係る前記モジュールの情報から、前記評価値に基づき前記修正における修正対象の処理又はモジュールを決定する、
   処理を実行させることを特徴とする、請求項１〜４のいずれか１項記載の分析プログラム。
6. 前記評価値は、前記判定で正常のステートと判定された処理が前記異常候補のモジュールの各々を経由する頻度の情報に基づき重み付けされる、
   ことを特徴とする、請求項５記載の分析プログラム。
7. 前記コンピュータに、
   前記所定期間に実行した複数の処理に係るユーザリクエストを保存し、
   前記異常モジュールの特定を行なう処理において、異常モジュールが特定されない場合、前記保存したユーザリクエストを再実行する、
   処理を実行させ、
   前記修正は、前記再実行の結果から前記所定期間に実行した各処理が経由するモジュールの情報を再生成することを含む、
   ことを特徴とする、請求項１記載の分析プログラム。
8. 前記コンピュータに、
   前記修正したモジュールの情報が置き換え条件を満たす場合、前記記憶するモジュールの情報を、前記修正したモジュールに置き換える、
   処理を実行させることを特徴とする、請求項１〜７のいずれか１項記載の分析プログラム。
9. 共用するモジュールが存在する複数の処理それぞれについて、各処理が経由するモジュールの情報を記憶する手段と、
   所定期間に実行した複数の処理に関するログ情報に基づき、前記所定期間に実行した各処理の正常又は異常のステートを判定する手段と、
   前記正常又は異常のステートの判定結果と前記所定期間に実行した各処理に係る前記モジュールの情報とを用いて異常モジュールの特定を行なう手段と、
   前記異常モジュールの特定を行なう手段により異常モジュールが特定されない場合、前記所定期間に実行した各処理に係る前記モジュールの情報を、所定の条件に基づき修正する手段と、
   前記正常又は異常のステートの判定結果と前記修正したモジュールの情報とを用いて異常モジュールを特定する手段と、
   を備えることを特徴とする、分析装置。
10. 共用するモジュールが存在する複数の処理それぞれについて、各処理が経由するモジュールの情報を記憶し、
    所定期間に実行した複数の処理に関するログ情報に基づき、前記所定期間に実行した各処理の正常又は異常のステートを判定し、
    前記正常又は異常のステートの判定結果と前記所定期間に実行した各処理に係る前記モジュールの情報とを用いて異常モジュールの特定を行なう処理において、異常モジュールが特定されない場合、前記所定期間に実行した各処理に係る前記モジュールの情報を、所定の条件に基づき修正し、
    前記正常又は異常のステートの判定結果と前記修正したモジュールの情報とを用いて異常モジュールを特定する、
    ことを特徴とする、分析方法。

Images