Алерты, которые не игнорируют: чек-лист перед продом

Почему алерт перестают читать уже через неделю

Алерт на загрузку CPU выше 80% может срабатывать десятки раз в день и не требовать никаких действий. Через неделю команда начнёт закрывать его автоматически, а вместе с ним пропустит настоящий отказ. Для связки Prometheus 2.x и Alertmanager 0.27.x перед продакшеном нужно проверить не только условие, но и весь путь: от метрики до уведомления, инструкции и результата.

Ниже — практический чек-лист для сервисов, где важны доступность, задержка и ошибки. Он не заменяет настройку SLO и отдельный разбор инцидентов, но помогает отсеять самые дорогие дефекты алертинга до первой ночной аварии.

Хороший алерт отвечает на три вопроса: что сломалось, насколько это опасно и какое действие нужно выполнить первым.

1. Сначала определите, какое действие запускает сигнал

Не начинайте с порога метрики. Начните с вопроса: что должен сделать дежурный после уведомления. Если ответ звучит как «посмотреть графики» или «разобраться», это пока не алерт, а заготовка для наблюдения.

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

У каждого критического алерта должен быть владелец: команда, канал и смена, которая отвечает за реакцию. Название сервиса в метках должно совпадать с тем, как он называется в каталоге и в инструкции по эксплуатации. Иначе уведомление придёт, но искать ответственного придётся вручную.

2. Проверьте, что условие ловит проблему, а не шум

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

Четыре типа сигналов

Бюджет ошибок¹ — допустимая доля времени или запросов, которые могут выйти за пределы SLO. Если сервис обещает 99,9% доступности, бюджет — не «ещё один график», а ограниченный ресурс для релизов и изменений.

Для клиентского алерта выбирайте симптом, который можно измерить со стороны пользователя. Высокий CPU не означает отказ: приложение может работать нормально при полной загрузке процессора. А вот доля HTTP 5xx, успешность фоновых задач или задержка на границе заданного SLO напрямую связаны с последствиями.

3. Разведите срочность и канал

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

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

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

4. Сделайте карточку алерта исполняемой

Текст должен быть понятен без открытия Prometheus. В нём нужны:

1. Короткое имя проблемы. Не «High value», а «Пять процентов запросов API завершаются ошибкой».
2. Окружение и сервис. Продакшен, регион, кластер и имя компонента.
3. Масштаб. Текущее значение, порог и длительность нарушения.
4. Последствие. Например, «пользователи не могут оформить заказ».
5. Первое действие. Ссылка на runbook с командой проверки, дашбордом и условиями эскалации.
6. Владелец. Команда и резервный контакт, а не имя одного сотрудника.

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

5. Проверьте граничные случаи

Нет данных — это не всегда ноль

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

Перезапуск не должен стирать проблему

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

Агрегация не должна прятать один плохой узел

Среднее значение по кластеру способно скрыть один перегруженный экземпляр. Для пользовательских ошибок и доступности смотрите агрегат, а для容量 и диагностики добавляйте разрез по узлу, зоне или экземпляру. Эти сигналы не обязаны будить дежурного, но должны помогать объяснить причину.

Время и метки должны быть стабильными

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

6. Прогоните алерты как сценарий аварии

До продакшена не ограничивайтесь проверкой синтаксиса правила. Нужен контролируемый тест на стенде или на отдельном тестовом сервисе. Зафиксируйте время появления условия, время создания алерта, время доставки и время подтверждения получения. Разница между этими моментами показывает, где находится задержка.

1. Создайте безопасное условие, которое гарантированно нарушает порог.
2. Убедитесь, что Prometheus перевёл алерт из pending в firing после заданной задержки.
3. Проверьте, что Alertmanager выбрал правильный маршрут и не отправил лишние копии.
4. Нажмите на ссылку из уведомления: дашборд, runbook и информация о владельце должны открываться без ручного поиска.
5. Проверьте восстановление: после возврата метрики в норму приходит resolved-уведомление или закрывается задача по принятому в команде процессу.

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

Когда сигнал нужно переделать, а не настроить тише

Долгие mute-правила и увеличение задержки firing часто маскируют плохой дизайн. Перед изменением порога ответьте на четыре вопроса:

• Сколько уведомлений за последние семь дней не потребовали действий?
• Сколько реальных инцидентов не имели алерта?
• Может ли дежурный понять влияние на пользователя по одной карточке?
• Есть ли безопасный способ воспроизвести условие и проверить доставку?

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

Что делать после чек-листа

Составьте для каждого page-алерта таблицу: условие, пользовательское последствие, владелец, канал, runbook, время реакции и способ тестирования. Затем измеряйте не количество алертов, а долю уведомлений, которые привели к действию, время подтверждения и число инцидентов без сигнала.

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

¹ SLO, или Service Level Objective, — целевой уровень качества сервиса, например допустимая доля успешных запросов или максимальная задержка.