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
ยังไม่มีความคิดเห็น