•
텔레메트리 데이터 수집 아키텍처에는 다음과 같은 구성요소가 존재함.
◦
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) 문제를 심화시키고, 통합 관측성 구현을 위한 운영 복잡도를 크게 증가시킴.
◦
OTEL을 사용하지 않는 경우 
에 ?가 있음.
에 ?가 있음.◦
OpenTelemetry는 데이터가 수집되는 시점부터 로그, 메트릭, 트레이스 간의 상관관계를 유지함(Correlate). 예를 들어, 특정 API 호출에 대한 트레이스와 그 호출 과정에서 발생한 로그, 관련 메트릭을 동일한 컨텍스트 ID로 연결할 수 있음.
◦
OpenTelemetry는 수집 단계에서 데이터를 표준화하므로, 모든 백엔드 시스템에 일관된 형식으로 데이터가 전달됨. 데이터가 표준화된 형식으로 수집되면 저장소를 나중에 변경하더라도 수집 코드를 수정할 필요가 없음.
•
OTEL이 하는 일
parse me : 언젠가 이 글에 쓰이면 좋을 것 같은 재료을 보관해 두는 영역입니다.
1.
None
from : 과거의 어떤 원자적 생각이 이 생각을 만들었는지 연결하고 설명합니다.
supplementary : 어떤 새로운 생각이 이 문서에 작성된 생각을 뒷받침하는지 연결합니다.
1.
None
opposite : 어떤 새로운 생각이 이 문서에 작성된 생각과 대조되는지 연결합니다.
1.
None
to : 이 문서에 작성된 생각이 어떤 생각으로 발전되거나 이어지는지를 작성하는 영역입니다.
1.
None
ref : 생각에 참고한 자료입니다.
1.
None