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

Description

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

所定の複数の処理を含む複数のサービス、例えばアプリケーションプログラムやネットワークサービス等において、遅延等の異常が発生している処理を特定することが試みられている。例えば、サービス（応答）の遅延が発生した場合に、各処理が出力するログを解析することで、実際に運用している状況下で、異常個所（問題個所）を検出し、原因を突き止める方法がある。

なお、異常個所とは、Ｗｅｂリクエスト等で、システムを構成する装置やネットワーク等における遅延等の異常が発生している部分（処理，コンポーネント）である。例えば異常個所としては、システムを構成するネットワーク，ＲＤＢ（Relational Database），アプリケーション等のうちの、ネットワークの遅延区間，ＲＤＢの遅延原因のＤＢやテーブル，アプリケーションの遅延原因のメソッド等が挙げられる。

一例として、監視装置によりサービスの各処理の前後のログを採取して状態を監視し続けることで、サービスの異常個所を発見することが可能である。例えばstart−Ａ−Ｂ−Ｃ−Ｄ−endという処理シーケンスの場合、Ａの直前、Ａ−Ｂの中間、Ｂ−Ｃの中間、Ｃ−Ｄの中間、Ｄの直後、でタイムスタンプが付いたログを採取することで、Ａ〜Ｄの各処理の遅延を見つけることができる。例えばＢが遅延している場合、Ｂの直前（Ａ−Ｂ間）のログとＢの直後（Ｂ−Ｃ間）のログとを参照することで、処理Ｂを異常個所（異常処理）として特定することができる。

特開２００７−２６４７３４号公報 国際公開第２００８／１２９６３５号パンフレット 特開２０１３−０９７７８３号公報

異常個所の分析・検出を行なう分析装置は、予め各サービスが実行する処理（コンポーネント）を記憶しておき、遅延が発生したときに実行されている複数のサービスから、遅延に影響を与えている可能性の高い処理を検出することも考えられる。

しかし、各サービスにおいて異常個所を検出するためには、監視装置は多数の監視個所で大量のログを採取することになる。このため、異常個所の絞り込み、特定には多大な実行オーバーヘッド及びネットワーク負荷が発生する。このように、各処理が出力するログの採取及び解析は、ネットワークの負荷増大等を伴うため、サービスに含まれる処理が多くなるにつれて、検出に時間がかかるとともに、システムのサービス提供に影響を与える場合がある。

また、監視装置は、各サービスが実行する処理を所定の単位でまとめることによって、検出の工数を削減することも考えられるが、処理をまとめる単位によっては、異常となる処理が隠れてしまい、異常個所を検出できない可能性もある。

１つの側面では、本発明は、少ない判断処理で異常処理の検出を可能とすることを目的とする。

なお、前記目的に限らず、後述する発明を実施するための形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本発明の他の目的の１つとして位置付けることができる。

分析方法の一態様は、複数の階層を持つモジュールを複数含む複数のサービスについて、前記の各サービスを構成するモジュールについて、前記の各モジュールの下位階層の処理単位が共通するモジュールをグルーピングしたコンポーネント定義情報と、サービスがどのグルーピングされたモジュールによって構成されているかを示すパス情報とをサービス情報として記憶する。また、前記複数のサービスに関するログデータ及び前記サービス情報に基づき、一以上のサービスに含まれるモジュールについて、異常の有無を判断する第１の判断処理を行なう。さらに、異常と判断されたモジュールがグルーピングされたグルーピングモジュールである場合、前記サービス情報に基づき、前記異常と判断されたグルーピングモジュールを前記グルーピングモジュールのトップレベルよりも下位の処理単位に展開して、展開した各モジュールのうち、異常であるモジュールが含み正常であるモジュールが含まない処理単位を異常と判断する第２の判断処理を行なう。
分析方法の他の態様は、複数の階層を持つモジュールを複数含む複数のサービスについて、前記の各サービスを構成するモジュールについて、前記の各モジュールの下位階層の処理単位が共通するモジュールを少なくとも１つ共通するモジュールとして相互に含む複数のグルーピングモジュールを定義するコンポーネント定義情報と、サービスがどのグルーピングされたモジュールによって構成されているかを示すパス情報とをサービス情報として記憶する。また、前記複数のサービスに関するログデータ及び前記サービス情報に基づき、一以上のサービスに含まれるモジュールについて、異常の有無を判断する第１の判断処理を行なう。さらに、異常と判断されたモジュールがグルーピングされたグルーピングモジュールである場合、前記サービス情報に基づき、前記異常と判断されたグルーピングモジュールを含む複数のグルーピングモジュールについて、異常であるグルーピングモジュールが含み正常であるグルーピングモジュールが含まないモジュールを異常と判断する第２の判断処理を行なう。

一態様によれば、少ない判断処理で異常処理を検出することが可能になる。

一実施形態に係るネットワークシステムの一例を示すブロック図である。 サービス（パス）とコンポーネントとの対応関係（パス情報）の一例を示す図である。 （Ａ）〜（Ｄ）は一実施形態に係る機能とコンポーネントとの関係をマトリクスで表現した例を示す図である。 本実施形態の事前分析フェーズの分析装置のハードウェア構成及び機能構成を示すブロック図である。 本実施形態に係る詳細ログの一例を示す図である。 本実施形態に係る紐付け結果の一例を示す図である。 本実施形態に係るｃｉｄ対応表の一例を示す図である。 本実施形態に係るｃｉｄセット表の一例を示す図である。 本実施形態に係るｐｉｄ対応表の一例を示す図である。 本実施形態に係るパス情報の一例を示す図である。 本実施形態に係るコンポーネント定義情報の一例を示す図である。 本実施形態の運用フェーズの分析装置のハードウェア構成及び機能構成を示すブロック図である。 本実施形態に係るアクセスログの一例を示す図である。 本実施形態に係る機能ごとの集計区間に正常と異常なデータとが混在する様子を模式的に示す図である。 図１４において正常区間と異常区間とを分離して、重なりで判定する様子を模式的に説明する図である。 本実施形態に係る運用フェーズの分析結果の通知画面例を示す図である。 本実施形態に係る事前分析フェーズの分析装置の動作例を説明するフローチャートである。 本実施形態に係る構成要素抽出処理の手順を説明するフローチャートである。 本実施形態に係る構成要素抽出処理を具体的に説明する図である。 本実施形態に係るサービス情報生成処理の手順を説明するフローチャートである。 本実施形態に係るサービス情報生成処理を具体的に説明する図である。 本実施形態に係る運用フェーズの分析装置の動作例を説明するフローチャートである。 本実施形態に係る分析処理の手順を説明するフローチャートである。 本実施形態に係る分析処理を具体的に説明する図である。 一実施形態に係る分析処理の適用事例を説明する図である。 第１変形例に係る粒度レベルの設定例を説明する図である。

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

〔１〕本実施形態の構成
図１〜図１６を参照しながら、本実施形態の構成について説明する。

〔１−１〕本実施形態に係るネットワークシステムの構成
図１は、一実施形態に係るネットワークシステム１の一例を示すブロック図である。図１に示すネットワークシステム１は、例示的に、インターネット等のネットワーク１０、ネットワーク１０に接続されたサーバ群２０，３０及び４０、ネットワークスイッチ５０、並びに、分析装置１００及び２００等をそなえる。サーバ群２０，３０及び４０には、例示的に、Ｗｅｂサーバ３０や、アプリケーション（ＡＰ）サーバ４０、その他のサーバ２０等が含まれる。なお、サーバ群２０，３０及び４０としては、ＰＣ（Personal Computer）やサーバ等の情報処理装置が挙げられる。

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

ところで、図１に示すように、ネットワークシステム１は、事前分析フェーズ１Ａにおいては分析装置１００を含み、運用フェーズ１Ｂにおいては分析装置２００を含む。

分析装置１００は、事前分析フェーズ１Ａにおいて、後述するサービス情報を生成する。また、分析装置２００は、運用フェーズ１Ｂにおいて、分析装置１００によって事前に生成されたサービス情報に基づき異常個所を特定する。つまり、分析装置１００は、運用フェーズ１Ｂの構成と同様の条件で、分析装置２００が分析を行なう前にサービス情報を生成しておくのである。なお、本実施形態において、異常個所とは、例えばシステムを構成する装置やネットワーク等における遅延等の異常が発生している部分（処理，コンポーネント）である。

このように、事前分析フェーズ１Ａは、運用フェーズ１Ｂで使用されるネットワーク１０，サーバ群２０，３０及び４０，並びにネットワークスイッチ５０等の構成を再現していることが好ましい。換言すれば、事前分析フェーズ１Ａの構成は、運用フェーズ１Ｂの構成と共通（完全同一）のものでなくてもよく、例えば運用フェーズ１Ｂのステージング環境等、運用フェーズ１Ｂとは異なるハードウェアをそなえた構成であってもよい。或いは、事前分析フェーズ１Ａ及び運用フェーズ１Ｂの少なくとも一方がＶＭ（Virtual Machine）であってもよい。

なお、分析装置１００及び２００としての機能は、それぞれ、ＡＰサーバ４０等によって実現されることができ、また、ネットワークシステム１に含まれる他のＰＣやサーバ等の情報処理装置によって実現されてもよい。さらに、分析装置１００及び２００としての機能は、１台のＡＰサーバ４０又は１台の情報処理装置等によって実現されてもよい。

本実施形態に係る分析装置１００及び２００の動作について、簡単に説明する。

まず、分析装置１００は、分析装置２００において運用時に余分なオーバヘッドやネットワーク負荷を発生させることなく異常個所を特定するために、事前に詳細なログを採取分析してサービスごとのサービス情報を生成する。このとき、分析装置１００は、予めキャプチャ済みの実データやテストデータを再現（リプレイ）するなどして採取したデータを用いて、システムの各サービスのパスを分類する。

例えば図２に示すごとくｐ１〜ｐ５をネットワークコンポーネントとした場合、分析装置１００は、各コンポーネントｐ１〜ｐ５を流れるメッセージデータ（ログ）を分析する。そして、分析装置１００は、例えばネットワーク上のリソースを示すＵＲＬ（Uniform Resource Locator）＋ＣＧＩ（Common Gateway Interface）パラメータでパスを分類する。

すると、各サービス（ＵＲＬｉ（ｉは自然数））は次のようなパスを通ることが分かる。

URL1=p1-p2 -p4-p5
URL2=p1 -p3 -p5
URL3=p1-p2
URL4= p3-p4

なお、コンポーネントｐｊ（ｊは自然数）は分析装置１００及び２００が分析を行なう単位である。以下、「コンポーネント」を、「処理」という場合がある。また、「サービス」を「機能」或いは「ＵＲＬ」という場合がある。なお、「パス」は、「コンポーネント」の集合として位置付けられる。ここで、ＵＲＬｉは、ユーザにより呼び出されたコンポーネントの組み合わせ、つまりサービスを特定するための識別子であり、一般的なインターネット上のリソースを特定するための識別子に限定する意図はない。

分析装置１００は、上述した分類により、サービス情報の一例としてのパス情報及びコンポーネント定義情報を生成することができる。なお、パス情報は、各ＵＲＬｉと複数のコンポーネントｐｊとの対応関係を示す情報、つまり各サービスＵＲＬｉに含まれるコンポーネントｐｊの組み合わせを示す情報（使用されるコンポーネントｐｊを特定する情報）である。また、コンポーネント定義情報は、コンポーネントｐｊの詳細情報、例えばコンポーネントの呼出名や、コンポーネントがまとめられている場合の詳細なコンポーネントの情報である。

