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

環境別のメトリクス

利用可能なメトリクスは、アプリケーションが ECS で実行されているか、コンテナで実行されているか、およびコンテナ環境が Managed Service for Prometheus と統合されているかどうかによって異なります。

トレンドグラフのメトリクス：

ECS 環境では、各インフラストラクチャグラフのタイトルの横にあるドロップダウンリストを使用して、平均値と最大値を切り替えることができます。

GC グラフでは、GC 回数と平均 GC 時間を切り替えます。JVM メモリグラフでは、ヒープメモリと非ヒープメモリのビューを切り替えます。

インスタンスリストの列：

コンテナ (Prometheus) 環境では、リソースに制限が設定されていない場合、CPU 使用率、メモリ使用率、およびディスク使用率に [-] が表示されます。

コンテナ環境の要件：

• Managed Service for Prometheus を使用する場合：コンテナメトリクスは Managed Service for Prometheus から取得されます。統合を設定するには、「Container Observability」をご参照ください。

• Managed Service for Prometheus を使用しない場合：アプリケーションモニタリングプローブをバージョン 4.1.0 以降にアップグレードしてください。以前のプローブバージョンでは、基本的なコンテナメトリクスが報告されません。プローブバージョンの詳細については、「プローブ (Java Agent) バージョンガイド」をご参照ください。

グラフの操作

各トレンドグラフは、次の 2 つのアクションをサポートしています。

• をクリックして、期間のメトリクス統計を表示、または異なる日付の同じ期間を比較します。

• をクリックして、縦棒グラフとトレンドグラフを切り替えます。

インスタンスリストのアクション

• インスタンス詳細を開くには、インスタンス IP (またはコンテナ環境の場合は [アクション] 列の [詳細]) をクリックします。

• [アクション] 列の [トレース] をクリックして、トレース詳細を表示します。 詳細については、「トレース分析」をご参照ください。

概要

[概要] タブには、選択されたインターフェースのリクエスト数、エラー数、平均レスポンス時間、および低速コール情報が表示されます。

左側の [ホストリスト] でホストを切り替えて、モニタリングデータを表示できます。サマリーカードには、前日比のパーセンテージ変化が表示されます。カードの下にある時系列トレンドチャートには、Requests/1m、Errors/1m、および Response Time/1m が 1 分単位で表示されます。このページには、[JVM モニタリング]、[ホストモニタリング]、および [トレース分析] タブも含まれています。

JVM 監視

[JVM モニタリング] タブには、選択されたインスタンスの GC、メモリ、スレッド、およびファイル記述子のメトリクスが表示されます。

GC セクションには、「Full GC 回数/1分」、「Young GC 回数/1分」、「Full GC トリガー理由/1分」、および 「Young GC トリガー理由/1分」 のグラフが含まれています。メモリセクションには、「メモリ使用量分布/1分」、「ヒープメモリ/1分」、「ヒープメモリ (使用量)/1分」、およびその他のグラフが含まれています。左側のパネルでは、特定のアプリケーションインスタンスを選択して、その監視データを表示できます。

スレッドプール監視

スレッドプール監視は、コアスレッド構成、アクティブスレッドステータス、およびタスク実行メトリクスを追跡します。タブの上部でタイプと名前でスレッドプールをフィルタリングできます。

コネクションプール監視

コネクションプール監視は、初期化構成とランタイム接続ステータスを追跡します。タブの上部でタイプでコネクションプールをフィルタリングできます。

ホスト監視

[ホストモニタリング] タブには、CPU、メモリ、ディスク、ロード、ネットワークトラフィック、ネットワークパケットのメトリクスが表示されます。

コンテナ監視

[コンテナモニタリング] タブには、コンテナレベルのリソースメトリックが表示されます。利用できるメトリックは、統合方法によって異なります。

[コンテナモニタリング] タブの「概要」エリアには、名前空間、クラスター、CPU (コア) とメモリの平均/最大/最新/制限に関する概要メトリクスが表示されます。その下の「リソース」エリアには、以下の 4 つの折れ線グラフが含まれています。

• メモリ/制限 (%)

• メモリ使用量

• CPU 使用率 (%)

• コア別 CPU 使用率 (ユーザー/システム/合計の曲線)

トレース分析

トレース分析は、保存されたトレースデータをリアルタイムでクエリします。フィルタと集計ディメンションを組み合わせて、さまざまなシナリオでパフォーマンスの問題を診断します。詳細については、「トレース分析」をご参照ください。

トレーシングコンソールで、serviceName: "mall-gateway" などの検索条件を入力してトレースデータをクエリします。このページには次の内容が含まれています。

• 左側のクイックフィルタパネル：[Status]、[Duration] (スライダー範囲 0 ns ～ 5 s)、[Interface Name]、および [Host Address] でフィルタリングできます。

