Warum `irate` von Prometheus Spikes nicht erfassen kann

• In PromQL werden rate und irate verwendet, um die per-second rate zu berechnen
• Es gibt das Missverständnis, dass irate Spikes innerhalb von [range] erfasst und rate diese Spikes nur mittelt
• irate berechnet nur die per-second rate der letzten beiden data points
• Welche letzten beiden data points bei jeder Query von query_range betrachtet werden, hängt von den Parametern start, end und step ab
  • Deshalb verändern sich Dashboards, die von irate abhängen, je nach Zooming und Scrolling stark
• Bei Countern mit starken Schwankungen ist es mit irate schwierig, alle Spikes zu erfassen

---

• Dafür unterstützt MetricsQL (eine Query Language, die größtenteils mit PromQL kompatibel ist) die Funktion rollup_rate
• Diese Funktion berechnet die Rate zwischen jeweils benachbarten data points und gibt deren min, avg und max zurück
• Dadurch können alle Spikes konsistent in min und max erfasst werden
• Wenn man das direkt im Dashboard visualisiert, sieht man ein Band, für das rollup_rate(min) <= irate <= rollup_rate(max) gilt

---

• Ein weiteres Missverständnis über irate ist, dass es schneller sei als rate
• Das wirkt vielleicht so, weil innerhalb des [range]-Intervalls nur die letzten beiden data points betrachtet werden
  • Tatsächlich verbraucht Prometheus aber die meiste CPU-Zeit bei Verwendung der query_range API dafür, die data points aus dem Intervall [start...end] zu extrahieren
  • Welche Funktion verwendet wird, hat auf die Performance keinen großen Einfluss

---

Da dies im Blogbeitrag nicht erklärt wird, hier noch eine Ergänzung: Den Unterschied zwischen der Verwendung des rollup="avg"-Werts von rollup_rate und der einfachen Nutzung von avg mit rate kann man in einer weiteren Antwort des MetricsQL-Entwicklers nachlesen.