ブログ on OpenTelemetry

OpenTelemetry JavaScript SDK 3.0 のリリース

Fri, 06 Nov 2026 11:32:20 +0000

OpenTelemetry JavaScript は SDK 3.0（安定版 v3.0.0 パッケージおよび実験的 v0.300.0 パッケージ）と API 1.10.0 をリリースしました。

マイグレーションガイド

破壊的変更の詳細については、OpenTelemetry JS SDK 3.x マイグレーションガイドを参照してください。

JS SDK 3.x とは

JS SDK 3.x は、opentelemetry-js リポジトリから公開されている @opentelemetry/* JavaScript パッケージの新しいリリースを包含するもので、API パッケージおよび semantic-conventions パッケージは除きます。この新しいメジャーバージョンのパッケージバージョンは、安定版が >=3.0.0、不安定版が >=0.300.0 です。パッケージの完全な一覧についてはマイグレーションガイドを参照してください。

加えて、opentelemetry-js-contrib リポジトリのすべてのパッケージが JS SDK 3.x にアップグレードされ、リリースされました。

OpenTelemetry のガイドラインに従い、安定版 SDK パッケージの 2.x バージョンは 3.0.0 リリースから1年間サポートされます。

変更点

サポートされる Node.js の最小バージョンが >=22.15.0 に引き上げられました。 これは、Node.js 18 および 20 のサポートが廃止されたことを意味します。
すべてのパッケージが適切な ES Module（ESM）および CommonJS エクスポートを提供するようになりました。これにより、ESM やバンドラーを使用するユーザーにとって使い勝手が大幅に向上します。
OTEP 4485 に基づく複合属性のサポートが API の一部（スパン属性、ログレコード属性など）に追加されました。 API の一部では単純属性のみサポートされています（リソース属性、メトリクス属性など）。詳細はマイグレーションガイドの解説を参照してください。
@opentelemetry/api-logs パッケージが @opentelemetry/api に統合されました。 ログシグナルが安定版になりました！ ログの安定化により、OpenTelemetry の3つのシグナル（トレース、メトリクス、ログ）すべてが JavaScript で安定版となりました。この安定化については別途ブログ記事を投稿する予定です。
複数のトレーシング SDK パッケージが統合され、@opentelemetry/sdk-trace パッケージにまとめられました。これにより、紛らわしい API が排除され、他のシグナルの SDK との一貫性が確保されました。
多くの非推奨パッケージが削除されました。 @opentelemetry/propagator-jaeger、@opentelemetry/exporter-jaeger、@opentelemetry/shim-opentracing、@opentelemetry/shim-opencensus などが含まれます。完全な一覧についてはマイグレーションガイドを参照してください。
パブリックインターフェイスが変更されました。 いくつかのパブリック型やクラス名が名前変更または移動されました。

API パッケージ（@opentelemetry/api）には破壊的変更はありません。また、ゼロコード計装で説明されているように @opentelemetry/auto-instrumentations-node パッケージを使用しているユーザーは変更の必要はありません。

Keycloak のオブザーバビリティへの道のり：プロジェクトメンテナーのためのガイド

Wed, 04 Nov 2026 14:02:54 +0000

Developer Experience SIG では、進行中のシリーズの一環として、OpenTelemetry の実際のデプロイメントについて組織にインタビューを行い、実践的な教訓をより広いコミュニティと共有しています。この記事では CNCF プロジェクトである Keycloak を取り上げ、出荷するソフトウェアにネイティブな OpenTelemetry サポートを追加するプロジェクトメンテナーの視点から、その道のりを見ていきます。

Identity and Access Management（IAM）ソリューションが必要になったことがあるなら、Keycloak が候補に挙がった可能性は高いでしょう。 Keycloak は広く使われているコミュニティ主導のオープンソース IAM システムで、OpenID Connect（OIDC）、OAuth 2.0、SAML などの業界標準プロトコルを通じて、人間と人間以外のユーザーの両方を認証し、アプリケーションを保護します。

Keycloak チームの Martin Bartoš と Alexander Schwartz がシステムの本番運用への準備を改善しようとしたとき、彼らは「すぐに使える」オブザーバビリティ体験を思い描いていました。 Quarkus Java フレームワークを基盤として、高リスクな認証フローでユーザーが信頼できるネイティブテレメトリーを目標としていました。しかし、スムーズな OpenTelemetry 統合への道のりは、メンテナーの道のりが新しいシグナルの実装と同じくらい、アーキテクチャ上のトレードオフに関わるものであることを明らかにしました。

ネイティブがエージェントに勝るとき：Java の世界からの教訓

最初の明らかな一手は OpenTelemetry Java エージェントでした。これは起動時にアタッチしてバイトコードをオンザフライで書き換えることで、あらゆる JVM アプリにトレーシングを導入するゼロコードの方法です。これにより、チームは OpenTelemetry の機能をすばやく試すことができましたが、コストはすぐに現れました。 Keycloak の場合、それまで瞬時に起動していたものがエージェントによって起動時間が数十秒遅くなりました。これは Keycloak に限った問題ではありません。エージェントはアプリケーションがロードするすべてのクラスをスキャンし、場合によっては変換する必要があり、エージェントのメンテナーもこの起動オーバーヘッドがこのアプローチに固有のものであることを確認しています。ユーザーからは起動時間がおよそ3分の1増加したとの報告があります。

「OpenTelemetry Java エージェントにより機能を試すことはできましたが、Keycloak の起動が非常に遅くなりました」と Alexander Schwartz はインタビューで述べました。「即座のパフォーマンスと迅速なスケーリングが重要なセキュリティに敏感なアプリケーションにとって、起動時間に数十秒を追加することは、サポートしたいことではありませんでした。」

チームはネイティブの Quarkus 統合に移行しました。これにより、必要なテレメトリーを維持しながら高速な起動を保つことができました。同様にパフォーマンスに敏感なアプリケーションのメンテナーにとって、汎用エージェントよりもネイティブフレームワークサポートを優先する価値があります。

シグナルの統合：メトリクスとトレース

Keycloak のオブザーバビリティへの道のりはメトリクスから始まり、すぐに価値をもたらしましたが、チームはまもなく、トレーシングこそが詳細な根本原因分析に欠けていた要素であることに気づきました。データベースや LDAP のボトルネックを伴う複雑なフローでは、トレーシングがリクエストがどこで停滞しているかを正確に特定するために必要なコンテキストを提供しました。これらのシグナルをリンクする力が最も明確になったのはエグゼンプラーで、これにより開発者はメトリクスのスパイクから代表的なトレースに直接ジャンプでき、99パーセンタイルのレイテンシーをトラブルシューティングする時間を劇的に短縮しました。

Kubernetes attributes processor が v1.0.0 マイルストーンに到達

Mon, 02 Nov 2026 12:22:04 +0000

Kubernetes メタデータでテレメトリーを拡充する Kubernetes attributes processor が、正式に v1.0.0 へ移行しました！カスタムディストロで試すことができ、最新の opentelemetry-collector-contrib および opentelemetry-collector-k8s ディストロリリースの一部としても利用可能です。

v1.0.0 であることは、このコンポーネントがテスト、ベンチマーク、ドキュメント、テレメトリーの安定性に関する要件を含む ‘stable’ 安定性基準を満たすことが検証されたことを意味します。また、API の破壊なしに Go ライブラリとして、またはバイナリの一部として再配布できることも保証されます。

変更内容と移行期間の管理方法については、移行ガイドをお読みください。

ここまでの経緯と今後の展望

2025年後半から、OpenTelemetry Collector SIG は OpenTelemetry プロジェクトの “Stable by Default” の取り組みの一環として、複数のコンポーネントの安定化に取り組んできました。これらの取り組みは、Collector ライブラリフレームワークの安定性を提供し、v1 Collector ディストロを生み出すための既存の取り組みを補完し、継続しています。

Collector のアンケートに対するエンドユーザーのフィードバックのおかげで、最もよく使われているコンポーネントと、安定性と信頼性がユーザーの最優先事項であることがわかりました。これにより、どのコンポーネントに注力すべきかが明確になり、ユーザーの期待に応えることを目指す厳格な基準に重点を置いた安定化へのロードマップも明確になりました。

これらの基準を満たすことは容易ではありません。コンポーネントの安定化には、そのコンポーネントが依存するセマンティック規約や仕様の一部の安定化も伴うため、Collector SIG は K8s Semantic Conventions SIG、System Semantic Conventions SIG、Prometheus Interoperability SIG などの他の SIG と緊密に協力しています。

K8s Semantic Conventions SIG はこの依存関係を早期に発見し、2025年11月に対応する K8s セマンティック規約を安定化するための集中的な作業を開始しました。 2026年3月にこれらのセマンティック規約はリリース候補の状態に達し、2026年6月に Semantic Conventions v1.42.0 で安定版として出荷されました。

これにより、Kubernetes attributes processor は安定した K8s 属性でテレメトリーを拡充できるようになり、コンポーネントのテレメトリーが今後も安定し続けることが保証されました。コンポーネントを安定性要件に適合させるための長期にわたる作業とともに、コンポーネントは卒業プロセスを経ました。このコンポーネントをすでに本番環境で使用しているエンドユーザーと、再配布しているベンダーからの数週間にわたるコミュニケーションと承認を経て、コンポーネントは v1.0.0 として承認されました。

OpenTelemetry eBPF Instrumentation が v1.0.0 に到達

Sat, 31 Oct 2026 10:18:31 +0000

OpenTelemetry eBPF Instrumentation（OBI）の v1.0.0 を発表できることを嬉しく思います。

OBI は、ソースコードを変更することなく、実行中の Linux アプリケーションに OpenTelemetry のオブザーバビリティを提供します。 OBI は eBPF とランタイム固有の計装を組み合わせて、サービス、言語、フレームワークを横断してアプリケーションのメトリクスとトレースをキャプチャします。リクエストレート、エラー、レイテンシー、サービス依存関係から始めて、ニーズの拡大に応じてより深い可視性を構築できます。

このリリースは、2026年に設定したフラッグシップ目標を達成するものです。 OBI の安定した基盤を確立するという目標です。これは、計装カバレッジの拡大、正確性の向上、リリースツールの強化、そしてユーザーが OBI を長期的に運用するために必要な互換性とテレメトリー移行プラクティスの構築に費やした1年間の成果を反映しています。

ユーザーにとって最も重要な変更は予測可能性です。アップグレード時に何が起こるかを把握し、何かが変わったときにどう進めばよいかを知ることができます。

OBI 1.0 は、Config v2、その生成スキーマ、ドキュメント化されたデプロイインターフェイス、サポート対象環境を含む、設定とデプロイに関するドキュメント化された互換性コミットメントを確立します。

テレメトリーに関しては、OBI と OpenTelemetry が進化する中での信頼性の高い移行パスがコミットメントです。 OBI は、安定したセマンティック規約に従うテレメトリーと、規約がまだ策定中のテレメトリーを混在して出力します。後者は、規約の成熟に伴い変更される可能性があります。また、安定した規約に従うテレメトリーの実際の動作が規約に準拠していない場合、そのバグも修正します。

この進化を管理しやすくするために、OBI はテレメトリーを Weaver 互換のスキーマレジストリで記述しています。 OpenTelemetry Weaver は、テレメトリーを定義、検証し、従うべき規約に照らしてレビューするのに役立ちます。公開されたテレメトリースキーマは、変更を表現できる場合にバージョン間の変換を記述し、追加の対応が必要な変更についてはリリースノートと移行ガイダンスで説明します。

ダッシュボード、アラート、処理パイプラインを管理するチームにとって、これはアップグレードを計画し、意図的に適応するための手段を提供します。テレメトリーの進化に伴い、定義、ツール、ガイダンスを備えた、サポートされた前進パスを提供することが約束です。

この基盤には、プロジェクト全体にわたる大幅な進展が伴っています。

アプリケーション依存関係のより広い可視性。 1.0 に至るリリースを通じて、OBI は MQTT、NATS、AMQP 1.0、MSSQL、Couchbase、Memcached、Aerospike を含むシステムへの計装を追加しました。多様なテクノロジースタックを運用するチームにとって、これは1つの計装アプローチでデータベースとメッセージングのアクティビティを理解する機会が増えることを意味します。サポートマトリクスには、各プロトコルのカバレッジ、トレース伝搬機能、制限事項が記載されています。
より良いトレースとより有用なサービス詳細。 HTTP/2 と gRPC の伝搬の改善により、既存の接続、多重化されたトラフィック、個々のストリームコンテキストの処理が強化されました。フレームワークルートの検出は Django、FastAPI、Flask、Rails、.NET、いくつかの PHP フレームワークに拡大しました。ルートテンプレートは、一意の URL をそれぞれ別のメトリクス系列にすることなく、遅いエンドポイントを区別するのに役立ちます。
自動計装からアプリケーション固有のインサイトへのパス。 OBI は、サポートされている OpenTelemetry Go Trace API と Auto SDK の設定を通じて、アプリケーションが作成したスパンをキャプチャできます。 Node.js でも、登録された SDK がないアプリケーション向けにオプトインの手動スパンキャプチャが追加されました。これらの機能により、開発者は OBI が周囲の自動計装を提供しつつ、ビジネスオペレーションに関する詳細を追加できます（ドキュメント化されたランタイム要件に従います）。

独自の Collector をビルドして必要なリソース検出器だけを含める

Sat, 31 Oct 2026 07:15:59 +0000

独自の OpenTelemetry Collector ディストリビューションをビルドする理由は数多くあります。既存のディストリビューションは幅広く役立つように設計されているため、個々のデプロイメントで使用するよりもはるかに多くのコンポーネントが含まれています。独自にビルドすることで、必要なコンポーネントだけを選択し、独自のカスタムコンポーネントを追加し、本番環境で実行するバイナリに含まれるものを正確にコントロールできます。

私が独自のディストリビューションをビルドすることを好む理由のひとつは、配布するバイナリのサイズを制限し、含まれる依存関係を最小限に抑えるためです。依存関係が少なければ、バイナリは小さくなり、攻撃対象領域も小さくなり、脆弱性が公開された際に追跡すべきサードパーティモジュールも少なくなります。 OpenTelemetry Collector Builder（ocb）がこれを可能にします。YAML でマニフェストファイルを書いて必要なコンポーネントを選択すると、ocb がそれらをコンパイルして最終的なバイナリを生成します。

リソース検出器

コンポーネントを制限するのは素晴らしいことですが、あるユーザーが最近報告したように、リソース検出器は使わない依存関係でバイナリのサイズを肥大化させる可能性があります。リソース検出器は、プロセスが生成するテレメトリーにリソース属性を自動的に注入するために使用されます。クラウド環境では、アプリケーションやサービスのデプロイメントに関するできるだけ多くの情報を取得したい場合に非常に有用です。

問題は、異なる環境（さまざまなクラウドプロバイダー、コンテナランタイムなど）の検出器がそれぞれ独自の依存関係を持ち込むことです。リソース検出プロセッサーのようなリソース検出をサポートするコンポーネントを選択すると、たとえ1つの環境でしか実行しない場合でも、すべての検出器がコンパイルされます。

さらに、Collector はバージョン v0.128.0 以降、内部テレメトリーに OpenTelemetry Configuration Schema のサポートを含んでいます。これは otelconf パッケージを介して行われており、このパッケージもリソース検出器をサポートしています。このパッケージは、リソース検出プロセッサーが含まれていなくても Collector にコンパイルされます。これまで、マニフェストには「これらの検出器だけが必要」と指定する方法がありませんでした。

Go ビルドフラグの使用

ocb は通常の Go プログラムを生成するため、標準的な Go ツールで結果をすでにトリミングできます。たとえば、-ldflags="-s -w" でデバッグ情報とシンボルテーブルを除去し、-trimpath でローカルファイルシステムのパスを削除すれば、バイナリのサイズが小さくなります。これらはすでに ocb のデフォルトであり、必要に応じてコマンドラインフラグで上書きできます。

ただし、これらのフラグはコンパイルされたものを縮小するだけです。バイナリがまだインポートしているコードを除去することはできないため、リソース検出器の問題は解決しません。ビルドタグはビルドからコードを除外できますが、依存先のコードがビルドタグを提供している場合に限ります。幸い、otelconf とリソース検出プロセッサーの両方への更新により、検出器をコンパイル時に除外できるようになりました。たとえば、以下の設定はシステムリソース検出器を除外します。

dist:
 module: github.com/open-telemetry/opentelemetry-collector-releases/core
 name: otelcol
 description: OpenTelemetry Collector
 version: 0.163.1
 output_path: ./_build
 build_tags: 'omit_detector_system'

各検出器は omit_ フラグで無効化できます。これにより、Collector はデフォルトですべての検出器を含み続け、既存の動作との後方互換性を維持できます。これはエンドユーザーに大きな柔軟性を提供しますが、設定が煩雑になる可能性があります。以下は、現在利用可能なすべての検出器を無効化する例です。

API の安定性を維持しながら OpenTelemetry のセキュリティを強化する

Sat, 31 Oct 2026 07:03:30 +0000

OpenTelemetry は、動作の変更が必要なセキュリティ修正に対応するため、クライアントバージョニングポリシーを更新しました。安定版の SDK および計装ライブラリやエクスポーターなどの Contrib コンポーネントは、既存のユーザーに影響する場合でも、限定的な範囲で必要なセキュリティ変更をマイナーリリースまたはパッチリリースで行えるようになりました。パブリック API の互換性は引き続き保護されます。

この目的は、ユーザーが現在使用しているメジャーバージョン内でセキュリティの改善を受けられるようにすることです。一部のアップグレードでは、設定や運用上の変更が必要になる場合があります。そのような場合、リリースノートで影響と対応方法を説明しなければなりません。

安定性にセキュリティ修正への道筋が必要な理由

私たちのエンジニアリングの価値観は「安定性を重視する」と述べています。この約束は重要です。アプリケーションやライブラリは OpenTelemetry に依存しており、オブザーバビリティツールのアップグレードは予測可能であるべきです。

しかし、変更されない動作がセキュリティ上の脆弱性となることがあります。たとえば、制限のないテレメトリーを受け入れると、攻撃者がアプリケーションの入力を過剰なメモリ使用に変えてしまう可能性があります。以前は受け入れていた入力を拒否するセーフガードは、すべてのアプリケーションが引き続きコンパイルできるとしても、動作を変更します。

明示的な例外規定がなければ、そのような緩和策には新しいメジャーバージョンが必要になる可能性があります。これは難しい選択を生みます。既存のリリースラインでリスクのある動作を維持するか、保護を得るためにユーザーにメジャーアップグレードを求めるかです。新しいポリシーは、明確な境界と移行情報を伴い、現在のメジャーバージョン内で緩和策を提供するための道筋を提供します。

AI はタイムリーなセキュリティ改善をより緊急なものにしています。英国国立サイバーセキュリティセンターの AI とサイバー脅威の評価は、AI が脆弱性の研究と悪用を改善し、防御側が対応できる時間を短縮すると予測しています。ツールが攻撃者による脆弱性の発見と悪用を加速できる場合、微細な弱点でも注意に値します。 OpenTelemetry にとって、これはセキュリティアップデートを実用的に導入できるようにする必要性を強化します。

セキュリティリリースで変更できること

セキュリティリスクへの対応が必要な場合、安定版の SDK および Contrib コンポーネントは、メジャーバージョンの変更なしに動作、設定のデフォルト値、またはサポートされる設定値を変更できます。これには、以前ドキュメント化されていた動作も含まれます。該当する修正はパッチリリースで提供できます。

例としては、証明書の検証の厳格化、安全でないプロトコルの無効化、テレメトリーに認証情報が表示されることの防止、またはサービス拒否のリスクを軽減するためのリソース制限の導入があります。緩和策の内容によっては、以前受け入れられていたデータや設定が拒否されたり、テレメトリーが切り詰められたり破棄されたりする可能性があります。無効な設定は、アプリケーションの初期化の失敗を引き起こすこともあります。

メモリ枯渇のリスクを軽減するための、仮想的な SDK の属性値制限を考えてみてください。アプリケーションは引き続きコンパイルできますが、大きすぎる値は切り詰められ、メモリ負荷が軽減される一方で、ダッシュボードに届く内容も変わります。この影響はインシデント発生時に重要です。このような変更は仕様に準拠し、セキュリティ上の利点、テレメトリーへの影響、および移行オプションを説明しなければなりません。

例外規定には明確な境界がある

すべての変更は、セキュリティリスクの緩和に必要な範囲に限定されなければなりません。既存のソースおよびバイナリ互換性の保証（SDK プラグインインターフェイスを含む）を維持し、OpenTelemetry のエラーハンドリング要件に準拠しなければなりません。

この例外規定を使用して、パブリック API の名前変更や削除、シグネチャの変更、設定パラメーターの名前変更や削除、セマンティック規約の再定義、またはシグナルの非推奨化および削除ルールの回避を行うことはできません。無関係な非互換の変更を含めることもできません。安定版の API パッケージは、同じメジャーバージョン内での互換性保証を維持します。

アップグレード時の確認事項

リリースノートはセキュリティ変更の一部です。リリースノートには、リスクと緩和策、影響を受ける動作と設定、変更前後の動作、新たに拒否される入力、切り詰めまたは破棄されるテレメトリー、および必要なユーザーアクションを記載しなければなりません。また、利用可能な移行パスとそのセキュリティへの影響についても記載しなければなりません。

KubeCon NA 2026で、OpenTelemetryのトークとアクティビティに参加しよう

Sat, 31 Oct 2026 00:28:54 +0000

OpenTelemetry のプロジェクトメンテナー、ガバナンス委員会メンバー、および技術委員会メンバーは、2026年11月9日から12日にかけてソルトレイクシティで開催される KubeCon NA に参加できることを楽しみにしています。ぜひ参加登録して、一緒に盛り上がりましょう！

KubeCon 期間中に予定されている OpenTelemetry 関連のすべてのイベントをご紹介します。

OpenTelemetry Contribfest

OpenTelemetry のメンテナーと一緒に OpenTelemetry Contribfest に参加して、プロジェクトをより良いものにしましょう。さまざまなコントリビューションの機会から選ぶことができ、各プロジェクト領域のメンテナーが最初の一歩をサポートします。 Contribfest は11月10日（火）11:30 - 12:50 に開催されます。

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

⚡ Project Lightning Talk: Fluent Bit: The Evolution of High-Performance Telemetry Pipelines
Eduardo Silva（Palo Alto Networks）
11月9日（月）• 10:41 - 10:46
Your Agent Needs a Platform: Cloud Native Infrastructure for Multi-Agent AI Systems
Soham Ghadge（GenbaNEXT）
11月10日（火）• 11:30 - 12:00
Next Generation DevOps: Reshaping the Cloud Native DevOps Infinity Loop with AI
Rey Lejano（Red Hat）
11月10日（火）• 11:30 - 12:00
Demo Theater: All the Ways to Add OpenTelemetry Without Touching Your Code
Michele Mancioppi（Dash0）
11月10日（火）• 12:30 - 12:50
Demo Theater: Agent Observability: Evaluating and Guardrailing Responses in Real Time
Greg Leffler（Splunk）
11月10日（火）• 12:55 - 13:15
Tracing at Scale: Running a 16 Billion Spans/Hour Pipeline at Nubank
Felipe Araujo & Kaynan Coelho（Nubank）
11月10日（火）• 14:50 - 15:20
From Bytes to Traces: A Deep Dive into OpenTelemetry eBPF Instrumentation Internals
Rafael Roquetto（Isovalent @ Cisco）、Mike Dame（Odigos）
11月10日（火）• 14:50 - 15:20
The Prompt Layer: What Platform Engineering Has to Own Next
Atulpriya Sharma（Improving）
11月10日（火）• 14:50 - 15:20
Just Keep Swimming: Benchmarking OSS Agent Memory on Kubernetes with OpenTelemetry
Henrik Rexed（Dynatrace）
11月10日（火）• 15:40 - 16:10
The SRE Is Not Dead: What AI Taught Us about Missing Context in Kubernetes Incident Response
Muhammed Yunas Chirayath（Best Buy）、Ajmal Ali kannu（Independent）
11月10日（火）• 15:40 - 16:10
From Traceroute to OTel Traces: Modeling Network Paths with OpenTelemetry
Antonio Jimenez Martinez（Cisco ThousandEyes）
11月10日（火）• 15:40 - 16:10
Agents on the Platform: Four Perspectives on the Conversation We’re Already Having in Private
Kasper Borg Nissen（Dash0）、Juraci Paixão Kröhling（OllyGarden）、Joseph Sandoval（Adobe）、Jed Salazar（Edera）、Alexa Griffith（Red Hat）
11月10日（火）• 16:40 - 17:10
Not All Memory Is Equal: How To Properly Observe Memory Usage
Braydon Kains（Google）、Roger Coll（Grafana Labs）
11月10日（火）• 16:40 - 17:10
Two-Stage OTel Aggregation: Taming Istio Cardinality at 10k-Pod Scale
Evelyn (Chungyu) Chen（Yahoo）
11月10日（火）• 17:30 - 18:00
Verticalizing Platform Intelligence for Regulated Domains
William Rizzo（Mirantis）、Kasper Borg Nissen（Dash0）
11月11日（水）• 11:00 - 11:30
OTel Blueprints: Prescriptive Patterns for Enterprise Observability
Dan Gomez Blanco（New Relic）、Lukasz Ciukaj（Cisco Splunk）
11月11日（水）• 11:00 - 11:30
Filter, Transform, Route: Mastering OTTL in the OpenTelemetry Collector
Evan Bradley（Dynatrace）、Edmo Vamerlatti Costa（Elastic）、Jamie Danielson（honeycomb.io）、Tyler Helmuth（Grafana Labs）
11月11日（水）• 11:00 - 12:20
Sample Smarter, Not Harder (Or Not At All!)
Reese Lee（New Relic）、Juliano Costa（Datadog）
11月11日（水）• 11:50 - 12:20
Demo Theater: ClickHouse Observability: Full-fidelity observability for AI agents and SREs
Mike Shi（ClickHouse）
11月11日（水）• 12:15 - 12:35
🪧 Poster Session: Many Agents, One Platform: Production Multi-Agent Apps on K8s with CNCF Building Blocks
Daniel Oh（Red Hat）
11月11日（水）• 13:20 - 14:20
🪧 Poster Session: Your GPU Dashboard Is Lying: Per-Tenant Blind Spots in MIG, MPS, and HAMi
Saiyam Pathak（vCluster）、Saloni Narang（Kubesimplify）
11月11日（水）• 13:20 - 14:20
GPU Observability with eBPF: From Kernel Hooks to Kubernetes Metrics
Qasim Sarfraz & Michael Friese（Microsoft）
11月11日（水）• 15:10 - 15:40
Battle-tested Autoscaling Paradigms with KEDA
Jan Wozniak（Kedify）、Christian Melendez（AWS）
11月11日（水）• 16:10 - 16:40
Zero-Trust Telemetry: Stopping AI-Powered Poisoning Attacks on Observability Pipelines
Chad M. Crowell（Akamai）、Diana Todea（VictoriaMetrics）
11月11日（水）• 16:10 - 16:40
OpenTelemetry in Your Pocket
Jason Plumb（Splunk）
11月11日（水）• 16:10 - 16:40
Exploring Telemetry Quality
Jacob Aronoff（Tero）
11月11日（水）• 16:10 - 16:40
Demo Theater: Day 2 for Stateful Kubernetes: Data Services You Can See
Brock Mowry & Tapas Mahanata（Tintri）
11月11日（水）• 16:25 - 16:45
Composing Inference on Kubernetes: Gateway, Schedule, Serve, Observe
Karena Angell（Red Hat）、Alex Chircop（Google）
11月11日（水）• 17:00 - 17:30
Beyond Dashboards: A Semantic Layer for AI-Driven Observability in Kubernetes
Pronnoy Goswami（NVIDIA）
11月12日（木）• 11:00 - 11:30
Demo Theater: HTTP 200, Tool Failed: Taming MCP Agent Traffic with NGINX
Ciara Stacke & Micheal Kingston（F5）
11月12日（木）• 11:25 - 11:45
Hope Is Not a Rollout Strategy: Balancing (AI) Quality, Cost, and Risk Through Experimentation
Todd Baert（Dynatrace）
11月12日（木）• 11:50 - 12:20
Seeing Inside LLM Inference: Observability and Cost Visibility for llm-d on Kubernetes
Nili Guy（IBM）、Guangya Liu（JPMorgan Chase）
11月12日（木）• 11:55 - 12:10
The Race to Standardize AI Observability
Liudmila Molkova（Google）、Trask Stalnaker（Microsoft）
11月12日（木）• 13:50 - 14:20
From Black-Box to Auditable AI-Grid: A Deterministic Governance Layer with Hybrid Cloud
Fatih E. Nar（Red Hat）、Andrew Hendrickson（FCC）
11月12日（木）• 14:40 - 15:10
Fast and Furious: OTel Drift
Laura Luttmer（Bindplane）
11月12日（木）• 15:30 - 16:00
OpenFeature as a Control Plane for OpenTelemetry
Simon Schrottner（Flagsmith）、Juliano Costa（Datadog）
11月12日（木）• 15:30 - 16:00

メンテナーサミット

併設イベントの1日前、カンファレンスの2日前にあたる11月8日に開催されるメンテナーサミットは、プロジェクトの担い手たちが直接顔を合わせる貴重な機会です。 OpenTelemetry 組織のメンバーが集まり、コラボレーション、学習、アイデアの共有、問題解決、そしてプロジェクトの充実を図ります。詳細はフルスケジュールをご覧ください。今すぐサインアップしましょう！

より高速で小さなチェックポイント: File Log レシーバーが protobuf を採用

Thu, 29 Oct 2026 13:08:22 +0000

File Log レシーバーを storage エクステンションと一緒に使っている場合、Collector はログファイルをポーリングするたびにチェックポイントを書き込みます。このチェックポイントは、レシーバーがどこまで読み取ったかを記憶するためのもので、再起動してもログの欠損や重複が発生しないようにします。長年にわたり、このチェックポイントのフォーマットは JSON でした。

OpenTelemetry Collector Contrib v0.164.0 以降、チェックポイントは常に protobuf で書き込まれます。ベンチマークでは、チェックポイントの保存は約5倍高速になり、読み込みは5倍超高速になり、チェックポイント自体のサイズは約35%小さくなりました。

なぜチェックポイントの最適化に価値があったのか

File Log レシーバーは、追跡するファイルごとに小さなレコードを保持しています。ファイルの先頭バイトから構築されたフィンガープリント、読み取りオフセット、レコード番号、ファイル属性、そして部分的な行をフラッシュするための状態です。ストレージが設定されている場合、このリスト全体がポーリングサイクルの終わりにシリアライズされてストレージエクステンションに書き込まれ、レシーバーの停止時にもう一度書き込まれます。読み戻されるのはレシーバーの起動時の一度だけです。

デフォルトの poll_interval が 200 ms であるため、Collector が稼働している間は毎秒5回の書き込みが発生します。数百のコンテナログファイルがある Kubernetes ノードでは、書き込みのたびに数百のレコードがシリアライズされます。

2025年10月、あるユーザーが Issue を報告しました。 file_storage を使って Kubernetes ログを収集している Collector が、同様の処理を行う Fluent Bit と比べて著しく多くのリソースを消費していたのです。プロファイリングの結果、チェックポイントの JSON エンコードに驚くほどの CPU が使われていることが判明しました。

JSON と protobuf の比較

JSON は人がデータを読む必要がある場合に優れています。チェックポイントを読むのはレシーバーだけなので、JSON は不要なコストを払っていました。

最大のコストはファイルのフィンガープリント、つまり各ファイルの先頭 1,000 バイトです。 JSON は生のバイト列を保持できないため、テキストに変換されていました。これによりサイズが約3分の1大きくなり、保存と読み込みのたびに変換をやり直す必要がありました。さらに、レコードごとに同じフィールド名が繰り返され、数値やタイムスタンプもテキストとして書き出されていました。

OpenTelemetry Go Logs API と SDK がリリース候補ステータスに到達

Tue, 20 Oct 2026 12:47:24 +0000

OpenTelemetry Go v1.47.0-rc.1 がリリースされました。このリリースでは、Logs API と SDK がリリース候補（RC）に昇格しました。これは安定版 v1 の互換性保証を提供する前の最終段階です。設計は準備が整ったと考えており、互換性保証が発効する前に、コミュニティの皆さんに実際のアプリケーションやインテグレーションでテストしていただく必要があります。

リリース候補に含まれるもの

RC は以下の2つのモジュールを対象としています。

go.opentelemetry.io/otel/log
go.opentelemetry.io/otel/sdk/log

これらのモジュールは、安定性がベータ段階の v0.22.0からv1.47.0-rc.1 に移行します。このバージョンにより、バージョン番号をそろえている他の安定版 OpenTelemetry Go モジュールと整合します。ログエクスポーターおよび logtest モジュールは引き続き実験的であり、この RC の安定性スコープには含まれません。

このリリースでは、ルートパッケージ go.opentelemetry.io/otel に Logger、GetLoggerProvider、SetLoggerProvider が追加されました。 go.opentelemetry.io/otel/log/global の同等の API は非推奨になりました。これにより、グローバルなロガーアクセスが、トレーサーやメーターで既に使用されているパターンと統一されます。

完全なリリースノートについては、リリース候補のリリースを参照してください。

リリース候補への道のり

現在の設計に向けた作業は、2023年後半の Logs API とブリッジのプロトタイプから始まりました。このプロトタイプにはベンチマークと初期のブリッジが含まれており、API を確定する前に、その形状とコストの両方をテストできました。

最初の Logs API アルファ版は2024年2月に続き、最初の Logs SDK アルファ版は4月に登場しました。 2024年5月には、API と SDK を合わせた最初のベータリリースを公開しました。それ以来、進化する OpenTelemetry Logs 仕様に継続的に追従し、API を当初のブリッジ中心のユースケースから直接利用へと拡大し、レコード表現、処理、制限、ライフサイクル動作、パフォーマンスを改善してきました。最近の変更には、シグナル間で共通の attribute.Value と attribute.KeyValue 型の採用と、エクスポーターのバックプレッシャー下でより安全な動作を実現するための BatchProcessor の再設計が含まれています。

バージョン付きメトリクス: hostmetrics に初のリリース候補メトリクスを導入

Sat, 17 Oct 2026 13:10:34 +0000

OpenTelemetry Collector Contrib v0.160.0 では、hostmetrics レシーバーの process スクレイパーにリリース候補（RC）の process セマンティック規約メトリクスを出力する機能が追加されました。これは安定版 v1 の前の最終段階です。 System SIG は約1年かけてこの作業を進めてきました。 process メトリクスは良い状態になったと考えていますが、RC はコミュニティがそれを証明するために存在します。 process メトリクスを収集している方は、新しいバージョン付き出力を試して、何が壊れるかを教えてください。

hostmetrics レシーバーの安定化が妨げられていた理由

process スクレイパーのメトリクスは OpenTelemetry セマンティック規約で変更されました。これらの規約に合わせるということは、ユーザーがすでに依存しているメトリクス名、型、属性を変更することを意味するため、単純に定義をその場で編集してリリースすることはできませんでした。

Collector における動作変更のための通常のツールはフィーチャーゲートですが、ゲートはすでに存在するコードパスを切り替えるだけです。必要だったのは、レガシーと RC のメトリクス定義の両方がコード内に同時に存在し、メトリクスごとに選択可能で、エンドユーザーが新しいメトリクスの使用をオプトインできることでした。理想的には、これをユーザーの設定スキーマに影響を与えずに行うことです。

この要件は設定スキーマ metadata.yaml に突き当たります。このファイルは、レシーバーが出力するメトリクスと属性、およびそれらの出力方法を定義します。 hostmetrics レシーバーの各スクレイパーはこのファイルを1つ持ち、mdatagen がこのファイルから出力コードを生成します。 <metric> の2つの定義が、名前は同じだが型や属性が異なる場合、1つのファイルに共存できません。

System SIG は、バージョン付きメトリクスに関する GitHub イシューで議論されたように、この問題を解決する2つの異なるアプローチに行き着きました。

レガシーメトリクスと RC メトリクスに2つの異なる設定スキーマを使用する。
レガシーメトリクスと RC メトリクスの両方を含む1つの設定スキーマを使用する。

1つ目は、レガシーと RC のメトリクスを別々のスキーマに保持する方法です。これにより命名の競合は回避できましたが、metadata.yaml の metrics: ブロックはエンドユーザーが Collector の設定を書くために使用する metrics: ブロックを生成するものです。そのため、2つのスキーマファイルは2つのユーザー設定ブロックを意味し、すべての既存ユーザーはアップグレード時か、レガシーブロックが最終的に削除される時点のいずれかで設定を編集しなければなりません。

2つ目は、両方の定義を1つのファイルに共存させ、mdatagen を更新して名前の競合を処理する方法です。これはユーザーにコストをかけず、コンポーネントメンテナーに単一の metadata.yaml ファイルで作業できる環境を提供しますが、スクレイパーの作業を開始する前に、Collector のコアリポジトリで mdatagen 自体を変更する必要がありました。

2026年の Prometheus と OpenTelemetry の相互運用性：調査結果

Sat, 17 Oct 2026 01:32:42 +0000

私たちは OpenTelemetry と Prometheus のユーザーを対象に、メトリクスの収集、処理、保存の方法を尋ねるサーベイを実施しました。目標は、憶測ではなく実際の利用データに基づいて、エコシステムがどこまで進んだか、そして相互運用性にいまだ摩擦が残っているかを理解することでした。

主なポイント

2024年のサーベイ以降、相互運用性は測定可能な改善を遂げました。使いやすさの平均評価は3.1から3.6に上昇しました。これは回答者の2人に1人がカテゴリを丸ごと1段階上に評価した場合に相当し、両者を一緒に使うのが難しいと感じた回答者の割合は29%から10%に減少しました。
インフラストラクチャの計装では、Prometheus エクスポーターが最も利用されている方法（72%）であり、OTel レシーバーが僅差で続いています（57%）。回答者のほぼ半数は、一方からもう一方に移行するのではなく、両方を同時に使用しています。
アプリケーションの計装では、OTel SDK が最も利用されている方法で65%、Prometheus SDK が52%であり、41%の回答者は OTel スタイルのアプリケーション計装のみを使用しています。
Prometheus リラベリングルール（54%）とオープンソースの OTel Collector（53%）が最も一般的な2つの処理ステップであり、回答者の65%はパイプライン内にベンダーの変換やカスタムビルドの Collector を含まない、一方または両方の「バニラスタック」を使用しています。

人口統計

回答した186人のうち、81人が Prometheus 隣接バックエンド上のアクティブな OpenTelemetry メトリクスユーザーとしてスクリーニングを通過しました。また、エンドユーザーに焦点を当てるため、オブザーバビリティベンダーの従業員を除外しました。分析対象サンプルの特徴は以下のとおりです。

回答者全員がアクティブな OpenTelemetry ユーザーです。
回答者全員が何らかの Prometheus 系ツールを使用しています。 Prometheus そのもの（46%）、Thanos、Cortex、Grafana Mimir などのオープンソースの Prometheus 互換バックエンド（42%）、または PromQL 互換のベンダー製品（12%）です。
回答者のオブザーバビリティ成熟度は高いです。 48%は自組織が「確立されたオブザーバビリティプラクティスを持っている」（エキスパート）と回答し、41%は「オブザーバビリティプラクティスを構築中」（中級）であり、初心者と自認しているのはわずか11%でした。
組織規模は大きい方に偏っています。 42%が従業員1,000人以上、31%が100〜999人、15%が50〜99人、12%が50人未満と回答しています。

使いやすさの経時変化

OpenTelemetry と Prometheus を一緒に使うのはどの程度簡単ですか、あるいは難しいですか？

今年は、2024年の同様のサーベイと同じ質問を行い、エンドユーザーが相互運用性に進歩を感じているかを確認しました。

平均評価は0.5ポイント上昇し、3.1から3.6になりました。これは回答者の2人に1人がカテゴリを丸ごと1段階上に移動した場合に相当します。最も明確な変化はスケールの「難しい」側にあります。両者を一緒に使うのが難しいと感じた回答者の割合は、2024年の水準のおよそ3分の1にまで低下しました。また、今年は「非常に難しい」を選んだ人はいませんでした。

OTLP と Prometheus で .NET メトリクスをデュアルエクスポートする

Sat, 17 Oct 2026 01:28:55 +0000

多くのアプリケーションは、メトリクスを直接 Prometheus にエクスポートしています。 Prometheus に馴染みがない方に向けて簡単に説明すると、カウンターやヒストグラムのようなメトリクスを保存するための時系列データベースです。 Prometheus にメトリクスを保存するアプリケーションは、通常、連携の一環として広く使われている Prometheus クライアントを使用しています。

OpenTelemetry が CNCF の Graduated プロジェクトとなった今、多くの企業がオブザーバビリティアーキテクチャにメトリクス以外のシグナルを追加するために、OpenTelemetry への移行を検討しています。ログとトレースは、アプリケーションの挙動をより深く理解するための一般的な追加シグナルです。プロファイルも、さらに深い理解を得るための4番目のテレメトリーシグナルとして注目を集めています。

ここで移行のハードルが生まれます。あるシステムから別のシステムへメトリクスを移行する際に、一括切り替えのイベントなしにどうすれば移行できるでしょうか。移行のリスクを軽減するには、一定期間メトリクスを両方のシステムにエクスポートし、「移行前」と「移行後」の状態を比較・検証できるインクリメンタルなアプローチが望ましいです。これにより、メトリクスの監視やアラートの駆動において、どちらのシステムでも本番環境の可視性が失われていないことを確認できます。

.NET 用 OpenTelemetry Prometheus エクスポーターの使用

.NET 用 OpenTelemetry Prometheus エクスポーターの最新リリースでは、本番メトリクスでまさにこのアプローチを取ることができます。アプリケーションやフレームワークのコードで .NET Meter クラスを使用してメトリクスを収集し、Prometheus と、OpenTelemetry.Exporter.OpenTelemetryProtocol NuGet パッケージが提供する OTLP エクスポーターなどの別のエクスポーターの両方にエクスポートできます。

Prometheus エクスポーターは、事実上 OpenTelemetry SDK の上に構築された Prometheus クライアントライブラリであり、アプリケーション内に HTTP スクレイプエンドポイントを公開して、Prometheus サーバーが定期的にアプリケーションからメトリクスを収集できるようにします。このエクスポーターは OpenTelemetry の Prometheus 仕様（マトリクス）を実装し、OpenMetrics との互換性を確保するために、ドキュメント化されたすべてのテキストエクスポジションフォーマット（まだ実験段階の OpenMetrics 2.0 を除く）を実装しています。

flowchart LR
 subgraph APP["アプリケーション"]
 AC["アプリケーションコード"]
 SDK["OpenTelemetry SDK"]
 PE["Prometheus エクスポーター"]
 OE["OTLP エクスポーター（クライアント）"]
 EP["GET /metrics HTTP エンドポイント（サーバー）"]

 AC -->|"メトリクスを生成"| SDK
 SDK -->|"メトリクスを供給"| PE
 PE -->|"text/plain としてメトリクスを提供"| EP
 SDK -->|"メトリクスを供給"| OE
 end

 P["Prometheus（クライアント）"]
 OTB["OpenTelemetry バックエンド（サーバー）"]

 P -->|"HTTP GET /metrics（スクレイプリクエスト）"| EP
 EP -->|"メトリクスレスポンス（テキスト形式）"| P

 OE -->|"OTLP エクスポートリクエスト"| OTB
 OTB -->|"OTLP レスポンス/確認応答"| OE

.NET アプリケーションコードで Meter クラスとともに Counter<T>、Gauge<T>、Histogram<T> の計装のみを使用することで、.NET OpenTelemetry SDK と専用の Prometheus クライアントの両方を使わずにメトリクスを収集できます。

OTel-Native by Design - あらゆるオブザーバビリティスタックへのエクスポートが可能なプロダクトを作る

Sat, 17 Oct 2026 01:28:06 +0000

Dan Gomez Blanco（New Relic）の協力のもと執筆。

セルフホスト型ソフトウェアや SaaS プロダクトを開発していると、ユーザーはいずれログ、トレース、メトリクスを自身のオブザーバビリティスタックに送りたいと要望するようになります。コンプライアンスの順守やコスト管理、あるいはすべてのオブザーバビリティデータを一箇所に集約するためです。

ユーザーを組み込みのダッシュボードに囲い込んだり、エクスポート先を特定のベンダーに限定したりすることは、不必要な摩擦を生みます。かわりに、OpenTelemetry（OTel）互換のあらゆるバックエンドへのエクスポートをサポートすることが、ベンダーニュートラルかつ将来性のあるプラクティスであり、ユーザーにオブザーバビリティスタックを自由に選択できる環境を提供します。

この記事では、ユーザーが望むときにログ、トレース、メトリクスを OTel バックエンドにエクスポートできるよう、プロダクトを設計する方法を概説します。

4つのオブザーバビリティシグナル

OpenTelemetry は4つのシグナルタイプを定義しており、すべて標準の OpenTelemetry Protocol（OTLP）で伝送されます。

ログ: イベントレコード、リクエスト/アクセスログ、およびタイムスタンプとメタデータを含むアプリケーションログ。
トレース: 分散トレースとスパンにより、ユーザーはサービス間のリクエストフローを確認し、ログと関連付けることができます。
メトリクス: カウンター、ゲージ、ヒストグラム（例: リクエストレート、レイテンシー、エラーレート）。
プロファイル: アプリケーションが実行中にどこでリソースを消費しているかを示すサンプル。

プロファイルはパブリックアルファ段階です

プロファイルは2026年3月26日にパブリックアルファに入りました。シグナルとして、OpenTelemetry はプロファイルを現在の3つの主要なオブザーバビリティシグナルと並ぶものとして位置づけようとしており、コードベース全体のリソース使用パターンをキャプチャすることで、ユーザーが本番環境のインシデントをトラブルシュートする助けとなります。

このブログではログ、トレース、メトリクスにのみ焦点を当てていますが、プロファイルがどのような形になるか、そしてコミュニティがオブザーバビリティシステムでどのように活用するか、楽しみにしています。

同じエクスポートの仕組みが3つすべて（ログ、トレース、メトリクス）に適用されます。ユーザーが OTLP エンドポイントを設定し、テレメトリーをそこにプッシュできるようにします。プロダクトが生成するものに応じて、1つ、2つ、または3つすべてのシグナルをサポートできます。

OTel エクスポートをサポートする多くのプラットフォームは、少なくともトレースとログをサポートしており、メトリクスサポートを提供するプラットフォームも増えています。 3つすべてを最初から設計しておけば、後からレトロフィットする必要がなくなります。

「良い」テレメトリーシステムとは

優れたエクスポートの仕組みには、サポートするすべてのシグナルに対していくつかの明確な特性があります。

ベンダーニュートラル: ユーザーは、ベンダーごとにカスタムインテグレーションを構築することなく、任意の OTel 互換エンドポイント、つまり Collector インスタンスや OTLP を直接サポートする多くのバックエンドのいずれかを指定できます。
大がかりなカスタム開発が不要: 外部プラットフォーム（またはユーザーのツール）は、独自 API のかわりに標準の OTel SDK と OTLP プロトコルを使ってインテグレーションできます。
豊富なコンテキストの保持: エクスポートされたデータには、メタデータ、タイムスタンプ、利用可能な場合のトレース/スパンの関連付け（例: トレース ID にリンクされたログレコード）が含まれるべきであり、ユーザーはコンテキストを失うことなく自身のバックエンドでデバッグと分析ができます。
セマンティック規約のサポート: セマンティック規約への準拠は、テレメトリーデータの標準化を保証し、互換性のあるあらゆるバックエンドで容易に解釈できるようにします。また、ファーストパーティかサードパーティかを問わず、ソフトウェアシステムの動作を理解するためのエンドユーザーの認知的負荷を軽減します。

サポートするシグナルに対してこれらの原則に沿った設計であれば、最新のプラットフォームがオブザーバビリティエクスポートについて考えるやり方と一致しています。

OpenTelemetry のエンティティイベントで何ができるのか

Mon, 12 Oct 2026 10:33:36 +0000

メトリクス、ログ、トレースはシステムがどのように 振る舞うか を教えてくれます。しかし、実際に何が 存在する かについてはあまり語りません。どのホスト、インターフェイス、スイッチ、サービス、ボリュームが今そこにあるのか、そして決定的に重要なこととして、その全体像がこの1時間、1日、あるいは四半期でどう変わったのか。この動的なインベントリは、オープンなオブザーバビリティスタックにおいて盲点であり続けてきました。

OpenTelemetry の エンティティイベント は、Entities SIG の成果であり、エンティティデータモデルに記述されています。これがその盲点を埋め始める要素です。エンティティイベントは ストリーム です。興味深い問いは 「届いたあとに何をするのか」 です。この記事では、オープンソースのコンシューマーを実例として、その問いへの一つの答えを紹介します。

Note: エンティティデータモデルとその規約はまだ 開発中 （安定版ではない）であり、進化を続けています。以下の属性名は例示として扱い、最新の仕様と照合してください。ここでの内容はエンティティイベントを活用する一般的な方法論であり、どのようなコンシューマーにも当てはまります。

エンティティイベントの60秒入門

OpenTelemetry は エンティティイベント を、エンティティセマンティック規約でアノテーションされた OTLP ログレコード として運びます。各イベントはエンティティの型、識別属性、説明属性、およびライフサイクルを示すイベントタイプを持ちます。コンシューマーは otel.entity.event.type の存在だけでレコードを分類できます。

# エンティティイベントのログレコード（例示）
LogRecord
 Timestamp: 2026-05-26T08:00:00Z # プロデューサー側のタイムスタンプ
 attributes:
 otel.entity.event.type: entity_state # 観測された状態、または entity_delete
 otel.entity.type: host
 otel.entity.id: { host.name: web-server-1 } # 識別属性（マップ）
 otel.entity.attributes: { os.type: linux, host.arch: amd64 } # 説明属性（マップ）

プロデューサーがこれらを送信します。ホストエージェント、ネットワークエージェント、OTLP を話すものなら何でも構いません。コンシューマーの仕事は、このような一連の観測を 問い合わせ可能な ものに変えることです。その形はパイプラインです。

OBI によるゼロコードのトレースとログの相関

Mon, 12 Oct 2026 09:34:48 +0000

ページャーが鳴ります。トレースを見ると、あるサービスでリクエストが失敗していることがわかります。答えはログの中にあるはずですが、あのリクエストに属するログ行はどれでしょうか。サービスがトレースコンテキスト付きの構造化ログを採用していなければ、正直なところ、タイムスタンプで grep して祈るしかありません。

OpenTelemetry eBPF Instrumentation（OBI）は、サービスがすでに出力しているログに、欠けていたトレースコンテキストを追加できるようになりました。アプリケーション側の変更は不要です。 SDK も、ロギングライブラリの設定変更も、アプリケーションの再ビルドや再デプロイも必要ありません。

最初に制約を明確にしておきます。対象となるのは stdout または stderr に書き込まれたログ、つまりコンテナランタイムがキャプチャするストリームです。ログ行にアノテーションが付与されるのは、書き込み時点で OBI が処理中のリクエストに対してアクティブなトレースコンテキストを持っている場合です。ロールアウトするのは、OBI の設定変更と、ログパイプラインでの1行のフィルター追加です。

内部的には、OBI は eBPF を通じて、各スレッドがログ行を書き込む時点でどのリクエストを処理しているかをすでに把握しています。それがこの仕組みのすべてです。コンテナのロギングパイプラインがログ行を受け取る前に、相関フィールドが追加されます。この記事の残りでは、実際に何が変わるのか、この機能が環境に何を要求するのか、そして有効化する方法を説明します。

インシデント時に何が変わるか

アプリケーションが次のように書き込みます。

{ "level": "INFO", "message": "payment authorized", "amount": 42 }

コンテナログは次のようになります。

{
 "level": "INFO",
 "message": "payment authorized",
 "amount": 42,
 "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
 "span_id": "00f067aa0ba902b7"
}

ID は OBI がそのリクエストのスパンで報告するものと同一なので、相関は双方向に機能します。失敗したトレースから trace_id をコピーしてログ検索に貼り付ければ、そのリクエストのログ行だけが得られます。あるいは、不審なログ行から trace_id をコピーしてトレースバックエンドに入力すれば、そのログが属するトレースに到達できます。

JSON ログ、NDJSON、プレーンテキストで機能します。自由形式のログ行には key=value アノテーションが付きます。

payment authorized trace_id=4bf92f3577b34da6a3ce929d0e0e4736 span_id=00f067aa0ba902b7

ロガーが設定済みのフィールドのいずれかをすでに出力している場合、OBI はそれを保持し、欠けているフィールドのみを補完します。

小さなデモでのエンドツーエンドの例を示します。計装されていない Go の frontend が計装されていない Go の backend を呼び出し、それぞれがリクエストごとに1行の JSON をログ出力します。これに OBI と Jaeger を加えた合計4つのコンテナです。アプリケーションコードには OpenTelemetry SDK は一切ありません。

OpenTelemetry 計装エコシステムの探求

Mon, 12 Oct 2026 08:49:49 +0000

OpenTelemetry には多くの構成要素があります。 API、SDK、プロトコル、セマンティック規約、計装、そして Collector のようなツールです。 API とプロトコルはテレメトリーの作成と交換の方法を定義し、計装はアプリケーション内部で実際に何が起きているかを観測してテレメトリーに変換します。セマンティック規約は、計装を書く人々に対して、観測対象を記述するための共通の方法を提供します。

このアプローチの優れた点は、まったく別々の作者が異なるライブラリを異なる言語で計装しても、同じ規約に従ったテレメトリーを生成できることです。 HTTP リクエストは、どのライブラリやどの言語が生成したかに関係なく、HTTP リクエストとして見えます。ユーザーはその共通の理解に基づいて、クエリ、ダッシュボード、その他のツールを構築できます。規約に合意しさえすれば、すべてが整合するはずです。

しかし、まだそうはなっていません。

規約は進化し、ドメインの安定化には何年もかかります。 HTTP は2019年6月に仕様に入りましたが、コア規約が安定版に達したのは2023年11月でした。データベースはほぼ同時期に始まり、安定版に達したのは2025年5月でした。

HTTP とデータベースのセマンティック規約のタイムライン。仕様への導入からコア規約の安定化まで。

OTel デモを壊しました

Mon, 12 Oct 2026 08:43:29 +0000

長い間デモを運用してきた方は、最近いくつかの構造的な変更に気づいたかもしれませんし、期待どおりに動作しなくなったことに怒りを覚えたかもしれません。その気持ちはよくわかりますし、十分に理解しています。残念ながら、既存のフローを壊さずに変更を行う方法はありませんでした。

以前のものは一部なくなりました。新しいサービスが追加されました。属性名が変更されました。カスタムメトリクスのダッシュボードを持っていた方は、すべてが壊れているはずです。

これは偶然ではありません。

OTel デモは常にリビングリファレンス実装であり、コミュニティが OTel で何ができるかを示す場所でした。しばらくすると、私たちが目指す方向の妨げになるものが蓄積されていきました。 3.0 は、それを一掃する取り組みです。意図的に、短期的な痛みを伴うことを承知の上で、明確な目的を持って行いました。

以下が主な変更点です。

何を壊したか（そしてなぜ）

アップグレードするとすぐに影響を受ける変更が2つあります。 1つはダッシュボードを壊し、もう1つはローカルやフォークでのデモの実行方法を壊します。

誰も望まなかったが全員が必要としていたリネーム

この変更はすべてのサービスに影響し、既存のダッシュボードやクエリを壊すため、独立したセクションにする価値があります。すべてのカスタムテレメトリー属性が app.* から demo.* にリネームされました。

すべてです。 app.product.id は demo.product.id になりました。 app.order.id は demo.order.id に。 app.payment.amount は demo.payment.amount に。すべてのサービスにわたって同様です。しかし、なぜでしょうか。

2022年に OTel デモを始めた頃、app.* は予約済みの属性ではなく、その名前空間ですべてのカスタム属性とメトリクスを構築していました。時が経ち、2023年に app.* がクライアントサイドアプリケーション（ウェブアプリやモバイルアプリなど）に関連する属性を表すためにプロジェクトに追加されました。

しかし、それが2023年に導入されたのに、なぜデモはまだ使い続けていたのでしょうか。

主な理由は2つあると考えられます。

それを支援するツールが必要でした。
タスクを手伝ってくれるコントリビューターがもっと必要でした。

1つ目は、Martin Thwaites が OpenTelemetry Weaver をデモに導入したことで解決されました。 2つ目は、Bloomberg メンターシップを通じてデモのコントリビューターになった Florian Bourgey の協力で解決されました。これは、OTel デモが OTel エコシステム全体とどれほど密接に結びついているかを示しています。

環境変数によるコンテキスト伝搬の安定化にご協力ください

Mon, 12 Oct 2026 08:43:13 +0000

トレースは常にネットワーク境界を越えるわけではありません。ワークフローランナーがシェルを起動し、シェルがビルドツールを立ち上げ、ビルドツールがテストプロセスを開始します。バッチ処理やデータ処理システムでも、同様の子プロセスのチェーンが作られます。これらの境界を越えてトレース情報を受け渡す共通の方法がなければ、各プロセスのスパンは別々のトレースに分かれてしまいます。

コンテキスト伝搬に馴染みがない方に説明すると、これはあるサービスやプロセスから次のサービスやプロセスへ情報を運ぶ仕組みです。トレーシングにおいては、新しいスパンが同じトレースに参加できるようにするトレース ID やスパン ID が含まれます。また、バゲージも運ぶことができます。バゲージとは、下流の処理に渡されるアプリケーション定義のキーバリューペアです。

OpenTelemetry の仕様では、環境変数をコンテキスト伝搬のキャリアとして使用するためのリリース候補が公開されました。プロトコルヘッダーやメッセージメタデータが利用できない場合に、プロパゲーターが環境変数を使ってトレースコンテキストやバゲージなどのデータをプロセス間で運ぶ方法を標準化するものです。

この仕様を Stable にする前に、言語実装者、ツール作者、プラットフォームエンジニア、そして実際の CI/CD、バッチ処理、コマンドラインのワークロードを運用しているユーザーからのフィードバックを求めています。

環境変数キャリアとは

キャリアとは、サービスやプロセス間で伝搬データを受け渡すために使われる媒体です。プロパゲーターは伝搬フィールドをキャリアに書き込み、受信側でそれを読み取ります。 HTTP ヘッダーはよく知られたキャリアです。あるプロセスが別のプロセスを起動する場合、子プロセスの環境が同じ役割を果たすことができます。伝搬フィールドは子プロセスの起動前に書き込まれ、子プロセスの初期化時に読み取られます。

リリース候補では、この仕組みがプラットフォーム間で一貫して動作するためのルールを定義しています。仕様では、文字列のキーバリューキャリアと共に使われるプロパゲーターの型を TextMapPropagator と呼んでいます。

たとえば、W3C Trace Context と W3C Baggage プロパゲーターを使用する場合、伝搬フィールドは以下のような環境変数で表されます。

TRACEPARENT=00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
TRACESTATE=vendorname=opaquevalue
BAGGAGE=build.id=42,repository.name=example

OpenTelemetry Propagators API では、伝搬フィールドをキャリアに書き込むことを注入、読み取ることを抽出と呼びます。

プロセス内部では、OpenTelemetry は伝搬データを Context に保持します。トレーシングの場合、そのデータには SpanContext が含まれ、Baggage も含まれることがあります。注入時に、プロパゲーターは現在の Context からデータを読み取り、キャリアに書き込みます。抽出時には、キャリアを読み取り、そのデータを含む新しい Context を返します。

環境変数キャリアはこれらの値を解釈しません。プレーンな文字列として扱います。フィールド名の選択、値の検証と解析は、設定されたプロパゲーターが引き続き担当します。これにより、キャリアは W3C フォーマットだけでなく、B3 のようなフォーマットでも使用できます。

環境変数名は HTTP ヘッダー名よりも制約が多いため、仕様では正規化アルゴリズムを定義しています。 ASCII 文字を大文字に変換し、サポートされない文字をアンダースコアに置き換え、名前が数字で始まらないようにします。たとえば以下のようになります。

OpenTelemetry におけるメトリクスのカーディナリティ制限：実践ガイド

Mon, 12 Oct 2026 08:43:02 +0000

OpenTelemetry のメトリクスは、本番環境で安全に使えるように設計されています。その安全性の一部を担っているのが、メトリクス SDK のカーディナリティ制限です。この制限は、メトリクスが一意な属性の組み合わせを過剰に受け取ったときに、プロセスのメモリが際限なく増加するのを防ぎます。

この保護は有用ですが、多くのユーザーが予想しない結果をもたらします。メトリクスストリームがオーバーフローすると、合計値は正しいままですが、属性でフィルタリングまたはグループ化するクエリは過少にカウントされる可能性があります。これは、オーバーフローが始まる前には正しく見えていたダッシュボード、サービスレベル目標（SLO）、アラートに影響する可能性があります。

メトリクスのコンセプトドキュメントには、SDK の動作を詳しく説明するカーディナリティ制限セクションが追加されました。この投稿は、そのドキュメントの運用面を補完するものです。制限が実際に何を意味するのか、オーバーフローした測定値のすべての属性がなぜ影響を受けるのか、適切な制限をどう選ぶか、すでに制限に達しているかどうかをどう確認するか、そして本番環境でどう監視するかを説明します。

基本モデル

メトリクスの測定値を記録するとき、http.route=/checkout、http.request.method=GET、success=false などの属性を付与できます。 SDK は属性値の完全なセットごとに測定値を集約します。一意な属性の組み合わせごとに、SDK がメモリ上で追跡する個別のデータポイントになります。

たとえば、このリクエストカウンターには4つの一意な組み合わせがあります。

`http.route`	`success`	カウント
`/home`	`true`	130
`/home`	`false`	2
`/cart`	`true`	50
`/cart`	`false`	1

このメトリクスストリームのカーディナリティは4です。 tenant_id のような高カーディナリティの属性を追加すると、組み合わせの数は非常に急速に増加します。これが SDK が制限を強制する理由です。デフォルトの集約カーディナリティ制限は、メトリクスストリームあたり2000の組み合わせです。

制限に達すると、追加の組み合わせは破棄されません。それらの値は otel.metric.overflow=true でマークされた単一のオーバーフローデータポイントに集約されます。重要なのは、元の測定値の属性がオーバーフローデータポイントから削除されるという点です。

したがって、次の測定値がオーバーフローした場合：

{http.route=/checkout, success=false} 1

エクスポートされる値は次の一部となります：

{otel.metric.overflow=true} 1

合計カウントは引き続き正しいです。リクエスト総数のクエリでは値を確認できます。しかし、success=false のクエリではその値を確認できません。オーバーフローデータポイントは success=false を持たないためです。

ここで覚えておくべきことがあります。オーバーフローは、高カーディナリティを引き起こした属性だけでなく、属性の組み合わせ全体に影響します。真偽値の success のような低カーディナリティの属性であっても、その測定値がオーバーフローに集約されると、フィルタリングやグループ化に対して信頼できなくなります。

本番環境への影響

カーディナリティ制限は、プロセスのメモリ保護メカニズムです。すべてのメトリクスの内訳がクエリ可能であることを一般的に保証するものではなく、バックエンドのカーディナリティ制限でもありません。

OpenTelemetry Java エージェント 3.0 がまもなく登場 — 今すぐプレビューしましょう

Sun, 11 Oct 2026 01:11:24 +0000

OpenTelemetry Java エージェントの 2.32.0 リリース が公開されました。これは 3.0 のリリース候補であり、2026年10月 のリリースを目標としています。 3.0 までに一部の動作が変更される可能性はありますが、デフォルトになる前に今すぐ新しい動作をプレビューできます。

3.0 はテレメトリー、設定、計装のデフォルトを変更します。データベースとコードの規約は安定版のデフォルトになり、メッセージングはまだ実験的な新しい規約を採用し、一部のキャプチャ設定や計装のデフォルトも変更されます。確認すべきポイントでは各領域について説明しています。

ご自身のダッシュボード、アラート、ダウンストリームパイプラインに対して試し、3.0 が確定する前に問題があればお知らせください。

プレビューを試す

以下の例では、環境変数と宣言的設定を示しています。 Java エージェントでの宣言的設定のサポートは実験的です。試す場合は、設定コンバーターと Ecosystem Explorer の設定ビルダーを使って始められます。 YAML ファイルは -Dotel.config.file=/path/to/otel-config.yaml で渡してください。

環境変数を最初のタブに、宣言的設定を2番目のタブに表示しています。 YAML スニペットは、既存の設定ファイルにマージするためのフラグメントです。リソース、エクスポーター、その他の設定はそのまま維持してください。

ステップ 1: 古いテレメトリーと新しいテレメトリーを比較する

テストデプロイメントで開始し、プレビュー設定を有効にする前にベースラインのテレメトリーをキャプチャしてください。次に、アプリケーションに関連するドメインを選択します。アンブレラプレビューフラグをオフにした状態で、/dup を追加すると、古い属性と新しい属性、およびデュアルエミッションがサポートされているメトリクスを同時に出力できます。

OTEL_INSTRUMENTATION_COMMON_V3_PREVIEW=false
OTEL_SEMCONV_STABILITY_OPT_IN=database/dup,code/dup
OTEL_SEMCONV_STABILITY_PREVIEW=messaging/dup

instrumentation/development:
 general:
 stability_opt_in_list: 'database/dup,code/dup'
 java:
 common:
 v3_preview: false
 semconv_stability:
 preview: [messaging/dup]

たとえば、public スキーマを使用するよう設定された、データベース orders への PostgreSQL JDBC 接続を考えてみましょう。デュアルエミッションを使用すると、スパンに両方のネーミングスキームを持たせることができます。