ブログ on OpenTelemetry

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 万リクエストをさばいています。

Apache Arrow を用いた OpenTelemetry Protocol の本番環境での活用

Sun, 21 Jun 2026 20:28:55 +0900

Apache Arrow を用いた OpenTelemetry Protocol（OTel-Arrow）プロジェクトの OpenTelemetry Collector 向けエクスポーターとレシーバーのコンポーネントは、現在 OpenTelemetry Collector-Contrib のリリースに含まれています。本記事は、ServiceNow Cloud Observability において、社内テレメトリーデータの主要な取り込みパスとして OTel-Arrow コンポーネントを使った OpenTelemetry Collector をデプロイした経験に関するケーススタディです。

F5, Inc. が OpenTelemetry プロジェクトに最初のコントリビューションを行って以来、F5 を含むコミュニティメンバーは、コストの高いネットワークリンクを介して大量の OpenTelemetry データを転送するための、信頼性と性能に優れたソリューションへ OTel-Arrow エクスポーターおよびレシーバーコンポーネントを発展させるべく協力してきました。これらのコンポーネントを社内テレメトリーに使ったところ、非圧縮サイズの 15 分の 1 から 30 分の 1 になる圧縮効果を観測しています。 OpenTelemetry Protocol（「OTLP」）と Apache Arrow を用いた OpenTelemetry Protocol を、同様に構成したトレースパイプラインで並行比較したところ、圧縮効果が 30% 改善することを確認しました。この調査は特にトレースデータに焦点を当てていますが、ログとメトリクスのシグナルでも本番環境で同様の結果を観測しており、OTel-Arrow ユーザーは同様のパイプライン構成において OTLP と比較して 50〜70% の改善を期待できます。

これまでの実験結果が本番環境で検証されたことで、Apache Arrow を用いた OpenTelemetry Protocol のエクスポーターおよびレシーバーは一般に利用できる状態にあると考えています。

エクスポーターとレシーバーのコンポーネント

Apache Arrow は、OpenTelemetry と組み合わせる技術として優れています。両プロジェクトには多くの共通点があるからです。 OpenTelemetry と同様に、Apache Arrow は共有データ仕様、トランスポートプロトコル、クロス言語 API 仕様、そして多数のランタイム環境向けにコミュニティが構築した SDK を備えています。

The Humans of OpenTelemetry - KubeCon EU 2025

Sun, 21 Jun 2026 10:41:26 +0900

Humans of OpenTelemetry の第4弾をお届けします。今回の舞台は、イギリス・ロンドンで開催された KubeCon EU です。 Reese Lee と私は、再び OpenTelemetry のコントリビューターやエンドユーザーにインタビューし、彼らが OTel にどのように関わるようになったかを聞きました。

Marylia Gutierrez (Grafana Labs)
Adriel Perkins (Liatrio)
Hanson Ho (Embrace)
Jamie Danielson (Honeycomb.io)
Mikko Viitanen (Dynatrace)
Damien Mathieu (Elastic)
Jacob Aronoff (Omlet)
Alolita Sharma (Apple)

また、以下の方々に特別な感謝を捧げます。

Reese Lee：共同インタビュアー
Henrik Rexed：音声・映像収録機材の提供と、撮影素材の初期編集

録画の全編はこちらからご覧いただけます。

これまで OpenTelemetry に貢献してくださったすべての方々に感謝します。 2025年以降も皆さんの継続的な貢献を楽しみにしています！🎉

Gateway API と mTLS を使用して Kubernetes で OTel Collector を公開する

Fri, 19 Jun 2026 07:58:27 +0900

このブログ記事の目的は、Kubernetes 内で動作する OpenTelemetry（OTel）Collector を、Kubernetes Gateway API と相互 TLS（mTLS）を使用して、認証と暗号化を伴いつつ安全に外部に公開する方法を紹介することです。

現代の分散システムにおいてオブザーバビリティがますます重要になる中、1つまたは複数の Kubernetes クラスターにデプロイされた OTel Collector を介してテレメトリーデータを集約することは一般的なプラクティスです。多くの場合、Kubernetes クラスターの外部で実行されているサービスやエージェントが、これらの Collector にデータを送信する必要があります。内部サービスの公開にはセキュリティと標準化の慎重な検討が必要です。ここで Kubernetes Gateway API と mTLS が力を発揮します。