• 上部の統計グラフ：[Call Count] ヒストグラム、[Errors/HTTP Errors] ヒストグラム、[Average Duration] 折れ線グラフ。

• 下部スパンのデータテーブルの列には、トレース ID、インターフェース名、アプリケーション名、期間、ステータス、開始時刻、ホストアドレス があります。[詳細] または [ログ] をクリックすると、トレース詳細を表示できます。

• 右側の[低速トレース分析]パネル: 所要時間への貢献度順に上位の spanName を表示します。

インスタンス間でトラフィックが不均等なのはなぜですか？

プローブバージョン 3.x では、メモリ最適化を有効にすると、一部のメトリクスが欠落する場合があります。プローブバージョン 4.x にアップグレードしてください。

単一の Undertow リクエストが 2 回カウントされるのはなぜですか？

プローブバージョン 3.2.x より前では、DeferredResult のインストルメンテーションにより、1 回の呼び出しが 2 回記録されます。プローブバージョン 3.2.x 以降にアップグレードしてください。

コンテナ監視の CPU またはメモリのクォータが Pod の設定と一致しないのはなぜですか？

Pod が複数のコンテナを定義しているかどうかを確認してください。このメトリクスは、Pod 内のすべてのコンテナのクォータの合計です。

一部のシステムメトリクスが欠落している、不正確である、または CPU 使用率が 100% と表示されるのはなぜですか？

プローブバージョン 4.x より前では、Windows でシステムメトリクスを収集しません。プローブバージョン 4.x 以降にアップグレードしてください。

アプリケーション起動直後に Full GC が発生するのはなぜですか？

デフォルトのメタスペースサイズは約 20 MB です。起動時にメタスペースが拡張され、Full GC がトリガーされます。-XX:MetaspaceSize および -XX:MaxMetaspaceSize パラメータを使用して、初期および最大メタスペースサイズを設定してください。

VM Stack はどのように計算されますか？

VM Stack は、稼働中のスレッド数に 1 MB (デフォルトのスレッドスタックサイズ) を掛けて計算されます。-Xss で異なるスタックサイズを設定した場合、このメトリクスは実際の値と一致しない可能性があります。

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

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

メモリメトリクス：

• ManagementFactory.getMemoryPoolMXBeans

• java.lang.management.MemoryPoolMXBean#getUsage

GC メトリクス (プローブ 4.4.0 より前)：

• ManagementFactory.getGarbageCollectorMXBeans

• GarbageCollectorMXBean#getCollectionCount

• GarbageCollectorMXBean#getCollectionTime

GC メトリクス (プローブ 4.4.0 以降)：

GarbageCollectionNotificationInfo イベントを GarbageCollectorMXBean からサブスクライブすることで取得されます。

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

値が -1 の場合、最大ヒープサイズが設定されていないことを意味します。-Xmx パラメータを使用して設定してください。

JVM ヒープメモリ使用量が最大ヒープメモリサイズと等しくないのはなぜですか？

-Xms パラメータは初期ヒープサイズを設定します。JVM は必要に応じてヒープを拡張し、-Xmx で設定された最大値に達します。不一致は、ヒープがまだ完全に拡張されていないことを意味します。

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

これは通常、JDK 8 のデフォルト GC アルゴリズムである ParallelGC で発生します。ParallelGC はデフォルトで -XX:+UseAdaptiveSizePolicy を有効にし、ヒープサイズを動的に調整します。Young GC が頻繁に実行されると、サバイバー領域が縮小し、オブジェクトが旧世代により早く昇格する可能性があります。これにより、旧世代の成長が加速し、より頻繁な Full GC がトリガーされます。詳細については、Java GC Ergonomics のドキュメントをご参照ください。

スレッドプールまたはコネクションプール監視のデータがないのはなぜですか？

1. [カスタム設定]ページで、[詳細設定]で、スレッドプールと接続プールの監視が有効になっていることを確認します。

2. 「Thread pool and connection pool monitoring」をご参照のうえ、お使いのフレームワークがサポート対象であることを確認してください。

HikariCP の最大接続数が期待値と一致しないのはなぜですか？

プローブバージョン 3.2.x より前では、最大接続数を正しく取得できません。プローブバージョン 3.2.x 以降にアップグレードしてください。

プール監視メトリクスが小数値として表示されるのはなぜですか？

プローブは 15 秒ごとにデータを収集します。コンソールには、選択した期間の平均値が表示されます。たとえば、1 分間の 4 つのデータポイントが 0、0、1、および 0 の場合、表示される値は 0.25 です。

スレッドプールまたはコネクションプールがいっぱいなのに、監視に変化が表示されないのはなぜですか？

