JP6568033B2 - 異常検出のための方法及びシステム - Google Patents

Description

この開示は、一般に、異常検出に関し、特に、アプリケーションランタイムにおける異常を検出するためのシステム及び方法に関する。

［優先権主張］
この特許出願は、２０１６年３月１７日に出願された特許文献１に対する優先権を主張する。前述の特許文献１の内容全体は、参照によって本明細書に組み込まれる。

異常又は例外は、アプリケーションの開発及び／又はテスト段階の間に報告されるかもしれない。間違ったコール、無効なパラメータ、ゼロで割るエラー、モジュールに入る間違ったフローなどのようなプログラミング論理例外が、プリケーションにおいて起こるかもしれない。幾つかの背景異常又は例外は、気付かれないまま進行するが、その理由として、それらの異常又は例外は、アプリケーションに対する直接のインパクトを、ほとんど持たない、又は全く持たないからである。しかし、もしそのような例外が修正されない場合、アプリケーションが生産環境において展開される時、それらの例外は、より大きなやり方で現れるかもしれない。

更にアプリケーションの開発の間、開発者は、追跡目的のためにログファイルに異常を記録して、更なる解析を可能にしようとする傾向がある。しかしながら、大きなアプリケーションについては、ログサイズは巨大であり、且つ記録された例外の幾つかは見落とされるような状況があるかもしれない。その上、開発者は、幾つかの異常を記録するのを忘れるかもしれず、このことは、そのような異常を識別することを困難にする。そのような例外又は異常は気付かれないまま進行し、そして破滅的な状況につながるかもしれない。

インド特許出願第２０１６２１００９３４０号

ここで発明者は、そのような従来のシステムに関する幾つかの技術的問題を認識している。幾つかの問題とは、以下に説明する通りである。アプリケーションに存在する数多くのモジュールから出て、多くのものは、代替的フローに入る可能性があるかもしれない。これらの幾つかは、アプリケーションの必要性のためかもしれず、その結果として、幾つかの機能性は適切に実施される。しかし、これらの多くは、コーディング又は論理における幾つかの問題のためでもある。しばしば、このことは、これらのモジュールの不完全な実行により、誤った結果をもたらす。そのような論理を修正することによって、アプリケーションを適切に走行させることが可能になるかもしれない。

本開示の実施形態は、従来のシステムにおける、発明者らによって認識された、上記の技術的な問題の１つ以上に対する解決策として、技術的改善を提示する。例えば、一実施形態において、異常検出のための、プロセッサにより履行される方法が提供される。本方法は、アプリケーションに関連付けられた少なくとも１つのスレッドを、１つ以上のハードウェアプロセッサを介して、実行するステップを含む。少なくとも１つのスレッドを実効するステップは、少なくとも１つのスレッドに関連付けられた１つ以上の方法を呼び出すことに帰着する。更に、本方法は、実行の間に、１つ以上のハードウェアプロセッサを介して、１つ以上の方法に関連付けられたメトリクスを捕捉するステップを含む。更には、本方法は、１つ以上のハードウェアプロセッサを介して、メトリクスを系統的に配列するステップを含むが、ここでのメトリクスは、複数のスレッド−方法対を表すためのデータ構造におけるメトリクス、及び複数のスレッド−方法対の各々に対応するメトリクスである。その上、本方法は、データ構造から、且つ１つ以上のハードウェアプロセッサを介して、１つ以上の異常を識別するステップを含むが、ここで１つ以上の異常とは、データ構造における、少なくとも１つの予め決められた条件の検出に基づいて、１つ以上の方法に関連付けられた異常である。１つ以上の異常の中の１つの異常は、非退出異常、例外異常、及びユーザにより定義される異常の１つを含む。

別の実施形態において、アプリケーションにおける異常検出のためのシステムが提供される。本システムは、少なくとも１つのメモリと、１つ以上のハードウェアプロセッサとを含む。少なくとも１つのメモリは、少なくとも１つのハードウェアプロセッサに結合され、且つ１つ以上のハードウェアプロセッサは、プログラムされた命令を実行することが可能であるが、ここでプログラムされた命令は、アプリケーションに関連付けられた少なくとも１つのスレッドを実行するために、少なくとも１つのメモリに格納される。少なくとも１つのスレッドを実行するステップは、少なくとも１つのスレッドに関連付けられた１つ以上の方法を呼び出すことに帰着する。更に、１つ以上のハードウェアプロセッサは、１つ以上の方法に関連付けられたメトリクスを、実行の間に捕捉するための、プログラムされた命令を実行することが可能である。更には、１つ以上のハードウェアプロセッサは、メトリクスを系統的に配列するためのプログラムされた命令を実行することが可能であるが、ここでのメトリクスは、複数のスレッド−方法対を表すためのデータ構造におけるメトリクス、及び複数のスレッド−方法対の各々に対応するメトリクスである。その上、１つ以上のハードウェアプロセッサは、１つ以上の異常を、データ構造から識別するための、プログラムされた命令を実行することが可能であるが、ここで１つ以上の異常とは、データ構造における、少なくとも１つの予め決められた条件の検出に基づいて、１つ以上の方法に関連付けられた異常である。１つ以上の異常の中の１つの異常は、非退出異常、例外異常、及びユーザにより定義される異常の１つを備える。

更に別の実施形態において、非一時的なコンピュータ可読媒体は、異常検出用の方法を実行するためのコンピュータプログラムを、自身の上に具現化している。本方法は、アプリケーションに関連付けられた、少なくとも１つのスレッドを実行するステップを含む。少なくとも１つのスレッドを実行するステップは、少なくとも１つのスレッドに関連付けられた１つ以上の方法を呼び出すことに帰着する。更に、本方法は、１つ以上の方法に関連付けられたメトリクスを、実行の間に捕捉するステップを含む。更には、本方法は、メトリクスを系統的に配列するステップを含むが、ここでのメトリクスは、複数のスレッド−方法対を表すためのデータ構造におけるメトリクス、及び複数のスレッド−方法対の各々に対応するメトリクスである。その上、本方法は、データ構造から、１つ以上の異常を識別するステップを含むが、ここで１つ以上の異常とは、データ構造における、少なくとも１つの予め決められた条件の検出に基づいて、１つ以上の方法に関連付けられた異常である。１つ以上の異常の中の１つの異常は、非退出異常、例外異常、及びユーザにより定義される異常の１つを含む。

理解するべきことであるが、前述の一般的な説明及び次の詳細な説明の両方は、単に典型的且つ説明的なものであり、且つ請求されているように、本発明を制限するものではない。

添付図面（これらの図面は、この開示の一部分に組み込まれ、且つこの開示の一部分を構成する）は、典型的な実施形態を例示し、且つ、説明と共に、開示された原理を説明することに役立つ。

本開示の幾つかの実施形態に従う、アプリケーションの走行中に遭遇する異常を検出するためのネットワーク履行例を示す図である。 本開示の幾つかの実施形態に従う、アプリケーションにおける異常を検出するためのシステムの機能的ブロック図である。 本開示の幾つかの実施形態に従う、アプリケーションにおいて遭遇する異常を検出するための機能的フローの表現例を示す図である。 本開示の幾つかの実施形態に従う、アプリケーションの走行中に遭遇する異常を検出する目的で捕捉されたメトリクスを格納するための、多レベルデータ構造のアーキテクチャ例を示す図である。 本開示の幾つかの実施形態に従う、アプリケーションの走行中に遭遇する異常を検出するための方法を示すフロー図である。

