ブログ on OpenTelemetry

OpenTelemetry コントリビューターエクスペリエンスサーベイからの知見

Thu, 09 Jul 2026 11:46:05 +0900

OpenTelemetry Contributor Experience SIG は先日サーベイを実施し、プロジェクトへの貢献がどのようなものか、そしてコントリビューターエクスペリエンスを改善するために何ができるかをコミュニティから学びました。 Contributor Experience Survey では、プロジェクトの組織体制、SIG への貢献、リーダーシップ委員会とのやり取り、イベントへの参加について、コントリビューターの意見を尋ねました。 120件の回答が寄せられ、47すべての Special Interest Group（SIG）から声が届きました。このフィードバックを活用して、OpenTelemetry への貢献をより簡単で実りあるものにしていきます。サーベイに参加してくださったすべての方に心から感謝します！それでは結果を見ていきましょう。

主なポイント

このサーベイは、プロジェクトがどう改善できるかを知るために実施しました。ここでは、コントリビューター向けに改善できる領域とともに、主な学びを紹介します。

始め方: 新しいコントリビューターの48%が、始め方を十分に把握できていません。 SIG 内・SIG 間のコミュニケーションや貢献ガイドの改善が必要です。
SIG ミーティング: コントリビューターの82%が SIG ミーティングを有用だと感じています。ミーティングへの出席は、プロジェクトの進め方や貢献方法に関する知識の向上と相関がありますが、ミーティングに求められる同期性を好まない人もいます。
ワークフロー: 半数以上のコントリビューターが、自分の貢献に対してタイムリーなフィードバックを受けていません。また、プロジェクトツールの使いにくさやゲートキーピングのボトルネックも経験しています。
プロジェクトとサブプロジェクトの優先事項: OpenTelemetry のリーダーシップ委員会の優先事項を十分に把握していると自信を持って言えるメンテナーは半数未満です。コントリビューターもまた、サブプロジェクトの優先事項を見つけるのが難しいと述べています。
イベント: コントリビューターは、トークよりもコラボレーションに重点を置いた対面イベントをもっと望んでいます。

詳細な知見

合計42の質問を含むこのサーベイは、OpenTelemetry のコントリビューターエクスペリエンスの幅広い領域をカバーしました。このセクションでは、回答を分析し、学んだことをまとめます。

一部のカテゴリではサンプルサイズがかなり小さいため、誤差の範囲が大きくなっています。可能な限り、回答数を括弧内に記載しました。

分析にあたっては、自己申告データをそのまま真実として扱い、「同意する」と「強く同意する」の回答を合算し、「同意しない」と「強く同意しない」も同様に合算しました。したがって、たとえば「SIG ミーティングに出席しているコントリビューターは、どの SIG でも貢献の始め方を知っている可能性がはるかに高い」と述べる場合、それは SIG ミーティングに定期的に出席していることに 同意または強く同意した コントリビューターが、貢献の始め方を知っていることに 同意または強く同意する 可能性が高いことを意味します。

回答者について

45人のメンテナーを含む120人のコントリビューターから回答があり、各 SIG から少なくとも1人のコントリビューターが参加しました。回答者の詳細は以下のとおりです。

63%がオブザーバビリティベンダーに勤務しています。
20%が貢献を始めてから6か月未満です。
86%が北米（45%）または EMEA（41%）に居住しています。これらの数字は、devstats の国別統計を地域別に分類した算出結果の39%と43%にほぼ一致します。
43%が自分の時間を使って貢献しています。
71%が OpenTelemetry Organization のメンバーです。

プロジェクトの組織体制

コントリビューターに、OpenTelemetry プロジェクトの組織面・運営面についてどう感じているかを尋ねました。始め方を知っているか？自分で問題を解決できるか？ SIG ミーティングは有用か？

Observability by Design: OpenTelemetry Weaver で一貫性を実現する

Sat, 04 Jul 2026 20:36:44 +0900

TL;DR

OpenTelemetry Weaver はチームが observability by design を実現するのを支援し、セマンティック規約を通じて一貫性のある、型安全で、自動化されたテレメトリーを可能にします。 Weaver を使えば、テレメトリースキーマの定義、検証、進化を行い、システム全体の信頼性と明確性を確保できます。

