OpenTelemetry Collector 開発

Receiver が解決するビジネスユースケースは以下の通りです

• リモートソースからデータをフェッチする
• リモートソースからデータを受信する

これは一般的に pull 型と push 型のデータ収集と呼ばれ、詳細は Receiver の概要 で読むことができます。

Processor が解決するビジネスユースケースは以下の通りです

• データ、フィールド、または値の追加や削除
• データを観測し、意思決定を行う
• バッファリング、キューイング、並び替え

留意すべき点は、Processor を流れるデータタイプは、下流のコンポーネントに同じデータタイプを転送する必要があるということです。詳細は Processor の概要 をお読みください。

Exporter が解決するビジネスユースケースは以下の通りです

• ツール、サービス、またはストレージにデータを送信する

OpenTelemetry Collector は「バックエンド」、つまりオールインワンのオブザーバビリティスイートになることを望んでおらず、むしろ OpenTelemetry を創設した原則を維持しています。つまり、すべての人のためのベンダーに依存しないオブザーバビリティです。詳細を再確認するには、Exporter の概要 をお読みください。

これはワークショップで見逃されたコンポーネントタイプです。比較的新しい Collector への追加であるためです。Connector を考える最良の方法は、異なるテレメトリタイプとパイプライン間で使用できる Processor のようなものです。つまり、Connector はログとしてデータを受け入れ、メトリクスを出力したり、あるパイプラインからメトリクスを受け入れ、観測したデータに関するメトリクスを提供したりできます。

Connector が解決するビジネスケースは以下の通りです

• 異なるテレメトリタイプ間の変換
  • ログからメトリクス
  • トレースからメトリクス
  • メトリクスからログ
• 受信データを観測し、独自のデータを生成する
  • メトリクスを受け入れ、データの分析メトリクスを生成する。

Processor の概要 の Ninja セクションに簡単な概要がありました。新しい Connector コンポーネントの更新についてはプロジェクトを確認してください。