ブログ on OpenTelemetry

OpenTelemetry Goのコンパイル時の計装v1の発表

Mon, 20 Jul 2026 21:41:39 +0900

Java、Python、Node.js、.NETで開発している場合、コードを編集せずにOpenTelemetryをアプリケーションへ追加することが長年可能で、起動時にエージェントをアタッチすれば、テレメトリーの送信が始まります。 Goは例外でした。 Goプログラムは、起動時にフックできるランタイムを持たない単一の静的バイナリにコンパイルされるため、Go開発者は手動で計装するか、プロセス外のeBPFエージェントを使用する必要がありました。

この隔たりは埋まりつつあります。 OpenTelemetryコミュニティは、OpenTelemetry Go Compile-Time Instrumentationの最初の安定版リリースを発表します。 2025年の初めにこのSIGを発表した際、AlibabaとDatadogは、Goをビルド時に計装する統一されたベンダー中立の方法を構築するために協力しました。 v1はこのプロジェクトにとって最初の安定版リリースです。

Goサービスをビルドして実行している場合、バイナリまたはコンテナイメージのビルド方法を1行変更するだけで、コードを変更せずにアプリケーションとその依存関係のOpenTelemetryトレースとメトリクスを取得できます。プラットフォームエンジニアやSREにとっては、各チームが独自にコードを計装するのを待たずに、フリート全体のサービスへオブザーバビリティを追加できることを意味します。

Goのコンパイル時の計装とは

Goは単一の静的バイナリにコンパイルされるため、長い間、インタプリタ言語よりも自動計装が困難でした。このプロジェクトは、ビルド中に標準のGoツールチェーン（-toolexecメカニズム経由）にフックし、コード、依存関係、標準ライブラリがコンパイルされる際にOpenTelemetry計装を注入します。別個のエージェントはなく、ランタイムでアタッチするものもありません。

つまり、ソースコードを変更せずにテレメトリーを取得でき、計装はバイナリに直接コンパイルされます。アプリケーションコードは計装に関する懸念から解放され、自分が所有していないサードパーティライブラリもカバーされます。

v1の主な機能

ゼロコード計装: 手動でコードを変更せずに、アプリケーションとその依存関係を計装します。
コンパイル時の注入、ランタイムオーバーヘッドの追加なし: 計装はランタイムでアタッチされるのではなく、バイナリに組み込まれます。
サードパーティと標準ライブラリのカバレッジ: 自分が所有していない依存関係と標準ライブラリパッケージを計装します。
v1でサポートされる計装: net/http、database/sql、gRPC、Redis、Goランタイムメトリクスを含む一般的なライブラリとフレームワークをサポートしており、さらに計装が定期的に追加されています。完全な最新リストは、サポートされるライブラリを参照してください。
ルールベースで拡張可能: SIGの計装ルール形式を通じて、新しいライブラリのサポートを追加できます。計装ガイドとルールリファレンスを参照してください。
セマンティック規約への準拠: 送信されるテレメトリーは、現在のOpenTelemetryセマンティック規約に従います。
CI/CDに対応: 開発時にツールを実行するか、ビルドパイプラインに組み込めます。

はじめに

このプロジェクトは、標準のGoツールチェーンをラップするotelcというコマンドラインツールを提供します。ビルドの変更は1行だけで、以前 go build を実行していた場所で otelc go build を実行します。 go の後に続くすべての引数はツールチェーンに転送されるため、ビルドの残りの部分は変わりません。

go install でインストールします。

go install go.opentelemetry.io/otelc/tool/cmd/otelc@latest

次に、これを介してアプリケーションをビルドします。

otelc go build -o myapp .

ビルドコマンドを変更したくない場合は、モジュールを準備するために一度 otelc setup を実行し、続いて、GOFLAGSを通じてGoツールチェーンをotelcに向け、通常どおりgo buildを実行します。

Dapr の非同期ワークフローオブザーバビリティの改善

Sun, 19 Jul 2026 17:27:12 +0900

この記事では、クラウドネイティブコミュニティのコントリビューターたちが協力して Dapr の OpenTelemetry 統合を強化した経緯、特に非同期ワークフローに関する取り組みについて紹介します。また、OpenTelemetry Weaver を使用して Dapr を OpenTelemetry セマンティック規約に準拠させる継続的な取り組みや、このコラボレーションが他の CNCF プロジェクトにとって有用な事例となりうることについても触れます。この作業は正式なイニシアチブとして始まったわけではありません。議論、実験、そしてテレメトリーをより理解しやすく、エコシステム全体でより一貫性のあるものにするという共通の目標を通じて生まれたものです。

複雑なオーケストレーション全体にわたるトレース伝搬の課題

Dapr のワークフローエンジンは、長時間実行される同期・非同期オーケストレーションを実装するための簡単な方法を提供します。ワークフローオーケストレーションは Dapr サイドカー内で実行され、ワークフローとアクティビティのコードは Dapr SDK を使用してアプリケーション内で実行されます。これらの間の通信は、長時間維持される gRPC ストリームを介して行われます。

これは効率的ですが、W3C Trace Contextの伝搬を困難にします。 HTTP やUnary gRPC 呼び出しは、各リクエストに traceparent および tracestate ヘッダーを自然に運びます。長時間維持されるストリームはそうではありません。ストリームが開かれると、ワークフローのステップは新しいメタデータを付与できません。これは、ワークフローエンジンがサイドカー内で正しいコンテキストを持つスパンを作成できたとしても、アクティビティメッセージが親コンテキストなしでアプリケーションに到達することを意味します。その結果、アクティビティ内のアウトバウンド呼び出しは独自のトレースを作成します。

結果として断片化が生じます。ワークフローのスパン、アクティビティのスパン、ユーザーレベルのスパンがトレーシングバックエンドに表示されますが、一貫した階層を形成しません。

この図は問題を示しています。ワークフローエンジンがスパンを生成しているにもかかわらず、gRPC ストリーミング境界でコンテキストが途切れるため、アクティビティコードはワークフローのトレースに接続できません。

典型的なワークフローオーケストレーションの複雑さ

ワークフローは表面上は単純に見えますが、トレースを始めると、構成要素の多さが明らかになります。ワークフローは単一のリクエストではありません。決定と状態遷移の長期にわたるシーケンスであり、それぞれが異なるダウンストリームシステムと連携する可能性があります。これらの連携の一部は同期的です。たとえば、アクティビティが外部サービスを呼び出して結果を待つ場合です。その他は非同期的で、作業のスケジューリング、外部シグナルの待機、タイマーの発火待ちなどがあります。これらの違いは、リクエストがシステムをどのように流れるかを変え、トレースがどのように見えるべきかを決定するため、重要です。

すべてのワークフローは独自のアイデンティティも持っています。ワークフローインスタンス ID は、時間的に離れていてもすべてのステップを概念的に結びつけます。ワークフローは数秒から数時間にわたって実行される場合があります。障害後に再ハイドレードされたり、サーバー再起動後に再開されたりすることもあります。永続的実行とは、ワークフローエンジンが状態を永続化し、イベントをリプレイし、外部条件が変化したときにワークフローを進めることを意味します。トレーシングの観点からすると、これは通常のリクエストやバックグラウンドジョブとは大きく異なります。単一のワークフロー実行は、多くのネットワーク呼び出し、待機期間、リトライ、部分的な進行にまたがることがあります。

Adobe の OpenTelemetry パイプラインの内側: 大規模環境におけるシンプルさ

Fri, 17 Jul 2026 17:10:25 +0900

