As it was repeated numerous times, again and again rate must be applied before sum.
Additionally both rate and irate require at least two samples in range vector to return anything. I doubt that you have a scrape interval of less then 8 seconds. So most likely you range selector is incorrect, and you need something bigger like [30s] or anything, but at least twice your scrape interval. And if you are planning to use it in Grafana you can use [$__rate_interval] instead: Grafana will substitute best suited value itself.
Your query should look like
sum by (app) (rate(application_errors_total[30s]))
Answer from markalex on Stack OverflowAs it was repeated numerous times, again and again rate must be applied before sum.
Additionally both rate and irate require at least two samples in range vector to return anything. I doubt that you have a scrape interval of less then 8 seconds. So most likely you range selector is incorrect, and you need something bigger like [30s] or anything, but at least twice your scrape interval. And if you are planning to use it in Grafana you can use [$__rate_interval] instead: Grafana will substitute best suited value itself.
Your query should look like
sum by (app) (rate(application_errors_total[30s]))
This could apply to more general use cases. So want to share my 2c.
As discussed, rate/irate/increase all requires two data points, so it's not usable for your use case.
We can hand calculate the increase, leveraging the offset feature of promQL.
Assuming the scrape-interval is 15 seconds, here is the promQL:
(sum(application_errors_total) by (app)) - (sum(application_errors_total) by (app) offset 15s)
If you really want rate, then you can divide the result by scrape-interval.
It still requires two data points to calculate the difference. But instead of requiring each app/error-type combination has at least two data points, it only requires each app has at least two data points for any error types.
Of course it's a poor man's increase/rate. It doesn't consider counter reset or extrapolation.