day-log

지난주 화요일 새벽 2시 반쯤이었다. 온콜 알림이 왔고, Prometheus 인스턴스 두 대가 연달아 OOM으로 죽었다는 내용이었다. 눈을 비비고 노트북을 열었는데, Grafana는 이미 죽어 있었다. 데이터 소스가 죽었으니 당연한 일이었다. 그 다음 두 시간 반 동안 내가 겪은 얘기다.처음엔 그냥 재시작하면 될 줄 알았다당시 우리 스택은 이랬다. 노드 24대 EKS 클러스터, kube-prometheus-stack으로 배포한 Prometheus 두 대 HA 구성, 메모리 리소스 리밋은 각각 16GB. 평상시 series 개수는 대략 480만 정도. 리텐션 15일. remote_write로 장기 저장소에 밀어넣고 있었다.일단 재시작. WAL replay가 시작됐는데, 이게 도무지 끝나지가 않았다. 평소엔..

지난 화요일 오전, 한 사용자한테 문의가 들어왔다. "결제 콜백이 가끔 실패한다"고. PM이 슬랙에 던진 메시지였는데, 솔직히 그때까지 우리는 아무 알림도 못 받은 상태였다. SLO 대시보드를 켰다. 99.5% 목표인 가용성 SLI가 99.1%까지 떨어져 있었다. error budget이 이미 절반 가까이 타들어간 상태였다.근데 burn rate 알림은 조용했다. 한 번도 안 울렸다.우리가 깔아둔 알림 구성Google SRE 워크북에 나오는 multi-window multi-burn-rate 패턴 그대로였다. 페이지(긴급) 알림은 1시간 윈도우 + 5분 윈도우 둘 다 14.4배 burn rate를 넘기면 발사. 티켓(완만) 알림은 6시간 + 30분 윈도우에 6배 burn rate. 표준 구성이다.- al..

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

작년 이맘때쯤 우리 팀은 Prometheus 단일 인스턴스로 버티는 게 한계에 다다랐다. 노드 800대, 활성 시리즈 3천만개를 넘기면서 메모리는 80GB를 넘어가고, 재시작 시 WAL 리플레이에 20분이 걸렸다. 장기 저장도 필요했다. 그래서 VictoriaMetrics 클러스터와 Grafana Mimir 두 개를 PoC로 띄워서 6개월씩 돌려봤고, 결국 메인을 VictoriaMetrics로 갔다. 이 글은 그 1년치 의사결정 기록이다.근데 미리 말해두면, 이건 "VM이 무조건 좋다"는 글이 아니다. 우리 팀 상황에 VM이 맞았던 거지, 다른 팀은 Mimir가 더 나을 수 있다. 그 경계가 어디인지 정리해보려고 한다.리소스 사용량 차이가 진짜였다벤치마크 자료들이 "VM이 메모리 5배 효율"이라고 떠드는..

무슨 일이 벌어지는가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..

지난주 화요일 새벽 3시쯤이었다. 슬랙 oncall 채널에 "그라파나 대시보드 일부 패널이 No data로 뜬다"는 핑이 올라왔다. 자다가 받은 알림이라 멘탈이 좀 나간 상태에서 노트북을 열었는데, 진짜로 우리 결제 서비스 P99 레이턴시 그래프가 새벽 1시 47분부터 약 한 시간 동안 비어 있었다.문제는 Prometheus 자체는 멀쩡했다는 거다. up{} 메트릭도 정상이고 로컬 쿼리도 잘 됐다. 그런데 Thanos를 통해 보던 장기 보관 대시보드에서만 그 구간이 통째로 비어 있었다. 결론부터 말하면 remote_write 큐가 막혀서 WAL에서 읽기가 블록됐고, 그 사이에 들어온 샘플들이 일부 누락됐다. 이게 내가 새벽 4시까지 깨어 있었던 이유다.처음 의심한 것들 (다 틀렸음)가장 먼저 의심한 건 ..

배포 자동화는 다들 잘 해놨는데, 정작 "이 배포 잘 된 거 맞아?"를 판단하는 건 사람이 대시보드 보고 있다. 우리도 그랬다. ArgoCD가 알아서 sync까지는 해주는데, P99가 튀거나 에러율이 올라가면 누군가는 새벽에 깨서 롤백을 해야 했다.올해 초 Argo Rollouts을 본격적으로 도입했고, AnalysisTemplate으로 Prometheus 메트릭을 보고 자동 롤백까지 시키는 데까지 왔다. 이 글은 그동안 정리해둔 셋업 노트다. 처음 도입하는 팀이 보면 30분 안에 동작하는 canary는 만들 수 있게 썼다.왜 Rollout인가 (Deployment로는 안 되나)솔직히 Deployment + RollingUpdate로도 canary 비슷한 흉내는 낼 수 있다. 그런데 두 가지가 안 된다...

요즘 운영하는 클러스터에서 메트릭 카디널리티가 슬슬 부담스러워졌다. http_request_duration_seconds 하나만 봐도 le 버킷이 12개씩 붙고, 거기에 method/status/route 라벨까지 곱해지면 한 서비스가 5만 series를 우습게 넘긴다. 그래서 작년부터 native histogram 으로 옮기는 작업을 조금씩 해왔는데, v3.8 부터 stable 표기가 붙으면서 본격적으로 손을 댔다.이번 글은 "어떻게 켜는지"가 아니라 "왜 이게 그렇게 효율적인지"에 대한 이야기다. 사실 내부 구조를 모르고 켜면 ingester 메모리만 튀어서 한참 헤매게 된다.classic histogram 의 비효율은 어디서 오는가classic histogram 은 도구라기보다 관행에 가깝다. le..

오늘 알게 된 건데, 아니 정확히는 어제 새벽 4시쯤 깨달은 건데, absent() 알람을 그냥 쓰면 staleness 때문에 정말 중요한 순간에 침묵할 수 있다. 이거 모르는 분 꽤 많더라. 우리 팀도 6개월째 이 룰을 쓰고 있다가 한 번 데였다.무슨 일이 있었나배치 잡 하나가 죽었다. 정확히는 메트릭을 push하는 사이드카가 OOM으로 재시작되면서 job_last_success_timestamp 시리즈가 사라졌다. 알람 룰은 이렇게 생겼었다.- alert: BatchJobMissing expr: absent(job_last_success_timestamp{job="nightly-etl"}) for: 10m근데 안 울렸다. 왜냐, Prometheus 3.x부터(사실 2.x 후반부터지만) stalen..

지난 주말, 새벽 2시쯤 PagerDuty가 울렸다. central monitoring 클러스터의 Prometheus가 OOMKill로 재시작 루프를 돌고 있다는 알람이었다. 메모리 limit을 32Gi로 잡아둔 인스턴스인데, 이게 몇 분 만에 한계를 찍고 죽고 있었다. 멘탈이 좀 흔들렸다. 평소엔 14~16Gi 정도에서 안정적으로 돌던 녀석이었다.원인을 추적하다 보니 결국 remote_write 큐 동작에 대해 내가 잘못 알고 있었던 부분이 꽤 있었다. 이번 글은 그날 새벽 삽질의 기록이다.배경: 우리 팀의 metric pipeline우리는 Thanos 대신 Mimir로 1년 전쯤 옮겼고, 각 워크로드 클러스터의 Prometheus가 remote_write로 Mimir 게이트웨이에 메트릭을 밀어넣는 구..