Developer Experience SIG は継続的なシリーズの一環として、さまざまな組織の実際の OpenTelemetry Collector デプロイメントについてインタビューを行い、実践的な教訓をより広いコミュニティと共有しています。この記事では Adobe を取り上げます。 Adobe はグローバルなソフトウェア企業であり、そのオブザーバビリティチームは大規模環境でのシンプルさを追求した OpenTelemetry ベースのテレメトリーパイプラインを構築しています。シグナルの種類ごとに数千の Collector が同社のインフラストラクチャ全体で稼働しています。

組織構造

Adobe の中央オブザーバビリティチームは、全社にオブザーバビリティインフラストラクチャを提供する責任を担っています。しかし、シニアソフトウェアエンジニアの Bogdan Stancu が説明したように、Adobe の買収の歴史により、全体が完全に統合されているわけではありません。一部の大規模プロダクトグループは専用のオブザーバビリティチームを持っており、中央チームは主要なプロバイダーとして機能しています。

OpenTelemetry ベースのパイプラインは、主に新しいアプリケーションとデプロイメント向けに設計された新しい選択肢として、既存のモニタリングソリューションと並行して導入されました。導入は任意であり、強制されていません。既存のモニタリングが確立されたアプリケーションは移行されていません。

OpenTelemetry の導入

OpenTelemetry を導入する決定は、プロジェクトの機能とチームの目標の一致によって推進されました。オブザーバビリティチームは、Adobe の多様な技術ランドスケープに対応し、複数のバックエンドをサポートし、サービスチームが簡単に導入できるソリューションを必要としていました。

「私たちが求めていたすべてと合致していました」と Bogdan は語りました。

OpenTelemetry Operator、Collector のコンポーネントモデル、そしてコミュニティの Helm チャートが、個々のサービスチームに深い OpenTelemetry の専門知識を要求せずにスケールできる、プラットフォームレベルのオブザーバビリティ基盤の構成要素を提供しました。

アーキテクチャ: 3層の Collector パイプライン

Adobe の Collector アーキテクチャは 3 層設計に従っています。 2つの Collector を含むユーザー向け Helm チャート、シグナルごとの Collector デプロイメントを持つ集中管理の名前空間、そしてオブザーバビリティバックエンドです。

第1層: ユーザー Helm チャート

オブザーバビリティチームは、サービスチームが自身の名前空間にデプロイする Helm チャートを提供しています。このチャートは2つの Collector を作成します。

10,000件の Slack メッセージが明らかにする OpenTelemetry 導入の課題

Fri, 17 Jul 2026 17:09:03 +0900

OpenTelemetry コミュニティはここ数年で大きく成長し、その成長とともにコミュニティの会話の中に貴重なインサイトが隠されています。私たちは、CNCF Slack の #otel-collector チャンネルと #opentelemetry チャンネルから、2019年5月から2025年12月までの約10,000件のメッセージを分析しました。ユーザーが最も頻繁に直面する課題、最も多くの議論を生むコンポーネント、そしてコミュニティがドキュメントやツールの改善を必要としている領域を明らかにすることが目的です。

データセット

分析対象は、最もアクティブな2つの OpenTelemetry Slack チャンネルにまたがる9,966件のメッセージです。

#otel-collector: 5,570件のメッセージ（56%）
#opentelemetry: 4,396件のメッセージ（44%）

これらのメッセージはいくつかのカテゴリに分類されます。

カテゴリ	割合
質問	46.7%
エラー報告	25.9%
ディスカッション	23.3%
設定	3.0%
ヘルプ回答	1.0%

質問とエラー報告の割合が高く（合計72%超）、これらのチャンネルがコミュニティにとって重要なサポートリソースとして機能していることを示しています。最も頻繁に登場するトピックは、実際の導入における課題を反映しています。

類似メッセージをクラスタリングするために BERTopic を使用したトピックモデリングを適用し、次にセンチメントとフラストレーション指標を分析して、最も困難を引き起こすトピックを特定しました。エラー報告、繰り返しのヘルプ要求、または混乱の表現を含むメッセージは、フラストレーション指標で高いスコアを記録しました。

最も議論された Collector コンポーネント

トピックモデリングにより、コミュニティの議論を最も多く生む Collector コンポーネントについて明確なパターンが浮かび上がりました。メッセージ量別の上位コンポーネントは次のとおりです。

1. Prometheus レシーバーとエクスポーター（498件、5.0%）

Prometheus との連携がコミュニティの議論を支配しています。ユーザーからの質問が多いのは次の点です。

メトリクスをスクレイプするための Prometheus レシーバーの設定
Prometheus リモートライトエクスポーターのセットアップ
パイプラインにおけるメトリクスの型とメタデータの保持についての理解
既存の Prometheus インフラストラクチャとの統合

Prometheus が広く採用されていることを考えれば、これは当然のことです。多くの組織が、既存の Prometheus セットアップと統合したり、そこから移行したりすることで OpenTelemetry への取り組みを始めています。特にリモートライトエクスポーターは多用されており、チームが OpenTelemetry を収集と処理に採用しながら、引き続き Prometheus をストレージバックエンドとして使用できるようになります。

OpenTelemetry プロファイルがパブリックアルファに

Wed, 15 Jul 2026 20:56:30 +0900

OpenTelemetry が初めてプロファイルを紹介して以来、トレース、メトリクス、ログと並ぶ継続的な本番プロファイリングの統一された業界標準の構築に向けた勢いは増す一方です。本日、Profiling SIG はプロファイルシグナルが正式にパブリックアルファに移行したことを発表します。より広いコミュニティでの利用とフィードバックを受け入れる準備が整いました。

すべての人に本番プロファイリングを

本番環境で低オーバーヘッドのパフォーマンスプロファイルを継続的に取得する手法は、数十年にわたって使われてきました。本番インシデントのトラブルシューティングに役立ち、ソフトウェアを高速化することでユーザー体験を向上させ、同じ処理に必要なリソースを減らすことで計算コストを削減します。歴史的に、JFR や pprof のようなフォーマットが普及していたにもかかわらず、継続的プロファイリングの共通フレームワークやプロトコルは業界に存在しませんでした。

OpenTelemetry プロファイルにより、コミュニティとエコシステムのサポートに支えられた、真のベンダー中立性を備えた本番プロファイリングの業界標準を導入します。これを実現するにはいくつかのコンポーネントがあります。

プロファイリングデータの統一されたデータ表現を作成し、pprof のような既存フォーマットとの互換性を確保する。
新しいリファレンス eBPF ベースのプロファイラー実装を導入する。
プロファイルを OpenTelemetry エコシステムの自然な一部にする（OTel Collector との統合など）。

上記のすべてがアルファリリースで大幅に改善されました。ここからは、私たちが取り組んできた内容を紹介します。

データ表現の標準化

統一されたプロファイリングフォーマットの作成は、多様な環境にわたる業界標準として機能する必要があるため、大きな課題です。ワーキンググループは多くの要件を調整する必要がありました。サンプリングとトレーシング、ネイティブランタイムとインタプリタランタイム、ワイヤー/メモリーサイズの効率性とデータの可読性のトレードオフ、その他同様の側面です。

結果として生まれたプロファイルアルファフォーマットは、プロファイリングデータを効率的にキャプチャできるバランスの取れた機能セットを提供します。

