day-log

세 함수, 한 줄 요약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"} 시리즈 자체가..

PromQL의 rate()랑 irate(), 언제 뭘 쓰는지 헷갈릴 때오늘 알림 룰 리뷰하다가 팀 주니어가 물어봤다. "이거 왜 rate() 썼어요? irate()가 더 최신 값 반영하는 거 아닌가요?" 아, 이거 은근히 헷갈려하는 사람 많더라. 짧게 정리한다.한 줄 요약대시보드와 알림에는 대부분 rate(). irate()는 진짜 필요할 때만.왜 그런지rate([5m])은 5분 범위 안의 첫 샘플과 마지막 샘플을 보고 초당 증가율의 평균을 낸다. 값이 부드럽다. 짧은 스파이크 하나가 튀어도 완만해진다.반면 irate([5m])은 범위 안의 가장 최근 두 샘플만 본다. 5분 범위를 줘도 실제로는 마지막 두 점만 쓴다는 얘기다. 그래서 반응은 빠른데 그래프가 지글지글하다.문제는 알림 룰에서 이걸 잘못 쓰면..

오늘 알게 된 건데, 이거 모르고 쓰는 분이 꽤 많더라. absent() 함수. Prometheus에서 "메트릭이 사라졌을 때" 알람 거는 그 함수 말이다.뭐가 문제냐면우리 팀이 최근에 배치 job 상태를 감시하려고 이런 룰을 넣었다.- alert: JobMetricMissing expr: absent(batch_job_last_success_timestamp) for: 5m문제는 이거다. 배치가 서버 2대에 떠 있고, 한쪽 서버만 죽었을 때 이 알람이 안 울린다. absent()는 "메트릭 전체가 사라졌을 때"만 1을 반환한다. 나머지 한 서버가 살아있으면 시리즈는 여전히 존재하니까 조용하다. 근데 우리는 인스턴스 단위로 놓치고 싶지 않았다.unless가 답인 경우이럴 땐 unless를 쓴다.- a..

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

요즘 운영하는 클러스터에서 메트릭 카디널리티가 슬슬 부담스러워졌다. 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..