ARMS は 15 秒ごとにスレッドプールとコネクションプールのメトリクスを収集します。この間隔内の短期的なスパイクはキャプチャされない場合があります。

スレッドプールの最大スレッド数が予期しない値または 21 億と表示されるのはなぜですか？

ARMS は、スレッドプールオブジェクトから最大スレッド数を直接読み取ります。21 億という値は、通常、スケジュールされたスレッドプールを示しており、デフォルトで Integer.MAX_VALUE に設定されています。

/**
 * 指定されたコアプールサイズで新しい ScheduledThreadPoolExecutor を作成します。
 * @param corePoolSize アイドル状態でもプールに保持するスレッドの数
 *        (allowCoreThreadTimeOut が設定されていない場合)
 * @throws IllegalArgumentException corePoolSize < 0 の場合
 */
public ScheduledThreadPoolExecutor(int corePoolSize) {
    super(corePoolSize, Integer.MAX_VALUE, 0, NANOSECONDS,
            new DelayedWorkQueue());
}

/**
 * 指定された初期パラメータで新しい ScheduledThreadPoolExecutor を作成します。
 * @param corePoolSize アイドル状態でもプールに保持するスレッドの数
 *        (allowCoreThreadTimeOut が設定されていない場合)
 * @param threadFactory エグゼキュータが新しいスレッドを作成する際に使用するファクトリ
 * @throws IllegalArgumentException corePoolSize < 0 の場合
 * @throws NullPointerException threadFactory が null の場合
 */
public ScheduledThreadPoolExecutor(int corePoolSize,
                        ThreadFactory threadFactory) {
    super(corePoolSize, Integer.MAX_VALUE, 0, NANOSECONDS,
            new DelayedWorkQueue(), threadFactory);
}

Tomcat スレッドプールメトリクスが期待値と一致しないのはなぜですか？

複数のメトリクス (最大スレッド数、アクティブスレッド数、コアスレッド数) がすべて期待値と異なる場合は、アプリケーションが複数のポートで Tomcat サービスを公開しているかどうかを確認してください。たとえば、Spring Actuator はメトリクス用に追加のポートを開きます。この場合、ARMS はディメンション収束により複数のスレッドプールのメトリクスをマージする可能性があります。

これを修正するには、probe をバージョン 4.1.10 以降にアップグレードします。 次に、[アプリケーション設定] > [カスタム設定] > [プーリング監視設定] に移動し、[スレッドプールのスレッド名パターンの抽出ストラテジー] を Replace trailing digits with * に設定します。

特定の時刻より前にスレッドプールまたはコネクションプールのデータがないのはなぜですか？

これは、スケジュールされたタスクがプールを作成する場合に発生します。データは、タスクがプールを初期化した後にのみ表示されます。API リクエスト数などのトラフィックベースのメトリクスも同様に動作します。

HttpClient コネクションプールのデータがないのはなぜですか？

ARMS プローブバージョン 4.x 以降、OkHttp3 および Apache HttpClient のコネクションプール監視はサポートされなくなりました。これらのフレームワークは、外部ドメインごとに個別のコネクションプールを作成します。多数のドメインが関与する場合、これにより過度のオーバーヘッドと安定性のリスクが発生します。

ACK アプリケーションを統合した後、コンテナ監視データがないのはなぜですか？

ARMS は、同じ Alibaba Cloud アカウント下のリソースに対してのみコンテナ監視データを表示します。ACK クラスタの作成に使用したアカウントが、ARMS 統合に使用したアカウントと一致することを確認してください。

ファイルハンドルのオープン率がゼロ以外なのに、ファイルハンドル数がゼロなのはなぜですか？

「Upgrade the ARMS agent」をご参照のうえ、プローブをバージョン 4.2.2 以降にアップグレードしてください。これは、ARMS プローブバージョン 3.x を使用して JDK 9 以降で発生します。

JVM プロセスの物理メモリ使用量が JVM 監視のヒープメモリ使用量と大きく異なるのはなぜですか？

JVM プロセスは、ARMS が完全には監視していない大量のオフヒープメモリを使用している可能性があります。ARMS がカバーする JVM メモリ領域の詳細については、「JVM 監視メモリの詳細」をご参照ください。

Druid が最大アイドル接続設定よりも多くのアイドル接続を表示するのはなぜですか？

Druid の MaxIdle パラメータは、DBCP 移行互換性のためにのみ存在します。機能的な効果はありません。

一部のインスタンスを最新のプローブバージョンにアップグレードした後、データがないのはなぜですか？

プローブバージョン 4.1.x より前からアップグレードする場合、すべてのインスタンスをアップグレードする必要があります。すべてのインスタンスが同じバージョンで実行されると、ページは自動的に適応します。