OpenTelemetry Collector を開発する

コンポーネントを検討する

Jenkinsからメトリクスを取得するために必要なコンポーネントの種類をおさらいしましょう:

エクステンションが解決するビジネスユースケースは以下の通りです:

  1. 実行時の設定が必要な共有機能を持つ
  2. コレクターの実行時間の観察に間接的に役立つ

詳細については、エクステンションの概要を参照してください。

レシーバーが解決するビジネスユースケースは以下の通りです:

  • リモートソースからのデータの取得
  • リモートソースからのデータの受信

これらは一般的に pullpush ベースのデータ収集と呼ばれ、詳細についてはレシーバーの概要で読むことができます。

プロセッサーが解決するビジネスユースケースは以下の通りです:

  • データ、フィールド、または値の追加または削除
  • データの観察と意思決定
  • バッファリング、キューイング、および並べ替え

プロセッサーを通過するデータタイプは、下流のコンポーネントに同じデータタイプを転送する必要があることを覚えておいてください。 詳細については、プロセッサーの概要をご覧ください。

エクスポーターが解決するビジネスユースケースは以下の通りです:

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

OpenTelemetryコレクターは「バックエンド」、すべてを一元化した観測可能性スイートを目指すのではなく、OpenTelemetryの創設原則に忠実であり続けることを目指しています。つまり、ベンダーに依存しない全ての人のための観測可能性です。詳細については、エクスポーターの概要をお読みください。

コネクターは比較的新しいコンポーネントで、このワークショップではあまり触れていません。 コネクターは、異なるテレメトリタイプやパイプラインをまたいで使用できるプロセッサーのようなものだといえます。たとえば、コネクターはログとしてデータを受け取り、メトリクスとして出力したり、あるパイプラインからメトリクスを受け取り、テレメトリーデータに関するメトリクスを提供したりすることができます。

コネクターが解決するビジネスケースは以下の通りです:

  • 異なるテレメトリタイプ間の変換
    • ログからメトリクスへ
    • トレースからメトリクスへ
    • メトリクスからログへ
  • 受信したデータを観察し、自身のデータを生成する
    • メトリクスを受け取り、データの分析メトリクスを生成する。

Ninjaセクションの一部としてプロセッサーの概要内で簡単に概要が説明されています。

これらのコンポーネントについて考えると、Jenkins に対応する場合はプルベースのレシーバーを開発する必要があることがわかります。