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

Description

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

アプリケーションプログラムやネットワークサービス等において、実際に運用を行なっている状況下で、遅延個所や異常個所を特定することが試みられている。

通常、遅延個所や異常個所を特定するためには、その個所の前後のログを採取して、状態を監視し続ける必要がある。例えばstart−Ａ−Ｂ−Ｃ−Ｄ−endという処理シーケンスの場合、Ａの直前、Ａ−Ｂ間、Ｂ−Ｃ間、Ｃ−Ｄ間、Ｄの直後でタイムスタンプの付いたログが採取される。これにより、処理Ａ〜Ｄのいずれにおいて、遅延が発生しているかを特定することができる。例えば処理Ｂが遅延している場合、Ｂの直前（Ａ−Ｂ間）のログと、Ｂの直後（Ｂ−Ｃ間）のログとを参照することで、処理Ｂを遅延個所として特定することができる。

その一方で、アプリケーションプログラムやネットワークサービスにおいて、遅延個所や異常個所を特定するためには、多数の監視個所で大量のログを採取する必要がある。このため、遅延個所や異常個所の絞込みや特定には、多大なオーバヘッド及びネットワーク負荷が発生する。

特開平８−１４７３４４号公報 特開２０００−８３０５７号公報

運用時に余分なオーバヘッドやネットワーク負荷を発生させることなく問題個所（遅延個所や異常個所）を特定するために、事前に詳細なログを採取分析して機能（処理）毎のパス情報（動作フロー）を取得することが試みられている。この場合、運用時には、実際の運用情報（リクエストログ）が取得される。そして、問題発生時には、事前に取得されたパス情報と、運用時に取得された運用情報とを用いて、問題個所の分析特定が行なわれる。以下、問題個所を、遅延原因個所あるいは問題コンポーネントという場合がある。

ここで、パス情報は、例えば、各機能で使用されるコンポーネントを特定する情報（コンポーネント群）を含む。このとき、Ｗｅｂ（ウエブ）の機能毎のパス情報は、例えば、ＵＲＬ（Uniform Resource Locator）を含むＵＲＩ（Uniform Resource Identifier）によって分類される。

例えば図２に示すごとくｃ１〜ｃ５をネットワークコンポーネントとした場合、各コンポーネントｃ１〜ｃ５を流れるメッセージデータを分析する。これにより、各機能Ｆｉ（ｉは自然数）で用いられるコンポーネントは、各機能Ｆｉに対応するＵＲＬ＋ＣＧＩ（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）のパス＝ｃ３−ｃ４

しかし、機能（ＵＲＬ＋ＣＧＩパラメータ）が同一であっても、運用時間帯や曜日や、リクエストパターンやデータベースの状況などに依っては、当該同一の機能に対応する各パス情報に、異なるコンポーネントが含まれる場合がある。つまり、前記状況に依って、同一の機能が、異なるパス情報を有し、異なる複数のパスを通る場合がある。この場合、当該同一の機能についての異なるパス情報は、当該同一の機能についての一つのパス情報に統合され、統合されたパス情報は、異なるコンポーネントの全てを含むように規定される。このため、パス情報には、不定（非決定的）な部分が含まれる場合がある。パス情報に不定な部分が含まれていると、実運用時に、或るリクエストがどのコンポーネントを使ったかが不明のまま分析処理が行なわれ、遅延原因個所を正確に特定（推定）することができない。

一つの側面で、本発明は、問題個所を正確に特定できるようにすることを目的とする。

本件の分析方法は、コンピュータが、複数の機能のそれぞれが使用する一以上のコンポーネントに係る情報を含む事前に取得される前記機能毎のパス情報と、運用時に取得される運用情報と、に基づき、前記一以上のコンポーネントの中から問題コンポーネントを問題個所として特定する。本件の分析方法は、前記コンピュータが、前記複数の機能のうちの同一の機能が使用する場合と使用しない場合とがあるコンポーネントを、不定コンポーネントとして事前に抽出する。また、本件の分析方法は、前記運用時に前記不定コンポーネントが使用されたかを検知する。さらに、本件の分析方法は、前記運用時に問題が生じた場合、前記パス情報と前記運用情報と前記不定コンポーネントの使用検知結果とに基づき、前記問題個所を特定する。

一実施形態によれば、問題個所を正確に特定することができる。

本実施形態に係る分析装置を適用されるネットワークシステムの一例、及び本実施形態に係る分析装置の機能構成の一例を示すブロック図である。 機能とコンポーネント群との対応関係（パス情報）の一例を示す図である。 同一の機能について、異なるコンポーネントを含む二つのパス情報が取得される場合の一例を示す図である。 図３に示す例について、同一の機能についての異なる二つのパス情報と当該二つのパス情報を統合した一つのパス情報とを示す図である。 実運用時に取得されるパス情報の第１例を示す図である。 図５に示すパス情報に基づく遅延原因個所の特定処理の第１例を説明する図である。 実運用時に取得されるパス情報の第２例を示す図である。 図７に示すパス情報に基づく遅延原因個所の特定処理の第２例を説明する図である。 （Ａ）〜（Ｃ）は本実施形態の分析手順の第１例を説明する図である。 （Ａ）〜（Ｃ）は本実施形態の分析手順の第２例を説明する図である。 本実施形態の分析方法における運用時ログ採取個所情報の決定処理の一例を説明する図である。 本実施形態の分析方法における、運用時に採取したログを用いた遅延原因個所の特定処理の一例を説明する図である。 本実施形態の使用情報出力コード（第１コード）の追加処理の一例を説明するフローチャートである。 本実施形態におけるＡＰサーバの運用時処理の一例を説明するフローチャートである。 本実施形態における遅延原因個所の特定処理の一例を説明するフローチャートである。 （Ａ）及び（Ｂ）は本実施形態の第１変形例を説明する図である。 （Ａ）及び（Ｂ）は本実施形態の第２変形例を説明する図である。

以下、図面を参照して実施形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、以下に明示しない種々の変形や技術が実施形態に適用されることは排除されない。また、以下に説明する各種の例示的態様は、適宜に組み合わせて実施しても構わない。なお、以下の実施形態で用いる図面において、同一符号を付した部分は、特に断らない限り、同一若しくは同様の部分を表す。

〔１〕本実施形態に係る分析装置を適用されるネットワークシステムの構成
まず、図１を参照しながら、本実施形態に係る分析装置を適用されるネットワークシステムの構成について説明する。なお、図１は、本実施形態に係る分析装置を適用されるネットワークシステムの一例、及び本実施形態に係る分析装置の機能構成の一例を示すブロック図である。

図１に示すネットワークシステムは、例えば、インターネット等のネットワーク１０と、当該ネットワーク１０に接続されるサーバ群（符号２０，３０，４０参照）と、ネットワークスイッチ（ＮＳ）５０とを含む。サーバ群には、例えば、Ｗｅｂサーバ３０や、アプリケーション（ＡＰ）サーバ４０、その他のサーバ２０等が含まれる。

ＡＰサーバ４０は、本実施形態に係る分析装置としての機能を実現すべく、例えば、事前分析ブロック４０１、運用ブロック４０２、ユーザリクエストデータベース４０３、パス情報データベース４０４、及び、運用時ログ採取個所情報データベース４０５を含む。以下、データベースはＤＢと略記する場合がある。

ＡＰサーバ４０は、例えば、ＣＰＵ（Cenrtral Processing Unit）等の処理部、ＲＯＭ（Read Only Memory），ＲＡＭ（Random Access Memory）等のメモリ、ＨＤＤ（Hard Disk Drive），ＳＳＤ（Solid State Drive）等の記憶装置、ＬＣＤ（Liquid Crystal Display）等の表示装置、印刷装置などを含む。ＡＰサーバ４０においては、ＣＰＵがメモリや記憶装置から所定のアプリケーションプログラムを読み出して実行することにより、各種機能が実現される。所定のアプリケーションプログラムには、例えば、後述する事前分析ブロック４０１や運用ブロック４０２としての機能を実現するプログラムの一例としての分析プログラムが含まれる。表示装置や印刷装置には、例えばＣＰＵによる演算結果等を出力することができる。なお、他のサーバ２０やＷｅｂサーバ３０についても、ハードウェアとして、上述と同様のＣＰＵ，メモリ，記憶装置，表示装置，印刷装置などが備えられる。

上述した所定のアプリケーションプログラムは、例えばフレキシブルディスク，ＣＤ（ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＣＤ−ＲＷなど），ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，ＤＶＤ−Ｒ，ＤＶＤ−ＲＷ，ＤＶＤ＋Ｒ，ＤＶＤ＋ＲＷなど），ブルーレイディスク等のコンピュータ読取可能な記録媒体に記録された形態で提供される。この場合、上記処理部は、当該記録媒体からプログラムを読み取って内部記憶装置または外部記憶装置に転送し格納して用いる。上記処理部は、ＣＰＵのほか、ＭＰＵ（Micro-Processing Unit），コンピュータ等であってもよい。

ユーザリクエストＤＢ４０３、パス情報ＤＢ４０４、及び運用時ログ採取個所情報ＤＢ４０５は、例えば、ＡＰサーバ４０のメモリや記憶装置によって実現される。

事前分析ブロック４０１は、事前分析フェーズにおいて、後述するごとく、パス情報や運用時ログ採取個所情報を生成する。事前分析ブロック４０１は、事前分析フェーズで用いられる分析装置の一例として捉えることができ、例えば、事前データ採取部４１０及びパス分析部４２０を含む。

