Back to Blog
OpenTelemetryObservabilityOTLPCNCFDistributed Tracing

0x01. OpenTelemetry 개요 - 벤더 락인 없이 분산 시스템을 관측하는 표준

Traces, Metrics, Logs를 하나의 프레임워크로 통합하는 OpenTelemetry의 핵심 개념과 아키텍처를 정리한다.

마이크로서비스 아키텍처에서 장애가 발생하면 가장 먼저 마주하는 질문이 있다. "어떤 서비스에서 문제가 생겼는가?" 서비스가 5개일 때는 로그를 하나씩 뒤져도 되지만, 50개, 500개가 되면 불가능하다. 분산 추적(Distributed Tracing), 메트릭(Metrics), 로그(Logs)를 체계적으로 수집해야 하는데, 각 도구마다 계측 방식이 다르면 벤더 락인에 빠진다.

OpenTelemetry(OTel)는 이 문제를 해결하는 벤더 중립적 관측성(Observability) 프레임워크이다. 계측 코드를 한 번 작성하면 Jaeger, Prometheus, Datadog, Grafana 등 어떤 백엔드로든 데이터를 보낼 수 있다. CNCF graduated 프로젝트로, Grafana Labs 설문 기준 71%의 관측성 사용자가 OTel을 활용하고 있다.

OTel이란 무엇인가

OpenTelemetry는 텔레메트리 데이터의 생성·수집·전송을 표준화하는 프레임워크이다. 핵심은 세 가지 구성 요소이다:

  • SDK: 애플리케이션에 내장. 텔레메트리 데이터를 생성
  • Collector: 중앙 허브. 데이터를 수집하고 가공한 뒤 백엔드로 전송
  • OTLP(OpenTelemetry Protocol): SDK와 Collector 간 표준 통신 프로토콜 (gRPC/HTTP)

OTel이 아닌 것

OpenTelemetry는 관측성 백엔드가 아니다. 데이터를 저장하거나 시각화하지 않는다. 수집과 전송만 담당하고, 나머지는 백엔드의 역할이다.

역할도구
계측 & 수집OpenTelemetry
Traces 저장/시각화Jaeger, Grafana Tempo, Zipkin
Metrics 저장/알림Prometheus, Grafana Mimir
Logs 저장/검색Elasticsearch, Grafana Loki
올인원Datadog, New Relic, Splunk

이 분리가 OTel의 핵심 가치이다. 계측 코드를 건드리지 않고 백엔드를 교체할 수 있다. Datadog에서 Grafana 스택으로 바꾸고 싶으면? Collector 설정만 변경하면 된다.

왜 OTel인가

  • 벤더 락인 방지: 계측 코드를 한 번 작성하면 백엔드를 자유롭게 교체
  • 표준화: W3C Trace Context, OTLP 등 업계 표준 프로토콜
  • 3가지 신호 통합: Traces + Metrics + Logs를 하나의 프레임워크로 수집하고, 상관관계(correlation) 분석
  • 광범위한 언어 지원: Java, Python, Go, JavaScript, .NET, Rust 등
  • 거대한 생태계: CNCF graduated, Kubernetes 다음으로 활발한 CNCF 프로젝트

세 가지 신호 미리보기

OTel은 세 가지 텔레메트리 신호(Signal)를 정의한다:

Traces (분산 추적)

요청이 분산 시스템을 통과하는 전체 경로를 추적한다. Trace는 여러 Span의 집합이다.

Trace (trace_id: abc123)
├── Span A: "HTTP GET /api/orders"     (Root Span)
│   ├── Span B: "DB Query: SELECT..."  (Child Span)
│   └── Span C: "HTTP POST /payment"   (Child Span)
│       └── Span D: "Process Payment"  (Grandchild Span)

Metrics (지표)

시간에 따른 수치 측정값을 기록한다. Counter(총 요청 수), Histogram(응답 시간 분포), Gauge(CPU 사용률) 등의 Instrument로 구성된다.

Logs (로그)

기존 로깅 라이브러리를 그대로 사용하면서, 자동 계측이 활성화되면 로그에 trace_id와 span_id를 자동 주입한다. "이 에러 로그가 어떤 요청에서 발생했는지" 바로 추적할 수 있다.

세 신호의 상관관계

세 신호는 Context Propagation을 통해 서로 연결된다:

  • Traces ↔ Logs: Trace ID로 연결
  • Traces ↔ Metrics: Exemplar로 연결 — Metric 데이터 포인트에 Trace ID를 첨부
  • Logs ↔ Metrics: 시간대로 상관관계

시리즈 안내

이 시리즈에서는 OpenTelemetry의 핵심 개념을 정리한다:

  1. 개요 — OTel의 철학, 아키텍처, 세 가지 신호 (이 글)
  2. Signals & Instrumentation — Traces, Metrics, Logs 심화 + 자동/수동 계측
  3. Collector & Context Propagation — 파이프라인 구성과 분산 추적의 핵심 메커니즘

OpenTelemetry 시리즈3편