Prometheus'taki `irate` neden spike'ları yakalayamıyor

• PromQL'de saniye başına oranı hesaplamak için kullanılan rate ve irate
• irate'in [range] boyunca spike'ları yakaladığı, rate'in ise bu spike'ların ortalamasını aldığına dair bir yanılgı var
• irate, yalnızca son iki data point'in saniye başına oranını hesaplar
• query_range içindeki her sorguda görülecek son iki data point'in hangileri olacağı start, end, step parametrelerine bağlıdır
  • Bu nedenle irate'e dayanan paneller, zoom ve scroll'a göre büyük ölçüde değişir
• Hızla değişen counter'larda irate ile tüm spike'ları yakalamak zordur

---

• MetricsQL'de (PromQL ile büyük ölçüde uyumlu bir sorgu dili) bunun için rollup_rate fonksiyonu desteklenir
• Bu fonksiyon, birbirine komşu her data point çifti arasındaki oranı hesaplar ve bunun min, avg, max değerlerini döndürür
• Bu sayede tüm spike'lar tutarlı biçimde min ve max içinde yakalanabilir
• Bunu doğrudan panelde görselleştirirseniz, rollup_rate(min) <= irate <= rollup_rate(max) koşulunu sağlayan bir bant görebilirsiniz

---

• irate hakkındaki bir başka yanılgı da rate'ten daha hızlı olduğu yönünde
• Muhtemelen [range] aralığında verilen data point'ler içinden yalnızca son ikisine baktığı için böyle hissediliyor olabilir?
  • Ancak gerçekte Prometheus'un en çok CPU zamanı harcadığı yer, query_range API kullanılırken [start...end] aralığındaki data point'leri çıkarmaktır
  • Hangi fonksiyonun kullanıldığı performansı büyük ölçüde etkilemez

---

Blog yazısında bu açıklanmadığı için eklemek gerekirse, rollup_rate içinde rollup="avg" değerini kullanmakla rate üzerinde doğrudan avg kullanmak arasındaki farkı MetricsQL geliştiricisinin başka bir yanıtında görebilirsiniz.