対象読者
この連載では以下の読者を想定しています。
- オブザーバビリティやOpenTelemetryに興味がある人
- SREやDevOps、Platform Engineeringに取り組んでいるエンジニア
- バックエンド開発者、クラウドエンジニア、インフラエンジニア
OpenTelemetryによるデータ収集
前回まではオブザーバビリティとOpenTelemetryとの関係性（第一回）、そしてオブザーバビリティのためのテレメトリーデータ（第二回）について解説してきました。
今回からは具体的なデータの取得方法について解説します。
第一回で「OpenTelemetryはオブザーバビリティフレームワーク」と紹介しました。
OpenTelemetryには、主にアプリケーションからトレースやメトリクスを取得するためのSDK、APIに加え、それらのデータやその他のメトリクスやログの収集、処理、送信を担うOpenTelemetry Collectorというコンポーネントが提供されています。
今回はこのOpenTelemetry Collectorについて解説します。
OpenTelemetry Collectorとは
OpenTelemetry Collector（以下、OTel Collector）は、Receiver、Processor、Exporterという3つの主要コンポーネントからなるテレメトリーデータのパイプラインを構成します。その他にもExtension、Connectorという拡張機能もあります。
概念図は以下の通りです。さまざまなデータソースをReceiverで受信し、Processorで処理、Exporterでバックエンド（オブザーバビリティツールなど）に送信することができます。
OpenTelemetry Collectorのメリット
何と言ってもテレメトリーデータの取得と送信がベンダー独自のデータモデルに縛られないことでしょう。
つまりベンダーロックインの回避です。
OTel Collectorを使うことでさまざまな事情によりオブザーバビリティツールを切り替えたい場合でも宛先を変更するだけで済みます。
その他にもデータ処理の柔軟性も挙げられます。こちらも後ほど詳しく見ていきたいと思います。
組織内のあらゆる環境のシステムにOTel Collectorに導入することでテレメトリーデータが標準化されエンジニア間のノウハウも共有可能になります。
エージェントを探す旅はこれで終わるのです。
OpenTelemetry Collectorのパイプラインの構造
各コンポーネントとパイプラインは設定ファイルのyamlで構成します。
最もシンプルな例は以下の通りです。これはアプリから取得したトレースをOTLP（OpenTelemetry Protocol）で受信し、バックエンドへOTLPで送信する処理になっています。
receivers:
otlp:
protocols:
grpc:
exporters:
otlp:
endpoint: <バックエンドのエンドポイント>
service:
extensions: []
pipelines:
traces:
receivers: [otlp]
processors: []
exporters: [otlp]
それでは各コンポーネントにはどのようなものがあるでしょうか？
次のページで簡単に見ていきたいと思います。