ここで、通常時に比べてＵＲＬ１及びＵＲＬ２が遅延した場合、分析装置２００は、分析装置１００が上述の如く分析したサービス情報に照らすことで、ＵＲＬ１とＵＲＬ２とが通過するコンポーネントを推定することができる。図２の例では、分析装置２００は、全てのコンポーネントｐ１，ｐ２，ｐ３，ｐ４及びｐ５が異常の可能性を持つと判断することができる。

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

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

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

なお、コンポーネントｐｊは、一般的なＵＲＬの要素としてのuid（ユーザＩＤ）等のＩＤ単位であってもよく、サーバ群２０，３０，４０、ネットワーク装置、装置間のネットワーク等の装置・ネットワーク単位であってもよい。

パス情報は、単純な例としては図３（Ａ）に示すようにＵＲＬ１〜ＵＲＬ４（サービス）とコンポーネントｐ１〜ｐ５とをマトリクスで表現することができる。

図３（Ｂ）に例示するように、分析装置２００は、悪化したサービス（図２の例でＵＲＬ１及びＵＲＬ２）のコンポーネントを論理和（ＯＲ）で検出する。次いで、図３（Ｃ）に例示するように、分析装置２００は、悪化していないサービス（図２の例でＵＲＬ３及びＵＲＬ４）のコンポーネントをＯＲで検出する。

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

〔１−２〕対比例
ここで、本実施形態に係る分析装置１００及び２００の対比例について説明する。

アプリケーションプログラムやネットワークコンポーネント等のサービスで異常個所を見つけるためには、事前に用意したパス情報やコンポーネント定義情報と、運用時に得られる運用情報とを用いて、原因コンポーネントを推定することが考えられる。

例えば、事前の分析により、以下の（方式１）又は（方式２）の手法でコンポーネントの粒度を決定し、コンポーネントを定義する事が考えられる。なお、粒度とは、コンポーネントの粒の大きさであり、コンポーネントをどの程度の詳細度で絞り込んで結果を通知するか、という処理単位である。処理単位が粗すぎると問題の切り分けが不十分になり、細かすぎると分析処理に時間と大量のリソースを消費することになる。

（方式１）一律にレベルを決めてコンポーネント化する手法
ユーザから呼び出されたサービスに含まれる最細粒度のモジュール（処理）として、以下の４つがある場合を考える。ただし、下記の各行はモジュール（処理）の呼出名である。また、例えば１行目において、“com.lang.Java.”はパッケージ、“Foo1”はクラス、“#Meth1”はメソッドである。これら各行のモジュールは、例えば上述したメソッド（関数）呼出し単位であり、ＡＰサーバ４０等のアプリケーションにより実行される処理である。

com.lang.Java.Foo1#Meth1
com.lang.Java.Foo2#Meth2
com.user.Pkg#Meth1
com.user.Pkg#Meth2

上記のクラス，メソッドがある場合、例えばｌｅｖｅｌ＝３でコンポーネントを自動定義するなら、つまり、各サービスにおいて、最上位の要素（例えば左端の“com”）から３つまでの要素を一括りのコンポーネントとしてまとめるなら、
p1=com.lang.Java
p2=com.user.Pkg
となる。

また、例えばｌｅｖｅｌ＝４でコンポーネントを自動定義するなら、
p1=com.lang.Java.Foo1
p2=com.lang.Java.Foo2
p3=com.user.Pkg#Meth1
p4=com.user.Pkg#Meth2
となる。

（方式２）要素数を決めてコンポーネント化する手法
ユーザから呼び出されたサービスに含まれるモジュールとして、以下の複数のモジュールがある場合を考える。ただし、以下の例では、パッケージ．クラス“com.lang.Java.Foo1”のメソッド“#Meth2”〜“#Meth22”を省略して“...”で表している。

com.lang.Java.Foo1#Meth1
...
com.lang.Java.Foo1#Meth23
com.lang.Java.Foo2#Meth1
com.lang.Java.Foo2#Meth2
com.user.Pkg#Meth1
com.user.Pkg#Meth2
com.user.Pkg#Meth3

上記のクラス，メソッドがある場合、例えば末端部の要素数＞３でコンポーネントを自動定義するなら、つまり要素数＞３の場合にコンポーネントとしてまとめるなら、
p1=com.lang.Java.Foo1（“#Meth1”〜“#Meth23”がまとめられた）
p2=com.lang.Java.Foo2#Meth1
p3=com.lang.Java.Foo2#Meth2
p4=com.user.Pkg#Meth1
p5=com.user.Pkg#Meth2
p6=com.user.Pkg#Meth3
となる。

また、例えば末端部の要素数＞２でコンポーネントを自動定義するなら、
p1=com.lang.Java.Foo1（“#Meth1”〜“#Meth23”がまとめられた）
p2=com.lang.Java.Foo2#Meth1
p3=com.lang.Java.Foo2#Meth2
p4=com.user.Pkg（“#Meth1”〜“#Meth3”がまとめられた）
となる。

このように、上記（方式１）又は（方式２）の手法により、分析装置は、閾値としてのレベル又は要素数を変化させることで、コンポーネントを定義する粒度を調整することができる。そして、分析装置は、パス情報及び上述のように定義したコンポーネント定義情報と、運用時に得られる運用情報（例えばログデータ）とを用いて、異常個所のコンポーネントを推定することができる。

しかしながら、上述した（方式１）及び（方式２）において、適切な粒度を決定することは難しい。

例えば、コンポーネントを粗い粒度とした場合（（方式１）や（方式２）において閾値となるレベルや要素数が小さい場合）、分析装置は、運用フェーズにおいて分析の絞り込みを間違うことがある。

例示的に、コンポーネント定義により、以下のサービスのコンポーネントが定義されているものとする。

URL1=p1-p2-p3（p31-p32-p33）
URL2=p1 -p3（p31 -p33）

なお、上記の例で、ＵＲＬ１におけるコンポーネントｐ３は、上記（方式１）又は（方式２）の手法により末尾の括弧内のコンポーネントｐ３１，ｐ３２及びｐ３３がまとめられたものである。同様に、ＵＲＬ２におけるコンポーネントｐ３は、末尾の括弧内のコンポーネントｐ３１及びｐ３３がまとめられたものである。つまり、括弧内はより細かい粒度の場合のパス情報を示す。以下、このような階層的なコンポーネントは、上位の階層のコンポーネントの末尾の括弧を付し、括弧内に下位の階層のコンポーネントを表記して示す。

ここで、ｐ３２のコンポーネントが遅延原因の場合、以下のようにｐ３２を含むＵＲＬ１は遅延し、ｐ３２を含まないＵＲＬ２は遅延しない。

×URL1=p1-p2-p3
○URL2=p1 -p3

これを分析装置によって分析すると、異常個所として、遅延したパスにのみ含まれるコンポーネントｐ２が抽出される。実際にはｐ３２が遅延原因であるが、上記（方式１）又は（方式２）の手法によりｐ３１〜ｐ３３は（ｐ３２の有無によらず）ｐ３としてまとめられたため、このような誤った分析結果になる。

さらに、上記の例において、
○URL3=p1-p2
というサービス情報がある場合には、ＵＲＬ３はｐ２を含むパスであるのに遅延していないため、分析装置によりｐ２が異常個所ではないと判断され、異常個所として何も抽出されない。

一方、例えば、コンポーネントを細かい粒度とした場合（（方式１）（方式２）において閾値となるレベルや要素数が大きい場合）、運用フェーズにおいて分析装置の処理の負荷が高くなる。すなわち、上述したような粗い粒度における異常個所の誤検出を避けるためには、分析装置は、ｐ１，ｐ２及びｐ３等を全てより細かい粒度としたサービス情報を生成し、分析を行なうことが考えられる。

しかし、細粒度の分析は、大量のメモリ量を消費し分析にも時間がかかるため、運用中のリアルタイムの分析には適さない。また、より細かい粒度としてどこまで細くすればよいか（閾値となるレベルや要素数をどう設定すればよいか）を判断することは難しい。

例示的に、ＵＲＬ数が以下のように１０通りあり、各ＵＲＬが１０コンポーネントを通る粗い粒度とした場合、
URL1=p1-p2-p3-p4-p5-p6-p7-p8-p9-p10
URL2=p2-p3-p4-p5-p6-p7-p8-p9-p10-p11
URL10=...
分析装置による分析の際の演算は、
ＵＲＬ１０通り×コンポーネント１０通り＝１００通り
となる。

さらに細粒度にし、以下のように各コンポーネントが１００コンポーネントに展開された場合、
p1=p1.1-p1.2-p1.3...-p1.100
p2=p2.1-p2.2...-p2.100
各ＵＲＬは以下のようになる。

URL1=p1.1-p1.2...-p1.100-p2.1-p2.2...-p2.100...-p10.100
URL2= ...

そして、この場合の分析装置による分析の際の演算は、
ＵＲＬ１０通り×コンポーネント１００通り＝１０００通り
となる。

このように、（方式１）又は（方式２）を用いた解析手法で最適な粒度を定義することは難しく、最適な粒度で分析しなかった結果、間違った分析結果になることもある。

〔１−３〕本実施形態に係る分析装置の構成
これに対し、本実施形態に係る分析装置１００及び２００は、それぞれ事前分析フェーズ１Ａ及び運用フェーズ１Ｂにおいて後述する処理を実行することで、少ない判断処理で異常モジュール（遅延コンポーネント，異常処理）の検出を可能とすることができる。

以下、図４〜図１６を参照しながら、本実施形態に係る分析装置１００及び２００の構成について説明する。

〔１−３−１〕事前分析フェーズの分析装置の構成
はじめに、図４を参照しながら、事前分析フェーズ１Ａの分析装置１００の構成について説明する。図４は、本実施形態の事前分析フェーズ１Ａの分析装置１００のハードウェア構成及び機能構成を示すブロック図である。分析装置１００は、上述したように、ＡＰサーバ４０等、又は、サーバ群２０，３０，４０とは別体の情報処理装置にそなえられることができる。本実施形態において、分析装置１００は、サーバ群２０，３０，４０とは別体の情報処理装置にそなえられているものとする。

分析装置１００は、例示的に、ＣＰＵ，ＭＰＵ（Micro-Processing Unit），コンピュータ等の処理部１１０と、ＲＡＭ，ＨＤＤ等の記憶部１２０とをそなえる。

処理部１１０は、例示的に、ログ採取部１１１，ログ加工部１１２，機能抽出部１１３，サービス情報生成部１１４をそなえる。処理部１１０は、記憶部１２０から所定のアプリケーションプログラム（分析プログラム）を読み出して実行することで、これらの機能を実現することができる。また、記憶部１２０は、上記分析プログラムを保存するほか、処理部１１０による事前分析処理に用いられる各種情報を保存することができる。記憶部１２０は、当該各種情報として、例えば、詳細ログ１２１，紐付け結果１２２，ｃｉｄ対応表１２３，ｃｉｄセット表１２４，ｐｉｄ対応表１２５，パス情報１２６，及びコンポーネント定義情報１２７を保存することができる。

上記分析プログラムは、コンピュータ読取可能な記録媒体に記録された形態で提供されてもよい。この場合、処理部１１０は、読出装置等のインタフェースを介して当該記録媒体からプログラムを読み取り、内部記憶装置または外部記憶装置に転送及び格納して、当該プログラムを実行することができる。

なお、記録媒体としては、例えばフレキシブルディスク、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ブルーレイディスク等の光ディスクや、ＵＳＢ（Universal Serial Bus）メモリやＳＤカード等のフラッシュメモリが挙げられる。ＣＤとしては、ＣＤ−ＲＯＭ、ＣＤ−Ｒ（CD-Recordable）、ＣＤ−ＲＷ（CD-Rewritable）等が挙げられる。また、ＤＶＤとしては、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ＋Ｒ、ＤＶＤ＋ＲＷ等が挙げられる。