一貫性が重要な理由: セマンティック規約の導入

次のような経験をしたことはありませんか…

メトリクス名が変更されたために、デプロイによって既存のアラートやダッシュボードが壊れた
チームごとに同じものに異なるメトリクス名を使っているために、過度に複雑なクエリを書かなければならない
計装が不足していたり不明確だったりしたために、本番環境の問題のデバッグに何時間も費やした
ドキュメント化されていない、または一貫性のないメトリクスの解釈にチームが苦労している

これらのいずれかに心当たりがあれば、あなただけではありません。これらは、テレメトリーをソフトウェア設計の意図的な一部としてではなく、後付けとして扱っていることの症状です。そこでセマンティック規約の出番です。

セマンティック規約は、テレメトリーデータのルールと標準名のセットです。メトリクス、トレース、ログの「文法」と考えてください。これにより、すべての人とすべてのもの（ツールを含む）が http.request.method、db.system.name、http.client.request.duration の意味を理解できます。

OpenTelemetry セマンティック規約は、9つのSIGによってメンテナンスされる、70以上のドメインにわたる900以上の属性とシグナルを含む大規模なオープンカタログです。このオープンカタログにより、以下が確保されます。

一貫性: 1つの名前、どこでも1つの意味。
相互運用性: ツール、チーム、ベンダーが互いに理解できる。
自動化: 機械可読な標準により、コードやドキュメントの生成、静的および動的なコンプライアンスチェックなどが可能になる。

しかし、チームやツールをまたいでこのようなレジストリをメンテナンスし進化させることは容易ではありません。そこで OTel Weaver の出番です。

Observability by design: 現代的なエンジニアリングアプローチ

Observability by design とは、オブザーバビリティをソフトウェア開発ライフサイクル（SDLC）の最初から組み込むことを意味します。これは「オブザーバビリティのシフトレフト」と呼ばれることが多く、オブザーバビリティの関心事を開発タイムラインの中でより早い段階（「左」）に移動させます。つまり、デプロイ後の監視から設計・開発フェーズへと移行します。

明確な目標を設定する: オブザーバビリティの目標を前もって定義する。どのシグナルが必要か。
自動化する: ツールを使ってコード、ドキュメント、テスト、スキーマを規約から生成する。
検証する: オブザーバビリティの問題を本番環境ではなく CI/CD の段階で早期に検出する。
反復する: 実際のフィードバックと進化するニーズに基づいてテレメトリーを改善する。

言い換えれば、テレメトリーをパブリック API のように扱うということです。アプリケーションの API をリリース間で壊さないのであれば、テレメトリーも壊さないでください。

OpenTelemetry の安定化とリリース慣行の進化

Sat, 04 Jul 2026 20:36:04 +0900

概要

OpenTelemetry は、あらゆる指標において、クラウドネイティブ領域で最も大規模かつ注目されているプロジェクトのひとつです。過去5年間で、このコミュニティは歴史上最も重要なオブザーバビリティプロジェクトのひとつを築き上げてきました。しかし、私たちは現状に満足しているわけではありません。プロジェクトは常に、幅広いステークホルダーからのフィードバックを求め、耳を傾けています。皆さんから聞こえてくるのは、次のレベルに進むためには優先事項を調整し、安定性、信頼性、そしてプロジェクトのリリースやドキュメント・サンプルコードなどの成果物の整理に注力する必要があるということです。

過去1年間にわたり、さまざまなユーザーインタビューやアンケートを実施し、多くの場でオープンな議論を行ってきました。これらの議論を通じて、OpenTelemetry の複雑さと安定性の欠如が本番デプロイメントの障壁となっていることが明らかになりました。

このブログ記事では、このフィードバックに対処するために Governance Committee が重要と考える目標と目的を示します。まずはこの記事から始めて、議論を公開の場で行っていきます。

私たちの目標

