OpenTelemetry Profiles の現在地
🐱 この章の目次
成熟度の異なる仕組みを分ける
OpenTelemetryでは、トレース、メトリクス、ログに続くシグナルとしてプロファイルの標準化が進んでいます。 2026年8月時点で、OpenTelemetry Profilesの仕様とシグナルはAlphaです。 Alphaは、評価とフィードバックの対象になっている段階であり、互換性を維持したまま運用できることを示すStableではありません。
Javaの診断では、成熟度を次のように分けます。
| 目的 | 2026年時点の選択 |
|---|---|
| JVM、JDK、OSイベントの記録 | JFRを使う |
| JFRの可視化と解析 | JMCまたはJDK 21の jfr コマンドを使う |
| Javaとネイティブを含むスタックの詳細調査 | async-profilerを使う |
| トレース、メトリクス、ログの自動計装 | OpenTelemetry Java agentを使う |
| プロファイルの共通データモデルとOTLP転送の評価 | OpenTelemetry Profilesを実験環境で試す |
OpenTelemetry Java agentは、トレース、メトリクス、ログの自動計装に使えます。 これを付ければJFRやCPUプロファイラーが不要になるわけではありません。 トレースはリクエストがどのサービスを通り、どのspanで時間を使ったかを示し、プロファイルは観測した時間帯にどのコードが資源を使ったかを示すからです。
プロファイルと他のシグナルを結ぶ
OpenTelemetry Profilesのデータモデルは、プロファイルのサンプルを trace_id と span_id に関連づけられるよう設計されています。
また、サービス名やプロセスなど同じResourceの属性で、メトリクス、ログ、トレースとプロファイルを対応づけます。
この対応が実装されていれば、調査を次のようにつなげられます。
- メトリクスでCPU使用率の上昇を検知する。
- 同じサービスと時刻の遅いトレースを選ぶ。
- spanに関連づいたプロファイルから、CPUを使ったスタックを調べる。
仕様が相関を表現できることと、使用するプロファイラー、Collector、バックエンド、UIが一連の操作を実装していることは別です。 導入前に各コンポーネントの対応バージョンと、関連づけが失われない経路を確認します。
eBPFプロファイラーの位置づけ
OpenTelemetryは、Linux向けのeBPFプロファイラーを公開しています。 アプリケーションへ計装コードを追加せず、複数の言語とネイティブコードを含むシステム全体のプロファイルを収集する方向の実装です。
このプロファイラーとOTel ProfilesはAlphaであり、この教室の本番運用の既定にはしません。 Linuxの実験環境で、カーネル要件、権限、シンボル解決、Collectorとバックエンドの対応を確認する対象として扱います。
OpenTelemetryの公式概念ページは、JFRなど言語ランタイム固有の統合を、シグナルの成熟に伴って利用可能になるものと説明しています。 したがって、JFR記録をOTLP Profilesへ安定して送る標準経路がすでに完成しているとは扱いません。
この教室での使い分け
インシデント対応では、JFRの継続記録とOpenTelemetryのトレース、メトリクス、ログを先に整えます。 コードレベルのCPUや割り当てを調べるときはasync-profilerを時間を区切って使います。 OpenTelemetry Profilesは、その既存手段を置き換えるものとしてではなく、プロファイルを他のシグナルへ関連づけて運ぶ標準の候補として評価します。