텔레메트리 데이터 수집 아키텍처에는 다음과 같은 구성요소가 존재함.
- Agent
- 애플리케이션이나 서버에 직접 설치되어 동작하는 경량 프로세스.
- 로컬에서 데이터를 수집하고 일차적인 처리(필터링, 기본 변환 등)를 수행.
- 보통 단일 호스트나 애플리케이션에 국한된 정보만 처리.
- Collector
- 여러 에이전트나 데이터 소스로부터 데이터를 중앙에서 수집하는 역할.
- 더 복잡한 처리(집계, 샘플링, 변환 등)를 수행함.
- 여러 호스트나 애플리케이션의 데이터를 수집해 백엔드로 전달함.
- Exporter
- 프로메테우스 생태계에서 주로 사용되는 용어로, 특정 시스템이나 애플리케이션의 메트릭을 노출(expose)하는 역할을 함.
- 데이터를 수집하여 HTTP 엔드포인트로 노출시키고, 프로메테우스 서버가 이를 긁어가는(scrape) 방식으로 동작함.
- pull 모델.
- Forwarder
- 수집된 텔레메트리 데이터를 다양한 백엔드 시스템으로 능동적으로 전송(push)하는 역할을 함.
- 주로 로그나 이벤트 데이터에서 사용됨. 데이터 형식 변환을 처리함.
- push 모델.
- SDK(Software Development Kit)
- 애플리케이션 코드에 직접 통합되는 라이브러리.
- 개발자가 애플리케이션 내부에서 텔레메트리 데이터를 생성하고 내보내는 데 사용함.
- 독립적인 프로세스가 아닌, 애플리케이션과 동일한 프로세스 내에서 "인-프로세스 에이전트" 역할을 수행함.
도구에 따라 일부 구성요소가 포함되거나 포함되지 않을 수 있고, 경계가 모호할 수도 있음. 예를 들어,
- fluent-bit
- Fluent Bit는 SDK가 아닌 독립 프로세스(애플리케이션 코드에 삽입되는 코드 없음).
- 애플리케이션의 파일 출력이나 표준 출력을 Fluent Bit가 수집하고 백엔드로 전송하거나 노출함. 즉, Fluent Bit는 agent, collector, forwarder, exporter가 하나의 프로세스로 통합된 형태.
- 대규모 환경에서는 Fluent Bit를 agent로, Fluentd를 중앙 collector로 사용하는 아키텍처도 가능함(Fluent Bit는 Fluentd의 경량화 버전임).
- 데이터 흐름
- 애플리케이션(file/stdout) → [ Fluent Bit(agent) → forward/export ] → 백엔드
- 애플리케이션(file/stdout) → Fluent Bit(agent) → [ Fluentd(collector) → forward/export ] → 백엔드
- cAdvisor
- cAdvisor는 독립적인 컨테이너로 실행되면서 호스트 머신의 컨테이너 런타임(Docker, containerd 등)에 접근함. 컨테이너 런타임 API를 통해 직접 정보를 수집하므로, 각 컨테이너 내부에 별도의 agent가 없음.
- Prometheus 형식으로 노출하여 exporter의 역할을 가지고 있지만, 능동적으로 전송하는 forwarder의 역할을 가지고 있지는 않음.
- 데이터 흐름
- 컨테이너 런타임 → [ cAdvisor(collector) → export ] → 백엔드
- OpenTelemetry
- 애플리케이션 코드에 직접 통합되는 표준화된 SDK로, 로그, 메트릭, 트레이스를 수집하여 OpenTelemetry Collector로 전송함.
- 데이터 흐름
- 애플리케이션 + OTEL SDK(forward) → OTEL Collector → forward/export → 백엔드
- Loki
- Loki Client Libraries는백엔드 시스템(Loki)에서 직접 제공하는 SDK로, 애플리케이션에서 Loki로 로그를 직접 전송 가능함.
- Promtail은 Loki 생태계의 별도 에이전트로, 파일 기반 로그를 수집함.
- 데이터 흐름
- 애플리케이션 + Loki Client Libraries(forward) → Loki(백엔드)
- 애플리케이션(file) → [ Promptail → forward ] → Loki(백엔드)
도입배경
-
MSA 환경에서 문제가 발생했을 때, 로그만 보거나 메트릭만 보는 것으로는 원인을 파악하기 어려움. 통합된 컨텍스트에서 데이터를 수집하면 "이 특정 요청이 실패한 이유는 무엇인가?"라는 질문에 더 쉽게 답할 수 있음. → 하지만 과거에 사용되던 그라파나와 같은 일반적인 도구들의 경우, 서로 다른 데이터 소스에서 가져온 데이터 간의 연결을 만드는 것이 어려움.
-
MSA 환경이 더 널리 사용되며, 다양한 목적의 로그 수집기와 저마다의 데이터 파이프라인이 생겨남. → 이러한 도구 생태계의 다양화는 벤더 종속성(vendor lock-in) 문제를 심화시키고, 통합 관측성 구현을 위한 운영 복잡도를 크게 증가시킴.
-
이 문제는 OpenTelemetry 공식 문서에 있는 그림에 잘 표현되어 있음.
OTEL을 사용하지 않는 경우 ↔에
?가 있음. -
OpenTelemetry는 데이터가 수집되는 시점부터 로그, 메트릭, 트레이스 간의 상관관계를 유지함(Correlate). 예를 들어, 특정 API 호출에 대한 트레이스와 그 호출 과정에서 발생한 로그, 관련 메트릭을 동일한 컨텍스트 ID로 연결할 수 있음.
-
OpenTelemetry는 수집 단계에서 데이터를 표준화하므로, 모든 백엔드 시스템에 일관된 형식으로 데이터가 전달됨. 데이터가 표준화된 형식으로 수집되면 저장소를 나중에 변경하더라도 수집 코드를 수정할 필요가 없음.
OTEL이 하는 일
