관찰 가능성(Observability)
보이지 않는 것은 고칠 수 없습니다. 관찰 가능성은 사고 발생 후에 덧붙이는 것이 아니라 처음부터 설계에 포함되어야 합니다. 프로덕션에 대한 질문에 답하기 위해 코드 변경이 필요하다면, 계측이 잘못된 것입니다.
규칙
- 세 가지 기둥: 로그, 메트릭, 트레이스. 각각은 서로 다른 질문에 답합니다. — 무슨 일이 일어났는지(로그), 얼마나 자주 그리고 얼마나 많이(메트릭), 왜 느렸는지(트레이스). 세 가지 모두 필요합니다.
- 구조화된 로그만 사용. JSON(또는 유사한 형식). 규모가 커지면 grep은 전략이 아닙니다.
- 모든 로그 라인에 상관관계/트레이스 ID 포함. 서비스 경계를 넘어 헤더를 통해 전파하십시오. 하나의 ID가 전체 요청 여정을 연결합니다.
- 모든 엔드포인트에 RED 메트릭. Rate(요청률), Errors(오류율), Duration(지속 시간, P50/P95/P99 포함). 회귀를 발견하는 데 필요한 최소한의 지표입니다.
- 모든 리소스에 USE 메트릭. Utilization(사용률), Saturation(포화도), Errors(오류율) — CPU, 메모리, 풀, 대기열, 디스크, 네트워크에 대해.
- 모든 서비스 간 호출을 추적. OpenTelemetry를 사용하십시오. DB 쿼리와 캐시 히트도 스팬으로 캡처하십시오.
- SLO 기반으로 알림을 설정하고, 원시 메트릭으로 알리지 마십시오. "CPU > 80%"는 새벽 3시에 사람을 깨우는 데 아무 도움이 되지 않습니다. "P99 지연 시간이 5분 동안 SLO를 위반"은 실제 사용자 불편을 포착합니다.
- 헬스와 readiness는 다른 엔드포인트입니다.
/health= "살아 있습니다, 재시작하지 마세요."/ready= "지금 트래픽을 처리할 수 있습니다." 이렇게 취급하십시오. - 올바른 수준으로 로그를 남기고, 이벤트당 한 번만 로그하십시오.
INFO는 요청 수명 주기,WARN은 복구 가능한 문제,ERROR는 사람의 개입이 필요한 상황. 중복 로그는 대시보드를 거짓으로 만듭니다. - PII나 비밀 정보는 절대 로그하지 마십시오. 앱ender에서 마스킹하십시오. 호출자가 기억할 것이라고 신뢰하지 마십시오.
- 모든 알림은 runbook을 가리킵니다. 문서화된 조치가 없는 알림은 페이지인 척하는 Slack 알림에 불과합니다.
위험 신호(Red flags)
- 프로덕션을 디버깅하기 위해 포드에 SSH로 접속하는 행위.
- 정기적으로 발생하지만 무시되는 알림. (알림 피로는 안정성 문제입니다.)
- 컨텍스트, ID, 스택 트레이스 없이
"error occurred"라고만 쓰인 로그. - 백분위수 없이 평균만 보여주는 메트릭.
- 서비스별 대시보드는 있고, 사용자 여정별 대시보드는 없는 상황.