Application Real-Time Monitoring Service:よくある質問

1. 設定が正しいことを確認してください。設定された CIDR ブロックにアプリケーションインスタンスの IP アドレスが含まれていることを確認してください。

2. 3.1.4 より前のバージョンのエージェントを使用している場合、Alpine ベースイメージとの互換性の問題により、プロファイリングエンジンが失敗することがあります。この問題はバージョン 3.1.4 で修正されています。安定性とデータの整合性を確保するために、エージェントをバージョン 3.1.4 以降にアップグレードすることを推奨します。

   説明

   Alpine Linux ベースイメージを使用しているかどうかを確認するには、「関連操作」をご参照ください。

3. 継続的プロファイリングは、データ収集に強化されたオープンソースの Async Profiler を使用しており、複数の Async Profiler を同時にマウントすることはサポートしていません。アプリケーションが Pyroscope エージェントの継続的プロファイリング機能も使用している場合、アプリケーションの起動に失敗することがあります。

4. 継続的プロファイリングのページで、クエリ時間を 8 時間早めて設定し、データが表示されるか確認してください。データが表示される場合、アプリケーションのタイムゾーンが UTC+0 に設定されている可能性があります。これにより、UTC+8 と比較して 8 時間のデータ書き込み遅延が発生します。

   解決策：アプリケーションに環境変数を追加して、タイムゾーンを UTC+8 に調整してください。

   説明

   まず、継続的プロファイリングのページで現在の Pod 名でフィルタリングし、過去 8 時間以内の複数回のコンテナ再起動による混乱を避けてください。

   Key: JAVA_TOOL_OPTIONS, Value: -Duser.timezone=GMT+8

   この問題は、エージェントのバージョン 4.1.10 で修正されています。これが問題であることを確認した場合、エージェントをバージョン 4.1.10 以降にアップグレードすることもできます。

5. アプリケーションが他の Async Profiler 動的ライブラリをマウントしているかどうかを確認します：

   1. 次のコマンドを実行します。[pid] をアプリケーションのプロセス ID に置き換えてください。

      lsof -p [pid] | grep libasync

   2. 結果に以下に示すような Alibaba Cloud 以外の動的ライブラリが含まれている場合、アプリケーションは独自の Async Profiler 動的ライブラリを使用しています。このライブラリは Application Real-Time Monitoring Service (ARMS) と互換性がありません。ARMS の機能を使用するには、独自の動的ライブラリを削除する必要があります。

      /home/admin/xxx/.default/temp/libasyncProfiler1309163652530490111.so

新しい継続的プロファイリングでストレージ料金が変更された理由

報告されるボリュームが変更された主な理由は次のとおりです：

• 継続的プロファイリングは、元の継続的プロファイリング機能と完全に互換性のある新しい機能です。複数インスタンスにまたがる集計クエリ、スレッドレベルの分析、および Copilot によるインテリジェントなフレームグラフ分析をサポートしています。

• ストレージ構造が変更されました。ユーザーがプロファイリングデータの二次分析を実行できるように、ストレージ媒体が組み込みの Object Storage Service (OSS) からアカウント内の Simple Log Service (SLS) インスタンスに移行しました。SLS プロジェクトは proj-xtrace-<encode>-<region-id> で、SLS Logstore は logstore-profiling です。この変更は、保存されるプロファイリングデータの量と、それに対応するストレージ料金に影響します。

データクエリでサポートされる時間範囲

継続的プロファイリングデータは 7 日間保存されます。この期間のデータをクエリできます。

問題

フレームグラフに「other」項目が表示されます。たとえば、プロファイリングタイプとして [Allocated Memory] を選択した分析結果では、メモリ割り当てランキングテーブルで [other] 項目 (6.41 MB) がオレンジ色でハイライト表示され、特定の Java メソッド (たとえば AbstractQueuedSynchronizer$ConditionObject.addConditionWaiter() 8.99 MB と java.util.Arrays.copyOfRange(char[], int, int) 8.90 MB) の間に配置されます。右側のフレームグラフには、対応する呼び出しスタック階層が表示されます。

原因

フレームグラフの「other」項目は正常です。フレームグラフはツリー構造を持っています。ノードが多すぎると、主要な情報を特定するのが困難になることがあります。ARMS は、重要度の低いノードを「other」カテゴリにまとめることで、グラフを簡素化し、重要な情報を強調表示します。

ARMS エージェントがこの情報ログメッセージを出力します。これは、継続的プロファイリングを有効にした後にのみ表示され、アプリケーションの実行時パフォーマンスには影響しません。ARMS は将来のバージョンでこのログ出力を無効にする予定です。

問題

Async-Profiler は、CPU プロファイリングのために perf_event_open システムコールに依存しています。しかし、seccomp などの Linux カーネルのセキュリティポリシーにより、プロセスによる特定のシステムコールの使用がブロックされる場合があります。