次いで、処理部１１０によって実現される、ログ採取部１１１，ログ加工部１１２，機能抽出部１１３，サービス情報生成部１１４としての機能について、図５〜図１１を参照しながら説明する。

ログ採取部１１１は、ユーザリクエストのデータ（リクエスト等）を仮想ユーザのデータとしてネットワーク１０（図４において図示省略）に投入（発行）する。なお、ログ採取部１１１により発行されるリクエストは、予め用意したテストシナリオに基づくリクエストであってもよい。或いは、ログ採取部１１１は、運用フェーズ１Ｂでの実際のリクエスト及び状態をパケットキャプチャ等により保存しておき、実運用時の運用状態を再現してもよい。

ネットワーク１０を介してリクエストを受けたＡＰサーバ４０では、当該リクエストに応じた処理が、アプリケーション４１によって実行され、当該リクエストに対応するリクエストログが、ログ出力部４２から分析装置１００へ出力される。なお、事前分析フェーズ１Ａにおいては、他のサーバ２０やＷｅｂサーバ３０からも同様にしてリクエストログがログ出力部４２から分析装置１００へ出力される。

ログ採取部１１１は、ＡＰサーバ４０等のログ出力部４２から図５に例示する詳細ログ１２１を採取して、記憶部１２０に保存する。

図５は、本実施形態に係る詳細ログ１２１の一例を示す図である。詳細ログ１２１は、ログ出力部４２によって出力されるログ（リクエストログ）の一例である。詳細ログ１２１には、例示的に、時刻（例えば図５の１行目の“timestamp1”），トランザクションＩＤ（ｔｉｄ；例えば図５の１行目の“tid1”）、値（呼出名；例えば図５の１行目の“com.lang.Java.Foo1#Meth1”）等が含まれる。なお、詳細ログ１２１において、ｔｉｄが共通のログは、１つのトランザクションすなわちサービスで実行されたモジュール（処理）のログである。

ログ加工部１１２，機能抽出部１１３，サービス情報生成部１１４は、仮想ユーザのデータ投入による結果として各サーバから採取したメッセージデータについて、パス分析を行ない、その分析結果を例えばサービス情報として記憶部１２０に格納する。なお、分析装置１００が生成するサービス情報には、パス情報１２６及びコンポーネント定義情報１２７が含まれる。

以下、ログ加工部１１２，機能抽出部１１３，サービス情報生成部１１４の処理について説明する。

ログ加工部１１２は、詳細ログ１２１に基づき、サービス（トランザクション，リクエスト）ごとにログの紐付けを行ない、紐付け結果１２２を生成して、記憶部１２０に保存する。例えば、ログ加工部１１２は、詳細ログ１２１を参照して、リクエストごとにトランザクションＩＤが共通するログ（モジュール（処理））の紐付けを行なうことにより、図６に示す紐付け結果１２２を生成することができる。

図６は、本実施形態に係る紐付け結果１２２の一例を示す図である。紐付け結果１２２は、例えば図５に示す詳細ログ１２１に対して、リクエストごとに、当該リクエストが属する（含まれる）サービスの識別情報を付した情報である。より具体的に、紐付け結果１２２は、図６に示すように、サービスの識別子の一例としてのＵＲＬと、トランザクションＩＤと、モジュールの呼出名（パッケージ，クラス，メソッド）とを含むことができる。なお、紐付け結果１２２には詳細ログ１２１における時刻の情報が含まれてもよい。

機能抽出部１１３は、紐付け結果１２２に基づき、各サービス（ＵＲＬ，機能）について細粒度での構成要素（モジュール（処理））を抽出し、ｃｉｄ対応表１２３及びｃｉｄセット表１２４を生成して、記憶部１２０に保存する。例えば、機能抽出部１１３は、紐付け結果１２２を参照して、互いに重複しないモジュールごとに一意のＩＤ（ｃｉｄ；例えばｃｋ（ｋは自然数）と表記）を割り当て、ｃｋとクラス，メソッドとの対応表であるｃｉｄ対応表１２３を生成することができる。また、機能抽出部１１３は、紐付け結果１２２を参照して、各サービス（トランザクション）に当該サービスに含まれるモジュールのｃｉｄを対応付けたｃｉｄセット表１２４を生成することができる。

図７は、本実施形態に係るｃｉｄ対応表１２３の一例を示す図であり、図８は、本実施形態に係るｃｉｄセット表１２４の一例を示す図である。ｃｉｄ対応表１２３は、例えばＩＤ（ｃｉｄ）と値（呼出名）とを含むことができる。一例として、ｃｉｄ対応表１２３は、図７に示すように、ＩＤ“c1”と、値“jpn.user.Pkg1#Meth1”とを含む。また、ｃｉｄセット表１２４は、例えばサービスのＵＲＬと、サービスに対応するｔｉｄと、サービスに含まれるモジュール群に対応する１以上のｃｉｄ（ｃｉｄセット）とを含むことができる。一例として、ｃｉｄセット表１２４は、図８に示すように、ＵＲＬ“URL1”と、ｔｉｄ“tid1”と、ｃｉｄセット“c1,c2,c4,c5,c6”とを含む。

なお、機能抽出部１１３によるｃｉｄ対応表１２３及びｃｉｄセット表１２４の生成前に、例えばログ加工部１１２又は機能抽出部１１３により、紐付け結果１２２から同一のトランザクションにおいてモジュールが重複するログが除去されることが好ましい。これにより、ｃｉｄ対応表１２３及びｃｉｄセット表１２４には、同一のモジュールが複数のｃｉｄとして登録されずに済むため、後述するサービス情報生成部１１４及び分析装置２００における処理負荷を軽減することができる。

機能抽出部１１３による具体的な処理（ｃｉｄ対応表１２３，ｃｉｄセット表１２４の作成）の手順については、図１８及び図１９を参照しながら後述する。

サービス情報生成部１１４は、ｃｉｄ対応表１２３及びｃｉｄセット表１２４に基づき、サービスごとに共通部分（共通モジュール（共通処理））を比較してコンポーネントを定義し、サービス情報（パス情報１２６及びコンポーネント定義情報１２７）を生成する。そして、サービス情報生成部１１４は、生成したサービス情報を記憶部１２０に保存する。なお、分析装置１００が分析装置２００とは異なる情報処理装置により実現される場合、サービス情報生成部１１４は、後述するｐｉｄ対応表１２５とサービス情報（パス情報１２６及びコンポーネント定義情報１２７）とを分析装置２００に送信してもよい。

以下、ｃｉｄ対応表１２３における複数のモジュール（処理）のうち、最上位の階層で共通するものがないモジュールについては、最上位の階層をトップレベルと呼ぶ。また、ｃｉｄ対応表１２３における複数のモジュールのうち、最上位の階層で共通するものがあるモジュールについては、共通するものがなくなる直前の階層をトップレベルと呼ぶ。例えば、図７に示すモジュールｃ１は、最上位の階層の値“jpn”がｃ１にのみ存在する（トップレベルで共通するものがない）ため、ｃ１におけるトップレベルは最上位の階層となる。また、図７に示すモジュールｃ３，ｃ４及びｃ５は、互いに“com.lang.Java.Foo1”まで共通する階層を持つため、ｃ３，ｃ４及びｃ５におけるトップレベルは共通するものがなくなる直前の階層となる。

サービス情報生成部１１４は、具体的には、ｃｉｄ対応表１２３を参照して、各モジュール（例えばｃ１,ｃ２,...）について、最上位の階層から下位の階層に向けて順に、他のモジュールとの間で共通する階層を抽出してトップレベルを検出し、分類を行なうことができる。そして、サービス情報生成部１１４は、図９に示すｐｉｄ対応表１２５を生成して、記憶部１２０に保存することができる。次いで、サービス情報生成部１１４は、ｃｉｄセット表１２４及びｐｉｄ対応表１２５に基づき、図１０に示すパス情報１２６を生成し、ｃｉｄ対応表１２３及びｐｉｄ対応表１２５に基づき、図１１に示すコンポーネント定義情報１２７を生成することができる。

図９は、本実施形態に係るｐｉｄ対応表１２５の一例を示す図である。ｐｉｄ対応表１２５は、例えばＩＤ（ｐｉｄ）と値（ｃｉｄ）とを含むことができる（図９の範囲Ａ参照）。一例として、ｐｉｄ対応表１２５は、図９の１行目に示すように、ＩＤ“p1”と、値“c1”とを含む。ここで、ｃ１は、上述のようにトップレベル（最上位の階層）の値“jpn”がｃ１にのみ存在する（トップレベルで共通するものがない）ため、単独でコンポーネントｐ１が割り当てられる。

他の例として、ｐｉｄ対応表１２５は、図９の３行目〜５行目に示すように、ＩＤ“p3.1”と、値“c3”とを含む。ここで、モジュールｃ３，ｃ４及びｃ５は、上述のようにトップレベル（共通するものがなくなる直前の階層）の値“com.lang.Java.Foo1”はｃ３，ｃ４及びｃ５で共通するため、これらのモジュールについてまとめてコンポーネントｐ３が割り当てられる。このとき、ｃ３，ｃ４及びｃ５を区別するために個別の添え字（“.1”，“.2”及び“.3”）が付加され、それぞれｐ３．１，ｐ３．２及びｐ３．３としてｐｉｄ対応表１２５に保存される。

また、ｐｉｄ対応表１２５は、図９の６行目〜７行目（図９の範囲Ｂ参照）に示すように、各サービス（ＵＲＬ）に含まれる個別のコンポーネント（図９の例ではｐ３．１，ｐ３．２及びｐ３．３）の集合がグループ化されて設定される。このとき、サービス間で完全一致しない集合についてはそれぞれ個別にグループ化される。

一例として、図９の６行目に示すように、ＵＲＬ１のｃｉｄセット（図７参照）に含まれる個別のコンポーネントの集合は、モジュールｃ３，ｃ４及びｃ５に対応するコンポーネントｐ３．１，ｐ３．２及びｐ３．３である。また、図９の７行目に示すように、ＵＲＬ２のｃｉｄセット（図７参照）に含まれる個別のコンポーネントの集合は、モジュールｃ３及びｃ５に対応するコンポーネントｐ３．１及びｐ３．３である。この場合、これらの集合はサービス（ＵＲＬ）間で完全一致しない集合であるため、それぞれ個別にグループ化される。そして、ｐｉｄ対応表１２５において、ＵＲＬ１のコンポーネントｐ３．１，ｐ３．２及びｐ３．３がコンポーネントｐ３．ａに対応付けられ、ＵＲＬ２のコンポーネントｐ３．１及びｐ３．３がコンポーネントｐ３．ｂに対応付けられて保存される。

図１０は、本実施形態に係るパス情報１２６の一例を示す図であり、図１１は、本実施形態に係るコンポーネント定義情報１２７の一例を示す図である。パス情報（第１の情報）１２６は、サービスごとに、サービスに含まれるコンポーネント（グルーピング処理）を対応付けた情報である。例えばサービスのＵＲＬと、サービスに含まれるモジュール群に対応する１以上のｐｉｄ（ｐｉｄセット）とを含むことができる。一例として、パス情報１２６は、図１０に示すように、ＵＲＬ“URL1”と、ｐｉｄセット“p1,p2,p3.a”とを含む。なお、パス情報１２６は、ｃｉｄセット表１２４のｃｉｄセット内のｃｉｄを、ｐｉｄ対応表１２５に基づきｐｉｄに置き換えたものとすることができる。