事前データ採取部４１０は、ユーザリクエストＤＢ４０３のデータ（リクエスト等）を仮想ユーザのデータとしてネットワーク１０へ投入（送信）する。なお、事前データ採取部４１０は、実運用時の実際のリクエスト及び状態等を保存しておいて、実運用時の運用状態を再現するようにしてもよい。そして、事前データ採取部４１０は、仮想ユーザのデータ投入による結果として各サーバ２０，３０，４０に流れるメッセージデータを採取する。

パス分析部４２０は、事前データ採取部４１０によって採取されたデータに基づきパス分析を行ない、その分析結果として、例えば、パス情報及び運用時ログ採取個所情報を生成し取得する。取得されたパス情報及び運用時ログ採取個所情報は、それぞれパス情報ＤＢ４０４及び運用時ログ採取個所情報ＤＢ４０５に格納される。パス分析部４２０は、後述するパス情報取得部４２１の一例、不定コンポーネント抽出部４２２の一例及び再構成部４２３の一例として捉えることができる。

運用ブロック４０２は、運用フェーズにおいて、後述するごとく、運用情報（運用データ）と、事前分析ブロック４０１によって事前に生成されたパス情報及び運用時ログ採取個所情報とに基づき問題個所を特定する。運用ブロック４０２は、運用フェーズで用いられる分析装置の一例として捉えることができ、例えば、運用データ採取部４３０、機能選別部４４０、データスライス分割部４５０、及び問題箇所特定部４６０を含む。

運用データ採取部４３０は、運用フェーズにおいて、実運用でサーバ群２０，３０，４０に流れるデータから例えばＵＲＬ＋ＣＧＩパラメータ等を例えばログデータ（リクエストログ）として採取する。運用データ採取部４３０は、後述する運用情報取得部４３１の一例及び検知部４３２の一例として捉えることができる。

なお、実運用では「前面のサーバ」の情報のみ採取するようにしてよい。「前面のサーバ」とは、事前分析フェーズにおける「全サーバ」と対比して、ユーザからのリクエストを受け付ける、最もユーザ側のサーバを意味する。図１に例示する構成ではＷｅｂサーバ３０が「前面のサーバ」に相当し得る。ただし、構成によっては、負荷分散サーバ（ロードバランサ；図示省略）が「前面のサーバ」に相当することもあれば、ＡＰサーバ４０が「前面のサーバ」に相当することもある。

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

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

問題個所特定部４６０は、データスライス分割部４５０によって切り出された時間区間について遅延の検知を行なう。問題個所特定部４６０は、遅延を検知した場合、後述するごとく、パス情報ＤＢ４０４のパス情報と照らし合わせて、問題個所の絞込み又は特定を行なう。問題個所特定部４６０は、後述する特定部の一例として捉えることができる。

なお、事前分析ブロック４０１及び運用ブロック４０２における各種機能は、本実施形態のネットワークシステムに含まれるＰＣ（Personal Computer）等の処理装置によって実現されてもよいし、本実施形態のネットワークシステムに含まれるＡＰサーバ４０等によって実現されてもよい。また、事前分析ブロック４０１及び運用ブロック４０２における各種機能は、一台の処理装置、もしくは、一台のＡＰサーバ４０等によって実現されてもよい。

本実施形態では、運用ブロック４０２において運用時に余分なオーバヘッドやネットワーク負荷を発生させることなく問題個所を特定するために、事前分析ブロック４０１において、事前に詳細なログを採取分析して機能（処理）毎のパス情報が生成されて取得されている。ここで、パス情報は、図２を参照しながら前述したように、例えば、各機能で使用されるコンポーネントを特定する情報（コンポーネント群）を含む。このとき、Ｗｅｂの機能毎のパス情報は、例えばＵＲＩ（ＵＲＬ）によって分類される。

例えば図２を参照しながら前述したように、各コンポーネントｃ１〜ｃ５を流れるメッセージデータを分析することで、各機能Ｆｉ（ｉは自然数）で用いられるコンポーネントは、各機能Ｆｉに対応するＵＲＩを用いて、機能Ｆｉ毎に分類される。以下、各機能Ｆｉに対応するＵＲＩをＵＲＬｉと表記する場合がある。

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

例えば図２を参照しながら前述したように、ｃ１〜ｃ５をネットワークコンポーネントとした場合、各コンポーネントｃ１〜ｃ５を流れるメッセージデータを分析し、ＵＲＬ＋ＣＧＩパラメータで機能Ｆｉを分類する。

なお、コンポーネントｃ１〜ｃ５は、プログラムのメソッド単位、ブロック単位として処理することもできる。「コンポーネント」という用語は、「モジュール」あるいは「チェックポイント」という用語に置き換えて使用してもよい。また、「パス」は、「コンポーネント」の集合（コンポーネント群）として位置付けられる。各機能（処理）Ｆｉと複数のコンポーネントｃ１〜ｃ５との対応関係を示す情報のことを「パス情報」と呼ぶ。さらに、「コンポーネント」を「コンポ」と略記する場合がある。

ここで、運用フェーズで用いられる運用ブロック４０２による問題個所（異常個所）の特定機能について、簡単に説明する。図２に示す例において、通常時に比べ機能Ｆ１及びＦ２が遅延した場合、運用ブロック４０２においては、パス情報に照らし合わせることで機能Ｆ１及びＦ２に対応するコンポーネントｃ１，ｃ２，ｃ３，ｃ４，ｃ５が問題個所である可能性をもつと判断することができる。

さらに、運用ブロック４０２においては、例えば、機能Ｆ３及びＦ４は遅延していないという情報と、機能Ｆ３及びＦ４のパス情報とにより、機能Ｆ１，Ｆ２及びＦ３の共通コンポーネントｃ１，ｃ２，ｃ３，ｃ４には問題がないと判断することができる。その結果、運用ブロック４０２（問題個所特定部４６０）においては、残ったコンポーネントｃ５を遅延原因個所として特定することができる。

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

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

〔２〕本実施形態に係る分析装置の概要
ところで、機能（リクエスト）に対応する「ＵＲＬ＋ＣＧＩパラメータ」が同一であっても、運用時間帯や曜日や、リクエストパターンやデータベースの状況などに依っては、当該同一の機能（リクエスト）に対応するパス情報の内容（コンポーネント集合の要素）が異なる場合がある。つまり、各機能に対応するパス情報に、異なるコンポーネントが含まれ、各リクエストによる動作が不定になる場合がある。

このような場合、二以上の同一の機能（リクエスト）は一つの機能（リクエスト）に統合され、統合された機能のパス情報は、異なるコンポーネントの全てを含むように規定される。このように二以上の同一の機能を一つの機能に統合する具体的な例について、図３および図４を参照しながら説明する。

ここで、図３は、同一の機能（ＵＲＬ＋ＣＧＩパラメータ）について、異なるコンポーネントを含む二つのパス情報が取得される場合の一例を示す図である。図４は、図３に示す例について、同一の機能についての異なる二つのパス情報と当該二つのパス情報を統合した一つのパス情報とを示す図である。

図３に示す例では、同一の「ＵＲＬ＋ＣＧＩパラメータ」（/foo/func?k1=v1）のそれぞれに対し、異なる二つのパス（ａ１）及び（ａ２）が取得されている。パス（ａ１）は、図３に示すように、コンポーネントｃ１，ｃ２，ｃ３，ｃ４を含む。パス（ａ２）は、図３に示すように、コンポーネントｃ１，ｃ２，ｃ３，ｃ５を含む。

また、図４の上段においては、各機能に対応するパスに含まれるコンポーネントがテーブル形式で示されている。図３及び図４において、各機能に対応するパスに含まれるコンポーネントには“１”が付与されている。

図３、及び図４の上段に示すように、パス（ａ１）とパス（ａ２）とにおいてコンポーネントｃ１，ｃ２，ｃ３は共通して含まれるが、コンポーネントｃ４はパス（ａ１）のみに含まれ、コンポーネントｃ５はパス（ａ２）のみに含まれる。

このような場合、同一の「ＵＲＬ＋ＣＧＩパラメータ」（/foo/func?k1=v1）について
の二つのパス情報は一つのパス情報に統合される。これにより、図４の上段に示す、同一の機能に対応する二つのパス（ａ１）とパス（ａ２）とは、図４の下段に示すように、一つのパス情報にまとめて定義される。したがって、統合後のパス情報は、５つのコンポーネントｃ１〜ｃ５を含む。

なお、図３及び図４における同一の機能（ＵＲＬ＋ＣＧＩパラメータ）は、以下、ＵＲＬ１と表記する場合がある。

しかしながら、上述のごとく二つのパス（ａ１），（ａ２）を統合して一つのパス情報として定義した場合、統合後のパス情報には、コンポーネントｃ４，ｃ５が不定（非決定的）な部分として含まれる。パス情報に不定な部分（例えばｃ４，ｃ５）が含まれていると、実運用時（システムの本番実行時）に、或るリクエスト（機能）がコンポーネントｃ４，ｃ５のどちらを使ったかが不明のまま分析処理が行なわれる。このため、図５〜図８を参照しながら具体的に説明するように、遅延原因個所を正確に特定することができない。

ここで、図５は、実運用時に取得されるパス情報の第１例を示す図であり、図６は、図５に示すパス情報に基づく遅延原因個所の特定処理の第１例を説明する図である。また、図７は、実運用時に取得されるパス情報の第２例を示す図であり、図８は、図７に示すパス情報に基づく遅延原因個所の特定処理の第２例を説明する図である。

