Настройка алертов мониторинга
Мониторинг без алертов — это просто красивые графики. Алерты превращают данные в действие: когда что-то идёт не так, вы узнаёте об этом сразу. Но есть проблема: если алертов слишком много, их начинают игнорировать. Если слишком мало — пропускают важное.
Хорошая новость: правильная настройка алертов — это не магия, а методология. Приоритеты, пороги, эскалация, каналы — всё это можно настроить так, чтобы алерты помогали, а не мешали. В этой статье — разбор того, как правильно настроить алерты мониторинга. Если нужно настроить мониторинг с алертами — поможем.
Зачем нужны алерты
Алерты — это способ превратить данные мониторинга в действие. Без них вы видите графики, но не знаете, когда реагировать. Разница между «мы видим метрики» и «мы реагируем на метрики» — принципиальная.
Раннее обнаружение
Вы узнаёте о проблеме до того, как она станет критичной. Время на реакцию — минуты, а не часы.
Минимальный простой
Проблемы решаются быстрее. Простой сокращается с часов до минут. Каждая минута — сэкономленные деньги.
Спокойствие команды
Команда знает, что система сообщит о проблеме. Не нужно постоянно смотреть графики и переживать, что что-то пропустят.
Данные для решений
История алертов показывает, какие проблемы повторяются и что нужно улучшить. Это основа для плана развития инфраструктуры.
Принципы хороших алертов
Хороший алерт — это тот, на который хочется реагировать. Плохой — тот, который игнорируют. Вот принципы, по которым строятся работающие алерты.
1. Алерт требует действия
Если на алерт не нужно ничего делать — он не нужен. Уберите его или переведите в дашборд. Каждый алерт — это прерывание работы человека, это должно быть оправдано.
2. Алертов должно быть мало
5–10 важных алертов лучше, чем 100 неважных. Если алертов слишком много — их перестают читать. Это психология: чем больше сигналов, тем меньше внимания к каждому.
3. Алерт — с контекстом
В алерте должно быть понятно: что случилось, где, что делать. Без контекста алерт бесполезен — человек тратит время на выяснение деталей вместо решения проблемы.
4. Приоритеты
Не все алерты одинаково важны. Критичные — звонок. Важные — Telegram. Информационные — email. Если всё «критично», то ничего не критично.
5. Дедупликация
Одна проблема — один алерт. Не нужно отправлять 50 сообщений, если сервер лежит. Группировка и дедупликация экономят внимание команды.
💡 Важно
Проверьте свои алерты: если вы можете неделю их игнорировать и ничего не случится — их слишком много. Сократите до минимума.
Пороги
Порог — это значение метрики, при котором срабатывает алерт. Важно выбрать реалистичные пороги, а не «на всякий случай».
Принципы выбора порогов
- Норма + запас: порог должен быть выше нормы на 20–30%;
- Длительность: метрика должна отклоняться N минут, а не секунду — это отсекает случайные всплески;
- Историчность: смотрите на прошлые данные — что было нормой месяц назад;
- Разные пороги для дня и ночи: ночью нагрузка ниже — это может быть нормально;
- Разные для разных серверов: web-сервер и БД — разные пороги и разное поведение.
Примеры порогов
| Метрика | Порог | Длительность | Приоритет |
|---|---|---|---|
| CPU usage | > 80% | 5 минут | Warning |
| CPU usage | > 95% | 1 минута | Critical |
| RAM usage | > 85% | 5 минут | Warning |
| Swap usage | > 30% | 1 минута | Critical |
| Disk usage | > 80% | — | Warning |
| Disk usage | > 90% | — | Critical |
| Service down | — | 1 минута | Critical |
| Error rate | > 1% | 5 минут | Warning |
| Response time p95 | > 1 сек | 5 минут | Warning |
Пороги не должны быть одинаковыми везде. Для продакшена — строже, для теста — мягче. Для БД — одни значения, для веб-серверов — другие.
Приоритеты
Приоритеты определяют, как быстро реагировать и насколько громко звонить. Это основа для разделения алертов по каналам и эскалации.
Critical
Сервис не работает или вот-вот упадёт. Реагировать немедленно.
- Сервис недоступен
- Диск заполнен > 95%
- RAM > 95%
- SSL истекает
- Репликация БД отстаёт
Warning
Что-то приближается к пределу. Разобраться в течение дня.
- CPU > 80%
- RAM > 85%
- Диск > 80%
- Error rate > 1%
- p95 response time растёт
Info
Информационные сообщения. Ознакомиться, но не паниковать.
- Сервис перезапущен
- Деплой завершён
- Кончились бэкапы
- Обновились метрики
- Новый сервер добавлен
Каналы уведомлений
Разные приоритеты — разные каналы. Критичные алерты не должны теряться в потоке email.
| Канал | Для чего | Плюсы | Минусы |
|---|---|---|---|
| Telegram | Все приоритеты | Быстро, удобно, бесплатно | Может заглушаться |
| Info, дайджесты | Архив, поиск | Медленно, теряется в спаме | |
| SMS | Critical | Не пропустишь | Дорого, зависит от оператора |
| Звонок | Critical (критичные системы) | Точно разбудит | Дорого, стресс |
| Slack | Командные уведомления | Обсуждение в команде | Не для критичных |
| Webhook | Интеграции | Гибко | Требует настройки |
Рекомендации по каналам
- Critical: SMS + Telegram + звонок (для самых критичных);
- Warning: Telegram + email;
- Info: только email или дашборд;
- Дежурный: отдельный телефон/канал только для дежурств;
- Разные каналы для разных команд: разработчики и DevOps могут получать разные алерты.
Эскалация
Эскалация — это передача алерта следующему человеку, если первый не отреагировал. Критично для сервисов, которые работают круглосуточно.
Как настроить
- Первый дежурный: получает алерт сразу;
- Если не отреагировал за 5 минут: алерт уходит второму дежурному;
- Если и он не отреагировал: уходит руководителю;
- Запись инцидента: все действия логируются для разбора.
Что важно
- Дежурства ротируются: нельзя, чтобы один человек всегда был на связи — это выгорание;
- Дежурный освобождён: если он дежурит, у него нет других задач;
- Инструменты: PagerDuty, Opsgenie, Grafana OnCall;
- Только для Critical: не нужно эскалировать warning-алерты — иначе потеряют смысл;
- Плановая ротация: минимум раз в неделю, чтобы у всех был опыт.
Silence и дедупликация
Silence
Silence — это отключение алертов на определённое время. Нужно, когда вы знаете о проблеме и работаете над ней.
- Плановые работы: отключить алерты на время технических работ;
- Известная проблема: замьютить до исправления;
- Правило: silence должен быть на время, не навсегда;
- Ответственный: кто создал silence — тот и снимает.
Дедупликация
Дедупликация — это объединение одинаковых алертов в один. Без неё одна проблема порождает 100 сообщений и команда устаёт.
- Группировка по сервису: все алерты по БД — в один;
- Группировка по причине: «диск заполнен» — один алерт на все разделы;
- Интервал: не отправлять повторно в течение N минут;
- Разные интервалы: для Critical — короткий, для Info — длинный.
Типичные ошибки
Слишком много алертов
100+ алертов в день. Команда игнорирует их. Важные теряются в потоке.
Слишком строгие пороги
Алерты срабатывают на нормальной нагрузке. Постоянные ложные срабатывания.
Все алерты — Critical
Нет приоритетов. Всё «критично» — значит, ничего не критично.
Один канал на всё
Все алерты в email. Критичные теряются среди информационных.
Нет контекста
Алерт «CPU high» без указания сервера и значения. Непонятно, что делать.
Нет эскалации
Дежурный не отреагировал — алерт потерян. Никто не знает о проблеме.
Silence навсегда
Замьютили алерт «на время» и забыли. Проблема не замечается месяцами.
Нет разбора после
Алерты сработали, проблема решена — но не проанализирована. Повторится снова.
Наши рекомендации
Что вы получаете, заказывая алерты у нас
- Набор алертов — 5–10 критичных для старта
- Приоритеты — Critical / Warning / Info
- Каналы — Telegram, email, SMS
- Эскалация — для critical на дежурных
- Дедупликация — без спама и повторов
- Silence — на плановые работы
📌 Итоговый вывод
Настройка алертов — это баланс между чувствительностью и шумом.
Что нужно знать:
- Принципы — алерт требует действия, их должно быть мало, с контекстом
- Пороги — норма + 20–30%, с длительностью, разные для дня и ночи
- Приоритеты — Critical / Warning / Info
- Каналы — Telegram для всех, SMS и звонок для critical
- Эскалация — для критичных систем, с ротацией дежурных
- Silence — на время, не навсегда
- Дедупликация — одна проблема — один алерт
- Ошибки — слишком много, строгие пороги, все critical, один канал
Также рекомендуем: зачем нужен мониторинг, Zabbix или Prometheus, ключевые метрики, Grafana, ошибки мониторинга, мониторинг серверов.