Application Real-Time Monitoring Service:Java アプリケーションインスタンス監視

[インスタンス監視] タブには、アプリケーションが 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 以降であることを確認してください。この場合、Application Monitoring のデータが表示されます。Java 用 ARMS エージェントの詳細については、「Java 用 ARMS エージェントのリリースノート」をご参照ください。

概要

[アクション] 列の [トレース] をクリックすると、インスタンスのトレース詳細を表示できます。 詳細については、「トレースエクスプローラー」をご参照ください。

JVM 監視

[JVM モニタリング] タブでは、インスタンスの GC、メモリ、スレッド、およびファイルを表示できます。

スレッドプール監視

接続プール監視

ホスト監視

[ホスト監視] タブでは、CPU 使用率、メモリ使用量、ディスク使用率、負荷、トラフィック、パケットに関するメトリクスを表示できます。

コンテナ監視

トレースエクスプローラー

トレースエクスプローラーを使用すると、保存されている完全なトレースデータに基づいて、フィルター条件と集計ディメンションを組み合わせてリアルタイム分析を実行できます。 これは、さまざまなシナリオのカスタム診断要件を満たすことができます。 詳細については、「トレースエクスプローラー」をご参照ください。

アプリケーションレベルのメトリクスと単一マシンのメトリクスの関係はどのようなものですか?

• 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 以降では、この問題が修正されています。

アプリケーションの起動時に Full GC がトリガーされたのはなぜですか?

これは、メタスペースサイズを設定していないことが原因である可能性があります。 デフォルトのメタスペースサイズは 20 MB です。 アプリケーションの起動時に、メタスペースが拡張されて Full GC がトリガーされる場合があります。 初期メタスペースサイズと最大メタスペースサイズは、-XX:MetaspaceSize パラメーターと -XX:MaxMetaspaceSize パラメーターを使用して設定できます。

合計 VM スタックサイズはどのように計算されますか?

このメトリックは、ライブ スレッド (状態: live、blocked、new、runnable、timed-wait、wait) の数にデフォルトの 1 MB スタックサイズを掛けて計算されます。-Xss を介してスタックサイズが変更された場合、このメトリックは不正確になります。

JVM メトリクスはどのように取得されますか？

ARMS は、次の標準 JDK インターフェイスを使用して JVM メトリクスを取得します。

• メモリメトリクス:

  • ManagementFactory.getMemoryPoolMXBeans

  • java.lang.management.MemoryPoolMXBean#getUsage

• GC メトリクス:

JVM の最大ヒープメモリが -1 なのはなぜですか?

-1 は、最大ヒープメモリサイズが設定されていないことを示します。

使用済み JVM ヒープメモリが最大ヒープメモリと等しくないのはなぜですか?

JVM メモリ割り当てメカニズムのコンテキストでは、-Xms パラメーターはヒープメモリの初期サイズを設定します。アプリケーションの実行中に残りのヒープメモリが不足すると、JVM は -Xmx パラメーターで指定された最大ヒープサイズに達するまで、ヒープサイズを段階的に増加させます。割り当てられたメモリ合計が最大値より小さい場合、これはヒープがまだ最大容量まで拡張されていないことを示します。使用済みメモリは、アプリケーションによって現在使用されているヒープメモリの実際の量を表します。

JVM GC の頻度が増加するのはなぜですか？

JVM GC の頻度が増加する原因は、JDK 8 のデフォルトの GC アルゴリズムである Parallel GC の使用にある可能性があります。このアルゴリズムは、デフォルトで -XX:+UseAdaptiveSizePolicy を有効にし、GC の一時停止時間目標を満たすために、Young 世代サイズや SurvivorRatio などのヒープサイズパラメータを自動的に調整します。Young GC が頻繁に発生すると、Survivor スペースのサイズが動的に縮小される場合があります。その結果、Survivor スペース内のオブジェクトが Old 世代に昇格しやすくなり、Old 世代スペースが急速に増加し、結果として Full GC の頻度が増加します。詳細については、「Java ドキュメント」をご参照ください。

スレッドプールまたは接続プール監視のデータが欠落しているのはなぜですか?

1. [詳細設定] セクションの [カスタム設定] タブで、スレッドプールまたは接続プール監視が有効になっているかどうかを確認します。