添付図を参照しながら、典型的な実施形態を説明する。図の中で、参照符号の最も左の数字は、その参照符号が最初に現れる図を識別する。どこであっても便利なことに、同じ部分又は同様な部分を参照するために、同じ参照符号が図面を通して使用される。本明細書では開示された原理の例及び特徴が説明されるが、開示された実施形態の趣旨及び範囲から外れなければ、変更例、改造例、及び他の履行例が可能である。以下の詳細な説明は単に典型的なものと考えられ、真の範囲及び趣旨は以下の請求項によって示される、ということが意図されている。

本開示は、アプリケーションの走行中に遭遇する異常を検出するためのシステム及び方法に関する。本開示を参照すると、「アプリケーション」は、「アプリケーションソフトウェア」を含んでもよく、この「アプリケーションソフトウェア」は、機能性の１つ以上の単位（例えば、電子メール機能性、データベースプログラム、文書処理プログラム、勘定プログラム、数値解析プログラムに関するウェブポータル）を包含するかもしれない。「アプリケーション」はまた、「サービス」を含んでもよく、この「サービス」は、機能性の一論理単位（例えば、データベース管理サービス又はデータベース・アプリケーション・プログラミングインターフェース（ＡＰＩ）サービスのようなデータの変換、格納及び／又は回復を担当する自律的な単位）を包含してもよい。アプリケーションに関連付けられたサービスは、アプリケーションによって提供される処理又はユースケースに関連付けられた、様々なプログラムに関係してもよい。例えば、オンラインチケット予約アプリケーションは、アプリケーションへのログイン、チケットの入手可能性のための検索、オンライン支払、ホテル予約、車予約などのような、様々な処理又はユースケースのためのプログラムを含んでもよい。幾つかの実施形態において、アプリケーションは、スタンドアロンのＪａｖａＴＭアプリケーションであり得る。幾つかの実施形態において、アプリケーションは、複数のリソースを利用できる複合の企業アプリケーションであり得る。幾つかの実施形態において、アプリケーションは、複数の階層に分散された分散型アプリケーションであってもよい。前記複数の階層は、ウェブインターフェース、データベース構成要素、及びアプリケーションインターフェースを含んでもよい。

あるシナリオにおいて、アプリケーションは、アプリケーションの背景で起こっている、異なる誤った条件にもかかわらず、的確に振舞う傾向があるかもしれない。例えば、アプリケーションの開発又はテスト段階の間、幾つかの背景エラー又は例外は、気付かれずに進行するかもしれないが、その理由は、そのようなエラーが、アプリケーションに対する直接のインパクトを、ほとんど持たない、又は全く持たないことによる。アプリケーションの正常なフローからの任意のずれは、「例外異常」と呼んでもよいが、ここで正常なフローからの任意のずれは、アプリケーションが希望通りに働くことを妨げ、且つアプリケーションの正常性を妨害するような、誤った状況がもたらされた結果である。もしアプリケーションの中で例外異常が修正されない場合、アプリケーションが生産環境において展開される時、それらの例外異常は、より大きなやり方で現れるかもしれない。

また、アプリケーション開発の間、開発者はエラーを記録する傾向があるが、このことは、アプリケーションコードで起こる問題を見つけるのに役立つ可能性がある。これらのエラーは記録してもよいが、しかし前記エラーは見落とされるかもしれず、又は気付かれないままとなるかもしれず、この理由は、アプリケーションを実行する間に生成されるアプリケーションログのサイズが巨大なためである。アプリケーションログのサイズが巨大であるために、続いて起こる解析及びログの修正は、時間がかかるものとなるかもしれない。しかしながら、エラーを見落とすことは、アプリケーションの性能に対して壊滅的な効果を持つかもしれない。

他のあるシナリオにおいて、アプリケーションにおける様々なモジュールは、代替的フロー又は誤ったフローを経験する、又は代替的フロー又は誤ったフローに入るかもしれない。代替的フロー又は誤ったフローの幾つかは、アプリケーションの必要性のために起こり、その結果として、特定の機能性は適切に実施される。しかし、多くの代替的フロー又は誤ったフローはまた、コーディング又は論理における幾つかの問題のためである。しばしば、そのような代替的フロー又は誤ったフローは、誤った結果をもたらすかもしれず、その理由は、前記モジュールに関連付けられた、論理の不完全な実行のためである。しかしながら、そのようなエラーは、もしチェックされない場合、前記モジュールの不完全な実行に帰着するかもしれない。代替的フローの例は、オンラインチケットを予約する際のユーザであり得る。もし勘定が十分にバランスしていない場合、チケット予約はうまくいかないであろう。そして妨害された席が、他のユーザに対して同時に発売されるであろう。ここで、勘定バランスが十分でない場合、明らかなエラーは、予約を停止するための代替的フローを誘発し、且つチケットを発売する。この場合、意図された代替的フローは、チケットを発売することである。

加えて、あるシナリオにおいて、非退出異常として知られる別の異常は、アプリケーションの不適切な機能につながるかもしれない。ある方法は、無限ループの中で、ある機能性を実施するかもしれず、このことは、そのために、ループを走行させる方法が非退出方法であることを意味する。しかしながら、もしループが意図されないループである場合、その時は、そのような方法は、非退出異常につながるかもしれない。例えば、幾つかのシナリオにおいて、行き詰まりが形成されるかもしれない。その行き詰まりでは、２つ以上のスレッド又はプログラムが、１つ以上のリソースにアクセスすることを試みるかもしれず、その一方で、他のスレッド又はプログラムに対して要求される１つ以上のリソースをロックする。そのような場合、１つ以上のリソースにアクセスするためのループは、無限ループかもしれず、このことは、そのために、意図されない非退出異常につながる。

不完全な実行、気付かれないログエラーなどのような、アプリケーション実行に関連付けられたエラー又は異常は、累積するかもしれず、そして後に、アプリケーション故障につながるかもしれない。そのような論理を修正することは、アプリケーションの適切な実行のために重要かもしれない。

開示された実施形態は、アプリケーションの実行中に遭遇する異常を検出するための、様々な方法及びシステムを提供する。例えば、一実施形態において、異常検出のためのシステムが提供されるが、その目的は、アプリケーションの走行中に遭遇する例外的エラー及び誤った代替的フローのような異常を捕捉し、且つ前記異常を提示することである。その結果として、異常に対して訂正動作が取られ、且つアプリケーションの正常性を回復することが可能となる。

図１を参照すると、アプリケーションの走行中に遭遇する異常を検出するためのネットワーク履行例１００が、本主題の実施形態に従って例示されている。ネットワーク履行例１００は、システム１０２、装置１０４−１、１０４−２・・・１０４−Ｎのような装置、及びシステム１０２と装置１０４−１、１０４−２・・・１０４−Ｎとの間の通信を容易にするための通信ネットワーク１０６を含むように示されている。一実施形態において、システム１０２は、アプリケーションの走行中に遭遇する異常を解析するための、共通プラットフォームを容易にする。

本主題は、システム１０２が単一装置として履行されることを考慮しながら説明されているが、次のように理解してもよい。即ち、システム１０２は、ラップトップコンピュータ、デスクトップコンピュータ、ノートブックコンピュータ、ワークステーション、メインフレームコンピュータ、ネットワークサーバ、タブレット、携帯電話、ロボットなどのような、様々なコンピューティングシステムとして履行してもよい、ということである。一実施形態において、アプリケーションは、アプリケーションが複数の階層に分散されるような、分散型アプリケーションであり得る。複数の階層のアプリケーションは、ウェブインターフェース、データベース構成要素、及びアプリケーションインターフェースを含んでもよい。理解されることであろうが、分散型アプリケーションに対しては、複数の階層が異なったノードにわたって分散され、且つ開示されたシステム１０２は、それぞれの分散されたノードからメトリクスを収集するために、前記異なったノードの中に具現化してもよい。

