JavaアプリケーションにApplication Real-Time Monitoring Service (ARMS) エージェントをインストールすると、ARMSはアプリケーションのモニタリングを開始します。アプリケーションの詳細ページのインスタンスモニタリングタブで、基本メトリクス、ガベージコレクション (GC)、Java仮想マシン (VM) メモリなど、アプリケーションインスタンスに関する情報を表示できます。
前提条件
アプリケーションモニタリングでは、新しい課金モードを有効にしているユーザー向けに、新しいアプリケーション詳細ページが提供されています。詳細については、課金（新規）を参照してください。
新しい課金モードを有効にしていない場合は、アプリケーション一覧ページで新バージョンに切り替えるをクリックして、新しいアプリケーション詳細ページを表示できます。
アプリケーションにARMSエージェントがインストールされています。詳細については、アプリケーションモニタリングの概要を参照してください。
手順
ARMS consoleにログオンします。左側のナビゲーションペインで、を選択します。
アプリケーション一覧ページで、上部のナビゲーションバーでリージョンを選択し、管理するアプリケーションの名前をクリックします。
説明言語列に表示されるアイコンは、アプリケーションが記述されている言語を示します。
：Javaアプリケーション
：Goアプリケーション
：Pythonアプリケーションハイフン（-）：Managed Service for OpenTelemetryで監視されているアプリケーション。
上部のナビゲーションバーで、インスタンスモニタリングタブをクリックします。
インスタンスモニタリングタブ
インスタンスモニタリングタブには、アプリケーションがElastic Compute Service (ECS) インスタンスまたはコンテナクラスターにデプロイされているかどうか、および環境がManaged Service for Prometheusで監視されているかどうかに基づいて、ダッシュボードデータが表示されます。
アプリケーションがManaged Service for Prometheusで監視されているコンテナクラスターにデプロイされている場合、Managed Service for Prometheusのデータがダッシュボードに表示されます。Managed Service for Prometheusを使用してコンテナクラスターを監視する方法については、ACKクラスターの監視を参照してください。
コンテナー クラスターがManaged Service for Prometheusで監視されていない場合は、ARMS エージェントのバージョンが 4.1.0 以降であることを確認してください。その後、アプリケーションモニタリングのデータが表示されます。Java 用 ARMS エージェントの詳細については、Java 用 ARMS エージェントのリリースノートを参照してください。
ECSインスタンス
クイックフィルターセクション（アイコン1）では、ホストIPアドレスでチャートとインスタンスをクエリできます。
トレンドチャートセクション（アイコン2）では、基本メトリクス、GC、JVMメモリの時系列を表示できます。
インスタンスベースモニタリング：指定された期間におけるCPU使用率、メモリ使用量、ディスク使用量のトレンドチャートを表示します。ドロップダウンリストから平均値と最大値を切り替えます。
インスタンスGC：指定された期間におけるフルGCとヤングGCのトレンドチャートを表示します。GCの数と平均継続時間を切り替えます。
JVMメモリ：ドロップダウンリストから指定された期間内の使用済みヒープメモリと最大ヒープメモリのトレンドチャートを表示します。ヒープメモリと非ヒープメモリを切り替えます。
説明アプリケーションモニタリングによって収集されたデータはJMXからのものであり、Javaプロセスのいくつかの非ヒープメモリ領域は除外されます。したがって、アプリケーションモニタリングに表示されるヒープメモリと非ヒープメモリの合計は、
topコマンドを実行してクエリされたRESとは大きく異なります。詳細については、JVMメモリ詳細を参照してください。
アイコンをクリックします。表示されるダイアログボックスで、特定の期間のメトリックデータを表示したり、異なる日付の同じ期間のメトリックデータを比較したりできます。
アイコンをクリックすると、データを棒グラフまたはトレンドチャートで表示できます。 インスタンスリストセクション（アイコン3）では、IPアドレス、CPU使用率、メモリ使用量、ディスク使用量、負荷、フルGCの数、ヤングGCの数、ヒープメモリ使用量、非ヒープメモリ使用量、およびREDメソッドで定義された各インスタンスの主要メトリクス（レート、エラー、継続時間を含む）などのインスタンス情報を表示できます。
インスタンスリストでは、次の操作を実行できます。
インスタンスのIPアドレスをクリックすると、インスタンスの詳細が表示されます。詳細については、インスタンスの詳細セクションを参照してください。
アクション列のトレースをクリックすると、インスタンスのトレース詳細が表示されます。詳細については、トレースエクスプローラーを参照してください。
Managed Service for Prometheusで監視されているコンテナクラスター
クイックフィルターセクション（アイコン1）では、クラスターIDまたはホストIPアドレスでチャートとインスタンスをクエリできます。
トレンドチャートセクション（アイコン2）では、基本メトリクス、GC、JVMメモリの時系列を表示できます。
インスタンスベースモニタリング：指定された期間におけるCPU使用率とメモリ使用量のトレンドチャートを表示します。
インスタンスGC：指定された期間におけるフルGCとヤングGCのトレンドチャートを表示します。GCの数と平均継続時間を切り替えます。
JVMメモリ：ドロップダウンリストから指定された期間内の使用済みヒープメモリと最大ヒープメモリのトレンドチャートを表示します。ヒープメモリと非ヒープメモリを切り替えます。
説明アプリケーションモニタリングによって収集されたデータはJMXからのものであり、Javaプロセスのいくつかの非ヒープメモリ領域は除外されます。したがって、アプリケーションモニタリングに表示されるヒープメモリと非ヒープメモリの合計は、
topコマンドを実行してクエリされたRESとは大きく異なります。詳細については、JVMメモリ詳細を参照してください。
アイコンをクリックします。表示されるダイアログボックスで、特定の期間のメトリックデータを表示したり、異なる日付の同じ期間のメトリックデータを比較したりできます。アイコンをクリックすると、データを棒グラフまたはトレンドチャートで表示できます。 インスタンスリストセクション（アイコン3）では、IPアドレス、使用済みCPU、リクエスト済みCPU、最大CPU、CPU使用率（％）、使用済みメモリ、リクエスト済みメモリ、最大メモリ、メモリ使用率（％）、使用済みディスクサイズ、最大ディスクサイズ、ディスク使用率（％）、負荷、フルGCの数、ヤングGCの数、ヒープメモリ使用量、非ヒープメモリ使用量、およびREDメソッドで定義された各インスタンスの主要メトリクス（レート、エラー、継続時間を含む）などのインスタンス情報を表示できます。最大CPU、メモリ、またはディスクサイズが設定されていない場合は、CPU使用率、メモリ使用率、またはディスク使用率の代わりに-が表示されます。
インスタンスリストでは、次の操作を実行できます。
インスタンスのIPアドレスをクリックするか、アクション列の詳細をクリックすると、インスタンスの詳細が表示されます。詳細については、インスタンスの詳細セクションを参照してください。
アクション列のトレースをクリックすると、インスタンスのトレース詳細が表示されます。詳細については、トレースエクスプローラーを参照してください。
コンテナクラスター（カスタムデータ収集）
クイックフィルターセクション（アイコン1）では、ホストIPアドレスでチャートとインスタンスをクエリできます。
トレンドチャートセクション（アイコン2）では、基本メトリクス、GC、JVMメモリの時系列を表示できます。
インスタンスベースモニタリング：指定された期間におけるCPU使用率とメモリ使用量のトレンドチャートを表示します。
インスタンスGC：指定された期間におけるフルGCとヤングGCのトレンドチャートを表示します。GCの数と平均継続時間を切り替えます。
JVMメモリ：ドロップダウンリストから指定された期間内の使用済みヒープメモリと最大ヒープメモリのトレンドチャートを表示します。ヒープメモリと非ヒープメモリを切り替えます。
説明アプリケーションモニタリングによって収集されたデータはJMXからのものであり、Javaプロセスのいくつかの非ヒープメモリ領域は除外されます。したがって、アプリケーションモニタリングに表示されるヒープメモリと非ヒープメモリの合計は、
topコマンドを実行してクエリされたRESとは大きく異なります。詳細については、JVMメモリ詳細を参照してください。
アイコンをクリックします。表示されるダイアログボックスで、特定の期間のメトリックデータを表示したり、異なる日付の同じ期間のメトリックデータを比較したりできます。アイコンをクリックすると、データを棒グラフまたはトレンドチャートで表示できます。 インスタンスリストセクション（アイコン3）では、IPアドレス、CPU使用率、メモリ使用量、負荷、フルGCの数、ヤングGCの数、ヒープメモリ使用量、非ヒープメモリ使用量、およびREDメソッドで定義された各インスタンスの主要メトリクス（レート、エラー、継続時間を含む）などのインスタンス情報を表示できます。
インスタンスリストでは、次の操作を実行できます。
インスタンスのIPアドレスをクリックするか、アクション列の詳細をクリックすると、インスタンスの詳細が表示されます。詳細については、インスタンスの詳細セクションを参照してください。
アクション列のトレースをクリックすると、インスタンスのトレース詳細が表示されます。詳細については、トレースエクスプローラーを参照してください。
インスタンスの詳細
概要
概要タブでは、リクエスト数、エラー数、平均継続時間、低速呼び出しを表示できます。
JVMモニタリング
JVMモニタリングタブでは、インスタンスのGC、メモリ、スレッド、ファイルを表示できます。
プーリングモニタリング
プーリングモニタリングタブでは、アプリケーションで使用されるスレッドプールまたはコネクションプールのメトリクス（コアスレッド数、既存スレッド数、許可される最大スレッド数、アクティブスレッド数、タスクキューで許可される最大タスク数を含む）を表示できます。
ホストモニタリング
ホストモニタリングタブでは、CPU使用率、メモリ使用量、ディスク使用量、負荷、トラフィック、パケットに関するメトリクスを表示できます。
コンテナモニタリング
Managed Service for Prometheusで監視されているコンテナクラスター
コンテナクラスターをManaged Service for Prometheusに接続する方法については、Prometheusインスタンスを作成してACKクラスターを監視するを参照してください。
コンテナモニタリングタブでは、CPU使用率、メモリ使用量、ディスク使用量、負荷、トラフィック、パケットに関するメトリクスを表示できます。
コンテナクラスター（カスタムデータ収集）
コンテナクラスターがManaged Service for Prometheusで監視されていない場合は、ARMSエージェントのバージョンが4.1.0以降であることを確認してください。Java用ARMSエージェントについては、Javaエージェントのリリースノートを参照してください。
コンテナモニタリングタブでは、CPU、メモリ、ネットワークトラフィックの時系列を表示できます。
トレースエクスプローラー
トレースエクスプローラーを使用すると、保存されているフルトレースデータに基づいて、フィルター条件と集計ディメンションを組み合わせてリアルタイム分析を実行できます。これは、さまざまなシナリオでのカスタム診断要件を満たすことができます。詳細については、トレースエクスプローラーを参照してください。
関連情報
アプリケーションモニタリングメトリクスの詳細については、アプリケーションモニタリングメトリクスを参照してください。
FAQ
アプリケーションレベルのメトリクスと単一マシンメトリクスの関係は何ですか？
REDメトリクス（レート、エラー、継続時間）：
リクエスト数、低速呼び出し数、HTTPステータスコード頻度：アプリケーションレベルのメトリクスは、対応する単一マシンメトリクスの集計合計です。
応答時間：アプリケーションレベルのメトリクスは、すべてのマシン全体の平均応答時間を表します。
JVMメトリクス：
GC頻度と継続時間：アプリケーションレベルのメトリクスは、単一マシンメトリクスの合計です。
ヒープメモリ使用量とスレッド数：アプリケーションレベルのメトリクスは、単一マシン間で観測された最大値を取ります。
スレッドプールとコネクションプールのメトリクス
このカテゴリのすべてのメトリクスについて、アプリケーションレベルのデータは単一マシンメトリクスの平均です。
システムメトリクス
すべてのシステムメトリクスについて、アプリケーションレベルのデータは単一マシン間で観測された最大値を取ります。
SQLおよびNoSQL呼び出し：REDメトリクスと同様に、頻度メトリクスは単一マシンメトリクスの集計合計です。その他のメトリクスは、すべてのマシン全体の平均値を表します。
例外メトリクス：アプリケーションレベルのすべての例外関連メトリクスは、単一マシンメトリクスの集計合計です。
インスタンス間のトラフィックが不均一なのはなぜですか？
メモリ最適化が有効になっている場合、ARMSエージェントv3.xでは一部のメトリックデータが欠落する可能性があります。エージェントv4.xではこの問題は修正されています。
Undertowリクエストが2回カウントされたのはなぜですか？
v3.2.xより前のARMSエージェントは、DeferredResultを使用すると実装メソッドを2回実行します。エージェントv3.2.x以降ではこの問題は修正されています。
コンテナのCPU/メモリクォータがポッドの実際の設定と一致しないのはなぜですか？
ポッドに複数のコンテナが定義されているかどうかを確認します。CPU/メモリクォータは、ポッド内のすべてのコンテナの合計クォータを集計します。
一部のシステムメトリクスが欠落しているか不正確なのはなぜですか？CPU使用率が100%なのはなぜですか？
v4.xより前のARMSエージェントは、Windows環境でのシステムメトリクスの収集をサポートしていません。ARMSエージェントv4.x以降ではこの問題は修正されています。
アプリケーションの起動時にフルGCがトリガーされたのはなぜですか？
これは、メタスペースサイズを設定していないことが原因である可能性があります。デフォルトのメタスペースサイズは20 MBです。アプリケーションの起動時に、メタスペースが拡張されてフルGCがトリガーされる場合があります。-XX:MetaspaceSizeパラメーターとXX:MaxMetaspaceSizeパラメーターを使用して、初期メタスペースサイズと最大メタスペースサイズを設定できます。
VMスタックの合計サイズはどのように計算されますか？
デフォルトのスレッドスタックサイズ（1 MB）が-Xssパラメーターによって変更されている場合、VMスタックの合計サイズは、スレッド数にスレッドスタックサイズを掛けて計算されます。それ以外の場合、VMスタックの合計サイズは、スレッド数に1 MBを掛けて計算されます。
JVMメトリクスはどのように取得されますか？
ARMSのJVMメトリクスは、次の標準JDKインターフェースを介して取得されます。
メモリメトリクス
ManagementFactory.getMemoryPoolMXBeans
java.lang.management.MemoryPoolMXBean#getUsage
GCメトリクス
ManagementFactory.getGarbageCollectorMXBeans
java.lang.management.GarbageCollectorMXBean#getCollectionCount
java.lang.management.GarbageCollectorMXBean#getCollectionTime
JVMの最大ヒープメモリが-1なのはなぜですか？
-1は、最大ヒープメモリサイズが設定されていないことを示します。
使用済みJVMヒープメモリが最大ヒープメモリと等しくないのはなぜですか？
JVMメモリ割り当てメカニズムのコンテキストでは、-Xmsパラメーターはヒープメモリの初期サイズを設定します。アプリケーションの実行中に残りのヒープメモリが不足すると、JVMは-Xmxパラメーターで指定された最大ヒープサイズに達するまでヒープサイズを段階的に増加させます。割り当てられたメモリの合計が最大値よりも小さい場合、これはヒープがまだ最大容量まで拡張されていないことを示します。使用済みメモリは、アプリケーションによって現在使用されているヒープメモリの実際の量を表します。
JVM GCの頻度が増加するのはなぜですか？
JVM GCの頻度が増加するのは、JDK 8のデフォルトのGCアルゴリズムであるParallel GCを使用していることが原因である可能性があります。このアルゴリズムは、デフォルトで-XX:+UseAdaptiveSizePolicyを有効にし、ヤングジェネレーションサイズやSurvivorRatioなどのヒープサイズパラメーターを自動的に調整して、GC一時停止時間の目標を達成します。ヤングGCが頻繁に発生すると、サバイバー空間のサイズが動的に縮小される可能性があります。その結果、サバイバー空間のオブジェクトがオールドジェネレーションに昇格しやすくなり、オールドジェネレーション空間が急速に増加し、その結果、フルGCの頻度が増加します。詳細については、Javaドキュメントを参照してください。
スレッドプールまたはコネクションプールのモニタリングデータが欠落しているのはなぜですか？
カスタム設定タブの詳細設定セクションで、スレッドプールまたはコネクションプールのモニタリングが有効になっているかどうかを確認します。
アプリケーションのフレームワークがサポートされているかどうかを確認します。詳細については、スレッドプールとコネクションプールのモニタリングを参照してください。
HikariCPコネクションプールから取得した最大接続数が正しくないのはなぜですか？
これは、v3.2.xより前のARMSエージェントのコーディングの問題が原因です。エージェントv3.2.x以降ではこの問題は修正されています。
プールモニタリングメトリクスの値が小数で表示されるのはなぜですか？
ARMSエージェントは15秒ごとにデータを収集するため、1分あたり4つのデータポイントを収集します。ARMSコンソールは、この収集データに基づいて、指定された期間の平均値を表示します。1分間に収集された4つのデータポイントが0、0、1、0であるとします。理論上の平均は0.25です。
ログやその他のレコードに示されているように、スレッドプールまたはコネクションプールが完全に使用されているときに、スレッドプールまたはコネクションプールのメトリクスが増加しないのはなぜですか？
メトリックのサンプリング時間とプールが完全に使用された時間の不一致が原因である可能性があります。ARMSは15秒ごとにスレッドプールとコネクションプールのステータスメトリクスを自動的に収集するため、この間隔内で発生する瞬間的なスパイクはキャプチャされない場合があります。
スレッドプールの最大スレッド数が想定どおりではないのはなぜですか？最大スレッド数が21億なのはなぜですか？
スレッドプールの最大サイズは、スレッドプールオブジェクトから最大スレッド数を取得するメソッドを直接呼び出すことによって取得されます。これは一般的に正しいです。想定どおりでない場合は、ユーザー定義の最大スレッド数が有効になっていないことが原因である可能性があります。
最大スレッド数が21億の場合、これは通常、スケジュールされたスレッドプールを示します。スケジュールされたスレッドプールでは、次の図に示すように、デフォルトの最大スレッド数はInteger.MAX_VALUEに設定されています。
