[OTel] OpenTelemetry 개념과 전송방법

sky_maru·2025년 8월 17일
OpenTelemetrykafkaobservabilitytraces
0

OpenTelemetry

목록 보기
1/3

1. [OTel] OpenTelemetry 개념

1) OpenTelemetry 개념

image

공식 홈페이지의 정의:

  • OTel이라고도 하는 OpenTelemetry는 추적, 메트릭, 로그와 같은 원격 분석 (Telemetry) 데이터를 계측, 생성, 수집, 내보내기 위한 벤더 중립적인 오픈 소스 Observability 프레임워크(출처).
  • CNCF(Cloud Native Computing Foundation) 주관 오픈소스 Observability 표준 프레임워크로 사용중

2) Observability 개념

  • Observability는 시스템의 내부 상태를 외부에서 발생하는 데이터(로그·메트릭·트레이스)를 통해 얼마나 잘 이해할 수 있는지를 나타내는 개념
  • 단순 모니터링(Monitoring)은 "알람을 주는 것"에 초점
  • Observability는 문제 원인을 깊이 파악하고 근본 분석(RCA) 가능하게 하는 것을 목표로 함

2-1) Observability의 핵심 3요소 (Three Pillars)

1) Logs (로그)
정의:
시스템이나 애플리케이션에서 발생한 이벤트를 시간순으로 기록한 데이터
 특징:
사람이 읽기 쉬움 (텍스트 기반)
 JSON, Plain text 등 다양한 형식
디버깅, 장애 원인 파악에 필수
 예시:

  ```text
  2025-08-15 13:12:04 ERROR PaymentService: 결제 요청 실패 (Order ID: 12345)
  ```

2) Metrics (메트릭)
정의:
숫자로 측정 가능한 시계열 데이터(Time-series)
 특징:
성능 및 상태를 추세로 파악 가능
 CPU 사용량, 메모리 사용량, 요청 처리량, 에러율 등
보통 Prometheus, InfluxDB 같은 TSDB에 저장
 예시:

  ```
  cpu_usage{host="app-server-1"} 0.73
  request_latency_seconds{path="/api/login"} 0.245
  ```

3) Traces (트레이스)
정의
 하나의 요청이 시스템 내부의 여러 서비스·컴포넌트를 거치는 경로를 추적한 데이터
흔히 분산 트랜잭션이라 부르며, 요청 지연·실패 지점을 파악하는 핵심 단위
 특징
분산 시스템에서 지연 발생 위치 파악 가능
 Jaeger, Zipkin, Tempo 등에서 시각화 가능
- Trace의 구성 요소
(1) Trace
 전체 요청을 대표하는 고유 ID(Trace ID) 보유
여러 개의 Span으로 구성
 (2) Span
Trace를 구성하는 작업 단위
 시작/종료 시간을 기록하며 소요 시간 측정
부모-자식 관계를 통해 계층 구조 형성
 예시 구조:
Span A: “API 요청”
 Span A1: “DB 쿼리 실행”
* Span A2: “외부 인증 서버 호출”

-> 즉, OpenTelemetry는 이러한 Trace/Span을 활용해 Observability를 구현하는 핵심 수단

OpenTelemetry 목적

  • 특정 벤더에 종속되지 않는 표준화된 방식으로 Metrics, Logs, Traces를 하나의 표준 형식으로 수집, 레메트리 데이터를 다룰 수 있게 해주는 것이 핵심이자 목표
    -> 핵심은 서비스 간 호출의 흐름을 시각화하고, 병목 지점을 파악하는 것!

2. OpenTelemetry 주요 구성 요소

전체 구조

[Instrumentation] → [SDK/API] → [OTLP] → [Collector] → [Backend]
  • Specification: 전체 규칙/표준
  • API/SDK: 애플리케이션에서 Telemetry 생성
  • Instrumentation: 계측 방법 (자동/수동)
  • OTLP: 전송 규격
  • Collector: 데이터 수집·가공·전송 허브
  • Backend: 저장·시각화·분석

1) Specification (명세)

  • 개념: OpenTelemetry의 API, SDK, 데이터 형식, 전송 방식(프로토콜)에 대한 명세로, 데이터 형태와 통신에 대한 규격을 정의
  • 역할: 언어/환경에 상관없이 일관된 방식으로 Telemetry 데이터를 생성·처리·전송할 수 있도록 규정

2) Collector (OpenTelemetry Collector)

  • 개념: Telemetry 데이터를 수신 → 처리 → 내보내기 하는 독립 실행형 프로세스(Agent 또는 Gateway)

  • 구성 요소

    • Receiver: 다양한 소스(애플리케이션, 시스템, 다른 Collector)에서 데이터 수신
      • 지원 프로토콜: OTLP, Jaeger, Prometheus 등
    • Processor: 수신된 데이터 가공 (필터링, 샘플링, 배치 처리, 속성 추가/변경 등)
    • Exporter: 처리된 데이터를 최종 Backend(Jaeger, Prometheus, Zipkin 등)로 전송

  • 역할: 애플리케이션과 Backend 사이에서 데이터 수집·전송 허브 역할 수행

    • Backend 변경 시 Collector 설정만 수정하면 됨 → 애플리케이션 수정 불필요

    3) API (Application Programming Interface)

  • 개념: 개발자가 애플리케이션 코드에 계측(Instrumentation) 코드를 추가하여 텔레메트리 데이터를 생성할 수 있도록 하는 언어별 인터페이스

  • 역할

    • Tracer, Meter, Logger 등을 사용해 Trace / Metric / Log 생성 방법 정의
    • 벤더 중립적 → Backend 교체 시 코드 변경 불필요

