図面 (/)

技術 異常検出のための方法及びシステム

出願人 タタコンサルタンシーサービシズリミテッド
発明者 ラムクマールイランゴヴァンサヤンタンダスショウナククンドゥスワルプシャッタルジェー
出願日 2016年9月27日 (3年5ヶ月経過) 出願番号 2016-188501
公開日 2017年9月21日 (2年5ヶ月経過) 公開番号 2017-168076
状態 特許登録済
技術分野 デバッグ/監視
主要キーワード データベース構成要素 技術的開発 方法ブロック データ格納庫 アプリケーションランタイム 機能的アーキテクチャ 監視セッション 演算論理
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2017年9月21日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (6)

課題

異常検出に関し、且つ、特に、異常を検出するためのシステム及び方法を提供する。

解決手段

本方法は、アプリケーションに関連付けられた少なくとも1つのスレッドを実行するステップを含む。少なくとも1つのスレッドを実行するステップは、少なくとも1つのスレッドに関連付けられた1つ以上の方法を呼び出すことに帰着する。実行の間、1つ以上の方法に関連付けられたメトリクス捕捉される。複数のスレッド−方法対を表すためのデータ構造におけるメトリクス、及び複数のスレッド−方法対の各々に対応するメトリクスが、系統的に配列される。1つ以上の方法に関連付けられた1つ以上の異常は、データ構造における、少なくとも1つの予め決められた条件を検出することに基づいて、データ構造から識別される。1つ以上の異常の中の1つの異常は、非退出異常、例外異常、及びユーザにより定義される異常の1つを含む。

概要

背景

優先権主張]
この特許出願は、2016年3月17日に出願された特許文献1に対する優先権を主張する。前述の特許文献1の内容全体は、参照によって本明細書に組み込まれる。

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

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

概要

異常検出に関し、且つ、特に、異常を検出するためのシステム及び方法を提供する。本方法は、アプリケーションに関連付けられた少なくとも1つのスレッドを実行するステップを含む。少なくとも1つのスレッドを実行するステップは、少なくとも1つのスレッドに関連付けられた1つ以上の方法を呼び出すことに帰着する。実行の間、1つ以上の方法に関連付けられたメトリクス捕捉される。複数のスレッド−方法対を表すためのデータ構造におけるメトリクス、及び複数のスレッド−方法対の各々に対応するメトリクスが、系統的に配列される。1つ以上の方法に関連付けられた1つ以上の異常は、データ構造における、少なくとも1つの予め決められた条件を検出することに基づいて、データ構造から識別される。1つ以上の異常の中の1つの異常は、非退出異常、例外異常、及びユーザにより定義される異常の1つを含む。

目的

開示された実施形態は、アプリケーションの実行中に遭遇する異常を検出するための、様々な方法及びシステムを提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

アプリケーションにおける異常検出のための、プロセッサにより履行される方法であって、前記アプリケーションに関連付けられた少なくとも1つのスレッドを実行するステップであって、前記少なくとも1つのスレッドを実行するステップは、前記少なくとも1つのスレッドに関連付けられた1つ以上の方法を呼び出すことに帰着する、ステップと、前記1つ以上の方法に関連付けられたメトリクスを、前記実行の間に捕捉するステップと、複数のスレッド−方法対を表すためのデータ構造における前記メトリクス、及び前記複数のスレッド−方法対の各々に対応する前記メトリクスを系統的に配列するステップと、前記データ構造における、少なくとも1つの予め決められた条件を検出することに基づいて、前記1つ以上の方法に関連付けられた1つ以上の異常を、前記データ構造から識別するステップであって、前記1つ以上の異常の中の1つの異常は、非退出異常、例外異常、及びユーザにより定義される異常の1つを備える、ステップと、を備える、方法。

請求項2

請求項1に記載の方法であって、前記1つ以上の方法に関連付けられた前記メトリクスは、方法名、方法呼び出しタイムスタンプ、方法退出タイムスタンプ、方法スタックトレース、例外名、例外原因、及び例外タイムスタンプを備える、方法。

請求項3

請求項2に記載の方法であって、前記1つ以上の方法において前記非退出異常を識別するステップは、前記1つ以上の方法に関連付けられた前記メトリクスにおいて、前記方法退出タイムスタンプの欠如を検出することを備える、方法。

請求項4

請求項1に記載の方法であって、前記1つ以上の方法において前記例外異常を識別するステップは、前記1つ以上の方法に関連付けられた前記メトリクスにおいて、例外名、例外原因、及び例外タイムスタンプを検出することを備える、方法。

請求項5

請求項1に記載の方法であって、前記少なくとも1つの予め決められた条件は、ユーザによって定義され、その結果として、前記方法において前記ユーザにより定義される異常を識別する、方法。

請求項6

請求項1に記載の方法であって、前記アプリケーションは、複数の層を有する分散型アプリケーションであり、前記分散型アプリケーションは、少なくとも1つのウェブインターフェース、少なくとも1つのデータベース構成要素、及び少なくとも1つのアプリケーションインターフェースの1つ以上を備える、方法。

請求項7

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

請求項8

