Мониторинг, который никто не читает: как настроить алерты без ложных тревог

У мониторинга два режима отказа. Первый очевиден: его нет, и о падении сайта сообщают клиенты. Второй коварнее: мониторинг есть, но алертов так много, что их перестали читать. Чат с уведомлениями замьючен, и настоящая авария тонет в потоке «CPU 81%». Формально система работает; фактически её нет.

Откуда берётся шум

Пороги, выставленные наугад. «Алерт при CPU выше 70%» звучит разумно, пока не выясняется, что ваш сервер штатно живёт на 75% в часы рассылок. Проверки слишком чувствительны: один таймаут из-за сетевой икоты — тревога. Всё летит в один канал с одинаковой важностью: упавший сайт и истекающий через месяц сертификат выглядят одинаково. Итог предсказуем — через месяц канал мьютят.

Правило: алерт — это то, с чем нужно что-то делать

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

Три уровня вместо одного потока

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

Калибровка — обязательный этап, а не роскошь

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