Доля ошибок пропала с графика: отличаем отсутствие серии от нуля

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

Допустим, http_requests_total создаётся с меткой status только после первого ответа соответствующего класса. Пока ошибок не было, серии status="500" может не существовать. При делении пустого числителя на обычный трафик PromQL не получает нулевую долю автоматически. А когда за выбранное окно вообще нет запросов, у нас появляется ещё и нулевой знаменатель — отдельная математическая ситуация.

Сначала обеспечить смысл входных данных

Предпочтительно инициализировать ожидаемые серии в приложении, если набор значений конечный и небольшой. Тогда ноль ошибок — реальное значение метрики. На этапе запроса можно построить нулевой числитель из доступной серии общего трафика с тем же набором меток. Для одного job без разреза по instance выражение выглядит так:

(
  sum(rate(http_requests_total{job="api",status=~"5.."}[5m]))
  or
  0 * sum(rate(http_requests_total{job="api"}[5m]))
)
/
sum(rate(http_requests_total{job="api"}[5m]))

Правая сторона or создаёт ноль только из имеющегося общего трафика. Если исчезли вообще все входные серии, она не подставляет независимый vector(0). Это помогает сохранить различие между «ошибок нет» и «данных нет». Для группировки по service обе стороны нужно агрегировать по одинаковым меткам и заранее проверить сопоставление.

Если общий rate равен нулю, доля 0/0 не имеет обычного числового значения. Можно показывать состояние «нет трафика» отдельным индикатором либо фильтровать долю условием положительного знаменателя. Выбор определяется смыслом панели: отсутствие нагрузки не является измеренной нулевой долей ошибок среди запросов.

Проверить четыре состояния

В тестовой метрике воспроизведите обычный трафик без ошибок, трафик с ошибками, отсутствие запросов при продолжающемся scrape и исчезновение самого target. Посмотрите промежуточные числитель и знаменатель отдельно. В каждом случае должно быть ясно, почему итоговая линия нулевая, ненулевая или отсутствует.

Для потери телеметрии используйте отдельную проверку доступности target и отсутствия ожидаемой метрики. Функция absent_over_time помогает выразить отсутствие данных за окно; она не определяет сама, что именно сломалось. Сервер мог переименовать метрику, изменить labels или перестать публиковать её после обновления.

После исправления подпишите состояния панели так, чтобы инженер отличал тишину в сервисе от тишины в мониторинге. Аккуратная линия нужна для чтения, но её значение должно оставаться следствием наблюдений. Иначе косметическое заполнение пропусков скрывает именно тот сбой, ради которого дашборд открывают.

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

Одно выражение или правило становится полезным, когда связано с конкретным действием инженера. В программе курса «Prometheus и Grafana: мониторинг и observability» — метрики учебного сервиса, exporters, обзорный и диагностический дашборды, SLI/SLO и алерты с инструкциями. Практика включает воспроизведение отказа или роста задержек и расследование по сигналам системы. Это продолжение для тех, кто хочет собрать мониторинг, по которому можно принимать решения во время сбоя.

Посмотреть программу курса

Источник: официальная документация.

Другие задачи по теме: Метрики и уведомления без неверных выводов.