이 발표 자료는 “분산 시스템 시대의 관측성을 위한 단 하나의 표준“이라는 강력한 메시지를 전달하며, OpenTelemetry, 특히 OpenTelemetry Collector가 클라우드 네이티브 환경에서 데이터 수집과 관측성(Observability)의 표준을 어떻게 제시하는지를 자세히 다루고 있습니다.

핵심 주제는 다음과 같습니다.

• OpenTelemetry의 중요성: 복잡한 분산 시스템에서 시스템의 동작을 이해하고 문제를 해결하기 위한 ‘관측성’의 필요성과, 이를 위한 단일 표준으로서 OpenTelemetry의 역할을 강조합니다.

• OpenTelemetry Collector의 역할과 구조: 분산 시스템에서 발생하는 다양한 텔레메트리(Telemetry) 데이터를 수집, 처리, 그리고 원하는 백엔드로 전송하는 OpenTelemetry Collector의 핵심 기능과 내부 구성 요소(Receivers, Processors, Exporters, Connectors)를 상세히 설명합니다.

• OpenTelemetry Collector의 배포와 활용: 다양한 환경과 요구사항에 맞춰 OpenTelemetry Collector를 배포하고 구성하는 방법, 그리고 이를 통해 실제 시스템의 관측성을 어떻게 확보할 수 있는지 구체적인 예시와 함께 제시합니다.

결론적으로, 이 자료의 핵심 메시지는 OpenTelemetry Collector가 분산 시스템의 관측성을 확보하는 데 있어 중앙 집중식의 효율적이고 유연한 데이터 파이프라인을 제공하는 핵심 컴포넌트라는 것입니다.

클라우드 네이티브로 전환하는 조직은 필연적으로 소스(여러 런타임과 언어), 신호(Log/Metric/Trace), 전송 프로토콜, 보안 요구, 백엔드의 다양성에 부딪힙니다. 이때 Collector는 다음의 이유로 “초기 아키텍처 결정”과 “장기 운영 안정화” 모두에 결정적인 도움을 줍니다.

• 표준화된 데이터 통로: OTLP/gRPC·HTTP를 기본으로, Prometheus·Jaeger 등 다양한 프로토콜을 리시버/익스포터 플러그인 형태로 흡수합니다. 이로써 벤더 락인 없이 다중 백엔드 동시 전송과 단계적 전환(예: 상용 APM→자체 스택)을 설계할 수 있습니다.

• 중앙 집약적 거버넌스: 게이트웨이 토폴로지에서 샘플링·마스킹·익명화·집계·스키마 표준화를 중앙에서 일괄 적용할 수 있어 보안·규제 환경(예: 공공·금융)에 유리합니다.

• 운영 단순화와 비용 통제: 배치(batch), 큐(queue)/재시도, 압축, 다운샘플링, 중복 제거 등 전송·저장 비용을 줄이는 정책을 Collector가 담당합니다. 백엔드 교체/증설 시에도 애플리케이션 변경을 최소화합니다.

• 쿠버네티스 친화성: DaemonSet(에이전트)과 Deployment(게이트웨이) 두 모델을 조합해 노드/파드 근접 수집 + 중앙 처리라는 이상적인 구조를 구현합니다.

장기적으로는 벤더 의존에서 아키텍처 의존으로 중심축을 이동시켜, 기술·비용 전략을 스스로 주도할 수 있게 됩니다

OpenTelemetry Collector가 왜 현대 분산 시스템에 필수적인 존재인지, 그리고 어떻게 비즈니스 가치를 창출하는지에 대한 깊이 있는 이해를 제공하므로, 클라우드 네이티브 시대의 관측성을 성공적으로 구현하고자 하는 모든 분들께 반드시 참고해야 할 자료라고 할 수 있습니다.

OpenTelemetry Collector는 모듈화된 아키텍처를 가지고 있으며, 크게 네 가지 주요 구성 요소(Receivers, Processors, Exporters, Connectors)로 이루어진 파이프라인을 통해 텔레메트리 데이터를 처리합니다. 각 구성 요소는 데이터 처리 흐름의 특정 단계를 담당합니다.