まず、図５及び図６を参照しながら、パス情報に不定な部分が含まれる場合の遅延原因個所の特定処理の第１例について説明する。図５及び図６に示すように、ＵＲＬ１のパス情報は、二つのパス（ａ１），（ａ２）を統合したものであり、５つのコンポーネントｃ１〜ｃ５を含む。また、ＵＲＬ２のパス（ｂ１）は、３つのコンポーネントｃ１〜ｃ３を含む。

ここで、図６に示すように、ＵＲＬ１の処理において遅延が生じ、ＵＲＬ２の処理は正常に実行されたものとする。この場合、ＵＲＬ１のパス情報は二つのパス（ａ１）及び（ａ２）を統合しているので、遅延原因個所をコンポーネントｃ４，ｃ５に絞り込むことはできるが、遅延原因個所がコンポーネントｃ４，ｃ５のいずれであるかを特定することはできない。

例えば、遅延の生じたリクエストがＵＲＬ１の（ａ１）のパスを通る場合、遅延原因個所はコンポーネントｃ４である一方、遅延の生じたリクエストがＵＲＬ１の（ａ２）のパスを通る場合、遅延原因個所はコンポーネントｃ５である。しかし、コンポーネントｃ４とｃ５とのどちらが使用されたかを正しく認識することができないため、遅延原因個所をコンポーネントｃ４及びｃ５よりも詳細に絞り込むことができない。

ついで、図７及び図８を参照しながら、パス情報に不定な部分が含まれる場合の遅延原因個所の特定処理の第２例について説明する。図７及び図８に示すように、ＵＲＬ１のパス情報は、前述したように、二つのパス（ａ１），（ａ２）を統合したものであり、５つのコンポーネントｃ１〜ｃ５を含む。また、ＵＲＬ３のパス（ｂ２）は、３つのコンポーネントｃ２，ｃ３，ｃ５を含む。

ここで、図８に示すように、ＵＲＬ３の処理において遅延が生じ、ＵＲＬ１の処理は正常に実行されたものとする。この場合、例えば、正常リクエストがＵＲＬ１の（ａ１）のパスを通るのであれば、ＵＲＬ１のパス情報はコンポーネントｃ１〜ｃ４を含みコンポーネントｃ５を含まない。したがって、ＵＲＬ３のパス（ｂ２）を考慮すると、遅延原因個所をコンポーネントｃ５に絞り込むことができる。

つまり、正常リクエストがＵＲＬ１の（ａ１）のパスを通ることが分かっていれば、コンポーネントｃ５を遅延原因個所として特定できるはずである。しかしながら、ＵＲＬ１のパス情報として二つのパス（ａ１）及び（ａ２）を統合した結果を用いて分析するため、図８に示すように、遅延原因個所の見逃しが発生してしまう。換言すると、二以上のパスを一つのパス情報に統合して定義する手法では、リクエストが、統合する前の元のパス（ａ１）及び（ａ２）のうち、どちらのパスのものか分からず、遅延原因個所の特定を正確に行なうことができない。

そこで、本実施形態では、事前の分析を行なってパス情報（動作フロー情報）を取得する際、機能（ＵＲＬ＋ＣＧＩパラメータ）が同一でパス（＝コンポーネントの集合）の異なるリクエストがある場合（動作が不定のリクエストがある場合）、不定な部分（不定コンポーネント）が抽出される。そして、実運用時には、遅延原因個所を特定するための必要最小限の情報である、不定な部分に係る情報（不定コンポーネントの使用検知結果）が取得され、不定な部分に係る情報に基づき、遅延原因個所が正確に特定（推定）される。なお、以下では、「実運用」を単に「運用」という場合がある。

特に、本実施形態の分析方法（以下「本方法」という場合がある）においては、以下の構成により、問題個所（遅延原因個所）を正確に特定することができる。

例えば、本方法は、複数の機能のそれぞれが使用する一以上のコンポーネントに係る情報を含む事前に取得される前記機能毎のパス情報と、運用時に取得される運用情報と、に基づき、前記一以上のコンポーネントの中から問題コンポーネントを問題個所として特定する。

このとき、本方法は、前記複数の機能のうちの同一の機能が使用する場合と使用しない場合とがあるコンポーネントを、不定コンポーネントとして事前に抽出する。また、本方法は、前記運用時に前記不定コンポーネントが使用されたかを検知する。そして、本方法は、前記運用時に問題が生じた場合、前記パス情報と前記運用情報と前記不定コンポーネントの使用検知結果とに基づき、前記問題個所を特定する。

このような構成により、事前の分析を行なってパス情報を取得する際に、機能が同一でパスの異なるリクエストがある場合、不定コンポーネントが抽出される。そして、運用時に、問題が生じた場合、問題個所を特定するための必要最小限の情報である、不定コンポーネントの使用検知結果が取得され、当該使用検知結果に基づき、図３〜図８を参照しながら前述した手法では不定であった部分の分析を決定的に行なうことができる。したがって、問題個所を正確に特定することができる。

〔３〕本実施形態に係る分析装置の機能構成
次に、図１を参照しながら、事前分析ブロック４０１，運用ブロック４０２，ユーザリクエストＤＢ４０３，パス情報ＤＢ４０４及び運用時ログ採取個所情報ＤＢ４０５を含む本実施形態に係る分析装置の機能構成について説明する。

事前分析ブロック４０１におけるパス分析部４２０は、パス情報取得部４２１、不定コンポーネント抽出部４２２及び再構成部４２３を含む。

パス情報取得部４２１は、複数の機能（ＵＲＬ＋ＣＧＩパラメータ）のそれぞれが使用する一以上のコンポーネント（モジュール，メソッド）に係る情報を含む機能毎のパス情報を、事前に取得する。

このとき、パス情報取得部４２１は、同一の機能についての異なるパス情報を前記同一の機能についての一つのパス情報に統合し、統合した前記一つのパス情報として、後述する不定コンポーネント抽出部４２２によって抽出される不定コンポーネントに係る情報を規定する（図９（Ｂ）や図１０（Ｂ）の“２”参照）。

また、パス情報取得部４２１は、同一の機能が常に使用するコンポーネントを決定コンポーネントとして認識し、統合した一つのパス情報として、決定コンポーネントに係る情報を規定する（図９（Ｂ）や図１０（Ｂ）の“１”参照）。

パス情報取得部４２１は、上述のごとく事前に取得したパス情報を、パス情報ＤＢ４０４に記録保存する。

またさらに、パス情報取得部４２１は、上述のごとく取得されたパス情報に基づき、運用時にログを採取すべき個所を示すログ採取個所情報（図１１参照）を事前に取得し、運用時ログ採取個所情報ＤＢ４０５に記録保存する。

不定コンポーネント抽出部４２２は、複数の機能のうちの同一の機能が使用する場合と使用しない場合とがあるコンポーネントを、不定コンポーネントとして事前に抽出する。

一方、運用ブロック４０２における運用データ採取部４３０は、運用情報取得部４３１及び検知部４３２を含む。

運用情報取得部４３１は、運用時つまり運用フェーズにおいて、サーバ群２０，３０，４０に流れるデータから、例えばＵＲＬ＋ＣＧＩパラメータ，処理時刻，応答時間等を、運用情報（図１２上段の運用データ（運用ログ）参照）として取得する。

検知部４３２は、運用時ログ採取個所情報ＤＢ４０５及びＡＰサーバ４０の運用時ログ出力部４１と協働して、運用時にどの不定コンポーネントが使用されたかを検知する。

このとき、検知部４３２は、運用開始時、具体的にはパス情報及び運用自ログ採取個所情報の取得後で運用開始前に、運用時ログ採取個所情報ＤＢ４０５（もしくはパス情報ＤＢ４０４）を参照する。検知部４３２は、運用時ログ採取個所情報ＤＢ４０５を参照することで、複数の機能のそれぞれについて取得されたパス情報において規定される不定コンポーネントを、使用検知対象として認識する。そして、検知部４３２は、運用時に、使用検知対象として認識した不定コンポーネントが使用されたかを検知する。

より具体的に、本実施形態において、運用開始時に、使用検知対象として認識した不定コンポーネントが運用時に使用されると第１使用検知情報（使用情報）を出力する第１コード（使用情報出力コード）が、不定コンポーネントに対して追加される。使用情報出力コードの追加には、例えばバイトコードインジェクションツールが用いられる。また、使用情報出力コードの追加は、運用データ採取部４３０における検知部４３２によって行なわれてもよいし、パス分析部４２０によって行なわれてもよい。そして、実運用中のＡＰサーバ４０において、使用情報出力コードを付されたコンポーネントが使用されると、ＡＰサーバ４０における運用時ログ出力部４１が、第１使用検知情報（使用情報）を検知部４３２に対して出力する。

問題個所特定部（特定部）４６０は、運用時に問題（遅延）が生じた場合、上述したパス情報と運用情報と不定コンポーネントの使用検知結果（第１使用検知情報）とに基づき、一以上のコンポーネントの中から問題コンポーネントを問題個所として特定する。

なお、運用時ログ出力部４１、運用時ログ採取個所情報ＤＢ４０５及び検知部４３２は、図１６（Ａ）や図１６（Ｂ）を参照しながら後述する本実施形態の第１変形例を実現する際にも用いられる。

このとき、検知部４３２は、運用開始時に、パス情報を事前に取得する際に前記複数の機能がいずれも使用しなかった未使用コンポーネントに対して、上述した第１コードと同様の第２コード（使用情報出力コード）を追加する。当該第２コードも、第１コードと同様、未使用コンポーネントが運用時に使用されると第２使用検知情報（使用情報）を、当該未使用コンポーネントを使用したＡＰサーバ４０等に出力させる。

