rate แล้วค่อย sum ใช่, sum แล้วค่อย rate ไม่ใช่

• เวลาจัดการ counter ใน Prometheus มีจุดที่พลาดกันได้ง่ายเมื่อใช้ฟังก์ชันที่ใช้ได้เฉพาะกับ counter อย่าง rate ร่วมกับ aggregation
• ใน Prometheus ค่า counter ทำได้เพียงแค่ “เพิ่มขึ้น”, “คงเดิม” หรือ “ถูกรีเซ็ต” เท่านั้น
• ถ้าอยากคำนวณอัตราคำขอต่อวินาทีของ Node Exporter สามารถเขียนคิวรีแบบนี้ได้?
  • sum by (job)(rate(http_requests_total{job="node"}[5m]))
• แล้วคิวรีแบบนี้ล่ะ?
  • rate(sum by (job)(http_requests_total{job="node"})[5m])
  • คิวรีนี้มีปัญหา
• ถ้าสมมติว่าโหนดตัวใดตัวหนึ่งรีสตาร์ต http_requests_total ของ Node Exporter บนโหนดนั้นจะถูกรีเซ็ตเป็น 0
  • ถ้าอย่างนั้นค่าของ sum(...) รวมก็จะลดลง
  • rate() จะตีความว่าเป็นการรีเซ็ต counter และทำให้เกิด spike ที่ผิดพลาด
    • *ถ้าค่าลดลงจาก n เป็น n-a ในมุมมองของ rate จะมองเหมือนค่ากระโดดขึ้นไปเท่ากับ (n-a)
• ดังนั้น...
  • rate(counter_a[5m] + counter_b[5m]) แบบนี้ NO
  • rate(counter_a[5m]) + rate(counter_b[5m]) แบบนี้ YES
• เรื่องนี้ไม่ได้ใช้กับ sum() เท่านั้น แต่ยังใช้กับ min(), max(), avg(), ceil(), histogram_quantile(), predict_linear() ด้วย
• ฟังก์ชันสำหรับ counter ไม่ได้มีแค่ rate() แต่ยังมี irate(), increase(), resets() ด้วย

---

สรุปที่มี * กำกับคือคำอธิบายเพิ่มเติมที่ไม่มีอยู่ในต้นฉบับ จึงแยกไว้ต่างหาก