문제를 일찍 잡기 위해 monitoring과 observability를 어떻게 구축합니까?

Question

Accepted Answer

목표는 **사용자가 알려주기 전에 시스템이 비정상임을 아는 것**입니다. 좋은 observability는 고정된 dashboard 세트만 확인하는 게 아니라, 예상하지 못한 질문에도 답할 수 있게 해 줍니다. tech lead로서 이것을 장애 *중*이 아니라 그 *전*에 구축합니다.

## 세 가지 기둥

- **Metrics** — 저렴한 수치 시계열(request rate, error rate, latency, 큐 깊이). 추세, alerting, SLO에 훌륭합니다.
- **Logs** — *왜* 무언가 일어났는지를 알려주는 상세한 이벤트 기록입니다. **구조화**(JSON)하고 **correlation ID**를 붙여 하나의 request를 여러 service에 걸쳐 추적할 수 있게 하세요.
- **Traces** — 하나의 request가 여러 service를 거치는 경로로, 시간이 실제 어디서 소비되는지를 보여 줍니다. 분산 시스템에서 필수입니다.

## 증상에 alert하고, 노이즈에 alert하지 마라

내부 흔들림이 아니라 **사용자가 느끼는 것**에 대해 page를 울리세요. alert를 **SLO**에 고정하세요: error rate, latency(p95/p99), 가용성. CPU 급등은 장애가 아닙니다. 사용자 2%의 checkout 실패가 장애입니다.

| alert할 대상 | page하지 말 것 |
| --- | --- |
| SLO를 위반하는 error rate | 단일 CPU 급등 |
| budget을 초과한 p99 latency | 하나의 느린 request |
| 실패한 health check | Disk 60% |

## alert를 실행 가능하게 만들기

모든 alert는 **긴급하고, 실제이며, 실행 가능**해야 합니다 — 무엇이 잘못됐는지 명시하고 다음 단계를 가리킵니다. 아주 자주 울리는 alert는 팀이 무시하도록 훈련시킵니다. **alert fatigue**가 바로 실제 장애를 놓치는 방식입니다. golden signal을 한눈에 보여 주는 **health check**와 dashboard를 추가하세요.

## 왜 중요한가

장애 이후에만 관찰하는 팀은 눈을 감고 나는 셈입니다. 화난 고객으로부터 장애를 알게 되고 추측으로 debug합니다. observability에 미리 투자하면 새벽 3시의 미스터리가 5분짜리 진단으로 바뀌고, downtime을 줄이며, 팀이 불을 끄는 대신 ship할 수 있게 해줍니다.

alert할 대상	page하지 말 것
SLO를 위반하는 error rate	단일 CPU 급등
budget을 초과한 p99 latency	하나의 느린 request
실패한 health check	Disk 60%