day-log

지난달 얘기다. SLO 도입한 지 반 년쯤 지났고, 이제 대시보드에 error budget 남은 % 뜨는 것도 익숙해질 무렵이었다. 그런데 정작 알림이 이상하게 울렸다. 새벽 2시에 페이지 오는데 실제로 보면 이미 회복돼 있고, 반대로 며칠에 걸쳐 조금씩 새는 장애는 누구도 눈치를 못 챘다. 팀 회고 때 한 명이 "우리 burn rate alert가 알림 역할을 못 하고 있는 것 같다"고 얘기했고, 그때부터 3주 동안 정말 여러 번 갈아엎었다.처음엔 그냥 5분 창이었다부끄러운 얘기지만, 처음 세팅한 알림은 "최근 5분 error rate가 SLO 임계값의 10배 넘으면 페이지" 정도였다. 이게 왜 문제인지는 세팅한 사람도 알고 있었을 텐데, 그냥 다들 바빠서 방치돼 있었다.문제는 두 가지였다.첫째, 트래..

세 함수, 한 줄 요약Prometheus 쓰다 보면 반드시 한 번은 헷갈리는 게 rate, increase, irate 세 함수다. 이거 모르는 분 꽤 많더라. 알림 튜닝하다가 값이 이상해서 파본 적이 있는데, 이번 기회에 정리해둔다.rate(x[5m]): 지정한 구간(5분) 동안의 초당 평균 증가율. 부드럽게 완만해진다.increase(x[5m]): 지정한 구간 동안의 총 증가량. 그냥 얼마 늘었냐.irate(x[5m]): 구간 내 마지막 두 샘플만 보고 계산한 순간 증가율. 뾰족하게 튄다.사실 내부적으로는 increase(x[5m])는 rate(x[5m]) * 300 이랑 같다. rate가 좀 더 근본이다.실무에서 언제 뭘 쓰나알림(Alerting)에는 무조건 rate. irate로 알림 걸면 순간 ..

문제 상황오늘 알게 된 건 아니고, 최근에 신규 팀원한테 알림 튜닝 인수인계하다가 "이 함수 처음 봐요"라는 말을 들었다. 생각해 보니 나도 예전에 absent()랑 헷갈려서 쓰다가 알람을 놓친 적이 있었다. 짧게 정리해 둔다.Prometheus 알림 대부분은 "값이 얼마 이상이면 발동"이다. 근데 실제 사고는 오히려 "메트릭 자체가 안 오는" 순간에 터진다. exporter 프로세스가 죽었거나, 파드가 재시작되면서 라벨이 살짝 바뀌었거나, scrape job이 config reload 때 조용히 빠졌거나.이럴 때 up == 0만 걸어두면 반쯤은 놓친다. up은 scrape target이 등록돼 있어야 값이 있는 거고, target이 아예 discovery에서 사라지면 up{job="X"} 시리즈 자체가..

며칠 전에 팀 신입한테 SLO 세팅을 맡겼는데, 결과물이 좀 아쉬웠다. Availability SLO 99.9% 걸어놓고 burn rate 알람을 하나만 만들어놨더라. 1시간 윈도우에 14.4x 넘으면 알람. 이거 흔한 실수라서 짧게 정리해둔다.왜 하나면 부족한가burn rate 알람 하나만 두면 두 가지 중 하나 문제가 무조건 생긴다.윈도우를 짧게 잡으면 (예: 5분/1시간) — 트래픽 스파이크 한 번에 알람을 뜬다. 새벽에 CDN이 잠깐 흔들려서 5분간 에러율 튀었다? 알람 온다. 근데 실제로는 15분 후에 자동 복구됐다. 오탐이다. 이런 게 반복되면 팀이 알람을 무시하기 시작한다.윈도우를 길게 잡으면 (예: 6시간/3일) — 진짜 큰 장애가 났는데 알람이 늦게 온다. 30분간 API가 완전히 죽어 ..

새벽에 burn rate 알람이 안 울렸다 — multiwindow SLO 알람 삽질 노트지난주 금요일, 정확히는 토요일 새벽 4시쯤에 한 통의 메시지로 잠에서 깼다. 새벽이라 페이저는 아니었다. 결제 팀 PL이 슬랙 DM으로 "혹시 새벽 2시 ~ 3시 사이에 결제 실패 폭주한 거 알고 있냐"고 물어본 게 시작이었다. 모니터링 알람은 한 통도 받지 못한 상태였다.대시보드를 켜보니 새벽 2시 12분부터 약 32분간 결제 API의 5xx 비율이 8%까지 튀었다가 자연 복구됐다. 우리 SLO는 가용성 99.9%, 즉 한 달에 약 43분의 에러 예산이 전부였다. 사실상 한 번의 사고로 한 달치를 다 태운 거다. 그런데 왜 burn rate 알람이 안 울렸지? 이날 알게 된 multiwindow burn rate..

무슨 일이 벌어지는가absent_over_time(up{job="api"}[5m]) 같은 알람 표현식은 "지정한 메트릭이 5분 동안 한 번도 안 보이면 1을 반환"한다. 그래서 잡 다운 감지용으로 흔히 쓴다. 근데 함정이 있다.Prometheus 프로세스가 막 기동했을 때, 아직 첫 스크레이프가 끝나지 않은 시점에서 이 표현식이 평가되면 어떻게 될까? 메트릭이 없으니까 그냥 1 이 나온다. 그리고 알람룰에 for 절이 없으면 그 즉시 firing.# 이렇게 쓰면 Prometheus 재시작할 때마다 알람 옴- alert: ApiDown expr: absent_over_time(up{job="api"}[5m]) labels: severity: critical룰 평가 주기가 보통 30초~1분이라, P..