Java アプリケーションにエージェントをインストールすると、ARMS はアプリケーションのモニタリングを開始します。[Exception Analysis] ページでは、名前、インターフェイス、ホストで例外をフィルタリングおよび分析して、エラーの原因となっているコードを最適化できます。
例外分析の表示
-
上部メニューで、 を選択します。
-
クイックフィルターエリアでは、[Exception]、[Operation]、[Host] で例外数と例外リストをフィルタリングできます。
-
トレンドチャートエリアでは、指定した時間範囲内にアプリケーションによって特定の例外がスローされた回数を表示できます。例外は積み上げグラフで表示されます。
アイコンをクリックすると、特定の期間内のメトリクスの統計を表示したり、異なる日付の同じ期間の統計を比較したりできます。
アイコンをクリックすると、棒グラフとトレンドチャートを切り替えることができます。 -
例外リストエリアでは、例外名、例外数、パーセンテージ、例外の概要を表示できます。
例外リストから、次の操作を実行できます：
-
[Actions] 列の [Overview] をクリックして、右側にパネルを開きます。このパネルには、例外の概要として、件数の推移、インターフェイスとインスタンス別の分布、および例外スタックが表示されます。
-
[Actions] 列の [Traces] をクリックして、トレースの詳細を表示します。詳細については、トレースエクスプローラーをご参照ください。
-
-
関連ドキュメント
アプリケーションモニタリングメトリクスの詳細については、アプリケーションモニタリングメトリクスをご参照ください。
よくある質問
なぜ例外数はリクエスト数を超えるのですか。
これには、次の理由が考えられます：
-
ARMS は、インストルメントされたメソッドによって例外がスローされるたびに例外を記録します。単一のインターフェイス呼び出し中に複数のインストルメントされたメソッドが例外をスローした場合、ARMS はそれぞれを記録するため、単一の呼び出しに対して複数のレコードが生成されます。
-
同じ例外が複数のインストルメントされたメソッドを介してコールスタックを上に伝播する場合、これらの各メソッドが例外を記録する可能性があり、その結果、単一の発生に対して複数のカウントが記録されます。
なぜアップグレード後に例外数が変わるのですか。
エージェントのバージョンごとに、インストルメントされたメソッドの数が増減する場合があります。その結果、これらのメソッドからキャプチャされる例外の数も増減する可能性があります。
なぜ未処理の例外が表示されるのですか。
エージェントによってインストルメントされた多くのフレームワークレベルのメソッドでは、例外がキャッチされ、ビジネスコードに伝播されることなく内部で処理される場合があります。アプリケーションがそれらを認識していなくても、エージェントはこれらの例外をキャプチャします。
たとえば、MongoTemplate を使用した MongoDB への呼び出しは、アプリケーションでエラーをスローしないかもしれませんが、ARMS コンソールではエラーが表示されることがあります。これは、MongoTemplate がリトライロジックをカプセル化しているためです。MongoTemplate メソッドの呼び出しでタイムアウトが発生すると、操作をリトライします。例外は、複数回のリトライが失敗した後にのみ呼び出し元にスローされます。したがって、MongoTemplate を使用して MongoDB にアクセスし、タイムアウトが原因で基盤となるリトライが発生した場合、アプリケーションには例外が表示されないかもしれませんが、ARMS コンソールには表示されます。
なぜスタックトレースと例外が一致しないのですか。
データ処理とレポートの効率を向上させるために、ARMS エージェントは、各例外に対して、そのクラス名、スタックトレースの最初の 3 行、およびスタックトレースの最後の 3 行に基づいてフィンガープリントを生成します。このフィンガープリントは、CRC64 を使用して 64 ビットの文字列にエンコードされます。最初の出現時に、エージェントはエンコードされた値と元のスタックトレースの両方をレポートします。以降に発生する同じ例外については、エンコードされた値のみがレポートされます。このプロセスにより、2 つの状況で不一致が発生する可能性があります：
-
2 つの例外の完全なスタックトレースは異なりますが、例外のクラス名とスタックトレースの最初と最後の 3 行が同じです。フィンガープリントロジックにより、それらのエンコードされた値は同一になり、不一致につながります。
-
2 つの例外のクラス名またはスタックトレースの最初と最後の 3 行が異なりますが、CRC64 は一意ではないエンコーディングアルゴリズムであるため、ハッシュ衝突が発生します。これにより、異なる例外に対して同じエンコードされた値が生成される可能性があります。
これらの状況のいずれかが発生した場合は、[カスタム設定] ページの [例外の高度なフィルタリング設定] セクションで、[類似例外スタックの区別深度] パラメーターを増やすことができます。例外の高度なフィルタリング設定ページには、次の設定が含まれています：[プラグイン例外の収集] (プラグインからの例外を収集するかどうかを制御します)、[すべての例外を収集] (有効にすると、例外コンストラクターをインストルメントしてすべての例外をキャプチャします)、[類似例外スタックの区別深度] (デフォルト値は 2。スタックの深さに基づいて類似の例外を区別するために使用されます)、[例外フィルタリングのホワイトリスト] (ホワイトリスト内の例外は、例外関連のチャートから除外されます)、[例外フィルタリングの親クラス継承] (エージェント v4.1.6 以降でのみサポートされます)、および [例外メッセージのフィルタリング]。
なぜ古い例外は ID のみを表示するのですか。
データレポート量を最適化するために、例外が最初に発生したとき、ARMS はそれをエンコードし、エンコードされた値と元の値の両方をサーバーに送信します。サーバーはこのマッピングを保存しますが、30 日後に有効期限が切れます。アプリケーションが 30 日以上実行されると、例外の元の値がそのエンコードされた値から取得できなくなる可能性があります。
なぜ一部の例外が表示されないのですか。
デフォルトでは、ARMS エージェントはすべての例外をキャプチャしません。ARMS エージェントによってインストルメントされたメソッドからスローされた例外のみが収集されます。
エージェントバージョン 4.1.12 以降を使用している場合は、[カスタム設定] ページの [エージェントスイッチ設定] セクションで例外プラグインを有効にできます。このプラグインを有効にすると、ARMS は例外インスタンスが作成されるたびに例外データを収集します。