ブログ on OpenTelemetry

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 をラップしないでください — 助けるつもりが逆効果になっているかもしれません

Wed, 14 Oct 2026 14:33:38 +0000

OpenTelemetry を導入する多くのチームで、あるパターンを目にしてきました。毎回、善意から始まります。あるエンジニアがチームの作業を楽にしたいと考え、OTel API の上に薄い抽象化レイヤーを構築します。 IMetric インターフェイス、TelemetryHelper クラス、MetricsWrapper モジュールなどを作り、チームの標準として展開します。「これを使えばいい」と彼らは言います。「もっとシンプルだから」と。

意図は本物です。しかし、結果はたいていよくありません。

ここでは .NET と Rust のメトリクスを具体例として使いますが、アンチパターンはすべての OpenTelemetry 言語 SDK とシグナルタイプに共通して当てはまります。

明確にしておくと、この記事は OTel API、つまりアプリケーションやライブラリのコードがログ、メトリクス、トレースを生成するために呼び出す計装インターフェイスのラップについて述べています。 SDK を設定する共有ヘルパー、たとえばエクスポーターやサンプリングポリシー、リソース属性などのセットアップを組織が提供するのは、まったく合理的なことです。それはインフラストラクチャのセットアップであり、API ラッパーではなく、開発者がコードを計装する方法を妨げるものではありません。

ラッパーの典型的な姿

ラッパーは通常、小さく合理的なところから始まります。 C# の場合:

public interface IMetric
{
 void RecordHistogram(long val, List<KeyValuePair<string, string>> attributes);
}

Rust の場合:

fn record_histogram(
 value: f64,
 attributes: Vec<(String, String)>,
) { /* ... */ }

これがなぜ問題なのかを見ていきましょう。

アンチパターン #1: アロケーションを強制するシグネチャ

List<KeyValuePair<string, string>> や Vec<(String, String)> — ラッパーが呼び出し元に構築を強制するコレクション型であれば、どれも同じ問題を抱えています。すべてヒープアロケーションが発生します。

OTel .NET の Histogram<T>.Record() には、設計上アロケーションが不要な、1個、2個、3個の属性に対応する専用オーバーロードがあります:

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 09:27:26 +0000

見逃していたかもしれない方のためにお伝えします。 OpenTelemetry（OTel）が正式に CNCF graduated ステータスを取得しました！いまや Kubernetes や Prometheus などの素晴らしいオープンソースプロジェクトと並ぶ存在です。長い道のりでしたし、私たちもとても興奮しています… ですが、次はどうなるのでしょうか？これからの方向性を理解するには、これまでの歩みを振り返ることが重要です。

歴史

それほど遠くない過去、テレメトリーシグナルは標準化されていませんでした。つまり、テレメトリーのフォーマットはツールごとに異なり、各テレメトリーベンダーが独自の計装ライブラリを作成・管理していました。ベンダーロックインは大きな問題でした。ベンダーを切り替えたい場合、既存のベンダーのライブラリをコードから取り除き、新しいベンダーのライブラリに置き換える必要がありました。その結果、ベンダーの切り替えは容易な作業ではありませんでした。

さらに、3つのコアテレメトリーシグナル（トレース、ログ、メトリクス）はそれぞれ独立して扱われていたため、相互に関連付ける簡単な方法がありませんでした。このため、オブザーバビリティの全体像は不完全でした。

標準化に向けた過去の試みとして、CNCF の OpenTracing と Google の OpenCensus があり、これらが後の OpenTelemetry の基盤となりました。

単一の標準を目指し、2019年5月に OpenCensus と OpenTracing が統合されて OpenTelemetry が誕生しました。 OpenTelemetry は両者の長所を取り入れ、さらにその先へと進み、トレース、メトリクス、ログの仕様、標準化された API セット、それらの API の言語固有の実装、そして Collector を提供しています。

OpenCensus と OpenTracing はいずれも正式にアーカイブされました。 OpenTracing は2022年1月にアーカイブされ、OpenCensus は2023年7月にアーカイブされました。

すべての主要なオブザーバビリティベンダーの支援と、活発な開発者・エンドユーザーコミュニティのもと、OpenTelemetry はテレメトリーのオープン標準となりました。

成長

OpenTelemetry は CNCF で2番目に活発なプロジェクトであり、Kubernetes に次ぐ規模です。 CNCF によると、OpenTelemetry は「2,800社超の企業からの12,000件超のコントリビューションと、さまざまな言語固有の Special Interest Group（SIG）にまたがる数百人のメンテナー」を擁しています。

設立以来、トレース、ログ、メトリクスは一般提供（GA）に達しました。プロファイリングが新しい OTel シグナルとして追加されました。 OpenTelemetry Demo は拡張されました。 OTel Collector も拡張され、新しいコンポーネントが定期的に追加されています。 OTel エコシステムをより使いやすくするための新しいコンポーネントも追加されてきました。 OpAMP、OTel Operator、OTel Weaver、OTel Arrow などです。

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 接続を考えてみましょう。デュアルエミッションを使用すると、スパンに両方のネーミングスキームを持たせることができます。

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

Thu, 01 Oct 2026 02:53:40 +0000

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

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

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

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

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

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

v1の主な機能

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

はじめに

このプロジェクトは、標準のGoツールチェーンをラップするotelcというコマンドラインツールを提供します。ビルドの変更は1行だけで、以前 go build を実行していた場所で otelc go build を実行します。 go の後に続くすべての引数はツールチェーンに転送されるため、ビルドの残りの部分は変わりません。同じ置き換えはコンテナビルドでも機能します。デフォルトでは、otelc はモジュール内のサポート対象ライブラリを検出し、設定やコード変更なしで自動的に計装します。

otelc のインストール、アプリケーションのビルド、生成されるテレメトリーの確認については、入門ガイドに従ってください。設定、サポートされるライブラリ、トラブルシューティングなどについては、コンパイル時の計装のドキュメントを参照してください。

どのような場合に使うべきか

Goサービスを開発または運用している場合、OpenTelemetryのテレメトリーを取得するための補完的な方法が3つあり、コンパイル時の計装は創設時の投稿で約束された3番目の選択肢です。

コンパイル時の計装（このプロジェクト）: アプリケーションを再ビルドでき、コード変更やランタイムオーバーヘッドを加えずに、依存関係と標準ライブラリをカバーしたい場合に最適です。
eBPF計装（OpenTelemetry eBPF Instrumentation、またはOBI）: バイナリを再ビルドできない場合や、プロセス外部からゼロコードで複数言語を計装したい場合に最適です。
OpenTelemetry Go API による手動計装: カスタムスパンやドメイン固有のテレメトリーに最適で、他の2つの方法と組み合わせられます。

v1はGoエコシステム全体を網羅するのではなく、対象を絞った計装セットを提供しており、カバレッジはリリースごとに拡大します。依存するライブラリがまだカバーされていない場合は、そのためのルールを追加するか、コンパイル時の計装と手動スパンを組み合わせることができます。上記の3つの方法は異なる方法で重複する問題を解決するため、OBIとGo SIGとともに、それらをより深く比較するフォローアップ投稿に取り組んでいます。

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

Sun, 20 Sep 2026 01:09:30 +0000

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 で検索してください。

小さな環境変数の旅路

Thu, 10 Sep 2026 12:25:50 +0000

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

お急ぎですか？

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

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

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

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

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

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 セキュリティプラクティスの適用

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

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