当該第２コードを用いることで、実運用中のＡＰサーバ４０において、使用情報出力コードを付されたコンポーネントが使用されると、ＡＰサーバ４０における運用時ログ出力部４１から、第２使用検知情報（使用情報）が検知部４３２に対して出力される。

再構成部４２３は、図１６（Ａ）や図１６（Ｂ）を参照しながら後述する本実施形態の第１変形例を実現する際に用いられるもので、第２使用検知情報が出力された場合、パス情報を、未使用コンポーネントを含むように再構成する。ここでは、再構成部４２３としての機能は、パス分析部４２０に含まれているが、第２使用検知情報を受信する運用データ採取部４３０に含まれていてもよい。

そして、問題個所特定部４６０は、運用時に問題（遅延）が生じた場合、再構成部４２３によって再構成されたパス情報と、運用情報と、第２使用検知情報とに基づき、一以上のコンポーネントの中から問題コンポーネントを問題個所として特定する。

また、不定コンポーネント抽出部４２２は、図１７（Ａ）や図１７（Ｂ）を参照しながら後述する本実施形態の第２変形例を実現する際にも用いられる。

このとき、不定コンポーネント抽出部４２２は、機能毎のパス情報と当該パス情報に含まれる一以上のコンポーネントとの関係について事前学習を行なう。そして、不定コンポーネント抽出部４２２は、当該事前学習の結果、同一の機能が使用する場合と使用しない場合とがあるコンポーネントを、不定コンポーネントとして抽出してもよい。

〔４〕本実施形態に係る分析装置の動作
ついで、図９〜図１５を参照しながら、本実施形態に係る分析装置の動作について説明する。

〔４−１〕本実施形態の分析手順の第１例
まず、図９（Ａ）〜図９（Ｃ）を参照しながら、本実施形態の分析手順の第１例について説明する。特に、本第１例では、図５及び図６を参照しながら前述したような不定な部分がパス情報に含まれる場合の分析手順について説明する。

事前分析に際して、まず、事前データ採取部４１０によって、ユーザリクエストＤＢ４０３のデータ（リクエスト等）が、仮想ユーザのデータとしてネットワーク１０へ投入される。これにより、事前データ採取部４１０によって、仮想ユーザのデータ投入による結果として各サーバ２０，３０，４０に流れるメッセージデータが採取される。

そして、採取されたデータに基づき、パス分析部４２０におけるパス情報取得部４２１及び不定コンポーネント抽出部４２２は、以下のようなパス分析を行なう。

例えば、図９（Ａ）に示すように、まず手順Ｓ１において、不定コンポーネント抽出部４２２は、不定コンポーネントを事前に抽出する。このとき、複数の機能のうちの同一の機能が使用する場合と使用しない場合とがあるコンポーネントを、不定コンポーネントとして事前に抽出する。

換言すると、同一の機能（ＵＲＬ＋ＣＧＩパラメータ；リクエスト）において１００％使用されるコンポーネント（メソッド）は、決定コンポーネント（決定的な部分）として抽出される。一方、同一の機能（ＵＲＬ＋ＣＧＩパラメータ）において使用される場合と使用されない場合とがあるコンポーネント（メソッド）は、不定コンポーネントとして抽出される。なお、決定コンポーネントは、不定コンポーネント抽出部４２２によって抽出されてもよいし、パス情報取得部４２１によって抽出されてもよいし、パス情報取得部４２１と不定コンポーネント抽出部４２２との協働によって抽出されてもよい。

図９（Ａ）に示す例では、同一のＵＲＬ１について異なるパス〔パス（ａ１）＝ｃ１−ｃ２−ｃ３−ｃ４及びパス（ａ２）＝ｃ１−ｃ２−ｃ３−ｃ５〕が得られる。このとき、コンポーネントｃ１〜ｃ３は、同一のＵＲＬ１の両方のパスで用いられるため、決定コンポーネントとして認識される。コンポーネントｃ４は、一方のパス（ａ１）で用いられ他方のパス（ａ２）で用いられないため、不定コンポーネントとして認識される。同様に、コンポーネントｃ５も、一方のパス（ａ２）で用いられ他方のパス（ａ１）で用いられないため、不定コンポーネントとして認識される。また、ＵＲＬ２については一つのパス（ｂ１）が得られ、当該パス（ｂ１）では三つのコンポーネントｃ１〜ｃ３が用いられている。このため、ＵＲＬ２について、三つのコンポーネントｃ１〜ｃ３は決定コンポーネントとして認識される。

これに伴い、パス情報取得部４２１によって、図９（Ｂ）に示すように、パス（ａ１）とパス（ａ２）とを一つに統合して一つのＵＲＬ１に対応付けたパス情報が生成されるとともに、ＵＲＬ２についてのパス情報が生成される（手順Ｓ１）。図９（Ｂ）に示すＵＲＬ１についてのパス情報では、コンポーネントｃ１〜ｃ３が決定コンポーネント（決定的な部分）である旨を示す“１”が設定され、コンポーネントｃ４，ｃ５が不定コンポーネント（不定な部分）である旨を示す“２”が設定される。また、図９（Ｂ）に示すＵＲＬ２についてのパス情報では、コンポーネントｃ１〜ｃ３が決定コンポーネント（決定的な部分）である旨を示す“１”が設定される。上述のごとく事前に取得されたパス情報は、パス情報ＤＢ４０４に記録保存される。

なお、図１１及び図１２を参照しながら後述する例では、上述のごとく事前に取得されたパス情報に基づき、運用時にログを採取すべき個所を示すログ採取個所情報（図１１参照）が事前に取得され、運用時ログ採取個所情報ＤＢ４０５に記録保存される。しかし、ここでは、運用時ログ採取個所情報の取得は省略され、図９（Ｂ）に示すごときパス情報において“２”を設定された不定コンポーネントｃ４，ｃ５が、運用時にログを採取すべき個所（使用検知対象）として認識される。後述する分析手順の第２例についても同様である。

上述のごとくパス情報を事前に取得した後、図９（Ａ）に示す例では、運用開始時（パス情報及び運用自ログ採取個所情報の取得後で運用開始前）に、検知部４３２はパス情報ＤＢ４０４を参照する。そして、手順Ｓ２において、検知部４３２は、決定コンポーネントｃ１〜ｃ３には使用情報出力コードを追加せず（運用ログを採らず）、不定コンポーネントｃ４，ｃ５には使用情報出力コードを追加する（運用ログを採る）。

これにより、使用情報出力コードを追加された不定コンポーネントｃ４，ｃ５が実運用時に使用されると、ＡＰサーバ４０における運用時ログ出力部４１が起動され、第１使用検知情報（使用情報）が、運用ログとして検知部４３２に対し出力される。したがって、検知部４３２は、運用時に、使用検知対象である不定コンポーネントｃ４とｃ５とのいずれかが使用されたか否かを検知することができる。

つまり、運用時には、運用情報取得部４３１によって、サーバ群２０，３０，４０に流れるデータから、運用ログ（例えば図１２上段参照）が取得される。その際、検知部４３２によって、ＡＰサーバ４０の運用時ログ出力部４１と協働して、運用時にどの不定コンポーネントが使用されたかが検知される。

ここで、図６に示す例と同様、ＵＲＬ１の処理（リクエスト）において遅延が生じ、ＵＲＬ２の処理（リクエスト）は正常に実行されたものとする。

このとき、運用時に、ＵＲＬ１についてコンポーネントｃ４の使用を示す使用情報が運用時ログ出力部４１から出力されると、図９（Ｃ）の上段（遅延原因個所の特定処理時のデータ）に示すごとく、ＵＲＬ１のｃ４のコンポーネント情報“１”が追加される。これに伴い、問題個所特定部４６０は、コンポーネントｃ４を問題コンポーネント（問題個所）として特定することができる（手順Ｓ３）。

一方、運用時に、ＵＲＬ１についてコンポーネントｃ５の使用を示す使用情報が運用時ログ出力部４１から出力されると、図９（Ｃ）の下段（遅延原因個所の特定処理時のデータ）に示すごとく、ＵＲＬ１のｃ５のコンポーネント情報“１”が追加される。これに伴い、問題個所特定部４６０は、コンポーネントｃ５を問題コンポーネント（問題個所）として特定することができる（手順Ｓ３）。

このようにして、運用時にコンポーネントｃ４とｃ５とのどちらが使用されたかを正しく認識することができ、遅延原因個所をコンポーネントｃ４とｃ５とのいずれか一方に絞り込むことができる。このため、本実施形態によれば、遅延原因個所を正確に特定することができる。

〔４−２〕本実施形態の分析手順の第２例
ついで、図１０（Ａ）〜図１０（Ｃ）を参照しながら、本実施形態の分析手順の第２例について説明する。特に、本第２例では、図７及び図８を参照しながら前述したような不定な部分がパス情報に含まれる場合の分析手順について説明する。

本第２例においても、上述した分析手順の第１例と同様、事前分析に際して、事前データ採取部４１０によって、各サーバ２０，３０，４０に流れるメッセージデータが採取される。そして、採取されたデータに基づき、パス情報取得部４２１及び不定コンポーネント抽出部４２２は、上述した分析手順の第１例と同様のパス分析を行なう。