通常、このようなセットアップは、クラスター外部にアプリケーションやワークロードがあり、それらのテレメトリーデータを収集する必要がある場合に役立ちます。以下にいくつかの例を示します。

ハイブリッドクラウド/オンプレミス環境: 従来のデータセンター、別のクラウド、または Kubernetes クラスター外部で実行されているアプリケーションやサーバーが、メトリクス、トレース、またはログを中央のオブザーバビリティソリューションに転送する必要がある場合。
マルチクラスターテレメトリー集約: 複数の Kubernetes クラスターで実行されるセットアップにおいて、1つのクラスターをプライマリの OTel Collector デプロイメントのホストとして指定する場合があります。他の「スポーク」クラスター内の Collector はクライアントとして機能し、外部エンドポイントを介して中央の Collector にデータをエクスポートします。たとえば、マルチクラスターサービスメッシュ構成では、テイルベースサンプリングを中央で実行する必要がある場合があります。この場合、テイルベースサンプリングプロセッサーが設定され、Gateway 経由で公開されている中央の Collector が、すべてのクラスターからスパンを集約してサンプリングの判断を行います。
エッジコンピューティング/IoT: エッジにデプロイされたデバイスは、運用データを中央プラットフォームに送信する必要があることが多いです。
サーバーレス関数/PaaS: サーバーレスプラットフォーム（AWS Lambda、Google Cloud Functions など）やクラスター外部の Platform-as-a-Service で実行されているアプリケーションが OTLP データをエクスポートする必要がある場合。
外部監視エージェント: クラスター内の共有 Collector に接続する必要があるサードパーティエージェントやローカルで実行されている開発インスタンス。
クライアントサイド監視: ブラウザやモバイルアプリケーションなどの外部クライアントから送られるテレメトリー。ブラウザからのテレメトリーエクスポートでは mTLS が使用されない場合がありますが、Collector は最終的に利用可能にする必要があります。

前提条件

始める前に、以下を準備してください。

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 にルーティングします。

The Humans of OpenTelemetry - KubeCon NA 2024

Mon, 15 Jun 2026 23:14:36 +0900

Humans of OpenTelemetry の第3弾をお届けします。今回の舞台は、アメリカ・ユタ州ソルトレイクシティで開催された KubeCon NA です。 Reese Lee と私は、再び OpenTelemetry のコントリビューターやエンドユーザーに（そしてお互いにも！）インタビューし、彼らが OTel にどのように関わるようになったかを聞きました。

また、以下の方々に特別な感謝を捧げます。

Reese Lee：共同インタビュアー
Henrik Rexed：音声・映像収録機材の提供と、撮影素材の初期編集

動画

フルバージョンの録画はこちらからご覧いただけます。

これまで OpenTelemetry に貢献してくださったすべての方々に感謝します。 2025年以降も皆さんの継続的な貢献を楽しみにしています！🎉

OpenTelemetry Spring Boot スターターが安定版になりました

Mon, 15 Jun 2026 23:13:48 +0900

OpenTelemetry Spring Boot スターターが安定版になったことをお知らせします。

Spring Boot スターターは、Spring Boot アプリケーションを OpenTelemetry で計装するプロセスを簡素化する強力なツールです。 OpenTelemetry Java エージェントに対する軽量で柔軟な代替手段を提供し、Spring Boot アプリケーションのオブザーバビリティをこれまで以上に簡単に実現できるようにします。

このブログ記事では、Spring スターターをいつ使用すべきか、安定版であるとはどういう意味か、主な機能は何か、そしてどのような課題に直面したかを説明します。最後のパートでは、GraalVM ネイティブイメージアプリケーションを使用して、スターターの機能の一部をデモンストレーションします。

すぐに始めたい場合は、Spring スターターのドキュメントをご覧ください。

Spring スターターを使用するタイミング

Spring スターターを使用したいシナリオをいくつか紹介します。

