OpenTelemetry コレクターの詳細を調べる

OpenTelemetry Collector は OpenTelemetry アーキテクチャの中心に位置しますが、W3C Trace Context とは無関係です。私のトレースデモでは、コレクターの代わりにイェーガーを使用しています。しかし、すべての OpenTelemetry 関連の投稿と同様に、この情報は遍在しています。もっと詳しく調べてみたいと思いました。

この投稿では、コレクターのさまざまな側面について説明します。

• データの種類: ログ、メトリック、トレース
• プッシュおよびプルモデル
• 操作: 読み取り、変換、書き込み

最初のステップ

ずっと前には、私たちが知っているような可観測性は存在していませんでした。代わりに私たちが持っていたのはモニタリングでした。当時の監視とは、ダッシュボードが表示された画面を大勢の人が見ていることでした。ダッシュボード自体はメトリクスと、主に CPU、メモリ、ディスク使用量などのシステム メトリクスのみで構成されていました。このため、まずメトリクスから始めます。

Prometheus は、主要な監視ソリューションの 1 つです。 Prometheus はプルベースのモデルで動作します。Prometheus はアプリケーションの互換性のあるエンドポイントを収集し、内部に保存します。

OTEL Collector を使用して Prometheus 互換エンドポイントをスクレイピングし、結果をコンソールに出力します。 Grafana Labs は、ランダムなメトリクスを生成して遊ぶプロジェクトを提供しています。簡単にするために、Docker Compose を使用します。セットアップは次のようになります。

 version: "3" services: fake-metrics: build: ./fake-metrics-generator #1 collector: image: otel/opentelemetry-collector:0.87.0 #2 environment: #3 - METRICS_HOST=fake-metrics - METRICS_PORT=5000 volumes: - ./config/collector/config.yml:/etc/otelcol/config.yaml:ro #4

1. 偽のメトリクス プロジェクトで使用できる Docker イメージはありません。したがって、それを構築する必要があります
2. この記事の執筆時点での OTEL Collector の最新バージョン
3. 次の設定ファイルをパラメータ化します
4. すべてがここで起こります

上で述べたように、OTEL Collector は多くのことができます。したがって、構成がすべてです。

 receivers: #1 prometheus: #2 config: scrape_configs: #3 - job_name: fake-metrics #4 scrape_interval: 3s static_configs: - targets: [ "${env:METRICS_HOST}:${env:METRICS_PORT}" ] exporters: #5 logging: #6 loglevel: debug service: pipelines: #7 metrics: #8 receivers: [ "prometheus" ] #9 exporters: [ "logging" ] #9

1. 受信者のリスト。受信機はデータを読み取ります。プッシュベースまたはプルベースのいずれかになります。
2. prometheus事前定義レシーバーを使用します
3. プルジョブを定義する
4. ジョブの構成
5. 輸出業者のリスト。レシーバーとは対照的に、エクスポーターはデータを書き込みます。
6. 最も単純なエクスポーターは、標準出力にデータを書き込むことです。
7. パイプラインはレシーバーとエクスポーターを組み立てます
8. メトリクス関連のパイプラインを定義する
9. パイプラインは、事前に定義されたprometheusレシーバーからデータを取得し、それをloggingエクスポーターに送信します。つまり、データを出力します。

