Серверные алерты без шума: как настроить сигналы, на которые реагируют

Алерт должен требовать действия, а не просто сообщать о метрике

Если сервер шлёт десятки уведомлений о кратких скачках нагрузки, дежурный быстро перестаёт их читать. Если же сигнал приходит только после того, как пользователи уже не могут оформить заказ, он опоздал. Для связки Prometheus 3.x и Alertmanager 0.27.x задача — не добавить побольше порогов, а связать сигнал с пользовательским последствием и понятным следующим шагом.

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

Сначала решите, кого и о чём будить

Алерт нужен, когда человеку пора что-то сделать. Рост загрузки процессора сам по себе ещё не авария: сервис может отвечать быстро, а нагрузка — быть штатной. Полезный сигнал описывает нарушение, которое уже влияет на доступность, задержку, ошибки или запас ресурсов.

Перед добавлением правила ответьте на четыре вопроса:

• Что сломалось для пользователя? Например, запросы к API стали чаще завершаться ошибкой или перестали укладываться в допустимое время.
• Кто отвечает за проблему? Укажите команду или владельца сервиса, а не только общий канал.
• Что должен сделать дежурный? Проверить зависимость, перейти к панели, включить аварийный план или передать инцидент другой команде.
• Насколько срочно? Разделите ситуацию, требующую немедленной реакции, и ту, которую достаточно разобрать в рабочее время.

Если на вопрос о действии нет ответа, метрика, скорее всего, нужна на дашборде, а не в канале срочных уведомлений.

Выберите сигнал под тип проблемы

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

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

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

Сделайте сигнал устойчивым к кратким всплескам

В Prometheus правило может оставаться в состоянии ожидания заданное время, прежде чем перейти в срабатывание. Это помогает отсеять краткий шум, но не должно превращаться в привычку откладывать все уведомления на одинаковый срок.

1. Определите, какое ухудшение действительно важно. Для доступности и ошибок используйте метрики, отражающие запросы пользователя. Для инфраструктурного риска — ресурс и оставшийся запас. Проверка: команда может назвать конкретный ущерб, который означает срабатывание.
2. Выберите длительность подтверждения по поведению сигнала. Посмотрите историю метрики во время обычной работы и известных инцидентов. Проверка: штатные краткие пики не будят команду, а реальная проблема обнаруживается раньше, чем исчерпывает запас.
3. Разведите предупреждение и срочный инцидент. Предупреждение оставляет время на плановую реакцию; критический уровень означает, что пользовательский путь уже нарушен или скоро станет недоступен. Проверка: для каждого уровня понятно, кто и в какой канал получает уведомление.
4. Добавьте контекст и инструкцию. В описании укажите сервис, проявление проблемы, ссылку на панель и короткое действие для дежурного. Проверка: человек, который не писал правило, может начать диагностику без поиска автора.
5. Проверьте путь до получателя. Убедитесь, что правило срабатывает, Alertmanager выбирает ожидаемый маршрут, а уведомление доходит до нужного канала. Проверка: проведён тестовый сигнал и зафиксирован ответственный за его обработку.

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

Сгруппируйте уведомления, но не прячьте разные аварии

Alertmanager умеет группировать и маршрутизировать уведомления, а также подавлять связанные сигналы через правила inhibition. Это не заменяет хорошее условие в Prometheus: группировка сокращает поток сообщений, но не делает ложное срабатывание полезным.

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

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

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

Когда выбирать какой подход

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

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

Что чаще всего ломает алертинг

• Срабатывание на каждую реплику. Один общий сбой превращается в десятки сообщений. Проверьте группировку по сервису и то, содержит ли уведомление перечень затронутых экземпляров.
• Правило без минимального трафика. Несколько ошибок дают большой процент при почти пустом сервисе. Учитывайте объём запросов или применяйте отдельный сигнал о недоступности.
• Нет владельца и инструкции. Сообщение доходит в общий канал, но никто не понимает, кто дежурит и куда смотреть. Добавьте владельца и проверенную ссылку на рабочую панель или runbook.
• Порог настроен по спокойному дню. После релиза, сезонного пика или изменения архитектуры прежняя норма уже не описывает систему. Пересматривайте правила после существенных изменений и инцидентов.
• Тестировали только условие. Правило сработало в Prometheus, но сообщение не дошло из-за маршрута или настройки получателя. Проверяйте весь путь до человека.

Не отключайте шумный алерт молча. Зафиксируйте, почему он срабатывает, измените условие или маршрут, а затем проверьте, что реальная авария всё ещё заметна. Иначе временное подавление станет постоянной слепой зоной.

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

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

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