PromQL rate() vs irate() — 평균 증가율과 순간 증가율
초당 요청 수를 대시보드에 걸려고 PromQL 함수를 찾으면 rate() 와 irate() 가 나란히 나옵니다.
인자도 똑같이 range vector 하나뿐이라 아무거나 넣어도 그래프는 그려집니다. 그런데 같은 지표에
걸어 놓고 보면 선 모양이 꽤 다릅니다.
애초에 왜 증가율을 구해야 하느냐면, Prometheus 가 요청 수나 에러 수를 Counter 로 저장하기 때문입니다. 계속 쌓이기만 하는 값이라 저장된 숫자는 “지금까지 누적 몇 건” 이고, 프로세스가 재시작되면 0 부터 다시 셉니다. 보고 싶은 건 누적이 아니라 초당 몇 건인지니까 증가율로 바꿔서 봅니다.
두 함수 다 그 초당 증가율을 주니 틀린 쪽이 있는 게 아니라, 값을 뽑는 방식이 달라서 선이 갈린 겁니다.
rate() — 범위 전체의 평균
지정한 시간 범위(range vector) 안의 평균 증가율을 냅니다.
rate(http_requests_total[5m])
# 5분간 평균 RPS
범위 안 첫 샘플과 마지막 샘플의 차이를 그 두 샘플 사이 시간으로 나누고, 범위 양끝까지는 그 기울기로 늘려서 채웁니다. 5분 사이에 늘어난 양을 5분에 걸쳐 고르게 펴니까, 잠깐 튄 구간이 있어도 희석돼서 선이 완만해집니다. 중간 샘플은 버리는 게 아니라 카운터가 재시작해 값이 줄어든 구간을 보정하는 데 쓰입니다.
irate() — 마지막 두 샘플의 순간값
같은 자리에 irate() 를 쓰면 범위 안의 샘플을 다 쓰지 않고 가장 최근 두 개만 봅니다.
irate(http_requests_total[5m])
# 가장 최근 두 샘플로 계산한 순간 RPS
여기 붙은 [5m] 은 평균을 낼 범위가 아니라, 어디까지 거슬러 올라가 마지막 두 샘플을 찾을지의
한계일 뿐입니다. 계산에 마지막 2개만 들어가는 만큼 순간 변화에 민감해지고, 잡음도 그대로 같이 올라옵니다.
선택 기준 — 알람은 rate, 실시간은 irate
| rate() | irate() | |
|---|---|---|
| 계산 | 범위 전체 평균 | 마지막 두 샘플 |
| spike 민감도 | 둔함 | 민감 |
| 노이즈 | 적음 | 많음 |
| 쓰는 곳 | 알람 룰, 추이 확인 | 실시간 대시보드 |
알람 룰에는 rate() 를 씁니다. 순간값으로 임계치를 걸면 튄 샘플 하나에 알람이 울렸고, 그런
알람이 몇 번 반복되면 사람이 아예 안 보게 됩니다. 평균이라 그만큼 안정적입니다.
반대로 지금 이 순간 튀는 걸 대시보드에서 봐야 하면 irate(). 대신 그래프가 지글거리는 건
감수해야 합니다.
범위가 너무 짧으면 no data
rate() 의 범위를 scrape interval 보다 짧게 잡으면 그 안에 샘플이 0~1개밖에 안 들어옵니다.
그러면 no data 가 나거나 값이 부정확해집니다. 증가율을 구하려면 범위 안에 최소 2개가 있어야 하고,
관행적으로는 여유를 둬서 scrape interval × 4 이상을 권합니다. scrape 가 15초면 최소 1분.
대시보드가 비어 보이는데 지표는 들어오고 있다면 이 범위부터 확인하면 됩니다. 값이 없는 게 아니라 계산할 샘플이 모자란 경우가 많아서입니다.
댓글 0