すべての OpenTelemetry ディストリビューションが「デフォルトで安定」であることを保証し、ユーザーが実験的または不安定な機能にオプトインするための標準化されたメカニズムを提供する。
ドキュメント、パフォーマンステスト、ベンチマークなどを含む、安定性に関する明確で一貫した基準を単一のセットとして用意する。
計装ライブラリの安定化を容易にし、セマンティック規約のフェデレーションを促進する。
エンドユーザー組織にとって導入しやすい「エポックリリース」を導入する。

フィードバックをお待ちしています！

メンテナーやコントリビューターの皆さんには、この提案全般と、実装のタイムライン、安定性レベルの移行要件、テレメトリー出力の移行をどう扱うかなどの具体的な事項についてフィードバックをいただきたいです。

エンドユーザーの皆さんには、OpenTelemetry のリリースをどのように導入したいか、また現在どのように導入しているかについてフィードバックをいただきたいです。さまざまなバージョニングやリリース戦略を評価するにあたり、現在どのように変更をロールアウトしているか、特にポリグロット環境での状況を理解できると助かります。また、計装ライブラリや Collector などのコンポーネントに関するドキュメントやパフォーマンスベンチマークについてもフィードバックをお待ちしています。

インテグレーター、ベンダー、そしてより広いエコシステムの皆さんには、計装やセマンティック規約のメタデータとディスカバリーに関するフィードバックと建設的な提案をいただきたいです。 OpenTelemetry の上に、あるいは OpenTelemetry と並行して構築しているインテグレーターの皆さんには、皆さんやユーザーが OpenTelemetry をより簡単に利用できるようにするにはどうすればよいか、また皆さん自身の計装の公開と保守をより容易にするにはどうすればよいか、ぜひお聞かせください。

このブログの後続のセクションでは、フィードバックをいただきたい具体的な事項がほかにもあります。これらの目標を達成する具体的な方法は確定していないことを覚えておいてください。だからこそ、提案に対する皆さんのフィードバックを求めているのです！目標を達成するためのより良い方法があると思う場合は、ディスカッションでお知らせください。

ディスカッションに参加しましょう！

なぜこれを行うのか

OpenTelemetry は、大規模で複雑なエコシステムへと成長しました。 4つのテレメトリーシグナル（トレース、メトリクス、ログ、プロファイル）を12以上のプログラミング言語でサポートしています。各言語には固有のランタイム要件と実行環境があります。仕様準拠マトリックスを見れば、私たちがどれほど多くのことを達成しようとしているかがわかります。その量は圧倒的です。

この複雑さが導入の現実的な障壁を生み出しています。本番環境で OpenTelemetry をデプロイしようとする組織は、予期しない問題に直面します。マイナーバージョン間で設定が壊れたり、スケール時にのみ現れるパフォーマンスの後退が起きたり、数百から数千のサービスにわたるロールアウトの調整が困難であったりします。その結果、多くのチームが OpenTelemetry のデプロイメントを延期したり、規模を縮小したりしています。

メンテナーにとっても、この複雑さは仕事を必要以上に困難にしています。ある時点で「何が最も重要か」についての明確なマイルストーンやガイダンスが不足しています。安定化の取り組みには多くの変更が伴い、時間をどこに集中すべきかについて矛盾するガイダンスがあることも少なくありません。

これらの懸念への対処は、メンテナーやコントリビューターの健全性のためだけでなく、プロジェクトの成熟に伴い、特にクラウドネイティブエコシステムにより深く統合されていく中で、成長とスケールを続けるためにも、プロジェクトにとって高い優先度であるべきです。

Governance Committee は、これらの変更を成功させるにはコミュニティの関与と議論が必要であると考えています。そのため、この機会に私たちの意図を発表し、ユーザー、メンテナー、コントリビューターからのフィードバックを得るために 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 はこれらのファイルをリアルタイムで監視し、イベントをパースし、レガシーアプリケーションにコード変更を加えることなく、構造化されたメトリクスに変換できます。

メインフレームにおける OpenTelemetry の優先事項の探求 - アンケート回答からのインサイト

Sun, 28 Jun 2026 13:10:43 +0900

