OpenTelemetry対応製品の設計：任意の可観測性基盤へ出力する方式
TL;DR: OpenTelemetryの公式ブログは、自社製品のログ、トレース、メトリクスをOTLP経由で任意のOTel対応バックエンドへ出力できるようにする設計を解説した。Kuma、Keycloak、Cloudflare Workers、Herokuの4つの事例が紹介されている。
OpenTelemetryは2026-10-08付の記事「OTel-Native by Design」で、セルフホスト型ソフトウェアやクラウドプラットフォームがユーザーに対し、OpenTelemetry Protocol（OTLP）を用いてログ、トレース、メトリクスをOTel対応のバックエンドへ出力できるようにする方法を説明した。
対象シグナルと出力方式
OpenTelemetryは、logs、traces、metrics、profilesの「four」種類のシグナルタイプを定義しており、いずれも標準のOTLPで転送される。記事は、ログ、トレース、メトリクスの3つを対象とする出力モデルを扱っている。
記事は、APIをポーリングする方式とOTLPによるプッシュ方式を比較している。ユーザーが独自のポーリング方式を構築すると、規模に対応できず、APIスキーマの変更に応じて多くの保守作業が必要になる可能性があるとされる。
各製品の出力事例
記事は、4つの統合事例を取り上げている。
- Kuma: MeshAccessLog、MeshTrace、MeshMetricのポリシーにより、ログ、トレース、メトリクスをOTelバックエンドへ出力するよう事前構成されている。
- Keycloak:
tracing-enabled=trueによりトレースを有効化でき、OTel統合を通じてメトリクスを公開する。ログ機能は現在プレビュー段階で、デフォルトでは無効になっている。 - Cloudflare Workers: Observability Destinations機能を通じて出力を行い、トレースとログを設定されたOTLPエンドポイントへ自動的にプッシュする。メトリクスの出力には現時点で対応していない。
- Heroku: Telemetry Drainsで、エンドポイント、転送プロトコル、ヘッダーを指定し、出力するシグナルを選択できる。プラットフォームは、OTel SDKを通じたユーザーアプリケーションのデータと、Routerなどのファーストパーティサービスのデータを収集する。
エンドポイント設定とCollector構成
記事では、KumaとKeycloakの設定例としてOTLPエンドポイントのポート4317が用いられており、例としてotel-collector:4317とmy-otel-endpoint:4317が示されている。
大規模な顧客や複雑な可観測性環境を管理する利用者は、テレメトリシグナルを異なるプラットフォームへ送信することを望む可能性があるとされる。記事では、テナントごとにCollectorを配置する構成と、Collectorを共有する構成が図示されている。
筆者の見立て
- OTel対応の任意のバックエンドへの出力をサポートすることは、ベンダーニュートラルで将来性のある実践であると論じている。
- 3つのシグナルすべてを最初から設計に含めると、後から作り直す必要がなくなると解釈している。
- 独自のポーリングモデルは、新規設計のデフォルトにすべきではないと論じている。
- 多くの現代的な開発者向けプラットフォームは、独自のポーリングAPIではなくOTLPプッシュを選ぶべきだと論じている。
- ユーザーに出力するシグナルを細かく選択させる仕組みは、実用的な設計パターンであると論じている。
- シグナルごとのルーティングを公開することは、高度なユーザーにとって大きな付加価値になると論じている。
- OpenTelemetryへの初期投資は、OpenTelemetryに依存するツールを統合するプラットフォームにおいて報われると予想している。
- 上記の要点は、Cloudflare、Heroku、Kuma、Keycloakが従う指針を要約したものであると解釈している。
この記事は元記事の事実のみに基づいて自動生成されました。
出典
- 媒体名：OpenTelemetry
- 原題：OTel-Native by Design - Building Products That Export to Any Observability Stack
- URL：https://opentelemetry.io/blog/2026/otel-native-by-design/
- 補足：OpenTelemetry Integrations page、CNCFの報道による