Por qué `irate` de Prometheus no logra capturar los picos

• rate e irate, que se usan en PromQL para calcular la tasa por segundo
• Existe el malentendido de que irate captura los picos durante [range], y que rate promedia esos picos
• irate solo calcula la tasa por segundo de los últimos dos data points
• Qué dos últimos data points verá cada consulta de query_range depende de los parámetros start, end y step
  • Por eso, los dashboards que dependen de irate cambian mucho según el zoom y el desplazamiento
• En counters que cambian bruscamente, es difícil capturar todos los picos con irate

---

• Para esto, MetricsQL (un lenguaje de consultas mayormente compatible con PromQL) ofrece la función rollup_rate
• Esta función calcula la tasa entre cada par de data points adyacentes y devuelve su min, avg y max
• Por lo tanto, todos los picos pueden reflejarse de forma consistente en min y max
• Si lo visualizas directamente en un dashboard, puedes ver una banda que cumple rollup_rate(min) <= irate <= rollup_rate(max)

---

• Otro malentendido sobre irate es que es más rápido que rate
• Quizá se siente así porque, de todos los data points dados durante el intervalo [range], solo mira los últimos dos
  • Pero en realidad, donde Prometheus consume más tiempo de CPU al usar la API query_range es al extraer los data points del intervalo [start...end]
  • Qué función se use no tiene un impacto importante en el rendimiento

---

Como esto no se explica en la entrada del blog, agrego que la diferencia entre usar el valor rollup="avg" de rollup_rate y simplemente usar avg sobre rate puede verse en otra respuesta del desarrollador de MetricsQL.