図１０（Ａ）に示す例でも、図９（Ａ）に示した例と同様、同一のＵＲＬ１について異なるパス（ａ１）及び（ａ２）が得られる。このとき、コンポーネントｃ１〜ｃ３は、同一のＵＲＬ１の両方のパスで用いられるため、決定コンポーネントとして認識される。コンポーネントｃ４は、一方のパス（ａ１）で用いられ他方のパス（ａ２）で用いられないため、不定コンポーネントとして認識される。同様に、コンポーネントｃ５も、一方のパス（ａ２）で用いられ他方のパス（ａ１）で用いられないため、不定コンポーネントとして認識される。また、ＵＲＬ３については一つのパス（ｂ２）が得られ、当該パス（ｂ２）では三つのコンポーネントｃ２，ｃ３，ｃ５が用いられている。このため、ＵＲＬ３について、三つのコンポーネントｃ２，ｃ３，ｃ５は決定コンポーネントとして認識される。

これに伴い、パス情報取得部４２１によって、図１０（Ｂ）に示すように、パス（ａ１）とパス（ａ２）とを一つに統合して一つのＵＲＬ１に対応付けたパス情報が生成されるとともに、ＵＲＬ３についてのパス情報が生成される（手順Ｓ１）。図１０（Ｂ）に示すＵＲＬ１についてのパス情報では、コンポーネントｃ１〜ｃ３が決定コンポーネント（決定的な部分）である旨を示す“１”が設定され、コンポーネントｃ４，ｃ５が不定コンポーネント（不定な部分）である旨を示す“２”が設定される。また、図１０（Ｂ）に示すＵＲＬ３についてのパス情報では、コンポーネントｃ２，ｃ３，ｃ５が決定コンポーネント（決定的な部分）である旨を示す“１”が設定される。上述のごとく事前に取得されたパス情報は、パス情報ＤＢ４０４に記録保存される。

上述のごとくパス情報を事前に取得した後、図１０（Ａ）に示す例でも、運用開始時に検知部４３２はパス情報ＤＢ４０４を参照する。そして、手順Ｓ２において、検知部４３２は、決定コンポーネントｃ１〜ｃ３には使用情報出力コードを追加せず（運用ログを採らず）、不定コンポーネントｃ４，ｃ５には使用情報出力コードを追加する（運用ログを採る）。

これにより、使用情報出力コードを追加された不定コンポーネントｃ４，ｃ５が実運用時に使用されると、ＡＰサーバ４０における運用時ログ出力部４１が起動され、第１使用検知情報（使用情報）が、運用ログとして検知部４３２に対し出力される。したがって、分析手順の第２例においても、上述した第１例と同様、検知部４３２は、運用時に、使用検知対象である不定コンポーネントｃ４とｃ５とのいずれかが使用されたか否かを検知することができる。

つまり、分析手順の第２例においても、上述した第１例と同様、運用時には、運用情報取得部４３１によって、サーバ群２０，３０，４０に流れるデータから、運用ログ（例えば図１２上段参照）が取得される。その際、検知部４３２によって、ＡＰサーバ４０の運用時ログ出力部４１と協働して、運用時にどの不定コンポーネントが使用されたかが検知される。

ここで、図８に示す例と同様、ＵＲＬ１の処理（リクエスト）は正常に実行され、ＵＲＬ３の処理において遅延が生じたものとする。

このとき、運用時に、ＵＲＬ１についてコンポーネントｃ４の使用を示す使用情報が運用時ログ出力部４１から出力されると、図１０（Ｃ）における遅延原因個所の特定処理時のデータに示すごとく、ＵＲＬ１のｃ４のコンポーネント情報“１”が追加される。

これに伴い、問題個所特定部４６０は、正常なリクエストがＵＲＬ１の（ａ１）のパスを通り、ＵＲＬ１のパス情報がコンポーネントｃ１〜ｃ４を含みコンポーネントｃ５を含まないことを認識することができる。したがって、問題個所特定部４６０は、ＵＲＬ３のパス情報（ｂ２）を考慮すると、遅延原因個所をコンポーネントｃ５に絞り込むことができる（手順Ｓ３）。このような組合せでＵＲＬ３が遅延している場合、正常なＵＲＬ１がコンポーネントｃ５を使用していることはあり得ない。

つまり、問題個所特定部４６０は、正常リクエストがＵＲＬ１の（ａ１）のパスを通ることを認識することができ、コンポーネントｃ５を遅延原因個所として特定することができる。したがって、ＵＲＬ１のパス情報として二つのパス（ａ１）及び（ａ２）を統合した結果を用いて分析しても、図８に示したような遅延原因個所の見逃しの発生を抑止することができる。このため、本実施形態によれば、遅延原因個所を正確に特定することができる。

〔４−３〕本実施形態の運用時ログ採取個所情報の決定処理の一例
次に、図１１を参照しながら、本実施形態の分析方法における運用時ログ採取個所情報の決定処理（事前分析フェーズ）の一例について説明する。

事前分析フェーズにおいて、まず、事前データ採取部４１０によって、ユーザリクエストＤＢ４０３のデータ（リクエスト等）が、仮想ユーザのデータとしてネットワーク１０へ投入される。これにより、事前データ採取部４１０によって、仮想ユーザのデータ投入による結果として、例えば図１１の上段に示す情報（リクエスト毎にパスを生成した情報）が採取される。

図１１の上段に示す情報には、リクエスト毎にＵＲＬと処理時刻（タイムスタンプ）と使用コンポーネント情報とが含まれる。具体的に、１番目のリクエストについて、“ＵＲＬ１”と、処理時刻“timestamp1”と、使用コンポーネント情報として“ｃ１：ｃ２：ｃ３：ｃ４”とが採取されている。２番目のリクエストについて、“ＵＲＬ２”と、処理時刻“timestamp2”と、使用コンポーネント情報として“ｃ１：ｃ２：ｃ３”とが採取されている。３番目のリクエストについて、“ＵＲＬ１”と、処理時刻“timestamp3”と、使用コンポーネント情報として“ｃ１：ｃ２：ｃ３：ｃ５”とが採取されている。４番目のリクエストについて、“ＵＲＬ３”と、処理時刻“timestamp4”と、使用コンポーネント情報として“ｃ２：ｃ３：ｃ５”とが採取されている。５番目のリクエストについて、“ＵＲＬ４”と、処理時刻“timestamp5”と、使用コンポーネント情報として“ｃ２：ｃ４”とが採取されている。６番目のリクエストについて、“ＵＲＬ４”と、処理時刻“timestamp6”と、使用コンポーネント情報として“ｃ２：ｃ３”とが採取されている。

図１１の上段に示すごとく採取された情報に基づき、パス情報取得部４２１及び不定コンポーネント抽出部４２２によって、以下のようなパス分析が行なわれ、図１１の中段に示すパス情報が取得されてパス情報ＤＢ４０４に保存される。

つまり、手順Ｓ１１において、リクエストＵＲＬ毎にパスが統合集約される。そして、ＵＲＬが同一のリクエストにおいて必ず使用されるコンポーネントは、決定コンポーネントとして抽出され、当該コンポーネントのパス情報として“１”が記録される。一方、ＵＲＬが同一のリクエストにおいて使用される場合と使用されない場合とがあるコンポーネントは不定コンポーネントとして抽出され、当該コンポーネントのパス情報として“２”が記録される。

例えば、図１１の中段に示すパス情報では、二つのリクエスト（ＵＲＬ１）について異なるパス（ｃ１：ｃ２：ｃ３：ｃ４とｃ１：ｃ２：ｃ３：ｃ５）が得られる。このとき、コンポーネントｃ１〜ｃ３は、二つのＵＲＬ１の両方のパスで用いられるため、決定コンポーネントとして認識される。コンポーネントｃ４は、一方のパスで用いられ他方のパスで用いられないため、不定コンポーネントとして認識される。同様に、コンポーネントｃ５も、一方のパスで用いられ他方のパスで用いられないため、不定コンポーネントとして認識される。したがって、ＵＲＬ１で使用されるコンポーネントｃ１〜ｃ５のパス情報としては、それぞれ１，１，１，２，２が設定される。

同様に、図１１の中段に示すパス情報では、二つのリクエスト（ＵＲＬ４）について異なるパス（ｃ２：ｃ４とｃ２：ｃ３）が得られる。このとき、コンポーネントｃ２は、二つのＵＲＬ４の両方のパスで用いられるため、決定コンポーネントとして認識される。コンポーネントｃ４は、一方のパスで用いられ他方のパスで用いられないため、不定コンポーネントとして認識される。同様に、コンポーネントｃ３も、一方のパスで用いられ他方のパスで用いられないため、不定コンポーネントとして認識される。したがって、ＵＲＬ４で使用されるコンポーネントｃ２〜ｃ４のパス情報としては、それぞれ１，２，２が設定される。

また、図１１の中段に示すパス情報では、ＵＲＬ２については一つのパスが得られ、当該パスではコンポーネントｃ１〜ｃ３が用いられている。このため、ＵＲＬ２について、コンポーネントｃ１〜ｃ３は決定コンポーネントとして認識される。したがって、ＵＲＬ２で使用されるコンポーネントｃ１〜ｃ３のパス情報としては、それぞれ１，１，１が設定される。

同様に、図１１の中段に示すパス情報では、ＵＲＬ３については一つのパスが得られ、当該パスではコンポーネントｃ２，ｃ３，ｃ５が用いられている。このため、ＵＲＬ３について、コンポーネントｃ２，ｃ３，ｃ５は決定コンポーネントとして認識される。したがって、ＵＲＬ３で使用されるコンポーネントｃ２，ｃ３，ｃ５のパス情報としては、それぞれ１，１，１が設定される。

そして、図１１の中段に示すごとく取得されたパス情報に基づき、パス情報取得部４２１によって、以下のような分析が行なわれ、図１１の下段に示す運用時ログ採取個所情報が取得されて運用時パスログ採取個所情報ＤＢ４０５に保存される。