Receiver는 원격 측정 데이터를 수신하는 구성 요소입니다. 마치 항구의 접안 시설처럼, 다양한 소스에서 들어오는 데이터를 표준화된 OpenTelemetry 데이터 모델로 변환하여 Collector 내부로 가져오는 역할을 합니다. 예를 들어, OTLP(OpenTelemetry Protocol) Receiver는 OpenTelemetry 표준 프로토콜로 전송된 데이터를 받으며, Kafka Receiver는 Kafka 토픽에서 데이터를 소비합니다. 이 외에도 Prometheus, Jaeger, Zipkin 등 다양한 프로토콜이나 특정 서비스로부터 데이터를 수신할 수 있는 Receiver들이 존재합니다. Apache Web Server Receiver, Docker Stats Collector Receiver, Filelog Collector Receiver 등 환경에 특화된 여러 Receiver를 통해 광범위한 데이터 소스를 통합할 수 있습니다.

Processor는 Receiver를 통해 수신된 데이터를 처리하고 변형하는 구성 요소입니다. 데이터가 백엔드로 전송되기 전에 필요한 가공 작업을 수행하여 효율성과 유용성을 높입니다. 예를 들어, Batch Processor는 수신된 데이터를 일정량 또는 일정 시간 동안 모아서 한 번에 처리하여 네트워크 부하를 줄입니다. Attribute Processor는 데이터에 추가적인 메타데이터(속성)를 추가하거나 기존 속성을 수정, 삭제하는 데 사용됩니다. 필터링, 샘플링, 데이터 마스킹, 집계 등 다양한 처리 작업을 통해 데이터의 품질을 향상시키고, 필요한 정보만을 백엔드로 전송할 수 있습니다. Memory Limiter Processor, K8s Attribute Processor, Transform Processor 등은 복잡한 환경에서 데이터 처리를 최적화하는 데 기여합니다.

Exporter는 처리된 텔레메트리 데이터를 다른 위치, 즉 관측성 백엔드로 전송하는 구성 요소입니다. Receiver가 데이터를 수신하는 역할이라면, Exporter는 데이터를 외부로 내보내는 역할을 합니다. OTLP Exporter는 OpenTelemetry 표준 프로토콜을 사용하여 데이터를 전송하며, Prometheus Remote Write Exporter는 Prometheus 서버로 데이터를 보냅니다. 또한 Elasticsearch Exporter, Kafka Collector Exporter, Loki Exporter 등 다양한 백엔드 시스템에 맞춰 데이터를 전송할 수 있는 Exporter들이 존재합니다. 이를 통해 기업은 특정 벤더에 종속되지 않고 원하는 관측성 백엔드를 자유롭게 선택하고 유연하게 변경할 수 있습니다. Debug Exporter는 데이터를 콘솔에 출력하여 디버깅 목적으로 활용됩니다.

Connector는 서로 다른 파이프라인을 연결하여 원격 측정 데이터를 전달하는 역할을 합니다. 이 구성 요소는 OpenTelemetry Collector의 아키텍처를 더욱 유연하고 강력하게 만듭니다. 과거에는 Processor가 트레이스-스팬 정보를 메트릭으로 변환하는 기능까지 담당하거나, 복잡한 우회 방법(워크어라운드)을 통해 데이터를 다른 파이프라인으로 넘겨야 했습니다. 하지만 Connector의 도입으로 이러한 비효율적인 과정이 사라졌습니다. 예를 들어, Span Metrics Connector는 트레이스(Span) 데이터를 받아서 이를 메트릭으로 변환한 후, 메트릭 파이프라인으로 전달할 수 있습니다. 이를 통해 데이터 전송이 단순해지고 Processor의 부담이 줄어들어 전체적인 파이프라인의 효율성이 크게 향상됩니다. Count Connector, Service Graph Connector 등 9종류 이상의 Connector가 opentelemetry-collector-contrib 리포지토리에 존재하며, 데이터 파이프라인 간의 유연한 연결을 지원합니다.

이러한 구성 요소들은 config.yaml과 같은 YAML 파일을 통해 선언적으로 구성되며, 각 파이프라인(예: traces, metrics, logs)에 Receiver, Processor, Exporter를 지정하여 데이터 처리 흐름을 정의합니다.

OpenTelemetry Collector는 사용자의 다양한 환경과 요구사항을 충족시키기 위해 여러 배포판 형태로 제공됩니다. 각 배포판은 특정 목적에 최적화된 컴포넌트 조합을 포함하고 있습니다.

