(57)【要約】【課題】処理の実行時に得られるログに基づき、処理を正確に分類できるようにする。【解決手段】複数のコンポーネントを用いる処理によるリクエスト実行時に採取される複数のリクエストログ内のパラメータから、当該複数のリクエストログに共通する共通パラメータを抽出する。そして、抽出された前記共通パラメータのうち、他の処理について抽出された共通パラメータとは異なる共通パラメータを、前記処理を特定する特定パラメータとして決定する。【選択図】図１１
2015095065.tif 000002
【特許請求の範囲】
【請求項１】
複数のコンポーネントを用いる処理によるリクエスト実行時に採取される複数のリクエストログ内のパラメータから、当該複数のリクエストログに共通する共通パラメータを抽出し、
抽出された前記共通パラメータのうち、他の処理について抽出された共通パラメータとは異なる共通パラメータを、前記処理を特定する特定パラメータとして決定する、分析方法。
【請求項２】
前記複数のリクエストログ内のパラメータのうち、キーも値も共通するパラメータについては、当該キーと当該値との両方を前記共通パラメータとして抽出する、請求項１に記載の分析方法。
【請求項３】
前記複数のリクエストログ内のパラメータのうち、値は共通しないがキーは共通するパラメータについては、当該キーのみを前記共通パラメータとして抽出する、請求項１または請求項２に記載の分析方法。
【請求項４】
前記複数のリクエストログ内のパラメータの出現頻度を取得し、
前記複数のリクエストログ内のパラメータのうち、値は共通しないがキーは共通するパラメータについて取得された前記出現頻度が所定しきい値よりも高い場合、当該キーと当該値との両方を前記共通パラメータとして抽出する、請求項１〜請求項３のいずれか一項に記載の分析方法。
【請求項５】
前記出現頻度が所定しきい値よりも低い場合、当該キーのみを前記共通パラメータとして抽出する、請求項４に記載の分析方法。
【請求項６】
リクエスト毎に当該リクエストの出現頻度を取得し、
前記出現頻度が所定しきい値よりも高いリクエストについてのリクエストログ内の、当該リクエストのみに出現するパラメータを、前記共通パラメータとして抽出する、請求項１に記載の分析方法。
【請求項７】
前記共通パラメータの中から、前記処理を特定する最小パラメータもしくは最小の組合せを前記特定パラメータとして決定する、請求項１〜請求項６のいずれか一項に記載の分析方法。
【請求項８】
複数のコンポーネントを用いる処理によるリクエスト実行時に採取される複数のリクエストログ内のパラメータから、当該複数のリクエストログに共通する共通パラメータを抽出する共通パラメータ抽出部と、
前記共通パラメータ抽出部によって抽出された前記共通パラメータのうち、他の処理について抽出された共通パラメータとは異なる共通パラメータを、前記処理を特定する特定パラメータとして決定する特定パラメータ決定部と、を備えた分析装置。
【請求項９】
複数のコンポーネントを用いる処理によるリクエスト実行時に採取される複数のリクエストログ内のパラメータから、当該複数のリクエストログに共通する共通パラメータを抽出し、
抽出された前記共通パラメータのうち、他の処理について抽出された共通パラメータとは異なる共通パラメータを、前記処理を特定する特定パラメータとして決定する、
処理をコンピュータに実行させる、分析プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分析方法、分析装置、及び分析プログラムに関する。
【背景技術】
【０００２】
アプリケーションプログラムやネットワークサービス等において、実際に運用を行なっている状況下で、遅延個所や異常個所を特定することが試みられている。
【０００３】
通常、遅延個所や異常個所を特定するためには、その個所の前後のログを採取して、状態を監視し続ける必要がある。例えばstart−Ａ−Ｂ−Ｃ−Ｄ−endという処理シーケンスの場合、Ａの直前、Ａ−Ｂ間、Ｂ−Ｃ間、Ｃ−Ｄ間、Ｄの直後でタイムスタンプの付いたログが採取される。これにより、処理Ａ〜Ｄのいずれにおいて、遅延が発生しているかを特定することができる。例えば処理Ｂが遅延している場合、Ｂの直前（Ａ−Ｂ間）のログと、Ｂの直後（Ｂ−Ｃ間）のログとを参照することで、処理Ｂを遅延個所として特定することができる。
【０００４】
その一方で、アプリケーションプログラムやネットワークサービスにおいて、遅延個所や異常個所を特定するためには、多数の監視個所で大量のログを採取する必要がある。このため、遅延箇所や異常個所の絞込みや特定には、多大なオーバヘッド及びネットワーク負荷が発生する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−２６０７８号公報
【特許文献２】特開２０１０−６７０４７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
運用時に余分なオーバヘッドやネットワーク負荷を発生させることなく問題個所を特定するために、事前に詳細なログを採取分析して機能（処理）毎のパス情報を取得することが試みられている。この場合、運用時には、事前に取得されたパス情報を用いて問題個所の分析特定が行なわれる。ここで、パス情報は、例えば、各機能で使用されるコンポーネントを特定する情報（コンポーネント群）を含む。このとき、Ｗｅｂ（ウエブ）の機能毎のパス情報は、例えば、ＵＲＬ（Uniform Resource Locator）を含むＵＲＩ（Uniform Resource Identifier）によって分類される。
【０００７】
例えば図２０に示すごとくｐ１〜ｐ５をネットワークコンポーネントとした場合、各コンポーネントｐ１〜ｐ５を流れるメッセージデータを分析することで、各機能Ｆｉ（ｉは自然数）で用いられるコンポーネントは、各機能Ｆｉに対応するＵＲＩを用いて、以下のように機能Ｆｉ毎に分類される。
機能Ｆ１のパス＝ｐ１−ｐ２−ｐ４−ｐ５
機能Ｆ２のパス＝ｐ１−ｐ３−ｐ５
機能Ｆ３のパス＝ｐ１−ｐ２
機能Ｆ４のパス＝ｐ３−ｐ４
【０００８】
このとき、ＵＲＩにはＩＤ（IDentification）などのパラメータが含まれているため、パラメータの組合せにより膨大な数の異なるＵＲＩが出現することになる。例えば図２１に示すように、ＵＲＩがパラメータとしてuid（ユーザＩＤ）を含む場合、uidの値は無限に存在するため、無限のＵＲＩが出現することになる。
【０００９】
このようなＩＤなどのパラメータがＵＲＩに含まれると、異なるＩＤをもつＵＲＩは、それぞれ異なる処理として分類されてしまう。例えば、同じ処理に対応するＵＲＩであっても、各ＵＲＩが異なるユーザＩＤを有する場合、各ＵＲＩは、異なる処理として分類されてしまう。このため、パス情報のデータ量は膨大なものになる。
【００１０】
一つの側面で、本発明は、処理の実行時に得られるログに含まれる適切なパラメータによって、処理を正確に分類できるようにすることを目的とする。
なお、前記目的に限らず、後述する発明を実施するための最良の形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本件の他の目的の一つとして位置付けることができる。
【課題を解決するための手段】
【００１１】
本件の分析方法は、複数のコンポーネントを用いる処理によるリクエスト実行時に採取される複数のリクエストログ内のパラメータから、当該複数のリクエストログに共通する共通パラメータを抽出する。そして、本件の分析方法は、抽出された前記共通パラメータのうち、他の処理について抽出された共通パラメータとは異なる共通パラメータを、前記処理を特定する特定パラメータとして決定する。
【発明の効果】
【００１２】
一実施形態によれば、処理の実行時に得られるログに含まれる適切なパラメータによって、処理を正確に分類することができる。
【図面の簡単な説明】
【００１３】
【図１】本実施形態に係る分析装置を適用されるネットワークシステムの一例を示すブロック図である。
【図２】本実施形態に係る分析装置のハードウエア構成及び機能構成を示すブロック図である。
【図３】本実施形態に係るアクセスログの一例を示す図である。
【図４】本実施形態に係る詳細ログの一例を示す図である。
【図５】本実施形態に係るコンポーネント定義の一例を示す図である。
【図６】本実施形態に係るパス表の一例を示す図である。
【図７】本実施形態に係るパラメータ表の一例を示す図である。
【図８】本実施形態に係るパス情報の一例を示す図である。
【図９】本実施形態に係る分析装置の動作を説明するフローチャートである。
【図１０】本実施形態に係るフロー解析処理（パス表作成処理）の手順を説明するフローチャートである。
【図１１】本実施形態に係るパラメータ抽出処理（パラメータ表作成処理）の手順を説明するフローチャートである。
【図１２】本実施形態に係る共通パラメータ抽出処理の手順を説明するフローチャートである。
【図１３】本実施形態に係る特定パラメータ抽出処理の手順を説明するフローチャートである。
【図１４】本実施形態に係るフロー解析処理を具体的に説明する図である。
【図１５】本実施形態に係るフロー解析処理を具体的に説明する図である。
【図１６】本実施形態に係るパラメータ抽出処理及びパラメータ加工処理を具体的に説明する図である。
【図１７】第１及び第２変形例の分析装置のハードウエア構成及び機能構成を示すブロック図である。
【図１８】第１変形例の分析装置におけるパラメータ抽出処理及びパラメータ加工処理を具体的に説明する図である。
【図１９】第２変形例の分析装置におけるパラメータ抽出処理及びパラメータ加工処理を具体的に説明する図である。
【図２０】機能（処理）とコンポーネント群（パス）との対応関係（パス情報）の一例を示す図である。
【図２１】ユーザＩＤをパラメータとして含むＵＲＩの例を示す図である。
【発明を実施するための形態】
【００１４】
以下に、図面を参照し、本願の開示する分析方法、分析装置、及び分析プログラムの実施形態について、詳細に説明する。ただし、以下に示す実施形態は、あくまでも例示に過ぎず、実施形態で明示しない種々の変形例や技術の適用を排除する意図はない。すなわち、本実施形態を、その趣旨を逸脱しない範囲で種々変形して実施することができる。また、各図は、図中に示す構成要素のみを備えるという趣旨ではなく、他の機能を含むことができる。そして、各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
【００１５】
〔１〕本実施形態の構成
図１〜図８を参照しながら、本実施形態の構成について説明する。
〔１−１〕本実施形態に係るネットワークシステムの構成
まず、図１を参照しながら、本実施形態に係る分析装置１００を適用されるネットワークシステムの構成について説明する。なお、図１は、本実施形態に係る分析装置１００を適用されるネットワークシステムの一例を示すブロック図である。
【００１６】
図１に示すネットワークシステムは、例えば、インターネット等のネットワーク１０、当該ネットワーク１０に接続されるサーバ群２０，３０及び４０、ネットワークスイッチ（ＮＳ）５０、並びに、分析装置１００及び２００等を含んでいる。サーバ群２０，３０及び４０には、例えば、Ｗｅｂサーバ３０や、アプリケーション（ＡＰ）サーバ４０、その他のサーバ２０等が含まれる。
【００１７】
ＡＰサーバ４０は、例えば、ＣＰＵ（Cenrtral Processing Unit）等の処理部、ＲＯＭ（Read Only Memory），ＲＡＭ（Random Access Memory）等のメモリ、ＨＤＤ（Hard Disk Drive），ＳＳＤ（Solid State Drive）等の記憶装置、ＬＣＤ（Liquid Crystal Display）等の表示装置、印刷装置などを備えている。ＡＰサーバ４０においては、ＣＰＵがメモリや記憶装置から所定のアプリケーションプログラム（図２の符号４１参照）を読み出して実行することにより、各種機能が実現される。表示装置や印刷装置には、例えばＣＰＵによる演算結果等を出力することができる。なお、他のサーバ２０やＷｅｂサーバ３０についても、ハードウェア的には、上述と同様のＣＰＵ，メモリ，記憶装置，表示装置，印刷装置などが備えられる。
【００１８】
分析装置１００は、事前分析フェーズにおいて、後述するパス情報１２７を生成する。また、分析装置２００は、運用フェーズにおいて、分析装置１００によって事前に生成されたパス情報１２７に基づき問題箇所を特定する。なお、分析装置１００及び２００としての機能は、それぞれ、本実施形態のネットワークシステムに含まれるＰＣ（Personal Computer）等の処理装置によって実現されてもよいし、本実施形態のネットワークシステムに含まれるＡＰサーバ４０等によって実現されてもよい。また、分析装置１００及び２００としての機能は、一台の処理装置、もしくは、一台のＡＰサーバ４０等によって実現されてもよい。
【００１９】
分析装置１００は、図２を参照しながら後述するように、図示しないユーザリクエストデータベースのデータ（リクエスト等）を仮想ユーザのデータとしてネットワーク１０に投入することでＡＰサーバ４０等から出力されるリクエストログを採取する。そして、分析装置１００は、図２を参照しながら後述するように、採取されたリクエストログに基づき、後述するパス情報１２７を生成する。
【００２０】
また、分析装置２００は、運用フェーズにおいて、実運用でサーバ群２０，３０，４０を流れるデータから例えばＵＲＬ＋ＣＧＩ（Common Gateway Interface）パラメータ等をログデータ（後述するリクエストログ）として採取する。分析装置２００は、採取されたログデータを、分析装置１００によって得られたパス情報１２７と照らし合わせて、ログデータの機能選別（分類）を行なう。そして、分析装置２００は、例えば、選別された各機能で正常と異常とが混在しない時間区間を切り出す処理（ステートの変化タイミングを演算する処理）を実施する。この後、分析装置２００は、切り出された時間区間について遅延の検知を行ない、遅延を検知した場合はパス情報１２７と照らし合わせて問題個所の絞込み又は特定を行なう。
【００２１】
本実施形態においては、事前分析フェーズ用の分析装置１００が、本件特有の技術に係るものであり、以下では、事前分析フェーズ用の分析装置１００の構成，機能，動作等について詳細に説明する。
【００２２】
〔１−２〕本実施形態に係る分析装置の構成
続いて、図２を参照しながら、本実施形態に係る分析装置１００の構成について説明する。図２は、本実施形態の分析装置１００のハードウエア構成及び機能構成を示すブロック図である。分析装置１００は、上述したように、ＡＰサーバ４０等、又は、サーバ群２０，３０，４０とは別体の処理装置に備えられている。本実施形態において、分析装置１００は、サーバ群２０，３０，４０とは別体の処理装置に備えられているものとする。
【００２３】
分析装置１００は、ＣＰＵ，ＭＰＵ（Micro-Processing Unit），コンピュータ等の処理部１１０と、ＲＡＭ，ＨＤＤ等の記憶部１２０とを有している。処理部１１０は、記憶部１２０から所定のアプリケーションプログラム（分析プログラム）を読み出して実行することで、後述するログ採取部１１１，フロー解析部１１２，パラメータ抽出部１１３，パラメータ加工部１１４としての機能を実現する。また、記憶部１２０は、前記所定のアプリケーションプログラムを保存するほか、処理部１１０による事前分析処理に必要な各種情報を保存する。記憶部１２０は、当該各種情報として、例えば、ログ定義１２１，アクセスログ１２２，詳細ログ１２３，コンポーネント定義１２４，パス表１２５，パラメータ表１２６，パス情報１２７を保存する。
【００２４】
前記所定のアプリケーションプログラムは、例えばフレキシブルディスク，ＣＤ（ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＣＤ−ＲＷなど），ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，ＤＶＤ−Ｒ，ＤＶＤ−ＲＷ，ＤＶＤ＋Ｒ，ＤＶＤ＋ＲＷなど），ブルーレイディスク等のコンピュータ読取可能な記録媒体に記録された形態で提供される。この場合、処理部１１０は、当該記録媒体からプログラムを読み取って内部記憶装置または外部記憶装置に転送し格納して用いる。
【００２５】
本実施形態では、分析装置２００において運用時に余分なオーバヘッドやネットワーク負荷を発生させることなく問題個所を特定するために、分析装置１００が、事前に詳細なログを採取分析して機能（処理）毎のパス情報１２７を生成して取得している。ここで、パス情報１２７は、例えば、各機能で使用されるコンポーネントを特定する情報（コンポーネント群）を含む。このとき、Ｗｅｂの機能毎のパス情報１２７は、例えばＵＲＩ（ＵＲＬ）によって分類される。
【００２６】
例えば図２０を参照しながら前述したように、各コンポーネントｐ１〜ｐ５を流れるメッセージデータを分析することで、各機能Ｆｉ（ｉは自然数）で用いられるコンポーネントは、各機能Ｆｉに対応するＵＲＩを用いて、機能Ｆｉ毎に分類される。なお、コンポーネントｐ１〜ｐ５は、プログラムのメソッド単位、ブロック単位として処理することもできる。「コンポーネント」という用語は、「モジュール」あるいは「チェックポイント」という用語に置き換えて使用する場合がある。また、「パス」は、「コンポーネント」の集合（コンポーネント群）として位置付けられる。各機能（処理）Ｆｉと複数のコンポーネントｐ１〜ｐ５との対応関係を示す情報のことを「パス情報」と呼ぶ。
【００２７】
ここで、運用フェーズで用いられる分析装置２００による問題箇所（異常個所）の特定機能について、簡単に説明する。図２０に示す例において、通常時に比べ機能Ｆ１及びＦ２が遅延した場合、分析装置２００は、パス情報１２７に照らし合わせることで機能Ｆ１及びＦ２に対応するコンポーネントｐ１，ｐ２，ｐ３，ｐ４，ｐ５が問題（異常）の可能性をもつと判断することができる。さらに、分析装置２００は、例えば、機能Ｆ３及びＦ４は遅延していないという情報と、機能Ｆ３及びＦ４のパス情報１２７とにより、機能Ｆ１，Ｆ２及びＦ３の共通コンポーネントｐ１，ｐ２，ｐ３，ｐ４には問題がないと判断することができる。その結果、分析装置２００は、残ったコンポーネントｐ５を遅延の原因個所として特定することができる。
【００２８】
なお、分析対象がプログラムの場合、コンポーネントｐ１〜ｐ５は、以下のように、メソッド（関数）呼出し単位、ブロック単位、利用者指定のログ出力個所単位、あるいはこれらのいずれかの組み合わせを単位として処理することができる。
【００２９】
・メソッド（関数）呼出し単位
ｐ１＝method1()→ｐ２＝method2()→ｐ４＝method3()等
・ブロック単位（ｉｆ文や｛｝などで区分けされたブロック）
ｐ１＝while(..)→ｐ２＝if ()...→ｐ４=else...等
・利用者指定のログ出力個所単位
ｐ１＝{file=foo.java,line=35}→ｐ２＝{file=foo.java,line=55}→ｐ４＝{file=boo.java,line=20}等
【００３０】
本実施形態の分析装置１００は、上述した通り、事前分析フェーズにおいて、パス情報１２７を生成すべくネットワークシステムにおけるＡＰサーバ４０等からリクエストログを採取する。このため、本実施形態では、事前分析フェーズにおいて、利用者６０が手動でネットワーク１０経由でリクエストを、ＡＰサーバ４０で稼働するアプリケーションプログラム（以下、単にアプリケーションという）４１に発行する。もしくは、リクエスト発行部６０が自動でネットワーク１０経由でリクエストをＡＰサーバ４０のアプリケーション４１に発行する。リクエストを受けたＡＰサーバ４０では、当該リクエストに応じた処理が、アプリケーション４１によって実行され、当該リクエストに対応するリクエストログが、ログ出力部４２から分析装置１００へ出力される。なお、事前分析フェーズにおいては、他のサーバ２０やＷｅｂサーバ３０からも同様にしてリクエストログがログ出力部４２から分析装置１００へ出力される。
【００３１】
ついで、処理部１１０によって実現される、ログ採取部１１１，フロー解析部１１２，パラメータ抽出部１１３，パラメータ加工部１１４としての機能について、図２〜図８を参照しながら説明する。
【００３２】
ログ採取部１１１は、ＡＰサーバ４０等のログ出力部４２から、リクエストログをリクエスト毎に採取する。各リクエストログは、一のアクセスログと当該一のアクセスログに対応する複数の詳細ログとを含む。このとき、ＡＰサーバ４０等に組み込んだログ出力部４２は、ログ定義１２１に従って、アプリケーション４１へのリクエストに応じたアクセスログ１２２及び詳細ログ１２３を、ログ採取部１１１へ出力する。もしくは、ログ採取部１１１は、記憶部１２０のログ定義１２１を参照し、ログ定義１２１に従って、アプリケーション４１へのリクエストに応じたアクセスログ１２２及び詳細ログ１２３を、ログ出力部４２経由で採取する。ログ採取部１１１によってリクエスト毎に採取されたアクセスログ１２２及び詳細ログ１２３は、記憶部１２０に保存される。ここで、ログ定義１２１は、詳細ログとして出力すべき出力対象のクラスやパッケージを指定する情報であり、ログ出力部４２もしくは記憶部１２０に予め設定されている。
【００３３】
図３は、本実施形態に係るアクセスログ１２２の一例を示す図である。アクセスログ１２２は、ログ出力部４２によって出力されるもので、アプリケーション４１へのアクセスログである。アクセスログ１２２には、例えば、ＵＲＩ，トランザクションＩＤ（以下TranＩＤと表記），処理時間などが含まれる。なお、図３において、例えば１行目のアクセスログにおける“308378505-httpWorkerThread-28080-0-1”はTranＩＤである。
【００３４】
図４は、本実施形態に係る詳細ログ１２３の一例を示す図である。詳細ログ１２３は、ログ出力部４２によって出力され、アクセスログ１２２に対応付けられる、アクセスログ１２２の詳細ログである。詳細ログ１２３には、例えば、時刻，TranＩＤ，クラス，メソッドなどが含まれる。なお、図４に示すように、各詳細ログ１２３は、TranＩＤによって一のアクセスログ１２２に対応付けられている。例えば、図４の１〜３及び５行目の詳細ログは、TranＩＤ“308378505-httpWorkerThread-28080-0-1”によって図３の１行目のアクセスログに対応付けられている。また、図４の４及び６行目の詳細ログは、TranＩＤ“308378505-httpWorkerThread-28080-15-1”によって図３の２行目のアクセスログに対応付けられている。
【００３５】
フロー解析部１１２は、アクセスログ１２２，詳細ログ１２３及びコンポーネント定義１２４に基づき、ＵＲＩ（リクエスト）毎のフロー解析を行ない、パス表１２５を生成する。フロー解析部１１２は、コンポーネント種別取得部１１２ａ及びパス表作成部１１２ｂを含む。フロー解析部１１２による処理（パス表作成処理）の手順については、図１０を参照しながら後述する。
【００３６】
コンポーネント種別取得部１１２ａは、ＵＲＩ（リクエスト，アクセスログ；機能／処理）毎に、当該ＵＲＩのTranＩＤによって、当該ＵＲＩに対応する複数の詳細ログ１２３を抽出する。また、コンポーネント種別取得部１１２ａは、抽出された複数の詳細ログ１２３のそれぞれに含まれる記述に基づき、複数のコンポーネント（例えばｐ１，ｐ２，…）のうち、各詳細ログに対応する対応コンポーネントの種別（ｐ１，ｐ２，…のいずれか一つ）を取得する。このとき、コンポーネント種別取得部１１２ａは、記憶部１２０に予め設定されたコンポーネント定義１２４を用いて、対応コンポーネントの種別を取得する。コンポーネント種別取得部１１２ａによる詳細ログ１２３の抽出処理の具体例については、図１４を参照しながら後述する。また、コンポーネント種別取得部１１２ａによるコンポーネント種別取得処理の具体例については、図１５を参照しながら後述する。
【００３７】
コンポーネント定義１２４は、詳細ログ１２３をまとめてコンポーネント（ｐ１，ｐ２，…のいずれか一つ）として処理する単位を指定する。より具体的に、コンポーネント定義１２４は、詳細ログ１２３に含まれる情報から、パス情報１２７の分類を作り出すための定義であり、複数の詳細ログ１２３のそれぞれに含まれる記述とコンポーネントの種別（ｐ１，ｐ２，…のいずれか一つ）とを対応付ける。
【００３８】
図５は、本実施形態に係るコンポーネント定義１２４の一例を示す図である。図５に示すコンポーネント定義１２４では、詳細ログ１２３の記述“com/foo/pkg/servlet”がコンポーネントｐ１に対応し、詳細ログ１２３の記述“com/foo/pkg/kernel”がコンポーネントｐ２に対応するように、コンポーネント定義１２４が設定されている。また、詳細ログ１２３の記述“com/foo/pkg/log”がコンポーネントｐ３に対応し、詳細ログ１２３の記述“org/hibernate/Session”がコンポーネントｐ４に対応するように、コンポーネント定義１２４が設定されている。
【００３９】
パス表作成部（対応表作成部）１１２ｂは、ＵＲＩ（リクエスト；機能／処理）毎に、各ＵＲＩについて取得された対応コンポーネントの種別と、対応するアクセスログに含まれるパラメータに係る記述とを対応付けるパス表（対応表）１２５を作成する。パス表作成部１１２ｂによって作成されたパス表１２５は、記憶部１２０に保存される。パス表作成部１１２ｂによる処理の具体例については、図１５を参照しながら後述する。
【００４０】
パス表１２５は、上述の通り、各ＵＲＩについて取得された対応コンポーネントの種別と、対応するアクセスログに含まれるパラメータに係る記述とを対応付ける。より具体的に、パス表１２５は、パラメータを含むＵＲＩと、そのＵＲＩのリクエスト実行時に使用されるコンポーネント群（パス）との対応関係を保存する。パラメータには、キーと当該キーの値とが含まれる。
【００４１】
図６は、本実施形態に係るパス表１２５の一例を示す図である。図６に示すパス表１２５の各行は、図３に示すアクセスログ１２２の各行に対応している。例えば、パス表１２５の１行目には、パスＩＤを示す“１”と、コンポーネント群（パス）“ｐ１：ｐ２：ｐ３：ｐ４”と、パラメータを含むＵＲＩ“http://foo.com/?fid=3&tab=2”とが対応付けられている。ここで、“fid=3&tab=2”がパラメータであり、“fid=”及び“tab=”がキーであり、“3”及び“2”がそれぞれキー“fid=”及び“tab=”の値である。図６に示す例において、パスＩＤ“１”はパス“ｐ１：ｐ２：ｐ３：ｐ４”に対応し、パスＩＤ“２”はパス“ｐ１：ｐ４：ｐ５：ｐ７：ｐ８”に対応し、パスＩＤ“３”はパス“ｐ３：ｐ８：ｐ９”に対応している。また、パスＩＤ“１”には、異なるパラメータを有する３つのＵＲＩ（アクセスログ）が対応し、パスＩＤ“２”には、異なるパラメータを有する２つのＵＲＩ（アクセスログ）が対応し、パスＩＤ“３”には、１つのＵＲＩ（アクセスログ）が対応している。
【００４２】
パラメータ抽出部１１３は、パス表１２５に基づき、パス（つまり機能／処理）を特定する特定パラメータを選別し、選別された特定パラメータをパラメータ表１２６として出力し記憶部１２０に保存する。パラメータ抽出部１１３は、共通パラメータ抽出部１１３ａ及び特定パラメータ抽出部１１３ｂを含む。パラメータ抽出部１１３による処理（パラメータ表作成処理）の手順については、図１１〜図１３を参照しながら後述する。
【００４３】
共通パラメータ抽出部１１３ａは、複数のコンポーネントを用いる機能Ｆｉによるリクエスト実行時に採取される複数のリクエストログ内のパラメータから、当該複数のリクエストログに共通する共通パラメータを抽出する。より具体的に、共通パラメータ抽出部１１３ａは、パスＩＤ（機能Ｆｉ）毎に、同じパスＩＤに対応する複数のＵＲＩに共通するパラメータを、共通パラメータとして抽出する。
【００４４】
このとき、共通パラメータ抽出部１１３ａは、フロー解析部１１２によって作成されたパス表１２５に基づき、複数のＵＲＩ内のパラメータから共通パラメータを抽出する。また、共通パラメータ抽出部１１３ａは、ＵＲＩ内のパラメータのうち、キーも当該キーの値も共通するパラメータについては、当該キーと当該値との両方を共通パラメータとして抽出する。さらに、共通パラメータ抽出部１１３ａは、ＵＲＩ内のパラメータのうち、キーの値は共通しないがキーは共通するパラメータについては、当該キーのみを共通パラメータとして抽出する。
【００４５】
なお、共通パラメータ抽出部１１３ａによる処理の手順については、図１２を参照しながら後述する。また、共通パラメータ抽出部１１３ａによる処理の具体例については、図１６を参照しながら後述する。
【００４６】
特定パラメータ抽出部１１３ｂは、共通パラメータ抽出部１１３ａによって抽出された共通パラメータのうち、機能Ｆｉ以外の他の機能（注目パスＩＤと異なるパスＩＤ）について抽出された共通パラメータとは異なる共通パラメータを、機能Ｆｉを特定する特定パラメータとして決定する。このとき、特定パラメータ抽出部１１３ｂは、共通パラメータの中から、機能Ｆｉ（パス／パスＩＤ）を特定する最小パラメータもしくは最小の組合せを、特定パラメータとして決定する。また、特定パラメータ抽出部１１３ｂによって決定された特定パラメータは、パラメータ表１２６として記憶部１２０に保存される。
【００４７】
なお、特定パラメータ抽出部１１３ｂによる処理の手順については、図１３を参照しながら後述する。また、特定パラメータ抽出部１１３ｂによる処理の具体例については、図１６を参照しながら後述する。
【００４８】
パラメータ表１２６は、ＣＧＩパラメータのキーやＰＯＳＴメソッドのパラメータなどのうち、機能Ｆｉ（パス／パスＩＤ）を特定する最小パラメータを保存する。ここで、例えば図１６に示す通り、パスＩＤ“１”（機能Ｆ１）を特定するパラメータが“tab=”、パスＩＤ“２”（機能Ｆ２）を特定するパラメータが“col=5”、パスＩＤ“３”（機能Ｆ３）を特定するパラメータが“col=4”である場合のパラメータ表１２６について説明する。この場合、特定パラメータ“tab=”を有するＵＲＩは、“tab=”の値に関係なく、パスＩＤ“１”（機能Ｆ１）に対応すると判断できる。また、特定パラメータ“col=5”を有するＵＲＩはパスＩＤ“２”（機能Ｆ２）に対応すると判断でき、特定パラメータ“col=4”を有するＵＲＩはパスＩＤ３（機能Ｆ３）に対応すると判断できる。
【００４９】
図７は、本実施形態に係るパラメータ表１２６の一例を示す図である。図７に示すパラメータ表１２６は、上述のように抽出された特定パラメータ“tab=”，“col=5”，“col=4”をまとめて記述したものである。パラメータ表１２６の記述“use, col”は、キーが“col=”であるパラメータ“col=x”についてはキー“col=”も当該キーの値“x”もパス情報として用いることを指示する。また、パラメータ表１２６の記述“delvalue, tab”は、パラメータ“tab=y”についてはキー“tab=”のみパス情報として用い、当該キー“tab=”の値“y”を捨てることを指示する。
【００５０】
パラメータ加工部１１４は、特定パラメータ抽出部１１２ｂによって決定された特定パラメータ（本実施形態ではパラメータ表１２６）に基づき、パス表１２５を加工する。パラメータ加工部１１４は、パス表１２５にパラメータ表１２６を適用してパス表１２５を加工することで、必要最小限のパラメータを含むＵＲＩ記述（処理）とパスＩＤ（複数のコンポーネント；コンポーネント群）との関係を示すパス情報１２７を生成する。パラメータ加工部１１４によって得られたパス情報１２７は、記憶部１２０に保存される。パラメータ加工部１１４による処理の具体例については、図１６を参照しながら後述する。
【００５１】
図８は、本実施形態に係るパス情報１２７の一例を示す図である。図８に示すパス情報１２７は、図６に示すパス表１２５に、図７に示すパラメータ表１２６を適用してパス表１２５を加工することで得られる。つまり、図６のパスＩＤ“１”の３つのＵＲＩは一つにまとめられ、当該ＵＲＩにおけるパラメータ記述は、図７のパラメータ表１２６を適用することで“tab=”のみに書き換えられる。また、図６のパスＩＤ“２”の２つのＵＲＩは一つにまとめられ、当該ＵＲＩにおけるパラメータ記述は、図７のパラメータ表１２６を適用することで“col=5”のみに書き換えられる。さらに、図６のパスＩＤ“３”のＵＲＩにおけるパラメータ記述は、図７のパラメータ表１２６を適用することで“col=4”のみに書き換えられる。したがって、分析装置２００は、実運用時に採取されたログデータにおけるＵＲＩ＋ＣＧＩパラメータと、パス情報１２７とを照らし合わせることで、当該ログデータを、対応するパス（機能／処理）に容易に選別することができる。
【００５２】
〔２〕本実施形態の動作
次に、図９〜図１６を参照しながら、本実施形態の動作について説明する。
〔２−１〕本実施形態に係る分析装置の動作の概要
まず、本実施形態に係る分析装置１００の動作の概要（要点）について説明する。分析装置１００は、基本的な動作として、下記項目（１）〜（３）に記載した動作を行なう。
【００５３】
（１）分析装置１００は、ＡＰサーバ４０等のリクエスト実行時のアクセスログ及び詳細ログをリクエスト毎に取得し、アクセスログ及び詳細ログに基づくフロー解析を行ない、リクエスト毎にコンポーネントを機能単位に分類する。ここで、「機能単位に分類」は、リクエスト毎に使用されるコンポーネント群（つまりパス）を分類することをいう。例えば、リクエスト１がコンポーネントｐ１，ｐ２，ｐ３，ｐ４を実行する場合、リクエスト１について分類される「コンポーネント群」はｐ１，ｐ２，ｐ３，ｐ４である。同様に、リクエスト２がコンポーネントｐ３，ｐ８，ｐ９を実行する場合、リクエスト２について分類される「コンポーネント群」はｐ３，ｐ８，ｐ９である。項目（１）に係る具体的な動作については図１４及び図１５を参照しながら後述する。
【００５４】
（２）分析装置１００は、リクエストログ（アクセスログ／ＵＲＩ）と機能単位（コンポーネント群／パス）とを対応付ける。これにより、分析装置１００は、パス表１２５を作成する。項目（２）に係る具体的な動作については図１５を参照しながら後述する。
【００５５】
（３）分析装置１００は、リクエストログ（アクセスログ／ＵＲＩ）内のパラメータから、機能単位（コンポーネント群／パス）を特定する特定パラメータを抽出する。パラメータは、上記項目（２）で作成されるパス表１２５に保存されている。項目（３）に係る具体的な動作については図１６を参照しながら後述する。
【００５６】
一般に、通常のＨＴＴＰ（HyperText Transfer Protocol）ログ等には、機能を特定するために必要な情報が含まれておらず、パラメータの選別を行なうことは困難である。これに対し、本実施形態の分析装置１００は、上記項目（２）のフロー解析により、各リクエストがどのコンポーネント群（機能セット；パス）を使用しているかを分類することを可能にする。即ち、本実施形態の分析装置１００は、各リクエストと機能（処理）との対応付けを行なうことにより、リクエストを特徴付けるパラメータ（特定パラメータ）を選別することを可能にする。
【００５７】
例えば、下記のように、異なるパラメータをもつ３つのＵＲＩが、それぞれ、機能単位“ｐ１:ｐ２:ｐ３”，“ｐ１:ｐ２:ｐ３”，“ｐ２:ｐ４:ｐ５”に対応付けられているものとする。この場合、パラメータ“fid=3”か“fid=2”が機能単位“ｐ１:ｐ２:ｐ３”と“ｐ２:ｐ４:ｐ５”とを区別するキー（特定パラメータ）になっていることが分かる。
http://foo.com/?fid=3&tab=2&uid=3523 → ｐ１:ｐ２:ｐ３
http://foo.com/?fid=3&tab=5&uid=9246 → ｐ１:ｐ２:ｐ３
http://foo.com/?fid=2&tab=2&uid=9246 → ｐ２:ｐ４:ｐ５
【００５８】
〔２−２〕本実施形態に係る分析装置の動作
次に、図９に示すフローチャート（ステップＳ１〜Ｓ５）に従って、本実施形態に係る分析装置１００の動作について説明する。
【００５９】
分析装置１００は、事前分析フェーズにおいて、ユーザ／リクエスト発行部６０に対しリクエスト発行指示を行なうことで、ネットワーク１０経由でリクエストをＡＰサーバ４０のアプリケーション４１に発行する（ステップＳ１）。リクエストを受けたＡＰサーバ４０では、当該リクエストに応じた処理が、アプリケーション４１によって実行され、当該リクエストに対応するリクエストログが、ログ出力部４２から分析装置１００へ出力される。なお、リクエストは、例えばユーザリクエストデータベース（図示略）に予め用意したリクエストデータを再生することで発行される。リクエストの発行処理は、所定の終了条件が満たされるまで繰り返される。なお、リクエストデータとしては、実運用時に採取したものや、テストデータとして生成したもの等を用いることができる。
【００６０】
そして、ログ採取部１１１は、リクエスト毎に、一のアクセスログ１２２と当該アクセスログ１２２に対応する複数の詳細ログ１２３とを含むリクエストログを、ＡＰサーバ４０等のログ出力部４２から受信し採取する（ステップＳ２）。このとき、採取されるアクセスログ１２２や詳細ログ１２３は、ログ定義１２１に従った内容を含んでいる。ログ採取部１１１によってリクエスト毎に採取されたアクセスログ１２２及び詳細ログ１２３は記憶部１２０に保存される。
【００６１】
この後、フロー解析部１１２は、アクセスログ１２２，詳細ログ１２３及びコンポーネント定義１２４に基づき、ＵＲＩ（リクエスト）毎のフロー解析を行ない、パス表１２５を生成する（ステップＳ３）。前述した通り、パス表１２５は、パラメータを含むＵＲＩと、そのＵＲＩのリクエスト実行時に使用されるコンポーネント群（パス）との対応関係を保存する。パラメータには、キーと当該キーの値とが含まれる。フロー解析部１１２によって作成されたパス表１２５は、記憶部１２０に保存される。ステップＳ３での処理手順、つまりフロー解析部１１２による処理（パス表作成処理）の手順については、図１０を参照しながら後述する。
【００６２】
ついで、パラメータ抽出部１１３は、ステップＳ３で作成されたパス表１２５に基づいて、パス（機能／処理）を特定する特定パラメータを選別する（ステップＳ４）。パラメータ抽出部１１３によって選別された特定パラメータは、パラメータ表１２６として出力され記憶部１２０に保存される。ステップＳ４での処理手順、つまりパラメータ抽出部１１３による処理（パラメータ表作成処理）の手順については、図１１〜図１３を参照しながら後述する。
【００６３】
そして、パラメータ加工部１１４は、ステップＳ３で作成されたパス表１２５に、ステップＳ４で作成されたパラメータ表１２６を適用して、パス表１２５を加工することで、パス情報１２７を生成する（ステップＳ５）。前述した通り、パス情報１２７は、必要最小限のパラメータを含むＵＲＩ記述（処理／機能）とパスＩＤ（複数のコンポーネント；コンポーネント群）との関係を示す。パラメータ加工部１１４によって得られたパス情報１２７は、記憶部１２０に保存される。
【００６４】
〔２−３〕本実施形態に係るフロー解析処理（パス表作成処理）の手順
次に、図１０に示すフローチャート（ステップＳ１１〜Ｓ１４）に従って、本実施形態に係るフロー解析処理（パス表作成処理；図９のステップＳ３の処理）の手順について説明する。
【００６５】
まず、フロー解析部１１２のコンポーネント種別取得部１１２ａは、アクセスログ１２２を一つずつ参照し、未処理のアクセスログつまり未処理のリクエストが有るか否かを判断する（ステップＳ１１）。未処理のリクエストが有る場合（ステップＳ１１のＹＥＳルート）、コンポーネント種別取得部１１２ａは、未処理のリクエストのアクセスログ１２２の一つを参照する。そして、コンポーネント種別取得部１１２ａは、当該アクセスログのTranＩＤによって当該アクセスログに対応する複数の詳細ログ１２３を抽出する（ステップＳ１２；図１４及び図１５の矢印Ａ１参照）。
【００６６】
この後、コンポーネント種別取得部１１２ａは、抽出された複数の詳細ログ１２３のそれぞれに含まれる記述に基づき、複数のコンポーネントのうち、各詳細ログに対応する対応コンポーネントの種別を取得する（ステップＳ１３；図１５の矢印Ａ２〜Ａ５参照）。このとき、コンポーネント種別取得部１１２ａは、記憶部１２０に予め設定されたコンポーネント定義１２４を用いて、対応コンポーネントの種別を取得する（図１５の矢印Ａ３，Ａ４参照）。なお、対応コンポーネントの種別は、例えば、コンポーネントＩＤであるｐ１，ｐ２，…のいずれか一つである。
【００６７】
ついで、パス表作成部１１２ｂは、アクセスログ（リクエスト；ＵＲＩ；機能／処理）毎に、パス表１２５を作成する（ステップＳ１４）。パス表１２５は、コンポーネント種別取得部１１２ａによって取得されたコンポーネントＩＤと、対応するアクセスログに含まれるパラメータに係る記述（パラメータ記述）とを対応付ける（図１５の矢印Ａ６，Ａ７参照）。ここで、コンポーネント種別取得部１１２ａによって取得されたコンポーネントＩＤは、リクエスト実行時に使用されるコンポーネント群（パス）であり、パラメータ記述は、アクセスログにおける、パラメータを含むＵＲＩである。
【００６８】
フロー解析部１１２は、ステップＳ１４の処理を終了すると、ステップＳ１１に戻り、未処理のリクエストの有無を判断する。ステップＳ１１〜Ｓ１４の処理は、ステップＳ１１で未処理のリクエストが無いと判断されるまで繰り返し実行される。未処理のリクエストが無いと判断されると（ステップＳ１１のＮＯルート）、フロー解析部１１２は、フロー解析処理を終了する。
【００６９】
〔２−４〕本実施形態に係るパラメータ抽出処理（パラメータ表作成処理）の手順
次に、図１１に示すフローチャート（ステップＳ２１〜Ｓ２４）に従って、本実施形態に係るパラメータ抽出処理（パラメータ表作成処理；図９のステップＳ４の処理）の手順について説明する。
【００７０】
まず、パラメータ抽出部１１３の共通パラメータ抽出部１１３ａは、ステップＳ３で作成されたパス表１２５を参照し、未処理のパスＩＤが有るか否かを判断する（ステップＳ２１）。未処理のパスＩＤが有る場合（ステップＳ２１のＹＥＳルート）、共通パラメータ抽出部１１３ａは、未処理のパスＩＤを一つ取り出す、つまり一の未処理のパスＩＤに係る情報をパス表１２５から読み出す（ステップＳ２２）。
【００７１】
そして、共通パラメータ抽出部１１３ａは、図１２を参照しながら後述する共通パラメータ抽出処理を実行する（ステップＳ２３；図１６の矢印Ａ１１参照）。共通パラメータ抽出処理によって、パスＩＤ毎に共通パラメータが抽出される。パラメータ抽出部１１３は、ステップＳ２３の処理を終了すると、ステップＳ２１に戻り、未処理のパスＩＤの有無を判断する。ステップＳ２１〜Ｓ２３の処理は、ステップＳ２１で未処理のパスＩＤが無いと判断されるまで繰り返し実行される。
【００７２】
未処理のパスＩＤが無いと判断されると（ステップＳ２１のＮＯルート）、特定パラメータ抽出部１１３ｂは、図１３を参照しながら後述する特定パラメータ抽出処理を実行する（ステップＳ２４）。このとき、特定パラメータ抽出部１１３ｂは、共通パラメータ抽出部１１３ａによってパスＩＤ毎に得られた共通パラメータに対して、特定パラメータ抽出処理を実行する（図１６の矢印Ａ１２，Ａ１３参照）。パラメータ抽出部１１３は、ステップＳ２４の処理を終了すると、パラメータ抽出処理を終了する。
【００７３】
〔２−４−１〕本実施形態に係る共通パラメータ抽出処理の手順
図１２に示すフローチャート（ステップＳ３１〜Ｓ３５）に従って、本実施形態に係る共通パラメータ抽出処理（図１１のステップＳ２３の処理）の手順について説明する。
【００７４】
まず、共通パラメータ抽出部１１３ａは、図１１のステップＳ２２で取り出された一のパスＩＤについて、パス表１２５に保存されているパラメータを、キーと値とに分割する（ステップＳ３１）。分割後、共通パラメータ抽出部１１３ａは、当該パスＩＤに共通するパス（コンポーネント）の中で、当該パスＩＤに対応する全てのＵＲＩに共通するキーを抽出する（ステップＳ３２）。
【００７５】
共通キーが抽出された場合（ステップＳ３２の「共通キーあり」ルート）、共通パラメータ抽出部１１３ａは、抽出した共通キーのうち、値も共通するキーを抽出する（ステップＳ３３）。この後、共通パラメータ抽出部１１３ａは、抽出結果つまりステップＳ３２及びＳ３３で抽出された共通キーや共通の値を記憶部（メモリ）１２０に格納保存してから（ステップＳ３４）、共通パラメータ抽出処理を終了する。
【００７６】
以上の処理により、当該パスＩＤに対応する全てのＵＲＩ内のパラメータから共通パラメータが抽出される（図１６の矢印Ａ１１参照）。つまり、当該パスＩＤに対応するＵＲＩ内のパラメータのうち、キーも当該キーの値も共通するパラメータについては、当該キーと当該値との両方が共通パラメータとして抽出される。また、当該パスＩＤに対応するＵＲＩ内のパラメータのうち、キーの値は共通しないがキーは共通するパラメータについては、当該キーのみが共通パラメータとして抽出される。
【００７７】
一方、共通キーが抽出された場合（ステップＳ３２の「共通キーなし」ルート）、共通パラメータ抽出部１１３ａは、以下の処理を行なう。つまり、共通パラメータ抽出部１１３ａは、共通キーのない複数のＵＲＬに対しそれぞれ異なるパスＩＤを設定することで、当該共通キーのない複数のＵＲＬを、別パスとして分離し、全体の処理に組み戻す（ステップＳ３５）。この後、共通パラメータ抽出部１１３ａは、共通パラメータ抽出処理を終了する。
【００７８】
以上のような共通パラメータ抽出処理は、パス表１２５に保存される全てのパスのそれぞれについて実行される。
【００７９】
〔２−４−２〕本実施形態に係る特定パラメータ抽出処理の手順
図１３に示すフローチャート（ステップＳ４１〜Ｓ４６）に従って、本実施形態に係る特定パラメータ抽出処理（図１１のステップＳ２４の処理）の手順について説明する。
【００８０】
まず、特定パラメータ抽出部１１３ｂは、特定パラメータ抽出処理をまだ行なっていない未処理のパスＩＤを一つ取り出す（ステップＳ４１）。未処理のパスＩＤが取り出された場合（ステップＳ４１の「未処理パスあり」ルート）、特定パラメータ抽出部１１３ｂは、取り出されたパスＩＤについて共通パラメータとして抽出された共通キーの組合せを生成する（ステップＳ４２）。図１６を参照しながら後述する例では、パスＩＤ“１”について抽出された共通キーは“fid=3”と“tab=”との２つであり、共通キーの組合せは“fid=3”のみと“tab=”のみと“fid=3”及び“tab=”の両方との３組となる。
【００８１】
特定パラメータ抽出部１１３ｂは、ステップＳ４２の処理を終了すると、ステップＳ４１に戻り、未処理のパスＩＤを一つ取り出す。ステップＳ４１及びＳ４２の処理は、ステップＳ４１で未処理のパスＩＤが取り出されなくなるまで繰り返し実行される。
【００８２】
未処理のパスＩＤが取り出されなかった場合（ステップＳ４１の「未処理パスなし」ルート）、特定パラメータ抽出部１１３ｂは、以下の処理をまだ行なっていない、組合せ生成後の未処理のパスＩＤを一つ取り出す（ステップＳ４３）。未処理のパスＩＤが取り出された場合（ステップＳ４３の「未処理パスあり」ルート）、特定パラメータ抽出部１１３ｂは、取り出されたパスＩＤのみに存在する共通キー又は共通キーの組合せが存在するか否かを判断する（ステップＳ４４）。
【００８３】
共通キーまたは共通キーの組合せが存在する場合（ステップＳ４４のＹＥＳルート）、特定パラメータ抽出部１１３ｂは、共通キー又は共通キーの組合せの中から最小の組合せを一つ選択する（図１６の矢印Ａ１２参照）。そして、特定パラメータ抽出部１１３ｂは、選択された組合せに係るパラメータを、特定パラメータとしてパラメータ表１２６に出力し保存する（ステップＳ４５；図１６の矢印Ａ１３参照）。例えば、上述したように共通キーの組合せが“fid=3”のみと“tab=”のみと“fid=3”及び“tab=”の両方との３組である場合、最小のパラメータ（キー）“tab=”が特定パラメータとして選択される。
【００８４】
一方、共通キー又は共通キーの組合せが存在しない場合（ステップＳ４４のＮＯルート）、特定パラメータ抽出部１１３ｂは、共通キーに係る全てのパラメータを、特定パラメータとしてパラメータ表１２６に出力し保存する（ステップＳ４６）。
【００８５】
特定パラメータ抽出部１１３ｂは、ステップＳ４５又はステップＳ４６の処理を終了すると、ステップＳ４３に戻り、組合せ生成後の未処理のパスＩＤを一つ取り出す。ステップＳ４３〜Ｓ４６の処理は、ステップＳ４３で未処理のパスＩＤが取り出されなくなるまで繰り返し実行される。未処理のパスＩＤが取り出されなかった場合（ステップＳ４３の「未処理パスなし」ルート）、特定パラメータ抽出部１１３ｂは、特定パラメータ抽出処理を終了する。
【００８６】
以上の処理により、共通パラメータ抽出部１１３ａによって抽出された共通パラメータのうち、注目パスＩＤ（機能Ｆｉ）以外の他のパスＩＤについて抽出された共通パラメータとは異なる（重ならない）共通パラメータが、注目パスＩＤを特定する特定パラメータとして決定される。このとき、共通パラメータの中から、機能Ｆｉ（パス／パスＩＤ）を特定する最小パラメータもしくは最小の組合せが、特定パラメータとして決定される。
【００８７】
〔２−５〕本実施形態に係るフロー解析処理の具体例
次に、図１４及び図１５を参照しながら、本実施形態に係るフロー解析処理（図９のステップＳ３の処理）の具体例について説明する。なお、図１４及び図１５は、本実施形態に係るフロー解析処理を具体的に説明する図である。
【００８８】
図１４及び図１５に示すように、コンポーネント種別取得部１１２ａは、未処理のアクセスログを一つ取り出すと、当該アクセスログ（注目アクセスログ）のTranＩＤ“308378505-httpWorkerThread-28080-0-1”と同じTranＩＤをもつ、複数の詳細ログを抽出する（矢印Ａ１参照）。なお、図１４では、注目アクセスログに対し４つの詳細ログが抽出された例が示され、図１５では、注目アクセスログに対し６つの詳細ログが抽出された例が示されている。
【００８９】
また、コンポーネント種別取得部１１２ａは、図１５に示すように、６つの詳細ログのそれぞれから、TranＩＤ以外の記述（図１５の詳細ログ例の網掛け部分参照）を抽出する（矢印Ａ２参照）。そして、コンポーネント種別取得部１１２ａは、コンポーネント定義１２４に基づき、各詳細ログの上記記述をコンポーネントＩＤに変換することで（矢印Ａ３，Ａ４）、各詳細ログに対応する対応コンポーネントの種別（コンポーネントＩＤ）を取得する。
【００９０】
図１５に示すコンポーネント定義１２４も、図５を参照しながら前述したコンポーネント定義１２４と同様のものである。つまり、コンポーネント定義１２４では、詳細ログ１２３の記述“com/foo/pkg/servlet”がコンポーネントｐ１に対応し、詳細ログ１２３の記述“com/foo/pkg/kernel”がコンポーネントｐ２に対応するように、コンポーネント定義１２４が設定されている。また、詳細ログ１２３の記述“com/foo/pkg/log”がコンポーネントｐ３に対応し、詳細ログ１２３の記述“org/hibernate/Session”がコンポーネントｐ４に対応するように、コンポーネント定義１２４が設定されている。
【００９１】
したがって、６つの詳細ログから抽出された各記述は、それぞれ、コンポーネントＩＤ“ｐ１”，“ｐ２”，“ｐ３”，“ｐ１”，“ｐ４”，“ｐ１”に変換される（矢印Ａ４参照）。このとき、コンポーネントＩＤ“ｐ１”は３回出現しているので、注目アクセスログ（注目ＵＲＩ）に対応するコンポーネント群として、４つのコンポーネントＩＤ“ｐ１”，“ｐ２”，“ｐ３”，“ｐ４”が抽出される（矢印Ａ５参照）。
【００９２】
この後、抽出された注目アクセスログ（注目ＵＲＩ）に対応する４つのコンポーネントＩＤ“ｐ１”，“ｐ２”，“ｐ３”，“ｐ４”と、注目アクセスログの、パラメータ記述を含むＵＲＩ“http://foo.com/?fid=3&tab=2”とが対応付けられてパス表１２５に登録される（矢印Ａ６，Ａ７参照）。以上のような処理をアクセスログ（ＵＲＩ）毎に実行することで、図６，図１５や図１６に示すようなパス表１２５が作成される。
【００９３】
図１６に示すパス表１２５も、図６を参照しながら前述したパス表１２５と同様のものである。つまり、図１６に示すパス表１２５の各行は、図１４や図１５に示すアクセスログ１２２の各行に対応している。例えば、パス表１２５の１行目には、パスＩＤを示す“１”と、コンポーネント群（パス）“ｐ１：ｐ２：ｐ３：ｐ４”と、パラメータを含むＵＲＩ“http://foo.com/?fid=3&tab=2”とが対応付けられている。ここで、“fid=3&tab=2”がパラメータであり、“fid=”及び“tab=”がキーであり、“3”及び“2”がそれぞれキー“fid=”及び“tab=”の値である。図１６に示す例においても、パスＩＤ“１”はパス“ｐ１：ｐ２：ｐ３：ｐ４”に対応し、パスＩＤ“２”はパス“ｐ１：ｐ４：ｐ５：ｐ７：ｐ８”に対応し、パスＩＤ“３”はパス“ｐ３：ｐ８：ｐ９”に対応している。さらに、パスＩＤ“１”には、異なるパラメータを有する３つのＵＲＩ（アクセスログ）が対応し、パスＩＤ“２”には、異なるパラメータを有する２つのＵＲＩ（アクセスログ）が対応し、パスＩＤ“３”には、１つのＵＲＩ（アクセスログ）が対応している。
【００９４】
なお、共通パラメータ抽出部１１３ａは、キーは共通するがキーの値が共通しないパラメータであっても、各値の出現頻度やバリエーションを学習することで、当該パラメータにおけるキーの値が有限種の値かランダムな値かを判定し、その判定結果を共通パラメータの抽出に反映してもよい。一つの機能内のパラメータにおいて出現するキーの値が共通しない場合（同一のキーに対して複数の異なる値が出現する場合）の対応例については、本実施形態の第１変形例として図１７及び図１８を参照しながら後述する。また、一つの機能内のパラメータにおいて共通のキーが出現しない場合の対応例については、本実施形態の第２変形例として図１７及び図１９を参照しながら後述する。
【００９５】
〔２−６〕本実施形態に係るパラメータ抽出処理及びパラメータ加工処理の具体例
次に、図１６を参照しながら、本実施形態に係るパラメータ抽出処理（図９のステップＳ４の処理）及びパラメータ加工処理（図９のステップＳ５の処理）の具体例について説明する。なお、図１６は、本実施形態に係るパラメータ抽出処理及びパラメータ加工処理を具体的に説明する図である。
【００９６】
図１６に示すように、共通パラメータ抽出部１１３ａは、パス表１２５を参照し、パスＩＤ（機能Ｆｉ）毎に、同じパスＩＤに対応する複数のＵＲＩに共通するパラメータを、共通パラメータとして抽出する（矢印Ａ１１参照）。例えば、パスＩＤ“１”に対応する３つのＵＲＩに共通するパラメータは、“fid=3”（キーも値も共通する）と“tab=”（キーは共通するが値は共通しない）との２つである。また、パスＩＤ“２”に対応する２つのＵＲＩに共通するパラメータは、“fid=4”（キーも値も共通する）と“ui=”（キーは共通するが値は共通しない）と“col=5”（キーも値も共通する）との３つである。さらに、パスＩＤ“３”に対応する一つのＵＲＩからは、共通パラメータとしては、当該ＵＲＩに含まれる全てのパラメータ“fid=4”，“ui=small”，“col=4”が抽出される。
【００９７】
そして、特定パラメータ抽出部１１３ｂは、上述のように抽出された共通パラメータのうち、注目パスＩＤ以外のパスＩＤについて抽出された共通パラメータとは重ならない共通パラメータを、注目パスＩＤ（機能Ｆｉ）を特定する特定パラメータとして決定する（矢印Ａ１２参照）。図１６に示す例において、パスＩＤ“１”のみに出現しパスＩＤ“２”及び“３”には出現しない共通パラメータのうち、最小のものは“tab=”であり、この“tab=”が、パスＩＤ“１”を特定する特定パラメータとして抽出される。同様に、パスＩＤ“２”のみに出現しパスＩＤ“１”及び“３”には出現しない共通パラメータのうち最小のものは“col=5”であり、この“col=5”が、パスＩＤ“２”を特定する特定パラメータとして抽出される。また、パスＩＤ“３”のみに出現しパスＩＤ“１”及び“２”には出現しない共通パラメータのうち、最小のものは“col=4”であり、この“col=4”が、パスＩＤ“２”を特定する特定パラメータとして抽出される。なお、パスＩＤ“３”に出現するパラメータ“ui=small”は、パスＩＤ“２”に出現するパラメータ“ui=”に包含されるので、パスＩＤ“３”のみに出現するパラメータとは言えないため、除外される。
【００９８】
上述のように抽出された特定パラメータ“tab=”，“col=5”，“col=4”は、そのままパラメータ表１２６に登録保存されてもよいが、図１６に示すパラメータ表１２６では、図７を参照しながら前述したパス表１２６と同様に登録保存されている（矢印Ａ１３参照）。つまり、パラメータ表１２６では、特定パラメータ“tab=”，“col=5”，“col=4”がまとめて記述されている。上述した通り、パラメータ表１２６の記述“use, col”は、キーが“col=”であるパラメータ“col=x”についてはキー“col=”も当該キーの値“x”もパス情報として用いることを指示する。また、パラメータ表１２６の記述“delvalue, tab”は、パラメータ“tab=y”についてはキー“tab=”のみパス情報として用い、当該キー“tab=”の値“y”を捨てることを指示する。
【００９９】
そして、パラメータ加工部１１４は、上述のように得られたパラメータ表１２６に基づき、パス表１２５のフィルタリング加工を行なう（矢印Ａ１４参照）。つまり、パラメータ加工部１１４は、パス表１２５にパラメータ表１２６を適用してパス表１２５を加工することで、必要最小限のパラメータを含むＵＲＩ記述（処理）とパスＩＤ（コンポーネント群）との関係を示すパス情報１２７を生成する。図１６に示す例でも、図６及び図８を参照しながら上述した例と同様、パスＩＤ“１”の３つのＵＲＩは一つにまとめられ、当該ＵＲＩにおけるパラメータ記述は、図１６のパラメータ表１２６を適用することで“tab=”のみに書き換えられる。また、パスＩＤ“２”の２つのＵＲＩは一つにまとめられ、当該ＵＲＩにおけるパラメータ記述は、図１６のパラメータ表１２６を適用することで“col=5”のみに書き換えられる。さらに、パスＩＤ“３”のＵＲＩにおけるパラメータ記述は、図７のパラメータ表１２６を適用することで“col=4”のみに書き換えられる。
【０１００】
〔３〕本実施形態の効果
本実施形態の分析装置１００によれば、複数のコンポーネントｐ１，ｐ２，…を用いる各機能Ｆｉによるリクエスト実行時に採取される複数のリクエストログ内のパラメータから、当該複数のリクエストログに共通する共通パラメータが抽出される。そして、機能Ｆｉ毎に抽出された共通パラメータのうち、機能Ｆｉ以外の他の機能について抽出された共通パラメータとは異なる共通パラメータが、機能Ｆｉを特定する特定パラメータとして決定される。このようにして、分析装置１００では、ＵＲＩにユーザＩＤなどがパラメータとして含まれていても、機能Ｆｉを特定することのできる適切なパラメータが、機能Ｆｉの実行時に得られるリクエストログから特定され、機能Ｆｉを正確に分類することができる。したがって、アプリケーションプログラムやネットワークサービス等において、実運用時に分析装置２００が問題個所を特定するために用いるパス情報１２７のデータ量を、大幅に削減することができる。
【０１０１】
また、実運用時に分析装置２００が分析（問題箇所特定）を行なう際には、分析時間や分析リソースの制約のために、ＵＲＩから機能（パス／コンポーネント群）を特定するために必要のないパラメータを取り除く必要がある。その際、機能の特定に必要な情報まで誤って取り除いてしまうと分析が有効に機能しなくなってしまう。そこで、機能を特定するために必要な最小限のパラメータを選別する必要がある。しかし、通常のＨＴＴＰログ等には機能を特定するために必要な情報がなく、パラメータの選別は困難である。このため、パラメータの選別作業にはオペレータ等の判断が必要になり、分析システム導入の障害となり、パラメータ選定の自動化が望まれている。
【０１０２】
これに対し、本実施形態の分析装置１００によれば、各リクエストがどのコンポーネント群（パス）を使用しているかを分類することが可能になる。すなわち、本実施形態の分析装置１００によれば、各リクエストと機能（処理）との対応付けが行なわれ、リクエスト（ＵＲＩ，パスＩＤ）を特徴付けるパラメータを選別することが可能になる。したがって、本実施形態の分析装置１００によれば、分析（問題箇所特定）のための機能やパラメータの自動選別が可能になり、分析環境の正しい構築や、分析環境の準備期間の短縮を実現することができる。
【０１０３】
さらに、本実施形態の分析装置１００によって得られたパス情報１２７は、必要最小限のパラメータを含むので、パス情報１２７のデータ量を削減できるだけでなく、実運用時に分析装置２００が問題個所を特定するために要する分析時間を大幅に短縮することもできる。つまり、分析装置２００は、実運用時に採取されたログデータにおけるＵＲＩ＋ＣＧＩパラメータと、パス情報１２７とを照らし合わせることで、当該ログデータを、対応するパス（機能／処理）に容易に且つ短時間で選別することができる。
【０１０４】
また、本実施形態のパラメータ表１２６では、例えば、“use, col”，“delvalue, tab”といった記述を用いることで、パス表１２５から抽出すべき必要最小限のパラメータに関する情報（特定パラメータに関する情報）を、まとめて記述することができる。したがって、単に特定パラメータをパラメータ表１２６に登録する場合に比べ、パラメータ表１２６のデータ量を大幅に削減することができる。
【０１０５】
〔４〕変形例
〔４−１〕第１変形例
本実施形態の第１変形例は、一つの機能内のパラメータにおいて出現するキーの値が共通しない場合（同一のキーに対して複数の異なる値が出現する場合）の対応例である。当該第１変形例では、同一のキーに対して複数の異なる値（例えばui=100, ui=80など）が出現する場合でも、キーの値として、ランダムでなく一定の値しか出現しない場合、その一定の「キーの値」が、機能を特定するパラメータの候補（共通パラメータ）として抽出される。
【０１０６】
以下、本実施形態の第１変形例について、図１７及び図１８を参照しながら説明する。なお、図１７は、第１変形例の分析装置１００Ａのハードウエア構成及び機能構成を示すブロック図である。図１８は、第１変形例の分析装置１００Ａにおけるパラメータ抽出処理及びパラメータ加工処理を具体的に説明する図である。図中、既述の符号と同一の符号は、同一もしくはほぼ同一の部分を示しているので、その説明は省略する。
【０１０７】
図１７に示すように、第１変形例の分析装置１００Ａも、図２に示す本実施形態の分析装置１００と同様に構成されている。ただし、第１変形例の分析装置１００Ａでは、フロー解析部１１２に出現頻度取得部１１２ｃが新たに追加されるとともに、記憶部１２０に頻度表１２８Ａが新たに追加されている。また、記憶部１２０には、パラメータ表１２６及びパス情報１２７に代えてパラメータ表１２６Ａ及びパス情報１２７Ａが保存される。
【０１０８】
第１変形例の出現頻度取得部１１２ｃは、パスＩＤ毎に、複数のアクセスログ１２２（リクエストログ）内における各パラメータの出現頻度を取得する。取得された出現頻度は、図１８に示すように、パスＩＤ毎に、パラメータ記述「キー＝値」に対応付けられて、頻度表１２８Ａに保存される。なお、図１７に示す例では、処理部１１０のフロー解析部１１２に出現頻度取得部１１２ｃを備えられているが、これに限定されるものではない。
【０１０９】
また、第１変形例の共通パラメータ抽出部１１３ａは、複数のアクセスログ１２２（ＵＲＩ）内のパラメータのうち、値は共通しないがキーは共通するパラメータについて取得された出現頻度が所定しきい値よりも高い場合、当該キーと当該値との両方を共通パラメータとして抽出する。また、第１変形例の共通パラメータ抽出部１１３ａは、出現頻度が低い場合、当該キーのみを共通パラメータとして抽出する。
【０１１０】
次に、図１８を参照しながら、第１変形例の出現頻度取得部１１２ｃ，共通パラメータ抽出部１１３ａ及び特定パラメータ抽出部１１３ｂの動作や、第１変形例のパラメータ表１２６Ａ及びパス情報１２７Ａについて説明する。
【０１１１】
図１８に示すように、第１変形例では、出現頻度取得部１１２ｃによって頻度表１２８Ａが作成されている。つまり、パス表１２５のＵＲＩ内において出現する各パラメータの出現頻度が、パスＩＤ毎に取得され、頻度表１２８Ａとして保存されている。図１８に示す頻度表１２８Ａでは、パスＩＤ“１”のＵＲＩ内のパラメータ“fid=3”の出現頻度として“５５”が取得され、パスＩＤ“１”のＵＲＩ内のパラメータ“ui=ss”の出現頻度として“２４”が取得されている。また、パスＩＤ“１”のＵＲＩ内のパラメータ“ui=100”の出現頻度として“１８”が取得され、パスＩＤ“１”のＵＲＩ内のパラメータ“ui=80”の出現頻度として“１３”が取得されている。同様に、パスＩＤ“２”のＵＲＩ内のパラメータ“fid=3”の出現頻度として“８４”が取得され、パスＩＤ“２”のＵＲＩ内のパラメータ“ui=large”の出現頻度として“４４”が取得され、パスＩＤ“２”のＵＲＩ内のパラメータ“ui=small”の出現頻度として“４０”が取得されている。
【０１１２】
共通パラメータ抽出部１１３ａは、パス表１２５及び頻度表１２８Ａを参照し、パスＩＤ毎に、同じパスＩＤに対応する複数のＵＲＩに共通するパラメータを、共通パラメータとして抽出する（矢印Ａ２１参照）。このとき、共通パラメータ抽出部１１３ａは、値は共通しないがキーは共通するパラメータについて取得された出現頻度が所定しきい値よりも高い場合、当該キーと当該値との両方も共通パラメータとして抽出する（矢印Ａ２１参照）。ここで、出現頻度の高低は、出現頻度と所定しきい値（回数）との比較によって判断されてもよいし、全体の回数に対する出現頻度の割合と所定しきい値（割合）との比較によって判断されてもよい。なお、ここで、図１８に示す頻度表１２８Ａにおける出現頻度については、全て、所定しきい値よりも高いと判断されているものとする。
【０１１３】
このとき、図１８に示す例において、共通パラメータ抽出部１１３ａは、以下のような共通パラメータを抽出する。つまり、パスＩＤ“１”に対応する３つのＵＲＩに共通するパラメータは、“fid=3”（キーも値も共通する）と、出現頻度が所定しきい値よりも高い３つのパラメータ“ui=ss, 100, 80”との４つである。また、パスＩＤ“２”に対応する２つのＵＲＩに共通するパラメータは、“fid=3”（キーも値も共通する）と、出現頻度が所定しきい値よりも高い２つのパラメータ“ui=large, small”との３つである。
【０１１４】
ここで、仮に“ui=ss”や“ui=100”などの出現頻度が少ない（所定しきい値よりも低い）場合、共通パラメータ抽出部１１３ａは、キー“ui=”の値は特定の値“ss”や“100”ではなく不定な変数であると判定し、キー（ui=）のみを共通パラメータとして抽出する。
【０１１５】
また、出現頻度の計数中に、同一のキーに対し、出現頻度の低い、多数の異なる値が得られている場合、当該キーについての計数は途中で打ち切り、共通パラメータ抽出部１１３ａは、当該キーの値は不定な変数であると判定し、キーのみを共通パラメータとして抽出する。
【０１１６】
さらに、例えば、パスＩＤ“１”とパスＩＤ“２”とにおいて、“ui=”の値として、共通する値が出現する場合、例えばどちらにも“ui=medium”が出現する場合、共通パラメータ抽出部１１３ａは、共通する値のみを、両方のパスで共通パラメータとして抽出してもよい。もしくは、この場合、共通パラメータ抽出部１１３ａは、共通する値の場合を無視してもよい。
【０１１７】
そして、特定パラメータ抽出部１１３ｂは、上述のように抽出された共通パラメータのうち、注目パスＩＤ以外のパスＩＤについて抽出された共通パラメータとは重ならない共通パラメータを、注目パスＩＤを特定する特定パラメータとして決定する（矢印Ａ２２参照）。図１８に示す例において、パスＩＤ“１”のみに出現しパスＩＤ“２”には出現しない共通パラメータは“ui=ss”，“ui=100”，“ui=80”であり、これらの共通パラメータが、特定パラメータとして抽出される。同様に、パスＩＤ“２”のみに出現しパスＩＤ“１”には出現しない共通パラメータは“ui=large”，“ui=small”であり、これらの共通パラメータが、特定パラメータとして抽出される。
【０１１８】
図１６を参照しながら上述した実施形態では、この特定パラメータ抽出段階で、パスＩＤ“１”もパスＩＤ“２”も、“ui”はキーのみとなるため、パスを特定するパラメータがなくなる。これに対し、第１変形例では、出現頻度情報（頻度表１２８Ａ）に基づき、値の異なるパラメータが数種類しか出現しないことが判明した場合、共通パラメータ抽出部１１３ａは、同一のキーについて複数の異なる値が出現する複数のパラメータを、共通パラメータとして処理する。
【０１１９】
上述のように抽出された特定パラメータ“ui=ss”，“ui=100”，“ui=80”，“ui=large”，“ui=small”は、図１８に示すパラメータ表１２６Ａでは“use, ui”としてまとめて記述されている（矢印Ａ２３参照）。
【０１２０】
そして、パラメータ加工部１１４は、上述のように得られたパラメータ表１２６Ａに基づき、パス表１２５のフィルタリング加工を行なう（矢印Ａ２４参照）。つまり、パラメータ加工部１１４は、パス表１２５にパラメータ表１２６Ａを適用してパス表１２５を加工することで、必要最小限のパラメータを含むＵＲＩ記述（処理）とパスＩＤ（コンポーネント群）との関係を示すパス情報１２７Ａを生成する。図１８に示す例において、パス情報１２７Ａの各行は、パス表１２５の各行に対応しており、パス表１２５の各行における“fid=3&”を削除した記述に書き換えられる。
【０１２１】
〔４−２〕第２変形例
本実施形態の第２変形例は、一つの機能内のパラメータにおいて共通のキーが出現しない場合の対応例である。当該第２変形例では、一つの機能内のパラメータにおいて共通のキーが出現しない場合でも、複数の「キー＝値」の組合せが一定のものしか出現しない場合、その一定の「キー＝値」の組合せが、機能を特定するパラメータの候補（共通パラメータ）として抽出される。
【０１２２】
以下、本実施形態の第２変形例について、図１７及び図１９を参照しながら後述する。なお、図１７は、第２変形例の分析装置１００Ｂのハードウエア構成及び機能構成を示すブロック図である。図１９は、第２変形例の分析装置１００Ａにおけるパラメータ抽出処理及びパラメータ加工処理を具体的に説明する図である。図中、既述の符号と同一の符号は、同一もしくはほぼ同一の部分を示しているので、その説明は省略する。
【０１２３】
図１７に示すように、第２変形例の分析装置１００Ｂも、図２に示す本実施形態の分析装置１００と同様に構成されている。ただし、第２変形例の分析装置１００Ｂでは、第１変形例の分析装置１００Ａと同様、フロー解析部１１２に出現頻度取得部１１２ｃが新たに追加されるとともに、記憶部１２０に頻度表１２８Ｂが新たに追加されている。また、記憶部１２０には、パラメータ表１２６及びパス情報１２７に代えてパラメータ表１２６Ｂ及びパス情報１２７Ｂが保存される。
【０１２４】
第２変形例の出現頻度取得部１１２ｃは、リクエスト毎に、当該リクエストの出現頻度を取得する。取得された出現頻度は、図１９に示すように、各リクエスト及び各リクエストのパスＩＤに対応付けられて、頻度表１２８Ｂに保存される。なお、図１７に示す例では、処理部１１０のフロー解析部１１２に出現頻度取得部１１２ｃを備えられているが、これに限定されるものではない。
【０１２５】
また、第２変形例の共通パラメータ抽出部１１３ａは、出現頻度が所定しきい値よりも高いリクエストについてのリクエストログ（アクセスログ／ＵＲＩ）内の、当該リクエストのみに出現するパラメータを、前記共通パラメータとして抽出する。
【０１２６】
次に、図１９を参照しながら、第２変形例の出現頻度取得部１１２ｃ，共通パラメータ抽出部１１３ａ及び特定パラメータ抽出部１１３ｂの動作や、第２変形例のパラメータ表１２６Ｂ及びパス情報１２７Ｂについて説明する。
【０１２７】
図１９に示すように、第２変形例では、出現頻度取得部１１２ｃによって頻度表１２８Ｂが作成されている。図１９に示す頻度表１２８Ｂでは、パス表１２５の各行（各リクエスト）の出現頻度が、各リクエストのみに出現するパラメータに対応付けて保存されている。つまり、図１８に示す例において、パス表１２５の１行目のリクエストに対応する頻度表１２８Ｂの１行目には、パスＩＤ“１”と、パス表１２５の１行目のみに出現するパラメータ“fid=3:ui=ss”と、当該リクエストの出現頻度“３０”とが記述されている。パス表１２５の２行目以降のリクエストに対応する頻度表１２８Ｂの２行目以降にも、１行目の記述と同様の記述がなされている。
【０１２８】
共通パラメータ抽出部１１３ａは、パス表１２５及び頻度表１２８Ｂを参照し、出現頻度が所定しきい値よりも高いリクエストについてのアクセスログ内の、当該リクエストのみに出現するパラメータを、共通パラメータとして抽出する（矢印Ａ３１）。ここで、出現頻度の高低は、前述したように、出現頻度と所定しきい値（回数）との比較によって判断されてもよいし、全体の回数に対する出現頻度の割合と所定しきい値（割合）との比較によって判断されてもよい。なお、ここで、図１９に示す頻度表１２８Ｂにおける出現頻度については、全て、所定しきい値よりも高いと判断されているものとする。
【０１２９】
このとき、図１９に示す例において、共通パラメータ抽出部１１３ａは、以下のような共通パラメータを抽出する。つまり、パスＩＤ“１”に対応する３つのＵＲＩに対応する共通パラメータとして、“fid=3:ui=ss”と“tab=2:col=5”と“tab=3:col=4”との３組が抽出される。また、パスＩＤ“２”に対応する２つのＵＲＩに対応する共通パラメータとして、“fid=2:col=3”と“tab=5:ui=small”との２組が抽出される。
【０１３０】
そして、特定パラメータ抽出部１１３ｂは、上述のように抽出された共通パラメータから、パスＩＤ“１”のみに出現するパラメータの組として、“fid=3:ui=ss”と“tab=2:col=5”と“tab=3:col=4”との３組を抽出する（矢印Ａ３２参照）。同様に、特定パラメータ抽出部１１３ｂは、パスＩＤ“２”のみに出現するパラメータの組として、“fid=2:col=3”と“tab=5:ui=small”との２組を抽出する（矢印Ａ３２参照）。
【０１３１】
図１６を参照しながら上述した実施形態では、この特定パラメータ抽出段階で、パスＩＤ“１”もパスＩＤ“２”も、“ui”はキーのみとなるため、パスを特定するパラメータがなくなる。これに対し、第２変形例では、各リクエストの出現頻度が、各リクエストのみに出現するキーの組合せの出現頻度として計数され、出現頻度情報（頻度表１２８Ｂ）が作成される。そして、出現頻度情報（頻度表１２８Ｂ）に基づき、出現頻度が所定しきい値よりも高いキーの組合せが、共通パラメータつまりは特定パラメータを抽出される。したがって、出現頻度が所定しきい値以下のキー（つまり出現頻度の低いキー）の組合せは、特定パラメータの候補から除外されるので、適切なパラメータを特定パラメータとして精度よく抽出することができる。
【０１３２】
上述のように抽出された５組の特定パラメータ“fid=3:ui=ss”，“tab=2:col=5”，“tab=3:col=4”，“fid=2:col=3”，“tab=5:ui=small”は、図１９に示すパラメータ表１２６Ｂでは、“use, fid”，“use, ui”，“use, tab”，“use, col”としてまとめて記述されている（矢印Ａ３３参照）。
【０１３３】
そして、パラメータ加工部１１４は、上述のように得られたパラメータ表１２６Ｂに基づき、パス表１２５のフィルタリング加工を行なう（矢印Ａ３４参照）。つまり、パラメータ加工部１１４は、パス表１２５にパラメータ表１２６Ｂを適用してパス表１２５を加工することで、必要最小限のパラメータを含むＵＲＩ記述（処理）とパスＩＤ（コンポーネント群）との関係を示すパス情報１２７Ｂを生成する。図１９に示す例において、パス情報１２７Ａの各行は、パス表１２５の各行に対応しており、各行では、４つのキー“fid=”，“ui=”，“tab=”，“col=”についてキー及び当該キーの値を残し、その他のキーについては除去する書き換えが行なわれている。
【０１３４】
〔５〕その他
以上、本発明の好ましい実施形態について詳述したが、本発明は、係る特定の実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲内において、種々の変形、変更して実施することができる。
【０１３５】
上述した実施形態では、ＵＲＩ内のパラメータを対象とした場合について説明したが、本発明は、これに限定されるものではなく、ＰＯＳＴメソッドやＨＴＴＰヘッダのパラメータなどにも同様に適用され、上述と同様の作用効果を得ることができる。
【０１３６】
〔６〕付記
以上の実施形態に関し、さらに以下の付記を開示する。
（付記１）
複数のコンポーネントを用いる処理によるリクエスト実行時に採取される複数のリクエストログ内のパラメータから、当該複数のリクエストログに共通する共通パラメータを抽出し、
抽出された前記共通パラメータのうち、他の処理について抽出された共通パラメータとは異なる共通パラメータを、前記処理を特定する特定パラメータとして決定する、分析方法。
【０１３７】
（付記２）
前記複数のリクエストログのそれぞれは、リクエスト毎に採取される、一のアクセスログと当該一のアクセスログに対応する複数の詳細ログとを含む、付記１に記載の分析方法。
【０１３８】
（付記３）
前記リクエスト毎に、前記複数の詳細ログのそれぞれに含まれる記述に基づき、前記複数のコンポーネントのうち、各詳細ログに対応する対応コンポーネントの種別を取得し、
前記リクエスト毎に、各リクエストについて取得された前記対応コンポーネントの種別と、前記一のアクセスログに含まれる前記パラメータに係る記述とを対応付ける対応表を作成し、
作成された前記対応表に基づき、前記複数のリクエストログ内のパラメータから前記共通パラメータを抽出する、付記２に記載の分析方法。
【０１３９】
（付記４）
予め定義された、前記複数の詳細ログのそれぞれに含まれる記述と前記コンポーネントの種別とを対応付けるコンポーネント定義を用いて、前記対応コンポーネントの種別を取得する、付記３に記載の分析方法。
【０１４０】
（付記５）
決定された前記特定パラメータに基づき前記対応表を加工して、前記処理と前記複数のコンポーネントとの関係を示すパス情報を生成する、付記３または付記４に記載の分析方法。
【０１４１】
（付記６）
前記複数のリクエストログ内のパラメータのうち、キーも値も共通するパラメータについては、当該キーと当該値との両方を前記共通パラメータとして抽出する、付記１〜付記５のいずれか一項に記載の分析方法。
【０１４２】
（付記７）
前記複数のリクエストログ内のパラメータのうち、値は共通しないがキーは共通するパラメータについては、当該キーのみを前記共通パラメータとして抽出する、付記１〜付記６のいずれか一項に記載の分析方法。
【０１４３】
（付記８）
前記複数のリクエストログ内のパラメータの出現頻度を取得し、
前記複数のリクエストログ内のパラメータのうち、値は共通しないがキーは共通するパラメータについて取得された前記出現頻度が所定しきい値よりも高い場合、当該キーと当該値との両方を前記共通パラメータとして抽出する、付記１〜付記５のいずれか一項に記載の分析方法。
【０１４４】
（付記９）
前記出現頻度が所定しきい値よりも低い場合、当該キーのみを前記共通パラメータとして抽出する、付記８に記載の分析方法。
【０１４５】
（付記１０）
リクエスト毎に当該リクエストの出現頻度を取得し、
前記出現頻度が所定しきい値よりも高いリクエストについてのリクエストログ内の、当該リクエストのみに出現するパラメータを、前記共通パラメータとして抽出する、付記１〜付記５のいずれか一項に記載の分析方法。
【０１４６】
（付記１１）
前記共通パラメータの中から、前記処理を特定する最小パラメータもしくは最小の組合せを前記特定パラメータとして決定する、付記１〜付記１０のいずれか一項に記載の分析方法。
【０１４７】
（付記１２）
複数のコンポーネントを用いる処理によるリクエスト実行時に採取される複数のリクエストログ内のパラメータから、当該複数のリクエストログに共通する共通パラメータを抽出する共通パラメータ抽出部と、
前記共通パラメータ抽出部によって抽出された前記共通パラメータのうち、他の処理について抽出された共通パラメータとは異なる共通パラメータを、前記処理を特定する特定パラメータとして決定する特定パラメータ決定部と、を備えた分析装置。
【０１４８】
（付記１３）
前記共通パラメータ抽出部は、前記複数のリクエストログ内のパラメータのうち、キーも値も共通するパラメータについては、当該キーと当該値との両方を前記共通パラメータとして抽出する、付記１２に記載の分析装置。
【０１４９】
（付記１４）
前記共通パラメータ抽出部は、前記複数のリクエストログ内のパラメータのうち、値は共通しないがキーは共通するパラメータについては、当該キーのみを前記共通パラメータとして抽出する、付記１２または付記１３に記載の分析装置。
【０１５０】
（付記１５）
前記複数のリクエストログ内のパラメータの出現頻度を取得する出現頻度取得部を備え、
前記共通パラメータ抽出部は、前記複数のリクエストログ内のパラメータのうち、値は共通しないがキーは共通するパラメータについて取得された前記出現頻度が所定しきい値よりも高い場合、当該キーと当該値との両方を前記共通パラメータとして抽出する、付記１２に記載の分析装置。
【０１５１】
（付記１６）
前記共通パラメータ抽出部は、前記出現頻度が所定しきい値よりも低い場合、当該キーのみを前記共通パラメータとして抽出する、付記１５に記載の分析装置。
【０１５２】
（付記１７）
リクエスト毎に当該リクエストの出現頻度を取得する出現頻度取得部を備え、
前記共通パラメータ抽出部は、前記出現頻度が所定しきい値よりも高いリクエストについてのリクエストログ内の、当該リクエストのみに出現するパラメータを、前記共通パラメータとして抽出する、付記１２に記載の分析装置。
【０１５３】
（付記１８）
前記特定パラメータ決定部は、前記共通パラメータの中から、前記処理を特定する最小パラメータもしくは最小の組合せを前記特定パラメータとして決定する、付記１２〜付記１７のいずれか一項に記載の分析装置。
【０１５４】
（付記１９）
複数のコンポーネントを用いる処理によるリクエスト実行時に採取される複数のリクエストログ内のパラメータから、当該複数のリクエストログに共通する共通パラメータを抽出し、
抽出された前記共通パラメータのうち、他の処理について抽出された共通パラメータとは異なる共通パラメータを、前記処理を特定する特定パラメータとして決定する、
処理を、コンピュータに実行させる、分析プログラム。
【０１５５】
（付記２０）
前記複数のリクエストログのそれぞれは、リクエスト毎に採取される、一のアクセスログと当該一のアクセスログに対応する複数の詳細ログとを含む、付記１９に記載の分析プログラム。
【０１５６】
（付記２１）
前記リクエスト毎に、前記複数の詳細ログのそれぞれに含まれる記述に基づき、前記複数のコンポーネントのうち、各詳細ログに対応する対応コンポーネントの種別を取得し、
前記リクエスト毎に、各リクエストについて取得された前記対応コンポーネントの種別と、前記一のアクセスログに含まれる前記パラメータに係る記述とを対応付ける対応表を作成し、
作成された前記対応表に基づき、前記複数のリクエストログ内のパラメータから前記共通パラメータを抽出する、
処理を前記コンピュータに実行させる、付記２０に記載の分析プログラム。
【０１５７】
（付記２２）
決定された前記特定パラメータに基づき前記対応表を加工して、前記処理と前記複数のコンポーネントとの関係を示すパス情報を生成する、
処理を前記コンピュータに実行させる、付記２１に記載の分析プログラム。
【符号の説明】
【０１５８】
１０    ネットワーク
２０    サーバ
３０    Ｗｅｂサーバ
４０    ＡＰ（アプリケーション）サーバ
４１    アプリケーションプログラム
４２    ログ出力部
５０    ネットワークスイッチ（ＮＳ）
６０    ユーザ／リクエスト発行部
１００，１００Ａ，１００Ｂ    事前分析フェーズ用の分析装置
２００    運用フェーズ用の分析装置
１１０    処理部（ＣＰＵ；コンピュータ）
１１１    ログ採取部
１１２    フロー解析部
１１２ａ    コンポーネント種別取得部
１１２ｂ    パス表作成部（対応表作成部）
１１２ｃ    出現頻度取得部
１１３    パラメータ抽出部
１１３ａ    共通パラメータ抽出部
１１３ｂ    特定パラメータ抽出部
１１４    パラメータ加工部
１２０    記憶部（メモリ）
１２１    ログ定義
１２２    アクセスログ
１２３    詳細ログ
１２４    コンポーネント定義
１２５    パス表
１２６，１２６Ａ，１２６Ｂ    パラメータ表
１２７    パス情報
１２８Ａ，１２８Ｂ    頻度表
Ｆ１，Ｆ２，Ｆ３，Ｆ４，Ｆｉ    機能（処理）
ｐ１，ｐ２，…    ネットワークコンポーネント（コンポーネント，モジュール，チェックポイント）
【図１】
2015095065.tif 000003
【図２】
2015095065.tif 000004
【図３】
2015095065.tif 000005
【図４】
2015095065.tif 000006
【図５】
2015095065.tif 000007
【図６】
2015095065.tif 000008
【図７】
2015095065.tif 000009
【図８】
2015095065.tif 000010
【図９】
2015095065.tif 000011
【図１０】
2015095065.tif 000012
【図１１】
2015095065.tif 000013
【図１２】
2015095065.tif 000014
【図１３】
2015095065.tif 000015
【図１４】
2015095065.tif 000016
【図１５】
2015095065.tif 000017
【図１６】
2015095065.tif 000018
【図１７】
2015095065.tif 000019
【図１８】
2015095065.tif 000020
【図１９】
2015095065.tif 000021
【図２０】
2015095065.tif 000022
【図２１】
2015095065.tif 000023