スタック表現は重複排除されており、各ユニークなコールスタックは一度だけ格納されるため、多様なプロファイリングデータを効率的にエンコードできます。
その他の一般的なエンティティのディクショナリテーブルにより、効率的なデータ正規化も可能です。
主に集約データのエンコードに焦点を当てていますが、個々の（サンプリングされた場合でも）オフ CPU イベントの記録などのユースケースをサポートするために、タイムスタンプ付きイベントデータのキャプチャも可能です。
リソース属性により、追加情報でデータモデルを拡張できます。文字列ディクショナリのサポートにより、プロファイリングデータを関連するログ、メトリクス、トレースを出力した同じリソースに効率的に（ワイヤーサイズ40%削減）リンクできます。
プロファイルサンプルは、さらにトレーシングの trace_id / span_id 属性と関連付けることができ、データのクロスシグナル相関を実現します。
セマンティック規約が、最も一般的なプロファイリング固有の属性の定義を提供します。

pprof フォーマットに着想を得て pprof のメンテナーと共同で開発された OTLP プロファイルは、OpenTelemetry エコシステムの幅広い要件に対応する独立した標準へと進化しました。元の pprof フォーマットのデータは、情報の損失なく OTLP プロファイルとの間でラウンドトリップ変換できます。この目的のために、シームレスな相互運用性を確保する新しいネイティブトランスレーターが含まれるようになりました。

データ品質と導入の容易さを確保するため、適合性チェッカーツールもリリースします。このツールにより、エクスポートされたプロファイルが OpenTelemetry プロファイルの技術仕様とセマンティック規約に準拠しているかを検証できます。

eBPF プロファイリングエージェントによる手間のないインサイト

Elastic による eBPF プロファイリングエージェントの OpenTelemetry への寄贈と OTel Collector との統合により、最も広く使われている言語ランタイムをサポートした、追加の計装なしの低オーバーヘッドなシステム全体の Linux 継続的プロファイリングが、すべての OpenTelemetry ユーザーに提供されるようになりました。

小さな環境変数の旅路

Wed, 15 Jul 2026 20:17:50 +0900

OpenTelemetry の Spring Boot スターターは、バージョン 2.26.0 から宣言的設定をサポートするようになりました。これは Java エージェントが 2025 年後半に導入したのと同じ YAML スキーマを application.yaml の中に埋め込むものです。この投稿では、1 つの環境変数 OTEL_SERVICE_NAME=petclinic がこの新しい仕組みの中で何をするのかを追跡し、どこに継ぎ目があるのかを明らかにします。

お急ぎですか？

Spring Boot スターターの宣言的設定ドキュメントに直接ジャンプするか、 application.properties をインタラクティブコンバーターに貼り付けるか、 Ecosystem Explorer で Spring Boot スターターのターゲットを選択して SDK のセットアップを選んでください。ストーリーはコーヒーを片手にどうぞ。

長年にわたり、環境変数（とその JVM -D 版）は OpenTelemetry SDK を設定する唯一の方法でした。すべてのエクスポーター、すべてのサンプラー、すべてのキャプチャするヘッダーが、フラットな OTEL_* 変数のリストとして表現されていました。

OpenTelemetry Spring Boot スターターのバージョン 2.26.0 以降、このリストには新しい兄弟ができました。 SDK の宣言的設定スキーマは、テレメトリーパイプライン全体（すべてのプロセッサー、すべてのエクスポーター、すべてのネストされたオプション）を SDK が実際に動作するのと同じ形で記述できる YAML ツリーです。

環境変数だけでは表現できないことに対して、Spring スターターのユーザーは @Bean を書く必要がありました。 Java エージェントのユーザーは、完全なエクステンションを書き、エージェントと一緒に配布する別の jar にパッケージする必要がありましたが、これは負担が大きいことがありました。

これらの新しい変更により、スキーマは application.yaml の中の 1 つの otel: キーの下に移動します。環境変数は引き続き機能しますが、その役割はより限定的になります。 OTEL_SERVICE_NAME はリソース属性として反映されますが、これはサービス名ディテクターが起動時にそれを読み取るためです。また、YAML に書いた ${VAR:default} プレースホルダーは名前を指定して環境変数を取り込みます。それ以外では、YAML が信頼できる情報源です。

good first issue のその先へ ― コントリビュートを持続可能にするには

Sun, 12 Jul 2026 22:54:50 +0900

OpenTelemetry は、アプリケーションやサービスからメトリクス、ログ、トレースを収集するためのツールと標準を提供します。コントリビュートを始めるのは気後れするかもしれません。ここでは、実際の経験から得た教訓をいくつか紹介します。

ほとんどのガイドは、「good first issue」の見つけ方、リポジトリのフォーク方法、SIG ミーティングへの参加方法を説明しています。そうしたアドバイスは有用であり、多くのリソースがそれをうまくカバーしています。あまり注目されないのは、コントリビュートにまつわるより広い文脈です。エコシステムの理解、コミュニティの力学のナビゲート、そして大規模なオープンソースプロジェクトへの長期的な関わりの構築がそれにあたります。

これらの側面は OpenTelemetry において特に重要です。開発は多くのリポジトリ、SIG、組織にまたがって行われるためです。新規参入者、とりわけ過小評価されている背景を持つコントリビューターにとって、この文脈は大きな違いを生みます。協力や意思決定に関する暗黙のルールが見えにくい場合、どこから始めるべきか、自信を持って参加する方法、あるいは単発のコントリビューターから長期的なメンバーへと成長する方法を知ることが難しくなります。

このガイドは、そのより深い層に焦点を当てています。「最初のコントリビュート」のチェックリストを超えて、OpenTelemetry コミュニティがどのように機能しているかを理解し、その中で自分の居場所を見つける手助けをします。

コンテキストとコミュニティ

特定のリポジトリに飛び込む前に、より広いクラウドネイティブエコシステムを探索してください。どのオブザーバビリティツールが進化しているか、どこにギャップがあるか、どのプロジェクトが OpenTelemetry の普及に影響を与えているか。戦略的なコントリビュートはコンテキストから始まります。 CLOTributor のようなプラットフォームは、1つの組織内だけでなく、クラウドネイティブプロジェクト全体にわたる「good first issue」を見つける手助けをしてくれます。これにより、自分のスキルが最もインパクトを発揮できる場所に身を置けます。

「good first issue」は競争が激しく、投稿されてから数時間以内に取られてしまうことがよくあります。見つからない場合は戦略を変えましょう。完璧なイシューを待つのではなく、SIG コールや Slack でのディスカッションを通じてコミュニティの活発な一員となり、自分が役に立てるアドホックなタスクを探しましょう。

Merge Forward のような取り組みは、オープンソースにおいて過小評価されているグループを支援し、従来の企業環境では多くのエンジニアが得られないメンターシップ、可視性、アクセスを提供しています。 OpenTelemetry は、参加障壁を積極的に下げるこの大きな CNCF エコシステムの中に存在しています。

OpenTelemetry は、メンターシッププログラム、ローカリゼーショングループ、非同期コラボレーションを通じてインクルーシブな参加を積極的に支援し、多様な背景を持つコントリビューターが対等に活動できるようにしています。

プロジェクトとコミュニティのつながりを理解することで、コントリビュートはより意義あるものになります。

コントリビュートはコード以上のもの

2026年1月から2026年3月までの OpenTelemetry.io ウェブサイトで最も人気のあるページを示すグラフ

プルリクエストは単なるコード変更ではありません。それはディスカッションであり、フィードバックであり、プロジェクトの方向性との整合です。メンテナー、承認者、SIG メンバーが優先事項を導きます。イシュースレッドや PR のディスカッションを読むことで、意思決定がどのように行われ、実際の摩擦がどこにあるかがわかります。その認識がコントリビュートをより強いものにします。