4) OTel SDK(Software Development Kit)

  • 개념: OpenTelemetry API를 구현한 라이브러리
  • 역할
    • 실제 텔레메트리 데이터를 수집하고, 처리하며, 최종적으로 내보내는(export) 역할을 담당
    • 애플리케이션에 라이브러리 형태로 통합하여 사용(개발자가 코드에 직접 호출하여 Telemetry를 생성/전송 가능)
    • API에서 정의한 Telemetry 생성을 실제로 동작시키는 엔진 역할

5) OTLP (OpenTelemetry Protocol)

  • 개념: OpenTelemetry가 정의한 Telemetry 데이터 전송 표준 프로토콜
  • 역할
    • Trace, Metric, Log 데이터를 효율적으로 전송
    • OpenTelemetry 구성 요소(Collector, SDK, Backend 등) 간 호환성 보장

6) Instrumentation

  • 개념: 애플리케이션에 Telemetry 수집 기능을 삽입하는 작업
  • 종류
    • 수동 계측: API를 직접 호출해 데이터 생성
    • 자동 계측: 에이전트/라이브러리로 코드 수정 없이 계측
  • 역할: SDK/Agent를 통해 Telemetry 데이터(Trace, Metric, Log)를 자동 또는 수동으로 수집

7) Backend

  • 개념: 수집된 Telemetry 데이터를 저장·조회·분석하는 시스템
  • 예시: Jaeger(Trace), Prometheus(Metric), Grafana, Datadog, Tempo, Loki 등
  • 역할: 문제 분석, 성능 모니터링, 경고(Alerts) 발송 등 Observability 기능 제공

3. Sentry & Pinpoint와의 OpenTelemetry 연관성

1) Sentry

2) Pinpoint

4. OpenTelemetry 종류

  • OpenTelemetry에는 크게 두 종류
    1) OpenTelemetry Collector
  • 개념: Observability 데이터를 수집, 처리, 내보내는 기본 Collector
  • 용도: Trace, Metric, Log 수집/전송의 핵심 기능 제공

2) OpenTelemetry Contrib Collector

  • 개념: 기본 Collector 기능 + 추가 receiver, processor, exporter 제공
  • 특징: Kubernetes 관련 기능 등 확장 기능 지원-> 쿠버네티스와 관련된 receiver 및 processor를 사용하기 위해 OpenTelemetry Contrib Collector를 활용

5. Collector 배포 방식

  • OpenTelemetry Collector는 애플리케이션이 생성한 Telemetry 데이터를 수집·변환·전송하는 핵심 컴포넌트이며, 배포 방식에 따라 다음과 같이 나뉩니다.

1) Sidecar

  • 개념: 애플리케이션 Pod 내부에 별도 컨테이너로 Collector를 같이 배치
  • 장점: 해당 애플리케이션의 Telemetry 데이터를 바로 수집 가능 (네트워크 hop 최소화)
  • 단점: Pod마다 Collector를 띄우므로 리소스 사용량 증가
  • 예시: Kafka Producer/Consumer Pod에 Collector 사이드카를 추가해 내부 애플리케이션에서 발생하는 Span/Metric/Log를 직접 수집
  • 주의: Kafka Broker 자체에서는 Trace/Span을 만들지 않고, 오직 메시지를 전달만 함. → Kafka 대신, 이벤트를 처리하는 Kafka Producer/Consumer Pod에 Collector 사이드카를 추가해 내부 애플리케이션에서 발생하는 Span/Metric/Log를 직접 수집

2) DaemonSet

  • 개념: Kubernetes의 각 Node마다 Collector를 하나씩 띄워서, Node 내에서 모든 Pod의 데이터를 수집
  • *특징: Node 레벨에서 여러 Pod의 데이터를 수집 가능

3) Gateway

  • 개념: 중앙 집중형 Collector → 여러 애플리케이션/Collector에서 데이터를 받아 처리 후 Export
  • 장점: 처리 로직, 필터링, 데이터 변환을 중앙에서 통제 가능
  • 단점: 단일 장애점(SPOF) 가능성
  • 예시: 모든 Collector에서 게이트웨이로 전송 → 게이트웨이에서 Jaeger, Tempo, Kafka, Prometheus 등으로 Export

6. Sidecar Collector 필요한 구성 요소

1) cert-manager

  • 역할: OpenTelemetry Collector/Operator간 통신 시 TLS 인증서 발급/관리
  • 의미: Collector 간, Collector ↔ Exporter 간 mTLS(mutuual TLS) 환경을 구성할 때 필요

2) opentelemetry-operator

  • 역할: Kubernetes에서 OpenTelemetry Collector를 CRD(Custom Resource Definition) 기반으로 쉽게 배포·관리
  • 의미: YAML 작성 없이 Collector 설정, 사이드카 자동 삽입 등을 가능하게 함
  • 예시: 특정 Deployment에 자동으로 Collector 사이드카를 붙이는 기능 제공

3) opentelemetry-collector

  • 역할: 실제 Telemetry 데이터 수집·변환·전송을 수행하는 프로세스
  • 의미: Exporter, Processor, Receiver 등 파이프라인을 설정해 관측 데이터를 목적지로 전달
  • 예시: OTLP → Jaeger 변환, Kafka → Prometheus 변환 등

참고 문서

profile
sky_maru
긍정적으로 현실적이게
다음 포스트

2. OpenTelemetry 트레이스 발생 실습 (with Kafka )

0개의 댓글