Por que o `irate` do Prometheus não consegue capturar spikes

• Em PromQL, rate e irate são usados para calcular a taxa por segundo
• Existe o equívoco de que o irate captura os spikes durante o [range], enquanto o rate faz a média desses spikes
• O irate calcula apenas a taxa por segundo dos dois últimos data points
• Quais serão os dois últimos data points vistos em cada query de query_range depende dos parâmetros start, end e step
  • Portanto, dashboards que dependem de irate variam bastante conforme zoom e rolagem
• Em counters que mudam abruptamente, é difícil capturar todos os spikes com irate

---

• No MetricsQL (uma linguagem de consulta majoritariamente compatível com PromQL), existe a função rollup_rate para isso
• Essa função calcula a taxa entre cada par de data points adjacentes e retorna min, avg e max
• Assim, todos os spikes podem ser capturados de forma consistente em min e max
• Ao visualizar isso diretamente em um dashboard, é possível ver uma banda que satisfaz rollup_rate(min) <= irate <= rollup_rate(max)

---

• Outro equívoco sobre o irate é achar que ele é mais rápido que o rate
• Talvez isso pareça fazer sentido porque, entre os data points fornecidos no intervalo [range], ele olha apenas para os dois últimos?
  • Mas, na prática, onde o Prometheus mais consome CPU ao usar a API query_range é na extração dos data points ao longo do intervalo [start...end]
  • A função usada não tem grande impacto no desempenho

---

Como isso não foi explicado no post do blog, vale acrescentar que a diferença entre usar rollup_rate com rollup="avg" e simplesmente usar avg com rate pode ser vista em outra resposta do desenvolvedor do MetricsQL.