day-log

SLO 알림 한 번 손봤다가 두 달을 끌었다. 이게 뭐 그리 복잡하다고. 처음엔 그렇게 생각했다.우리 팀은 작년 가을부터 핵심 API 다섯 개에 대해 SLO 기반 알림을 운영하고 있다. 가용성 99.9%, 레이턴시 P99 300ms 이하. 알림은 Prometheus + Alertmanager 조합. Google SRE Workbook에 나온 multi-window multi-burn-rate(MWMBR)를 그대로 베껴 쓰고 있었다. 처음엔 만족스러웠다. 그런데 올해 초부터 슬슬 문제가 보이기 시작했다.1차 시도: Workbook 그대로 베끼기처음 셋업할 때는 SRE Workbook 표를 그대로 옮겼다. 4개 티어, 각 티어마다 short/long 두 윈도우.- alert: HighErrorBudgetBu..

P99 레이턴시가 살짝 튀었다고 한밤중에 페이저가 울리는 경험, 다들 한 번쯤 해봤을 것 같다. 우리 팀도 작년에 SLO를 도입하고 단일 burn rate 알람으로 굴리다가 알람 피로도 때문에 결국 6개월 만에 갈아엎었다. 이번 글에서는 그때 갈아탔던 멀티 윈도우, 멀티 burn rate 방식의 셋업 가이드를 정리해본다. Google SRE workbook에 나온 것을 우리 팀 환경에 맞춰 변형한 버전이고, Prometheus 기반이라면 거의 그대로 쓸 수 있다.단일 burn rate가 왜 안 되냐먼저 단일 윈도우 알람이 왜 망가지는지부터 짚고 가자. SLO 99.9% 가용성을 가정해보자. 30일 기준 에러 버짓은 약 43분이다. burn rate가 1이면 에러 버짓을 정확히 30일에 걸쳐 다 쓰는 속도..

오늘 알게 된 건데, Prometheus 3.8에서 native histogram이 드디어 stable로 올라왔다. 나처럼 몇 년째 "언젠간 써봐야지" 하고 미뤄두신 분들 꽤 있을 것 같아서 짧게 정리해둔다.왜 지금이냐기존 classic histogram 써본 분들은 아마 버킷 설계에서 한 번쯤 멘붕 겪어봤을 거다. 레이턴시 분포가 어떻게 생겼는지도 모르고 le 버킷을 깎아야 하고, 세밀하게 하자니 카디널리티 폭발, 대충 하자니 P99가 거짓말을 한다. 이걸 수년째 "일단 이 정도면 됐지" 하면서 쓰고 있었다.Native histogram은 버킷 경계를 exponential하게 자동 생성한다. 즉 설정 한 줄로 버킷 설계가 끝난다. 거기에 Remote Write 2.0에서 native form 그대로 전..