Prometheusの`irate`がスパイクを捉えられない理由

• PromQLで per-second rate を計算するために使われる rate と irate
• irate は [range] の間のスパイクを捉え、rate はそれらのスパイクを平均化するという誤解が存在
• irate は最後の 2 つの data points の per-second rate だけを計算する
• query_range の各 query で見ることになる最後の 2 つの data points が何になるかは、start、end、step パラメータに依存する
  • したがって、irate に依存するダッシュボードは zooming や scrolling によって大きく変化する
• 急激に変化する counter では、irate ではすべてのスパイクを捉えるのは難しい

---

• MetricsQL（PromQL と大半の互換性がある Query Language）ではこのために、rollup_rate 関数をサポートしている
• この関数は隣接する各 data point 同士の rate を求め、その min、avg、max を返す
• そのため、すべてのスパイクを一貫して min と max に捉えられる
• 実際にダッシュボードで可視化してみると、rollup_rate(min) <= irate <= rollup_rate(max) を満たす band を確認できる

---

• irate に関するもう 1 つの誤解は、rate より高速だということ
• おそらく [range] interval の間に与えられた data point のうち最後の 2 つだけを見るため、そのように感じるのかもしれない
  • しかし実際に Prometheus が最も多くの CPU time を使うのは、query_range API を使う際に [start...end] interval の data point を抽出する部分
  • どの関数を使うかは、性能に大きな影響はない

---

ブログ記事では説明されていないので補足すると、rollup_rate の rollup="avg" 値を使うことと、rate に単に avg を使うことの違いについては、MetricsQL 開発者による別の回答で確認できます。