理解されることであろうが、システム１０２は、１つ以上の装置１０４−１、１０４−２・・・１０４−Ｎ（以降は、集団的に装置１０４と呼ぶ）を通して、複数のユーザによってアクセスされるかもしれない、又はアプリケーションは装置１０４に常駐している。装置１０４の例は、以下に限定されるものではないが、携帯型コンピュータ、携帯情報端末、携帯用装置、及びワークステーションを含んでもよい。アプリケーションセッションを走行させるために、ユーザ装置１０４は、サーバ１０８と共に、対応するセッションを確立することが可能である。

一実施形態において、各装置１０４は、サーバ１０８と通信するために、サーバ１０８と共にセッションを確立することが可能である。装置１０４は、通信ネットワーク１０６を通して、サーバ１０８と通信することが可能である。通信ネットワーク１０６は、無線ネットワーク、有線ネットワーク、又はこれらの組み合わせであってもよい。通信ネットワーク１０６は、イントラネット、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、インターネットなどのような、異なったタイプのネットワークの１つとして履行することが可能である。通信ネットワーク１０６は、専用ネットワーク又は共有ネットワークのいずれかであってもよい。共有ネットワークは、異なったタイプのネットワークの連合を表し、ここで異なったタイプのネットワークは、互いに対して通信するために、様々なプロトコルを使用するが、それらは、例えば、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）、無線アプリケーションプロトコル（ＷＡＰ）などである。更に、ネットワーク１０６は、ルータ、ブリッジ、サーバ、コンピューティング装置、記憶装置などを含めて、様々なネットワーク装置を含んでもよい。

アプリケーションの走行中に遭遇する異常を検出することは、全てのメトリクスを捕捉することによって実行できるが、ここで全てのメトリクスは、アプリケーションに関連付けられた１つのスレッドに関連付けられた１つ以上の方法に関連付けられる。幾つかの実施形態において、ユーザは、装置（又はクライアント）１０４を用いて、サーバ１０８上で走行するアプリケーションに対して異常の検出を開始することが可能である。別の実施形態において、異常の検出は、周期的なやり方で自動的に開始することが可能である。

クライアント、例えば装置１０４は、異常を捕捉するために、サーバ１０８と共に、監視セッションを確立することが可能である。監視セッションの間、アプリケーションは、様々なスレッド及び関連する方法の系統的な実行に関して、制御された環境の中で監視されるが、ここで様々なスレッド及び関連する方法は、サーバ１０８上のＪａｖａ仮想マシン（ＪＶＭ）上で走行するアプリケーションに関連付けられる。

ランタイム環境においてアプリケーションを系統的に実行する間、様々なメトリクスが生成されるかもしれない。一実施形態において、システム１０２は、前記メトリクスを捕捉する。サーバ１０８上で具現化されたシステム１０２は、メトリクスを記録すると共に格納することが可能であるが、ここでのメトリクスは、クライアント１０４から監視セッションを走行させる解析のために、様々なスレッドに関連付けられた様々な方法に関連付けられる。幾つかの実施形態において、メトリクスは、サーバ１０８上のメモリに格納することが可能である。代わりに、メトリクスは、システム１０２のメモリに格納することが可能である。一実施形態において、アプリケーションが分散型アプリケーションである場合、メトリクスは、それぞれの複数の階層／ノードに格納することが可能であり、且つ解析のために、システム１０２によって収集することが可能である。

幾つかの実施形態において、システム１０２は、解析のために、メトリクスをクライアント１０４に送信してもよい。クライアント１０４は、メトリクスを表示することが可能であるが、このメトリクスは、装置１０４上に表示されたグラフィカル・ユーザ・インターフェース（ＧＵＩ）におけるＪＶＭ上で走行するアプリケーションに対して記録されたものである。異常メトリクスの収集は、ユーザにより誘発される、又は自動構成される、のいずれかであり得る。アプリケーションに関連付けられた異常を検出するためのシステム例は、図２を参照しながら更に説明する。

ここで、図２から図３を参照すると、図２は実施例に従う、アプリケーションにおける異常を検出するためのシステム２００のブロック図を例示する。システム２００は、図１のシステム１０２の例である。一実施例において、システム２００は、コンピューティング装置において具現化することが可能である。代わりに、システム２００は、サーバにおいて具現化することが可能である（例えば、図１のサーバ１０８）。一実施形態において、アプリケーションが複数の階層／ノードに分散されている場合、システムは、前記複数の階層／ノードにおいて分散的に具現化することが可能である。一実施形態において、システム２００は、異常捕捉セッションの間に生成されたメトリクスの解析に基づいて、アプリケーションの走行中に遭遇する異常の検出を容易にする。本明細書で注意することであろうが、異常検出セッションは監視セッションを含んでもよく、この監視セッションの間に、捕捉されたメトリクスに基づいて、アプリケーションの振舞いを解析して、異常を検出してもよい。この故に、「異常検出セッション」及び監視セッションという用語は、説明を通して、交換可能に使用してもよい。システム２００は、プロセッサ２０２のような少なくとも１つのプロセッサ、メモリ２０４のような少なくとも１つのメモリ、及びユーザインターフェース２０６を含む、又は、そうでなければ、これらと通信状態にある。一実施形態において、プロセッサ２０２、メモリ２０４、及びユーザインターフェース２０６は、システムバス２０８のようなシステムバス又は同様な機構によって結合してもよい。

プロセッサ２０２は、とりわけ、異常検出に関連付けられた論理機能を履行する回路構成を含んでもよい。例えば、プロセッサ２０２は、以下に限定されるものではないが、１つ以上のデジタル信号プロセッサ（ＤＳＰ）、１つ以上のマイクロプロセッサ、１つ以上の特殊用途コンピュータチップ、１つ以上のフィールドプログラマブル・ゲート・アレイ（ＦＰＧＡ）、１つ以上の特定用途向け集積回路（ＡＳＩＣ）、１つ以上のコンピュータ、様々なアナログからデジタルへの変換器、デジタルからアナログへの変換器、及び／又は他の支援回路を含んでもよい。プロセッサ２０２はまた、従って、メッセージ及び／又は、データ若しくは情報を符号化するための機能性を含んでもよい。プロセッサ２０２は、とりわけ、プロセッサ２０２の動作を支援するように構成されたクロック、演算論理回路（ＡＬＵ）及び論理ゲートを含んでもよい。更に、プロセッサ２０２は、１つ以上のソフトウェアプログラムを実行するための機能性を含んでもよく、ここで１つ以上のソフトウェアプログラムは、メモリ２０４に格納してもよく、又は、そうでなければ、プロセッサ２０２にアクセス可能であってもよい。