また、コンポーネント定義情報（第２の情報）１２７は、コンポーネント（グルーピング処理）に含まれるモジュールをグルーピングされた階層ごとに示す情報である。例えばｐｉｄと値（モジュール又はコンポーネント）とを含むことができる。一例として、コンポーネント定義情報１２７は、図１１の１行目に示すように、ｐｉｄ“p1”と、値“jpn.user.Pkg1#Meth1”とを含む。また、他の例として、コンポーネント定義情報１２７は、図１１の３行目に示すように、ｐｉｄ“p3.a”と、値“p3.1,p3.2,p3.3”とを含み、図１１の５行目に示すように、ｐｉｄ“p3.1”と、値“com.lang.Java.Foo1#Meth1”とを含む。このように、コンポーネント定義情報１２７は、サービス情報生成部１１４により定義されたコンポーネントの階層構造を規定する情報であるといえる。なお、コンポーネント定義情報１２７は、ｐｉｄ対応表１２５の値に設定されたｃｉｄを、ｃｉｄ対応表１２３に基づき呼出名（“com.lang.Java.Foo1#Meth1”等）に置き換えたものとすることができる。

上述のように、ｃｉｄ対応表１２３，ｃｉｄセット表１２４，ｐｉｄ対応表１２５，パス情報１２６及びコンポーネント定義情報１２７は、互いに補完可能な情報を持つ。従って、機能抽出部１１３及びサービス情報生成部１１４は、サービス情報の生成過程において、これらの情報１２３〜１２７のうちの少なくとも１つの生成及び記憶部１２０への保存を省略してもよい。

ここで、上述した（方式１）及び（方式２）の手法では、コンポーネントｐ１，ｐ２及びｐ３は、互いに共通のモジュールを含まないように生成される。

一方、本実施形態に係る分析装置１００は、共通部分（共通コンポーネントｐ３．１及びｐ３．３）を含むコンポーネントｐ３．ａ及びｐ３．ｂを定義している。つまり、分析装置１００は、パス情報１２６に、第１のサービスに含まれる第１のグルーピング処理と、第２のサービスに含まれ、グルーピングされた複数の処理のうちの一部の処理のみが第１のグルーピング処理と共通する第２のグルーピング処理と、を互いに区別可能に記憶する。このように、本実施形態においては、コンポーネントの定義において、共通部分を含みつつ互いのコンポーネントｐ３．ａ及びｐ３．ｂを区別可能な態様で、モジュールや下位の階層のコンポーネントｐ３．１，ｐ３．２及びｐ３．３を階層化するのである。これにより、（方式１）又は（方式２）において各モジュールを単にレベルや要素数等に応じて階層化して、コンポーネントｐ３１，ｐ３２及びｐ３３等がコンポーネントｐ３としてまとめられる場合と異なり、間違った分析結果になることを抑止できる。

なお、コンポーネントｐ３．ａ及びｐ３．ｂは、添え字を付加されることで他のコンポーネントｐ１及びｐ２と区別されているが、コンポーネントｐ３．ａ及びｐ３．ｂを単にコンポーネントｐ３と定義してもよい。この場合、コンポーネントｐ３には、共通部分を含むことを示す属性値を持たせ、当該属性値をテーブル等で管理してもよい。

サービス情報生成部１１４による具体的な処理（ｐｉｄ対応表１２５，パス情報１２６，コンポーネント定義情報１２７の作成）の手順については、図２０及び図２１を参照しながら後述する。

〔１−３−２〕運用フェーズの分析装置の構成
次に、図１２を参照しながら、運用フェーズ１Ｂの分析装置２００の構成について説明する。図１２は、本実施形態の運用フェーズ１Ｂの分析装置２００のハードウェア構成及び機能構成を示すブロック図である。分析装置２００は、上述したように、ＡＰサーバ４０等、又は、サーバ群２０，３０，４０とは別体の情報処理装置にそなえられることができる。本実施形態において、分析装置２００は、サーバ群２０，３０，４０とは別体の情報処理装置にそなえられているものとする。なお、記述のように、分析装置２００は分析装置１００と同一の情報処理装置により実現されてもよい。

分析装置２００は、処理部２１０が実行する処理や記憶部２２０が保存する情報が異なるものの、分析装置１００と同様の構成をそなえることができる。以下、特に言及しない限り、分析装置２００は分析装置１００と同様の構成をそなえるものとする。

処理部２１０は、例示的に、ログ採取部２１１，機能選別部２１２，データスライス分割部２１３，問題個所特定部２１４，結果出力部２１５をそなえる。処理部２１０は、記憶部２２０から所定のアプリケーションプログラム（分析プログラム）を読み出して実行することで、これらの機能を実現することができる。また、記憶部２２０は、上記分析プログラムを保存するほか、処理部２１０による異常個所特定処理に用いられる各種情報を保存することができる。記憶部２２０は、当該各種情報として、分析装置１００が生成したｐｉｄ対応表１２５，パス情報１２６，及びコンポーネント定義情報１２７を保存することができるほか、例えばアクセスログ２２１を保存することができる。

なお、分析装置２００においても、上記分析プログラムは、コンピュータ読取可能な記録媒体に記録された形態で提供されてもよい。この場合、処理部２１０は、読出装置等のインタフェースを介して当該記録媒体からプログラムを読み取り、内部記憶装置または外部記憶装置に転送及び格納して、当該プログラムを実行することができる。分析装置１００及び２００が異なる情報処理装置により実現される場合には、上記分析プログラムは、事前分析フェーズ１Ａ及び運用フェーズ１Ｂのそれぞれに係る機能で分割されて、分析装置１００及び２００に提供されてよい。

次いで、処理部２１０によって実現される、ログ採取部２１１，機能選別部２１２，データスライス分割部２１３，問題個所特定部２１４，結果出力部２１５としての機能について、図１２〜図１６を参照しながら説明する。

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

ログ採取部２１１が採取するログデータの一例を、図１３に示す。図１３は、本実施形態に係るアクセスログ２２１の一例を示す図である。アクセスログ２２１は、例えばＷｅｂサーバ３０へのＷｅｂリクエストのＵＲＬと、Ｗｅｂサーバ３０におけるＷｅｂリクエストの（受信或いは応答）時刻と、Ｗｅｂリクエストへの応答にかかった時間とを含むことができる。一例として、アクセスログ２２１は、図１３に示すように、ＵＲＬ“http://foo.com/a.cgi?〜”と、時刻“timestamp1”と、応答時間“3ms”とを含む。

機能選別部２１２は、採取したログデータを分析装置１００から予め取得したパス情報１２６と照らして、ログデータの機能選別（分類）を行なう。

データスライス分割部２１３は、選別した各機能（サービス）で正常と異常とが混在しない時間区間を切り出す処理（ステートの変化タイミングを演算する処理）を実施する。なお、選別した機能がパス情報１２６に含まれない場合は、パス情報１２６のサービスに当てはめる。

以下、正常と異常のデータが混在する場合の問題について図１４及び図１５を参照して説明する。図１４は、本実施形態に係る機能ごとの集計区間に正常と異常なデータとが混在する様子を模式的に示す図であり、図１５は、図１４において正常区間と異常区間とを分離して、重なりで判定する様子を模式的に説明する図である。

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

ここで、同じ機能でもタイミングによって正常なデータと異常なデータとが混在する場合があり、その場合には、パス情報１２６に基づく図３（Ａ）〜図３（Ｄ）を用いて既述のマトリクスを使った絞り込みを行なうことは困難である。

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

そこで、データスライス分割部２１３は、正常及び異常のステートが混在しない領域（時間区間）を自動的に切り出すことで絞り込みを可能にする。

基本的な処理の一例としては、まず、データスライス分割部２１３は、アクセスログ２２１に基づき、各ＵＲＬで正常及び異常のステートの変化のタイミングを演算し、当該タイミングに基づき、各ＵＲＬで正常及び異常のステートが混在しない時間区間を区切る。

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

問題個所特定部２１４は、データスライス分割部２１３により区切られた、各ＵＲＬで正常及び異常のステートが混在しない時間区間に基づいて、サービスの正常及び異常の状態が変化した（切り替わった）ことを検出すると、分析処理を実行する。

具体的には、問題個所特定部（第１判断部）２１４は、各時間区間が重なり合う範囲で、図３を用いて既述のように、マトリクスを作って演算（複数のサービスとモジュールとのパス情報１２６に基づき、問題個所となっている異常モジュールを算出（検出））する（第１の判断処理）。そして、問題個所特定部（第２判断部）２１４は、パス情報１２６及びコンポーネント定義情報１２７と照らし合わせて問題個所の絞込み又は特定を行なう（第２の判断処理）。

より具体的に、問題個所特定部２１４は、マトリクスの演算により原因個所として抽出したコンポーネントが共通コンポーネントを持つ場合は、共通コンポーネントを細粒度に展開して分析処理を行なう。

一例として、問題個所特定部２１４が、サービスＵＲＬ１及びＵＲＬ２について以下の判定をした場合を想定する。

URL1:遅延
URL2:正常

なお、ＵＲＬ１及びＵＲＬ２のパス情報１２６は、以下であるとする（図１０参照）。

URL1=p1-p2-p3.a
URL2=p1-p2-p3.b

この場合、問題個所特定部２１４は、マトリクスによる分析によって、遅延が生じているＵＲＬ１にのみ存在するコンポーネントｐ３．ａが遅延の原因であると推定する。

次いで、問題個所特定部２１４は、コンポーネントｐ３．ａには、共通コンポーネントを持つ同一階層の他のコンポーネントが存在するか否かを、コンポーネント定義情報１２７に照らして判定する。コンポーネントｐ３．ａには、共通コンポーネントｐ３．１及びｐ３．３を持つ同一階層のコンポーネントｐ３．ｂが存在する。

そこで、問題個所特定部２１４は、
p3.a:遅延
p3.b:正常
という情報と、コンポーネント定義情報１２７から得られる
p3.a=p3.1-p3.2-p3.3
p3.b=p3.1 -p3.3
という細粒度のパス情報とを用いてマトリクスによる分析を行ない、遅延が生じているｐ３．ａにのみ存在するコンポーネントｐ３．２が遅延の原因（異常処理）であると推定する。

なお、分析装置２００が用いるパス情報１２６は、適宜に更新されてよい。例えば、分析装置２００は、運用フェーズ１Ｂにおけるリクエストデータをユーザリクエストとして記憶部２２０等に保存しておく。そして、事前分析フェーズ１Ａで出現しなかった未知のデータが運用フェーズ１Ｂで出現した場合、分析装置２００は、保存しておいたリクエストデータを用いて再事前分析を実施することで、パス情報１２６を更新してもよい。

結果出力部２１５は、問題個所特定部２１４により推定された問題個所（異常処理）の情報を表示装置等に出力する。出力データの一例を図１６に示す。図１６は、本実施形態に係る運用フェーズ１Ｂの分析結果の通知画面例を示す図である。図１６の紙面上側には、運用フェーズ１Ｂでの分析結果の通知画面４００の一例が示されている。

通知画面４００には、例示的に、サービス（パス）とコンポーネントとの対応関係（パス情報）が表示される。また、通知画面４００に表示されたパス情報のうち、推定された問題個所のコンポーネント（或いはモジュール）のラベル（図１６の符号４０１参照）は、他のラベルとは異なる表示になる（例えば色を変えて表示される）。このとき、結果出力部２１５は、問題個所として複数の候補がある場合は例えば優先順位付で複数個出力してよい（例えば問題個所の可能性が最も高いｐ４を他の候補ｐ６及びｐ７よりも濃い色で表示する等）。なお、優先順位が付かない場合もある。

また、問題個所のラベルは選択可能（例えばマウス等によりクリック可能）になっており、ユーザが当該ラベルを選択すると、紙面下側に示す詳細表示画面４１０が表示される。なお、結果出力部２１５は、原因コンポーネントを自動で詳細表示してもよい。

