Документация

Заглушки

Версия v2.3.1 · Обновлено

Заглушки#

Заглушки (silence) временно подавляют уведомления об алертах для планового обслуживания, шумных алертов или известных инцидентов, не требующих вызова.

Заглушка принадлежит одной команде и использует общий формат матчеров IncidentRelay. Когда входящий алерт совпадает с активной заглушкой, IncidentRelay помечает его как заглушённый и пропускает обычные уведомления.

Как работает сопоставление#

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

{}

Сопоставить конкретный алерт на одном инстансе:

{
  "alertname": "DiskFull",
  "instance": "host1.example.com"
}

Структурированная форма меток эквивалентна:

{
  "labels": {
    "alertname": "DiskFull",
    "instance": "host1.example.com"
  }
}

См. Матчеры алертов для полного описания общего формата, операторов значений и поведения редактора матчеров.

Примеры матчеров#

Заглушить предупреждающие алерты CPU#

{
  "alertname": "HighCPU",
  "severity": "warning"
}

Заглушить критические алерты для сервиса#

{
  "service": "billing-api",
  "severity": "critical"
}

Заглушить группу хостов по регулярному выражению#

{
  "instance": {
    "regex": "^web-[0-9]+\\.example\\.com$"
  }
}

Заглушить алерты Kubernetes по namespace#

{
  "namespace": "staging"
}

Исключить одно значение#

{
  "environment": {
    "not": "production"
  }
}

Совпадение с одним из нескольких значений#

{
  "severity": ["warning", "info"]
}

Подсказки матчеров#

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

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

Статусы#

СтатусЗначение
ActiveЗаглушка включена, и текущее время находится между starts_at и ends_at.
ScheduledЗаглушка включена, но starts_at в будущем.
ExpiredЗаглушка завершилась. Истёкшие заглушки по умолчанию скрываются после окна хранения.
DisabledЗаглушка была отключена вручную и остаётся видимой для просмотра.

Существующие неразрешённые алерты#

По умолчанию Silence влияет только на вхождения алертов, полученные во время его активности. Алерты, которые уже находились в состоянии firing, продолжают текущий поток уведомлений и эскалации.

Включайте Apply to existing unresolved alerts, только если Silence должен немедленно подавить и совпадающие активные алерты. Это полезно при экстренном шторме алертов, однако настройка намеренно отключена по умолчанию: ответственные уже могут работать над существующим инцидентом.

По умолчанию настройка Reactivate silenced alerts when this Silence ends включена. Когда последний совпадающий Silence заканчивается или отключается, алерты, созданные или ретроактивно подавленные этим Silence, снова становятся активными. После этого IncidentRelay запускает обычный поток уведомлений для алертов, о которых ещё не уведомляли, либо отправляет обновление для алертов, по которым уведомления уже создавались. Подтверждённые группы алертов сохраняют состояние acknowledged.

Отключайте эту настройку, только если затронутые алерты должны оставаться подавленными после завершения Silence. Они не будут реактивированы автоматически. Чтобы снять подавление позднее, отредактируйте Silence, включите настройку и сохраните его. Настройка применяется независимо для каждого Silence.

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

История истёкших заглушек#

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

Включите историю истёкших заглушек на странице Silences, чтобы найти более старые записи для аудитов и устранения неполадок.

Отключённые заглушки#

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

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

Рекомендуемая стратегия матчеров#

Держите заглушки настолько узкими, насколько это возможно.

Предпочтительно:

{
  "alertname": "DiskFull",
  "instance": "host1.example.com"
}

Избегайте широких матчеров, если только окно обслуживания не является намеренным:

{
  "severity": "critical"
}

Широкая заглушка может подавить несвязанные инциденты.

Распространённые метки#

Точный набор меток зависит от полезной нагрузки входящей интеграции.

МеткаПример
alertnameDiskFull
severitycritical
instancehost1.example.com
jobnode-exporter
servicebilling-api
namespaceproduction
clusterprod-eu-1

Матчеры Alertmanager обычно нацелены на значения из alerts[].labels. Для полезных нагрузок Zabbix или обобщённых вебхуков используйте метки, сохранённые в итоговом алерте.

Устранение неполадок#

Если заглушка не совпадает с алертом:

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

Если заглушается слишком много алертов, добавьте метки, такие как alertname, instance, service, namespace или severity, чтобы сузить матчер.