メモリ２０４のような少なくとも１つのメモリは、システムの機能を履行するためにシステムによって使用される、複数の情報又はデータを格納してもよい。例えば、一実施例において、メモリ２０４は、アプリケーションの監視セッションの間に生成されるメトリクスを格納するように構成される。一実施形態において、アプリケーションの監視は、システム２００のユーザインターフェースから実施することが可能である。例えば、ユーザは、システム（又は、図１の装置１０４のようなクライアント装置）のユーザインターフェースからアプリケーション監視を開始することが可能である。メモリ２０４は、例えば、揮発性メモリ及び／又は不揮発性メモリを含んでもよい。揮発性メモリは、揮発性ランダムアクセスメモリ（ＲＡＭ）を含んでもよいが、しかしこれに限定されない。不揮発性メモリは、加えて又は代わりに、電気的に消去可能でプログラム可能な読み出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリ、ハードドライブなどを備えてもよい。揮発性メモリの幾つかの例は、以下に限定されるものではないが、ランダムアクセスメモリ、ダイナミック・ランダムアクセスメモリ、スタティック・ランダムアクセスメモリなどを含む。非不揮発性メモリの幾つかの例は、以下に限定されるものではないが、ハードディスク、磁気テープ、光ディスク、プログラム可能な読み出し専用メモリ、消去可能でプログラム可能な読み出し専用メモリ、電気的に消去可能でプログラム可能な読み出し専用メモリ、フラッシュメモリなどを含む。メモリ２０４は、情報、データを格納するように構成してもよいが、ここでこれらの情報、データは、様々な実施例に従って様々な機能を実行すること目的として、異常解析のための異常、アプリケーション、命令などを捕捉することに関連する。加えて又は代わりに、メモリ２０４は、命令を格納するように構成してもよく、ここで命令は、プロセッサ２０２によって実行される場合、システム２００に、様々な実施形態において説明されたようなやり方で振舞わせる。

一実施形態において、システム２００に、アプリケーションの実行を開始させる。例えば、システム２００に、ユーザ入力に基づいて、監視セッションにおいてアプリケーションの実行を開始させてもよい。本明細書では、アプリケーションを実行することは、アプリケーションに関連付けられた少なくとも１つのスレッドを実行することを指してもよい。少なくとも１つのスレッドを実行することは、少なくとも１つのスレッドに関連付けられた、１つ以上の方法を呼び出すことに帰着する。システム２００に、監視セッションの間、１つ以上の方法に関連付けられたメトリクスを捕捉するようにさせてもよい。一実施形態において、方法に関連付けられたメトリクスは、方法名、方法呼び出しタイムスタンプ、方法退出タイムスタンプ、方法スタックトレース、例外名、例外原因、及び例外タイムスタンプを含んでもよい。

一実施形態において、システム２００は異常記録器モジュールを含んでもよく、ここで異常記録器モジュールは、スレッドに関係付けられた１つ以上の方法を捕捉するための走行アプリケーションと統合してもよい。異常記録器モジュールは、プロセッサ２０２によって構成してもよく、且つ構成部品であってもよいが、この構成部品は、エージェントとして働き、アプリケーションから関連するメトリクスを収集し、且つ目メトリクスをデータ格納庫（例えば、メモリ２０４）へ保存する。一実施形態において、異常記録器モジュールは、アプリケーションに添付されると共に、更に二進数実行論理をアプリケーションに注入することが可能であり、それによって、アプリケーションを実行する間に、スレッドの方法に関連付けられた１つ以上のメトリクスを捕捉する。例えば、Ｊａｖａ（ＴＭ）に基づくアプリケーションに対して、異常記録器モジュールは、それ自体をアプリケーションに埋め込むためのバイトコード計装（ＢＣＩ)技術を使用することが可能である。ＢＣＩを使用して、サンプルのＪａｖａ（ＴＭ）アプリケーションは変換され、要求通りにメトリクスを収集する。一実施形態において、システム２００に、アプリケーションのクラス及び二進数を変換させるが、これは、異常記録器モジュールが、異常を捕捉するのに要求される関連データ（又はメトリクス）を収集することを可能にするためである。例えば、アプリケーションが開始される場合、監視セッションを開始するために、信号を異常記録器モジュールに送信してもよい。一実施例において、信号は、ユーザ入力に基づいて送信してもよい。代わりに、信号は、幾つかの予め決められた基準に基づいて、自動的に送信してもよい。例えば、監視セッションは、アプリケーションの始動と共に開始してもよい。代わりに、監視セッションは、サンプリングによって開始してもよい（例えば、どの１時間に対しても最初の１０分間監視する、若しくは１時間ごとに交替で監視する、又は、ＣＰＵ使用度が非常に高い又は低い場合にのみ監視する、など）。本明細書で注意することであろうが、監視セッションを選択するために予め決められた基準は、本明細書で定義された基準に限定されず、且つ前記基準は、様々なシナリオに拡張することが可能である。

一実施形態において、アプリケーションが開始される場合、クラスは、ランタイム環境において、クラスローダによってロードされる。異常記録器モジュールは、例えばＢＣＩを使用して、アプリケーションクラスのバイトコードを変換する。ＢＣＩは、１つ以上のフィルタ処理規則に基づいて、ＪＶＭの中にロードされている新しいクラスと同様に、既にロードされたクラスを変換してもよい。一実施形態において、フィルタ処理規則は、カスタマイズ可能な規則であってもよく、例えば、規則は、変換されたクラスを得るために、ユーザ入力に基づいて定義してもよい。別の実施形態において、初期設定値（又は作り付けの規則）を、フィルタ処理規則として選択してもよい。一実施形態において、変換されたクラスは、非退出異常、例外的異常、及びユーザにより定義される異常のような異常を記録するための異常記録器モジュールに対して、メトリクス収集の１点として働いてもよい。

一実施形態において、システム２００に、メトリクスを系統的に配列させるが、ここでのメトリクスは、複数のスレッド−方法対を表すためのデータ構造におけるメトリクス、及び複数のスレッド−方法対の各々に対応するメトリクスである。一実施形態において、データ構造は、外部データ構造及び内部データ構造を有する、多レベルデータ構造であり得る。

一実施形態において、多レベルデータ構造の第１レベルは、一意的なスレッド識別子を鍵として含んでもよい。各スレッドは、複数の方法を呼んでもよく、且つ各方法は、複数の異常を経験してもよい。方法とスレッドとの間の対応例を、以下の表における例によって提供する。

表１に示すように、アプリケーションの実行は、スレッド１及びスレッド２のようなスレッドに帰着してもよい。各スレッドは、複数の方法を呼び出してもよい。例えば、スレッド１は、方法１及び方法２を呼び出してもよく、且つ、また、スレッド２は、方法３、方法４及び方法５を呼び出してもよい。スレッドに関連付けられた１つ以上の方法は、異常を経験してもよい。例えば、方法１は、異常１−１、異常１−２のような異常を経験してもよく、方法２は、異常２−１、異常２−２、異常２−３のような異常を経験してもよく、且つ方法３は、異常３−１のような異常を経験してもよい、などである。

一実施形態において、システム２００に、異常データを格納させるが、該異常データは、データ構造から、１つ以上の方法に関連付けられたメトリクスを有する。一実施形態において、メモリ２０４は、方法の中で識別された異常を格納するためのデータ格納庫を含む、又は、そうでなければ、これと通信状態にある。多レベルデータ構造の詳細な例は、図４を参照しながら更に説明する。

一実施形態において、システム２００に、データ構造から、１つ以上の異常を識別させてもよく、ここで１つ以上の異常とは、データ構造において、少なくとも１つの予め決められた条件を検出することに基づいて、１つ以上の方法に関連付けられたものである。一実施形態において、システム２００は異常解析器モジュールを含むが、この異常解析器モジュールは、メトリクスに基づいて、方法に関連付けられた異常を識別するためのものである。一実施形態において、メトリクスに関連付けられた、予め決められた条件は、異なったタイプの異常に対して、異なるかもしれない。例えば、方法の中で非退出異常を識別するための、予め決められた条件は、方法に対応するメトリクスにおいて、方法退出タイムスタンプの欠如を検出することを含んでもよい。従って、本実施形態では、記録されたメトリクスに基づいて、システム２００に、１つ以上の方法の中の１つの方法において非退出異常を識別させてもよく、ここでの識別は、方法に対応するメトリクスにおいて、方法退出タイムスタンプの欠如を検出することによる。一実施形態において、システム２００は、非退出異常を識別すると共に記録するための、非退出記録器（ＵＲ）モジュールを含んでもよい。ＵＲモジュール、及びＵＲモジュールによる非退出異常の識別は、図３を参照しながら更に詳細に説明する。

