Prometheus의 irate가 spike를 잡지 못하는 이유

• PromQL에서 per-second rate을 계산하는데 사용되는 rate와 irate
• irate은 [range] 동안의 spike를 잡고, rate은 이 spike들을 평균낸다는 오해가 존재
• irate은 마지막 두 data points의 per-second rate 만을 계산
• query_range의 각 query에서 보게될 마지막 두 data points가 어떤게 될건지는 start, end, step 파라미터에 의존함
  • 따라서, irate에 의존하는 대시보드는 zooming과 scrolling에 따라 크게 변함
• 급격하게 변하는 counter에서 irate로는 모든 spike를 잡기 어려움

• MetricsQL(PromQL과 대부분 호환되는 Query Language)에서는 이를 위해, rollup_rate 함수를 지원
• 이 함수는 인접한 각 data point들끼리의 rate을 구하고 이것의 min, avg, max를 반환
• 따라서 모든 spike가 일관되게 min과 max에 잡힐 수 있음
• 직접 대시보드에서 시각화해보면, rollup_rate(min) <= irate <= rollup_rate(max)를 만족하는 band를 볼 수 있음

• irate에 대한 또 하나의 오해는, rate 보다 빠르다는 것
• 아무래도 [range] interval 동안 주어진 data point들 중에서 마지막 두개만 봐서 그렇게 느끼는걸지도?
  • 하지만 실제로 Prometheus가 가장 많은 CPU time을 쓰는곳은 query_range API를 사용할때, [start...end] interval 동안의 data point들을 추출하는 것
  • 어떤 함수를 쓰는지는 크게 성능에 영향이 없음

블로그 글에서 설명이 안되어 있어서 추가하면, rollup_rate의 rollup="avg" 값을 쓰는것과, rate에 그냥 avg를 쓰는것에 대한 차이는 MetricsQL 개발자의 다른 답변에서 확인 가능합니다.