Mengapa `irate` di Prometheus tidak dapat menangkap spike

• rate dan irate digunakan untuk menghitung rate per detik di PromQL
• Ada kesalahpahaman bahwa irate menangkap spike selama [range], sedangkan rate merata-ratakan spike tersebut
• irate hanya menghitung rate per detik dari dua data point terakhir
• Dua data point terakhir yang akan terlihat pada setiap query query_range bergantung pada parameter start, end, dan step
  • Karena itu, dashboard yang bergantung pada irate dapat berubah drastis tergantung zooming dan scrolling
• Pada counter yang berubah sangat cepat, sulit bagi irate untuk menangkap semua spike

---

• Untuk ini, MetricsQL (bahasa query yang sebagian besar kompatibel dengan PromQL) mendukung fungsi rollup_rate
• Fungsi ini menghitung rate antar setiap data point yang berdekatan lalu mengembalikan min, avg, dan max
• Karena itu, semua spike dapat tertangkap secara konsisten di min dan max
• Jika divisualisasikan langsung di dashboard, Anda dapat melihat band yang memenuhi rollup_rate(min) <= irate <= rollup_rate(max)

---

• Kesalahpahaman lain tentang irate adalah bahwa ia lebih cepat daripada rate
• Mungkin terasa demikian karena dari data point yang diberikan selama interval [range], ia hanya melihat dua yang terakhir?
  • Namun, dalam praktiknya bagian yang paling banyak menghabiskan CPU time di Prometheus saat menggunakan API query_range adalah mengekstrak data point selama interval [start...end]
  • Fungsi mana yang digunakan tidak banyak memengaruhi performa

---

Tambahan karena hal ini tidak dijelaskan di postingan blog: perbedaan antara menggunakan nilai rollup="avg" pada rollup_rate dan sekadar memakai avg pada rate dapat dilihat di jawaban lain dari pengembang MetricsQL.