График rate пропадает при приближении: $__rate_interval и частота scrape

На суточном графике скорость запросов видна уверенно. При приближении до последних пяти минут линия исчезает или распадается на редкие точки. Исходный счётчик продолжает поступать. Частая причина — окно rate связано с графическим шагом и при приближении становится короче интервала между опросами.

У range-запроса есть шаг: насколько часто вычислять выражение на временной оси. У rate(counter[...]) есть собственное окно: сколько истории читать для каждого вычисления. Более частые точки не создают дополнительные samples счётчика. Если окно содержит меньше двух подходящих наблюдений, скорость посчитать нельзя.

Найдём зависимость от масштаба

Предположим, Prometheus опрашивает приложение каждые 15 секунд. В панели записано rate(http_requests_total[$__interval]). На широком диапазоне Grafana выбирает большой interval, и расчёт работает. После приближения interval становится 5 секунд: внутри такого окна часто нет даже двух опросов.

Откройте инспектор запросов до и после zoom. Запишите итоговое выражение, start/end и step. Если в range selector оказалось 5s при scrape 15s, проблема локализована. Не меняйте порог или единицы панели: они не добавят недостающие наблюдения.

Используем окно, учитывающее scrape

sum by (service) (
  rate(http_requests_total{job="api"}[$__rate_interval])
)

Макрос Grafana рассчитывается как max($__interval + scrape_interval, 4 * scrape_interval). При interval 5 секунд и scrape 15 секунд получится max(20, 60), то есть окно 60 секунд. При interval 60 секунд получится max(75, 60), то есть 75 секунд. Дополнительное перекрытие помогает учитывать приращения между соседними окнами.

Это настройка Grafana, поэтому выражение с макросом не выполняется напрямую в обычном Prometheus. Для ручной проверки замените окно конкретным значением, например 1m. Так можно отдельно убедиться, что исходная метрика существует и скорости появляются на том же интервале.

Откуда макрос узнаёт частоту опроса

Grafana использует Min step конкретного запроса, если он задан, либо Scrape interval в настройках data source. Она не выводит автоматически истинный период каждой серии из её timestamps. Если в Prometheus для job стоит 60s, а в data source осталось 15s, макрос может оказаться слишком коротким.

Для job с собственной частотой укажите её через Min step. Это важно на dashboard, объединяющем targets с разными interval. Настройка Min interval на уровне панели решает другой вопрос и не подменяет scrape interval в этой формуле. Сверьте источники значения макроса с реальной конфигурацией опросов.

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

Проверим цену устойчивого графика

Длиннее окно — плавнее линия. Короткий всплеск может стать ниже по амплитуде, потому что rate усредняет его за больший период. Это ожидаемое изменение смысла точки. Для расследования сравнивайте панели с одинаковым окном, особенно если хотите оценить величину пика до и после релиза.

Не все дырки вызваны масштабом. Пропавшие scrapes, новая идентичность серии или фильтр переменной тоже убирают данные. После настройки макроса сравните исходный counter и up на проблемном участке. Если samples отсутствовали несколько минут, достаточное окно не восстановит неизвестные события.

Завершите проверку двумя масштабами и одинаковым выбранным service. В инспекторе должно быть видно ожидаемое окно, а график — сохранять осмысленные скорости. Теперь его устойчивость опирается на частоту исходных данных, а не на случайное разрешение экрана.

Ещё по теме

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

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

Продолжить на практике

  • Prometheus и Grafana: мониторинг и observability ↗

    Замечайте сбои до жалоб пользователей. Соберите мониторинг приложения: метрики Prometheus, запросы PromQL, дашборды Grafana и алерты, по которым понятно, что делать. Итог — наблюдаемый сервис и разбор учебного инцидента.