Alertmanager шлёт слишком много сообщений: group_by и интервалы уведомлений

Во время отказа одной зависимости одновременно срабатывают алерты на десяти репликах API. Каждое сообщение выглядит почти одинаково, но приходит отдельно. Увеличить repeat_interval кажется очевидным решением, однако первые десять уведомлений уже относятся к разным группам. Для них интервал повтора ещё не играет роли.

Alertmanager сначала выбирает маршрут и получателя, затем объединяет алерты по labels из group_by. Поэтому борьбу с шумом начинают с двух сообщений: сравнивают alertname, cluster, service, instance и фактический маршрут. Нужно понять, это разные группы, изменение состава одной группы или повтор неизменившегося события.

Определим единицу уведомления

Для дежурного по API удобно одно сообщение на тип проблемы, кластер и сервис. Labels отдельных реплик остаются внутри группы. Минимальный фрагмент конфигурации может выглядеть так:

route:
  receiver: team-api
  group_by: [alertname, cluster, service]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
receivers:
  - name: team-api
    webhook_configs:
      - url: http://alert-webhook.internal:8080/alerts

Адрес webhook здесь пример внутреннего приёмника: его нужно заменить реальным согласованным endpoint. Если добавить instance в group_by, каждая реплика снова получит отдельную группу. Специальное значение ['...'] группирует по всем labels и фактически отключает объединение разных алертов. Оно редко помогает в сценарии общего сбоя.

Слишком широкая группа тоже неудобна. Если убрать cluster, проблемы независимых окружений могут попасть в одно сообщение. Выбирайте ключ по тому, какое решение должен принять получатель и какой состав объектов он способен разобрать в одном уведомлении.

Пройдём по времени

Первая реплика попала в новую группу в 12:00:00. В течение group_wait Alertmanager ждёт другие связанные алерты. Если ещё девять пришли до 12:00:30, они смогут войти в первое сообщение. Короткий сбой, завершившийся до конца этого ожидания, может вообще не дать первого уведомления. Поэтому уменьшение шума здесь связано и с задержкой обнаружения для получателя.

После первого уведомления group_interval определяет проверки изменений группы. Новая реплика, добавившаяся через минуту, не обязана немедленно породить сообщение: изменение будет обработано на очередном таком интервале. Repeat_interval относится к повтору группы без новых срабатываний или завершений. Эти интервалы решают разные задачи.

Проверка повтора идёт на границах group_interval, поэтому repeat_interval удобно выбирать кратным ему. Если период хранения данных Alertmanager короче заданного повтора, уведомление может повториться раньше желаемого.

Проверим причины, которые группировка не исправляет

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

Дубли могут возникать также из-за нескольких маршрутов с continue, независимых Alertmanager без общей дедупликации или внешнего приёмника, который повторно обрабатывает доставку. Сравните labels, receiver и время отправки в интерфейсе и журналах. Настройка group_by не заменяет анализ пути доставки.

Как оценить новую конфигурацию

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

Удачная настройка сохраняет смысл события: дежурный видит affected instances, получает существенное изменение состава и не читает десять одинаковых сообщений. Если в группе уже нельзя быстро понять масштаб проблемы, улучшите шаблон сообщения или разделите ключ группировки по реальным зонам ответственности.

Ещё по теме

• Dashboard Grafana сбрасывает изменения: UI, provisioning и источник файла
• Grafana показывает No data: проверяем метрику, время и переменные

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

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