OpenTelemetryプロファイルがパブリックアルファに入ります

概要

OpenTelemetryのProfilesシグナルがパブリックAlphaとなり、業界標準のプロファイリング基盤への大きな一歩。 eBPFベースのプロファイラやOTel Collectorとの統合により、Linux環境での継続的プロファイリングを実現。 pprof互換の新フォーマットやコンフォーマンスチェッカーなど、データ標準化も進展。 Kubernetes連携やOTLPリソースモデル強化など、OTelエコシステムとの統合も強化。今後はシグナル間連携やシンボリゼーション標準化など、さらなる発展が期待。

OpenTelemetry Profiles シグナルのAlphaリリース

OpenTelemetry Profiling SIG がProfilesシグナルのパブリックAlphaリリースを発表
トレース、メトリクス、ログ に続く 統一的なプロファイリング標準 の確立
継続的プロファイリング による本番環境でのパフォーマンス監視、高速化、コスト削減の実現
これまで業界共通のプロファイリングフレームワーク・プロトコルが存在しなかった課題の解消
pprofやJFR など既存フォーマットとの互換性を持ちながら、 ベンダーニュートラル な標準を提供

プロファイリングデータの標準化

多様な実行環境 や要件（サンプリング/トレース、ネイティブ/インタプリタ等）に対応した 新フォーマット
スタック表現の重複排除 により、効率的なエンコーディングを実現
辞書テーブル によるデータ正規化と省メモリ化
集約データ だけでなく、タイムスタンプ付きイベントデータも記録可能
リソース属性 や 文字列辞書 による40%の通信量削減と、他シグナル（ログ・メトリクス・トレース）との連携
trace_id / span_id によるクロスシグナル相関
pprofフォーマット との完全な相互変換、新しい ネイティブトランスレータ の提供
コンフォーマンスチェッカー ツールで仕様遵守の検証が可能

eBPFプロファイリングエージェントの進化

Elastic社のeBPFプロファイラ がOpenTelemetryに寄贈、OTel Collectorと統合
Linux全体の低負荷プロファイリング が追加インストゥルメンテーション無しで利用可能
Goバイナリの自動シンボリゼーション、 Node.js V8のARM64対応、 BEAM（Erlang/Elixir）初期対応
.NET 9/10対応、Rubyのアンワインド/シンボリゼーション改善
eBPFエージェント がCollectorのレシーバーとして動作、Kubernetesメタデータやメトリクスと連携

OTelエコシステムとの統合

OTel Collector がProfilesデータの受信・インフラ情報付与に対応
pprofレシーバー でpprof形式のプロファイルも受信可能
k8sattributesprocessor によるKubernetesメタデータの自動付与
OTTLサポート でカスタムルールによるプロファイル変換・フィルタが可能
OTLPリソースモデル の最適化により、効率的な情報共有を実現

導入方法とツール

OpenTelemetry公式ドキュメント のprofiles conceptsページで詳細を学習可能
eBPFプロファイラ＋OTLP Profiles対応バックエンド の組み合わせで導入が容易
Elastic社のdevfiler （デスクトップアプリ）が実験用バックエンドとして利用可能（本番利用は非推奨）
eBPFプロファイラリポジトリ で詳細手順を参照

貢献者一覧

Google, Datadog, Polar Signals, Elastic, Grafana Labs, Red Hat, Shopify, Zymtrace, Adobe, Splunk など、多数の企業・開発者が貢献

今後の展望と参加方法

OTel Profiles対応ツール・製品の開発者 はエクスポート/受信機能の追加を推奨
eBPFエージェントやCollector（v0.148.0以降） のテストとフィードバック募集
ドキュメント改善提案やIssue/PR の投稿歓迎
Alpha版のため、本番環境のクリティカルワークロードには非推奨
シグナル間連携、シンボリゼーションAPI/ストレージ標準化、SDKとeBPFエージェント連携 など、今後の課題
GitHub Issue を通じたフィードバックが今後の発展の鍵

まとめ

OpenTelemetry Profiles は、プロファイリングの業界標準化・エコシステム連携を加速
低負荷・高効率な本番環境プロファイリング の普及に貢献
多様な言語・実行環境・クラウドネイティブ基盤 での導入が可能
今後のベータ・GAリリース に向けて、さらなる開発とコミュニティの参加が重要

Hackerたちの意見

プロダクションで低オーバーヘッドのパフォーマンスプロファイルを継続的にキャプチャすることについて。OTelコミュニティが設計したものが「低オーバーヘッド」の期待に応えられるなんて、ちょっと驚きだよね。

└

何か追加することある？

└

OTelプロファイリングSIGのメンテイナーです。あなたの懸念は理解していますが、プロトコルや関係するコンポーネント全体で効率的にするように最善を尽くしています。今出しているもので問題があれば教えてください。

└

プロファイラーのリファレンス実装[1]は、もともとElasticが買収してOTELに寄付したOptimyzeチームが作ったものです。そのチームは本当に優秀です。例えば、フレームポインタが有効でないバイナリからスタックトレースを取得するための.eh_frameウォーキング技術を発明しました。そのチームのOGたちは後にZymtrace[2]を設立して、今はGPU内部で何が起こっているかのプロファイリングをやっています！ [1] https://github.com/open-telemetry/opentelemetry-ebpf-profile... [2] https://zymtrace.com/article/zero-friction-gpu-profiler/

└

今は気分が良くなった？

