Миф: если есть мониторинг, я узнаю о проблеме первым

MAATRIX

У вас стоит Zabbix, Uptime Kuma или связка Prometheus + Grafana, алерты падают в Telegram — и вы уверены, что теперь узнаете о любой проблеме раньше клиентов. Это разумное ожидание: мониторинг для того и придуман. Но на практике разрыв между «мониторинг настроен» и «вы узнали первым» случается регулярно — и почти всегда по одной из четырёх предсказуемых причин.

Рациональное зерно: мониторинг действительно должен опережать пользователей

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

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

Причина 1: мониторинг видит только то, что в него заложили

Любая система мониторинга — это конечный список проверок: доступность порта, код ответа HTTP, использование диска, память, CPU, наличие процесса. Всё, что не входит в этот список, для мониторинга не существует.

Классический пример: сайт отвечает 200 OK, Uptime Kuma довольна, а на деле форма оформления заказа возвращает ошибку из-за упавшей интеграции с платёжным шлюзом. HTTP-код корневой страницы никак не связан со здоровьем конкретной бизнес-функции в глубине сайта.

# то, что вы обычно проверяете
curl -o /dev/null -s -w "%{http_code}\n" https://example.com/
# 200

# то, что реально важно пользователю
curl -X POST https://example.com/api/checkout -d '{"cart_id":123}'
# может отдавать 500, пока корневая страница светится зелёным

Та же логика касается редких edge-случаев: переполнение конкретной очереди задач, исчерпание file descriptors у одного процесса, деградация ответа API у стороннего сервиса, от которого зависит часть функциональности. Пока кто-то явно не добавил проверку именно этого сценария — мониторинг о нём ничего не знает и знать не может. «Мониторинг всего» не бывает физически: это всегда набор конкретных гипотез о том, что может сломаться, а реальность регулярно ломается способом, который в эти гипотезы не попал.

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

Причина 2: алерт отправлен — но не замечен человеком

Технически мониторинг может выполнить свою часть работы идеально: обнаружить проблему за секунды и отправить уведомление. А дальше начинается человеческий фактор, который в схему «настроил и забыл» обычно не закладывают.

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

Второй, более коварный сценарий — «усталость от алертов» (alert fatigue). Если пороги настроены слишком чувствительно и система шлёт по 40 уведомлений в день, из которых 38 — ложные срабатывания (кратковременный всплеск CPU при плановой задаче, временная задержка ответа при пиковой нагрузке), человек довольно быстро перестаёт реагировать на алерты вообще. Психологически это неизбежно: мозг обучается игнорировать сигнал, который в 95% случаев ни на что не влияет. В итоге настоящий инцидент тонет в том же потоке, что и шум, и реагируют на него не по алерту, а по жалобе клиента — то есть миф не выполняется на практике, хотя технически мониторинг «своё дело сделал». Частые причины именно такого шума и способы их убрать разобраны в статье про типовые ошибки алертов в Telegram.

Лечится это не отключением алертов, а их калибровкой:

• разделять каналы по критичности (критично — отдельный чат с звуком, информационно — общий лог);
• вводить пороги с гистерезисом (алерт при превышении X в течение N минут подряд, а не по одному пику);
• группировать связанные алерты в один инцидент вместо десяти отдельных сообщений о падении одного и того же сервиса;
• регулярно чистить правила, которые дают ложные срабатывания чаще, чем реальные проблемы.

Причина 3: мониторинг может упасть вместе с тем, что он проверяет

Отдельная категория провалов — когда сама система мониторинга физически зависит от той же инфраструктуры, за которой следит. Если Zabbix-сервер и веб-приложение сидят на одной VPS, а у VPS отваливается сеть целиком, то падает не только сайт — падает и мониторинг вместе с механизмом отправки алертов. Формально проблема была «обнаружена» за долю секунды до того, как оборвалась связь, но уведомление никуда не ушло, потому что сеть уже недоступна.

То же самое с электропитанием на своём железе, с общей точкой отказа в виде одного маршрутизатора или одного дата-центра, с зависимостью алертов от того же почтового сервера, который отправляет письма пользователям (и который тоже может лежать).

Плохо:                              Лучше:
┌─────────────────┐                ┌─────────────────┐      ┌──────────────────┐
│   Сервер А       │                │   Сервер А       │      │  Внешний сервис   │
│  ┌────────────┐  │                │  ┌────────────┐  │      │  мониторинга      │
│  │ Приложение │  │                │  │ Приложение │  │◄─────┤  (другой дата-    │
│  ├────────────┤  │                │  └────────────┘  │      │  центр/провайдер) │
│  │ Мониторинг │  │  ← оба падают  │                   │      └─────────┬────────┘
│  └────────────┘  │    вместе      └───────────────────┘                │
└─────────────────┘                                                       ▼ алерт уходит,
                                                                            пока сервер А
                                                                            недоступен

Решение — вынести хотя бы базовую проверку доступности (ping/HTTP-чек) на независимую от основной инфраструктуры точку: внешний сервис мониторинга в другом дата-центре, а лучше — у другого провайдера. Именно так строится классическая связка «своя VPS с Uptime Kuma + внешний сторожевой сервис», описанная в статье про инструменты мониторинга доступности сайта. Если у вас критичный проект, разумно держать и внешнюю точку контроля в отдельной локации — например, арендовать недорогую VPS в другом регионе только под задачу мониторинга, не размещая на ней ничего из основного стека.

Причина 4: интервал опроса — это встроенная задержка обнаружения

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

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

Для по-настоящему быстрых сценариев (высоконагруженный продакшен, где минута простоя стоит денег) интервал стоит сокращать до секунд, но это почти всегда означает переход с бесплатного тарифа внешнего сервиса на платный или на собственный агент с активным push-уведомлением вместо пассивного опроса (например, healthcheck внутри самого приложения, который сам сигнализирует при отклонении, а не ждёт, пока его спросят).

Как понять, что мониторинг действительно опережает пользователей

Проверить миф на практике можно не рассуждениями, а конкретным тестом. Возьмите последние 3-5 реальных инцидентов (даже мелких) и по каждому ответьте на четыре вопроса:

1. Была ли в системе проверка именно этого сценария до инцидента, или её пришлось добавлять постфактум?
2. Алерт вообще пришёл, или о проблеме узнали из внешнего источника (жалоба, ручная проверка)?
3. Если алерт пришёл — сколько времени прошло до реакции человека, и не потерялся ли он среди других уведомлений?
4. Была ли задержка между наступлением проблемы и первой проверкой мониторинга критичной для этого конкретного случая?

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

Частые вопросы