テック業界で過小評価されているグループのエンジニアにとって、可視性と継続的な参加は重要です。 OpenTelemetry は、特定の場所にいることや大手テクノロジー企業で働いていることに依存しない参加方法をいくつか提供しています。会話は Slack チャネル、SIG ミーティング、GitHub イシュー、プルリクエストのディスカッションなど、複数のコミュニティスペースで行われます。これらのチャネルにより、異なる地域、職歴、経験レベルのコントリビューターがプロジェクトに参加し、実践的なフィードバックを共有できます。

OTel-Arrow フェーズ 2: 効率的なトランスポートから効率的なテレメトリーパイプラインへ

Sun, 28 Jun 2026 13:12:19 +0900

OTel-Arrow のフェーズ 1 では、OTAP（OpenTelemetry Arrow Protocol）を OpenTelemetry 向けの効率的なトランスポートプロトコルとして確立しました。 Apache Arrow は、構造化データをシステム間で効率的に移動・処理するために設計された、言語非依存の列指向インメモリフォーマットです。テレメトリーを OpenTelemetry データモデルとの互換性を維持しつつ、大幅に低いネットワークオーバーヘッドで転送できることを実証しました。

フェーズ 2 では異なる問いを立てました。 Arrow をネットワーク上だけでなく、パイプラインが内部的に扱うデータ表現としても使ったらどうなるのか、という問いです。

テレメトリーの量は急速に増加しており、その背景には OpenTelemetry の幅広い導入、より豊富な計装、そしてよりダイナミックな AI やエージェントベースのワークロードがあります。この規模になると、属性の削除、フィールドのリネーム、メタデータの追加、シグナルのルーティングといった一般的なパイプライン操作は、できるだけコストが低いことが求められます。これらの操作の多くは単純で反復的です。プロセッサーがあるレコードの属性に対して処理を行う場合、同じバッチ内の多くのレコードに対しても同じ属性への処理が行われることが多いのです。

このパターンは列指向の表現とよく適合します。テレメトリーをコンパクトな Arrow バッチに保ったまま、プロセッサーが属性のリネーム、データのエンリッチメント、シグナルのルーティングを行えれば、パイプラインは各変換にかかる周辺処理を削減し、CPU とメモリをより効率的かつ予測可能に使用できます。 OTAP は、テレメトリーの増加という次のフェーズにおいて、OpenTelemetry パイプラインをより効率的に運用する上で重要な役割を果たせると考えています。

Arrow パスを検証するためのデータフローエンジン

このアイデアを探るため、OTel-Arrow Dataflow Engine を構築しました。これは OTAP をパイプライン内の主要なデータ表現として設計した Rust ランタイムです。 OTAP ストリームをエンドツーエンドで受信・送信でき、OTLP（OpenTelemetry Protocol）も別のファーストクラスのデータパスとしてサポートしています。

このデュアルパス設計により、同じランタイム内で 2 つのモードを比較できます。テレメトリーを Arrow レコードバッチのまま保持する OTAP ダイレクトパスと、明示的な境界で OTLP と OTAP 間の変換を行う OTLP 互換パスです。結果は明確です。テレメトリーが OTAP パス上にエンドツーエンドで留まると、トランスポートと処理のコストが大幅に低下します。

OpenTelemetry Collector は、OpenTelemetry パイプラインのための広く利用されている汎用的な実装です。そのパイプラインモデルは OTLP 形式のインメモリデータ構造を中心に構築されており、柔軟で OpenTelemetry データモデルと密接に整合していますが、大量のバッチ処理には比較的コストがかかります。本研究の目的は、異なる設計ポイントを検証することです。 OTAP を主要なデータ表現とし、OTLP 互換性を明示的な境界で処理するテレメトリーデータプレーンの構築です。

OpenTelemetry の謎を解く：レガシー環境でオブザーバビリティを恐れる必要がない理由

Sun, 28 Jun 2026 13:12:00 +0900

何十年もの間、オンプレミスのデータセンターからレガシーアプリケーション、産業制御システムに至るレガシーなテクノロジー環境は、多くの組織の基盤を支えてきました。これらのシステムは実績があり、ビジネスオペレーションに深く組み込まれていますが、IT プラクティスの近代化、特にオブザーバビリティに関しては独特の課題を抱えています。

レガシー環境でオブザーバビリティを実装する際の課題

ノイズが多く構造化されていないログからは、意味のある情報を抽出することが困難です。
異なるツールやシステムにわたってサイロ化された監視データは、可視性の断片化につながります。
レガシーアプリケーションやシステムでは計装が限られているため、最新のメトリクスやトレースの収集が困難です。
チームは新しいオブザーバビリティツールの追加によるパフォーマンスへの影響を懸念することが多いです。
レガシープロトコルやハードウェアと最新のプラットフォームとの統合は困難な場合があります。

これを実践的に理解するために、忙しい生産ラインを持つ架空の製造会社を見ていきましょう。ここでは、センサーを搭載したロボットアームが MQTT 経由で運用データを中央ブローカーに報告しています。レガシーアプリケーションは生産イベントやエラーをディスクにログとして記録し、SQL Server と Windows マシンが生産、分析、在庫管理をサポートしています。聞き覚えがあるでしょうか。これは、古い世界と新しい世界をつなごうとする多くの組織の現実です。

計装が組み込まれているクラウドネイティブ環境とは異なり、レガシーシステムや産業システムは一貫性のないログ、限られたメトリクス、断片化されたツールに依存しています。これにより可視性が不足し、トラブルシューティング、チューニング、メンテナンスが遅く困難になります。組織が信頼性の向上と変革の加速を目指す中で、オブザーバビリティはもはや「あれば便利」なものではなく、戦略的な必須要素です。しかし、オブザーバビリティへの道、そして OpenTelemetry への標準化の道は、根強い誤解によって曇らされることがあります。いくつかの誤解を打ち破りましょう！

誤解 1：私たちのシステムは大量の役に立たないログを生成するだけで、ここでオブザーバビリティを実現する方法はない

レガシーの生産システムについて考えてみてください。古い機械やアプリケーションが、ファイルにプレーンテキストのログをひたすら出力し続けているかもしれません。 JSON も構造も API もなく、ただ延々とテキストの行が続くだけです。そのような混沌から意味のある洞察を引き出す方法はないと思いがちです。

なぜこの誤解が根強いのか（レガシーログ）

多くの従来型環境では、生産ライン、レガシーアプリケーション、産業制御システムのいずれであっても、目にする唯一のデジタル「シグナル」は、生の構造化されていないログファイルのストリームかもしれません。運用マネージャーにとって、これらのファイルは不透明でもどかしい存在です。運用マネージャーは特定の障害を深く気にかけています。ライン 1 が「Jam」で停止しているのか「LowPressure」で停止しているのかを知ることが、即時の対応とメンテナンス戦略を決定します。しかし、その重要なデータが FAULT_DETECTED: Line1, Fault=Jam のような非構造化テキストに埋もれていると、標準的な監視ダッシュボードからは見えません。テキストをグラフ化することはできず、ファイル内の文字列に対して簡単にアラートを設定することもできず、時間の経過に伴う傾向を把握することもできません。このことが、これらのシステムは監視できないという誤解につながっています。しかし、OpenTelemetry のような最新のオブザーバビリティツールを使えば、これらの「役に立たない」ログは運用上の洞察の宝庫になり得ます。

レガシーログの行の例