結果のサンプルを次に示します。

 2023-11-11 08:28:54 otel-collector-collector-1 | StartTimestamp: 1970-01-01 00:00:00 +0000 UTC 2023-11-11 08:28:54 otel-collector-collector-1 | Timestamp: 2023-11-11 07:28:54.14 +0000 UTC 2023-11-11 08:28:54 otel-collector-collector-1 | Value: 83.090000 2023-11-11 08:28:54 otel-collector-collector-1 | NumberDataPoints #1 2023-11-11 08:28:54 otel-collector-collector-1 | Data point attributes: 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__embrace_world_class_systems: Str(concept) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__exploit_magnetic_applications: Str(concept) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__facilitate_wireless_architectures: Str(extranet) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__grow_magnetic_communities: Str(challenge) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__reinvent_revolutionary_applications: Str(support) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__strategize_strategic_initiatives: Str(internet_solution) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__target_customized_eyeballs: Str(concept) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__transform_turn_key_technologies: Str(framework) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__whiteboard_innovative_partnerships: Str(matrices) 2023-11-11 08:28:54 otel-collector-collector-1 | StartTimestamp: 1970-01-01 00:00:00 +0000 UTC 2023-11-11 08:28:54 otel-collector-collector-1 | Timestamp: 2023-11-11 07:28:54.14 +0000 UTC 2023-11-11 08:28:54 otel-collector-collector-1 | Value: 53.090000 2023-11-11 08:28:54 otel-collector-collector-1 | NumberDataPoints #2 2023-11-11 08:28:54 otel-collector-collector-1 | Data point attributes: 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__expedite_distributed_partnerships: Str(approach) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__facilitate_wireless_architectures: Str(graphical_user_interface) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__grow_magnetic_communities: Str(policy) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__reinvent_revolutionary_applications: Str(algorithm) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__transform_turn_key_technologies: Str(framework) 2023-11-11 08:28:54 otel-collector-collector-1 | StartTimestamp: 1970-01-01 00:00:00 +0000 UTC 2023-11-11 08:28:54 otel-collector-collector-1 | Timestamp: 2023-11-11 07:28:54.14 +0000 UTC 2023-11-11 08:28:54 otel-collector-collector-1 | Value: 16.440000 2023-11-11 08:28:54 otel-collector-collector-1 | NumberDataPoints #3 2023-11-11 08:28:54 otel-collector-collector-1 | Data point attributes: 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__exploit_magnetic_applications: Str(concept) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__grow_magnetic_communities: Str(graphical_user_interface) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__target_customized_eyeballs: Str(extranet)

印刷を超えて

上記は優れた最初のステップですが、コンソールに出力するだけではありません。通常の Prometheus インスタンスによって収集されるメトリクスを公開します。 Grafana ダッシュボードを追加して視覚化できます。無意味に思えるかもしれませんが、単なるステップストーンなので我慢してください。

上記を実現するには、OTEL コレクターの構成のみを変更します。

 exporters: prometheus: #1 endpoint: ":${env:PROMETHEUS_PORT}" #2 service: pipelines: metrics: receivers: [ "prometheus" ] exporters: [ "prometheus" ] #3

1. prometheusエクスポータを追加する
2. Prometheus 準拠のエンドポイントを公開する
3. 印刷を露光に置き換える

それでおしまい。 OTEL Collector は非常に柔軟です。

コレクタは複数入力、複数出力であることに注意してください。データの印刷とエンドポイント経由での公開の両方を行うために、データをパイプラインに追加します。

 exporters: prometheus: #1 endpoint: ":${env:PROMETHEUS_PORT}" logging: #2 loglevel: debug service: pipelines: metrics: receivers: [ "prometheus" ] exporters: [ "prometheus", "logging" ] #3

1. データを公開する
2. 印刷データ
3. パイプラインはデータの出力と公開の両方を行います

Prometheus エクスポーターを構成すると、Grafana でメトリクスを視覚化できます。

レシーバーとエクスポーターはそのタイプを指定し、それらはすべて一意である必要があることに注意してください。最後の要件を満たすために、それらを区別するための修飾子、つまりprometheus/fooとprometheus/bar.

中間データ処理

全体的な設計がより脆弱になるため、なぜ OTEL Collector がソースと Prometheus の間に設定されているのかという疑問は当然です。この段階では、OTEL Collector の真の能力であるデータ処理を活用できます。これまでのところ、生のメトリクスを取り込んでいますが、ソース形式がデータの視覚化方法に適合していない可能性があります。たとえば、私たちの設定では、メトリクスは偽のジェネレーター「ビジネス」と基盤となる NodeJS プラットフォーム「テクニカル」から取得されます。それはメトリクスの名前に反映されています。専用のソース ラベルを追加し、不要なプレフィックスを削除して、より効率的にフィルタリングすることができます。

データ プロセッサは、構成ファイルのprocessorsセクションで宣言します。コレクターは、宣言された順序でそれらを実行します。上記の変換を実装してみましょう。

私たちの目標に向けた最初のステップは、コレクターには 2 つの種類があることを理解することです。1 つは「素の」もの、もう 1 つはそれをベースにしたコントリビュートです。前者に含まれるプロセッサーは、数も機能も限られています。したがって、contrib のバージョンを切り替える必要があります。

 collector: image: otel/opentelemetry-collector-contrib:0.87.0 #1 environment: - METRICS_HOST=fake-metrics - METRICS_PORT=5000 - PROMETHEUS_PORT=8889 volumes: - ./config/collector/config.yml:/etc/otelcol-contrib/config.yaml:ro #2