つまり、手順Ｓ１２において、パス情報が参照され、いずれかのＵＲＬで不定（＝２）を記録されているコンポーネント（パス情報の縦の列のどこかに“２”を設定されたコンポーネント）はログ採取対象として認識される。そして、当該コンポーネントについて、ＤＢ４０５における運用時ログ採取個所情報に“１”が記録される。

例えば、図１１の中段に示すパス情報からは、手順Ｓ１２によって、コンポーネントｃ３，ｃ４，ｃ５について“１”を記録した、図１１の下段に示すような運用時ログ採取個所情報が、取得されて、運用時ログ採取個所情報ＤＢ４０５に保存される。

〔４−４〕本実施形態の遅延原因個所の特定処理の一例
次に、図１２を参照しながら、本実施形態の分析方法における、運用時に採取したログを用いた遅延原因個所の特定処理（運用フェーズ）の一例について説明する。

運用フェーズにおいて、まず、運用開始時に、運用時ログ採取個所情報ＤＢ４０５における運用時ログ採取個所情報（図１１の下段参照）が参照される。そして、運用時ログ採取個所情報において“１”を設定されたコンポーネント（図１１及び図１２ではｃ３，ｃ４，ｃ５）に使用情報出力コードが追加される。これにより、当該コンポーネントが使用されると当該コンポーネントについての運用ログを採取することが可能になる。この後、運用データ採取部４３０の運用情報取得部４３１によって、例えば、図１２の上段に示すような運用データ（運用ログ）が、運用時のリクエスト毎に取得される（手順Ｓ２１）。

図１２の上段に示す運用ログには、リクエスト毎に、ＵＲＬと、処理時刻と、応答時間（遅延／正常）と、当該リクエスト時に使用される不定コンポーネントに関する情報とが含まれる。なお、例えば、応答時間が所定閾値を超えた場合、当該応答時間に対応するリクエストは遅延と認識される一方、応答時間が所定閾値以下である場合、当該応答時間に対応するリクエストは正常と認識される。

具体的に、１番目のリクエストについては、“ＵＲＬ１”と処理時刻“timestampA”と応答時間“restime(遅延)”とが採取されたものとする。このとき、ＵＲＬ１について、コンポーネントｃ１，ｃ２，ｃ３，ｃ４が使用実行され遅延が生じた場合、これらのコンポーネントｃ１，ｃ２，ｃ３，ｃ４には、運用時ログ採取対象としてコンポーネントｃ３，ｃ４が含まれる。このため、検知部４３２によってコンポーネントｃ３，ｃ４の使用情報が検知される。しかし、ＵＲＬ１では、コンポーネントｃ３，ｃ４のうち、コンポーネントｃ４のみが不定コンポーネントであることが、パス情報に基づき認識される。したがって、コンポーネントｃ４のみが運用ログとして記録される。当該１番目のリクエストと同様、４番目のリクエストについては、“ＵＲＬ１”と処理時刻“timestampD”と応答時間“restime(遅延)”とコンポーネントｃ４とが運用ログとして記録される。

また、２番目のリクエストについては、“ＵＲＬ２”と処理時刻“timestampB”と応答時間“restime(正常)”とが採取されたものとする。このとき、ＵＲＬ２について、コンポーネントｃ１，ｃ２，ｃ３が正常に使用実行された場合、これらのコンポーネントｃ１，ｃ２，ｃ３には、運用時ログ採取対象としてコンポーネントｃ３が含まれる。このため、検知部４３２によってコンポーネントｃ３の使用情報が検知される。しかし、ＵＲＬ２においてコンポーネントｃ３は不定でないことが、パス情報に基づき認識される。したがって、コンポーネントｃ３は運用ログとして記録されない。当該２番目のリクエストと同様、３番目のリクエストについては、“ＵＲＬ２”と処理時刻“timestampC”と応答時間“restime(正常)”とが運用ログとして記録される。

問題個所特定部４６０は、事前分析で得られたパス情報（図１２の中段参照）を参照する。これにより、問題箇所特定部４６０は、分析対象となるＵＲＬ１及びＵＲＬ２のうちＵＲＬ１は、不定コンポーネントｃ３またはｃ４を使用している可能性があることを認識する（手順Ｓ２２）。

そこで、問題個所特定部４６０は、上述のごとく採取された運用ログ（図１２の上段参照）からＵＲＬ１を検索し、ＵＲＬ１についてコンポーネントｃ４を使用していることを示す使用情報を認識する（手順Ｓ２３）。そして、問題個所特定部４６０は、図１２の下段（遅延原因個所の特定処理時のデータ）に示すごとく、ＵＲＬ１の使用コンポーネントに不定コンポーネントｃ４を含めた上で、遅延原因個所の特定処理を実行する（手順Ｓ２４）。

これにより、運用時にコンポーネントｃ４とｃ５とのどちらが使用されたかを正しく認識することができ、遅延原因個所をコンポーネントｃ４とｃ５とのいずれか一方に絞り込むことができる。したがって、遅延原因個所を正確に特定することができる。

〔４−５〕本実施形態における各種処理の説明
まず、図１３に示すフローチャート（ステップＳ１０１，Ｓ１０２）に従って、本実施形態の使用情報出力コード（第１コード）の追加処理の一例について説明する。

不定コンポーネントが使用されると使用情報を出力する使用情報出力コードを追加する処理は、前述したように、検知部４３２もしくはパス分析部４２０によって行なわれる。当該処理は、例えば図１３に示すフローチャートに従って行なわれる。

つまり、まず、運用開始時に、運用時ログ採取個所が、運用時ログ採取個所情報ＤＢ４０５から読み出される（ステップＳ１０１）。読み出された運用時ログ採取個所は、ログ出力機構の設定テンプレート内に埋め込まれ、設定ファイルとして出力されることで、使用情報出力コードが追加される。

使用情報出力コードの追加については、汎用的なツール（例えばバイトコードインジェクションツール）が用意されているため、そのツールの設定ファイルを用意するだけで自動的に埋め込み処理を実行することができる。当該埋め込み処理は、事前分析フェーズ完了後（運用開始前）に一回のみ実行される。

ついで、図１４に示すフローチャート（ステップＳ１１１，Ｓ１１２）に従って、本実施形態におけるＡＰサーバ４０の運用時処理（運用時ログ出力部４１による処理）の一例について説明する。

運用フェーズにおいて、ＡＰサーバ４０は、リクエスト時に呼び出されたコンポーネントを、事前分析で得られたＤＢ４０４におけるパス情報と照らし合わせ、呼び出されたコンポーネントが不定コンポーネントであるか否かを認識する。呼び出されたコンポーネントが不定コンポーネントでない場合、ＡＰサーバ４０は、当該コンポーネントについての運用ログを記録しない。一方、呼び出されたコンポーネントが不定コンポーネントである場合、当該コンポーネントについての運用ログを、ＡＰサーバ４０のメモリ上に記録する（ステップＳ１１１）。

そして、リクエスト終了時に、ＡＰサーバ４０は、メモリ上に、不定コンポーネントについてのＵＲＬ（＋ＣＧＩパラメータ）と処理時刻（リクエスト時刻）と応答時間（リクエスト処理に要した時間）とが記録されているか否かを判断する。不定コンポーネントに係る情報が記録されていない場合、ＡＰサーバ４０は、運用データ採取部４３０に対し何ら出力しない。一方、不定コンポーネントに係る情報が記録されている場合、ＡＰサーバ４０は、当該不定コンポーネントについてのＵＲＬ，処理時刻，応答時間を含む当該不定コンポーネントに係る情報を、運用データ採取部４３０に対し運用データとして出力する（ステップＳ１１２）。

ついで、図１５に示すフローチャート（ステップＳ１２１〜Ｓ１２５）に従って、本実施形態における遅延原因個所の特定処理（問題個所特定部４６０による処理）の一例について説明する。

運用フェーズにおいて、ＡＰサーバ４０等から新しいリクエストについての運用データ（運用ログ）が採取されると、運用ブロック４０２の問題個所特定部４６０は、その運用ログを読み出す（ステップＳ１２１）。

そして、問題個所特定部４６０は、パス情報の決定コンポーネント（例えば図１２のＵＲＬ１のｃ１〜ｃ３）と運用データ上の不定コンポーネント（例えば図１２のＵＲＬ１のｃ４）とを、当該新しいリクエストのパスとして認識する（ステップＳ１２２）。問題個所特定部４６０は、認識したパスが遅延リクエストか否か（応答時間が所定閾値を超えているか否か）を判断する（ステップＳ１２３）。

認識したパスが遅延リクエストでない場合（ステップＳ１２３のＮＯルート）、問題個所特定部４６０は、ステップＳ１２１の処理に戻り、新しいリクエストについての運用データが採取されるのを待機する。一方、認識したパスが遅延リクエストである場合（ステップＳ１２３のＹＥＳルート）、問題個所特定部４６０は、図９や図１０や図１２を参照しながら前述した手順によって、読み出したリクエスト群を用い遅延原因個所の特定処理を実行する（ステップＳ１２４）。そして、問題個所特定部４６０は、特定処理によって得られた遅延原因個所を、ディスプレイ，プリンタ，各種記録媒体等によって出力する（ステップＳ１２５）。

なお、ここでは、機能選別部４４０やデータスライス分割部４５０による処理の説明は省略している。

〔５〕変形例
次に、図１６及び図１７を参照しながら、本実施形態の変形例について説明する。

〔５−１〕本実施形態の第１変形例
まず、図１６（Ａ）及び図１６（Ｂ）を参照しながら、本実施形態の第１変形例について説明する。