2026-01-04 00:39:58 | PRODUCT_COMPLETED: Line1, Count=1
2026-01-04 00:40:00 | FAULT_DETECTED: Line2, Fault=LowPressure
2026-01-04 00:40:02 | MACHINE_START: Line2
2026-01-04 00:40:07 | FAULT_DETECTED: Line2, Fault=Overheat
2026-01-04 00:40:10 | MACHINE_START: Line2
2026-01-04 00:40:14 | PRODUCT_COMPLETED: Line1, Count=1
2026-01-04 00:40:18 | MACHINE_START: Line2
2026-01-04 00:40:21 | PRODUCT_COMPLETED: Line1, Count=1
2026-01-04 00:40:27 | SENSOR_READING: Line1, Temp=83.9
2026-01-04 00:40:29 | FAULT_DETECTED: Line1, Fault=LowPressure
2026-01-04 00:40:32 | SENSOR_READING: Line1, Temp=84.7
2026-01-04 00:40:34 | PRODUCT_COMPLETED: Line1, Count=1

このシステムを可観測にする方法

OpenTelemetry Collector はこれらのファイルをリアルタイムで監視し、イベントをパースし、レガシーアプリケーションにコード変更を加えることなく、構造化されたメトリクスに変換できます。

KubeCon + CloudNativeCon Europe 2026

Sat, 27 Jun 2026 16:01:33 +0900

OpenTelemetry プロジェクトのメンテナー、ガバナンス委員会メンバー、そして技術委員会メンバーは、2026年3月23日から26日にアムステルダムで開催される KubeCon EU に参加します。ぜひ登録して、一緒に参加しましょう！

KubeCon 期間中の OpenTelemetry 関連イベントについて、以下をお読みください。

トークとメンテナーセッション

We Deleted Our Observability Stack and Rebuilt It With OTel: 12 Engineers to 4 at 20K+ Clusters
by Yash Sharma, DigitalOcean; Kunju Perath, DigitalOcean
Tuesday March 24, 2026 11:15 - 11:45CET
When OTTL Goes Off the Rails: Debugging Transformations with Confidence
by Edmo Vamerlatti Costa, Elastic; Tyler Helmuth, Honeycomb
Tuesday March 24, 2026 12:00 - 12:30CET
Schema Inference and Automation: A New Era for Telemetry Management
by Arthur Silva Sens, Grafana Labs; Nicolas Takashi, Coralogix
Tuesday March 24, 2026 15:15 - 15:45CET

Mastodon が本番環境で OpenTelemetry Collector を運用する方法

Sun, 21 Jun 2026 21:36:56 +0900

2025年初頭、OpenTelemetry Developer Experience SIG は最初のコミュニティサーベイの結果を公開しました。最も強いテーマの一つは明確でした。チームは OpenTelemetry SDK や OpenTelemetry Collector が実際に本番環境でどのように使われているかについて、より多くの実例を求めていたのです。

このギャップを埋めるために、SIG はさまざまな業界、アーキテクチャ、企業規模のエンドユーザーから直接ストーリーを収集し始めました。この記事は、組織の実際の運用事例に特化した新しいシリーズの第一弾です。小規模ながらも独自の課題を持つケースからスタートします。

最初のストーリーの主役は、世界規模で運営しながらも驚くほど少人数のチームで活動している非営利団体 Mastodon です。

Mastodon の概要

Mastodon は、非営利団体が運営する、フリーでオープンソースの分散型ソーシャルメディアプラットフォームです。

分散化はここではマーケティング用語ではなく、中核的なアーキテクチャ原則です。誰でも自分の Mastodon サーバーを運用でき、それぞれ独立して運営されるサーバーは、Fediverse（ActivityPub などの標準化されたプロトコルを使用して相互に通信する独立したソーシャルプラットフォームの連合ネットワーク）の一部として、オープンプロトコルを使って相互運用します。メールと同様に、ユーザーは誰がサーバーを運営しているかに関係なく、インスタンス間で通信できます。

この思想は、Mastodon の機能に関する意思決定だけでなく、オブザーバビリティへのアプローチにも影響を与えています。

組織構造

Mastodon の組織全体は約 20 名で構成されており、オブザーバビリティインフラストラクチャ（OpenTelemetry Collector を含む）はたった一人のエンジニアが管理しています。

少人数のチームにもかかわらず、Mastodon は 2 つの大規模な本番 Mastodon インスタンスを運用しています。

mastodon.social

9～15 ノード（各 16 コア、64 GB RAM）間でオートスケーリングする Kubernetes 上で稼働しています。 Web フロントエンドは 5～20 Pod、さまざまな Sidekiq ワーカープールは 10～40 Pod の間でスケーリングします。平均して、mastodon.social では常時 70～80 の Pod が稼働しています。このプラットフォームは 1 日あたり最大 30 万のアクティブユーザー を処理し、毎分約 1,000 万リクエストをさばいています。

Skyscanner が実践する OpenTelemetry のスケーリング: 24 の本番クラスターにまたがる Collector の管理

Wed, 17 Jun 2026 23:09:29 +0900

Developer Experience SIG は、さまざまな業界や規模の企業における実際の OpenTelemetry デプロイメントを紹介するブログ記事シリーズを公開しています。この記事では、スコットランドのエジンバラに拠点を置くグローバルな旅行検索プラットフォーム Skyscanner を取り上げます。

全世界で 1,400 人の従業員を擁し、24 の本番 Kubernetes クラスターで 1,000 以上のマイクロサービスを運用している Skyscanner の OpenTelemetry 導入事例は、大規模な組織にとって貴重な教訓を提供します。

組織構造

6 名のプラットフォームエンジニアで構成される Hubble チームが、Skyscanner の Collector の大部分を管理しています。より大きなプラットフォームエンジニアリング組織の一部として、主に Java ベースのマイクロサービスアーキテクチャを実行するコンピューティングプラットフォームを担当しています。

サービスチーム自体は、デプロイメントやテレメトリー収集のインフラストラクチャから抽象化されています。 Java サービスの場合、チームは事前設定された OpenTelemetry Java エージェントを含むベース Docker イメージを継承します。 Python および Node.js サービスの場合、プラットフォームチームが環境やリソース属性に基づいた適切なデフォルト値を設定するラッパーライブラリを提供しています。これらのアプローチにより、ボイラープレートのセットアップが最小化され、サービスチームは OpenTelemetry の深い知識を必要とせずに、すぐにオブザーバビリティを利用できます。

OpenTelemetry の導入

Skyscanner の OpenTelemetry 導入は 2021 年に始まりました。当時、同社は社内で構築したオープンソーススタックから商用ベンダーへの移行を進めていましたが、ベンダーロックインを避けたいと考えていました。

「ベンダーに依存しない方法でベンダーに移行したかったのです」と、Skyscanner の Hubble プラットフォームチームのソフトウェアエンジニアである Neil Fordyce は説明しました。

このベンダーに依存しないアプローチにより、テレメトリーインフラストラクチャの中核として OpenTelemetry Collector を採用することになりました。

アーキテクチャ: 集中ルーティング、分散収集

Skyscanner の Collector アーキテクチャは、Istio ベースのインテリジェントルーティングを備えた中央 DNS エンドポイントを特徴としています。サービスがグローバルのどこで実行されていても、どのクラスターにあっても、テレメトリーはこの単一のアドレスに送信されます。 Istio がリクエストを最も近い利用可能な Collector にルーティングします。

OTel ブループリントとリファレンス実装の紹介

Sun, 14 Jun 2026 18:49:28 +0900

OpenTelemetry を導入するエンドユーザーが、その過程のどこかで 「なぜこんなに複雑なんだ?」 と自問することは珍しくありません。本格的な導入には、通常、SDK のさまざまな設定方法、複数のコレクターのデプロイメント、データパイプライン、計装ライブラリ、セマンティック規約レジストリ、多くの異なるプログラミング言語にわたる手動計装用 API、その他多数の可動部分を理解する必要があります。

