Плохой мониторинг — это когда сообщение приходит на каждый скачок нагрузки, и через неделю его перестают читать. Хороший начинается не с графиков, а с вопроса: что именно для нас «сломано»?
Четыре вопроса вместо трёхсот панелей
Обычно ответов на этот вопрос три-четыре:
- Пользователь не может войти.
- Заказы не создаются.
- Выгрузка не уехала получателю.
- Резервная копия не снялась.
Под каждый ответ — одна проверка, желательно снаружи сервиса, эмулирующая реальный сценарий: авторизация, создание сущности, чтение файла из хранилища, наличие вчерашней копии.
# простейший чёрный ящик: сценарий, а не порт
curl -fsS --max-time 10 -o /dev/null \
-H "Authorization: Bearer $PROBE_TOKEN" \
https://api.example.com/health/deep
/health/deep отличается от /health тем, что действительно ходит в базу, в кэш и в очередь. Обычный /health, который возвращает {"status":"ok"} из константы, не проверяет ничего — его отсутствие и присутствие одинаково бесполезны.
Что считать алертом
Правило, к которому пришёл: алерт обязан требовать действия в момент получения. Если дежурный, получив сообщение, идёт смотреть график, чтобы понять, что происходит, — это заметка, а не алерт. Заметки пусть живут на дашборде.
Отсюда три категории:
- Страница (звонок): пользователь страдает прямо сейчас, и есть что сделать руками.
- Тикет (утро): деградация, которая станет аварией через дни — место на диске, истекающий сертификат, деградация бэкапа.
- График (молчание): всё остальное, включая нагрузку, задержки и ошибки в пределах нормы.
Пороги вместо средних
Каждый алерт должен иметь два параметра: условие и выдержку по времени. «Доля ошибок выше 1% в течение пяти минут» — нормально. «Ошибка была» — нет. Без выдержки вы будете просыпаться от одного ретрая при деплое.
И последнее: раз в квартал полезно посмотреть на список алертов и вычеркнуть те, что за это время не срабатывали или срабатывали вхолостую. Мониторинг гниёт без чистки так же, как код.