1. contribフレーバーを使用する
2. さらに楽しむために、構成ファイルは別のパスにあります

この時点で、プロセッサ自体を追加できます。

 processors: metricstransform: #1 transforms: #2 - include: ^fake_(.*)$ #3 match_type: regexp #3 action: update operations: #4 - action: add_label #5 new_label: origin new_value: fake - include: ^fake_(.*)$ match_type: regexp action: update #6 new_name: $${1} #6-7 # Do the same with metrics generated by NodeJS

1. メトリクス変換プロセッサを呼び出す
2. 順番に適用される変換のリスト
3. すべてのメトリクスを定義された正規表現と照合します
4. 順番に適用される操作のリスト
5. ラベルを追加する
6. 正規表現グループのプレフィックスを削除してメトリックの名前を変更します。
7. 面白いこと: 構文は$${x}です

最後に、定義したプロセッサをパイプラインに追加します。

 service: pipelines: metrics: receivers: [ "prometheus" ] processors: [ "metricstransform" ] exporters: [ "prometheus" ]

結果は次のとおりです。

レシーバーとエクスポーターの接続

コネクタはレシーバーとエクスポーターの両方であり、2 つのパイプラインを接続します。ドキュメントの例では、スパン (トレース) の数を受け取り、メトリックを含むカウントをエクスポートします。 500 エラーで同じことを達成しようとしました - スポイラー: 意図したとおりに機能しません。

まずログ レシーバーを追加しましょう。

 receivers: filelog: include: [ "/var/logs/generated.log" ]

次に、コネクタを追加します。

 connectors: count: requests.errors: description: Number of 500 errors condition: [ "status == 500 " ]

最後に、ログ レシーバーとメトリクス エクスポーターを接続します。

 service: pipelines: logs: receivers: [ "filelog" ] exporters: [ "count" ] metrics: receivers: [ "prometheus", "count" ]

メトリックの名前はlog_record_count_totalですが、その値は 1 のままです。

ログの操作

プロセッサではデータ操作が可能です。オペレーターは、ログを処理する特殊なプロセッサーです。 Elasticsearch Logstash Kibana スタックに精通している場合、これらは Logstash と同等です。

現時点では、ログのタイムスタンプは取り込みタイムスタンプです。これを作成時のタイムスタンプに変更します。

 receivers: filelog: include: [ "/var/logs/generated.log" ] operators: - type: json_parser #1 timestamp: #2 parse_from: attributes.datetime #3 layout: "%d/%b/%Y:%H:%M:%S %z" #4 severity: #2 parse_from: attributes.status #3 mapping: #5 error: 5xx #6 warn: 4xx info: 3xx debug: 2xx - id: remove_body #7 type: remove field: body - id: remove_datetime #7 type: remove field: attributes.datetime - id: remove_status #7 type: remove field: attributes.status

1. ログは JSON 形式です。提供された JSON パーサーを使用できます
2. 設定するメタデータ属性
3. 読み取るフィールド
4. 解析パターン
5. マッピングテーブル
6. 範囲 (例: 501-599を受け入れます。オペレーターは、HTTP ステータスに対して特別に解釈された値5xx (および同様のもの) を持ちます。
7. 重複したデータを削除する

ログ

この時点で、ログを任意のログ集約コンポーネントに送信できます。私たちは Grafana Labs 領域に留まり、Loki を使用します。

 exporters: loki: endpoint: "http://loki:3100/loki/api/v1/push"

コレクター自体からのログを使用することもできます。

 service: telemetry: logs:

最後に、別のパイプラインを追加しましょう。

 service: pipelines: logs: receivers: [ "filelog" ] exporters: [ "loki" ]

Grafana はログを視覚化することもできます。データソースとして Loki を選択します。

結論

この投稿では、OpenTelemetry コレクターについて詳しく説明しました。これは OTEL アーキテクチャの必須の部分ではありませんが、すべてのデータ処理ニーズに対応する便利なスイス ナイフです。特定のスタックに固執していない場合、またはそうしたくない場合には、これは非常に役立ちます。

この投稿の完全なソース コードはGitHubにあります。

さらに進むには:

• OpenTelemetry コレクター
• OpenTelemetry オペレーター