これらの可動部分は単独で動作するわけでもありません。組織のソフトウェアシステムを標準的で高品質なテレメトリーで記述するための統合ソリューションの一部として、互いに上手く連携する必要があります。これに失敗すると、OpenTelemetry が解決しようとしていたまさにその問題、すなわちスタック全体で異なるセマンティック規約が使われた断片的なテレメトリー、サービスとシグナル間のコンテキスト伝搬の欠如、不必要に大量のデータ量……、要するに必要なものとは正反対の、品質の低いテレメトリーに行き着くリスクがあります。

プロジェクトが進化して安定するにつれて、また大規模な本番環境で OpenTelemetry を導入するエンドユーザーが増えるにつれて、同じフィードバックを耳にし続けてきました。エンドユーザーは、プロジェクトとそのメンテナーが推奨する、規範的で意見の明確な「OpenTelemetry のデプロイ方法」(これが何を意味するかは解釈次第) を求めています。彼らは、自分たち のオブザーバビリティの課題を 最もシンプルな 方法で解決するのに必要なコンポーネントを構成するための一連の手順に従いたいのであって、それ以上を望んでいるわけではありません。

皆さんの声を聞き、私たちは耳を傾けました。 End User SIG が Developer Experience SIG と協力して推進する新しい取り組み、ブループリントとリファレンス実装を発表できることをうれしく思います。

複雑性の源とブループリントの必要性

最初の問いに戻りましょう。「なぜこんなに複雑なんだ?」。 1986 年に書かれた Fred Brooks の論文 銀の弾などない —ソフトウェア工学における本質と偶有 で説明されている用語を用いると、OTel 導入の複雑性は 2 つに分けられます。本質的 なものと、より頻繁に見られる 偶有的 なものです。

本質的な複雑性

OTel の複雑性の 本質的 な部分、つまりその設計に内在する部分は、主にその幅広さと横断的な性質に起因します。 OpenTelemetry はスタックのほぼすべての部分、つまりクライアントサイド(ブラウザやモバイル)からアプリケーション、Kubernetes、インフラ、データベースなどに触れます。私たちのドキュメントはこれらの各コンポーネントがどのように動作するかを説明するのに優れており、宣言的設定やInjectorといった新しい開発、そして長年存在している OpenTelemetry Operator により、これらすべてのコンポーネントにわたる統合された設定を適用することは容易になりました。しかし、依然としてこれは非常に大きなデプロイ対象であり、一貫性を達成する必要があり、ほとんどの場合、単一のチームでは扱えないという事実は変わりません。

OpenTelemetry はまた、単一のソリューションに限定されず、任意のバックエンドで動作するように設計されています。スタックに事前構築済みのエージェントを投入してデータが流れるのを見るという古いモデルは魅力的かもしれませんが、データの主権を維持する必要のある現代のシステムに必要な柔軟性に欠けています。 OpenTelemetry の柔軟性により、エンドユーザーはデータがどのように生成され、最終的にどこに保存されるかにかかわらず、自分自身のデータを制御できますが、この柔軟性は幅広さとあいまってさらなる複雑性をもたらす可能性があります。

要約すると、OTel は大規模に適用すると 本質的 に複雑になることがあり、これは通常もっともな理由によるものです。

LLM 呼び出しの内側: OpenTelemetry による GenAI オブザーバビリティ

Fri, 05 Jun 2026 16:58:42 +0900

AI エージェントに単純な質問をしたら、回答までに 45 秒もかかった、ということを想像してみてください。原因はモデルでしょうか。それともツール呼び出しが遅かったのでしょうか。あるいはリトライのループに陥っていたのでしょうか。アプリケーションが LLM を呼び出すたびに、モデル呼び出し、ツール実行、トークンのやり取りといった一連の処理が裏側で起きています。オブザーバビリティがなければ、原因は推測するしかありません。

OpenTelemetry の Generative AI 向けセマンティック規約は、この内側を可視化します。 GenAI 操作の記録方法を標準化しており、呼び出されたモデル、入出力のトークン数、そして明示的に有効化した場合にはプロンプト、応答、ツール呼び出し、ツールの実行結果の中身までを記録します。

この記事では、以下を順に紹介します。

LLM を活用したアプリケーションから GenAI のテレメトリーをエクスポートする。
そのテレメトリーを受信して表示できるよう、オブザーバビリティツールを設定する。
GenAI ビジュアライザーを使って、GenAI のトレース、メトリクス、イベントを探索する。

GenAI テレメトリーをエクスポートする

このチュートリアルでは、多くの開発者がすでにインストール済みであることから、テレメトリーを発生させるツールとして VS Code Copilot を使います。ただし、多くのコーディングアシスタントが OpenTelemetry によるモニタリングをサポートしています。

VS Code Copilot は、エージェントとのやり取りごとにトレース、メトリクス、イベントを出力します。
OpenAI Codex は、API リクエスト、ツール呼び出し、セッションについて、構造化ログイベントと OTel メトリクスをエクスポートします。
Claude Code は OTel でメトリクスとログイベントをエクスポートし、トレース対応はベータ版で提供されています。

すでに使っているツールをモニタリングするだけでなく、自分の GenAI アプリケーションに OpenTelemetry を組み込めば、LLM とのやり取りの様子を可視化できます。

テレメトリーエクスポートを設定する

テレメトリーをエクスポートするには、いくつかの設定が必要です。 VS Code Copilot の場合は、設定画面を開いて copilot otel で検索してください。

OpenTracing 互換性要件の非推奨化

Fri, 05 Jun 2026 16:09:11 +0900

2026年3月19日、OpenTelemetry Specification プロジェクトは PR #4938 をマージし、仕様における OpenTracing 互換性要件を非推奨としました。

この変更は、エコシステムがすでに到達している状況に合わせて仕様を更新するものです。 OpenTracing は何年も前にアーカイブされており、新しいインテグレーションは、OpenTracing のシム要件の上に構築するのではなく、ネイティブの OpenTelemetry API および SDK を使用することが期待されています。

これは仕様要件の非推奨化であり、互換性に関する記述を即座に削除するものでも、既存のシムの成果物を今すぐ削除することを求めるものでもありません。

何が変わるのか

仕様における OpenTracing 互換性要件が非推奨になります。
新しい SDK や実装において、新たに OpenTracing 互換性を実装することはもはや必須ではありません。
既存の OpenTracing シムは、非推奨期間中、後方互換性のために引き続きサポートできます。
新しい作業では、新たな OpenTracing への依存を導入するのではなく、ネイティブの OpenTelemetry API、SDK、および OTLP ベースのワークフローを対象とすべきです。

なぜ今なのか

OpenTracing 自体は何年も前にアーカイブされており、エコシステムでの採用はネイティブの OpenTelemetry API と OTLP ベースのワークフローに収束してきました。このプロジェクトには、PR #4715 での Zipkin エクスポーターの非推奨化など、過去の非推奨化作業から、こうした段階的なアプローチの前例もあります。

タイムラインとポリシー

仕様の非推奨化: 2026年3月より有効。
仕様からの最も早い削除時期: マージされた仕様本文に記載のとおり、2027年3月より前にはなりません。

ユーザーは何をすべきか

まだ OpenTracing シムに依存している場合、今こそネイティブの OpenTelemetry API および SDK への移行を計画する良い時期です。

レガシー環境における OpenTelemetry セキュリティプラクティスの適用

Fri, 05 Jun 2026 16:04:50 +0900

