OpenTelemetry入門【実践編】～OpenTelemetry Collectorでテレメトリーデータを扱う～

　この連載は、オブザーバビリティという言葉を聞いたことはあるが具体的なイメージを持っていないエンジニア向けにOpenTelemetryについて紹介するものです。概要理解から導入方法まで一通り理解いただける連載となります。第3回目は、テレメトリーデータの収集と送信のためのOpenTelemetry Collectorについて扱います。

対象読者

　この連載では以下の読者を想定しています。

• オブザーバビリティや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でバックエンド（オブザーバビリティツールなど）に送信することができます。

https://opentelemetry.io/ja/docs/collector/

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]

　それでは各コンポーネントにはどのようなものがあるでしょうか？

　次のページで簡単に見ていきたいと思います。