Ошибки настройки мониторинга
Мониторинг настроили, алерты приходят, дашборды красивые. Казалось бы — всё работает. Но проходит месяц, и команда перестаёт реагировать на алерты. Одни и те же проблемы повторяются, важные уведомления теряются в потоке, а мониторинг становится источником раздражения, а не пользы.
Причина — типичные ошибки настройки. Их совершают почти все, кто начинает работать с мониторингом. Хорошая новость: этих ошибок можно избежать. В этой статье — разбор самых частых ошибок настройки мониторинга: что упускают, к чему это приводит, как исправить. Если нужно настроить мониторинг правильно — поможем.
1. Слишком много алертов
Самая частая ошибка. Настраивают алерт на каждую метрику — получается 100+ уведомлений в день. Через неделю команда перестаёт их читать.
Что происходит
- Шум: команда утопает в уведомлениях и не может отличить важное от второстепенного;
- Игнор: через неделю алерты перестают читать — это защитная реакция психики;
- Потеря важного: критичный алерт теряется среди 99 неважных;
- Раздражение: мониторинг становится источником стресса, а не пользы.
Как исправить
- Правило: алерт должен требовать действия. Если можно проигнорировать — не нужен;
- 5–10 критичных лучше, чем 100 информационных;
- Переведите часть алертов в дашборды — пусть команда смотрит, но не получает уведомления;
- Разделите по командам: разработчики получают одно, DevOps — другое.
💡 Важно
Проверьте свои алерты: если вы можете неделю их игнорировать и ничего не случится — их слишком много.
2. Строгие пороги
«Поставим порог 50% CPU — на всякий случай». Через день — десятки ложных срабатываний, через неделю — команда не реагирует.
Что происходит
- Ложные срабатывания: алерты на нормальной нагрузке;
- Привыкание: команда привыкает, что алерты — это норма;
- Пропуск реального: когда действительно что-то сломается — не заметят;
- Раздражение: «опять этот мониторинг».
Как исправить
- Смотрите на историю: что было нормой месяц назад;
- Порог = норма + 20–30%, а не «на всякий случай»;
- Длительность: метрика должна отклоняться N минут, а не секунду;
- Разные пороги: для дня и ночи, для разных серверов и сервисов.
3. Все алерты — Critical
Без приоритетов всё «критично». А значит — ничего не критично.
Что происходит
- Нельзя расставить приоритеты: что решать первым;
- Все звонят ночью: даже по мелочам;
- Выгорание: команда не может расслабиться;
- Потеря фокуса: критичное тонет в потоке «критичного».
Как исправить
| Приоритет | Что относится | Как реагировать |
|---|---|---|
| Critical | Сервис не работает, диск заполнен, SSL истекает | Немедленно, ночью звонок |
| Warning | CPU > 80%, RAM > 85%, error rate растёт | В течение рабочего дня |
| Info | Сервис перезапущен, деплой завершён | Ознакомиться, не паниковать |
4. Один канал на всё
Все алерты идут в email. Критичные теряются среди информационных.
Что происходит
- Критичное не выделяется: все сообщения выглядят одинаково;
- Email не читают ночью: проблема ждёт до утра;
- Поток: в почте теряются важные письма;
- Нет срочности: email не воспринимается как срочное.
Как исправить
- Critical: SMS + Telegram + звонок;
- Warning: Telegram + email;
- Info: только дашборд или email-дайджест;
- Дежурный: отдельный канал, отдельный телефон.
5. Нет контекста
Алерт «CPU high» без указания сервера, значения и времени. Непонятно, что делать.
Что происходит
- Долгий разбор: сначала нужно понять, что случилось;
- Ошибки: команда может неправильно интерпретировать проблему;
- Паника: непонятно, критично это или нет;
- Потеря времени: 10 минут на понимание алерта — это 10 минут простоя.
Что должно быть в алерте
- Что: метрика и значение;
- Где: сервер, сервис, среда;
- Когда: время срабатывания;
- Порог: при каком значении сработало;
- Что делать: ссылка на runbook или инструкцию.
Хороший алерт выглядит так: «CPU на web-01 достиг 95% (порог 90%) в 14:32. Runbook: /wiki/cpu-high».
6. Нет эскалации
Дежурный получил алерт, но не отреагировал. И всё — алерт потерян.
Что происходит
- Потеря алертов: никто не знает о проблеме;
- Простой до утра: если ночью никто не отреагировал;
- Единая точка отказа: зависит от одного человека;
- Стресс: дежурный боится пропустить алерт.
Как исправить
- Первый дежурный: получает алерт сразу;
- Если не отреагировал за 5 минут: алерт уходит второму;
- Если и он не отреагировал: руководителю;
- Инструменты: PagerDuty, Opsgenie, Grafana OnCall.
7. Silence навсегда
Замьютили алерт «на время» и забыли. Проблема не замечается месяцами.
Что происходит
- Скрытые проблемы: алерт отключён, проблема остаётся;
- Накопление: через полгода обнаруживается десяток таких silence;
- Потеря мониторинга: фактически часть системы не мониторится;
- Ложное спокойствие: «всё хорошо» — потому что алертов нет.
Как исправить
- Silence с датой: всегда указывайте, когда снимать;
- Ответственный: кто создал — тот и снимает;
- Регулярный аудит: раз в месяц проверяйте активные silence;
- Алерт на silence: если silence висит больше недели — уведомление.
💡 Важно
Silence — это инструмент для плановых работ. Если вы используете его для постоянного отключения алертов — проблема в самих алертах.
8. Нет разбора после
Алерты сработали, проблема решена — но никто не проанализировал, почему это произошло.
Что происходит
- Повторение: одна и та же проблема возвращается снова;
- Потеря опыта: команда не учится на инцидентах;
- Нет улучшений: мониторинг и инфраструктура не развиваются;
- Выгорание: постоянно тушат пожары вместо развития.
Что делать
- Пост-мортем: после каждого значимого инцидента — разбор;
- Документирование: записать причину, решение, что улучшить;
- Действия: конкретные задачи по улучшению;
- Обмен: поделиться с командой — чтобы не повторялось.
9. Только инфраструктура
Мониторят CPU, RAM, диски — но не приложение. А пользователь видит именно приложение.
Что происходит
- CPU в норме, а сайт тормозит: проблема в приложении, не в железе;
- Метрики инфраструктуры зелёные, а пользователи жалуются: ошибки в приложении;
- Пропуск проблем: медленные запросы, ошибки 5xx, проблемы с БД;
- Ложное спокойствие: «всё зелёное», а бизнес теряет деньги.
Что добавить
- Метрики приложения: response time, RPS, error rate;
- Метрики БД: slow queries, connections, replication lag;
- Бизнес-метрики: заказы, регистрации, платежи;
- Uptime-мониторинг: проверка доступности снаружи.
10. Нет доступа команде
Только админ видит дашборды. Остальные работают вслепую.
Что происходит
- Зависимость: вся информация у одного человека;
- Медленная реакция: нужно ждать, пока админ посмотрит;
- Нет проактивности: разработчики не могут сами проверить свои сервисы;
- Слепые решения: правки делают без понимания последствий.
Что настроить
- Права доступа: роли viewer / editor / admin;
- Дашборды для ролей: разработчики, DevOps, бизнес;
- Обучающие сессии: как читать метрики и дашборды;
- Ссылки на дашборды: в документации и в runbook'ах.
Наши рекомендации
Что вы получаете, заказывая аудит мониторинга у нас
- Аудит алертов — что лишнее, что упущено
- Аудит порогов — реалистичность и обоснованность
- Аудит каналов — правильные приоритеты
- Аудит дашбордов — что смотреть в первую очередь
- Рекомендации — что улучшить и как
- Обучение — как работать с мониторингом
📌 Итоговый вывод
Ошибки настройки мониторинга — это раздражение команды и потерянные проблемы.
Что нужно знать:
- Слишком много алертов — их перестают читать
- Строгие пороги — постоянные ложные срабатывания
- Все Critical — ничего не критично
- Один канал — критичное теряется
- Нет контекста — долгий разбор
- Нет эскалации — потерянные алерты
- Silence навсегда — скрытые проблемы
- Нет разбора — повторение проблем
- Только инфраструктура — пропуск проблем приложения
- Нет доступа команде — слепые решения
Также рекомендуем: зачем нужен мониторинг, Zabbix или Prometheus, ключевые метрики, настройка алертов, Grafana, мониторинг серверов.