別の実施形態において、方法の中で例外異常を識別するための、予め決められた条件は、メトリクスにおける方法に対応する例外名、例外原因、及び例外タイムスタンプを検出することを含んでもよい。一実施形態において、システム２００は、アプリケーションにおける例外異常を識別するための、例外記録器（ＥＲ）モジュールを含んでもよい。一実施形態において、ＥＲモジュールは、メトリクスにおける方法に対応する例外名、例外原因、及び例外タイムスタンプの検出に基づいて、アプリケーションにおける例外異常を識別してもよい。ＥＲモジュール、及びＥＲモジュールによる例外異常の識別は、図３を参照しながら更に詳細に説明する。

更に別の実施形態において、システム２００に、アプリケーションにおける、ユーザにより定義される異常を識別させる。本実施形態では、方法における例外的異常及び非退出異常を捕捉することを目的として、ユーザにより定義される異常を識別するために、少なくとも１つの予め決められた条件が、ユーザによって定義される。例えば、ユーザは１つ以上の特定の方法を選択してもよく、その方法に対して、例外的異常は、含まれてもよい、又は除外されてもよい。一実施形態において、ユーザは、ＵＩ２０６を利用することによって、特定の方法を選択してもよい。例えば、「ユーザ方法」と呼ばれる方法は、ユーザにより定義される属性であってもよい。ここで、予め決められた条件が、「方法の中で起こる全ての例外的異常を捕捉すること」としてユーザによって定義される場合、異常記録器モジュールは、方法の中で起こる例外的異常を捕捉してもよい。代わりに、もしユーザにより定義される属性が、「方法の中で起こる例外的異常を除外すること、又は無視すること」のような予め決められた条件を含む場合、その時は、前記方法の中で起こる全ての例外的異常は、システム２００によって無視してもよい。

別の実施例において、予め定義された一組の例外以外に、アプリケーションの中で、あるカスタマイズされた例外を選択してもよい。一実施形態において、システム２００に、そのようなユーザにより定義される例外の（名前及びタイプのような）例外詳細を、パラメータとして受信させてもよい。一実施形態において、前記例外詳細は、システム２００の異常記録器モジュールに入力してもよい。一旦システム２００において前記例外が定義されると、異常記録器モジュールは、アプリケーションの中で起こるそのような例外的異常を捕捉してもよい。

あるシナリオにおいて、非退出方法は、アプリケーション論理に依存して、アプリケーションの適切な走行にとって必要かもしれない。例えば、その方法は、無限ループにおいて、ある機能性を実施しているかもしれず、このことは、そのために、ループを走行させる方法は非退出方法であり、且つ異常記録器によって報告されるかもしれないことを意味する。この場合、注意するべきことであるが、その方法は非退出方法であるが、しかし非退出異常ではなく、且つ、この故に、その方法は、例外として、異常記録器モジュールに提供されるべきである。本実施形態では、そのような方法名は、パラメータとしてシステムに提供され、その結果、もしその方法が非退出方法である場合さえも、異常記録器モジュールは、除外する／無視する。

一実施形態において、システム２００に、異常に関連付けられる、解析された異常データを表示させてもよい。一実施形態において、システム２００は、解析された異常データを表示するために、異常ビューアモジュールを含んでもよい。一実施形態において、メモリ２０４は、異常ビューアモジュールを含んでもよい、又は異常ビューアモジュールと通信状態にあってもよい。一実施形態において、システム２００は、システムのＵＩ２０６上に異常データを表示するように構成される。

上で議論したように、システム２００は、異常検出システムに関連付けられた様々な機能性を実施するために、異常ビューアモジュール、異常解析器モジュール、異常記録器モジュールのような様々なモジュール、及びメトリクスデータ庫を組み込んでもよい。前記モジュールは、システム２００のメモリ２０４に格納してもよく、又はシステム２００に通信可能に結合してもよい。プロセッサ２０２は、前記モジュールを実行するように構成される。モジュールを含む異常検出システム２００の機能的アーキテクチャの例は、図３を参照しながら更に説明する。

図３は、アプリケーション、例えば、実施例に従うアプリケーション３０２において遭遇する異常を検出するための、機能的フロー３００の表現例を例示する。機能的フローは、様々なブロック間のフローを含むように示されており、ここで様々なブロックは、アプリケーション３０２に関連付けられた構成データ３０４、データ格納庫３０６、異常解析器モジュール３０８、異常ビューアモジュール３１０、及び異常記録器モジュール３１２を含む。前記ブロックは、アプリケーションの異常を検出するためのシステムを集合的に構成し、且つシステム２００の中に埋め込むことが可能である（図２）。

ここでのアプリケーション３０２は、対象アプリケーションを表し、ここで対象アプリケーションは、ウェブアプリケーション又はシッククライアント・アプリケーションであってもよい。あるシナリオにおいて、アプリケーション３０２を走行させること（又はアプリケーション３０２のスレッドを実行すること）によって、１つ以上のエラー又は異常に遭遇するかもしれない。特に、スレッドを実行することは、前記スレッドに関連付けられた方法に関与し、且つあるシナリオにおいて、該方法は、異常に関連付けられるかもしれない。そのような異常の例は、図１及び図２を参照しながら説明したように、非退出異常、例外異常、及びユーザにより定義される異常などを含んでもよい。プロセスフロー３００は、アプリケーション３０２における前記異常の検出を容易にするかもしれない。異常記録器モジュール３１２は、アプリケーション３０２と共に添付されるかもしれない、プロファイラ・エージェントであってもよい。一実施形態において、異常記録器３１２は、アプリケーション３０２に関連付けられた異常を捕捉し、且つアプリケーションに関連付けられた（メトリクスのような）関連データを周期的に収集するように構成される。一実施形態において、異常記録器モジュール３１２は、アプリケーション始動時に開始し、且つアプリケーションの実行の初めからデータを捕捉させてもよい。代わりに、異常記録器モジュール３１２は、アプリケーション３０２の走行中の任意の点で呼び出してもよい。異常記録器モジュール３１２は、走行しているアプリケーションに自身を添付することが可能であり、且つメトリクスの捕捉を開始するかもしれず、それによって、再起動無しに、連続してアプリケーションを走行させることが可能である。本明細書で、注意することであろうが、異常記録器モジュール３１２は、代替的フロー又は異常フローに関する全てのプロセスを捕捉するための、特別な能力を作り付けで備えており、従って、前記フロー又はエラーが気付かれないまま進行し、且つアプリケーションの実行の間に問題を引き起こすことを防止する。

構成データ３０４は、メトリクスを捕捉することに関するデータを含む。例えば、構成データ３０４は、メトリクスにおいてどんなデータが捕捉されるべきか、いつデータが捕捉されなければばらないか、などのような情報を含んでもよい。一実施形態において、構成データ３０４は、ユーザによって提供してもよく、且つアプリケーションの走行において遭遇する異常を捕捉するための、異常捕捉セッションを開始する以前に格納してもよい。一実施例において、初期設定の自動生成標準構成を、メトリクスを捕捉するために使用してもよい。例えば、Ｓｔｒｕｔｓフレームワークを有する標準Ｊ２ＥＥ（Ｊａｖａ ２ Ｐｌａｔｆｏｒｍ Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ）アプリケーションに対しては、そのフレームワークに関連する標準構成をロードすることが可能である。バックエンドのＪａｖａバッチアプリケーションに対しては、バッチプログラムに関連する構成をロードすることが可能である。