詳細表示画面４１０には、例示的に、ラベル（コンポーネント）名、分析期間、分析期間内の原因コンポーネントを使ったリクエスト数、分析期間内の原因コンポーネントを使ったＵＲＬ、原因コンポーネントが統合するパッケージ群等の情報が表示される。

なお、結果出力部２１５は、遅延原因となったコンポーネントを使うＵＲＬをクリップボードにコピーするボタン（図１６の符号４１１参照）等を表示してもよい。また、結果出力部２１５は、問題個所特定部２１４が分析の際に自動で細粒度に展開するのと同様に、通知画面４００上でも自動で細粒度に展開するようにしてもよい。例えば、問題個所特定部２１４によりコンポーネントｐ３．ａに含まれるコンポーネントｐ３．２が遅延の原因（異常処理）であると推定された場合には、上記の詳細表示画面４１０に、“p3.2=com.lang.Java.Foo1#Meth2”が遅延原因であることを示す情報が表示される。

なお、上述した通知画面４００は、問題個所特定部２１４による問題個所の推定が完了する前（例えば分析開始前後）から表示されていてもよい。

また、結果出力部２１５は、パス情報や問題個所を表示装置等に表示せず、メール等でユーザに通知してもよく、分析結果をファイルに格納してもよい。

以上のように、分析装置１００は、事前分析フェーズ１Ａにおいて、使用コンポーネントを事前に最細粒度で分析し、より細粒度のコンポーネントで共通コンポーネントの有無を考慮した複数の粒度でコンポーネント定義を生成する。すなわち、分析装置１００は、複数の階層を持つ処理を複数含むサービスについて、サービスごとの各処理を共通する階層の有無を考慮して所定の階層でグルーピングしたサービス情報を生成し、記憶する。

また、分析装置２００は、運用フェーズ１Ｂにおいて、共通コンポーネントを持つコンポーネントが原因個所であると分析した場合は、そのコンポーネントを（グループ化されたコンポーネントでなくなるまで）細粒度化して再分析する。このように、分析装置２００は、段階的に原因個所を特定する。すなわち、分析装置２００は、複数のサービスに関するログデータ及びサービス情報に基づき、１以上のサービスに含まれる処理について、異常の有無を判断する第１の判断処理を行なう。また、分析装置２００は、異常と判断された処理がグルーピングされたグルーピング処理である場合、サービス情報に基づき、異常と判断されたグルーピング処理を所定の階層よりも下位の階層の１以上の処理に展開して、展開した１以上の処理について異常の有無を判断する第２の判断処理を行なう。

このように、分析装置１００及び２００によれば、粗い粒度での分析のように原因個所の判定を間違えることなく、かつ細粒度の分析のようにリアルタイム性を損なうことなく原因個所の分析をすることが可能となる。

〔１−４〕本実施形態に係る分析装置の動作例
次に、上述のごとく構成された本実施形態に係る分析装置１００及び２００の動作例について説明する。

〔１−４−１〕事前分析フェーズの分析装置の動作例
はじめに、図１７に示すフローチャート（ステップＳ１〜Ｓ４）に従って、本実施形態に係る分析装置１００の動作例について説明する。

分析装置１００は、事前分析フェーズ１Ａにおいて、ログ採取部１１１からネットワーク１０経由でサーバ２０，３０及び４０にリクエストを発行する。リクエストを受けたサーバ２０，３０及び４０では、当該リクエストに応じた処理が実行され、当該リクエストに対応するリクエストログが分析装置１００へ出力される。なお、リクエストは、例えばユーザリクエストデータベース（図示省略）に予め用意したリクエストデータを再生することで発行される。リクエストの発行処理は、所定の終了条件が満たされるまで繰り返される。なお、リクエストデータとしては、実運用時に採取したものや、テストデータとして生成したもの等を用いることができる。

そして、ログ採取部１１１は、リクエストログの一例としての詳細ログ１２１を、サーバ２０，３０及び４０等から受信し採取する（ステップＳ１）。ログ採取部１１１によって採取された詳細ログ１２１は記憶部１２０に保存される。

この後、ログ加工部１１２は、詳細ログ１２１に基づき、サービス（トランザクション，リクエスト）ごとにログの紐付けを行ない、紐付け結果１２２を生成して、記憶部１２０に保存する（ステップＳ２）。

次いで、機能抽出部１１３は、紐付け結果１２２に基づき、各サービス（ＵＲＬ，機能）について細粒度での構成要素（モジュール（処理））を抽出し、ｃｉｄ対応表１２３及びｃｉｄセット表１２４を生成して、記憶部１２０に保存する（ステップＳ３）。ステップＳ３での処理手順、つまり機能抽出部１１３による処理（構成要素抽出処理）の手順については、図１８及び図１９を参照しながら後述する。

サービス情報生成部１１４は、ステップＳ３で作成されたｃｉｄ対応表１２３及びｃｉｄセット表１２４基づき、サービスごとに共通部分（共通モジュール（共通処理））を比較してコンポーネントを定義する。そして、サービス情報生成部１１４は、サービス情報（パス情報１２６及びコンポーネント定義情報１２７）を生成して記憶部１２０に保存する（ステップＳ４）。ステップＳ４での処理手順、つまりサービス情報生成部１１４による処理（サービス情報生成処理）の手順については、図２０及び図２１を参照しながら後述する。

〔１−４−１−１〕構成要素抽出処理
次に、図１８に示すフローチャート（ステップＳ１１〜Ｓ１８）及び図１９に示すテーブル例を参照しながら、分析装置１００（機能抽出部１１３）の構成要素抽出処理の動作例について説明する。

はじめに、機能抽出部１１３は、構成要素抽出処理において、ログ加工部１１２により生成された紐付け結果１２２（図１９参照）を参照し、未処理のｔｉｄセットがあるか否かを判断する（ステップＳ１１）。未処理のｔｉｄセットがある場合（ステップＳ１１のＹｅｓルート）、機能抽出部１１３は、紐付け結果１２２に未処理のレコードがあるか否かを判断する（ステップＳ１２）。

未処理のレコードがない場合（ステップＳ１２のＮｏルート）、処理がステップＳ１１に移行する。一方、未処理のレコードがある場合（ステップＳ１２のＹｅｓルート）、機能抽出部１１３は、未処理のレコードのモジュールが、同一ｔｉｄ内で未出現か否かを判断する（ステップＳ１３）。未処理のレコードのモジュールが同一ｔｉｄ内で未出現ではない場合（ステップＳ１３のＮｏルート）、機能抽出部１１３は当該レコードを重複として除去し（ステップＳ１４，図１９の重複除去例１２２参照）、処理がステップＳ１２に移行する。なお、紐付け結果１２２の重複除去は、機能抽出部１１３ではなくログ加工部１１２による紐付け結果１２２の生成の際に行なわれてもよい。

一方、ステップＳ１３において、未処理のレコードのモジュールが同一ｔｉｄ内で未出現の場合（ステップＳ１３のＹｅｓルート）、機能抽出部１１３は、当該モジュール内のメソッドがｃｉｄ対応表１２３に未登録か否かを判断する（ステップＳ１５）。メソッドが未登録の場合（ステップＳ１５のＹｅｓルート）、当該メソッドをｃｉｄ対応表１２３（図１９参照）に登録し（ステップＳ１６）、処理がステップＳ１７に移行する。なお、ｃｉｄ対応表１２３（最細粒度テーブル）において最細粒度の要素は全てのＵＲＬ及びｔｉｄで共通となる。また、メソッドが登録済の場合（ステップＳ１５のＮｏルート）、処理がステップＳ１７に移行する。

ステップＳ１７では、機能抽出部１１３は、ｃｉｄ対応表１２３を参照して当該モジュール内のメソッドからｃｉｄを抽出して記憶し、処理がステップＳ１２に移行する。

また、ステップＳ１において、未処理のｔｉｄセットがない場合（ステップＳ１１のＮｏルート）、機能抽出部１１３は、ステップＳ１７で抽出し記憶した１以上のｃｉｄ（ｃｉｄセット）をｃｉｄセット表１２４（図１９参照）に登録する（ステップＳ１８）。このとき、機能抽出部１１３は、当該ｃｉｄセットを対応するｔｉｄ及びＵＲＬに関連付ける。

以上により、機能抽出部１１３による構成要素抽出処理が終了する。

〔１−４−１−２〕サービス情報生成処理
次に、図２０に示すフローチャート（ステップＳ２１〜Ｓ２４）及び図２１に示すテーブル例を参照しながら、分析装置１００（サービス情報生成部１１４）のサービス情報生成処理の動作例について説明する。

はじめに、サービス情報生成部１１４は、サービス情報生成処理において、ｃｉｄ対応表１２３でトップレベルから共通するものを抽出して分類し、ｐｉｄ対応表１２５（図２１参照）を生成して記憶部１２０に保存する（ステップＳ２１）。例えば図２１のｃｉｄ対応表１２３において、ｃ１のトップレベルの“jpn”は、ｃｉｄ対応表１２３中でｃ１のみであるため、ｃ１には単独でコンポーネントｐ１が割り当てられ、ｐｉｄ対応表１２５に登録される（ｐｉｄ対応表１２５のＡ領域１行目参照）。また、例えば図２１のｃｉｄ対応表１２３において、ｃ３のトップレベルの“com.lang.Java.Foo1”は、ｃｉｄ対応表１２３中でｃ３，ｃ４及びｃ５で共通するため、ｃ３，ｃ４及びｃ５には共通でコンポーネントｐ３が割り当てられる。このとき、ｐ３には、ｃ３，ｃ４及びｃ５を区別するために添え字“.1”，“.2”及び“.3”が付加され、ｐｉｄ対応表１２５に登録される（図２１のＡ領域の３〜５行目参照）。

次いで、サービス情報生成部１１４は、複数要素を持つｐｉｄに対してｃｉｄセット表１２４で完全一致しない集合をグループ化し（ステップＳ２２）、ｐｉｄ対応表１２５を更新する（図２１のｐｉｄ対応表（更新）１２５のＢ領域参照）。例えば図２１のｐｉｄ対応表１２５において、複数の要素を持つコンポーネントはｐ３のみであり、ｐ３に相当するｃｉｄセットは、ＵＲＬ１ではｃ３，ｃ４及びｃ５、ＵＲＬ２ではｃ３及びｃ５である。この場合、ｃ３，ｃ４及びｃ５とｃ３及びｃ５とは完全一致しないため、サービス情報生成部１１４は、各サービスをグループ化し、それぞれｐ３．ａ及びｐ３．ｂとしてｐｉｄ対応表１２５を更新する。

そして、サービス情報生成部１１４は、グループ化したｐｉｄの中に下位レベルに共通する処理があるか否かを判断する（ステップＳ２３）。下位レベルに共通する処理がある場合（ステップＳ２３のＹｅｓルート）、処理がステップＳ２１に移行する。例えば、図２１のｃｉｄ対応表１２３において、ｃ３及びｃ４が以下のモジュールであった場合を考える。

c3:com.lang.Java.Foo1.Boo2#Meth1
c4:com.lang.Java.Foo1.Boo2#Meth2

図２１の例では、ＵＲＬ１はｃ３，ｃ４及びｃ５が“com.lang.Java.Foo1”でグループ化されているが、ｃ３及びｃ４についてはさらに１つ下の階層の“Boo2”も共通である。この場合、サービス情報生成部１１４は、ｃ３及びｃ４を“com.lang.Java.Foo1.Boo2”でまとめるために、ステップＳ２１の処理を再度実行するのである。なお、図２１に示すテーブル例では、ステップＳ２３のＹｅｓルートに対応するものはない。

