Мониторинг для раннего продукта: четыре сигнала и тишина

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

Для раннего продукта хватит четырёх сигналов и нескольких правил, которые не дают им превратиться в шум.

Доступность снаружи

Внешняя проверка раз в минуту из другой сети: открывается ли сайт и отвечает ли API. Важно, что именно проверять. Главная страница, которая отдаётся из CDN, будет открываться, даже когда база лежит. Лучше завести эндпоинт /health, который делает простейший запрос к базе и возвращает ошибку, если тот не прошёл.

Проверка из нескольких точек снижает ложные срабатывания: один сбой сети у сервиса мониторинга не должен никого будить.

Ошибки

Трекер ошибок, который группирует одинаковые исключения и показывает, сколько людей задело. Полезные настройки с первого дня:

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

Задержка

Среднее время ответа почти бесполезно: девять быстрых запросов и один на десять секунд дают приличное среднее и одного очень недовольного человека. Смотри на 95-й перцентиль, то есть на время, быстрее которого отвечают 95 запросов из 100.

Следить за всеми эндпоинтами не нужно. Выбери три-пять, от которых зависит главный сценарий: вход, основная страница, сохранение, оплата. Медленный отчёт в админке раз в день — не повод для алерта.

Очередь фоновых задач

Если в продукте есть фоновые задачи — письма, генерация файлов, обработка вебхуков, вызовы ИИ, — то самая тихая поломка живёт здесь. Обработчик упал, сайт работает, а письма с подтверждением не уходят уже три часа.

Два числа, которые стоит видеть:

сколько задач ждёт в очереди;
сколько ждёт самая старая из них.

Второе полезнее первого: длинная очередь, которая быстро разгребается, — норма, а одна задача, которая висит час, — нет. Для задач по расписанию нужна обратная проверка: задача сама сообщает «я отработала», и если сообщения не было, приходит алерт.

Как не утонуть в алертах

Алерт — это просьба к человеку что-то сделать. Если делать нечего, это не алерт, а запись в журнал. Несколько правил:

Алерт на симптом, который чувствует пользователь, а не на причину. Загрузка процессора 85% — не проблема, если запросы отвечают быстро.
Порог с длительностью: «ошибки выше нормы пять минут подряд», а не «одна ошибка».
Два уровня. Срочное приходит на телефон и требует реакции сейчас. Всё остальное собирается в сводку, которую смотрят утром.
У каждого срочного алерта есть короткая заметка: что проверить первым и где.

Чистка раз в месяц

Раз в месяц открой историю алертов и задай про каждый один вопрос: кто-то что-то сделал после него? Если нет, алерт стоит удалить, ослабить или перевести в сводку. Если была авария, о которой алерт не сообщил, — добавить новый. Через несколько таких проходов срочный канал становится тихим, и именно поэтому его снова начинают читать.

Кто смотрит

В команде из трёх человек дежурство звучит громко, но вопрос «кому приходит алерт в субботу» нужно решить заранее. Ответ «всем» на практике означает «никому»: каждый думает, что посмотрит кто-то другой.

SUBXCAT может настроить этот минимум и первые пару месяцев чистить алерты вместе с командой, пока они не станут тихими.