OpenTelemetry Collector のデプロイパターンを今一度振り返る
この記事は OpenTelemetry Advent Calendar 2025 の 5 日目の記事です。
2025 年 12 月時点での情報をもとに執筆しています。
はじめに
この記事では OpenTelemetry Collector を用いてシグナルを取得する際のデプロイパターンについて振り返ります。
基本的なパターンは全て以下の OpenTelemetry の公式ドキュメントにまとまっていますので、そちらも参照してください。
上記で紹介されたパターンを全て試した経験を踏まえて、実運用における注意点などを補足しながら紹介します。
デプロイパターン
1. コレクターなしパターン
このパターンでは OpenTelemetry Collector やその他のコンポーネントを使用せずに、アプリケーションに計装を行い、直接オブザーバビリティバックエンドにデータを送信します。
公式サイトの Pros & Cons は以下のとおり記載されています。
Pros:
- Straightforward to use, especially in development and test environments
- No additional moving parts to deploy or operate
Cons:
- Requires code changes if collection, processing, or ingestion needs change
- Strong coupling between application code and backend storage or visualization
- Each language implementation supports only a limited number of exporters
このパターンでは、それぞれのオブザーバビリティバックエンドが提供している SDK や OpenTelemetry SDK を利用することが多いです。
初めてオブザーバビリティを導入する際に、最初に利用されることが多いパターンです。
アプリケーションに対して計装を行うだけで簡単に利用できます。
計装における注意点
一方で、アプリケーションから直接データを送信するため、認証情報の管理などをアプリケーション側で行う必要があります。
クラウドベンダーのマネージドサービスを利用する場合でも、 IAM や Service Account をアプリケーションごとに設定する必要があります。
SaaS を利用する際にはアプリケーション側に認証情報を持たせる必要があります。
また、異なるオブザーバビリティバックエンドを利用したい場合には、アプリケーション側に計装したコードを変更する必要があります。
※ OpenTelemetry SDK で実装している場合は exporter の差し替えだけで対応できる場合もあります。
運用における注意点
このパターンでは、基本的にアプリケーションで発行されたデータをそのままオブザーバビリティバックエンドに送信する必要があるため、コスト面での課題が出てくることがあります。
オブザーバビリティバックエンドや OpenTelemetry の SDK でも確率的サンプリング ( ヘッドベースサンプリング ) はサポートされています。
しかし、基本的には発行されたデータを全て送信し、オブザーバビリティバックエンド側でサンプリングやフィルタリングを設定する必要があります。
各オブザーバビリティバックエンドの料金体系にもよりますが、送信データ量に応じた課金体系を採用している場合が多いです。
このパターンだと送信データ量が増える分、コストが高くなる可能性があります。
他のパターンに乗り換えるタイミング
オブザーバビリティの導入初期においてはこのパターンが最もシンプルで始めやすいです。
色々なオブザーバビリティバックエンドを試したい・コストが気になるなどの課題が出てきたタイミングで後述のパターンへの乗り換えを検討すると良いでしょう。
2. Agent パターン
このパターンは、アプリケーションから直接オブザーバビリティバックエンドに送信するのではなく、間に一度、エージェントを挟むパターンです。
公式サイトの Pros & Cons は以下のとおり記載されています。
Pros:
- Straightforward to get started
- Clear one-to-one mapping between application and Collector
Cons:
- Limited scalability for teams and infrastructure resources
- Inflexible for complex or evolving deployments
後述の Gateway パターンがロードバランサーを利用するのとは異なり、アプリケーションからは特定のエージェントに対してデータを送信します。
OpenTelemetry の記事では OTLP を利用していますが、 New Relic や Datadog などの SaaS が独自にプロトコルなどを提供している場合もあります。
データを送信する先のエージェントは、同じホスト・サイドカー・独立したサービスなど様々な形式でデプロイできます。
どの形式でデプロイするかは、それぞれのツールが推奨する方法に従うと良いでしょう。
Kubernetes 環境下で OpenTelemetry Collector を利用する場合は Deployment > DaemonSet > サイドカーの順で考慮するのがおすすめです。
Deployment で配置することで以下のようなメリットを享受できます。
- 中央集権で設定を管理できる
- リソースの変更が容易にできる
もちろん、運用しているサービスの特性にもよります。
ある程度大規模になってくると、エージェント側にも負荷がかかってきます。
Deployment だと負荷が集中してしまうので DaemonSet にしてエージェントごとに負荷を分散させるのも選択肢の 1 つです。
サイドカーにする場合には、 Pod ごとにエージェントが立ち上がるため、負荷の軽減にはなる一方でかなりリソースを消費することになるため、コスト面での注意が必要です。
また、サイドカーにすることで設定ファイルの変更やバージョンアップなどの運用面での負荷も増えてしまいます。
このパターンでは、エージェントを挟むことでオブザーバビリティバックエンドだけではなくエージェント側でもサンプリングやフィルタリングが可能になります。
※ 一般的には、このパターンではスパン単位でのヘッドベースサンプリングやフィルタリングのみ可能です。
また、エージェント側で様々な情報を取得し、トレースデータに attribute として付与することも可能になります。
例えば、 DaemonSet でデプロイさせているエージェントだと、そのアプリケーションが稼働している Kubernetes ノードのバージョンやクラウドのゾーンの情報なども付与できます。
これにより、アプリケーション側ではインフラ側の情報を取得するような計装を行わなくても一括でトレースデータに対して調査時に必要なインフラ側の情報を付与できます。
計装における注意点
このパターンではアプリケーション側で認証情報を考慮する必要がなく、計装・運用で責務分解ができます。
一方で、コレクターなしパターンと同じように計装方法によってはオブザーバビリティバックエンドごとにコードの変更が必要になる場合があります。
運用における注意点
運用における注意点としては、コレクターなしパターンに比べて管理するコンポーネントが増えることです。
一般的にはこのエージェントが処理できなくなるとトレースデータは全て欠損していくので調査に支障が出てしまいます。
アプリケーション / サービスの障害時に調査ができなくなると本末転倒なのでアプリケーション / サービスよりも高い信頼性が求められます。
オブザーバビリティバックエンドが提供しているエージェントだとしても、そのエージェントのバージョンアップ対応などは必須となります。
また、エージェントもインフラリソースを消費するのでユーザー側が支払うコストも増えてしまいます。
他のパターンに乗り換えるタイミング
このパターンから後述の Gateway パターンに乗り換えるタイミングとしては、「テールベースサンプリングを導入したい」などのより複雑な要件が出てきたタイミングが良いでしょう。
3. Gateway パターン
このパターンでは、アプリケーションから直接コレクターにデータを送信するのではなく間にロードバランサーを挟み、複数のコレクターにデータを分散させるパターンです。
公式サイトの Pros & Cons は以下のとおり記載されています。
Pros:
- Separation of concerns such as centrally managed credentials
- Centralized policy management (for example, filtering certain logs or sampling)
Cons:
- It’s one more thing to maintain and that can fail (complexity)
- Added latency in case of cascaded collectors
- Higher overall resource usage (costs)
メリットとしては Agent パターンのメリットに加えて、コレクターレイヤーの負荷分散やより柔軟なサンプリング、フィルタリングなどが可能になります。
アプリケーション側の設定としては、 Agent パターンと同様に送信先を設定するだけなので追加の対応は不要です。
計装における注意点
計装における注意点としては Agent パターンと同様になります。
運用における注意点
このパターンは Agent パターンに比べてさらにロードバランサーレイヤーも加わるため、管理するコンポーネントがさらに増えます。
クラウドベンダーのマネージドサービスを利用したり Kubernetes Service を利用することで運用コストを下げることも可能です。
より柔軟にスパンの情報などを用いてロードバランシングしたい場合は、 OpenTelemetry Collector の loadbalancingexporter を利用することで実現できます。
loadbalancingexporter を利用することで、一般的なリクエストに基づくロードバランシングだけではなく、特定のトレースに関連するスパンを全て同じコレクターに送信するなどのトレースデータに関連したロードバランシングも可能になります。
おまけ : Agent + Gateway パターン
上記で紹介したパターンは必要に応じて組み合わせて利用できます。
例えば、大規模にテールベースサンプリングを導入したい場合には、以下のように Agent + Gateway パターンを組み合わせることで実現できます。
エージェントをアプリケーションと同じホストに DaemonSet でデプロイし、一度アプリケーションからデータを受け取ります。
その際に、エージェントでそのホストの情報をトレースデータに付与できます。
その後、エージェントから Gateway パターンで構築されているエージェントにデータを送信し、テールベースサンプリングを実施します。
このパターンでは前段のエージェントで情報の付与などを行い、後段のエージェントでサンプリングやフィルタリングなどの処理を行うように分離することで責務分解や負荷分散が可能になります。
最後に
この記事では OpenTelemetry Collector のデプロイパターンについて振り返りました。
各パターンにはそれぞれメリット・デメリットがあるため、運用しているサービスの特性や要件に応じて最適なパターンを選択することが重要です。
この記事では紹介しきれなかった実際のサービスや運用に関する知見については、以下の参考発表をぜひご覧ください。
参考発表の紹介
参考レポジトリの紹介
今回紹介したデプロイパターンをはじめとした、色々なデプロイパターンでの OpenTelemetry Collector の設定ファイルをまとめたレポジトリを見つけたので共有しておきます。
Discussion