Что это решает
Сообщение клиента «у вас ничего не открывается» как первый источник информации об аварии стоит дорого: к моменту письма поломка живёт уже несколько часов, репутационный ущерб нанесён, а разбираться приходится по памяти. Мониторинг переставляет очередь: первым узнаёт система, вторым — дежурный человек, клиент в идеале не узнаёт вовсе. Закрываются три разных случая: тихое падение ночью, деградация без падения (сервис отвечает, но медленно или частично) и поломки на краях — истёкший сертификат, забитый диск, молча не отработавший крон, отвалившаяся интеграция.
Как устроено
1. Внешняя проба
HTTP-запрос к сервису из точки вне его инфраструктуры, с интервалом порядка минуты. Проверяется не только код ответа, но и наличие ожидаемой строки на странице: заглушка хостера отдаёт честные 200, а сайта при этом нет. Внешняя точка обязательна — проба, живущая на том же сервере, умрёт вместе с ним и не пришлёт ничего.
2. Health-check
Отдельный маршрут в приложении, который проверяет зависимости и отдаёт короткий JSON: база отвечает, очередь жива, хранилище доступно, миграции применены, свободного места достаточно. Его дёргают и внешняя проба, и балансировщик. Проверки внутри держат лёгкими: health-check, который сам создаёт нагрузку на базу, добивает сервис в худший момент.
3. Метрики
Числа с привязкой ко времени: запросов в секунду, доля ошибочных ответов, время ответа по перцентилям, загрузка процессора, памяти и диска, длина очереди задач. Среднее время ответа скрывает беду — считают p95 и p99, потому что страдают именно хвосты. Метрики складываются в базу временных рядов, рисуются графиками и служат основой порогов.
4. Трекер ошибок
Исключение из кода уходит в трекер (Sentry, GlitchTip и подобные) со стеком вызовов, версией релиза, идентификатором пользователя и «хлебными крошками» — цепочкой последних действий перед падением. Одинаковые ошибки группируются, у группы есть счётчик событий и число затронутых людей. Отдельно ловится регрессия: ошибка, помеченная закрытой, появилась снова после выката.
5. Логи
Последняя инстанция при разборе. Приносят пользу, когда пишутся структурно (JSON, а не свободный текст) и содержат идентификатор запроса, по которому собирается вся цепочка от входа до ответа. Логи отвечают на вопрос «что именно произошло с этим конкретным заказом», а не «всё ли хорошо».
6. Heartbeat
Обратная проба для того, что должно происходить по расписанию: ночная выгрузка, бэкап, рассылка, пересчёт. Задача сама дёргает выделенный URL после успешного завершения. Если сигнала нет в оговорённое окно — тревога. Обычная проба доступности сервера про несработавший крон не знает ничего: сервер жив, а выгрузки нет вторую неделю.
7. Бизнес-метрика
Заказов в час, оплат в час, регистраций в день. Ловит поломки, невидимые технически: все ответы 200, ошибок в трекере нет, а кнопка оплаты не работает из-за правки вёрстки или платёжный шлюз молча отклоняет всё. Порог задаётся с оглядкой на суточный и недельный профиль, иначе воскресная ночь будет звонить каждую неделю.
Маршрутизация тревог
Порог формулируется вместе с длительностью: не «случилась ошибка», а «доля ответов 5xx выше порога пять минут подряд». Одинаковые срабатывания склеиваются, чтобы двести писем за минуту превратились в одно. На время выката ставится окно тишины. Каналы делятся по важности: то, ради чего будят ночью, идёт в мессенджер или звонком, остальное — в утренний дайджест. К каждому правилу пишется короткая инструкция: что означает, куда смотреть, что сделать первым, кого звать, если не помогло.
Полезные сценарии
- Внешняя проба главной и страницы входа раз в минуту с проверкой конкретной строки в ответе.
- Heartbeat на ночную выгрузку и на бэкап: молчание — такая же тревога, как ошибка.
- Порог по доле ответов 5xx и отдельно по p95 времени ответа: деградация приходит раньше падения.
- Срок действия TLS-сертификата и оплаченного домена с предупреждением сильно заранее.
- Свободное место на диске по тренду — предупреждение за неделю до заполнения, а не в момент отказа записи.
- Ноль оплат за два часа рабочего времени как бизнес-канарейка поверх всей технической цепочки.
- Длина очереди задач и возраст самой старой задачи в ней.
- Новый тип ошибки после релиза и возврат ранее закрытой ошибки.
Ограничения
Мониторинг внутри той же инфраструктуры падает вместе с ней. Хотя бы одна проба должна жить снаружи и уметь достучаться до человека независимо от основного сервера.
Шум обесценивает всю систему. Когда тревог больше, чем дежурный способен обработать, их перестают читать целиком, и настоящая авария тонет среди привычных. Признак здоровья простой: все срабатывания за месяц можно перечислить и по каждому сказать, что было сделано.
Это стоит денег и времени. Внешние сервисы считают по числу проверок и объёму событий, свой стек — сервер, диск под ряды и логи, обновления и дежурство. Хранение логов растёт быстрее, чем кажется на старте.
Мониторинг ловит поломку в проде, но не мешает ей туда попасть — эту работу делают тесты и ревью. Одно другим не подменяется.
Покрыть всё нельзя. Останутся сценарии, которые видит только живой пользователь на своём устройстве со своим набором расширений в браузере.
Выкаты дают ложные всплески. Без окна тишины команда быстро привыкает отмахиваться от тревог во время релиза, а вместе с ними пропускает настоящие.
Тревога, у которой нет обязанного реагировать адресата, работает как запись в журнале — до неё дойдут руки когда-нибудь.
Персональные данные утекают в трекеры ошибок через параметры запросов, тела форм и «хлебные крошки» логов. Фильтр на стороне отправки настраивается до первого боевого события, а не после.
Как проверить результат
Учебная поломка. Остановить сервис на стенде или вернуть 500 на специально заведённом маршруте и засечь секундомером время от поломки до сообщения на телефоне. Это единственная честная метрика всей системы; всё остальное — намерения.
Проверка heartbeat: отключить крон на стенде и дождаться тревоги в назначенное окно. Молчание означает, что расписание и порог разошлись.
Проверка пути доставки: убедиться, что ночное сообщение приходит туда, куда человек реально смотрит ночью. Почтовый ящик, открываемый в десять утра, для критичного канала не годится.
Ревизия за месяц. Выписать все сработавшие тревоги и отметить, какие потребовали действия. Если действий потребовала меньше половины, чистить пороги, а не добавлять новые правила.
Проверка инструкции. Дать runbook случайной тревоги человеку, который его не писал, и посмотреть, дойдёт ли он по шагам до конца без вопросов.
Сверка графиков с реальностью. Взять известный инцидент прошлой недели и найти его на графиках метрик. Если по цифрам он неотличим от обычного дня, измеряется не то.
Мониторинг самого мониторинга. У внешнего сервиса — уведомление о собственном простое, у своей установки — вторая независимая точка, которая проверяет, что первая жива и продолжает слать данные.