2. アプリケーションのフレームワークがサポートされているかどうかを確認します。詳細については、「スレッドプールと接続プール監視」をご参照ください。

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 に設定されています。

Tomcat スレッドプールメトリクスが期待どおりでない場合はどうすればよいですか?

ARMS スレッドプールメトリクスは、スレッドプールオブジェクトの対応するメソッドを呼び出すことによって直接取得されるため、通常はエラーが発生しません。いくつかのディメンション（最大スレッド数、アクティブスレッド数、コア スレッド数など）が一致しない場合は、まず、アプリケーションが複数のポートを介して Tomcat サービスを提供しているかどうかを確認します（たとえば、spring-actuator のようなコンポーネントもメトリクスを公開するためにポートを開きます）。このような場合、ディメンション収束メカニズムにより、ARMS エージェントは統計中に複数のスレッドプールからのデータを結合する場合があります。データが結合されている場合は、エージェントバージョンを 4.1.10 以降にアップグレードし、[カスタム設定] タブの [プール済み監視設定] セクションで、スレッドプール スレッド名パターン抽出ポリシー パラメーターを 末尾の数字 * を置換 に変更します。

特定の時点より前に、特定のスレッドプールまたは接続プールにデータがないのはなぜですか?

ビジネスはスケジュールされたタスクを開始し、初期化時にスレッドプールまたは接続プール用のデータを生成します。 タスクがトリガーされるまで、対応するスレッドプールまたは接続プールのデータはありません。 これは、特定のインターフェイスのリクエスト数などのトラフィックタイプのデータでよく発生します。

HTTPClient 接続プールにデータがないのはなぜですか？

ARMS エージェント V4.x 以降では、okHttp3 や Apache HTTPClient などのフレームワークの接続プール監視がサポートされなくなりました。この決定は、これらのフレームワークが現在のアプリケーションによってアクセスされる外部ドメイン名ごとに接続プールオブジェクトを作成するという点を考慮して行われました。多くの外部ドメインにアクセスする場合、これは大きなオーバーヘッドにつながり、安定性のリスクをもたらす可能性があります。したがって、これらの接続プールの監視のサポートは廃止されました。

ACK 環境にアプリケーションを統合した後、コンテナ監視データが表示されないのはなぜですか?

これは、ACK クラスターの作成に使用した Alibaba Cloud アカウントと ARMS の統合に使用した Alibaba Cloud アカウントが異なることが原因である可能性があります。現在、ARMS は同じ Alibaba Cloud アカウント内のコンテナ監視データのみを表示することをサポートしています。

ハンドルオープン率が 0 ではないのに、ファイルハンドルの数が 0 の場合はどうすればよいですか？

お使いのアプリケーション環境が JDK 9 以降で、ARMS エージェントのバージョンが 3.x であるかをご確認ください。該当する場合、この問題は、この環境におけるメトリック収集ロジックの互換性の問題が原因で発生します。この問題は、エージェント V4.2.2 以降で修正済みです。エージェントをアップグレードすることを推奨します。

JVM プロセスの実際の物理メモリ使用量と JVM 監視に表示されるヒープメモリ使用量が大きく異なるのはなぜですか?

これは、JVM プロセスに大量のオフヒープメモリ使用量があることが原因である可能性があります。現在、ARMS は JVM プロセスのインヒープメモリとオフヒープメモリ使用量の一部のみを監視できます。ARMS で監視できる JVM メモリ使用量の部分と監視できない部分については、「JVM メモリの詳細」をご参照ください。オフヒープメモリ使用量が高い場合は、「非ヒープメモリ」セクションを参照して独自の分析を実行できます。

Druid 接続プールのリアルタイムのアイドル接続数が、セットされた最大アイドル接続数を超えるのはなぜですか？

MaxIdle パラメーターは、DBCP ユーザーの移行を容易にするために Druid によって導入されましたが、実際には有効になりません。

一部のインスタンスエージェントを最新バージョンにアップグレードした後、データが欠落するのはなぜですか？

これらのエージェントが 4.1.x より前のバージョンからアップグレードされた場合、ページが自動的に適応してデータを表示できるように、すべてのインスタンスエージェントを最新バージョンにアップグレードする必要があります。