OpenTelemetry Collector は OpenTelemetry アーキテクチャの中心に位置しますが、W3C Trace Context とは無関係です。私の では、コレクターの代わりにイェーガーを使用しています。しかし、すべての OpenTelemetry 関連の投稿と同様に、この情報は遍在しています。もっと詳しく調べてみたいと思いました。 トレースデモ この投稿では、コレクターのさまざまな側面について説明します。 データの種類: ログ、メトリック、トレース プッシュおよびプルモデル 操作: 読み取り、変換、書き込み 最初のステップ ずっと前には、私たちが知っているような 存在していませんでした。代わりに私たちが持っていたのは でした。当時の監視とは、ダッシュボードが表示された画面を大勢の人が見ていることでした。ダッシュボード自体はメトリクスと、主に CPU、メモリ、ディスク使用量などのシステム メトリクスのみで構成されていました。このため、まずメトリクスから始めます。 可観測性は モニタリング   、主要な監視ソリューションの 1 つです。 Prometheus はプルベースのモデルで動作します。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 偽のメトリクス プロジェクトで使用できる Docker イメージはありません。したがって、それを構築する必要があります この記事の執筆時点での OTEL Collector の最新バージョン 次の設定ファイルをパラメータ化します すべてがここで起こります 上で述べたように、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 受信者のリスト。受信機はデータを読み取ります。プッシュベースまたはプルベースのいずれかになります。   事前定義レシーバーを使用します prometheus プルジョブを定義する ジョブの構成 輸出業者のリスト。レシーバーとは対照的に、エクスポーターはデータを書き込みます。 最も単純なエクスポーターは、標準出力にデータを書き込むことです。 パイプラインはレシーバーとエクスポーターを組み立てます メトリクス関連のパイプラインを定義する パイプラインは、事前に定義された レシーバーからデータを取得し、それを エクスポーターに送信します。 、データを出力します。 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   エクスポータを追加する prometheus Prometheus 準拠のエンドポイントを公開する 印刷を露光に置き換える それでおしまい。 OTEL Collector は非常に柔軟です。 コレクタは複数入力、複数出力であることに注意してください。データの印刷とエンドポイント経由での公開の両方を行うために、データをパイプラインに追加します。   exporters: prometheus: #1 endpoint: ":${env:PROMETHEUS_PORT}" logging: #2 loglevel: debug service: pipelines: metrics: receivers: [ "prometheus" ] exporters: [ "prometheus", "logging" ] #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   フレーバーを使用する contrib さらに楽しむために、構成ファイルは別のパスにあります この時点で、プロセッサ自体を追加できます。   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 メトリクス変換プロセッサを呼び出す 順番に適用される変換のリスト すべてのメトリクスを定義された正規表現と照合します 順番に適用される操作のリスト ラベルを追加する 正規表現グループのプレフィックスを削除してメトリックの名前を変更します。 面白いこと: 構文は です $${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" ] メトリックの名前は ですが、その値は 1 のままです。 log_record_count_total ログの操作 プロセッサではデータ操作が可能です。オペレーターは、ログを処理する特殊なプロセッサーです。 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 ログは JSON 形式です。提供された JSON パーサーを使用できます 設定するメタデータ属性 読み取るフィールド 解析パターン マッピングテーブル 範囲 ( :  を受け入れます。オペレーターは、HTTP ステータスに対して特別に解釈された値  (および同様のもの) を持ちます。 例 501-599 5xx 重複したデータを削除する ログ この時点で、ログを任意のログ集約コンポーネントに送信できます。私たちは 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 オペレーター 初版は 2023 年 11 月 12 日に で A Java Geek 公開されました

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

このオーディオは、ストーリーの元の言語で制作されています。

長すぎる; 読むには

Make resilience your competitive advantage

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

About Author

コメント

ラベル

この記事は

Related Stories

Claude Sonnet 3.5 システムプロンプトの漏洩: 法医学的分析

ユニークなエコシステムを支えるビットコインUTXOのモデル

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

海を航海する: データレイクを使用した本番環境レベルの RAG アプリケーションの開発

Claude Sonnet 3.5 システムプロンプトの漏洩: 法医学的分析

ユニークなエコシステムを支えるビットコインUTXOのモデル

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

海を航海する: データレイクを使用した本番環境レベルの RAG アプリケーションの開発

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps