เหตุผลที่ `irate` ของ Prometheus จับ spike ไม่ได้

• rate และ irate ที่ใช้คำนวณ per-second rate ใน PromQL
• มีความเข้าใจผิดว่า irate จะจับ spike ในช่วง [range] ได้ ส่วน rate จะนำ spike เหล่านั้นมาเฉลี่ย
• irate คำนวณเฉพาะ per-second rate ของ data points สองจุดสุดท้ายเท่านั้น
• data points สองจุดสุดท้ายที่จะถูกนำมาดูในแต่ละ query ของ query_range ขึ้นอยู่กับพารามิเตอร์ start, end, step
  • ดังนั้น dashboard ที่พึ่งพา irate จึงเปลี่ยนแปลงอย่างมากตามการซูมและการเลื่อนดู
• สำหรับ counter ที่เปลี่ยนแปลงอย่างรวดเร็ว irate จับทุก spike ได้ยาก

---

• ใน MetricsQL (Query Language ที่เข้ากันได้กับ PromQL เป็นส่วนใหญ่) จึงมีฟังก์ชัน rollup_rate รองรับกรณีนี้
• ฟังก์ชันนี้จะคำนวณ rate ระหว่าง data point ที่อยู่ติดกันแต่ละคู่ แล้วคืนค่า min, avg, max
• ดังนั้น spike ทั้งหมดจึงสามารถถูกจับได้อย่างสม่ำเสมอใน min และ max
• เมื่อลองทำ visualization บน dashboard โดยตรง จะเห็น band ที่เป็นไปตาม rollup_rate(min) <= irate <= rollup_rate(max)

---

• อีกหนึ่งความเข้าใจผิดเกี่ยวกับ irate คือมันเร็วกว่า rate
• อาจรู้สึกแบบนั้นเพราะมันดูแค่สองจุดสุดท้ายจาก data points ที่มีอยู่ในช่วง [range]
  • แต่ในความเป็นจริง จุดที่ Prometheus ใช้ CPU time มากที่สุดคือการดึง data points ออกมาจากช่วง [start...end] ตอนใช้ query_range API
  • จะใช้ฟังก์ชันไหนจึงแทบไม่ส่งผลต่อประสิทธิภาพมากนัก

---

• เพิ่มเติมจากที่บทความบล็อกไม่ได้อธิบายไว้ ความแตกต่างระหว่างการใช้ค่า rollup="avg" ของ rollup_rate กับการใช้ avg กับ rate ตรงๆ สามารถดูได้จากคำตอบอีกอันของผู้พัฒนา MetricsQL