製造業をはじめとするレガシー環境において、組織がモダンなオブザーバビリティのアプローチを模索する中で、OpenTelemetry は注目を集めつつあります。しかし、こうしたプラクティスを従来型のシステムに適用すると、これまでとは異なるセキュリティ上の課題が生じます。レガシーインフラの制約は、セキュリティ制御をどこにどのように適用すべきかを根本的に変えてしまいます。

レガシー環境や産業環境には、次のような特徴がよくみられます。

変更や計装が不可能なシステム
長い機器のライフサイクルと限られたパッチ適用の機会
フラットなネットワーク、もしくはセグメンテーションが弱いネットワーク
一般的な PII ではない、機密性の高い運用データ

本記事では、こうした環境で OpenTelemetry を保護する際に何が異なるのか、そしてそれに応じてアプローチをどのように適応させればよいのかに焦点を当てます。

なぜレガシー環境は異なるのか

クラウドネイティブシステムにおけるセキュリティのガイダンスは、次のような前提に立っています。

サービスは計装可能である
暗号化と認証はどこでも強制できる
システムは定期的にパッチを適用できる

レガシー環境や産業環境では、これらの前提が成り立たないことがよくあります。

その結果、セキュリティはどこにでも理想的な制御を適用することではなくなります。 テレメトリーパイプラインの正しい場所に制御を配置し、可視性とリスクのバランスを取ることが重要になります。

レガシーシステム特有のセキュリティ課題

システムを変更できない

多くの産業システムは、エージェントを実行できず、モダンなライブラリをサポートできず、まったく変更できません。これは次のことを意味します。

ソースにおけるモダンな TLS や認証のサポートが限定的、あるいは一貫していない
SDK を用いた直接的な計装ができない
中継機能（Collector、ブリッジ、ログパイプライン）に依存する

ソースシステムがモダンな制御を強制できない場合、セキュリティの負担はより多く Collector、中継システム、ネットワーク境界へと移ります。

脆弱な、あるいは存在しないネットワークセグメンテーション

レガシー環境のネットワークアーキテクチャは、モダンなオブザーバビリティを念頭に設計されていないことがよくあります。セグメンテーションが最小限のフラットあるいは共有ネットワーク上で動作するものもあれば、レガシーなプロトコルが混在する深くネストされたネットワークに依存するものもあります。いずれの場合も、テレメトリー収集を導入することで次のような事態が起こり得ます。

意図しないネットワークセグメントに対して新たな受信エンドポイントが露出する
Collector やブリッジへの意図しない横方向アクセスが許容される
これまで分離されていたゾーンの間に予期せぬ経路が生まれる

このような環境では、Collector の配置は Collector の設定と同じくらい重要です。ネットワーク境界、ファイアウォール、プロトコルゲートウェイに対して Collector がどこに位置するのかを慎重に評価してください。

限られたパッチ適用と長いライフサイクル

産業システムはアップグレードなしで何年も稼働することがあります。 Collector の配置方法によって、パッチ適用の戦略は決まります。一般的なモデルは 2 つあります。

Collector を外部ブリッジとして配置する（推奨）:

Collector はレガシーシステムの境界の外側（別のホスト、VM、コンテナ上）で動作し、産業環境とオブザーバビリティバックエンドの間のブリッジとして機能します。このモデルでは、次のような利点があります。

OpenTelemetry が CNCF の Graduated プロジェクトに

Fri, 22 May 2026 19:35:22 +0900

本日、Cloud Native Computing Foundation（CNCF）は OpenTelemetry が Graduated になったことを発表しました。

Graduated はプロジェクトにとって重要なマイルストーンであり、OpenTelemetry のコミュニティとエコシステムの強さを反映するものです。 OpenTracing と OpenCensus の統合以降、数千人ものコントリビューター、メンテナー、エンドユーザー、そして多くの組織が、OpenTelemetry を業界全体で利用される、オープンでベンダーニュートラルなオブザーバビリティフレームワークへと育てる手助けをしてきました。

このマイルストーンはコミュニティのものです。

コード、ドキュメント、仕様、言語 SDK、セマンティック規約、バグ報告、レビュー、コミュニティサポート、アドボカシー、そしてエンドユーザー体験を寄せてくださったすべての方々に感謝します。 OpenTelemetry は、毎日プロジェクトに時間と専門知識を投じ続けてくれる人々のおかげで存在しています。

また、Graduated のプロセスを通じて OpenTelemetry を支えてくださった CNCF コミュニティ、Technical Oversight Committee のスポンサー、そしてエンドユーザーの皆様にも感謝しています。

Graduated はゴールではありません。 OpenTelemetry コミュニティは、グローバル規模のクラウドネイティブソフトウェアのために、相互運用可能で高品質なオブザーバビリティの標準とツールを構築することに、これからも取り組み続けます。

この旅の一員でいてくださり、ありがとうございます。この先に何が待っているのか、私たちはワクワクしています。

Ecosystem Explorer プロジェクトの紹介

Tue, 19 May 2026 21:31:49 +0900

OpenTelemetry は広大です。 Java エージェントだけでも、240 を超えるさまざまな自動計装が含まれています。 Collector には数百ものコンポーネントがあります。 Python、JavaScript、Go、.NET には、それぞれ独自の計装ライブラリエコシステムがあり、それぞれに独自のパターンや規約があります。

2025 Developer Experience Survey では、ユーザーは「ドキュメントをたどるのが難しく、OpenTelemetry ウェブサイトと GitHub リポジトリを行き来する必要がある」、また「さまざまな情報源から情報をつなぎ合わせなければならない」ことが多いと回答しました。主要な情報源として opentelemetry.io を利用しているユーザーは約半数にすぎず、それ以外のユーザーは GitHub、ベンダードキュメント、あるいは答えを見つけられる場所を参照しています。

そして、ドキュメントを見つけられたとしても、それが基本的な疑問に答えてくれるとは限りません。実際にどのテレメトリーシグナルを受け取ることになるのでしょうか。 OpenTelemetry Getting Started Survey では、回答者の 65% が、計装が実際に何を生成するのかを示すリファレンス実装を求めていることがわかりました。 OpenTelemetry 2025 Year in Review post で述べられているように、既存の OpenTelemetry Registry はユーザーがコンポーネントを見つける助けになりますが、次のような疑問に答えるために「必要な情報の深さを常に提供しているわけではありません」。どのライブラリが計装されているのか。どのスパン、メトリクス、属性を出力するのか。それはバージョンごとにどのように変わるのか。

OpenTelemetry の導入の中心には、根本的なジレンマがあります。あるコンポーネントがどのテレメトリーを生成するのか（どのスパン、メトリクス、属性なのか）を理解するには、多くの場合、まずそれをデプロイしなければなりません。 OpenTelemetry が自分たちのニーズに合うか評価している人に、それを求めるのは大きな負担です。

私たちはそれを解決するものを構築しています。約 1 年にわたってプロトタイプに取り組んだ後、新しいサイトが explorer.opentelemetry.io で公開されましたが、まだまだ開発途上です。

Java エージェントエコシステム

Java エージェントは、私たちが最初に完全にマッピングしたエコシステムです。 240 を超える計装がインデックス化され、検索可能になっています。名前で閲覧したり、計装タイプでフィルタリングしたり、各計装が出力するスパン、メトリクス、属性を正確に示す詳細ページを掘り下げたりできます。設定オプションはドキュメント化され、それが影響するテレメトリーにマッピングされています。

バージョンサポートも組み込まれています。 Explorer は複数の Java エージェントリリースを追跡するため、特定のバージョンがどのテレメトリーを生成するのか、あるいはバージョン間で何が変わったのかを確認できます。これは、アップグレードを計画するときや、リリース後にテレメトリーの見え方が変わった理由をデバッグするときに特に役立ちます。

