Vì sao `irate` của Prometheus không bắt được spike

• rate và irate được dùng để tính per-second rate trong PromQL
• Có một hiểu lầm rằng irate sẽ bắt các spike trong [range], còn rate thì lấy trung bình các spike này
• irate chỉ tính per-second rate của hai data point cuối cùng
• Việc hai data point cuối nào sẽ được nhìn thấy trong mỗi query của query_range phụ thuộc vào các tham số start, end, step
  • Vì vậy, dashboard phụ thuộc vào irate có thể thay đổi rất nhiều khi zoom và cuộn
• Với các counter thay đổi đột ngột, rất khó để irate bắt được mọi spike

---

• Trong MetricsQL (Query Language tương thích phần lớn với PromQL), có hỗ trợ hàm rollup_rate cho mục đích này
• Hàm này tính rate giữa từng cặp data point liền kề và trả về min, avg, max của chúng
• Vì vậy, mọi spike đều có thể được phản ánh nhất quán trong min và max
• Nếu trực tiếp trực quan hóa trên dashboard, bạn có thể thấy một dải thỏa mãn rollup_rate(min) <= irate <= rollup_rate(max)

---

• Một hiểu lầm khác về irate là nó nhanh hơn rate
• Có lẽ vì nó chỉ nhìn hai data point cuối trong số các data point của khoảng [range] nên tạo cảm giác như vậy?
  • Nhưng trên thực tế, nơi Prometheus tiêu tốn CPU time nhiều nhất là khi dùng query_range API để trích xuất các data point trong khoảng [start...end]
  • Việc dùng hàm nào không ảnh hưởng nhiều đến hiệu năng

---

Bổ sung thêm vì bài blog không giải thích phần này: sự khác nhau giữa việc dùng giá trị rollup="avg" của rollup_rate và chỉ dùng avg với rate có thể xem trong một câu trả lời khác của tác giả MetricsQL.