OpenTelemetry Collector を開発する
コンポーネントを検討する
Jenkinsからメトリクスを取得するために必要なコンポーネントの種類をおさらいしましょう:
レシーバーが解決するビジネスユースケースは以下の通りです:
- リモートソースからのデータの取得
- リモートソースからのデータの受信
これらは一般的に pull 対 push ベースのデータ収集と呼ばれ、詳細についてはレシーバーの概要で読むことができます。
プロセッサーが解決するビジネスユースケースは以下の通りです:
- データ、フィールド、または値の追加または削除
- データの観察と意思決定
- バッファリング、キューイング、および並べ替え
プロセッサーを通過するデータタイプは、下流のコンポーネントに同じデータタイプを転送する必要があることを覚えておいてください。 詳細については、プロセッサーの概要をご覧ください。
エクスポーターが解決するビジネスユースケースは以下の通りです:
- データをツール、サービス、またはストレージに送信する
OpenTelemetryコレクターは「バックエンド」、すべてを一元化した観測可能性スイートを目指すのではなく、OpenTelemetryの創設原則に忠実であり続けることを目指しています。つまり、ベンダーに依存しない全ての人のための観測可能性です。詳細については、エクスポーターの概要をお読みください。
コネクターは比較的新しいコンポーネントで、このワークショップではあまり触れていません。 コネクターは、異なるテレメトリタイプやパイプラインをまたいで使用できるプロセッサーのようなものだといえます。たとえば、コネクターはログとしてデータを受け取り、メトリクスとして出力したり、あるパイプラインからメトリクスを受け取り、テレメトリーデータに関するメトリクスを提供したりすることができます。
コネクターが解決するビジネスケースは以下の通りです:
- 異なるテレメトリタイプ間の変換
- ログからメトリクスへ
- トレースからメトリクスへ
- メトリクスからログへ
- 受信したデータを観察し、自身のデータを生成する
- メトリクスを受け取り、データの分析メトリクスを生成する。
Ninjaセクションの一部としてプロセッサーの概要内で簡単に概要が説明されています。
これらのコンポーネントについて考えると、Jenkins に対応する場合はプルベースのレシーバーを開発する必要があることがわかります。