Phase 6레슨 26
Observability (Logging, Metrics, Tracing)
Three Pillars — 시스템의 내부를 들여다보는 법
💡ELI5·
자동차 계기판과 Observability
Metrics = 계기판 (속도, 연료, 온도 — 시계열 수치) Logging = 블랙박스 (이벤트 기록 — 사고 분석) Tracing = 여정 추적 (출발→경유→도착, 어디서 막혔는지)
💡 비유 — 자동차. 계기판(Metrics)으로 현재 상태를 보고, 블랙박스(Logging)로 사고를 분석하고, 네비게이션 경로(Tracing)로 어디서 막혔는지 찾는다. 세 가지가 합쳐야 자동차(시스템)를 완전히 이해할 수 있다.
🔬Deep Dive·
Three Pillars
| 종류 | 특징 | 도구 | 질문 |
|---|---|---|---|
| Logging | 이벤트 기록, 구조화(JSON) | ELK, Loki, Fluentd | 무슨 일이 있었나? |
| Metrics | 시계열 수치, 집계, 알림 | Prometheus, Grafana | 얼마나 자주/느린가? |
| Tracing | 요청 경로, 분산 추적 | Jaeger, Zipkin, OTel | 어디서 지연되었나? |
🔬Deep Dive·
Metrics 유형
# Counter — 단조 증가
http_requests_total{method="GET", status="200"}
# Gauge — 증감 가능
active_connections{service="order"}
memory_usage_bytes{host="server-1"}
# Histogram — 분포 (버킷별 카운트)
http_request_duration_seconds_bucket{le="0.1"}
http_request_duration_seconds_bucket{le="0.5"}
http_request_duration_seconds_bucket{le="1.0"}
# p99 계산
histogram_quantile(0.99,
rate(http_request_duration_seconds_bucket[5m]))🔬Deep Dive·
구조화된 로깅
// 잘못된 로그 (검색 불가)
log("User 12345 ordered item 67890, total 50000 KRW")
// 구조화된 로그 (검색, 집계 가능)
{
"timestamp": "2026-09-02T10:30:00Z",
"level": "INFO",
"event": "order_created",
"userId": "12345",
"itemId": "67890",
"amount": 50000,
"currency": "KRW",
"traceId": "abc123", // Tracing과 연결
"service": "order-service"
}모든 로그에 traceId를 포함하면 로그와 트레이스를 연결할 수 있다. 이는 분산 시스템 디버깅의 핵심.
⚖️Trade-off·
Observability의 비용
| 이점 | 대가 |
|---|---|
| 장애 원인 빠른 파악 | 저장 비용 (로그, 메트릭) |
| 성능 병목 식별 | 수집 에이전트 오버헤드 |
| 용량 계획 (트렌드 분석) | 대시보드 구축/유지 시간 |
| SLO 측정 | 학습 곡선 (PromQL 등) |
❓ 체크포인트 질문
- 1.Observability와 Monitoring의 차이는?
- 2.Logging, Metrics, Tracing의 역할은?
- 3.로그 레벨(DEBUG, INFO, WARN, ERROR)을 남발하면 어떤 문제가?
- 4.Metrics에서 Counter, Gauge, Histogram의 차이는?
- 5.RED 메서드와 USE 메서드의 차이는?