本実施形態において、例えば図１６（Ａ）に示すように、ｃ１，ｃ２，ｃ３が決定コンポーネントでありｃ４，ｃ５が不定コンポーネントであることが、事前分析時の情報として取得されたものとする（手順Ｓ１）。この場合、図９（Ａ）に示す例と同様、決定コンポーネントｃ１〜ｃ３には使用情報出力コードは追加されず、不定コンポーネントｃ４，ｃ５には使用情報出力コードが追加される（手順Ｓ２）。

一方、ネットワークシステムにおいては、運用時に、例えば図１６（Ｂ）に示すごとく事前分析時には使用しなかった未使用コンポーネントが使用されるといった想定外の挙動を示す場合があり得る。このような想定外の挙動は、例えば、事前分析に用いるリクエストパターンの網羅が足りなかった状況において生じる。

そこで、本実施形態の第１変形例では、事前分析時に、どのリクエストによっても使用されなかった未使用コンポーネント（例えば図１６（Ｂ）中のコンポーネントｃ６，ｃ７など）に対しても使用情報出力コードが追加される。これにより、上述のような想定外の挙動を示した場合（例えば図１６（Ｂ）において一点鎖線で示すような未知のパスを通った場合）にも、遅延原因個所の正確な特定が可能になる。ただし、このとき、全ての未使用コンポーネントに使用情報出力コードを追加するのではなく、ログ採取オーバーヘッドとのトレードオフを考慮して使用情報出力コードを追加すべき未使用コンポーネントを選択することが望ましい。

上述のように、未使用コンポーネントにも使用情報出力コードを追加すべく、第１変形例において、検知部４３２は、運用開始時に、パス情報を事前に取得する際に未使用コンポーネントに対して、上述した第１コードと同様の第２コード（使用情報出力コード）を追加する。当該第２コードも、第１コードと同様、未使用コンポーネントが運用時に使用されると第２使用検知情報（使用情報）を、当該未使用コンポーネントを使用したＡＰサーバ４０等に出力させる。

上述のような第２コードを用いることで、実運用中のＡＰサーバ４０において、使用情報出力コードを付されたコンポーネントが使用されると、ＡＰサーバ４０における運用時ログ出力部４１から、第２使用検知情報（使用情報）が検知部４３２に対して出力される。

そして、パス分析部４２０または運用データ採取部４３０における再構成部４２３は、運用時ログ出力部４１から第２使用検知情報（使用情報）が出力された場合、パス情報を、未使用コンポーネントを含むように再構成する。

これにより、問題個所特定部４６０は、運用時に問題（遅延）が生じた場合、再構成部４２３によって再構成されたパス情報と、運用情報と、第２使用検知情報とに基づき、未使用コンポーネントも考慮して、遅延原因個所（問題コンポーネント）を正確に特定することができる。

〔５−２〕本実施形態の第２変形例
ついで、図１７（Ａ）及び図１７（Ｂ）を参照しながら、本実施形態の第２変形例について説明する。

本実施形態の第２実施形態では、パス分析部４２０における不定コンポーネント抽出部４２２は、機能毎のパス情報と当該パス情報に含まれる一以上のコンポーネントとの関係について事前学習を行なう。そして、不定コンポーネント抽出部４２２は、当該事前学習の結果、同一の機能が使用する場合と使用しない場合とがあるコンポーネントを、不定コンポーネントとして抽出する。

このとき、事前分析時に、例えば図１７（Ａ）に示すように、ＵＲＬ１について、月〜金曜日のパスが、ＵＲＬ１について、決定コンポーネントｃ１，ｃ２，ｃ３の他に、コンポーネントｃ４も必ず使用することが学習された場合、第２変形例では以下のように動作する。つまり、運用時が月〜金曜日であれば、コンポーネントｃ４も決定コンポーネントとして取り扱われる。これにより、図１７（Ａ）に示すように、月〜金曜日のパスとしては、パス（ａ１）のみが用いられパス（ａ２）（コンポーネントｃ５）は用いられない。したがって、決定コンポーネントｃ１〜ｃ４には使用情報出力コードは追加されない。

また、事前分析時に、例えば図１７（Ｂ）に示すように、ＵＲＬ１について、土・日曜日のパスが、ＵＲＬ１について、決定コンポーネントｃ１，ｃ２，ｃ３の他に、コンポーネントｃ５も必ず使用することが学習された場合、上述した月〜金曜の場合と同様に動作する。つまり、運用時が土日であれば、コンポーネントｃ５も決定コンポーネントとして取り扱われる。これにより、図１７（Ｂ）に示すように、土日のパスとしては、パス（ａ２）のみが用いられパス（ａ１）（コンポーネントｃ４）は用いられない。したがって、決定コンポーネントｃ１〜ｃ３，ｃ５には使用情報出力コードは追加されない。

事前分析時に上述のような学習を行なった結果、依然として不定コンポーネントが存在する場合に、当該不定コンポーネントについて、使用情報出力コードが追加される。

ここで、曜日等に依ってパス上のコンポーネントを全て決定できる場合、使用情報出力コードを追加して不定コンポーネントのログを採らなくてもよい。これは、ＵＲＬ１のパスについては、曜日が分かればパスがコンポーネントｃ４とｃ５のどちらを通過したかを特定できるからである。したがって、上述したように、曜日等の分類（学習）を行なっても不定コンポーネントが存在する場合に、当該不定コンポーネントについて、使用情報出力コードを追加してログの採取が行なわれる。

なお、上述した第２実施形態では、曜日について学習する場合について説明したが、コンポーネントの時間帯や、リクエストパターンやデータベースの状況などについて学習してもよい。

〔６〕その他
以上、本発明の好ましい実施形態について詳述したが、本発明は、係る特定の実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲内において、種々の変形、変更して実施することができる。

例えば、運用時ログを出力するＡＰサーバ４０と、本実施形態に係る分析装置としての機能を実現する事前分析ブロック４０１及び運用ブロック４０２を含むサーバとは、異なる二つのハードウェア上に別々に備えられてもよいし、同一のハードウェア上に備えられてもよい。

〔７〕付記
以上の実施形態に関し、さらに以下の付記を開示する。

（付記１）
複数の機能のそれぞれが使用する一以上のコンポーネントに係る情報を含む事前に取得される前記機能毎のパス情報と、運用時に取得される運用情報と、に基づき、前記一以上のコンポーネントの中から問題コンポーネントを問題個所として特定する分析方法であって、
前記複数の機能のうちの同一の機能が使用する場合と使用しない場合とがあるコンポーネントを、不定コンポーネントとして事前に抽出し、
前記運用時に前記不定コンポーネントが使用されたかを検知し、
前記運用時に問題が生じた場合、前記パス情報と前記運用情報と前記不定コンポーネントの使用検知結果とに基づき、前記問題個所を特定する、分析方法。

（付記２）
前記同一の機能についての異なるパス情報を前記同一の機能についての一つのパス情報に統合し、
統合した前記一つのパス情報として、前記不定コンポーネントに係る情報を規定する、付記１に記載の分析方法。

（付記３）
前記同一の機能が常に使用するコンポーネントを決定コンポーネントとして認識し、
統合した前記一つのパス情報として、前記決定コンポーネントに係る情報を規定する、付記２に記載の分析方法。

（付記４）
運用開始時に、前記複数の機能のそれぞれについて取得された前記パス情報において規定される前記不定コンポーネントを、使用検知対象として認識し、
前記運用時に、前記使用検知対象として認識した前記不定コンポーネントが使用されたかを検知する、付記２または付記３に記載の分析方法。

（付記５）
前記運用開始時に、前記使用検知対象として認識した前記不定コンポーネントが前記運用時に使用されると第１使用検知情報を出力する第１コードを、前記不定コンポーネントに対して追加し、
前記第１使用検知情報を前記使用検知結果として用いる、付記４に記載の分析方法。

（付記６）
運用開始時に、前記パス情報を事前に取得する際に前記複数の機能がいずれも使用しなかった未使用コンポーネントに対して、前記未使用コンポーネントが前記運用時に使用されると第２使用検知情報を出力する第２コードを追加し、
前記第２使用検知情報が出力された場合、前記パス情報を、前記未使用コンポーネントを含むように再構成する、付記１〜付記５のいずれか一項に記載の分析方法。

（付記７）
前記機能毎のパス情報と当該パス情報に含まれる前記一以上のコンポーネントとの関係について事前学習を行ない、
当該事前学習の結果、前記同一の機能が使用する場合と使用しない場合とがあるコンポーネントを、前記不定コンポーネントとして抽出する、付記１〜付記６のいずれか一項に記載の分析方法。

（付記８）
複数の機能のそれぞれが使用する一以上のコンポーネントに係る情報を含む前記機能毎のパス情報を、事前に取得するパス情報取得部と、
前記複数の機能のうちの同一の機能が使用する場合と使用しない場合とがあるコンポーネントを、不定コンポーネントとして事前に抽出する不定コンポーネント抽出部と、
運用時に運用情報を取得する運用情報取得部と、
前記運用時に前記不定コンポーネントが使用されたかを検知する検知部と、
前記運用時に問題が生じた場合、前記パス情報と前記運用情報と前記不定コンポーネントの使用検知結果とに基づき、前記一以上のコンポーネントの中から問題コンポーネントを問題個所として特定する特定部と、を備えた、分析装置。

（付記９）
前記パス情報取得部は、
前記同一の機能についての異なるパス情報を前記同一の機能についての一つのパス情報に統合し、
統合した前記一つのパス情報として、前記不定コンポーネントに係る情報を規定する、付記８に記載の分析装置。