請求項7に記載のシステムであって、前記1つ以上の方法に関連付けられた前記メトリクスは、方法名、方法呼び出しタイムスタンプ、方法退出タイムスタンプ、方法スタックトレース、例外名、例外原因、及び例外タイムスタンプを備える、システム。

請求項9

請求項8に記載のシステムであって、前記少なくとも1つのプロセッサは、前記1つ以上の方法において前記非退出異常を識別するための、プログラムされた命令を実行することが可能であり、且つ前記1つ以上の方法に関連付けられた前記メトリクスにおいて前記方法退出タイムスタンプの欠如を検出することを備える、システム。

請求項10

請求項7に記載のシステムであって、前記少なくとも1つのプロセッサは、前記1つ以上の方法における前記非退出異常を識別するための、プログラムされた命令を実行することが可能であり、且つ前記1つ以上の方法に関連付けられた前記メトリクスにおいて、例外名、例外原因、及び例外タイムスタンプを検出することを備える、システム。

請求項11

請求項7に記載のシステムであって、前記少なくとも1つの予め決められた条件は、ユーザによって定義され、その結果として、前記方法において前記ユーザにより定義される異常を識別する、システム。

請求項12

請求項7に記載のシステムであって、前記アプリケーションは、複数の層を有する分散型アプリケーションであり、前記複数の層は、少なくとも1つのウェブインターフェース、少なくとも1つのデータベース構成要素、及び少なくとも1つのアプリケーションインターフェースの1つ以上を備える、システム。

請求項13

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

技術分野

0001

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

背景技術

0002

優先権主張]
この特許出願は、2016年3月17日に出願された特許文献1に対する優先権を主張する。前述の特許文献1の内容全体は、参照によって本明細書に組み込まれる。

0003

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

0004

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

先行技術

0005

インド特許出願第201621009340号

発明が解決しようとする課題

0006

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

課題を解決するための手段

0007

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

0008

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

0009

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

0010

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

0011

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

図面の簡単な説明

0012

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

実施例

0013

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

0014

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

0015

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

0016

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

0017

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

0018

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

0019

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

0020

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

0021

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

0022

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

0023

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

0024

一実施形態において、各装置104は、サーバ108と通信するために、サーバ108と共にセッションを確立することが可能である。装置104は、通信ネットワーク106を通して、サーバ108と通信することが可能である。通信ネットワーク106は、無線ネットワーク有線ネットワーク、又はこれらの組み合わせであってもよい。通信ネットワーク106は、イントラネットローカルエリアネットワーク(LAN)、ワイドエリアネットワークWAN)、インターネットなどのような、異なったタイプのネットワークの1つとして履行することが可能である。通信ネットワーク106は、専用ネットワーク又は共有ネットワークのいずれかであってもよい。共有ネットワークは、異なったタイプのネットワークの連合を表し、ここで異なったタイプのネットワークは、互いに対して通信するために、様々なプロトコルを使用するが、それらは、例えば、ハイパーテキスト転送プロトコルHTTP)、伝送制御プロトコルインターネットプロトコル(TCP/IP)、無線アプリケーションプロトコル(WAP)などである。更に、ネットワーク106は、ルータブリッジ、サーバ、コンピューティング装置記憶装置などを含めて、様々なネットワーク装置を含んでもよい。

0025

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

0026

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

0027

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

0028

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

0029

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

0030

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

0031

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

0032

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

0033

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

0034

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

0035

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

0036

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

0037

0038

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

0039

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

0040

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

0041

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

0042

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

0043

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

0044

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

0045

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

0046

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

0047

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

0048

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

0049

構成データ304は、メトリクスを捕捉することに関するデータを含む。例えば、構成データ304は、メトリクスにおいてどんなデータが捕捉されるべきか、いつデータが捕捉されなければばらないか、などのような情報を含んでもよい。一実施形態において、構成データ304は、ユーザによって提供してもよく、且つアプリケーションの走行において遭遇する異常を捕捉するための、異常捕捉セッションを開始する以前に格納してもよい。一実施例において、初期設定自動生成標準構成を、メトリクスを捕捉するために使用してもよい。例えば、Strutsフレームワークを有する標準J2EE(Java 2 Platform Enterprise Edition)アプリケーションに対しては、そのフレームワークに関連する標準構成をロードすることが可能である。バックエンドのJavaバッチアプリケーションに対しては、バッチプログラムに関連する構成をロードすることが可能である。

0050

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

0051

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

0052

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

0053

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

0054

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

0055

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

0056

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

0057

内部データ構造404では、方法名、方法呼び出しタイムスタンプ、退出タイムスタンプ、方法スタックトレースのような方法詳細は、あらゆるスレッドIDに対応付けられる。また、内部データ構造404では、あらゆる方法名は、一意的な識別子として格納され、且つ方法呼び出しタイムスタンプ406、退出タイムスタンプ408、方法スタックトレース410のような方法詳細が、方法識別子に対応付けられる。例外名412、例外原因414、及びタイムスタンプ416のような例外詳細は、例外詳細(ED)418と呼ばれる別個のデータ構造に格納される。非退出方法の場合、EDデータ構造418は空である。ED及び方法詳細の組み合わせは、異常及び例外モデルAEM)と呼ばれる。

0058

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

0059

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

0060

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

0061

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

0062

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

0063

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

0064

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

0065

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

0066

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

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