異常記録器モジュール３１２は、データ格納庫３０６においてメトリクスを捕捉する。例えば、メトリクスデータ格納庫３０６は、方法に関連付けられた方法名、方法呼び出しタイムスタンプ、方法退出タイムスタンプ、方法スタックトレース、例外名、例外原因、及び例外タイムスタンプを格納することが可能である。一実施形態において、メトリクスは、多レベルデータ構造の形態で、系統的に格納してもよい。

一実施例において、異常記録器モジュール３１２は、非退出異常記録器（ＵＲ）モジュール３１４及び例外的異常記録器（ＥＲ）モジュール３１６を含んでもよい。ＵＲモジュール３１４は、ＢＣＩを使用して、非退出異常を記録すること／捕捉することが可能である。一実施形態において、あらゆる方法の呼び出しに関して、ＵＲモジュール３１４は、スレッドＩＤ及び方法名を記録し、且つ呼び出しタイムスタンプをデータ構造に挿入する。一実施形態において、ＵＲモジュール３１４は、監視セッション又はプロファイリングセッションの間、メトリクスを記録してもよいが、このことは、異常記録器モジュール３１２が、異常ビューアモジュールによって、プロファイリングを停止するように指示されるまで続く。別の実施形態において、アプリケーション３０２が強制的に停止させられる場合、監視セッションを停止してもよく、且つ、従って、メトリクスの記録を停止してもよい。一実施形態において、あらゆる方法が完了すると、ＵＲモジュール３１４は、方法の各々に対して、退出タイムスタンプのような詳細をチェックする。１つ以上の方法が退出タイムスタンプを有さないという決定に基づいて、前記１つ以上の方法を、非退出であると識別してもよい。識別された方法を非退出方法として登録したものは、多レベルデータ構造におけるデータ格納庫３０６に、格納してもよい。

一実施形態において、ＥＲモジュール３１６は、ＢＣＩを使用して、例外異常を記録すること／捕捉することが可能である。本明細書では、例外は次のイベントとして定義してもよい。即ち、そのイベントは、アプリケーションの実行中に起こり、その結果として、前記プログラムは、プログラム命令の正常なフローを中断させる。例外的なフロー又は異常が、ある方法の中で起こる場合、該方法は、オブジェクトを作成し、且つ該オブジェクトをランタイムシステムに引き渡す。ランタイムシステム（ランタイムシステム又は単にランタイムとも呼ばれる）は、コンピュータ言語で書かれたコンピュータプログラムを実行することを支援するように設計されたソフトウェアである。Ｊａｖａにおいて、ランタイムは、Ｊａｖａランタイム環境（ＪＲＥ）と呼ばれる。ＤｏｔＮｅｔフレームワークにおいて、ランタイムは、共通言語ランタイム（ＣＬＲ）と呼ばれる。例外的フローの間に作成されるオブジェクトは、例外オブジェクトと呼ばれ、且つアプリケーションにおいて起こる異常に関する情報を含む。一実施形態において、例外オブジェクトは、ＥＲモジュール３１６に送信してもよい。ＥＲモジュール３１６は、ＢＣＩを使用して、例外オブジェクトから引き出された例外詳細を抽出する。方法の呼び出しに関して、ＥＲモジュール３１６は、スレッドＩＤ及び方法名を包含する異常メトリクス（ＡＭ）の中に１つの登録を挿入する。例えば、例外が起こる場合、ＥＲモジュール３１６は、例外が起こったスレッドのスレッドＩＤを捕捉する。また、ＥＲモジュール３１６は、例外名、例外原因、タイムスタンプ及びスタックトレースのような例外詳細を記録し、且つデータ格納庫３０６における前記例外詳細を更新する。例外詳細を有する登録は、例外異常に対する異常メトリクス（ＡＭ）の１つの登録と考えてもよく、且つ多レベルデータ構造におけるデータ格納庫３０６の中に格納される。本開示に従う多レベルデータ構造例は、図４において更に詳細に説明する。

データ格納庫３０６は、異常解析器モジュール３０８と結合される。データ格納庫３０６で捕捉されたメトリクスは、異常解析器モジュール３０８に提供され、且つ異常解析器モジュール３０８は、アプリケーション３０２の走行において起こる異常に対して、データを解析する。一実施形態において、異常解析器モジュール３０８は、１つ以上の異常を、データ構造から識別するように構成してもよく、ここで１つ以上の異常とは、データ構造における少なくとも１つの予め決められた条件の検出に基づいて、１つ以上の方法に関連付けられたものである。

一実施形態において、異常解析器モジュール３０８は、データ構造によってデータを読み取り、且つ異常メトリクスにおいて述べられたフォーマットの中でデータを処理する。異常解析器モジュール３０８は、データ構造における複数のスレッドのスレッド識別子によってループを作り、且つ各スレッド識別子の下で対応する方法の名前を引き出す。異常解析器モジュール３０８は、例外詳細を含むデータ、及び方法の各々に対応する異常詳細を、データ格納庫３０６から更に引き出す。異常解析器モジュール３０８は、非退出異常を識別するために、データ格納庫３０６から引き出されたデータから、例外詳細、呼び出しタイムスタンプ、及び方法スタックトレースを決定する。加えて又は代わりに、異常解析器モジュール３０８は、例外異常を識別するために、データ格納庫３０６から引き出された例外名、例外原因、及びタイムスタンプを含む例外詳細を決定する。

異常ビューアモジュール３１０は、異常解析器モジュールに結合され、且つシナリオ／実施される処理に基づいて、異常ビューアモジュール３１０は、アプリケーションが遭遇する異常のタイプを示す解析を、提示する又は表示するように構成される。異常ビューアモジュール３１０はまた、ユーザが、メトリクスの捕捉に関連する入力を提供することを可能にしてもよい。
例えば、
（ａ）ユーザは特定の方法名を述べてもよく、この方法名から、ユーザは例外的異常を含むこと、又は除外することを希望する。例えば、「ユーザ方法」と呼ばれる方法は、ユーザにより定義される属性として、ユーザによって設定される。ユーザが積極的な条件を設定する場合、その方法において起こる全ての例外的異常は、異常記録器によって捕捉される。しかしながら、ユーザが消極的な条件を設定する場合、その方法において起こる全ての例外的異常は無視される。
（ｂ）ユーザは、関連付けられたアプリケーションにおいて、予め定義された一組の例外以外の、あるカスタマイズされた例外を使用することが可能である。ユーザは、そのようなユーザ定義の例外の詳細（名前及びタイプ）を、パラメータとして、異常記録器に提供することが可能である。一旦これらの例外詳細が設定されると、異常記録器は、アプリケーションにおいて起こる、そのような例外的異常を捕捉することが可能である。
（ｃ）ある場合には、非退出異常は、アプリケーションの適切な走行にとって必要かもしれない。このことは、再び、アプリケーション論理に依存する。例えば、アプリケーションは、無限ループにおいて、ある機能性を実施しているかもしれない。これが意味するのは、ループを走行させる方法は非退出の方法であり、且つ異常記録器モジュールによって報告される、ということである。ユーザは、そのような方法名をパラメータとして通すことが可能であり、その結果、もし前記方法が非退出である場合でさえも、異常記録器は、自身がどの方法を無視するかを決定してもよい。