（付記１０）
前記パス情報取得部は、
前記同一の機能が常に使用するコンポーネントを決定コンポーネントとして認識し、
統合した前記一つのパス情報として、前記決定コンポーネントに係る情報を規定する、付記９に記載の分析装置。

（付記１１）
前記検知部は、
運用開始時に、前記複数の機能のそれぞれについて取得された前記パス情報において規定される前記不定コンポーネントを、使用検知対象として認識し、
前記運用時に、前記使用検知対象として認識した前記不定コンポーネントが使用されたかを検知する、付記９または付記１０に記載の分析装置。

（付記１２）
前記検知部は、前記運用開始時に、前記使用検知対象として認識した前記不定コンポーネントが前記運用時に使用されると第１使用検知情報を出力する第１コードを、前記不定コンポーネントに対して追加し、
前記特定部は、前記第１使用検知情報を前記使用検知結果として用いる、付記１１に記載の分析装置。

（付記１３）
前記検知部は、運用開始時に、前記パス情報を事前に取得する際に前記複数の機能がいずれも使用しなかった未使用コンポーネントに対して、前記未使用コンポーネントが前記運用時に使用されると第２使用検知情報を出力する第２コードを追加し、
前記第２使用検知情報が出力された場合、前記パス情報を、前記未使用コンポーネントを含むように再構成する再構成部を備える、付記８〜付記１２に記載の分析装置。

（付記１４）
前記不定コンポーネント抽出部は、
前記機能毎のパス情報と当該パス情報に含まれる前記一以上のコンポーネントとの関係について事前学習を行ない、
当該事前学習の結果、前記同一の機能が使用する場合と使用しない場合とがあるコンポーネントを、前記不定コンポーネントとして抽出する、付記８〜付記１３のいずれか一項に記載の分析装置。

（付記１５）
複数の機能のそれぞれが使用する一以上のコンポーネントに係る情報を含む事前に取得される前記機能毎のパス情報と、運用時に取得される運用情報と、に基づき、前記一以上のコンポーネントの中から問題コンポーネントを問題個所として特定するコンピュータに、
前記複数の機能のうちの同一の機能が使用する場合と使用しない場合とがあるコンポーネントを、不定コンポーネントとして事前に抽出し、
前記運用時に前記不定コンポーネントが使用されたかを検知し、
前記運用時に問題が生じた場合、前記パス情報と前記運用情報と前記不定コンポーネントの使用検知結果とに基づき、前記問題個所を特定する、
処理を実行させる、分析プログラム。

（付記１６）
前記同一の機能についての異なるパス情報を前記同一の機能についての一つのパス情報に統合し、
統合した前記一つのパス情報として、前記不定コンポーネントに係る情報を規定する、
処理を、前記コンピュータに実行させる、付記１５に記載の分析プログラム。

（付記１７）
前記同一の機能が常に使用するコンポーネントを決定コンポーネントとして認識し、
統合した前記一つの機能の前記パス情報として、前記決定コンポーネントに係る情報を規定する、
処理を、前記コンピュータに実行させる、付記１６に記載の分析プログラム。

（付記１８）
運用開始時に、前記複数の機能のそれぞれについて取得された前記パス情報において規定される前記不定コンポーネントを、使用検知対象として認識し、
前記運用時に、前記使用検知対象として認識した前記不定コンポーネントが使用されたかを検知する、
処理を、前記コンピュータに実行させる、付記１６または付記１７に記載の分析プログラム。

（付記１９）
前記運用開始時に、前記使用検知対象として認識した前記不定コンポーネントが前記運用時に使用されると第１使用検知情報を出力する第１コードを、前記不定コンポーネントに対して追加し、
前記第１使用検知情報を前記使用検知結果として用いる、
処理を、前記コンピュータに実行させる、付記１８に記載の分析プログラム。

（付記２０）
運用開始時に、前記パス情報を事前に取得する際に前記複数の機能がいずれも使用しなかった未使用コンポーネントに対して、前記未使用コンポーネントが前記運用時に使用されると第２使用検知情報を出力する第２コードを追加し、
前記第２使用検知情報が出力された場合、前記パス情報を、前記未使用コンポーネントを含むように再構成する、
処理を、前記コンピュータに実行させる、付記１５〜付記１９のいずれか一項に記載の分析プログラム。

１０ ネットワーク
２０ サーバ
３０ Ｗｅｂサーバ
４０ ＡＰ（アプリケーション）サーバ（分析装置，コンピュータ）
４１ 運用時ログ出力部（検知部）
５０ ネットワークスイッチ（ＮＳ）
４０１ 事前分析ブロック（分析装置）
４０２ 運用ブロック（分析装置）
４０３ ユーザリクエストデータベース（分析装置）
４０４ パス情報データベース（分析装置）
４０５ 運用時ログ採取個所情報データベース（検知部，分析装置）
４１０ 事前データ採取部
４２０ パス分析部
４２１ パス情報取得部
４２２ 不定コンポーネント抽出部
４２３ 再構成部
４３０ 運用データ採取部
４３１ 運用情報取得部
４３２ 検知部
４４０ 機能選別部
４５０ データスライス分割部
４６０ 問題個所特定部（特定部）
Ｆ１，Ｆ２，Ｆ３，Ｆ４，Ｆｉ 機能（処理）
ｃ１，ｃ２，ｃ３，ｃ４，ｃ５ コンポーネント（モジュール，メソッド，チェックポイント）

Claims (9)

1. コンピュータが、複数の機能のそれぞれが使用する一以上のコンポーネントに係る情報を含む事前に取得される前記機能毎のパス情報と、運用時に取得される運用情報と、に基づき、前記一以上のコンポーネントの中から問題コンポーネントを問題個所として特定する分析方法であって、
   前記コンピュータは、
   前記複数の機能のうちの同一の機能が使用する場合と使用しない場合とがあるコンポーネントを、不定コンポーネントとして事前に抽出し、
   前記運用時に前記不定コンポーネントが使用されたかを検知し、
   前記運用時に問題が生じた場合、前記パス情報と前記運用情報と前記不定コンポーネントの使用検知結果とに基づき、前記問題個所を特定する、分析方法。
2. 前記コンピュータは、
   前記同一の機能についての異なるパス情報を前記同一の機能についての一つのパス情報に統合し、
   統合した前記一つのパス情報として、前記不定コンポーネントに係る情報を規定する、請求項１に記載の分析方法。
3. 前記コンピュータは、
   前記同一の機能が常に使用するコンポーネントを決定コンポーネントとして認識し、
   統合した前記一つのパス情報として、前記決定コンポーネントに係る情報を規定する、請求項２に記載の分析方法。
4. 前記コンピュータは、
   運用開始時に、前記複数の機能のそれぞれについて取得された前記パス情報において規定される前記不定コンポーネントを、使用検知対象として認識し、
   前記運用時に、前記使用検知対象として認識した前記不定コンポーネントが使用されたかを検知する、請求項２または請求項３に記載の分析方法。
5. 前記コンピュータは、
   前記運用開始時に、前記使用検知対象として認識した前記不定コンポーネントが前記運用時に使用されると第１使用検知情報を出力する第１コードを、前記不定コンポーネントに対して追加し、
   前記第１使用検知情報を前記使用検知結果として用いる、請求項４に記載の分析方法。
6. 前記コンピュータは、
   運用開始時に、前記パス情報を事前に取得する際に前記複数の機能がいずれも使用しなかった未使用コンポーネントに対して、前記未使用コンポーネントが前記運用時に使用されると第２使用検知情報を出力する第２コードを追加し、
   前記第２使用検知情報が出力された場合、前記パス情報を、前記未使用コンポーネントを含むように再構成する、請求項１〜請求項５のいずれか一項に記載の分析方法。
7. 前記コンピュータは、
   前記機能毎のパス情報と当該パス情報に含まれる前記一以上のコンポーネントとの関係を分析し、
   当該分析の結果、前記同一の機能が使用する場合と使用しない場合とがあるコンポーネントを、前記不定コンポーネントとして抽出し、前記関係を運用ログとして蓄積する、請求項１〜請求項６のいずれか一項に記載の分析方法。
8. 複数の機能のそれぞれが使用する一以上のコンポーネントに係る情報を含む前記機能毎のパス情報を、事前に取得するパス情報取得部と、
   前記複数の機能のうちの同一の機能が使用する場合と使用しない場合とがあるコンポーネントを、不定コンポーネントとして事前に抽出する不定コンポーネント抽出部と、
   運用時に運用情報を取得する運用情報取得部と、
   前記運用時に前記不定コンポーネントが使用されたかを検知する検知部と、
   前記運用時に問題が生じた場合、前記パス情報と前記運用情報と前記不定コンポーネントの使用検知結果とに基づき、前記一以上のコンポーネントの中から問題コンポーネントを問題個所として特定する特定部と、を備えた、分析装置。
9. 複数の機能のそれぞれが使用する一以上のコンポーネントに係る情報を含む事前に取得される前記機能毎のパス情報と、運用時に取得される運用情報と、に基づき、前記一以上のコンポーネントの中から問題コンポーネントを問題個所として特定するコンピュータに、
   前記複数の機能のうちの同一の機能が使用する場合と使用しない場合とがあるコンポーネントを、不定コンポーネントとして事前に抽出し、
   前記運用時に前記不定コンポーネントが使用されたかを検知し、
   前記運用時に問題が生じた場合、前記パス情報と前記運用情報と前記不定コンポーネントの使用検知結果とに基づき、前記問題個所を特定する、
   処理を実行させる、分析プログラム。

Images