OTelネイティブ設計 - どんなオブザーバビリティスタックにもエクスポートできる製品の構築

OTelネイティブ設計 - どんなオブザーバビリティスタックにもエクスポートできる製品の構築 Nityananda Gohain (SigNoz)、Dhruv Ahuja (SigNoz) | 2026年10月08日 木曜日 Dan Gomez Blanco (New Relic) による寄稿。 セルフホスト型ソフトウェアまたはSaaS製品を構築している場合、ユーザーは最終的に、コンプライアンスの遵守、コスト管理、またはオブザーバビリティデータを一箇所に集約するために、自身のオブザーバビリティスタックにログ、トレース、メトリクスを送信するように求めるでしょう。 組み込みダッシュボードにユーザーを閉じ込めたり、特定のベンダーへのエクスポートを制限したりすることは、不必要な摩擦を生み出します。代わりに、任意のOpenTelemetry (OTel) 互換バックエンドへのエクスポートをサポートすることは、ベンダーニュートラルで将来性のあるプラクティスであり、ユーザーにオブザーバビリティスタックを選択する自由を与えます。 この記事では、ユーザーがログ、トレース、メトリクスを必要に応じてOTelバックエンドにエクスポートできるように、製品をどのように設計できるかを概説します。 4つのオブザーバビリティシグナル OpenTelemetryは4つのシグナルタイプを定義しており、これらはすべて標準のOpenTelemetry Protocol (OTLP) を介して伝送されます。 ログ: イベントレコード、リクエスト/アクセスログ、タイムスタンプとメタデータを持つアプリケーションログ。 トレース: 分散トレースとスパン。これにより、ユーザーはサービス間のリクエストフローを確認し、ログと相関させることができます。 メトリクス: カウンター、ゲージ、ヒストグラム（例: リクエストレート、レイテンシ、エラーレート）。 プロファイル: アプリケーションが実行中にリソースを消費する箇所を示すサンプル。 プロファイルはパブリックアルファ版です プロファイルは2026年3月26日にパブリックアルファ版になりました。シグナルとして、OpenTelemetryはプロファイルを現在の3つの主要なオブザーバビリティシグナルと並ぶものとして意図しており、コードベース全体のリソース使用パターンをキャプチャすることで、ユーザーが本番環境のインシデントをトラブルシューティングするのを支援します。 このブログではログ、トレース、メトリクスにのみ焦点を当てていますが、プロファイルがどのように形作られ、コミュニティがオブザーバビリティシステムでそれらをどのように活用していくのかを見るのが楽しみです。 エクスポートの話は、これら3つ（ログ、トレース、メトリクス）すべてに同じように適用されます。ユーザーがOTLPエンドポイントを設定し、そこにテレメトリをプッシュできるようにします。製品が生成するものに応じて、1つ、2つ、またはすべてのシグナルをサポートできます。 OTelエクスポートをサポートする多くのプラットフォームは、少なくともトレースとログをサポートしており、現在ではメトリクスサポートを搭載するものも増えています。最初からすべて3つをサポートするように設計することで、後で改修する必要がなくなります。 「良い」テレメトリシステムとは 堅牢なエクスポートストーリーは、サポートする各シグナルに対して、いくつかの明確なプロパティを持っています。 ベンダーニュートラル: ユーザーは、各ベンダーごとにカスタムインテグレーションを構築することなく、コレクターインスタンスやOTLPを直接サポートする多くのバックエンドのいずれかなど、任意のOTel互換エンドポイントを指すことができます。 深いカスタム開発不要: 外部プラットフォーム（またはユーザーのツール）は、プロプライエタリAPIの代わりに標準OTel SDKとOTLPプロトコルを使用して統合できます。 リッチなコンテキストを維持: エクスポートされたデータには、メタデータ、タイムスタンプ、および利用可能な場合はトレース/スパンの相関（例: トレースIDにリンクされたログレコード）が含まれている必要があります。これにより、ユーザーはコンテキストを失うことなく、自身のバックエンドでデータをデバッグおよび分析できます。 セマンティックコンベンションのサポート: セマンティックコンベンションへの準拠により、テレメトリデータが標準化され、互換性のあるバックエンドで容易に解釈可能であることが保証されます。また、エンドユーザーがソフトウェアシステム（ファーストパーティまたはサードパーティのシステム）の動作を理解する際の認知的負荷を軽減します。 発行するシグナルに対してこれらの原則に沿った設計を行えば、最新のプラットフォームがオブザーバビリティエクスポートをどのように考えているかに沿ったものになります。 2つのコンテキスト: 製品はどこで実行されますか？ OTelエクスポートを追加する方法は、テレメトリを生成するシステムを誰が所有しているかによって異なります。これを正しく理解することで、適切なアプローチを選択できます。 セルフホスト型ソフトウェア あなたの製品は、顧客が自身の環境（データセンター、クラウド、Kubernetesクラスター）にインストールして実行するアプリケーションまたはシステム（例: 認証サーバー、サービスメッシュ、データベース）です。 この場合、OpenTelemetryで製品をインストルメントします。顧客がエンドポイントを設定すると（例: 環境変数または設定ファイル経由）、アプリケーションは実行中のプロセスからテレメトリをエクスポートします。 OpenTelemetryはこのような標準的な設定オプションを提供しているため、ユーザーは他のOTelインストルメントされたシステムですでに持っている設定体験と同じものを期待できます。 エクスポートは顧客の環境で発生します。彼らはバイナリと宛先を制御します。例: Keycloak、Kuma。 クラウドプラットフォーム あなたの製品は、顧客が自身のアプリをデプロイしたり、あなたのマネージドサービス（例: PaaS、サーバーレス、APIゲートウェイ）を使用したりするプラットフォームです。ワークロードはあなたのインフラストラクチャ上で実行されます。 この場合、「テレメトリドレイン」や「オブザーバビリティデスティネーション」のようなプラットフォーム機能を追加し、顧客がテレメトリを送信する場所を設定できるようにします。あなたのプラットフォームは、顧客のワークロード（およびルーターのようなあなた自身のサービス）からテレメトリを収集し、顧客のOTLPエンドポイントに転送します。 エクスポートは、顧客が実行するアプリケーションバイナリではなく、あなたのインフラストラクチャによって行われます。例: Heroku、Cloudflare。 要するに、ユーザーがデプロイしたソフトウェア → 組み込みインストルメンテーションとエンドポイント設定に焦点を当てる。あなたが運用するプラットフォーム → あなたのインフラストラクチャが転送に使用する設定可能なエクスポート宛先に焦点を当てる。 他社はどうしているか この記事では、上記の2つのコンテキストを代表する例として、Kuma、Keycloak、Cloudflare、Herokuの4つのインテグレーションに焦点を当てていますが、これらがOTLP経由でネイティブにテレメトリをエクスポートしている唯一の例ではありません。OpenTelemetry Integrationsページには、ネイティブインストルメンテーションまたはファーストクラスプラグインを提供するライブラリやサービスが掲載されています。 以下は、これら4つの例が3つのシグナル（またはそのサブセット）をどのように処理しているかと、そこから学べることです。 プラットフォーム | ログ | トレース | メトリクス | デプロイメントモード | メモ Kuma | はい | はい | はい | ソフトウェアユーザーがデプロイ | 各シグナルごとに別々のポリシー、すべてOTel Keycloak | はい† | はい | はい | ソフトウェアユーザーがデプロイ | †ログはプレビュー版。すべて同じエンドポイント Cloudflare Workers | はい | はい | いいえ* | プラットフォーム | *メトリクスエクスポートはまだサポートされていません Heroku | はい | はい | はい | プラットフォーム | ユーザーは --signals でシグナルを選択 セルフホスト型アプローチ: KumaとKeycloak ユーザーがあなたのソフトウェアを自身の環境にデプロイする場合、アプリケーションをOpenTelemetryで事前にインストルメントして出荷し、OTLPエンドポイント用の設定フラグを公開するのがベストプラクティスです。 Kuma 顧客がKumaのコントロールプレーンとデータプレーンを自身のKubernetesクラスターまたはVMで実行する場合でも、ログ、トレース、メトリクスをOTelバックエンドに発行するように事前に設定されています。 ユーザーは、メッシュポリシーを通じて、Kumaデプロイメントから実行されるエクスポートを設定します。 MeshAccessLog: アクセスログをOTelコレクター（エンドポイント + メッシュ名、開始時刻などの属性）にルーティングします。 MeshTrace: 設定可能なサンプリングとタグ付けで分散トレースを処理します。 MeshMetric: コントロールプレーンとデータプレーンのメトリクスを公開します。OpenTelemetryおよびPrometheusと統合します。 例えば、トレースをOTelバックエンドに送信する場合、次のようになります。 # MeshTrace ポリシー backends: - type: OpenTelemetry openTelemetry: endpoint: otel-collector:4317 アクセスログの送信は、異なるポリシーで全く同じパターンに従います。 # MeshAccessLog ポリシー backends: - type: OpenTelemetry openTelemetry: endpoint: otel-collector:4317 body: kvlistValue: values: - key: mesh value: stringValue: '%KUMA_MESH%' - key: start_time value: stringValue: '%START_TIME%' さらに読む: Kuma MeshAccessLog – OpenTelemetry Kuma MeshTrace (OpenTelemetry バックエンド) Kuma オブザーバビリティ Keycloak Keycloakは、優れたテレメトリエクスポート機能を提供するセルフホスト型ソフトウェアのもう一つの例です。 個別のサイドカーやプラットフォーム機能を必要とするのではなく、ユーザーはコレクターエンドポイントを指す起動フラグを渡すだけで、Keycloakプロセス自体がエクスポートを処理します。 単一のテレメトリエンドポイントを使用しますが、特定のシグナルを切り替えるための詳細なフラグを提供します。 トレース: tracing-enabled=true (HTTPリクエスト、DB、LDAP、アウトバウンドHTTP/IdPをカバーします)。 メトリクス: 同じOTel統合を介して公開される詳細なメトリクス。 ログ: 現在プレビュー版であり、デフォルトでは無効です (--features=opentelemetry-logs --telemetr