Серверные алерты без шума: ошибки и рабочие приёмы

Если каждый короткий скачок CPU отправляет уведомление, а настоящий отказ сервиса прячется среди повторов, проблема не в невнимательности дежурного — алерт настроен плохо. На примерах для Prometheus 3.0.x и Alertmanager 0.28.x разберём, как сократить шум, сохранить важные сигналы и понять, что делать после уведомления.

Сначала проверьте, можно ли действовать по алерту

Хороший алерт сообщает о состоянии, которое требует реакции сейчас или в заданное время. «CPU выше 80%» — пока только показание датчика. «Сервис не отвечает на запросы пять минут» — уже возможная причина открыть инцидент. Перед тем как добавлять правило, ответьте на три вопроса:

• Какое пользовательское или системное последствие означает это условие?
• Кто должен отреагировать и каким способом?
• Что человек проверит первым?

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

Оповещать стоит не о каждом необычном значении метрики, а о ситуации, где промедление увеличивает ущерб.

Термин: кардинальность — число разных комбинаций значений меток у метрики. Если добавлять в метки идентификаторы запросов или пользователей, рядов становится слишком много, а сами алерты могут размножиться по одному на каждую комбинацию.

Три ошибки, из-за которых алерты отключают

1. Условие ловит колебания, а не устойчивую проблему

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

Порог тоже должен вытекать из поведения сервиса. Для загрузки CPU универсального значения нет: один сервер выдержит высокий уровень при нормальном отклике, другой начнёт отказывать при меньшей нагрузке. Смотрите на симптом для пользователя и проверяйте порог на данных своего сервиса.

2. Алерт не говорит, что именно сломалось

Сообщение «High latency» бесполезно, если в нём нет сервиса, окружения и ссылки на нужный дашборд. В Prometheus названия алертов, метки и аннотации попадут в уведомление, если шаблон и получатель Alertmanager их используют. Пишите короткое резюме и описание с контекстом, не зашивайте в текст значение, которое может меняться, если его можно передать через метку или выражение.

Пример правила для цели, которую Prometheus уже обнаружил:

groups:
  - name: availability
    rules:
      - alert: InstanceScrapeFailed
        expr: up{job="node"} == 0
        for: 5m
        labels:
          severity: page
        annotations:
          summary: "Prometheus не собирает метрики с {{ $labels.instance }}"
          description: "Проверьте доступность узла и сбор метрик для job={{ $labels.job }}."

Это пример для Prometheus 3.0.x. Он обнаруживает неработающий scrape уже известной цели. Если цель исчезла из конфигурации или списка обнаружения целиком, ряда up для неё может не быть — такое условие само по себе пропажу не поймает. Проверяйте этот сценарий отдельно, исходя из способа обнаружения целей.

3. Каждое срабатывание превращается в отдельное сообщение

При отказе узлов или множества экземпляров сервис может выдать целый поток одинаковых по смыслу уведомлений. Группировка в Alertmanager объединяет алерты с одинаковыми значениями выбранных меток; повторная отправка при этом регулируется отдельно. Не группируйте всё только по имени правила: так можно спрятать проблемы разных кластеров или сервисов в одном сообщении.

Фрагмент маршрута для Alertmanager 0.28.x:

route:
  receiver: on-call
  group_by: [alertname, cluster, service]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h

Это фрагмент, а не полный конфиг: получатель on-call должен быть объявлен в конфигурации отдельно. Значения интервалов — отправная точка, а не рекомендация для любой команды. Слишком короткое ожидание может отправить несколько уведомлений до того, как группа сформируется; слишком редкие повторы — оставить длительный инцидент без напоминания.

Выберите подход по цене ошибки

Часто это не взаимоисключающие варианты: правило определяет, когда сигнал становится активным, а Alertmanager — кому и в каком виде его доставить. Выбирайте срочный маршрут для условий, где нужна немедленная реакция. Для менее срочных проблем задайте отдельную маршрутизацию, а не отправляйте всё дежурному одинаковым способом.

Как проверить правило до дежурства

1. Проверьте смысл. Найдите состояние системы, которое соответствует выражению, и убедитесь, что оно действительно требует действия. Проверка пройдена, если для срабатывания можно назвать последствия и ответственного.
2. Проверьте время. Сравните длительность условия и for с тем, сколько система выдержит без реакции. Проверка пройдена, если краткий безвредный скачок не вызывает вызов, а опасная деградация не ждёт дольше допустимого.
3. Проверьте аннотации и метки. Убедитесь, что в уведомлении видны сервис, окружение, затронутый экземпляр и следующий шаг. Проверка пройдена, если дежурный понимает, куда перейти и что открыть.
4. Проверьте группировку и доставку. Посмотрите, какие алерты объединятся и кому уйдут. Проверка пройдена, если сообщения приходят нужному получателю, а независимые проблемы не сливаются в одну группу.
5. Смоделируйте отсутствие данных. Остановите сбор или исключите цель в тестовом окружении и проверьте, не исчезает ли наблюдаемость молча. Проверка пройдена, если вы понимаете, какой отдельный сигнал покажет потерю метрик.

Что ломается в проде

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

Инвалидация алертов и построение SLO — отдельные темы; здесь мы разбирали качество правил и доставку уведомлений.

Что делать дальше

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