OTel Collector: テレメトリ パイプラインの中心
L'OpenTelemetry コレクター スタンドアロンでベンダーに依存しないコンポーネントは、 テレメトリ データを処理してエクスポートします。アプリケーション間のスマートプロキシとして機能します インストルメンテーションと可観測性のバックエンドを分離し、抽象化レイヤーを提供します。 最終宛先からのデータの生成。
コレクターは、運用環境の可観測性インフラストラクチャの最も重要なコンポーネントです。 Without it, each application must know and manage the direct connection to the backend, バックエンドの変更、中間処理の追加、またはシナリオの管理が困難になる フェイルオーバー。 Collector を使用すると、エクスポート構成とアプリケーションを一元化できます。 コレクターに到達する方法を知る必要があるだけです。
この記事で学べること
- コレクターの内部アーキテクチャ: レシーバー、プロセッサー、エクスポーター
- YAML を使用してコレクタを構成する方法
- 最も重要なプロセッサ: バッチ、フィルター、属性、tail_sampling
- 導入パターン: エージェント、ゲートウェイ、サイドカー
- コレクターのスケーリングと高可用性
- コレクター自体の監視 (メタ可観測性)
コレクタのアーキテクチャ
Collector は、3 種類のコンポーネントで構成されるパイプライン アーキテクチャを持ち、接続されています。 経由 パイプライン 信号のタイプごとに構成可能 (トレース、メトリック、ログ):
コレクターパイプライン
受信機 (入力) → プロセッサー (変身) →
輸出業者 （出口）
パイプラインには複数のレシーバー (複数のソースから収集)、プロセッサーのチェーンを含めることができます。
(フィルター、エンリッチ、サンプル) および複数のエクスポーター (同時に複数のバックエンドに送信)。
レシーバー: エントリーポイント
I 受信機 これらはコレクターのエントリ ポイントです。テレメトリデータを受け入れます さまざまなソースからファイルを取得し、内部 OTel 形式に変換します。最も一般的な受信機は OTLP 受信機です。 ただし、Collector は、さまざまなプロトコルやソースの数十の受信機をサポートしています。
プロセッサ: データ変換
I プロセッサー 受信とエクスポートの間にデータを変更します。彼らはできる テレメトリ信号のフィルタリング、強化、サンプリング、グループ化、変換を行います。 パイプライン内のプロセッサの順序は重要です。プロセッサは順番に実行されます。
エクスポーター: データの宛先
Gli 輸出業者 処理されたデータは最終的な宛先、つまりバックエンドに送信されます。 ストレージ、表示サービス、またはその他のコレクター。パイプラインには複数のエクスポーターを含めることができます 同じデータを異なる宛先に同時に送信します。
完全なコレクター構成
コレクターは、レシーバー、プロセッサー、エクスポーター、およびレシーバーを定義する YAML ファイルで構成されます。 それらをつなぐパイプライン。以下は本番環境に対応した構成です。
# otel-collector-config.yaml - Configurazione production-ready
receivers:
# OTLP receiver: il protocollo nativo di OpenTelemetry
otlp:
protocols:
grpc:
endpoint: "0.0.0.0:4317"
max_recv_msg_size_mib: 4
http:
endpoint: "0.0.0.0:4318"
cors:
allowed_origins: ["*"]
# Prometheus receiver: scraping di metriche Prometheus
prometheus:
config:
scrape_configs:
- job_name: "kubernetes-pods"
scrape_interval: 30s
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
action: keep
regex: true
# Filelog receiver: raccolta log da file
filelog:
include: ["/var/log/pods/*/*/*.log"]
operators:
- type: json_parser
timestamp:
parse_from: attributes.time
layout: "%Y-%m-%dT%H:%M:%S.%LZ"
processors:
# Batch processor: raggruppamento per invii efficienti
batch:
send_batch_size: 1024
send_batch_max_size: 2048
timeout: 5s
# Memory limiter: protezione da OOM
memory_limiter:
check_interval: 1s
limit_mib: 512
spike_limit_mib: 128
# Resource processor: aggiungere attributi globali
resource:
attributes:
- key: deployment.environment
value: "production"
action: upsert
- key: collector.version
value: "0.96.0"
action: insert
# Attributes processor: filtrare attributi sensibili
attributes:
actions:
- key: http.request.header.authorization
action: delete
- key: db.query.text
action: hash
# Filter processor: scartare telemetria non necessaria
filter:
error_mode: ignore
traces:
span:
- 'attributes["http.route"] == "/health"'
- 'attributes["http.route"] == "/ready"'
metrics:
metric:
- 'name == "http.server.request.duration" and resource.attributes["service.name"] == "debug-service"'
exporters:
# OTLP exporter: verso Jaeger per le tracce
otlp/jaeger:
endpoint: "jaeger-collector:4317"
tls:
insecure: true
# Prometheus exporter: esporre metriche per Prometheus
prometheus:
endpoint: "0.0.0.0:8889"
resource_to_telemetry_conversion:
enabled: true
# Loki exporter: verso Loki per i log
loki:
endpoint: "http://loki:3100/loki/api/v1/push"
default_labels_enabled:
exporter: true
job: true
# Debug exporter: per testing
debug:
verbosity: basic
sampling_initial: 5
sampling_thereafter: 200
extensions:
# Health check endpoint
health_check:
endpoint: "0.0.0.0:13133"
# Performance profiling
pprof:
endpoint: "0.0.0.0:1777"
# zPages: debugging UI built-in
zpages:
endpoint: "0.0.0.0:55679"
service:
extensions: [health_check, pprof, zpages]
pipelines:
# Pipeline per le tracce
traces:
receivers: [otlp]
processors: [memory_limiter, filter, attributes, batch]
exporters: [otlp/jaeger, debug]
# Pipeline per le metriche
metrics:
receivers: [otlp, prometheus]
processors: [memory_limiter, resource, batch]
exporters: [prometheus]
# Pipeline per i log
logs:
receivers: [otlp, filelog]
processors: [memory_limiter, resource, attributes, batch]
exporters: [loki]
telemetry:
logs:
level: info
metrics:
address: "0.0.0.0:8888"
導入パターン
コレクターは 3 つの主なパターンで導入でき、それぞれに利点とトレードオフがあります。 具体的な。実稼働環境では、複数のパターンが組み合わされることがよくあります。
1. エージェントモード (DaemonSet)
各クラスター ノード上のコレクターのインスタンス (Kubernetes の DaemonSet)。あらゆるアプリケーション ノード上のテレメトリは localhost 経由でローカル コレクタに送信され、ネットワーク遅延が最小限に抑えられます。 エージェントは簡単な前処理 (バッチ処理、フィルタリング) を実行し、ゲートウェイに転送します。
2. ゲートウェイ モード (展開)
エージェントから、またはエージェントから直接テレメトリを受信するコレクタの集中プール アプリケーション。ゲートウェイは、負荷の高い処理 (テール サンプリング、集計) を実行し、 バックエンドにエクスポートします。テレメトリのボリュームに基づいて水平方向にスケールします。
3. サイドカーモード
ポッドごとに 1 つのコレクタ インスタンス。サイドカー コンテナとしてデプロイされます。隔離を提供します アプリケーション全体にわたって包括的であり、サービス固有の構成が可能です。そしてそのパターン リソースの点では最も高価ですが、最も柔軟です。
# Kubernetes: Agent (DaemonSet) + Gateway (Deployment)
# Agent DaemonSet - uno per nodo
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: otel-collector-agent
namespace: observability
spec:
selector:
matchLabels:
app: otel-collector-agent
template:
metadata:
labels:
app: otel-collector-agent
spec:
containers:
- name: collector
image: otel/opentelemetry-collector-contrib:0.96.0
args: ["--config=/etc/otel/config.yaml"]
resources:
requests:
cpu: 100m
memory: 256Mi
limits:
cpu: 500m
memory: 512Mi
ports:
- containerPort: 4317 # OTLP gRPC
- containerPort: 4318 # OTLP HTTP
volumeMounts:
- name: config
mountPath: /etc/otel
volumes:
- name: config
configMap:
name: otel-agent-config
---
# Gateway Deployment - scalabile
apiVersion: apps/v1
kind: Deployment
metadata:
name: otel-collector-gateway
namespace: observability
spec:
replicas: 3
selector:
matchLabels:
app: otel-collector-gateway
template:
metadata:
labels:
app: otel-collector-gateway
spec:
containers:
- name: collector
image: otel/opentelemetry-collector-contrib:0.96.0
args: ["--config=/etc/otel/config.yaml"]
resources:
requests:
cpu: 500m
memory: 1Gi
limits:
cpu: 2
memory: 4Gi
導入パターンの比較
| パターン | リソース | レイテンシ | 絶縁 | 一般的な使用方法 |
|---|---|---|---|---|
| エージェント | 低 (ノードごと) | 最小値 (ローカルホスト) | ノード別 | 前処理、バッファリング |
| ゲートウェイ | 中～高 (プール) | メディア（ネットワーク） | 集中化 | テールサンプリング、集計 |
| サイドカー | 高 (ポッドあたり) | 最小値 (ローカルホスト) | サービス用 | 特定の構成、分離 |
メタオブザーバビリティ: コレクターの監視
コレクターはインフラストラクチャの重要なコンポーネントです。機能しなくなったら失われます システム全体の可視性。このため、コレクター自体を監視することが不可欠です。 OTel Collector は、廃棄可能な専用エンドポイントで内部メトリクスを公開します プロメテウスより。
監視すべき主要なコレクターメトリクス
- otelcol_receiver_accepted_spans: スパンは正常に受信されました (入力スループット)
- otelcol_receiver_refred_spans: スパンが拒否されました (オーバーロードの可能性があります)
- otelcol_exporter_sent_spans: スパンは正常にエクスポートされました (出力スループット)
- otelcol_exporter_send_failed_spans: エクスポート エラー (バックエンドの問題)
- otelcol_processor_batch_batch_send_size: 送信されたバッチのサイズ
- otelcol_process_runtime_total_alloc_bytes: 割り当てられたメモリ (OOM リスク)
- otelcol_processor_dropped_spans: プロセッサによって破棄されたスパン (データ損失)
結論と次のステップ
OTel Collector は、可観測性インフラストラクチャの主要なアーキテクチャ コンポーネントです スケーラブルで保守可能です。パイプライン アーキテクチャ (レシーバー、プロセッサー、エクスポーター) データのフィルタリングからテレメトリ データの管理に完全な柔軟性を提供します 複数のバックエンドへのルーティングに敏感です。
導入パターン (エージェント、ゲートウェイ、サイドカー) の選択は、特定のニーズに応じて異なります 組織の。運用環境で最も一般的なパターンは、エージェント (DaemonSet) を組み合わせます。 集中処理とエクスポートのためのローカル前処理とゲートウェイ (デプロイメント)。
次の記事では、バックエンドとの統合: 設定方法 トレースにはJaeger、メトリクスにはPrometheus、視覚化ダッシュボードにはGrafana、 完全で機能的な可観測性スタックを作成します。