また、ステップＳ２３において、下位レベルに共通する処理がない場合（ステップＳ２３のＮｏルート）、サービス情報生成部１１４は、結果をサービス情報として格納し（ステップＳ２４）、処理が終了する。例えば、サービス情報生成部１１４は、ｃｉｄセット表１２４及びｐｉｄ対応表１２５に基づき、パス情報１２６を生成し、ｃｉｄ対応表１２３及びｐｉｄ対応表１２５に基づき、コンポーネント定義情報１２７を生成する（図２１参照）。

以上により、サービス情報生成部１１４によるサービス情報生成処理が終了する。

〔１−４−２〕運用フェーズの分析装置の動作例
次に、図２２に示すフローチャート（ステップＳ３１〜Ｓ３４）に従って、本実施形態に係る分析装置２００の動作例について説明する。

分析装置２００は、運用フェーズ１Ｂにおいて、前面のサーバの一例としてのＷｅｂサーバ３０からログデータを入力され、ログ採取部２１１はログデータ（例えばアクセスログ２２１）を採取する（ステップＳ３１）。

次いで、機能選別部２１２は、採取したデータからＵＲＬ、ＣＧＩ等のパラメータを基に機能単位を選別する。

さらに、データスライス分割部２１３は、選別した各機能（ＵＲＬ）で正常と異常とが混在しない時間区間を切り出す処理（ステートの変化タイミングを演算する処理）を実施する。なお、選別した機能がパス情報１２６に含まれない場合は、パス情報１２６の機能に当てはめる。

その後、問題個所特定部２１４は、データスライス分割部２１３により区切られた、各機能で正常及び異常のステートが混在しない時間区間に基づいて、サービスの正常及び異常の状態が変化したことを検出すると、分析処理を実行する（ステップＳ３２）。

また、問題個所特定部２１４は、分析処理により原因個所として推定（抽出）したコンポーネントが共通コンポーネントを持つ場合は、共通コンポーネントを細粒度に展開して分析処理を行なう（ステップＳ３３）。ステップＳ３３の分析処理は、最細粒度になるまで、階層的に展開及び分析が繰り返される。ステップＳ３３での処理手順、つまり問題個所特定部２１４による処理（分析処理）の手順については、図２３及び図２４を参照しながら後述する。

最後に、結果出力部２１５は、問題個所特定部２１４により推定された問題個所（異常処理）の情報を表示装置等に出力する（ステップＳ３４）。

以上により、運用フェーズ１Ｂの分析装置２００の処理が終了する。

〔１−４−２−１〕分析処理
次に、図２３に示すフローチャート（ステップＳ４１〜Ｓ４７）及び図２４に示すテーブル例を参照しながら、分析装置２００（問題個所特定部２１４）の分析処理の動作例について説明する。

はじめに、問題個所特定部２１４は、分析処理の対象データ（図２４の（ａ）参照）があるか否かを判断する（ステップＳ４１）。対象データがない場合（ステップＳ４１のＮｏルート）、処理が終了する。一方、対象データがある場合（ステップＳ４１のＹｅｓルート）、問題個所特定部２１４は、パス情報１２６を参照して、対象データから遅延要素（遅延コンポーネント）を特定する（ステップＳ４２，図２４の（ｂ）参照）。

例えば、問題個所特定部２１４は、図２４に示すように対象データのうちのＵＲＬ１が遅延する一方、ＵＲＬ２が正常であり、ＵＲＬ１にはＵＲＬ２に含まれないコンポーネントｐ３．ａがある場合、ｐ３．ａを遅延原因の要素と推定する。

次いで、問題個所特定部２１４は、ステップＳ４２で特定した要素があるか否か、つまり要素が特定されたか否かを判断する（ステップＳ４３）。特定した要素がない場合（ステップＳ４３のＮｏルート）、処理がステップＳ４６に移行する。一方、特定した要素がある場合（ステップＳ４３のＹｅｓルート）、問題個所特定部２１４は、コンポーネント定義情報１２７を参照して、特定した要素にサブ要素（サブコンポーネント）があるか否かを判断する（ステップＳ４４）。

特定要素にサブ要素がない場合（ステップＳ４４のＮｏルート）、問題個所特定部２１４は、特定した要素を機能選別部２１２に出力し（ステップＳ４５）、他に未処理の要素があるか否かを判断する（ステップＳ４６）。未処理の要素がある場合（ステップＳ４６のＹｅｓルート）、処理がステップＳ４１に移行する。一方、未処理の要素がない場合（ステップＳ４６のＮｏルート）、処理が終了する。

また、特定要素にサブ要素がある場合（ステップＳ４４のＹｅｓルート）、問題個所特定部２１４は、コンポーネント定義情報１２７（又はｐｉｄ対応表１２５）を参照して特定要素をサブ要素に展開する（図２４の（ｃ）参照）。そして、問題個所特定部２１４は、展開したサブ要素を対象データとして（ステップＳ４７）、ステップＳ４１の処理を再度実行する。

なお、サブ要素について、ステップＳ４１のＹｅｓルートを経てステップＳ４２の処理が実行されると、問題個所特定部２１４は、図２４の（ｄ）に示すように、要素ｐ３．２を遅延要素として特定する。要素ｐ３．２には、サブ要素はないため、問題個所特定部２１４は、コンポーネント定義情報１２７を参照して、特定した要素ｐ３．２に関する以下の情報を、結果出力部２１５に出力する（図２４の（ｅ）参照）。

特定した要素:p3.2=c4=com.lang.Java.Foo1#Meth2

以上により、問題個所特定部２１４による分析処理が終了する。

〔２〕適用事例
次に、図２５を参照しながら、一実施形態に係る分析装置２００の適用事例を説明する。図２５に示すパス情報１２６は、以下のように表すことができる。

URL1=p1-p2.a(p2.1) -p3.a(p3.1-p3.2-p3.3)
URL2=p1-p2.b(p2.1-p2.2)-p3.b(p3.1 -p3.3)

・コンポーネントｐ３．２が遅延原因の場合
コンポーネントｐ３．２が遅延原因の場合、コンポーネントｐ３．２はＵＲＬ１のみに含まれるため、問題個所特定部２１４は、サービスＵＲＬ１及びＵＲＬ２について以下の判定をする。

URL1:遅延
URL2:正常

このとき、問題個所特定部２１４は、パス情報１２６に基づくマトリクスによる分析によって、遅延が生じているＵＲＬ１にのみ存在するコンポーネントｐ２．ａ又はｐ３．ａが遅延の原因であると推定する。

次いで、問題個所特定部２１４は、コンポーネントｐ２及びｐ３について、それぞれ細粒度化（サブコンポーネントに展開）する。問題個所特定部２１４は、例えばｐ２についてマトリクスに基づく分析を行なうが、遅延が生じているｐ２．ａにのみ存在するコンポーネントは存在しないため、原因個所は特定されない。

×p2.a=p2.1
○p2.b=p2.1-p2.2

一方、問題個所特定部２１４は、ｐ３についてマトリクスに基づく分析を行ない、遅延が生じているｐ３．ａにのみ存在するコンポーネントｐ３．２を原因個所として抽出（推定）することができる。

×p3.a=p3.1-p3.2-p3.3
○p3.b=p3.1 -p3.3

・コンポーネントｐ２．２が遅延原因の場合
コンポーネントｐ２．２が遅延原因の場合、コンポーネントｐ２．２はＵＲＬ２のみに含まれるため、問題個所特定部２１４は、サービスＵＲＬ１及びＵＲＬ２について以下の判定をする。

URL1:正常
URL2:遅延

このとき、問題個所特定部２１４は、パス情報１２６に基づくマトリクスによる分析によって、遅延が生じているＵＲＬ２にのみ存在するコンポーネントｐ２．ｂ又はｐ３．ｂが遅延の原因であると推定する。

次いで、問題個所特定部２１４は、コンポーネントｐ２及びｐ３について、それぞれ細粒度化（サブコンポーネントに展開）する。問題個所特定部２１４は、例えばｐ２についてマトリクスに基づく分析を行ない、遅延が生じているｐ２．ｂにのみ存在するコンポーネントｐ２．２を原因個所として抽出（推定）することができる。

○p2.a=p2.1
×p2.b=p2.1-p2.2

一方、問題個所特定部２１４は、ｐ３についてマトリクスに基づく分析を行なうが、遅延が生じているｐ３．ｂにのみ存在するコンポーネントは存在しないため、原因個所は特定されない。

○p3.a=p3.1-p3.2-p3.3
×p3.b=p3.1 -p3.3

本適用事例を（方式１）及び（方式２）の手法で分析した場合、ＵＲＬ１及びＵＲＬ２におけるｐ２及びｐ３はいずれもｐ２及びｐ３としてまとめられるため、ＵＲＬ１及びＵＲＬ２は一致してしまい、遅延原因として何も検出されない。

これに対し、一実施形態に係る分析装置２００によれば、図２５に示すように複数個所で、モジュールを所定の粒度（所定の階層）でコンポーネント化していても、正確に異常処理を推定することができる。また、粒度を粗く（上位の階層で処理をグルーピング）しても原因個所の判定を正確に行なうことができる。さらに、原因個所の可能性があるコンポーネントについてのみ、コンポーネントを展開し階層的な分析を繰り返すので、サービス全体を細粒度で分析する場合と対比して、リアルタイム性を損なうことなく高速に原因個所の分析・推定をすることが可能になる。

〔３〕変形例
一実施形態に係る分析装置１００又は２００は、上述したものに限定されるものではない。以下、一実施形態に係る分析装置１００又は２００の変形例について説明する。

〔３−１〕第１変形例
一実施形態に係る分析装置２００は、最も粗い（トップレベルの）粒度で分析を開始するものとして説明したが、これに限定されるものではない。

すなわち、一実施形態に係る分析装置２００（問題個所特定部２１４）は、粗い粒度から分析処理を開始し、コンポーネントの共通性等により細かい粒度を展開して処理を行なうが、細粒度から分析を開始してもよい。

例えば、ユーザが予め分析開始の粒度レベルを設定しておくことで、分析装置２００（問題個所特定部２１４）は、パス情報１２６を設定した粒度レベルまで展開した状態から分析を開始してもよい。

図２６は、第１変形例に係る粒度レベルの設定例を説明する図である。ユーザ等は、例えば予めレベル２やレベル３等の粒度レベルを分析装置２００に通知（設定）しておき、分析装置２００は、通知された粒度レベルを記憶部２２０等に記憶する。なお、分析装置２００は、パス情報１２６とコンポーネント定義情報１２７（或いはｐｉｄ対応表１２５）とに基づき、設定された粒度レベルを認識することができる。

例えば、一実施形態に係る分析装置２００（問題個所特定部２１４）が、図２６に示すレベル１のパス情報１２６が入力され、サービスＵＲＬ１及びＵＲＬ２について以下の判定をした場合を想定する。

URL1:遅延
URL2:正常

この場合、一実施形態に係る分析装置２００は、レベル１から分析処理を開始し、コンポーネントｐ１及びｐ２は絞り込みにより原因候補から外れるため、レベル２のｐ３．ａ及びｐ３．ｂを展開して、更なる分析処理を行なう。

一方、第１変形例に係る分析装置２００（問題個所特定部２１４）は、仮に粒度レベル２から処理を開始することが設定（定義）されている場合、以下のようにパス情報１２６をレベル２に展開した状態から分析処理を開始する。

URL1=p1-p2-p3.1-p3.2.a
URL2=p1-p2-p3.1-p3.2.b

第１変形例に係る分析装置２００は、上記のようにレベル２に展開したパス情報１２６に入力例の遅延／正常を当てはめると、コンポーネントｐ１，ｐ２及びｐ３．１は絞り込みにより原因候補から外れる。そこで、第１変形例に係る分析装置２００は、レベル２に展開したパス情報１２６を、さらにレベル３（ｐ３．２．ａ及びｐ３．２．ｂ）に展開して、分析装置を行なう。