図４は、実施例に従う、多レベルデータ構造のアーキテクチャを例示する。図２及び図３を参照しながら議論したように、アプリケーションに関連付けられたあらゆるスレッドは、対応する一意的な識別子を割り当てられる。各スレッドに対する一意的な識別子は、スレッドＩＤとしてのものである。アプリケーションの実行に関して生成されたメトリクスは、多レベルデータ構造、例えば、データ構造４００に格納される。一実施形態において、多レベルデータ構造は、外部データ構造４０２及び内部データ構造４０４を含む。外部データ構造４０２では、スレッドＩＤは、一意的な識別子として格納される。

内部データ構造４０４では、方法名、方法呼び出しタイムスタンプ、退出タイムスタンプ、方法スタックトレースのような方法詳細は、あらゆるスレッドＩＤに対応付けられる。また、内部データ構造４０４では、あらゆる方法名は、一意的な識別子として格納され、且つ方法呼び出しタイムスタンプ４０６、退出タイムスタンプ４０８、方法スタックトレース４１０のような方法詳細が、方法識別子に対応付けられる。例外名４１２、例外原因４１４、及びタイムスタンプ４１６のような例外詳細は、例外詳細（ＥＤ）４１８と呼ばれる別個のデータ構造に格納される。非退出方法の場合、ＥＤデータ構造４１８は空である。ＥＤ及び方法詳細の組み合わせは、異常及び例外モデル（ＡＥＭ）と呼ばれる。

アプリケーションの走行中に遭遇する異常を検出するための方法を例示するフロー図は、図５を参照しながら更に説明する。

図５は、実施例に従う、アプリケーションの走行中に遭遇する異常を検出するための方法５００のフロー図を例示する。方法５００は、コンピュータ実行可能な命令の一般的な文脈で説明してもよい。一般に、コンピュータ実行可能な命令は、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造、プロシージャ、モジュール、関数などを含むことが可能であり、これらは、特定の機能を実施する、又は特定の抽象的データタイプを履行する。方法５００はまた、分散型コンピューティング環境において実践してもよく、この分散型コンピューティング環境では、機能は、通信ネットワークを通して連結される遠隔処理装置によって実施される。分散型コンピューティング環境では、コンピュータ実行可能な命令は、メモリ記憶装置を含めて、局所的コンピュータ記憶媒体及び遠隔的コンピュータ記憶媒体の両方に位置してもよい。

方法５００が説明される順序は、制限を与えるものと解釈されることを意図しておらず、且つ任意の数の説明される方法ブロックは、方法５００又は代替的方法を履行するために、任意の順序で結合することが可能である。加えて、個々のブロックは、方法５００から削除してもよいが、これは、本明細書で説明される主題の趣旨及び範囲から外れないことを前提としている。更に、方法５００は、任意の適切なハードウェア、ソフトウェア、ファームウェア、又はこれらの組み合わせにおいて、履行することが可能である。しかしながら、説明を簡単にするために、以下で説明される実施形態においては、方法５００は、上で説明されたシステム１０２（図１）及び／又はシステム２００（図２）において履行されるべきと考えてもよい。

５０２では、アプリケーションに関連付けられた、少なくとも１つのスレッドが実行される。一実施形態において、少なくとも１つのスレッドを実行するステップは、少なくとも１つのスレッドに関連付けられた、１つ以上の方法を呼び出すことに帰着する。５０４では、実行中に１つ以上の方法に関連付けられたメトリクスが捕捉される。捕捉されたメトリクスを格納するためのメトリクスデータ構造の詳細は、図４を参照しながら説明する。５０６では、周期的に捕捉されるメトリクスに基づいて、メトリクスは、複数のスレッド−方法対を表すために、データ構造の中で配列される。５０８では、アプリケーションの走行中に遭遇する、異なったタイプの異常は、配列されたメトリクスから検出される。

記述した説明は、本明細書における主題を説明するが、これは、当業者が、実施形態を作成すると共に使用することを可能にするためである。主題実施形態の範囲は、請求項によって定義され、且つ当業者に対して生じる他の変更例を含んでもよい。そのような他の変更例は、請求項の範囲の中にあることが意図されており、このことは、もし他の変更例が、請求項の文字通りの文言と違わない類似要素を有する場合、又は、もし他の変更例が、請求項の文字通りの文言から実質的な違いのない等価的要素を含む場合、においても当てはまる。

本開示の様々な実施形態は、アプリケーションの走行中に遭遇する異常を検出するための方法及びシステムを提供する。異常又は例外は、プログラミング論理における逸脱であり、この逸脱は、アプリケーションの実行における特定のエラー条件につながる。幾つかの背景異常又は例外は、気付かれないまま進行するが、その理由は、それらの異常又は例外が、アプリケーションに対する直接のインパクトを、ほとんど持たない、又は全く持たないからである。しかし、もしそのような例外が修正されない場合、アプリケーションが生産環境において展開される時、それらの例外は、より大きなやり方で現れるかもしれない。モジュールの不完全な実行のために、時として、アプリケーションは、誤った結果を与えて終わるかもしれない。全ての異常及び例外を捕捉すると共に意味のある方法で提示することは、アプリケーションを訂正するための適切な訂正活動を行う上で、開発者の助けとなり得る。本開示の様々な実施形態は、系統的アプローチを提供するが、この系統的アプローチの目的は、アプリケーションの走行において遭遇する例外的エラー及び誤った代替的フローのような異常を捕捉するために、アプリケーションを監視すると共に関連するメトリクスを収集することであり、その結果として、異常及び回復されたアプリケーションの正常化に対して、訂正的活動を行うことが可能である。

例示したステップは、示された典型的な実施形態を説明するために提示され、且つ、予期すべきことであるが、進行中の技術的開発は、特定の機能が実施されるやり方を変化させるであろう。これらの例は、限定することではなく、例示することを目的として、本明細書で提示される。更に、機能的な構築ブロックの境界は、説明の便宜上、本明細書で任意に定義されてきた。指定された機能及びそれらの関係が適切に実施される限り、代替的境界を定義することは可能である。本明細書に包含される教示に基づけば、（本明細書で説明された内容の等価例、拡張例、変形例、変移例などを含めた）代替例は、関連技術の当業者にとって明らかであろう。そのような代替例は、開示された実施形態の範囲及び趣旨の中に落とし込まれる。また、「備える（ｃｏｍｐｒｉｓｉｎｇ）」、「有する（ｈａｖｉｎｇ）」、「包含する（ｃｏｎｔａｉｎｉｎｇ）」、及び「含む（ｉｎｃｌｕｄｉｎｇ）」という単語、並びに他の類似の形は、意味において等価的であり、且つ制限の無いことが意図されている。ここで制限の無いとは、品目又はこれらの単語のいずれか１つに続く品目は、そのような品目（複数を含む）を徹底的に列挙したものであること、又は列挙された項目（複数含む）だけに限定されること、を意味しないということである。また注意しなければならないことであるが、本明細書において、及び添付された請求項において使用されるように、単数形である「ａ」、「ａｎ」、及び「ｔｈｅ」は、文脈としてそうでないことが明確に規定しない場合、複数の参照例を含む。

更には、１つ以上のコンピュータ可読な記憶媒体は、本開示と首尾一貫した実施形態を履行することにおいて、使用してもよい。コンピュータ可読な記憶媒体は、任意タイプの物理的メモリを指し、このメモリの上に、プロセッサによって可読である情報又はデータを格納してもよい。従って、コンピュータ可読な記憶媒体は、１つ以上のプロセッサによって実行するための命令を格納してもよく、該命令は、プロセッサに、本明細書で説明された実施形態と首尾一貫したステップ又は段階を実施させるための命令を含む。「コンピュータ可読な媒体」という用語は、有形の品目を含み、且つ搬送波及び過渡的な信号を除外する（即ち、非一時的である）ものと理解するべきである。例として、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、揮発性メモリ、不揮発性メモリ、ハードドライブ、ＣＤ−ＲＯＭ、ＤＶＤ、フラッシュドライブ、ディスク、及び他の既知の物理的記憶媒体が含まれる。

