OTel Collector 구성과 파이프라인

Collector가 왜 필요한가

앞 챕터들에서 애플리케이션이 직접 OTLP Exporter로 백엔드에 데이터를 내보냈다. 작은 서비스 하나라면 충분하지만, 실제 운영 환경에서는 세 가지 문제가 생긴다.

첫째, 벤더 결합. 앱 코드에서 Jaeger endpoint나 Datadog API 키를 직접 참조하면, 백엔드를 바꿀 때마다 코드를 고쳐야 한다.

둘째, 공통 처리의 중복. 서비스마다 민감한 속성을 제거하거나, 배치를 묶거나, 메모리 한도를 조절하는 코드를 각자 구현해야 한다.

셋째, 다중 백엔드 부채. 같은 트레이스를 Jaeger와 Tempo 두 곳에 동시에 보내려면, 앱 코드에 exporter를 두 개 달아야 한다.

OTel Collector는 이 세 문제를 해결하는 벤더 중립 텔레메트리 프록시다. 앱은 항상 표준 OTLP로 Collector에만 내보내고, Collector가 라우팅·변환·팬아웃을 담당한다.

핵심 컴포넌트 네 가지

Collector는 네 종류의 컴포넌트로 구성된다.

Connector는 Exporter이면서 동시에 Receiver 역할을 하는 특수 컴포넌트다. 한 파이프라인의 출구와 다른 파이프라인의 입구를 연결한다.

YAML 설정 전체 구조

Collector 설정은 크게 다섯 섹션으로 나뉜다.

# otelcol-config.yaml

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
  hostmetrics:
    collection_interval: 30s
    scrapers:
      cpu:
      memory:
      disk:

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 1800
    spike_limit_mib: 400
  resource:
    attributes:
      - key: deployment.environment
        value: production
        action: upsert
  attributes:
    actions:
      - key: http.user_agent
        action: delete          # 민감 정보 제거
  batch:
    timeout: 200ms
    send_batch_size: 1024

exporters:
  otlp:
    endpoint: tempo:4317
    tls:
      insecure: true
  prometheusremotewrite:
    endpoint: http://prometheus:9090/api/v1/write
  otlphttp/loki:
    endpoint: http://loki:3100/otlp

extensions:
  health_check:
    endpoint: 0.0.0.0:13133
  zpages:
    endpoint: 0.0.0.0:55679

service:
  extensions: [health_check, zpages]
  pipelines:
    traces:
      receivers:  [otlp]
      processors: [memory_limiter, resource, attributes, batch]
      exporters:  [otlp]
    metrics:
      receivers:  [otlp, hostmetrics]
      processors: [memory_limiter, resource, batch]
      exporters:  [prometheusremotewrite]
    logs:
      receivers:  [otlp]
      processors: [memory_limiter, resource, batch]
      exporters:  [otlphttp/loki]

컴포넌트를 정의해도, service.pipelines에 포함되지 않으면 활성화되지 않는다. 이 설계 덕분에 같은 컴포넌트를 여러 파이프라인에서 공유하거나, A/B 설정을 한 파일에 나란히 두고 pipelines에서 선택할 수 있다.

Connector: 두 파이프라인 연결하기

Connector는 두 파이프라인을 이어주는 특수 컴포넌트다. 한쪽 파이프라인의 Exporter로 동작하면서, 동시에 다른 파이프라인의 Receiver로도 동작한다.

가장 자주 쓰이는 예: span-to-metrics. 트레이스 파이프라인에서 요청 수·에러율·레이턴시 메트릭을 자동 생성해 메트릭 파이프라인으로 내보낸다.

connectors:
  spanmetrics:
    histogram:
      explicit:
        buckets: [5ms, 10ms, 25ms, 50ms, 100ms, 250ms, 500ms, 1s]
    dimensions:
      - name: http.method
      - name: http.status_code
    metrics_flush_interval: 15s

