Как строить алерты, которые не раздражают. Alert fatigue и лучшие практики

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

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

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

Что такое alert fatigue и почему она возникает

Alert fatigue — это состояние, при котором специалисты перестают воспринимать уведомления мониторинга как важные из-за их чрезмерного количества или низкого качества.

Типичный сценарий:

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

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

Основные причины alert fatigue:

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

Например, алерт:

CPU usage > 80%

сам по себе мало полезен.

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

Гораздо полезнее:

CPU usage > 90% в течение 15 минут
AND
load average превышает количество CPU
AND
есть рост времени ответа приложения

Такой сигнал уже говорит о возможной деградации сервиса.

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

Одна из самых распространенных ошибок — строить мониторинг вокруг отдельных показателей.

Например:

свободное место на диске меньше 20%;
RAM используется на 85%;
количество соединений к базе больше 500.

Но сами по себе эти значения не всегда означают проблему.

Лучший подход — ориентироваться на пользовательский опыт и состояние сервиса.

Вместо:

Disk usage > 80%

лучше:

Disk will be full in less than 24 hours

Вместо:

Memory usage > 90%

лучше:

Application restarted 5 times in the last 10 minutes due to OOM

Второй вариант дает инженеру информацию о последствиях, а не просто показывает изменение одной метрики.

Используйте уровни критичности

Не каждый алерт должен будить инженера ночью.

Обычно достаточно нескольких уровней:

Critical

Ситуация требует немедленной реакции.

Примеры:

сервис недоступен;
база данных не принимает соединения;
массовые ошибки 5xx;
закончилась свободная память и приложение падает.

Такие события могут отправляться через:

телефонные звонки;
PagerDuty;
Telegram/MAX;
SMS.

Warning

Проблема потенциально развивается, но прямо сейчас сервис работает.

Примеры:

диск заполнен на 80%;
выросло время ответа;
увеличилась очередь задач.

Такие уведомления обычно идут в рабочие каналы.

Info

События для анализа:

перезапуск сервиса;
изменение конфигурации;
выполнение резервной копии.

Они не должны создавать тревогу.

Используйте окна времени и устойчивые условия

Один из главных источников шума — реакция на кратковременные изменения.

Например:

RAM usage > 90%

может сработать из-за секундного скачка.

Лучше:

RAM usage > 90% for 10 minutes

или:

Average RAM usage over 15 minutes > 90%

То же относится к CPU, нагрузке, сетевому трафику и количеству ошибок.

Мониторинг должен отличать временный всплеск от настоящей деградации.

Не создавайте алерты на все метрики

Современные системы мониторинга могут собирать тысячи показателей:

CPU;
память;
диски;
сеть;
контейнеры;
базы данных;
приложения;
бизнесовые метрики.

Но далеко не каждая метрика должна иметь алерт.

Например, полезно собирать:

node_cpu_seconds_total
node_memory_MemAvailable_bytes
container_cpu_usage_seconds_total
http_request_duration_seconds

Но это не означает, что для каждой нужно создавать уведомление.

Хороший вопрос перед добавлением алерта:

Если это событие произойдет ночью, я действительно хочу проснуться и что-то сделать?

Если ответ "нет", возможно, это просто метрика для анализа.

Добавляйте контекст в уведомления

Плохой алерт:

Disk alert on server01

Инженеру придется самому искать:

какой диск;
сколько осталось места;
какой сервис использует место;
насколько срочно нужно реагировать.

Хороший алерт:

CRITICAL: Disk space low

Server:
web-prod-01

Filesystem:
/var

Usage:
92%

Available:
18 GB

Prediction:
disk will be full in ~6 hours

Possible cause:
large application logs

Runbook:
https://internal/wiki/disk-cleanup

Чем больше полезной информации содержит алерт, тем меньше времени занимает реакция.

Используйте SLO вместо случайных порогов

Один из лучших подходов современного мониторинга — строить алерты вокруг SLO (Service Level Objectives).

Например, вместо:

CPU > 80%

можно использовать:

99.9% запросов должны отвечать быстрее 500 мс

Если инфраструктура работает нормально, высокая загрузка CPU сама по себе не является проблемой.

Если пользователи начинают получать ошибки или задержки — это уже повод для реакции.

SLO помогают связать технические показатели с реальным качеством сервиса.

Удаляйте бесполезные алерты

Мониторинг требует постоянного обслуживания.

Хорошая практика:

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

Если алерт несколько месяцев не приводил к действиям, стоит задать вопрос: нужен ли он вообще?

Автоматизация вместо уведомлений

Иногда лучше не отправлять алерт человеку, а автоматически исправить проблему.

Примеры:

перезапустить упавший контейнер;
очистить временные файлы;
расширить диск в облаке;
перезапустить зависший worker.

Автоматическое восстановление уменьшает количество ручных действий и снижает нагрузку на команду.

Заключение

Хороший мониторинг — это не максимальное количество алертов. Это минимальное количество уведомлений, каждое из которых имеет значение.

Главные принципы качественных алертов:

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

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

Как строить алерты, которые не раздражают. Alert fatigue и лучшие практики

Настроить мониторинг за 30 секунд