IT/모니터링

PromQL의 rate()랑 irate(), 언제 뭘 쓸지 헷갈릴 때

gfrog 2026. 7. 5. 12:12
SMALL

PromQL의 rate()랑 irate(), 언제 뭘 쓰는지 헷갈릴 때

오늘 알림 룰 리뷰하다가 팀 주니어가 물어봤다. "이거 왜 rate() 썼어요? irate()가 더 최신 값 반영하는 거 아닌가요?" 아, 이거 은근히 헷갈려하는 사람 많더라. 짧게 정리한다.

한 줄 요약

대시보드와 알림에는 대부분 rate(). irate()는 진짜 필요할 때만.

왜 그런지

rate([5m])은 5분 범위 안의 첫 샘플과 마지막 샘플을 보고 초당 증가율의 평균을 낸다. 값이 부드럽다. 짧은 스파이크 하나가 튀어도 완만해진다.

반면 irate([5m])은 범위 안의 가장 최근 두 샘플만 본다. 5분 범위를 줘도 실제로는 마지막 두 점만 쓴다는 얘기다. 그래서 반응은 빠른데 그래프가 지글지글하다.

문제는 알림 룰에서 이걸 잘못 쓰면 이런 일이 벌어진다. HTTP 5xx 카운터가 잠깐 두 샘플 사이에서만 튀었다가 다음 스크레이프에서 정상으로 돌아오면, irate()는 순간 확 뛰었다가 바로 사라진다. FOR: 5m 조건이 리셋된다. 알림이 안 온다. 근데 사용자는 이미 500 봤다. 이런 상황 몇 번 겪으면 그냥 rate() 쓰게 된다.

그럼 irate()는 언제

두 가지 경우에만 쓴다.

첫째, 초 단위로 값이 확확 바뀌는 카운터를 디버깅 목적으로 그래프로 볼 때. 예를 들어 특정 API 엔드포인트의 요청량이 순간적으로 어떻게 움직였는지 보고 싶을 때. 이때는 노이즈가 오히려 정보다.

둘째, 스크레이프 간격이 매우 짧고(예: 5초) 값의 변화가 실시간에 가까운 게 중요할 때.

이 두 경우 다 알림에는 안 어울린다. 알림은 안정적으로 지속되는 이상을 잡아야지 순간 파이크에 반응하면 페이저가 미쳐 날뛴다.

놓치기 쉬운 함정

sum(irate(http_requests_total[5m])) 이거 하지 마라. 반드시 순서가 이래야 한다:

sum(irate(http_requests_total[5m])) by (service)

그리고 이것보다 더 중요한 건, irate()를 먼저 계산하고 sum()으로 감싸야 한다는 점. 만약 aggregation을 먼저 하고 irate()를 씌우면 컨테이너 재시작 같은 카운터 리셋을 감지 못한다. 아래처럼 쓰면 안 됨:

# 이거 잘못됨
irate(sum(http_requests_total) by (service) [5m:])

정상 형태:

sum by (service) (irate(http_requests_total[5m]))

그래서 결론

대시보드 만들 때, 알림 룰 짤 때 별생각 없으면 rate(). 90%는 이걸로 커버된다. irate()는 특정 순간 값의 움직임을 자세히 뜯어볼 필요가 있을 때만 조심스럽게 쓴다.

혹시 이거 말고 increase()랑도 헷갈리는 분 있으면, increase(x[5m])은 그냥 rate(x[5m]) * 300이라고 생각하면 된다. 초당이 아니라 5분 총량으로 보고 싶을 때 쓰는 것. 내부적으론 rate랑 같다.

BIG