Grafana показывает No data: проверяем метрику, время и переменные

Вчера график работал, сегодня вместо него No data. После изменения dashboard легко начать менять legend, единицы и цвета, хотя пустой результат мог возникнуть раньше: Grafana обратилась к другому источнику, переменная выбрала старый экземпляр или окно запроса больше не содержит нужных наблюдений. Диагностику удобно строить в порядке движения данных.

Возьмём панель скорости запросов API. Известно имя счётчика http_requests_total, а приложение должно публиковать label job="api". Сначала откройте редактирование панели и запишите выбранный data source, исходный запрос, диапазон времени и значения переменных. Это точка сравнения: после каждого изменения будет понятно, какое условие вернуло данные.

Получил ли источник хоть какие-то серии

Перейдите в Explore с тем же источником Prometheus. Установите последние 30 минут и начните с простого instant-запроса:

up

Если вернулись строки, соединение с источником работает хотя бы для этого запроса. Если получена ошибка доступа, timeout или ошибка прокси, разбирайте её текст. Ошибка запроса и успешный ответ с пустым набором данных — разные наблюдения. No data на панели не отменяет этой разницы.

Теперь выполните up{job="api"}. Пустой результат при непустом up подсказывает проверить реальные значения labels. Возможно, job переименовали в api-production. Нулевой up означает другую ситуацию: target существует, но его последний опрос не удался. Посмотрите страницу targets в Prometheus и конкретную ошибку scrape.

Вернём метрику без лишних условий

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

Добавляйте ограничения по одному. Если первая строка даёт данные, а вторая нет, причина связана с label. Если исходный счётчик есть, а скорость отсутствует, сравните окно с периодичностью scrape: для скорости нужны несколько наблюдений. Также проверьте, что серия действительно существует на выбранном интервале и метрика не поменяла тип.

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

Посмотрим запрос после подстановки

В панели с выбором экземпляра обычно стоит выражение с переменной. Для одиночного выбора точное сравнение может работать, а после включения Multi-value перестать соответствовать итоговой строке. Для нескольких значений Prometheus-переменной обычно нужен regex matcher:

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

Здесь $instance — переменная dashboard, а $__rate_interval — макрос Grafana. Такой текст нельзя без подстановки копировать в обычный интерфейс Prometheus. Если нужно проверить его там, замените переменную реальным значением, а окно — например, на 5m.

Откройте инспектор запросов панели и изучите отправленное выражение, start/end и ответ источника. Это особенно полезно для All, нескольких выбранных значений и связанных переменных. Сравнение исходного шаблона с фактическим запросом быстрее показывает лишнюю кавычку, пустое значение или неожиданный regex. Инспектор запроса и ответа помогает локализовать именно эту границу.

Проверим время и обработку результата

Если приложение перестало работать час назад, последние 15 минут могут быть пустыми, а вчерашний интервал — содержать линии. Сравните абсолютные границы времени в инспекторе и момент последнего scrape. Проверьте относительный сдвиг и override времени самой панели: её диапазон может отличаться от соседних графиков. Часовой пояс меняет подписи и выбор абсолютного времени, поэтому ориентируйтесь на отправленные timestamps.

Затем посмотрите тип запроса: range строит последовательность вычислений, instant возвращает состояние в один момент. Убедитесь, что выбранная визуализация получает подходящий результат. Временно отключите transformations и фильтры полей. Если в ответе источника строки есть, а после преобразования их нет, продолжать менять PromQL уже бессмысленно: нужно исправлять обработку результата панели.

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

Ещё по теме

• Dashboard Grafana сбрасывает изменения: UI, provisioning и источник файла
• Alertmanager шлёт слишком много сообщений: group_by и интервалы уведомлений

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

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