メインフレームのオブザーバビリティを向上させるために、ユーザーが最も重要と考える OpenTelemetry の機能は何でしょうか。今年初め、OpenTelemetry on Mainframes Special Interest Group（SIG）と Open Mainframe Project は、この問いに答えるためにアンケートを実施しました。このブログでは、アンケート結果の詳細な概要を紹介します。

背景と目的

OpenTelemetry プロジェクトは、あらゆるソースからあらゆるターゲットへ高品質でポータブルなテレメトリーを提供することで、効果的なオブザーバビリティを実現することを目指しています。このプロジェクトは現在、仕様と実装を網羅する90のリポジトリを GitHub 上でホストしています。 OpenTelemetry on Mainframes SIG が設立された際、メインフレームにおいて最も重要な OpenTelemetry コンポーネントを有効にすることを使命とし、セマンティック規約、プログラミング言語 SDK、および OpenTelemetry Collector の拡張の 3 つの重点領域に注力しました。 OpenTelemetry プロジェクトの広範なスコープとメインフレームの高度なアーキテクチャを考慮すると、メインフレームで OpenTelemetry の機能を最大限に活用するためには、ユーザーの優先事項を十分に理解することが不可欠であることがすぐに明らかになりました。アンケート結果が出揃った今、SIG はメインフレームプラットフォームでの OpenTelemetry の採用を加速するための活動に優先順位を付け、実施していきます。

主な知見

メインフレーム SIG の活動に優先順位を付けるための主な知見を以下に示します。

メインフレームコミュニティ内で OpenTelemetry の専門知識を向上させる。 OpenTelemetry 初心者26人のうち21人は 10 年以上のメインフレーム経験を持っていますが、11人はその機能についてまったく知識がないと回答しています。
System Performance メトリクスのセマンティック規約を優先し、続いて Job Processing、Databases、Applications を優先する。回答者のうち30人が OpenTelemetry はまずメトリクスに注力すべきだと考えており、メトリクスのカテゴリについて尋ねたところ、約32人がシステムメトリクスを最優先事項として挙げました。
z/OS 向けの Java および Python SDK を優先し、COBOL SDK を開発する。 Java（25人）と Python（20人）の SDK を希望するすべての回答者が、z/OS 向けの OpenTelemetry SDK も必要としています。 COBOL SDK は26人から要望があり、Java SDK と同等の重要度でした。
OpenTelemetry Collector を使用して System Performance および Platform メトリクスを収集する方法を評価する。回答によると、30人の参加者がエージェントとしてデプロイされた OpenTelemetry Collector で System Performance および Platform メトリクスを収集することに関心を示しました。 28人が Mainframe Operations を主なユーザーとして特定し、27人が OpenTelemetry 形式の System Performance メトリクスを自組織にとって最も重要と評価しました。

貢献方法

コントリビューターや組織の皆さんに、OpenTelemetry on Mainframes SIG への参加を呼びかけています。アンケートで明らかになった優先事項のオーナーシップを持ち、OpenTelemetry プロジェクトのコントリビューターになりましょう。たとえば、コード計装やポーティングの取り組みに参加してください。

自動計装の謎を解く: その仕組みを理解する

Sun, 28 Jun 2026 09:07:17 +0900

OpenTelemetry や eBPF が普及しているにもかかわらず、自動計装が内部で実際に何をしているかを理解している開発者はほとんどいません。この記事ではその仕組みを分解します。自分で自動計装を構築することを勧めるためではなく、ツールが「ただ動く」ときに何が起きているのかを理解する手助けとするためです。

ここでは、自動計装を支える 5 つの主要な技術を紹介します。モンキーパッチ、バイトコード計装、コンパイル時計装、eBPF、そして言語ランタイム API です。それぞれの技術は、異なるプログラミング言語やランタイム環境の固有の特性を活用し、コードを変更せずにオブザーバビリティを実現します。

自動計装とは何か

用語集によると、自動計装とは「エンドユーザーがアプリケーションのソースコードを変更する必要のないテレメトリー収集方法。方法はプログラミング言語によって異なり、バイトコードインジェクションやモンキーパッチがその例です。」と定義されています。

