---
title: プロファイル
weight: 5
description: コードレベルにおけるリソース使用の記録
default_lang_commit: 065e35458f11219cc77c7fb5ead7507d426694f3
---

**ステータス**: [アルファ](/docs/specs/otel/document-status/)

**プロファイル**は、実行中にどこでアプリケーションがリソースを消費するかを示すサンプルと関連メタデータの**集まり**です。

サンプルは、あるプログラムのコンテキスト（典型的にはスタックトレース）で検出した値を記録します。

オプションで、より上位のリクエストに対応するトレース ID のような補助情報が付加される場合もあります。

サンプルを取得する瞬間は**サンプルイベント**として知られており、観測データ点だけでなく、それが取得された時刻も含みます。

たとえば、On-CPU プロファイルには、サンプル取得時に CPU 上で実行されていたコードに対するサンプル（集約されたスタックトレース）と、各スタックトレースが観測されたタイムスタンプおよび回数が一緒に含まれます。

## プロファイルの概要 {#profiles-overview}

プロファイルは、ログ、メトリクス、そしてトレースに並ぶ、可観測性における第4の本質的シグナルとして台頭しつつあります。

システムおよびアプリケーションの挙動に対する独自の洞察を提供し、他のシグナルでは見落とされがちなパフォーマンスのボトルネックを明らかにすることがよくあります。

プロファイルは、リソース消費とコード実行に関する詳細な時間に基づくビューを提供し、以下を包含します。

- **アプリケーションレベルのプロファイリング**: どのようにソフトウェアの関数が CPU、メモリ、その他のリソースを消費するかを明らかにし、遅いまたは非効率なコードを特定します。

- **システムレベルのプロファイリング**: インフラストラクチャの全体的なビューを提供し、オペレーティングシステムのコール、カーネル操作、I/O における問題を特定します。

このパフォーマンスの全体像は、以下につながる可能性があります。

- **より速い根本原因分析**: パフォーマンス低下の正確な原因を迅速に特定します。
- **事前の最適化**: ユーザーに影響が出る前に、潜在的な問題を特定します。
- **リソース利用の改善**: コスト削減と効率のためにインフラストラクチャを最適化します。
- **開発者生産性の向上**: 開発者がコードのパフォーマンスを検証し、リグレッションを防ぐのに役立ちます。

## プロファイルが他のシグナルをどう補完するか {#how-profiles-complement-other-signals}

各 OpenTelemetry シグナルは以下の異なる問いに答えます。

| シグナル         | 問い                                                         |
| ---------------- | ------------------------------------------------------------ |
| **ログ**         | どのような離散イベントが起きたか？（システムの挙動への洞察） |
| **メトリクス**   | システムレベルで何が起きているか？（例: CPU 使用率が 90%）   |
| **トレース**     | リクエストは、どのように分散システムを通過するか？           |
| **プロファイル** | どのコードがリソース消費の原因になっているか？               |

OpenTelemetry のプロファイルは、他のシグナルとの双方向リンクをサポートします。
これらの相関は、以下の 2 つの次元で機能します。

- **リクエストコンテキストの相関**: 特定のトレースまたはスパンにプロファイリングデータを結び付けることで、特定のリクエスト中にどのコードが実行されていたかを把握できます。

- **リソースコンテキストの相関**: プロファイリングデータを同じサービスインスタンスのような関連するメトリクス、ログまたはトレースを発したのと同じ[リソース](/docs/concepts/resources/)に結び付けます。

プロファイルは、他のシグナルと相関させたときに特に強力になります。

- **ログからプロファイルへ**: メモリ不足のログエントリから、メモリ負荷の原因となっているコードパスを見つけます。
- **メトリクスからプロファイルへ**: CPU またはメモリ使用量の急増から、それらのリソースを消費している関数に直接たどり着きます。
- **トレースからプロファイルへ**: トレース内の遅いスパンから、レイテンシの原因となっているコードを特定するために対応するプロファイルを参照します。

## プロファイルの種類 {#profile-types}

プロファイリングは、さまざまな種類のリソース使用を取得できます。一般的なプロファイルの種類には、以下が含まれます。

- **On-CPU**: どの関数がプロセッサー時間を消費しているか？
- **Off-CPU**: スレッドは実行するかわりに、どこでブロックまたは待機しているか（例: ロック、I/O）？
- **ヒープ（メモリ）**: どの関数が、まだ使用中のメモリを割り当てているか？
- **割り当て（メモリ）**: どのコードパスが最も多くのメモリ割り当てを担っているか（そのメモリが解放済みかどうかに関わらず）？

OpenTelemetry のプロファイルシグナルは、これらすべてを収容するために十分柔軟です。
ただし、利用できる具体的なプロファイルの種類は、使用する言語ランタイムとプロファイラに依存します。

## プロファイリングの仕組み {#how-profiling-works}

プロファイルを収集するために複数のアプローチがあり、それらすべてをサポートするために OpenTelemetry のプロファイルを設計しました。

- **サンプリングベースのプロファイリング**: プロファイラは、たとえばタイマーベースの割り込みを用いてプログラムを周期的に中断し、現在のスタックトレースを記録します。
  これは CPU プロファイリングで最も一般的なアプローチです。
  Linux 上では、プロファイラは一切ユーザー空間アプリケーションを変更する必要がなく、カーネルからスタックトレースを取得するために eBPF を使うことができます。
  このアプローチは、ゼロ計装によるシステム全体プロファイリング（ランタイムサポートのないコンパイル言語で生成されたコードを含む）を可能にし、継続的でオーバーヘッドの低い本番利用向けに設計されています。
- **計装ベースのプロファイリング**: ランタイムフックまたはバイトコード計装は、メモリ割り当て、ロック取得、ガベージコレクションなどのイベントを、それぞれに関連するスタックトレースとともに報告します。

収集方法にかかわらず、得られたデータは OpenTelemetry の共通プロファイルデータモデルにシリアライズされ、OTLP 経由でエクスポートされます。

## プロファイルの収集 {#collecting-profiles}

OpenTelemetry は、コード変更なしにほとんどの言語をプロファイリングできる Linux 向け[eBPF ベースのプロファイリングエージェント](https://github.com/open-telemetry/opentelemetry-ebpf-profiler)を提供します。

Java の JFR や Go の pprof のような組み込みのランタイムプロファイリングフレームワークに接続する言語固有のプロファイリング統合も、シグナルが成熟するにつれ利用可能になります。

OTLP 経由で OpenTelemetry コレクター、または直接互換性のある任意のバックエンドにプロファイルをエクスポートできます。

## 仕様 {#specification}

OpenTelemetry におけるプロファイルの詳細については、[プロファイル仕様](/docs/specs/otel/profiles/)を参照してください。