가장 기본적인 배포판으로, 필수적인 컴포넌트들만 포함합니다. 가볍고 최소한의 기능만을 필요로 하는 환경에 적합하며, 리소스 사용량이 적어 효율적인 운영이 가능합니다. 마치 최소한의 기능만 갖춘 운영체제처럼, 필요한 기능만 추가하여 커스터마이징의 기반이 됩니다.

Core 버전에 더해 다양한 커뮤니티 및 서드파티 기여 컴포넌트들을 포함하는 풀 옵션 배포판입니다. 이는 훨씬 더 많은 Receiver, Processor, Exporter 등을 포함하고 있어, 광범위한 데이터 소스와 백엔드 시스템을 지원합니다. 데모, 실험, 그리고 OpenTelemetry 초기 도입 시 다양한 기능을 시험해볼 때 주로 사용됩니다. 대부분의 시나리오에서 이 contrib 배포판이 유용하게 활용될 수 있습니다.

Kubernetes 환경 내 워크로드 모니터링에 최적화된 배포판입니다. 쿠버네티스 클러스터에서 동작하는 애플리케이션의 텔레메트리 데이터를 효과적으로 수집하고 처리하기 위한 특정 컴포넌트(예: Kubernetes Cluster Collector Receiver, K8s Attributes Processor 등)를 포함하고 있을 가능성이 높습니다. 쿠버네티스 환경의 특성을 고려하여 자원 관리 및 데이터 라우팅을 효율적으로 수행하도록 설계됩니다.

OTLP(OpenTelemetry Protocol) 전용 배포판으로, OTLP Receiver와 OTLP Exporter만을 포함하는 최소 구성입니다. OpenTelemetry 표준 프로토콜을 사용하여 데이터 수집 및 전송만을 수행하는 가장 기본적인 파이프라인이 필요한 경우에 적합합니다. OTLP는 OpenTelemetry 프로젝트의 핵심 프로토콜이므로, 이 배포판은 매우 일반적인 사용 사례에 대응합니다.

특정 기능(예: eBPF 기반 프로파일링)에 특화된 공식 배포판들이 존재할 수 있습니다. 이는 특정 기술 스택이나 관측성 요구사항에 맞춰 고성능의 특화된 기능을 제공합니다.

AWS, Datadog, Splunk와 같은 클라우드 벤더나 APM(Application Performance Management) 솔루션 제공업체들은 OpenTelemetry Collector를 기반으로 자사의 플랫폼에 최적화된 커스터마이징된 배포판을 제공하기도 합니다. 이들은 자사 서비스와의 통합을 강화하고, 사용자 경험을 개선하기 위한 추가 기능을 포함할 수 있습니다.

만약 위의 공식/비공식 배포판들이 여러분의 특정 요구사항을 충족시키지 못하는 경우, ocb (OpenTelemetry Collector Builder) 도구를 사용하여 자체 배포판을 빌드할 수 있습니다. 이는 필요한 Receiver, Processor, Exporter만을 선택적으로 포함하여 경량화된 Collector를 만들거나, 특정 기능을 추가하여 맞춤형 Collector를 구축할 수 있게 해줍니다.

OpenTelemetry Collector(이하 “Collector”)는 관측(Observability) 데이터를 “수집→정제→전송”하는 표준 파이프라인의 실행체이며, 벤더 종속 없이 다양한 백엔드로 데이터를 안정적으로 전달하는 플랫폼 중립적 데이터 계층이라는 점입니다.

Collector는 애플리케이션·플랫폼·인프라 전반에서 발생하는 Logs/ Metrics/ Traces(필요 시 Profiles) 신호를 리시버(Receiver)–프로세서(Processor)–익스포터(Exporter)로 구성된 파이프라인에 태워 가공하고, 보안·가용성·비용 관점에서 최적화된 한 지점(게이트웨이) 혹은 각 노드(에이전트)에서 다중 백엔드로 내보냅니다.

표준 전송 규격인 OTLP를 중심으로 동작하며, Collector 자체가 하나의 실행 파일(바이너리)로 제공되어 온·오프프레미스 어디서든 동일한 운영 모델을 취할 수 있습니다.