OpenTelemetry Collector란? 파이프라인 구조와 설정 3요소 | Guance

OpenTelemetry Collector(OTel Collector)는 트레이스·메트릭·로그 같은 텔레메트리 데이터를 받아서(receivers), 가공하고(processors),보내는(exporters) 중간 기지입니다. 애플리케이션이 데이터를 만들면, Collector 가 그것을 모아 배치 처리·필터링·마스킹을 거쳐 하나 이상의 백엔드(관측성 플랫폼)로 보냅니다. OTel 자체는 데이터의 "만드는 법과 운반"만 정하고, 저장·조회는 백엔드의 몫이라는 점이 핵심입니다(전체 개념은 옵저버빌리티란?을 참고하세요).

왜 애플리케이션에서 바로 보내지 않을까

SDK 에서 백엔드로 직접 보낼 수도 있습니다. 그런데도 운영 환경에서는 Collector 를 사이에 두는 것이 표준입니다. 이유는 세 가지입니다.

배치와 재전송: 전송을 모아서 효율화하고, 장애 때는 큐잉으로 유실을 막습니다.
가공의 일원화: 개인정보 마스킹, 속성 추가·삭제, 샘플링을 Collector 설정 한곳에서 관리합니다.
멀티 전송(듀얼 라이트): 같은 데이터를 현행 백엔드와 검증 중인 새 백엔드에 동시에 보낼 수 있습니다. 마이그레이션 검증의 핵심 기법입니다.

파이프라인으로 이해하기 — 설정 3요소

Collector 설정은 세 요소와 그것을 잇는 파이프라인으로 이루어집니다.

관련 가이드APM 뜻: 애플리케이션 성능 모니터링의 원리와 실무

receivers: 데이터를 받는 입구. 표준은 OTLP(OTel 의 표준 프로토콜)이고, 그 외에도 다양한 형식을 받을 수 있습니다.
processors: 받은 데이터를 가공. 배치(batch)가 사실상 필수이고, 속성 수정·필터·메모리 제한 등이 있습니다.
exporters: 보내는 출구. 백엔드마다 exporter 를 두고, 하나의 파이프라인에서 여러 exporter 로 동시에 보낼 수 있습니다.

개념 예시(동작 구조를 보여 주기 위한 최소 형태):

receivers:
  otlp:                 # SDK 에서 OTLP 로 수신
    protocols:
      grpc:
      http:
processors:
  batch:                # 모아서 보냄 (유실·효율의 핵심)
exporters:
  otlphttp/backend_a: { endpoint: "https://a.example.com" }
  otlphttp/backend_b: { endpoint: "https://b.example.com" }  # 듀얼 라이트
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/backend_a, otlphttp/backend_b]

여기서 중요한 것은 파이프라인을 선언하지 않으면 데이터가 흐르지 않는다는 점입니다. receivers 와 exporters 를 정의만 하고 service.pipelines 에 연결하지 않는 실수가 "데이터가 안 보인다"의 대표 원인입니다. 실제 이행( Datadog 과의 듀얼 라이트 전체 YAML)은 영문판 Datadog to OpenTelemetry에 있습니다.

자주 겪는 문제 3가지

파이프라인 미선언: 위에서 본 대로, 정의만 하고 pipeline 에 안 넣으면 조용히 아무 일도 안 일어납니다.
포트 혼동: OTLP 는 gRPC 4317, HTTP 4318 이 기본입니다. exporter 의 엔드포인트가 백엔드가 기대하는 프로토콜·포트와 맞는지 확인하세요.
샘플링 이중 적용: SDK 와 Collector 양쪽에서 샘플링하면 의도보다 훨씬 적게 남습니다. 어느 한쪽에서만 결정하는 것이 안전합니다.

트레이스가 아예 안 보일 때의 7단계 점검표는 영문판 OpenTelemetry Not Showing Traces에 정리돼 있습니다.

도입 순서 — 작게 시작해서 키우기

대상을 좁혀 주요 거래 경로 1~2개에 자동 계측을 넣습니다.
Collector 를 OTLP 수신 → 현행 백엔드 전송 구성으로만 둡니다.
속성(서비스명·환경·버전)을 통일하고, 트래픽에 맞춰 샘플링을 정합니다.
필요하면 exporter 를 추가해 제2의 백엔드와 병행 가동하며 조회 품질을 맞춰 봅니다.

자주 묻는 질문

Q. OpenTelemetry Collector 는 무료인가요?
네, 규격과 구현은 오픈소스로 무료입니다. 비용이 드는 쪽은 데이터를 저장·조회하는 백엔드이며, 제품마다 과금 모델이 다릅니다(비교는 APM 뜻과 도구 선택 참조).

Q. Collector 를 꼭 써야 하나요?
소규모 검증이라면 SDK 에서 직접 보내도 됩니다. 운영 환경에서는 배치·마스킹·멀티 전송을 위해 Collector 를 끼우는 구성이 표준입니다.

Q. Jaeger 와는 무슨 관계인가요?
Collector 는 텔레메트리의 수집·운반(중간 기지), Jaeger 는 트레이스를 저장·보여 주는 백엔드(도착지)입니다. Collector 로 모아 Jaeger 로 보내는 조합이 일반적입니다.

Q. 이미 Datadog SDK(ddtrace)를 쓰고 있습니다.
백엔드를 바꾸고 싶다면 두 길이 있습니다. 계측을 OTel 로 옮기는 길(언어별 전환표는 Datadog to OpenTelemetry)과, ddtrace 호환 입력을 가진 백엔드로 보내는 목적지만 바꾸는 길입니다. 후자라면 재계측 없이 전환 비용을 낮출 수 있습니다.