현대적인 Production 서버 운영에서는 하나의 Monitoring 도구만으로 전체 시스템을 분석하기 어렵습니다.
서비스 규모가 커지면 다음 세 가지 데이터가 필요합니다.
Metrics:
CPU
Memory
Request 수
LatencyLogs:
Error 기록
Application 이벤트
접속 기록Tracing:
사용자 요청 흐름
Service 이동 경로기존에는 각각 다른 시스템을 사용했습니다.
Prometheus
↓
Metrics
Loki / ELK
↓
Logs
Jaeger
↓
Tracing문제:
- 데이터가 분리됨
- 장애 분석 과정 복잡
- 서비스 흐름 확인 어려움
이를 해결하기 위한 기술이 OpenTelemetry입니다.
구조:
Application
↓
OpenTelemetry
↓
Metrics
Logs
Traces
↓
Observability Platform이번 글에서는 Docker Compose 환경에서 OpenTelemetry 구조, Collector 구성, Prometheus·Loki·Jaeger 연동, 통합 Observability 운영 방법까지 알아보겠습니다.
OpenTelemetry란 무엇인가?
OpenTelemetry는 Application에서 발생하는 Observability 데이터를 수집하기 위한 표준 기술입니다.
지원 데이터:
- Metrics
- Logs
- Traces
구조:
Application
↓
OpenTelemetry SDK
↓
Collector
↓
Backend SystemBackend 예:
- Prometheus
- Loki
- Jaeger
- Elasticsearch
기존 Monitoring 구조의 문제점
기존:
Application
↓
각각 Agent
↓
Metrics System
Logs System
Tracing System문제:
- 관리 복잡
- 설정 중복
- 데이터 연결 어려움
OpenTelemetry:
Application
↓
하나의 Collector
↓
여러 BackendDocker Compose OpenTelemetry 구조
기본 구조:
Application Container
↓
OpenTelemetry Collector
↓
-----------------
Prometheus
Loki
Jaeger
-----------------Collector가 중간에서 데이터를 처리합니다.
OpenTelemetry 주요 구성 요소
SDK
Application 내부에서 데이터를 생성합니다.
예:
API 요청
↓
Trace 생성Collector
데이터 수집 및 변환 담당
역할:
- Receive
- Process
- Export
Exporter
데이터 전달
예:
Trace
↓
JaegerMetrics
↓
PrometheusDocker Compose OpenTelemetry Collector 구성
docker-compose.yml:
services:
otel-collector:
image: otel/opentelemetry-collector
ports:
- "4317:4317"
- "4318:4318"실행:
docker compose up -d확인:
docker psOpenTelemetry Collector 설정
otel-config.yml:
receivers:
otlp:
protocols:
grpc:
http:
exporters:
logging:
service:
pipelines:
traces:
receivers:
- otlp
exporters:
- logging구조:
Application
↓
OTLP
↓
Collector
↓
BackendOpenTelemetry Metrics 연결
Metrics 흐름:
Application
↓
OpenTelemetry
↓
Collector
↓
Prometheus수집:
- Request Count
- Response Time
- Error Rate
- Resource Usage
OpenTelemetry Logs 연결
Logs 흐름:
Application Log
↓
Collector
↓
Loki / Elasticsearch장점:
- Log 형식 통일
- 중앙 관리
- 검색 가능
OpenTelemetry Tracing 연결
Tracing:
User Request
↓
API Gateway
↓
Service A
↓
Service B
↓
DatabaseCollector:
Trace 데이터 전달
↓
JaegerDocker Compose OpenTelemetry와 Jaeger 연동
구조:
Application
↓
OpenTelemetry Collector
↓
Jaeger
↓
Trace 분석확인:
- Service 호출 순서
- 처리 시간
- 오류 위치
Docker Compose OpenTelemetry와 Prometheus 연동
구조:
Metrics
↓
Collector
↓
Prometheus
↓
Grafana활용:
- 서버 상태
- Application 성능
- Resource 분석
Docker Compose OpenTelemetry와 Loki 연동
구조:
Logs
↓
Collector
↓
Loki
↓
Grafana활용:
- Error 검색
- 장애 분석
- Log 추적
OpenTelemetry 기반 장애 분석 과정
장애:
API 응답 지연분석:
Metrics:
Latency 증가 확인Tracing:
Payment Service 5초 지연Logs:
Database Timeout결과:
원인 정확히 확인Docker Compose OpenTelemetry Production 구조
실제 운영:
User
↓
API Gateway
↓
Application
↓
OpenTelemetry Collector
↓
-------------------
Prometheus
Loki
Jaeger
-------------------
Grafana DashboardOpenTelemetry 장점
표준화
하나의 방식으로 데이터 관리
확장성
Backend 변경 가능
통합 분석
Metrics + Logs + Traces 연결
Cloud Native 지원
Kubernetes 환경으로 확장 가능
OpenTelemetry 운영 Best Practice
추천:
- Collector 중앙화
- Trace Sampling 설정
- 민감 데이터 제거
- Service Name 표준화
- Dashboard 연결
- Alert 연동
운영 흐름:
Application
↓
Telemetry 생성
↓
Collector 처리
↓
Storage 저장
↓
Dashboard 분석
↓
장애 대응자주 묻는 질문
OpenTelemetry와 Jaeger 차이는 무엇인가요?
OpenTelemetry는 데이터를 생성·수집하는 표준이고 Jaeger는 Trace 저장 및 분석 시스템입니다.
OpenTelemetry가 Prometheus를 대체하나요?
아닙니다.
Prometheus 같은 시스템과 연결하여 사용합니다.
작은 서버에도 필요한가요?
기본 Monitoring 이후 규모가 성장하면 적용하는 것이 좋습니다.
Docker Compose에서도 OpenTelemetry 사용 가능한가요?
가능합니다.
Collector를 Container로 운영할 수 있습니다.
마무리
Docker Compose OpenTelemetry 통합 운영은 Metrics, Logs, Traces를 하나의 Observability 구조로 연결하는 핵심 기술입니다.
최종 구조:
Application
↓
OpenTelemetry
↓
Collector
↓
Metrics
Logs
Traces
↓
Monitoring Platform대규모 서버 운영에서는 단순히 장애를 발견하는 것이 아니라 장애 원인을 빠르게 분석하는 구조가 중요합니다.
OpenTelemetry를 활용하면 Docker Compose 환경도 Cloud Native 수준의 Observability 구조로 확장할 수 있습니다.
다음 글에서는 서버 운영에서 중요한 영역인 Docker Compose 보안 모니터링 구축 방법을 알아보겠습니다.