Pourquoi `irate` de Prometheus ne capture pas les pics

• En PromQL, rate et irate servent à calculer un taux par seconde
• Il existe une idée reçue selon laquelle irate capture les pics sur l’intervalle [range], tandis que rate en fait simplement la moyenne
• En réalité, irate calcule uniquement le taux par seconde à partir des deux derniers points de données
• Les deux derniers points de données visibles pour chaque requête dans query_range dépendent des paramètres start, end et step
  • Par conséquent, les tableaux de bord qui reposent sur irate peuvent varier fortement selon le zoom et le défilement
• Avec un compteur qui évolue brutalement, il est difficile pour irate de capturer tous les pics

---

• Pour répondre à ce problème, MetricsQL (un langage de requête largement compatible avec PromQL) prend en charge la fonction rollup_rate
• Cette fonction calcule le taux entre chaque paire de points de données adjacents, puis renvoie les valeurs min, avg et max
• Ainsi, tous les pics peuvent être capturés de manière cohérente dans min et max
• En le visualisant directement dans un tableau de bord, on peut voir une bande vérifiant rollup_rate(min) <= irate <= rollup_rate(max)

---

• Une autre idée reçue au sujet de irate est qu’il serait plus rapide que rate
• C’est peut-être l’impression qu’il donne, puisqu’il ne regarde que les deux derniers points parmi ceux fournis sur l’intervalle [range]
  • Mais en pratique, l’endroit où Prometheus consomme le plus de temps CPU, lors de l’utilisation de l’API query_range, est l’extraction des points de données sur l’intervalle [start...end]
  • La fonction utilisée a donc peu d’impact sur les performances

---

Comme ce point n’est pas expliqué dans l’article de blog, on peut ajouter que la différence entre l’utilisation de rollup_rate avec rollup="avg" et l’utilisation directe de avg avec rate est détaillée dans une autre réponse du développeur de MetricsQL.