[ERROR] Failed to execute 'start,jfr=0,event=cpu,interval=11ms,alloc=512k,file=/tmp/cpc-async-profiler-7729534006755968198.jfr'
[ERROR] Failed to start Continuous Profile Collector
java.lang.RuntimeException: java.lang.IllegalStateException: No access to perf events. Try --fdtransfer or --all-user option or 'sysctl kernel.perf_event_paranoid=1'

解決策

• Docker 環境の場合、次のコマンドでコンテナを実行してください。システムコールのより詳細な制御については、公式ドキュメントをご参照ください。

    docker run --security-opt seccomp=unconfined  XXX

• Kubernetes 環境の場合、特権コンテナのパラメーターを privileged: true に設定してください。特権コンテナは常に Unconfined です。

  システムコールのより詳細な制御については、公式ドキュメントをご参照ください。

問題

このエラーは通常、Java 仮想マシン (JVM) の標準出力に表示されます。継続的プロファイリングが CPU ホットスポットをサンプリングする際、ネイティブスタック (Linux カーネル、JVM、および C/C++) と Java スタックの両方を収集します。ネイティブスタックを収集するには、各 Java スレッドの perf_event ファイル記述子に対してメモリマップ (MMap) を実行する必要があります。Linux カーネルは、これらの MMap 操作の合計メモリを制限します。デフォルトの制限は 516 KB です。Java アプリケーションに多数のスレッドがある場合、この制限を超える可能性があります。これにより、Java の標準出力に perf_event mmap failed... という警告がトリガーされます。この警告は、Java アプリケーションやビジネスロジックには影響しません。唯一の副作用は、フレームグラフにネイティブスタックが表示されなくなることです。通常、CPU ホットスポットの診断には Java メソッドスタックで十分であるため、この警告は無視できます。

解決策

このエラーメッセージを解消するには、次の手順を実行してください：

1. ホストマシンで、次のコマンドを実行してください。

   echo 1028 > /proc/sys/kernel/perf_event_mlock_kb

   デフォルトのしきい値は 516 です。警告が止まるまでこの値を増やすことができます。値は、N を自然数として、数式 8*N + 4 に従う必要があります。たとえば、516 = 512 + 4、1028 = 1024 + 4 です。

2. エラーを解決するには、Docker を再起動してください。

お使いの環境の JDK にデバッグシンボルが含まれているかどうかの確認

デバッグシンボルがないと、メモリホットスポットのアクティベーションに失敗します。その結果、メモリホットスポットのデータは収集できません。

• エージェントログでデバッグシンボルが欠落しているかを確認してください。

  エージェントのインストールディレクトリで、logs ディレクトリに cpc.log ファイルがあるか確認してください。一部の古いバージョンのエージェントでは、このファイルは logs/arms_log ディレクトリにあります。ログにキーワード No AllocTracer symbols found. Are JDK debug symbols installed? が含まれている場合、デバッグシンボルが欠落していることを意味します。

  2023-03-08 11:32:00 [continuous Profile collector] [INFO]
  Some or all engines success, details below
  CPU:true
  Alloc:false:No AllocTracer symbols found. Are JDK debug symbols installed?
  Wall:true
  Other:false
  Lock:false

• コマンドを使用して、環境にデバッグシンボルが欠落しているかどうかを確認してください。

  • JDK のインストールパスに移動してください。

    環境内の JDK インストールパスは、which java コマンドまたは echo $JAVA_HOME を使用して見つけることができます。

  • JDK インストールパスのトップレベルから、次のコマンドを実行して libjvm.so ファイルへのパスを見つけてください。

    find ./ -name "*libjvm.so*"

  • 次のコマンドを実行して、ファイルからデバッグシンボルが削除 (strip) されているかどうかを確認してください。/path/to/ を実際のパスに置き換えてください。

    file /path/to/libjvm.so

    コマンドが not stripped を返した場合は、お使いの環境の JDK にはデバッグシンボルが含まれています。stripped を返した場合は、デバッグシンボルは含まれていません。

    [root@iZj6cbirlzrhmgljxdfxw9Z jdk-directory]# cd jdk8u412-b08
    [root@iZj6cbirlzrhmgljxdfxw9Z jdk8u412-b08]# ls
    ASSEMBLY_EXCEPTION  LICENSE  NOTICE  THIRD_PARTY_README  bin  include  jre  lib  man  release  sample  src.zip
    [root@iZj6cbirlzrhmgljxdfxw9Z jdk8u412-b08]# find ./ -name "*libjvm.so*"
    ./jre/lib/amd64/server/libjvm.so
    [root@iZj6cbirlzrhmgljxdfxw9Z jdk8u412-b08]# file ./jre/lib/amd64/server/libjvm.so
    ./jre/lib/amd64/server/libjvm.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, not stripped

デバッグシンボルがないためにメモリホットスポットの収集に失敗する場合の解決策

from Alpine:3.9
RUN apk add openjdk8