관측 가능성(observability)은 세 가지 기둥 — 로그(logs), 지표(metrics), 트레이스(traces) — 에 기반하며, 목표는 직접 검사하기에는 너무 큰 시스템에 대해 "무엇이 잘못되었고 왜인가"에 답하는 것입니다. 대규모에서 전략은 상관관계(correlation), 샘플링, 비용에 관한 것입니다.
관측 가능성(observability)은 세 가지 기둥 — 로그(logs), 지표(metrics), 트레이스(traces) — 에 기반하며, 목표는 직접 검사하기에는 너무 큰 시스템에 대해 "무엇이 잘못되었고 왜인가"에 답하는 것입니다. 대규모에서 전략은 상관관계(correlation), 샘플링, 비용에 관한 것입니다.
| 기둥 | 답하는 것 | 도구 |
|---|
| 지표 | 무언가 잘못되었나?(비율, 지연) | Prometheus, Grafana |
| 트레이스 | 흐름의 어디에서? | OpenTelemetry, Jaeger |
| 로그 | 정확히 무슨 일이 있었나? | ELK, Loki |
지표 알림 ─▶ 트레이스가 느린 서비스를 정확히 짚음 ─▶ 로그가 원인을 설명
(넓음) (경로) (상세)
trace/correlation ID는 지표 레이블, 로그 라인, span을 관통해야 합니다. 그래야 이들 사이를 전환(pivot)할 수 있습니다.
로그 라인: level=error trace_id=abc123 service=payments msg="gateway timeout"
^^^^^^^^^^^^^^^ 동일한 id가 트레이스 + 지표에도 나타남
✓ 표준화: 모든 서비스에 OpenTelemetry
✓ 구조화된(JSON) 로그 사용 — grep만이 아니라 질의 가능
✓ 트레이스 샘플링(예: 모든 오류 + 성공의 1% 유지)으로 비용 제어
✓ SLO를 정의하고 잡음이 아니라 증상(지연/오류율)에 알림
✓ 대시보드에 RED/USE 방법(Rate, Errors, Duration)
모든 것을 100%로 로깅하는 것은 감당할 수 없고 신호를 묻어버립니다. 대신 샘플링하고, 구조화하고, SLO에 알림을 거세요.
수백 개의 서비스가 있으면 SSH로 들어가서 들여다볼 수 없습니다. 관측 가능성은 프로덕션 동작을 이해하는 유일한 방법입니다.
이기는 전략은 상관되고, 샘플링되며, SLO 주도적입니다. 텔레메트리 저장 비용으로 파산하거나 온콜을 잡음에 묻지 않으면서 실제 문제를 빠르게 드러냅니다.