このように、分析装置２００は、問題個所特定部２１４の分析処理において、１以上のサービスに含まれる処理のうちのグループ化されたコンポーネントについては、コンポーネント定義情報１２７に基づき所定の階層よりも下位の階層の１以上の処理に展開してから、異常の有無を判断する。

このようにすることで、コンポーネント定義を最も粗い粒度としたパス情報１２６が簡素な場合（細粒度に展開して分析することが明らかな場合）、第１変形例に係る分析装置２００は、設定された粒度レベルまで初めから展開した状態で分析を開始できる。従って、第１変形例に係る分析装置２００によれば、異常処理の検出時間を短縮することができる。

〔３−２〕第２変形例
第１変形例では、粒度レベルをユーザが設定するものとして説明したが、これに限定されるものではない。例えば、第２変形例に係る分析装置２００は、第１変形例に係る分析装置２００に加えて、データの傾向を学習して分析開始粒度を決定する（所定の階層を他の階層に変化させる）機能をそなえてもよい。

例えば、第２変形例に係る分析装置２００は、所定の回数、パスの状態変化の検出及び問題個所の分析を繰り返すことで、遅延原因となる可能性の高いコンポーネントを学習することができる。この学習結果は、例えば分析装置２００がｐｉｄ対応表１２５やコンポーネント定義情報１２７等に対して、遅延原因と推定したコンポーネントに累積の推定回数を設定すること等により管理することができる。

そして、第２変形例に係る分析装置２００は、学習結果に基づき、遅延原因となる可能性の高いコンポーネント（及び当該コンポーネントの近傍のコンポーネント等）を予め細粒度に展開した状態で、分析処理を行なう。なお、分析装置２００は、学習結果に基づきパス情報１２６やコンポーネント定義情報１２７等を更新してもよい。

なお、分析装置２００が予め展開するコンポーネントは、１つでも複数でもよい。分析装置２００が「いくつのコンポーネントを展開するか」や「どのレベルまで展開するか」は、ユーザによる設定や計算リソースによる自動制限等の手法で決定することができる。

このように、第２変形例に係る分析装置２００によれば、実際に遅延原因となったコンポーネントを学習し、遅延原因となる可能性の高いコンポーネント等に対して、上述した第１変形例を適用することができる。従って、遅延原因となる可能性の高いコンポーネントについて、初めから展開した状態で分析を開始できるため、異常処理の検出時間をさらに短縮することができる。

〔３−３〕第３変形例
一実施形態に係る分析装置１００は、ログ採取部１１１が採取した詳細ログ１２１に基づいて、コンポーネント定義情報１２７を生成するものとして説明したが、これに限定されるものではない。

例えば、分析装置２００は、ユーザが定義して記憶部２２０に格納したコンポーネント定義情報１２７（及びパス情報１２６等）を用いてもよい。この場合、分析装置１００はコンポーネント定義情報１２７等の生成を省略することができる。また、分析装置１００は、ユーザにより定義されたコンポーネント定義情報１２７等の内容を考慮して他の情報（例えばｐｉｄ対応表１２５等）を生成してもよい。なお、分析装置２００は、分析装置１００により生成され、ユーザによって更新（加工）されたコンポーネント定義情報１２７等を用いてもよい。

例えばアプリケーションやネットワーク、システム全体の設計等の段階で、頻繁に使用される（遅延原因になる可能性が高い）モジュールがわかっている場合、ユーザは、当該モジュールを考慮してコンポーネント定義情報１２７を定義することができる。例えば、ユーザは、頻繁に使用されるモジュールを含むコンポーネントについては、比較的細粒度或いは最細粒度でコンポーネントを定義することができる。なお、ユーザは、使用される頻度が低い（遅延原因になる可能性が低い）モジュールについては、粗い粒度でコンポーネントを定義してもよい。

これにより、遅延原因となる可能性の高いコンポーネントについて、初めから展開した状態で分析を開始できるため、異常処理の検出時間を短縮することができる。

〔３−４〕第４変形例
また、分析装置２００は、分析結果を学習してコンポーネント定義情報１２７（及びパス情報１２６等）を動的に変更してもよい。

例えば、あるレベル（階層）のコンポーネントにおいて、次（下位）のレベルのコンポーネント（サブコンポーネント）の数が多く、且つ当該あるレベルのコンポーネントが遅延原因と判定される頻度が高い場合がある。このような場合、分析装置２００は、当該コンポーネントを分割して複数のコンポーネントとして定義しなおしてコンポーネント定義情報１２７等を更新することで、分析の効率を上げることができる。

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

例えば、上述した実施形態では、ＵＲＬ内のパラメータやアプリケーションのモジュールを対象とした場合について説明したが、本発明は、これに限定されるものではない。例えば、本発明は、ＰＯＳＴメソッドやＨＴＴＰ（Hypertext Transfer Protocol）ヘッダのパラメータ等にも同様に適用され、上述と同様の効果を奏することができる。

また、図１に示す事前分析フェーズ１Ａの構成は、分析装置１００を含めて、ｐｉｄ対応表１２５やサービス情報（パス情報１２６及びコンポーネント定義情報１２７）等の生成及び分析装置２００への保存が完了した後は、撤去（削除）されてもよい。すなわち、事前分析フェーズ１Ａ（分析装置１００）は、運用フェーズ１Ｂで用いるサービス情報等を生成するための構成であるため、サービス情報等の生成・保存後は少なくとも分析装置１００は不要となる。

また、上述した各変形例において、コンポーネント定義情報１２７のほかにパス情報１２６やｐｉｄ対応表１２５等がユーザによって生成されてもよく、この場合、事前分析フェーズ１Ａ（少なくとも分析装置１００）を省略してもよい。

〔５〕付記
以上の実施形態及び各変形例に関し、さらに以下の付記を開示する。

（付記１）
複数の階層を持つ処理を複数含むサービスについて、サービスごとの各処理を共通する階層の有無を考慮して所定の階層でグルーピングしたサービス情報を記憶し、
複数のサービスに関するログデータ及び前記サービス情報に基づき、一以上のサービスに含まれる処理について、異常の有無を判断する第１の判断処理を行ない、
異常と判断された処理がグルーピングされたグルーピング処理である場合、前記サービス情報に基づき、前記異常と判断されたグルーピング処理を前記所定の階層よりも下位の階層の一以上の処理に展開して、展開した一以上の処理について異常の有無を判断する第２の判断処理を行なう、
ことを特徴とする、分析方法。

（付記２）
前記サービス情報は、サービスごとに、サービスに含まれるグルーピング処理を対応付けた第１の情報を含み、
前記第１の情報に、第１のサービスに含まれる第１のグルーピング処理と、第２のサービスに含まれ、グルーピングされた複数の処理のうちの一部の処理のみが前記第１のグルーピング処理と共通する第２のグルーピング処理と、を互いに区別可能に記憶する、
ことを特徴とする、付記１記載の分析方法。

（付記３）
前記サービス情報は、グルーピング処理に含まれる処理をグルーピングされた階層ごとに示す第２の情報を含み、
前記第１の判断処理において、前記一以上のサービスに含まれる処理のうちのグルーピング処理については、前記第２の情報に基づき前記所定の階層よりも下位の階層の一以上の処理に展開してから、異常の有無を判断する、
ことを特徴とする、付記１又は付記２記載の分析方法。

（付記４）
前記サービス情報は、グルーピング処理に含まれる処理をグルーピングされた階層ごとに示す第２の情報を含み、
前記第２の判断処理の処理結果を記憶し、
記憶した処理結果に基づき、前記所定の階層を他の階層に変化させる、
ことを特徴とする、付記１又は付記２記載の分析方法。

（付記５）
前記サービス情報は、グルーピング処理に含まれる処理をグルーピングされた階層ごとに示す第２の情報を含み、
前記第２の判断処理の処理結果を記憶し、
記憶した処理結果に基づき、所定のグルーピング処理を分割して複数のグルーピング処理とする、
ことを特徴とする、付記１又は付記２記載の分析方法。

（付記６）
前記第２の判断処理において、
異常と判断された処理がグルーピング処理である場合、異常と判断された処理がグルーピング処理でなくなるまで、段階的に前記異常と判断された処理をさらに下位の階層の一以上の処理に展開して、展開した一以上の処理について異常の有無を判断する、
ことを特徴とする、付記１〜５のいずれか１項記載の分析方法。

（付記７）
複数のサービスに関する前記ログデータに基づき、各サービスの状態に正常及び異常の状態が混在しない時間区間を取得し、
前記第１の判断処理において、
取得した時間区間に実行された一以上のサービスに含まれる処理について、異常の有無を判断する、
ことを特徴とする、付記１〜６のいずれか１項記載の分析方法。

（付記８）
複数の階層を持つ処理を複数含むサービスについて、サービスごとの各処理を共通する階層の有無を考慮して所定の階層でグルーピングしたサービス情報を記憶する記憶部と、
複数のサービスに関するログデータ及び前記サービス情報に基づき、一以上のサービスに含まれる処理について、異常の有無を判断する第１の判断処理を行なう第１判断部と、
異常と判断された処理がグルーピングされたグルーピング処理である場合、前記サービス情報に基づき、前記異常と判断されたグルーピング処理を前記所定の階層よりも下位の階層の一以上の処理に展開して、展開した一以上の処理について異常の有無を判断する第２の判断処理を行なう第２判断部と、をそなえる
ことを特徴とする、分析装置。

（付記９）
前記サービス情報は、サービスごとに、サービスに含まれるグルーピング処理を対応付けた第１の情報を含み、
前記記憶部は、第１のサービスに含まれる第１のグルーピング処理と、第２のサービスに含まれ、グルーピングされた複数の処理のうちの一部の処理のみが前記第１のグルーピング処理と共通する第２のグルーピング処理と、を互いに区別可能に設定された前記第１の情報を記憶する、
ことを特徴とする、付記８記載の分析装置。

（付記１０）
前記サービス情報は、グルーピング処理に含まれる処理をグルーピングされた階層ごとに示す第２の情報を含み、
前記第１判断部は、前記一以上のサービスに含まれる処理のうちのグルーピング処理については、前記第２の情報に基づき前記所定の階層よりも下位の階層の一以上の処理に展開してから、異常の有無を判断する、
ことを特徴とする、付記８又は付記９記載の分析装置。

（付記１１）
前記サービス情報は、グルーピング処理に含まれる処理をグルーピングされた階層ごとに示す第２の情報を含み、
前記記憶部は、前記第２の判断処理の処理結果を記憶し、
記憶した処理結果に基づき、前記所定の階層を他の階層に変化させる、
ことを特徴とする、付記８又は付記９記載の分析装置。

（付記１２）
前記サービス情報は、グルーピング処理に含まれる処理をグルーピングされた階層ごとに示す第２の情報を含み、
前記記憶部は、前記第２の判断処理の処理結果を記憶し、
記憶した処理結果に基づき、所定のグルーピング処理を分割して複数のグルーピング処理とする、
ことを特徴とする、付記８又は付記９記載の分析装置。

（付記１３）
前記第２判断部は、
異常と判断された処理がグルーピング処理である場合、異常と判断された処理がグルーピング処理でなくなるまで、段階的に前記異常と判断された処理をさらに下位の階層の一以上の処理に展開して、展開した一以上の処理について異常の有無を判断する、
ことを特徴とする、付記８〜１２のいずれか１項記載の分析装置。