「自動計装」という用語は、関連はしているものの異なる 2 つの概念を指すためによく使われる点に注意が必要です。上記の定義およびこのブログ記事では、コードを変更せずにオブザーバビリティを実現するために使用できる特定の技術（バイトコードインジェクションやモンキーパッチなど）を指しています。一方、会話の中で「自動計装」と言う場合、OpenTelemetry Java エージェントのような完全なゼロコードソリューションを意味することがよくあります。

この区別は重要です。実際には 3 層の階層構造があります。最下層には、このブログ記事で紹介する自動計装の技術（バイトコードインジェクション、モンキーパッチなど）があります。これらの技術は、特定のフレームワークを対象とした計装ライブラリによって使用されます。たとえば、Spring および Spring Boot、Express.js、Laravel、その他の人気フレームワークを計装するライブラリがあります。そして、OpenTelemetry Java エージェントのような完全なソリューションは、これらの計装ライブラリをまとめ、エクスポーター、サンプラー、その他の構成要素に必要なボイラープレート設定をすべて追加します。

オブザーバビリティコミュニティでは適切な用語について議論が続いていますが、このブログ記事ではその議論の解決を試みません。

ある人にとって「自動」に見えるものが、別の人にとっては「手動」に見えることもあります。ライブラリ開発者が OpenTelemetry API を自分のコードに統合していれば、そのライブラリのユーザーは、アプリケーションに OpenTelemetry SDK を追加するだけで、そのライブラリからトレース、ログ、メトリクスを「自動的に」取得できます。

技術を自分で試してみたい場合

このブログ記事には、概念を説明するための小さなコードスニペットが含まれています。完全に動作するサンプルは、ラボリポジトリで試すことができます。

これらの技術を紹介する前に、重要な注意点があります。自動計装をゼロから自分で構築すべきではありません。特に、このブログ記事を設計図として使うべきではありません。ここでのサンプルは教育目的で簡略化されており、実際の実装で直面する多くの複雑な詳細は省略されています。複雑さやエッジケースの多くに対処してくれる確立されたツールやメカニズムが利用可能です。この分野をさらに深く掘り下げたい場合は、OpenTelemetry のような既存プロジェクトに貢献するのが最良のアプローチです。経験豊富なメンテナーから学び、本番環境で使えるコードに取り組むことができます。

自動計装の技術

それでは、これらの技術が内部でどのように動作するかを見ていきましょう。

モンキーパッチ: ランタイムでの関数置換

モンキーパッチは、おそらく最も直感的な自動計装の技術であり、JavaScript、Python、Ruby などの動的言語でよく使われます。コンセプトはシンプルです。ランタイムで既存の関数を計装済みバージョンに置き換え、元の関数の呼び出し前後にテレメトリーを挿入します。

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 への移行を計画する良い時期です。

宣言的設定のジャーニー: トレースにおけるヘルスチェックエンドポイントを無視するのに5年かかった理由

Fri, 05 Jun 2026 16:08:55 +0900

過去数年間にわたり、Java OpenTelemetryに対する最も持続的に人気のある機能リクエストのひとつは、効率的にヘルスチェックエンドポイントのスパンをドロップする（またはその他の価値が低くコストのかかるエンドポイントをドロップする）機能でした。このイシューは2020年8月に最初に提起されましたが、驚くほど長い間、包括的なソリューションは見つかりませんでした。なぜこの一見単純な問題を解決するのに5年もかかったのでしょうか？その答えは、OpenTelemetryの設定システムの基本原則と、より堅牢で柔軟なアプローチである宣言的設定へのジャーニーにあります。

OpenTelemetryは、当初から設定のために環境変数に依存していました。これは環境変数が言語を問わず普遍的に利用可能であり、解析が容易であるという理由からの選択でした。しかし、より複雑な設定のユースケースの必要性が高まるにつれて、単純な文字列ベースの環境変数の制限がますます明らかになり、高度な設定の管理が煩雑かつ困難になりました。

