Otel Collector: 원격 측정 파이프라인의 핵심
L'OpenTelemetry 수집기 그리고 공급업체에 구애받지 않는 독립형 구성요소는 다음과 같습니다. 원격 측정 데이터를 처리하고 내보냅니다. 애플리케이션 간의 스마트 프록시로 작동합니다. 계측 및 관찰 가능성 백엔드를 통해 분리되는 추상화 계층을 제공합니다. 최종 목적지에서 데이터가 생성됩니다.
Collector는 프로덕션 관측성 인프라의 가장 중요한 구성 요소입니다. 이것이 없으면 각 애플리케이션은 백엔드에 대한 직접 연결을 알고 관리해야 합니다. 백엔드 변경, 중간 처리 추가, 시나리오 관리가 어려워집니다. 장애 조치. Collector를 사용하면 중앙 집중식 내보내기 구성 및 애플리케이션 수집기에 접근하는 방법만 알면 됩니다.
이 기사에서 배울 내용
- Collector의 내부 아키텍처: 수신기, 프로세서, 내보내기
- YAML을 사용하여 수집기를 구성하는 방법
- 가장 중요한 프로세서: 배치, 필터, 속성, tail_sampling
- 배포 패턴: 에이전트, 게이트웨이 및 사이드카
- 수집기 확장 및 고가용성
- Collector 자체 모니터링(메타 관찰 가능성)
수집기 아키텍처
Collector에는 세 가지 유형의 구성 요소로 구성된 파이프라인 아키텍처가 있습니다. 통해 파이프라인 각 신호 유형(추적, 측정항목, 로그)에 대해 구성 가능:
수집기 파이프라인
수신기 (입력) → 프로세서 (변신) →
수출업체 (출구)
파이프라인에는 여러 수신기(여러 소스에서 수집), 프로세서 체인이 있을 수 있습니다.
(필터, 강화, 샘플) 및 여러 내보내기(동시에 여러 백엔드로 보내기).
수신기: 진입점
I 수신기 이는 Collector의 진입점입니다. 원격 측정 데이터를 허용합니다. 다양한 소스에서 내부 Otel 형식으로 변환합니다. 가장 일반적인 수신기는 OTLP 수신기이며, 그러나 Collector는 다양한 프로토콜과 소스에 대해 수십 개의 수신기를 지원합니다.
프로세서: 데이터 변환
I 프로세서 수신과 내보내기 사이에 데이터를 수정합니다. 그들은 할 수 있다 원격 측정 신호를 필터링, 강화, 샘플링, 그룹화 및 변환합니다. 파이프라인에서 프로세서의 순서는 중요합니다. 즉, 순차적으로 실행됩니다.
내보내기: 데이터 대상
그만큼 수출업체 처리된 데이터를 최종 목적지인 백엔드로 보냅니다. 저장, 보기 서비스 또는 기타 수집가. 파이프라인에는 여러 내보내기가 있을 수 있습니다. 동일한 데이터를 동시에 다른 목적지로 전송합니다.
완전한 수집기 구성
Collector는 수신기, 프로세서, 내보내기 및 내보내기를 정의하는 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"
배포 패턴
Collector는 각각 장점과 장단점이 있는 세 가지 주요 패턴으로 배포할 수 있습니다. 구체적. 프로덕션 환경에서는 여러 패턴이 결합되는 경우가 많습니다.
1. 에이전트 모드(DaemonSet)
각 클러스터 노드의 Collector 인스턴스(Kubernetes의 DaemonSet) 모든 애플리케이션 노드에서는 localhost를 통해 로컬 수집기에 원격 분석을 보내 네트워크 대기 시간을 최소화합니다. 에이전트는 간단한 전처리(일괄 처리, 필터링)를 수행하고 게이트웨이로 전달합니다.
2. 게이트웨이 모드(배포)
에이전트로부터 또는 에이전트로부터 직접 원격 측정을 수신하는 중앙 집중식 수집기 풀 응용 프로그램. 게이트웨이는 대량 처리(테일 샘플링, 집계)를 수행하고 관리합니다. 백엔드로 내보냅니다. 원격 측정 볼륨을 기준으로 수평으로 확장합니다.
3. 사이드카 모드
포드당 하나의 Collector 인스턴스가 사이드카 컨테이너로 배포됩니다. 격리를 제공합니다. 애플리케이션 전반에 걸쳐 포괄적이며 서비스별 구성이 가능합니다. 그리고 패턴 리소스 측면에서는 가장 비싸지만 가장 유연합니다.
# 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
배포 패턴 비교
| 패턴 | 자원 | 숨어 있음 | 격리 | 일반적인 사용 |
|---|---|---|---|---|
| 대리인 | 낮음(노드당) | 최소(로컬호스트) | 노드별 | 전처리, 버퍼링 |
| 게이트웨이 | 중간-높음(풀) | 미디어(네트워크) | 중앙 집중식 | 테일 샘플링, 집계 |
| 사이드카 | 높음(포드당) | 최소(로컬호스트) | 서비스를 위해 | 특정 구성, 격리 |
메타 관찰 가능성: 수집기 모니터링
Collector는 인프라의 중요한 구성 요소입니다. 작동이 멈추면 잃게 됩니다 전체 시스템에 대한 가시성. 이러한 이유로 Collector 자체를 모니터링하는 것이 중요합니다. Otel Collector는 폐기할 수 있는 전용 엔드포인트에 내부 측정항목을 노출합니다. 프로메테우스에서.
모니터링할 키 수집기 측정항목
- otelcol_receiver_accepted_spans: 성공적으로 수신된 스팬(입력 처리량)
- otelcol_receiver_refused_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는 관찰성 인프라를 위한 핵심 아키텍처 구성 요소입니다. 확장 가능하고 유지 관리가 가능합니다. 파이프라인 아키텍처(수신자, 프로세서, 내보내기) 데이터 필터링부터 원격 측정 데이터 관리에 있어 완전한 유연성을 제공합니다. 여러 백엔드로의 라우팅에 민감합니다.
배포 패턴(에이전트, 게이트웨이, 사이드카) 선택은 특정 요구 사항에 따라 다릅니다. 조직의. 프로덕션에서 가장 일반적인 패턴은 Agent(DaemonSet)를 결합한 것입니다. 중앙 집중식 처리 및 내보내기를 위한 로컬 전처리 및 게이트웨이(배포).
다음 기사에서는백엔드와의 통합: 구성 방법 추적을 위한 Jaeger, 메트릭을 위한 Prometheus, 시각화 대시보드를 위한 Grafana, 완전하고 기능적인 관찰 가능성 스택을 생성합니다.