> Source: https://www.ymotongpoo.com/works/oteps/profiles/otep-0212/


# OTEP-0212: OpenTelemetryプロファイリングビジョンの提案

以下は、私たちが達成したいと望んでいる、OpenTelemetryプロジェクトにおけるプロファイリングサポートの長期的なビジョンを定義する、ハイレベルな項目です。

このビジョンドキュメントは私たちの現在の願望を反映したものですが、要件のチェックリストというよりも、集団で合意された一連の目標に向けたガイドとなることを意図しています。
OpenTelemetryコミュニティのメンバーからなるグループが、2か月にわたって隔週のミーティングを重ねてきました。
このグループは業界やドメインの専門知識を横断する構成となっており、このドキュメントの作成において共通の目的を見出しました。
今後も足並みをそろえ続けることが、私たちの共通の意図です。
私たちのビジョンが発展し成熟するにつれて、最適な成果を促進するために、そこから得られた学びをさらに取り入れていくつもりです。

このドキュメントとこれまでの取り組みは、次のことに動機づけられています。

- 2020年10月に作成された、この[長年続いているイシュー](https://github.com/open-telemetry/oteps/issues/139)
- KubeCon EU 2022での対面のOpenTelemetryミーティングにおける優先順位についての議論
- ログ、メトリクス、トレースと並ぶオブザーバビリティのシグナルとしてのプロファイリングへの、コミュニティの関心の高まり

## プロファイリングとは何か {#what-is-profiling}

「プロファイル」と「プロファイリング」という用語は、文脈によって意味合いが多少異なることがありますが、このOTEPでは、この2つの用語を次のように定義します。

- プロファイル: 各スタックトレースに何らかのメトリクスが関連付けられたスタックトレースの集合であり、そのメトリクスは通常そのスタックトレースが検出された回数を表します
- プロファイリング: 実行中のプログラム、アプリケーション、またはシステムからプロファイルを収集するプロセス

## プロファイリングはOpenTelemetryのビジョンとどのように整合するか {#how-profiling-aligns-with-the-opentelemetry-vision}

[OpenTelemetryのビジョン](https://opentelemetry.io/community/mission/#vision)では、次のように述べられています。

_効果的なオブザーバビリティは、高い信頼性を維持しながら開発者がより速くイノベーションを起こせるようにするため、強力なものです。_
_ただし、効果的なオブザーバビリティには、高品質なテレメトリーと、それを可能にするパフォーマンスに優れた一貫性のある計装が絶対に必要です。_

既存のOpenTelemetryのシグナルはこれらの基準をすべて満たしていますが、最近まで、プロファイリングデータに基づいたパフォーマンスに優れた一貫性のある計装を作成することを明確に目指した取り組みはありませんでした。

## プロファイリングを加えることによる、バランスの取れたオブザーバビリティスイートの構築 {#making-a-well-rounded-observability-suite-by-adding-profiling}

現在、ログ、メトリクス、トレースは、オブザーバビリティの主要な「柱」として広く受け入れられており、それぞれがユーザーが自分たちのシステムやアプリケーションについての疑問に答えるためにクエリできる、異なる種類のデータを提供しています。

プロファイリングデータは、ログ、メトリクス、トレースでは答えにくいシステムやアプリケーションに関する特定の疑問に答えることで、この目標をさらに推し進める助けとなります。
私たちは、このプロファイリングデータの収集、処理、転送について最高水準のサポートが可能な実装を促進することを目指しています。

プロファイリングに関する私たちの目標は、OpenTelemetry全体の目標と一致しています。

- **プロファイリングは簡単であるべきです**: プロファイリングの性質上、多くの場合は最小限のコードを任意で組み込むだけで、アプリケーションのリソース使用状況についての詳細を即座に得られるという、高速な価値提供が可能です
- **プロファイリングは普遍的であるべきです**: 現在、プロファイリングは言語によって多少異なりますが、少しの工夫によって、プロファイリングデータの表現は言語間で一貫しているだけでなく、プロファイリングデータ自体も他のオブザーバビリティのシグナルと一貫性のある形で標準化できます
- **プロファイリングはベンダーニュートラルであるべきです**: ユーザーは、1つのプロファイリングエージェントから、好きなベンダー（あるいはベンダーを介さない形）にデータを送信し、他のOSSプロジェクトと相互運用できるべきです

## プロファイラーの現状 {#current-state-of-profilers}

現状では、アプリケーションのプロファイルを収集する方法や、収集されるプロファイルのフォーマットは、次のようないくつかの要因によって大きく異なります。

- 言語（および言語ランタイム）
- プロファイラーの種類
- プロファイリング対象のデータの種類（CPU、メモリなど）
- シンボル情報の有無や利用状況

さまざまなプロファイリングフォーマットのかなり包括的な分類は、[profilerpediaサイト](https://profilerpedia.markhansen.co.nz/formats/)で確認できます。

このようなばらつきの結果、プロファイリングデータのツール群や収集は、まさにOpenTelemetryが中核的なエンジニアリング上の価値として築いてきた領域において不足しています。

- プロファイリングには現在、互換性が欠けています: 各ベンダー、OSSプロジェクト、言語ごとにプロファイリングデータの収集、送信、保存の方法が異なっており、他のシグナルとの紐付けを考慮していないことがよくあります
- プロファイリングには現在、一貫性が欠けています: 現在のプロファイリングエージェントやフォーマットは、エンドユーザーを考慮するための統一された基準がないまま、任意に変更され得ます

## プロファイリングを他のシグナルと互換性のあるものにする {#making-profiling-compatible-with-other-signals}

プロファイルは、他のシグナルの文脈において特に有用です。
たとえば、トレース内の特定の「遅い」スパンについてのプロファイルがあれば、そのスパンが遅かったという事実を単に知るよりも、より実用的な情報が得られます。

OpenTelemetryは、プロファイルがログ、トレース、メトリクスとどのように関連付けられるか、またこの関連付け情報がどのように保存されるかを定義します。

関連付けは、2つの主要な次元にわたって機能します。

- 同一のリクエストに対して発行されたテレメトリーを関連付けること（リクエストコンテキストまたはトレースコンテキストの関連付けとも呼ばれます）
- 同一の発生源から発行されたテレメトリーを関連付けること（リソースコンテキストの関連付けとも呼ばれます）

## 業界全体での共有と再利用のためのプロファイリングデータモデルの標準化 {#standardize-profiling-data-model-for-industry-wide-sharing-and-reuse}

私たちは、次の目標を念頭に置きながら、プロファイリングデータの大部分を表現することを目指したプロファイリングデータモデルを設計します。

- プロファイリングフォーマットは可能な限りコンパクトであるべきです
- プロファイリングデータは可能な限り効率的に転送されるべきであり、このモデルはロスレスであり、効率的なマーシャリング、（他のフォーマットとの間の）トランスコーディング、分析を可能にすることに意図的に重点を置くべきです
- プロファイリングフォーマットは、標準化されたデータモデルへ一義的にマッピングできるべきです（collapsed、pprof、JFRなど）
- プロファイリングフォーマットは、他のテレメトリーシグナルとの関係を表現する仕組みを備えるべきです（コールスタックとスパンを紐付けるなど）

## レガシーなプロファイリングフォーマットのサポート {#supporting-legacy-profiling-formats}

既存のプロファイラーについては、これらのレガシーなフォーマットがOpenTelemetryのアプローチと互換性を持ち、テレメトリーデータの関連付けを可能にする形でプロファイルを発行する方法についての手順を提供します。

特にGoやJava（JFR）にネイティブなプロファイラーなどの一般的なプロファイラーについては、最小限のオーバーヘッドでOpenTelemetry互換のプロファイルを生成できるよう支援します。

## パフォーマンスに関する考慮事項 {#performance-considerations}

プロファイリングエージェントはさまざまな方法で設計することができ、パフォーマンス、網羅性、精度などに影響し得る妥当なトレードオフが伴います。
同様に、そのようなプロファイラーがOpenTelemetry互換のデータを生成または消費する方法も、大きく異なる可能性があります。
そのため、私たちの標準化の取り組みにおいて、プロファイラーのリソース使用量について規定的であることは現実的ではありません。

しかし、OpenTelemetryの標準化の取り組みの成果物は、既存の一部のプロファイラーが低オーバーヘッドかつ高パフォーマンスであるように設計されていることを考慮しなければなりません。
たとえば、それらはデータセンター全体にわたって常時稼働する形で動作したり、CPU、RAM、ネットワークの使用量を低く抑えることを保証しなければならない環境で動作したりすることがあります。
OpenTelemetryの標準化の取り組みはこの点を考慮し、パフォーマンスの保証を犠牲にすることなく、この種のプロファイラーで利用可能なフォーマットを生み出すよう努めるべきです。

他のOpenTelemetryのシグナルと同様に、私たちは本番環境を対象としています。
したがって、プロファイリングシグナルは低オーバーヘッドで実装可能であり、OpenTelemetry全体のランタイムオーバーヘッド／侵襲性および通信データサイズの要件に準拠していなければなりません。

## プロファイリングによるクラウドネイティブなベストプラクティスの推進 {#promoting-cloud-native-best-practices-with-profiling}

CNCFのミッションでは、次のように述べられています。

_クラウドネイティブ技術は、パブリック、プライベート、ハイブリッドクラウドといった最新の動的な環境において、組織がスケーラブルなアプリケーションを構築・実行できるようにします_

私たちは、そうした環境で稼働するレガシーなアプリケーションを含め、クラウドネイティブ環境（Kubernetes、サーバーレスなど）で発行されるプロファイルについて、最高水準のサポートを提供します。
この目標の達成を目指すにあたり、私たちはプロファイリング対象のアプリケーションをレジリエントで管理しやすく、オブザーバブルにすることを中心に取り組みます。
これはCloud Native Computing FoundationとOpenTelemetryのミッションに沿ったものであり、それぞれのミッションをさらに推し進めるために、これらのコミュニティをさらに拡大し活用することを可能にします。

## プロファイリングのユースケース {#profiling-use-cases}

- コードの変更、ハードウェア構成の変更、一時的な環境上の問題がパフォーマンスにどのように影響するかを理解するために、アプリケーションのリソース使用状況を経時的に追跡すること
- どのコードがリソース（CPU、RAM、ディスク、ネットワークなど）の消費を引き起こしているかを理解すること
- 本番環境で稼働している一群のサービスに対するリソース割り当てを計画すること
- コードの異なるバージョンのプロファイルを比較し、コードが時間とともにどのように改善または劣化してきたかを理解すること
- 本番環境において頻繁に使用されているコードと「デッド」コードを検出すること
- トレーススパンをコードレベルの粒度（関数呼び出しやコードの行など）に分解し、その特定の単位についてのパフォーマンスを理解すること