service:
  pipelines:
    traces:
      receivers:  [otlp]
      processors: [batch]
      exporters:  [otlp, spanmetrics]   # spanmetrics는 connector → exporter 역할

    metrics:
      receivers:  [otlp, spanmetrics]   # spanmetrics는 connector → receiver 역할
      processors: [batch]
      exporters:  [prometheusremotewrite]

forward connector는 한 파이프라인의 데이터를 다른 파이프라인으로 그대로 전달하는 가장 단순한 connector다.

배포 패턴

Collector는 세 가지 패턴으로 배포한다.

에이전트 모드 (DaemonSet)

노드마다 Collector 하나를 띄워 노드 로컬 데이터를 수집한다. hostmetrics, filelog, kubelet_stats receiver처럼 노드 파일시스템이나 kubelet에 직접 접근해야 하는 데이터를 다룰 때 필수다.

게이트웨이 모드 (Deployment)

중앙 집중형 Collector. 여러 에이전트나 앱에서 OTLP를 받아 처리·팬아웃한다. 수평 확장(HPA)이 가능하고, tail sampling처럼 전체 트레이스를 한 곳에서 봐야 하는 처리에 적합하다.

사이드카 모드

Pod마다 Collector 컨테이너를 붙인다. 레이턴시가 가장 낮지만, Pod 수만큼 Collector가 늘어나 리소스 낭비가 크다. 특수한 격리 요구사항이 없으면 DaemonSet을 우선한다.

핵심 Processor 정리

batch: 텔레메트리를 모아 한 번에 내보낸다. 기본 timeout: 200ms, send_batch_size: 1024. 프로덕션에서는 4096~8192, 5~10초로 늘리면 처리량이 올라간다.

memory_limiter: 메모리 사용량이 limit_mib를 넘으면 신규 데이터를 강제로 drop해 OOM을 막는다. 항상 processor 체인의 첫 번째에 배치한다.

attributes: 속성 추가(insert), 갱신(upsert), 삭제(delete), 해시화(hash)를 지원한다. 개인식별정보(PII)나 신용카드 번호를 해시화할 때 유용하다.

filter: OTTL(OpenTelemetry Transformation Language) 조건식으로 스팬·메트릭·로그를 drop하거나 유지한다. 헬스체크 트레이스 같은 노이즈를 걸러낸다.

resource: 스팬·메트릭·로그에 service.version, deployment.environment 같은 리소스 속성을 일괄 추가한다.

tail_sampling: 트레이스가 완성될 때까지 기다린 뒤 샘플링 여부를 결정한다. 에러·느린 트레이스는 100% 보존, 정상 트레이스는 10% 샘플링 같은 정책이 가능하다. 게이트웨이에서만 사용한다(전체 트레이스가 한 인스턴스에 모여야 함).

한 줄 정리

OTel Collector는 Receiver → Processor → Exporter 파이프라인으로 텔레메트리를 처리하고, service.pipelines에서 컴포넌트를 조합해 활성화한다. DaemonSet 에이전트와 Deployment 게이트웨이를 2계층으로 구성하는 패턴이 Kubernetes 표준 아키텍처다.

References

• https://opentelemetry.io/docs/collector/
• https://opentelemetry.io/docs/collector/architecture/
• https://opentelemetry.io/docs/collector/configuration/
• https://oneuptime.com/blog/post/2026-02-06-opentelemetry-collector-pipeline-receivers-processors-exporters/view
• https://signoz.io/blog/opentelemetry-collector-complete-guide/
• https://www.dash0.com/guides/opentelemetry-collector
• https://newrelic.com/blog/infrastructure-monitoring/opentelemetry-collector-deployment-modes-in-kubernetes
• https://www.groundcover.com/learn/kubernetes/opentelemetry-collector-kubernetes
• https://medium.com/@alokrahuldevocs/day-164-opentelemetry-collector-processors-the-control-layer-of-your-observability-pipeline-066cceeb82d8