OpenTelemetry Java エージェントが動作しない Spring Boot ネイティブイメージアプリケーション
OpenTelemetry Java エージェントの起動オーバーヘッドが要件を超える場合
別の監視用 Java エージェントがすでに使用されており、OpenTelemetry Java エージェントとの互換性の問題が発生している場合
Spring Boot 設定ファイル（application.properties、application.yml）を使用して OpenTelemetry Spring Boot スターターを設定する場合（OpenTelemetry Java エージェントでは動作しません）
Spring Bean を使用した OpenTelemetry Spring Boot スターターのプログラムによる設定、たとえば動的な認証ヘッダーなど（OpenTelemetry Java エージェントではこのためにエクステンションが必要です）
コード依存関係を使用: JVM オプション（たとえば Docker ファイル内）を追加する必要がなく、pom.xml または build.gradle ファイルに依存関係と BOM を追加するだけです

少し意外かもしれませんが、Spring ネイティブイメージアプリケーションをビルドしない場合、デフォルトの推奨は、バイトコード計装を備えた OpenTelemetry Java エージェントを使用することです。後で説明するように、Spring スターターの計装よりも多くのすぐに使える計装を提供するためです。

Prometheus と OpenTelemetry - ともに、より良く

Mon, 15 Jun 2026 23:13:47 +0900

Prometheus や OpenTelemetry のようなツールは、複雑な分散システムの健全性、パフォーマンス、可用性の監視に役立ちます。どちらも Cloud Native Computing Foundation (CNCF) 傘下のオープンソースプロジェクトですが、オブザーバビリティにおいてそれぞれどのような役割を果たしているのでしょうか。

OpenTelemetry（略称 OTel）は、テレメトリーデータの計装、生成、収集、エクスポートのためのベンダー中立なオープン標準です。 Prometheus はオブザーバビリティの分野で定番のツールであり、組織内の監視とアラートに広く利用されています。

Prometheus と OTel はどちらもメトリクスを出力しますが、両者の違いと類似点については多くのことがあり、この記事の範囲外です。ここでは、OTel がどのように Prometheus をサポートしているか、特に Kubernetes 環境での連携に焦点を当てて紹介します。この記事で学べること：

OTel Collector の Prometheus レシーバーを使って Prometheus メトリクスを取り込む方法。
K8s クラスターレシーバーや Kubelet 統計レシーバーなど、OTel ネイティブのオプションによる Prometheus メトリクス収集の代替手段。

また、OTel Operator の Target Allocator（TA）について技術的に掘り下げ、以下を学びます：

Prometheus のサービスディスカバリにどのように活用できるか。
Prometheus ターゲットの均等な分配をどのように実現するか。

OTel と Prometheus

OTel は主にオブザーバビリティの計装部分に焦点を当てているため、テレメトリーを保存するバックエンドは提供していません。データの保存、アラート、クエリのためにバックエンドベンダーにデータを転送する必要があります。

一方、Prometheus は計装クライアントに加えて、メトリクス用の時系列データストアを提供します。グラフやチャートの表示、アラートの設定、Web ユーザーインターフェイスを通じたデータのクエリが可能です。また、Prometheus テキストベースのエクスポジションフォーマットとして知られるデータフォーマットも含んでいます。

Prometheus の データ はディメンショナル時系列として保存されます。つまり、データには属性（たとえばラベルやディメンション）とタイムスタンプがあります。

Prometheus サーバー は、設定ファイルで定義されたターゲットから Prometheus メトリクスデータを収集します。ターゲットとは、Prometheus サーバーが保存するメトリクスを公開するエンドポイントのことです。

KubeCon + CloudNativeCon Japan 2025で、 OpenTelemetryのトークとアクティビティに参加しよう

Mon, 15 Jun 2026 23:11:08 +0900

OpenTelemetryプロジェクトは、KubeCon + CloudNativeCon Japan（参加登録）および東京で同時開催されるCommunity Day（2025年6月14日〜17日）で、OpenTelemetryコミュニティのメンバーと一緒に過ごすことを皆さんにご案内します。

この記事では、KubeCon期間中に予定されているOpenTelemetry関連のすべてのアクティビティを紹介しています。カンファレンス開始前に、随時更新情報をチェックしてください！

Community Day

