Silence на обслуживание скрыл чужой сервис: сужаем matchers

На время работ с базой создали silence по alertname="DatabaseUnavailable". Уведомления ожидаемо прекратились, но позже выяснилось, что такое же имя использует база другого окружения. Умолчание не различает намерения инженера. Оно выбирает алерты по matchers, и слишком широкий набор условий может скрыть посторонний отказ.

Silence удобно применять для ограниченного по времени обслуживания. В отличие от изменения правил мониторинга, оно оставляет вычисление алертов на месте. Но для безопасного использования нужно описать объект работ метками: какой сервис, какое окружение и, если требуется, какой instance. Чем точнее эти метки отражают границу обслуживания, тем проще проверить результат до начала действий.

Сформировать область работ

Для конкретной базы набор условий может включать три точных совпадения. Это не полный конфиг Alertmanager, а пример значений matchers, которые выбирают в интерфейсе silence или передают через подходящий API.

alertname="DatabaseUnavailable"
service="catalog-db"
environment="staging"

Перед сохранением посмотрите предварительно совпавшие алерты. Все они должны относиться к работам. Затем найдите похожий алерт другого environment и убедитесь, что он не попадает под условия. Если метки service у нужного алерта нет, добавление такого matcher не исправляет его автоматически: silence просто не совпадёт. Сначала нужно увидеть реальные labels.

Регулярные выражения используйте только там, где действительно нужен набор объектов. Условие service=~".*db.*" легко захватывает больше, чем одна база. При этом точный matcher тоже может быть широким, если выбранная метка имеет слишком общий смысл. Не ориентируйтесь только на длину записи: важен фактический список совпадений.

Ограничить время и оставить причину

У silence должны быть понятные начало, конец и комментарий с причиной обслуживания. Срок выбирают по окну работ с разумным запасом, а не оставляют на несколько недель «на всякий случай». Если работы завершились раньше, silence стоит закончить явно: иначе новый отказ останется без уведомления до назначенного времени.

Во время работ смотрите состояние алертов в Alertmanager и метрики напрямую. Подавление сообщения не переводит сервис в норму. Если меняются labels или создаётся новый instance, проверьте соответствие снова: прежний matcher может либо перестать покрывать нужную цель, либо продолжить покрывать уже другой объект с тем же именем.

После завершения убедитесь, что silence истёк или удалён, а уведомления для контрольного тестового алерта снова проходят по ожидаемому пути. Это особенно полезно после длинных работ, где участвовало несколько человек. В runbook можно оставить короткую последовательность: определить объект, проверить совпадения, назначить срок, завершить silence и проверить канал. Такая дисциплина сохраняет удобство плановых работ, не превращая временное исключение в постоянную потерю наблюдаемости.

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

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

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

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

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