毎晩実行される自動化があります。新しい Java エージェントバージョンがリリースされると、パイプラインがそれを検出し、メタデータを抽出し、レジストリを更新するため、手動での介入は不要です。

Java で初期アプローチを検証しました。今度は、新しいエコシステムへ拡張するための助けが必要です。

OpenTelemetry 日本コミュニティ向けアンケート

Mon, 04 May 2026 09:31:32 +0900

このレポートは、日本の開発者やエンジニアにおける OTel の認知度、導入状況、コミュニティ参加の現状を把握するために実施された、OpenTelemetry 日本コミュニティ向けアンケートの結果をまとめたものです。このアンケートは、開発、SRE、DevOps、プラットフォームエンジニアリングといった役割の実務者を対象とし、CNCF コミュニティチャネル、および X (旧 Twitter)、Qiita、Zenn といった日本のソーシャルプラットフォームを通じて配布されました。目的は、日本の技術エコシステムにおいて OTel の利用とエンゲージメントを意義ある形で拡大できる、データドリブンな戦略を立案することです。

主なポイント

OTel の導入については、本アンケートには成熟した層からの回答が集まりました。 61.47% がすでに本番環境で稼働させており、さらに 25.69% が評価中です。両者を合わせると回答者の約 87% を占めます。
シグナルの収集ではトレースが 93% で最も多く、メトリクスが先行する傾向にある世界の OTel アンケートとは対照的な結果となっています。
コミュニティの満足度は高く、NPS は +49 を記録しました。ただし 27.37% は中立 (パッシブ) であり、ドキュメントの改善やコミュニティへの働きかけによって、推奨者へと転換できる余地があります。
Go のユーザーは導入への意欲が最も強く、評価段階の 39% と比較して本番運用が 76% と数値が跳ね上がっており、いずれの言語よりも大きな伸びを示しています。
回答者の 86% がカンファレンスに参加していますが、KubeCon Japan 2025 への参加は 25% にとどまっており、今後の開催に向けて、まだリーチできていない大きな潜在層があることを示唆しています。
Twitter/X は 2 番目に多く利用されている情報源 (83%) ですが、OpenTelemetry はそこに公式アカウントを持っておらず、また日本でよく使われている Zenn や Qiita にも存在感がありません。日本の利用者と関わっていきたいのであれば、これに対処することを検討すべきです。

回答者属性と背景

回答者の構成は 開発チーム に大きく偏っており (44.95%)、次いで SRE が 22.94% で 2 番目に大きなグループとなっています。 DevOps、プラットフォームエンジニアリング、セールスエンジニアリングが中位層を形成し、運用担当 (Operations) と専任のオブザーバビリティ担当を合わせても 7% 未満にとどまります。地理的には、東京を含む 関東地方 に大きく集中しており (76.15%)、近畿地方 (大阪・京都圏) が 12.84% で大きく離された 2 位となっています。これは日本のテック産業における東京の存在感を考えれば驚くことではありませんが、これらの都市圏以外の日本の開発者層を完全に代表しているとは言えない可能性があることは、留意しておく必要があります。

Span Events APIの非推奨化

Thu, 26 Mar 2026 19:22:32 +0900

OpenTelemetryはSpan Event APIを非推奨化します。この記事では、この変更を行う理由、その概要、そして準備のために必要なことを説明します。要約すると以下のとおりです。

イベントを送信する2つの重複した方法（スパンイベントとログベースのイベント）によって生じる混乱と重複を解消したいと考えています。
新しいコードは、現在のスパンに関連付けられたログとしてイベントを記録すべきです。
古い「スパンイベント」スタイルは段階的に廃止されますが、スパン上のイベントを表示する既存のデータとビューは引き続き機能します。

なぜSpan Event APIを非推奨にするのか？

現在、OpenTelemetryはトレースと相関するイベントを送信するための主要な方法を2つ提供しています。

Tracing APIのSpan.AddEventまたはSpan.RecordExceptionメソッドを使用して作成されるスパンイベント。
Logs APIを介して（直接、またはOpenTelemetryにブリッジされたロギングライブラリを通じて）送信され、アクティブなコンテキストに関連付けられるログベースのイベント。

同じ概念に対して競合する2つのAPIを持つことには、いくつかの欠点があります。

計装の作成者に対するガイダンスの分断。 ライブラリやフレームワークの作者は、非常に似たデータを送信するための2つの方法のいずれかを選択しなければなりません。選択が異なると、エコシステム全体でユーザーエクスペリエンスに一貫性がなくなります。
ユーザーにとっての重複した概念。 オペレーターはスパンイベントとログイベントの両方、それらのエクスポート方法、およびバックエンドでの扱いを理解しなければなりません。
進化の遅延。 イベントモデルの改善（たとえば、スキーマ、属性、後方互換性に関するもの）は、2か所で仕様策定と実装が必要になります。

OpenTelemetryコミュニティは、よりシンプルなメンタルモデルへの収束を進めています。 イベントはLogs APIを介して送信される名前付きのログであり、スパン上の特別なケースとしてではなく、コンテキストを通じてトレースやメトリクスと相関するというモデルです。この変更は、OpenTelemetryがイベントを表現する方法を統一するものとして重要です。この方向性の背景については、以前のブログ記事OpenTelemetry Logging and Youを参照してください。

同時に、スパンイベントが今日広く使用されていることも認識しています。多くのバックエンドは専用のトレースビューでスパンイベントを表示しており、一部のユーザーは親スパンと同じOTLPエクスポートペイロードにイベントが含まれることに依存しています。

OTEP 4430: Span Event API非推奨化計画のプランは、以下の目標のバランスを取ることを目指しています。

新しいイベントはLogs APIを通じて送信すべきという明確で一貫したガイダンスの提供。
互換性レイヤーを通じて、トレース内のスパンイベントに依存する既存のワークフローの保持。

つまり、スパンに付随するイベントを見る機能ではなく、スパンイベントを記録するためのAPIを非推奨化するということです。

何が変わるのか？

非推奨化は新しいイベントの記録方法に焦点を当てています。

ログベースのイベントに対するOTLPサポートはすでに安定しており、Logs APIはスパンイベントがこれまで持っていたすべてのものを、より豊富なメタデータとより柔軟なエクスポートおよびフィルタリング機能とともに記録できます。
トレース仕様は、ログベースのイベントの送信を優先してSpan.AddEventやSpan.RecordExceptionなどのAPIを非推奨化します。
言語APIとSDKはログベースのイベントをファーストクラスとして扱い、必要に応じてそれらのイベントをスパンイベントとして表示できる互換性オプションを提供します。
計装とセマンティック規約は、次のメジャーバージョンでスパンイベントからログベースのイベントへと段階的に移行しながら、それまでは既存の動作を安定した状態に保ちます。

何が変わらないのか？

Span Event APIが非推奨化されても、ユーザーエクスペリエンスのいくつかの重要な側面は意図的に保持されます。

シグナル間の相関は同じように機能し続けます。 ログベースのイベントは引き続きOpenTelemetryコンテキストに関連付けられます。
既存のデータは有効なままです。 すでにスパンイベントを使用しているデータは、サポートされているOTLPトレースモデルの一部として残ります。

非推奨化は、新しいコードでイベントを送信する単一の推奨方法を提供するものであり、スパン上のイベントへの可視性を削除するものではありません。

何をすべきか？

まず何より、この移行が安全で段階的であり、現在依存しているワークフローと互換性があるものにしたいと考えています。

役割に応じて、今後の変更がどのように影響するか、そして何ができるかを以下に示します。