Java アプリケーションに ARMS エージェントをインストールすると、ARMS はそのアプリケーションのモニタリングを開始します。例外 ページでは、例外名、API 名、またはホストを基準に例外をフィルター処理および分析し、例外を発生させるコードの最適化を行えます。
例外記録の仕組み
ARMS は、計測対象メソッド内で try-catch ブロックから例外が脱出した際に、その例外を 1 件記録します。try-catch ブロック内でキャッチされ、処理された例外は記録されません。
以下のシナリオでこの動作を説明します。ARMS エージェントが methodA および methodB の両方を計測済みであると仮定します。
両方のメソッドは例外をキャッチします
public int methodA() {
try {
return methodB();
} catch (Throwable e) {
e.printStackTrace();
return 0;
}
}
public int methodB() {
try {
return 1 / 0;
} catch (Throwable e) {
e.printStackTrace();
return 0;
}
}結果： ARMS は例外を記録しません。両方の例外は、それぞれの try-catch ブロック内でキャッチおよび処理されています。
片方のメソッドのみが例外をキャッチする場合
public int methodA() {
try {
return methodB();
} catch (Throwable e) {
e.printStackTrace();
return 0;
}
}
public int methodB() {
return 1 / 0;
}結果： ARMS は java.lang.ArithmeticException を 1 件記録します — methodB 内でキャッチされていません。
どちらのメソッドも例外をキャッチしない場合
public int methodA() {
return methodB();
}
public int methodB() {
return 1 / 0;
}結果： ARMS は java.lang.ArithmeticException を 2 件記録します — 例外がキャッチされずに伝播した、計測対象の各メソッドごとに 1 件ずつです。
キャッチ後に別の例外型として再スローする場合
public static int methodA() {
try {
return methodB();
} catch (Throwable e) {
throw new RuntimeException(e);
}
}
public static int methodB() {
return 1 / 0;
}結果： ARMS は 2 件の例外を記録します：
java.lang.ArithmeticException—methodB内でキャッチされていません。java.lang.RuntimeException—methodAによってスローされます。
例外分析の表示
-
ARMS コンソール にログインします。左側のナビゲーションウィンドウで、 を選択します。
上部のナビゲーションバーで、 を選択します。
クイックフィルター領域（①）では、例外、API、または ホスト を基準に例外数および例外一覧をフィルター処理できます。
トレンドチャート領域（②）では、指定された時間範囲内でスローされた例外数を確認できます。データは例外タイプ別に積み上げ表示されます。
アイコンをクリックすると、特定の期間におけるメトリック統計を表示したり、異なる日付における同一期間の統計を比較したりできます。
アイコンをクリックすると、横棒グラフとトレンドチャートを切り替えることができます。例外一覧領域（③）では、API 名、例外数、割合、および例外情報のまとめを確認できます。
例外一覧では、以下の操作を実行できます：
操作 列の 概要 をクリックすると、右側にパネルが開きます。このパネルには、例外数のトレンド、API およびインスタンス別の例外分布、スタックトレースなどの情報が表示されます。
操作 列の トレース をクリックすると、呼び出しのトレース詳細を表示できます。詳細については、「トレース分析」をご参照ください。
関連ドキュメント
アプリケーションモニタリングのメトリックの一覧については、「アプリケーションモニタリングのメトリック」をご参照ください。
よくある質問
API の 例外数がリクエスト数を上回る
この現象は、以下の理由により発生する可能性があります：
ARMS は、計測対象メソッドから例外がスローされた時点で例外を記録します。1 回の API 呼び出し中に複数の計測対象メソッドが例外をスローした場合、その呼び出しに対して複数の例外が記録されます。
同一の例外が、複数の計測対象メソッドを経由してメソッドスタックを上位へ伝播した場合、ARMS はその例外を複数回記録します。
エージェントのアップグレード後に例外データが変更される
各エージェントバージョンでは、計測対象メソッドのセットが変更される場合があります。計測対象メソッドの数が増減すると、キャプチャされる例外数もそれに応じて変化します。
ARMS がビジネスロジックでキャッチされていない例外を表示する
エージェントによって計測された多くのフレームワークライブラリでは、一部の例外がフレームワークレベルで内部的にキャッチおよび処理され、ご利用のビジネスコードにはスローされません。エージェントはこれらの例外をキャプチャしますが、アプリケーション自体はそれらを認識しません。
たとえば、MongoTemplate を使用して MongoDB にアクセスする呼び出しでは、アプリケーション側で例外が報告されない場合でも、ARMS コンソールに例外が表示されることがあります。これは、MongoTemplate に組み込みのリトライロジックが含まれているためです。タイムアウトが発生した場合、MongoTemplate は操作を再試行し、複数回のリトライが失敗した後にのみ呼び出し元に例外をスローします。したがって、MongoTemplate を使用して MongoDB にアクセスし、下位層でタイムアウトおよびリトライが発生した場合、ビジネスロジックでは例外を認識しないものの、ARMS コンソールには例外が表示されます。
例外スタックトレースの不一致
データ処理およびレポート効率を向上させるため、ARMS エージェントは各例外について、クラス名、メソッドスタックの先頭 3 行、および末尾 3 行に基づいて指紋（fingerprint）を生成します。この指紋は、CRC64 を使用して 64 ビット値にエンコーディングされます。例外が初めて発生した際には、エージェントはエンコーディング済み値と元の値の両方をレポートします。その後の同一例外については、エンコーディング済み値のみがレポートされます。この処理により、以下の 2 つの状況で表示されるスタックトレースと実際のスタックトレースが不一致になる可能性があります：
2 つの例外の完全なメソッドスタックは異なりますが、クラス名およびメソッドスタックの先頭 3 行・末尾 3 行が同一の場合、同一のエンコーディング値が生成され、不一致が発生します。
2 つの例外のクラス名、またはメソッドスタックの先頭 3 行・末尾 3 行のいずれかが異なるにもかかわらず、エンコーディング値が同一となる場合があります。これは、非一意な CRC64 エンコーディングアルゴリズムによるハッシュコリジョンが原因です。
上記のいずれかの状況が発生した場合は、カスタム設定 ページの 例外高度フィルタリング設定 セクションにある 類似例外スタックの差別化深度 パラメーターの値を増加させることができます。
30 日経過後に ID として表示される例外
レポートされるデータ量を最適化するため、ARMS は例外をエンコーディングし、初回発生時にエンコーディング済み値と元の値の両方をサーバーに送信します。サーバーはこのマッピングを保存しますが、有効期限は 30 日間です。アプリケーションの実行期間が 30 日を超えた場合、サーバーはエンコーディング済み値から元の例外値を照合できなくなる可能性があります。
コンソールに例外が表示されない
デフォルトでは、ARMS エージェントは計測対象メソッドからのみ例外を収集します。
エージェントバージョン 4.1.12 以降をご利用の場合、カスタム設定 ページの エージェントスイッチ設定 セクションで例外プラグインを有効化できます。プラグインを有効化すると、ARMS は例外インスタンスが作成されるたびにデータを収集します。