Critical не подавил warning: проверяем equal в Alertmanager

Один и тот же сервис одновременно присылает warning и critical о высокой доле ошибок. Правило inhibition уже настроено, но оба уведомления продолжают приходить. Обычно нужно проверить не названия receiver, а labels самих алертов. Подавление опирается на соответствие источника, цели и значений меток, перечисленных в equal.

Inhibition описывает зависимость между активными алертами. Например, critical для одного сервиса может делать менее срочное warning избыточным. Но critical сервиса billing не должен скрывать warning сервиса catalog. Для этого правило связывает уровни через идентичность объекта, а не только через severity.

Выбрать метки одной проблемы

Ниже source — critical, target — warning, а совпадать должны alertname, service и environment. Это фрагмент секции inhibit_rules конфигурации Alertmanager.

inhibit_rules:
  - source_matchers:
      - 'severity="critical"'
    target_matchers:
      - 'severity="warning"'
    equal:
      - alertname
      - service
      - environment

Такое правило подходит, когда два уровня одного alertname действительно описывают одну проблему. Если у warning имя ApiLatencyWarning, а у critical ApiLatencyCritical, включённый alertname помешает совпадению. В этом случае нужно либо унифицировать идентичность правила с уровнем в severity, либо явно определить другое соответствие. Убирать все equal ради исчезновения дублей опасно: suppression может распространиться на посторонние сервисы.

Обратная проблема — отсутствие нужной метки с обеих сторон. В сравнениях equal отсутствующая метка и пустое значение могут совпасть. Поэтому поле environment в YAML не создаёт его в алертах. Проверьте, что метки действительно присутствуют и имеют одинаковое написание. Значения prod и production не станут равными по смыслу автоматически.

Проверить подавление на двух объектах

В интерфейсе Alertmanager откройте конкретные critical и warning и сравните полный набор labels. Начните с той пары, где suppression ожидается. Затем создайте на тестовом стенде warning другого service или environment: он должен продолжать уведомлять. Отрицательный сценарий здесь столь же важен, как исчезновение лишнего сообщения.

Проверьте конфигурацию через amtool check-config, затем испытайте поведение на отдельном Alertmanager с тестовыми алертами. Статическая проверка найдёт ошибки структуры, но не знает вашей предметной связи между двумя названиями. Для этой части нужны заранее записанные пары «подавлять» и «оставлять».

Inhibition не удаляет алерт из Prometheus и не исправляет его выражение. Оно меняет уведомления при наличии связанного активного источника. Поэтому во время расследования warning может оставаться видимым, хотя сообщение по нему не отправлено. Это полезное свойство: история сигнала сохраняется, а инженер получает более короткий список действий. В инструкции укажите, какой critical объясняет подавленный warning и что делать, если источник оказался ошибочным.

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

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

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

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

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