（付記１４）
複数のサービスに関する前記ログデータに基づき、各サービスの状態に正常及び異常の状態が混在しない時間区間を取得する取得部をさらにそなえ、
前記第１判断部は、
取得した時間区間に実行された一以上のサービスに含まれる処理について、異常の有無を判断する、
ことを特徴とする、付記８〜１３のいずれか１項記載の分析装置。

（付記１５）
コンピュータに、
複数の階層を持つ処理を複数含むサービスについて、サービスごとの各処理を共通する階層の有無を考慮して所定の階層でグルーピングしたサービス情報を記憶し、
複数のサービスに関するログデータ及び前記サービス情報に基づき、一以上のサービスに含まれる処理について、異常の有無を判断する第１の判断処理を行ない、
異常と判断された処理がグルーピングされたグルーピング処理である場合、前記サービス情報に基づき、前記異常と判断されたグルーピング処理を前記所定の階層よりも下位の階層の一以上の処理に展開して、展開した一以上の処理について異常の有無を判断する第２の判断処理を行なう、
処理を実行させることを特徴とする、分析プログラム。

（付記１６）
前記サービス情報は、サービスごとに、サービスに含まれるグルーピング処理を対応付けた第１の情報を含み、
前記コンピュータに、
前記第１の情報に、第１のサービスに含まれる第１のグルーピング処理と、第２のサービスに含まれ、グルーピングされた複数の処理のうちの一部の処理のみが前記第１のグルーピング処理と共通する第２のグルーピング処理と、を互いに区別可能に記憶する、
処理を実行させることを特徴とする、付記１５記載の分析プログラム。

（付記１７）
前記サービス情報は、グルーピング処理に含まれる処理をグルーピングされた階層ごとに示す第２の情報を含み、
前記第１の判断処理において、前記一以上のサービスに含まれる処理のうちのグルーピング処理については、前記第２の情報に基づき前記所定の階層よりも下位の階層の一以上の処理に展開してから、異常の有無を判断する、
ことを特徴とする、付記１５又は付記１６記載の分析プログラム。

（付記１８）
前記サービス情報は、グルーピング処理に含まれる処理をグルーピングされた階層ごとに示す第２の情報を含み、
前記コンピュータに、
前記第２の判断処理の処理結果を記憶し、
記憶した処理結果に基づき、前記所定の階層を他の階層に変化させる、
処理を実行させることを特徴とする、付記１５又は付記１６記載の分析プログラム。

（付記１９）
前記サービス情報は、グルーピング処理に含まれる処理をグルーピングされた階層ごとに示す第２の情報を含み、
前記コンピュータに、
前記第２の判断処理の処理結果を記憶し、
記憶した処理結果に基づき、所定のグルーピング処理を分割して複数のグルーピング処理とする、
処理を実行させることを特徴とする、付記１５又は付記１６記載の分析プログラム。

（付記２０）
前記第２の判断処理において、
異常と判断された処理がグルーピング処理である場合、異常と判断された処理がグルーピング処理でなくなるまで、段階的に前記異常と判断された処理をさらに下位の階層の一以上の処理に展開して、展開した一以上の処理について異常の有無を判断する、
ことを特徴とする、付記１５〜１９のいずれか１項記載の分析プログラム。

（付記２１）
前記コンピュータに、
複数のサービスに関する前記ログデータに基づき、各サービスの状態に正常及び異常の状態が混在しない時間区間を取得する、
処理を実行させ、
前記第１の判断処理において、
取得した時間区間に実行された一以上のサービスに含まれる処理について、異常の有無を判断する、
ことを特徴とする、付記１５〜２０のいずれか１項記載の分析プログラム。

１ ネットワークシステム
１Ａ 事前分析フェーズ
１Ｂ 運用フェーズ
１０ ネットワーク
２０ サーバ
３０ Ｗｅｂサーバ
４０ ＡＰ（アプリケーション）サーバ
５０ ネットワークスイッチ（ＮＳ）
１００，２００ 分析装置
１１０，２１０ 処理部
１２０，２２０ 記憶部
１１１，２１１ ログ採取部
１１２ ログ加工部
１１３ 機能抽出部
１１４ サービス情報生成部
１２１ アクセスログ
１２２ 紐付け結果
１２３ ｃｉｄ対応表
１２４ ｃｉｄセット表
１２５ ｐｉｄ対応表
１２６ パス情報（第１の情報）
１２７ コンポーネント定義情報（第２の情報）
２１２ 機能選別部
２１３ データスライス分割部（取得部）
２１４ 問題個所特定部（第１判断部，第２判断部）
２２１ アクセスログ
４００ 通知画面
４０１ ラベル
４１０ 詳細表示画面
４１１ ボタン
ＵＲＬ１，ＵＲＬ２，ＵＲＬ３，ＵＲＬ４ サービス
ｃ１，ｃ２，ｃ３，ｃ４，ｃ５ モジュール
ｐ１，ｐ２，ｐ３，ｐ４，ｐ５ コンポーネント
ｐ２．１，ｐ２．２，ｐ２．ａ，ｐ２．ｂ コンポーネント
ｐ３．１，ｐ３．２，ｐ３．３，ｐ３．ａ，ｐ３．ｂ コンポーネント

Claims (8)

1. 複数の階層を持つモジュールを複数含む複数のサービスについて、前記の各サービスを構成するモジュールについて、前記の各モジュールの下位階層の処理単位が共通するモジュールをグルーピングしたコンポーネント定義情報と、サービスがどのグルーピングされたモジュールによって構成されているかを示すパス情報とをサービス情報として記憶し、
   前記複数のサービスに関するログデータ及び前記サービス情報に基づき、一以上のサービスに含まれるモジュールについて、異常の有無を判断する第１の判断処理を行ない、
   異常と判断されたモジュールがグルーピングされたグルーピングモジュールである場合、前記サービス情報に基づき、前記異常と判断されたグルーピングモジュールを前記グルーピングモジュールのトップレベルよりも下位の処理単位に展開して、展開した各モジュールのうち、異常であるモジュールが含み正常であるモジュールが含まない処理単位を異常と判断する第２の判断処理を行なう、
   ことを特徴とする、分析方法。
2. 複数の階層を持つモジュールを複数含む複数のサービスについて、前記の各サービスを構成するモジュールについて、前記の各モジュールの下位階層の処理単位が共通するモジュールを少なくとも１つ共通するモジュールとして相互に含む複数のグルーピングモジュールを定義するコンポーネント定義情報と、サービスがどのグルーピングされたモジュールによって構成されているかを示すパス情報とをサービス情報として記憶し、
   前記複数のサービスに関するログデータ及び前記サービス情報に基づき、一以上のサービスに含まれるモジュールについて、異常の有無を判断する第１の判断処理を行ない、
   異常と判断されたモジュールがグルーピングされたグルーピングモジュールである場合、前記サービス情報に基づき、前記異常と判断されたグルーピングモジュールを含む複数のグルーピングモジュールについて、異常であるグルーピングモジュールが含み正常であるグルーピングモジュールが含まないモジュールを異常と判断する第２の判断処理を行なう、
   ことを特徴とする、分析方法。
3. 前記第２の判断処理において、
   異常と判断されたモジュールがグルーピングモジュールである場合、異常と判断されたモジュールがグルーピングモジュールでなくなるまで、段階的に前記異常と判断されたモジュールをさらに下位の階層の一以上のモジュールに展開して、展開した一以上のモジュールについて異常の有無を判断する、
   ことを特徴とする、請求項２に記載の分析方法。
4. 複数のサービスに関する前記ログデータに基づき、各サービスにおいて正常状態及び異常状態が混在しない時間区間を取得し、
   前記第１の判断処理において、
   取得した時間区間に実行された一以上のサービスに含まれるモジュールについて、異常の有無を判断する、
   ことを特徴とする、請求項１〜３のいずれか１項記載の分析方法。
5. 複数の階層を持つモジュールを複数含む複数のサービスについて、前記の各サービスを構成するモジュールについて、前記の各モジュールの下位階層の処理単位が共通するモジュールをグルーピングしたコンポーネント定義情報と、サービスがどのグルーピングされたモジュールによって構成されているかを示すパス情報とをサービス情報として記憶する記憶部と、
   前記複数のサービスに関するログデータ及び前記サービス情報に基づき、一以上のサービスに含まれるモジュールについて、異常の有無を判断する第１の判断処理を行なう第１判断部と、
   異常と判断されたモジュールがグルーピングされたグルーピングモジュールである場合、前記サービス情報に基づき、前記異常と判断されたグルーピングモジュールを前記グルーピングモジュールのトップレベルよりも下位の処理単位に展開して、展開した各モジュールのうち、異常であるモジュールが含み正常であるモジュールが含まない処理単位を異常と判断する第２の判断処理を行なう第２判断部と、をそなえる、
   ことを特徴とする、分析装置。
6. 複数の階層を持つモジュールを複数含む複数のサービスについて、前記の各サービスを構成するモジュールについて、前記の各モジュールの下位階層の処理単位が共通するモジュールを少なくとも１つ共通するモジュールとして相互に含む複数のグルーピングモジュールを定義するコンポーネント定義情報と、サービスがどのグルーピングされたモジュールによって構成されているかを示すパス情報とをサービス情報として記憶する記憶部と、
   前記複数のサービスに関するログデータ及び前記サービス情報に基づき、一以上のサービスに含まれるモジュールについて、異常の有無を判断する第１の判断処理を行なう第１判断部と、
   異常と判断されたモジュールがグルーピングされたグルーピングモジュールである場合、前記サービス情報に基づき、前記異常と判断されたグルーピングモジュールを含む複数のグルーピングモジュールについて、異常であるグルーピングモジュールが含み正常であるグルーピングモジュールが含まないモジュールを異常と判断する第２の判断処理を行なう第２判断部と、をそなえる、
   ことを特徴とする、分析装置。
7. コンピュータに、
   複数の階層を持つモジュールを複数含む複数のサービスについて、前記の各サービスを構成するモジュールについて、前記の各モジュールの下位階層の処理単位が共通するモジュールをグルーピングしたコンポーネント定義情報と、サービスがどのグルーピングされたモジュールによって構成されているかを示すパス情報とをサービス情報として記憶し、
   前記複数のサービスに関するログデータ及び前記サービス情報に基づき、一以上のサービスに含まれるモジュールについて、異常の有無を判断する第１の判断処理を行ない、
   異常と判断されたモジュールがグルーピングされたグルーピングモジュールである場合、前記サービス情報に基づき、前記異常と判断されたグルーピングモジュールを前記グルーピングモジュールのトップレベルよりも下位の処理単位に展開して、展開した各モジュールのうち、異常であるモジュールが含み正常であるモジュールが含まない処理単位を異常と判断する第２の判断処理を行なう、
   処理を実行させることを特徴とする、分析プログラム。
8. コンピュータに、
   複数の階層を持つモジュールを複数含む複数のサービスについて、前記の各サービスを構成するモジュールについて、前記の各モジュールの下位階層の処理単位が共通するモジュールを少なくとも１つ共通するモジュールとして相互に含む複数のグルーピングモジュールを定義するコンポーネント定義情報と、サービスがどのグルーピングされたモジュールによって構成されているかを示すパス情報とをサービス情報として記憶し、
   前記複数のサービスに関するログデータ及び前記サービス情報に基づき、一以上のサービスに含まれるモジュールについて、異常の有無を判断する第１の判断処理を行ない、
   異常と判断されたモジュールがグルーピングされたグルーピングモジュールである場合、前記サービス情報に基づき、前記異常と判断されたグルーピングモジュールを含む複数のグルーピングモジュールについて、異常であるグルーピングモジュールが含み正常であるグルーピングモジュールが含まないモジュールを異常と判断する第２の判断処理を行なう、
   処理を実行させることを特徴とする、分析プログラム。

Images