意図しているのは、開示及び実施例は単に典型的なものとして考えられ、開示された実施形態の真の範囲及び趣旨は次の請求項によって示される、ということである。

Claims (13)

1. アプリケーションにおける異常検出のための、プロセッサにより履行される方法であって、
   前記アプリケーションに関連付けられた少なくとも１つのスレッドを実行するステップであって、前記少なくとも１つのスレッドを実行するステップは、前記少なくとも１つのスレッドに関連付けられた１つ以上のメソッドを呼び出すことに帰着し、前記アプリケーションを走行するサーバとの間で監視セッションを確立すると、前記少なくとも１つのスレッドが実行されるステップと、
   前記１つ以上のメソッドに関連付けられたメトリクスを、前記実行の間に周期的に捕捉するステップであって、前記メトリクスは、ランタイム環境において、前記アプリケーションを実行する間に生成される、ステップと、
   複数のスレッド−方法対を表すためのデータ構造における前記メトリクス、及び前記複数のスレッド−方法対の各々に対応する前記メトリクスを配列するステップと、
   前記データ構造における、前記メトリクスに関連付けられた少なくとも１つの予め決められた条件を検出することに基づいて、前記１つ以上のメソッドに関連付けられた１つ以上の異常を、前記データ構造から識別するステップであって、前記１つ以上の異常の中の１つの異常は、非退出異常、例外異常、及びユーザにより定義される異常の１つを備える、ステップと、
   を備える、方法。
2. 請求項１に記載の方法であって、
   前記１つ以上のメソッドに関連付けられた前記メトリクスは、方法名、方法呼び出しタイムスタンプ、方法退出タイムスタンプ、方法スタックトレース、例外名、例外原因、及び例外タイムスタンプを備える、方法。
3. 請求項２に記載の方法であって、
   前記１つ以上のメソッドにおいて前記非退出異常を識別するステップは、前記１つ以上のメソッドに関連付けられた前記メトリクスにおいて、前記方法退出タイムスタンプの欠如を検出することを備える、方法。
4. 請求項１に記載の方法であって、
   前記１つ以上のメソッドにおいて前記例外異常を識別するステップは、前記１つ以上のメソッドに関連付けられた前記メトリクスにおいて、例外名、例外原因、及び例外タイムスタンプを検出することを備える、方法。
5. 請求項１に記載の方法であって、
   前記少なくとも１つの予め決められた条件は、ユーザによって定義され、その結果として、前記方法において前記ユーザにより定義される異常を識別する、方法。
6. 請求項１に記載の方法であって、
   前記アプリケーションは、複数の層を有する分散型アプリケーションであり、前記分散型アプリケーションは、少なくとも１つのウェブインターフェース、少なくとも１つのデータベース構成要素、及び少なくとも１つのアプリケーションインターフェースの１つ以上を備える、方法。
7. アプリケーションにおける異常検出のためのシステムであって、
   少なくとも１つのメモリと、
   １つ以上のハードウェアプロセッサであって、前記少なくとも１つのメモリは前記１つ以上のハードウェアプロセッサに結合され、前記１つ以上のハードウェアプロセッサは、前記少なくとも１つのメモリに格納される、プログラムされた命令を実行することが可能であり、該命令の目的は、
   前記アプリケーションに関連付けられた少なくとも１つのスレッドを実行することであって、前記少なくとも１つのスレッドを実行することは、前記少なくとも１つのスレッドに関連付けられた１つ以上のメソッドを呼び出すことに帰着し、前記アプリケーションを走行するサーバとの間で監視セッションを確立すると、前記少なくとも１つのスレッドが実行されることと、
   前記１つ以上のメソッドに関連付けられたメトリクスを、前記実行の間に周期的に捕捉することであって、前記メトリクスは、ランタイム環境において、前記アプリケーションを実行する間に生成されることと、
   複数のスレッド−方法対を表すためのデータ構造における前記メトリクス、及び複数のスレッド−方法対の各々に対応する前記メトリクスを配列することと、
   前記データ構造における、前記メトリクスに関連付けられた少なくとも１つの予め決められた条件を検出することに基づいて、前記１つ以上のメソッドに関連付けられた１つ以上の異常を、前記データ構造から識別することであって、前記１つ以上の中の１つの異常は、非退出異常、例外異常、及びユーザにより定義される異常の１つを備える、ことから成る、
   １つ以上のハードウェアプロセッサと、
   を備える、システム。
8. 請求項７に記載のシステムであって、
   前記１つ以上のメソッドに関連付けられた前記メトリクスは、方法名、方法呼び出しタイムスタンプ、方法退出タイムスタンプ、方法スタックトレース、例外名、例外原因、及び例外タイムスタンプを備える、システム。
9. 請求項８に記載のシステムであって、
   前記少なくとも１つのプロセッサは、前記１つ以上のメソッドにおいて前記非退出異常を識別するための、プログラムされた命令を実行することが可能であり、且つ前記１つ以上の方法に関連付けられた前記メトリクスにおいて前記方法退出タイムスタンプの欠如を検出することを備える、システム。
10. 請求項７に記載のシステムであって、
    前記少なくとも１つのプロセッサは、前記１つ以上の方法における前記非退出異常を識別するための、プログラムされた命令を実行することが可能であり、且つ前記１つ以上の方法に関連付けられた前記メトリクスにおいて、例外名、例外原因、及び例外タイムスタンプを検出することを備える、システム。
11. 請求項７に記載のシステムであって、
    前記少なくとも１つの予め決められた条件は、ユーザによって定義され、その結果として、前記方法において前記ユーザにより定義される異常を識別する、システム。
12. 請求項７に記載のシステムであって、
    前記アプリケーションは、複数の層を有する分散型アプリケーションであり、前記複数の層は、少なくとも１つのウェブインターフェース、少なくとも１つのデータベース構成要素、及び少なくとも１つのアプリケーションインターフェースの１つ以上を備える、システム。
13. 異常検出のための方法を実行するためのコンピュータプログラムを自身の上に埋め込んだ非一時的なコンピュータ可読媒体であって、前記方法は、
    アプリケーションに関連付けられた少なくとも１つのスレッドを実行するステップであって、前記少なくとも１つのスレッドを実行するステップは、前記少なくとも１つのスレッドに関連付けられた１つ以上のメソッドを呼び出すことに帰着し、前記アプリケーションを走行するサーバと共に監視セッションを確立すると、前記少なくとも１つのスレッドが実行されるステップと、
    前記１つ以上の方法に関連付けられたメトリクスを、前記実行の間に周期的に捕捉するステップであって、前記メトリクスは、ランタイム環境において、前記アプリケーションを実行する間に生成される、ステップと、
    複数のスレッド−方法対を表すためのデータ構造における前記メトリクス、及び前記複数のスレッド−方法対の各々に対応する前記メトリクスを配列するステップと、
    前記データ構造における、前記メトリクスに関連付けられた少なくとも１つの予め決められた条件を検出することに基づいて、前記１つ以上の方法に関連付けられた１つ以上の異常を、前記データ構造から識別するステップであって、前記１つ以上の異常の中の１つの異常は、非退出異常、例外異常、及びユーザにより定義される異常の１つを備える、ステップと、
    を備える、非一時的なコンピュータ可読媒体。
    

Images