ついでに聞きたいんだけど、rsyslogd（LinuxやFreeBSDの分散syslogger、他のプラットフォームもあるかも）の、中央ノードにログを送信するモードでのパフォーマンスと信頼性の特性をプロファイルした人いる？俺は比較的小規模（ノードは高い単位で数個、活動が集中するときは毎分100万〜200万リクエストくらい）で設定して使ったことがあるけど、分散ログやトレースの一般的な解決策になってない理由が気になってるんだ。UIの問題は解決しないけど、ログを集めるのはできるし。例えば、rsyslogdに対してJepsenみたいなストレステストをやった人がいて、その結果を共有してるとか？前にちょっと調べたけど、何も見つからなかった。

└

人々はsyslogに興味ないみたい。98%の同僚はそれを知らない。

└

毎日数十GiBのログを扱ってるんだけど（rsyslog -> 中央rsyslog -> elasticsearch）、ちゃんと動いてるよ。ただ、設定がマジで地獄で、ドキュメントもイマイチだし、トラブルシューティングはCコードの深いところまで潜らないといけないことが多い。今、Alloy+Lokiに移行する予定なんだ。

└

これはOTel関連の投稿だから、OTelコレクターを使ってログを集めて中央のOTelコレクターインスタンスに転送することもできるよ。 > そうだね、UIの問題は解決しないけど、ログを集めるのは解決できる。私はNetdataで働いていて、ここ数ヶ月でOTelログを取り込んでインデックスする外部Netdataプラグインを開発したんだ。[1] 現在の実装では、ログをsystemd互換のジャーナルファイルに保存していて、可視化はsystemdジャーナルログをクエリしたときに得られるものとほぼ同じだよ。[2] i > ねえ…誰かrsyslogdに対してJepsenみたいなストレステストをやったことある人いる？結果を共有してる人がいればいいんだけど。前にちょっと調べたけど、何も見つからなかった。rsyslogdは使ったことないけど、君が言ってるログのボリュームで問題が出るとは思えないな。[1] https://github.com/netdata/netdata/tree/master/src/crates/ne... [2] https://learn.netdata.cloud/docs/logs/systemd-journal-logs/s...

これにはすごくワクワクしてる。$WORKでElixir版を何回か使ったけど、めちゃくちゃ役立ったよ。

これがgrafana pyroscopeとどう比較されるのか気になるな。あれはこの手のことにすごく良くて、すでにかなり成熟してるしね。 https://grafana.com/oss/pyroscope/ https://github.com/grafana/pyroscope

└

確か、Pyroscope自体はプロファイラーじゃなくて、プロファイルを送ったりクエリしたりする場所なんだよね。OpenTelemetryがプロファイラーをリリースするから、比較にはならないけど、両方を組み合わせて使えるよ。

└

OpenTelemetryで収集したプロファイルをPyroscopeに送ることができるよ。https://grafana.com/docs/pyroscope/latest/configure-client/o...

└

どちらか一方ってわけじゃないよ。PyroscopeにはOTel互換のレシーバーがもうあるから、フォーマット変換なしでOTelプロファイルを直接送れるんだ。お互いに補完し合う関係だよ。OTelプロファイリングの標準は、バックエンドの選択よりもクライアント契約としての方が価値がある。OTel SDKで一度計測してから、Pyroscope、Grafana Cloud、Datadog、または自分のTempoインスタンスにルーティングできる。アプリケーションコードを変更する必要はないんだ。それが実際の提案だよ。今の問題は標準そのものじゃなくて、言語のカバー範囲のギャップなんだ。JVMの継続的プロファイリングはeBPFを使ってしっかりしてるし、プロダクションでも使える。Node.jsはまだV8のサンプリングプロファイラーに頼っていて、カーネルレベルのeBPFアプローチに比べて2-5%のオーバーヘッドがあるんだ。これは注目すべきギャップだね。

これいいね、OTelが進展してる。OTelにはまだ粗い部分があって、$workでは理想のテレメトリーのワンストップショップにはなってないと思う。特に、良い（Sentryスタイルの）例外キャプチャがまだないし。最近、メトリック名をたくさん変更したみたいで（理由は良さそうだけど）、ネットで見つかるほとんどのダッシュボードが壊れちゃった。OTelはまだ成熟してないって人に警告されたけど、今でもそう感じる。でも、最近はメンテナが何とかしようとしてるみたいだね。

└

じゃあ、代替案は何かある？（Sentry以外で）OTelはトレースのサポートが結構広いと思うんだけど。

└

otelに関する「問題」は、計測が簡単で無料（ビールと自由の両方の意味で）なのに、ダッシュボードの部分になると、実際に数十の異なるSaaSソリューションがあって、どれもOTelの開発に関わってるから、自分たちのソリューションを使って（お金も払って）ほしいってことだと思う。自己ホスティングのGrafana + Tempoでかなりのところまで行けるけど、Grafana Labsもどんどん新機能をGrafana Cloudのサブスクリプションモデルの後ろに隠してきてるしね。

Perforatorでは、最初はGoogleの美しいpprofから始めたんだけど、すぐにネストされた繰り返しフィールドを全部排除したんだ。それで、https://github.com/yandex/perforator/blob/main/perforator/pr....にたどり着いたよ。protobufの繰り返しフィールドは、ほんとにメモリとCPUを食うからね。このレイアウトのおかげで、数億のサンプルを一つのプロファイルに素早く統合できるんだ。実質的な制限はprotobufの2GBメッセージサイズの上限だけだね。

└

昨年、あなたたちに連絡を取って、フォーマットのアイデアを取り入れられないか探ってみたんだ。確かに面白そうだよね！でも、確か私の記憶が正しければ、あなたたちのチームからは誰も私たちのSIGミーティングに参加しなかったよね？ https://github.com/yandex/perforator/issues/13

ハクソク