Rate и increase в Prometheus: считаем запросы и учитываем сброс счётчика

После выкладки на графике запросов появился провал. Приложение продолжает отвечать, но линия метрики упала почти к нулю. Если панель рисует http_requests_total, это ещё не свидетельство потери трафика: процесс мог перезапуститься и начать считать заново. Чтобы понять нагрузку, нужно отделить накопленное значение от скорости, с которой оно меняется.

Предположим, каждый экземпляр API публикует счётчик обработанных HTTP-запросов с labels job, instance и status. Для счётчика естественны рост и сброс. Падение температуры или длины очереди имеет другой смысл: такие величины относятся к gauge. Применять к ним правила коррекции сбросов нельзя.

Сначала выберем единицу результата

Дежурному нужна текущая интенсивность: сколько запросов в секунду обслуживает API. Для этого подходит средняя скорость за последние пять минут. Команде, разбирающей короткий эпизод, может понадобиться прирост за это же окно:

sum by (job) (rate(http_requests_total{job="api"}[5m]))
sum by (job) (increase(http_requests_total{job="api"}[5m]))

Первое выражение возвращает запросы в секунду, второе — оценку числа запросов за пять минут. Установите соответствующие единицы на панелях. Значение 12 на первой панели означает примерно 12 запросов в секунду, а не 12 запросов за весь видимый час. Каждая точка часового графика всё равно рассчитана по своему пятиминутному окну.

Для одинакового окна increase соответствует rate, умноженному на длительность окна в секундах. При скорости 2 запроса в секунду оценка за пять минут равна 600. Это полезная проверка единиц, но она не превращает метрику в журнал отдельных операций.

Почему после рестарта нельзя вычитать крайние значения

Рассмотрим наблюдения одного экземпляра: 100, 130, 5, 20. Между вторым и третьим опросом процесс перезапустился. Разность последнего и первого значения равна −80, хотя запросы обслуживались. Коррекция сброса учитывает наблюдаемые участки: 30 до сброса, 5 после начала нового счётчика и ещё 15. Получается 50 наблюдаемых приращений до поправки на границы окна.

Запросы, которые успели пройти после последнего опроса старого процесса и до его остановки, в этих данных отсутствуют. Prometheus не может восстановить их по имени метрики. Если нужны точные операции для взаиморасчётов, сохраняйте события в подходящем учётном хранилище.

Функции rate и increase учитывают сбросы каждой временной серии. Поэтому в примере сначала вычисляется скорость, затем складываются экземпляры. Если сначала сложить сырые счётчики, рост одного процесса может скрыть сброс другого. Вы потеряете информацию, необходимую для коррекции.

Откуда берутся дроби

Опросы редко совпадают с обеими границами окна. Кроме того, один из них может не состояться. Алгоритм использует расстояние между наблюдениями и экстраполирует результат к границам с собственными ограничениями. Поэтому increase может вернуть 17,5, хотя приложение увеличивает счётчик только на единицу. Округление меняет отображение, но не делает оценку точным подсчётом событий.

Слишком короткое окно создаёт другую проблему: для расчёта может не хватить точек. При опросе раз в минуту окно в 30 секунд часто бесполезно. Начните с окна, которое уверенно содержит несколько опросов, и сравните его с требуемой скоростью реакции. Более длинное окно сглаживает короткие всплески; это осознанный обмен детализации на устойчивость.

Как проверить подозрительный провал

resets(http_requests_total{job="api"}[30m])
up{job="api"}

Первая проверка показывает обнаруженные сбросы по сериям. Из-за дополнительных labels один процесс может дать несколько строк. Вторая показывает успешность последних опросов существующих targets. Сопоставьте время сбросов с выкладкой, затем посмотрите исходный счётчик одного instance. Это позволяет различить рестарт, отсутствие опросов и настоящее снижение нагрузки.

После исправления панели сравните её с количеством запросов в доступном журнале за ограниченный интервал. Небольшие расхождения на границах ожидаемы. Резкое систематическое отличие требует проверить, что именно считает приложение: начатые запросы, завершённые ответы или обращения только к отдельному обработчику. Верная формула не исправит неверно выбранный смысл метрики.

Ещё по теме

• P95 в Prometheus: как считать задержку по histogram и не усреднять процентили
• Scrape timeout в Prometheus: как различить медленный exporter и проблему сети

Продолжить изучение

Хотите построить мониторинг, который помогает находить причины сбоев? Метрики, дашборды и оповещения входят в программу «Prometheus и Grafana: мониторинг и observability».