宣言的設定の導入は、YAMLファイルを活用してOpenTelemetryの設定を定義する強力な進化です。この変化により、任意のツリー構造のソースからデータを読み取ることが可能になり、複雑な設定へのアプローチが根本的に変わります。このポストを通じて、宣言的設定が過去の課題に対してどのようにエレガントなソリューションを提供するかを探り、Javaにおけるヘルスチェック除外などの実用的なユースケースでその即時的な影響を示します。

はじめに

設定ファイルは言語に依存しないため、一度ファイルを作成すれば、すべてのSDKで使用できます。唯一の例外は、特定の言語名を持ち、その言語にのみ関連するパラメーターです（たとえばinstrumentation/development.java.spring_batchパラメーター）。

宣言的設定は 実験的 であるため、まだ変更される可能性があることに注意してください。

次の例は、開始するために使用できる基本的な設定ファイルです。

file_format: '1.0-rc.1'

resource:
 attributes_list: ${OTEL_RESOURCE_ATTRIBUTES}
 detection/development:
 detectors:
 - service: # OTEL_SERVICE_NAMEから"service.instance.id"と"service.name"を追加します

propagator:
 composite:
 - tracecontext:
 - baggage:

tracer_provider:
 processors:
 - batch:
 exporter:
 otlp_http:
 endpoint: ${OTEL_EXPORTER_OTLP_TRACES_ENDPOINT:-http://localhost:4318/v1/traces}

meter_provider:
 readers:
 - periodic:
 exporter:
 otlp_http:
 endpoint: ${OTEL_EXPORTER_OTLP_METRICS_ENDPOINT:-http://localhost:4318/v1/metrics}

logger_provider:
 processors:
 - batch:
 exporter:
 otlp_http:
 endpoint: ${OTEL_EXPORTER_OTLP_LOGS_ENDPOINT:-http://localhost:4318/v1/logs}

実験的な宣言的設定オプションを有効にするには、アプリケーションにOTEL_EXPERIMENTAL_CONFIG_FILE=/path/to/otel-config.yamlを渡すだけです。この変数は、執筆時点ではJavaエージェントとJavaScriptでのみ機能します。

レガシー環境における 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トレースモデルの一部として残ります。

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

何をすべきか？

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

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

コントリビューターの募集: OpenTelemetry for Kotlin

Mon, 15 Dec 2025 21:01:52 +0900

なぜOpenTelemetry for Kotlinを立ち上げるのか？

Kotlin Multiplatform（KMP）は、ブラウザ、サーバー、デスクトップ環境など、さまざまなプラットフォームでKotlinのコードを実行できます。従来、KotlinはAndroidとJVMで最も人気がありましたが、KMPの登場により、異なるプラットフォーム間でコードを共有するために使用するユーザーが着実に増加しています。

Embraceは、KMPプロジェクトで使用できるOpenTelemetry仕様のKotlin実装を寄贈する提案を公開しました。これにより、KMPおよびKotlinプロジェクトは、1つのAPIで多くの異なるプラットフォーム向けのテレメトリーを取得できるようになります。このAPIは、可能な限りプラットフォームに依存しないOpenTelemetryの実装として設計されており、AndroidとiOSの重要なユースケースに対応するため、モバイルフレンドリーであることを目指しています。

opentelemetry-javaはJVM上で動作するKotlinアプリをサポートしていますが、これはJava相互運用に依存しており、Kotlinらしい慣用的なAPIだと「感じられません」。さらに、opentelemetry-javaはJVM上でしか動作しませんが、Kotlinは非JVMターゲットにもデプロイできます。

コントリビューターの募集

Kotlin MultiplatformでOpenTelemetryを使用することに興味がある方、ぜひご協力ください！コードベースのメンテナンス、定期的なSpecial Interest Group（SIG）ミーティングへの参加、SDKの発展に貢献してくださるコントリビューターを募集しています。

コントリビューターになることに興味がある方、または興味を持ちそうな方をご存知の方は、寄贈の提案にコメントしてください。

コントリビューターにはならないけれども、これまでのプロジェクトへのフィードバックや試用を したい という方は、こちらのリポジトリをご覧いただき、ご意見をissueとしてお寄せください。