これは6月15日に開催される無料のイベントで、本カンファレンスに先立ち、クラウドネイティブコミュニティと交流する貴重な機会です。

Community Dayでは、KubeCon + CloudNativeCon Japanの参加者と、さまざまな地域ミートアップコミュニティ、Special Interest Group（SIG）やCloud Native Community Japanのサブグループのメンバーが一堂に会し、クラウドネイティブエコシステムにおける協業、学び、貢献を促進します。このイベントは、クラウドネイティブ開発やコミュニティ参加のさまざまな側面を対象とする複数のテーマ・トラックに分かれて構成されています。今すぐ登録しましょう！

KubeConトーク一覧

⚡ Lightning Talk: OTel 2025: The Latest Milestones and What’s Next（OTel 2025：最新の進展と今後の展望）
Steve Flanders（Contributor）
6月17日（火）• 11:51 - 11:56
Full Lifecycle API Management in Kubernetes With Envoy and WebAssembly（EnvoyとWebAssemblyを使ったKubernetesでのフルライフサイクルAPI管理）
Brandon Kang（Akamai Technologies）& Mostafa Radwan（Datadog）
6月17日（火）• 14:10 - 14:40
Navigating Millions of Kafka Events in Real Time With OTel（OTelで数百万のKafkaイベントをリアルタイム処理）
Siddharth Vijay（Baazi Games）& Shivay Lamba（Couchbase）
6月17日（火）• 14:10 -14:40

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、コンテナ上）で動作し、産業環境とオブザーバビリティバックエンドの間のブリッジとして機能します。このモデルでは、次のような利点があります。

AIエージェントオブザーバビリティ - 標準の進化とベストプラクティス

Tue, 26 May 2026 18:06:05 +0900

2025年、AIエージェントの年

AIエージェントは、2025年の人工知能における次の大きな飛躍になりつつあります。自律的なワークフローからインテリジェントな意思決定まで、AIエージェントは業界を横断する数多くのアプリケーションを強化するでしょう。しかし、この進化に伴い、特に企業のニーズに合わせてこれらのエージェントを拡張する場合、AIエージェントのオブザーバビリティが非常に重要になります。適切な監視、トレース、ロギングのメカニズムがなければ、AIエージェント駆動型アプリケーションの問題を診断し、効率を改善し、信頼性を確保することは困難です。

AIエージェントとはなにか

AIエージェントとは、LLMの能力、外界に接続するツール、高レベルの推論を組み合わせて使用し、望ましい最終目標や状態を達成するアプリケーションのことです。別の言い方では、エージェントは、LLMが自身のプロセスやツールの使い方を動的に指示し、タスクを達成する方法を制御するシステムとして扱うこともできます。

Image credit: Google AI Agent Whitepaper.

AIエージェントについての情報は他にも以下を参照してください。

オブザーバビリティのかなたへ

通常、アプリケーションからのテレメトリーは、アプリケーションの監視とトラブルシューティングのために使用されます。 AIエージェントの場合、その非決定論的な性質から、テレメトリーは、評価ツールのインプットとして使用することで、エージェントの品質から継続的に学び、改善するためのフィードバックループとしても使用されます。

生成AIのためのオブザーバビリティと評価ツールがさまざまなベンダーから提供されていることを考えると、ベンダーやフレームワーク固有のフォーマットによるロックインを避けるために、エージェントアプリによって生成されるテレメトリーの形状に関する標準を確立することが重要です。

AIエージェントのオブザーバビリティの現状

AIエージェントのエコシステムが成熟し続けるにつれて、標準化された強固なオブザーバビリティの必要性がより明らかになってきています。いくつかのフレームワークが組み込みの計装を提供する一方で、他のフレームワークはオブザーバビリティツールとの統合に依存しています。この断片的な状況は、生成AIオブザーバビリティプロジェクトとOpenTelemetryの新たなセマンティック規約の重要性を強調しています。これらは、テレメトリーデータがどのように収集され報告されるかを統一することを目的としています。

AIエージェントアプリケーションとAIエージェントフレームワークの比較

AIエージェントアプリケーションとAIエージェントフレームワークを区別することは極めて重要です。

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としてお寄せください。