day-log

VictoriaMetrics vs Mimir, 1년 굴려보고 뭘 쓸까

작년 이맘때쯤 우리 팀은 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 게이트웨이에 메트릭을 밀어넣는 구..

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일에 걸쳐 다 쓰는 속도..