Create a database
Application Monitoring は、新しい課金モードを有効にしているユーザー向けに、新しいアプリケーション詳細ページを提供します。
Visual Studio を使用する場合は、[新しいプロジェクトの作成] ダイアログで [Blazor WebAssembly アプリ] テンプレートを選択します。
基準
Application Real-Time Monitoring Service (ARMS) の例外分析機能は、Java 例外を検出します。 try...catch 文のため、インターフェイス呼び出しで発生した例外が検出されない場合があります。 文が複数回実行されると、インターフェイス呼び出しでさまざまな例外が発生する可能性があります。 例外が try...catch 文によって検出されずにインターフェイス呼び出しの応答に影響を与える場合、エラーが返されます。
手順
ARMS コンソール にログインします。 左側のナビゲーションウィンドウで、 を選択します。
[アプリケーションリスト] ページで、上部のナビゲーションバーでリージョンを選択し、管理するアプリケーションの名前をクリックします。
説明[言語] 列に表示されるアイコンは、アプリケーションが記述されている言語を示します。
: Java アプリケーション
: Go アプリケーション
: Python アプリケーションハイフン ([-]): Managed Service for OpenTelemetry で監視されるアプリケーション
上部のナビゲーションバーで、 を選択します。
クイックフィルタセクション（アイコン 1）では、例外操作コンテナー URL、、または で例外をクエリできます。
トレンドチャートセクション（アイコン 2）では、指定された期間内にアプリケーションが例外をスローした回数を表示できます。 異なる例外を持つ列は互いに積み重ねられています。
アイコンをクリックします。 表示されるダイアログボックスで、特定の期間のメトリックデータを表示したり、異なる日付の同じ期間のメトリックデータを比較したりできます。 
アイコンをクリックすると、データを縦棒グラフまたはトレンドチャートで表示できます。例外リストセクション（アイコン 3）では、各例外の名前、発生回数、割合、および概要情報を表示できます。
例外リストで、必要に応じて次の操作を実行します。
概要アクション 列の をクリックすると、表示されるパネルに例外数の傾向、インターフェイスとインスタンスの分布、および異常スタックが表示されます。
既存のメディアを移行します。メディア設定を構成するトレース エクスプローラー 列の をクリックすると、インターフェイストレースの詳細が表示されます。 詳細については、「」をご参照ください。
参考資料
Application Monitoring メトリックについては、「Application Monitoring メトリック」をご参照ください。
よくある質問
インターフェイス呼び出しの例外の数がインターフェイスリクエストの数よりも多いのはなぜですか？
この問題は、次のいずれかの理由で発生する可能性があります。
ARMS は、インストゥルメント化されたメソッドが例外をスローすると、例外カウントを記録します。 1 回のインターフェイス呼び出し中に複数のメソッドが例外をスローし、これらのメソッドが ARMS エージェントによって自動的にインストゥルメント化されている場合、ARMS はその 1 回の呼び出しで複数の例外を記録します。
同じ例外が下位レベルのメソッドから上位レベルのメソッドに伝播し、呼び出しスタック内の複数のメソッドがインストゥルメント化されている場合、この例外は複数回記録されます。
ARMS エージェントのスペックアップ後に例外が変更されたのはなぜですか？
ARMS エージェントがスペックアップされるたびに、インストゥルメント化されたメソッドが増減する可能性があります。 その結果、これらのインストゥルメント化されたメソッド内でスローされる例外の数もそれに応じて増減する可能性があります。
インターフェイスの例外カウントがゼロではないのに、ビジネスロジックによって関連する例外がキャッチされなかったのはなぜですか？
ほとんどのインストゥルメント化されたフレームワークコードでは、特定の例外がフレームワークレイヤー内でキャッチおよび処理され、ビジネスコードにスローされない場合、ARMS エージェントはこれらの例外をキャプチャできますが、ユーザーはそれらを認識できない場合があります。
たとえば、エラーが発生せずに MongoTemplate を使用して MongoDB にアクセスする場合でも、ARMS コンソールに MongoDB アクセスエラーが表示される場合があります。 これは、MongoTemplate がリトライロジックをカプセル化しているためです。 MongoTemplate の 1 回のメソッド呼び出し中にタイムアウト例外が発生した場合、再試行され、複数回の再試行が失敗した後にのみ呼び出し元に例外がスローされます。 したがって、基になる再試行動作で MongoTemplate を使用して MongoDB にアクセスする場合、ビジネスロジックは例外を認識しない場合がありますが、ARMS コンソールには例外が表示されます。
例外スタックがインターフェイスで実際に発生した例外と一致しないのはなぜですか？
データ処理とレポート効率を向上させるために、ARMS エージェントは例外クラス名、例外メソッドスタックの最初の 3 行、および例外メソッドスタックの最後の 3 行に基づいて文字列を生成します。 次に、この文字列を CRC64 を使用して 32 ビット文字列にエンコードします。 最初のレポートでは、エンコードされた値と元の値の両方が報告されます。 同じ例外の以降のレポートには、エンコードされた値のみが含まれます。 次のシナリオでは、例外スタックは実際のスタックと一致しません。
2 つの例外の完全なメソッドスタックは異なりますが、例外クラス名、例外メソッドスタックの最初の 3 行、および例外メソッドスタックの最後の 3 行は同じです。 この場合、処理ロジックによって同じエンコードされた値が生成され、不一致が発生します。
2 つの例外の例外クラス名、例外メソッドスタックの最初の 3 行、および例外メソッドスタックの最後の 3 行は異なりますが、CRC64 エンコーディングの一意性がないため、エンコードされた値が同じになる場合があり、不一致が発生します。
不一致を修正するには、同様の例外スタックの差別化の深さ変更を保存メディア ファイルをアップロードします。
タブの セクションで パラメーターの値を増やします。
アプリケーションの実行が 30 日を超えた後、ARMS コンソールに例外の ID が 1 つしか表示されないのはなぜですか？
レポートされるデータ量を最適化するために、例外が初めて発生したときに、システムは例外をエンコードし、エンコードされた値と元の値の両方をサーバーに報告します。 サーバーはこのエンコードされた値を元の値とともに保存し、保存期間は 30 日です。 アプリケーションの実行が 30 日を超えると、エンコードされた値を使用して例外の元の値を取得できなくなる場合があります。
ARMS コンソールに一部の例外が表示されないのはなぜですか？
ARMS エージェントはすべての例外をキャプチャできるわけではありません。 エージェントによって収集できるのは、インストゥルメント化されたメソッドによってスローされた例外のみです。
ARMS エージェントが v4.1.12 以降の場合は、2. App Service プランを作成するカスタム構成 タブの セクションで、例外に対応するプラグインをオンにすることができます。 その後、各例外が発生したときに、ARMS は例外データを収集します。