Что мониторить в первую неделю: четыре сигнала, которые не пропустят сбой
Мониторинг — это не инструмент, а система раннего предупреждения. Его задача — ответить на вопрос «работает ли сервис?» до того, как об этом спросит клиент. Поэтому порядок важнее выбора инструмента: сначала то, что скажет «сервис не работает», потом всё остальное. Красивые панели с сотней метрик — это тупик: они не отвечают на главный вопрос, а только создают иллюзию контроля.
Первая неделя мониторинга — это четыре сигнала, которые покрывают большинство критических сбоев. Их достаточно, чтобы не пропустить проблему, но не настолько много, чтобы утонуть в алертах. Дальше разберём, что это за сигналы, как они работают, и как не превратить мониторинг в источник ложных тревог.
Доступность снаружи: проверка, без которой мониторинг не имеет смысла
Первое, что нужно мониторить, — это доступность сервиса для клиента. Не метрики изнутри, не логи, не нагрузка на базу, а простой вопрос: «Может ли клиент достучаться до сервиса?»
Как проверять:
- Отправлять HTTP-запрос на корневой эндпоинт (например,
/health) и ждать успешного ответа. - Устанавливать разумный таймаут: если сервис не ответил за время, сопоставимое с ожиданиями клиента, он считается недоступным.
- Проверка должна идти с внешнего хоста, а не с того же сервера, где запущен сервис. Если сервер упал, но мониторинг на нём продолжает работать, это ничего не значит.
Что ловит:
- Падение сервера (например, из-за нехватки памяти, сбоя ядра или проблем с сетью).
- Проблемы с балансировщиком нагрузки или DNS.
- Блокировку фаерволом или системами защиты от DDoS-атак.
Что не ловит:
- Частичные сбои (например, одна из реплик базы данных недоступна, но сервис формально отвечает).
- Логические ошибки (сервис возвращает успешный код, но данные неверные).
Почему это первое: Если сервис недоступен снаружи, всё остальное не имеет значения. Даже если база работает, а логи пишутся, клиент всё равно не получит ответ. Поэтому доступность снаружи — это базовый сигнал, без которого мониторинг теряет смысл.
Ошибки на входе: что ломается, когда сервис «вроде работает»
Сервис может отвечать на запросы, но при этом возвращать ошибки. Например, коды 500, если упал бэкенд, или 403, если сработала защита. Эти ошибки не всегда видны в метриках доступности, потому что сервис формально «работает» — просто возвращает не то, что ожидает клиент.
Как проверять:
- Считать долю ошибок (коды 5xx, 4xx) от общего числа запросов.
- Устанавливать порог на основе ожиданий клиента: если доля ошибок превышает уровень, при котором клиенты начинают замечать проблемы, это уже сигнал.
- Источник данных — логи или метрики с балансировщика нагрузки (например, Nginx, Envoy).
Что ловит:
- Падение бэкенда (например, база данных недоступна, но сервис отвечает кодом 500).
- Проблемы с авторизацией (например, истёк токен, но сервис возвращает 403).
- Ошибки в коде (например, необработанное исключение).
Что не ловит:
- Задержки ответа (сервис может отвечать медленно, но без ошибок).
- Проблемы с данными (например, сервис возвращает успешный код, но данные неверные).
Почему это второе: Ошибки на входе — это первый признак того, что сервис работает не так, как ожидается. Если их не мониторить, можно пропустить сбой, который не виден в метриках доступности.
Задержка ответа: почему сервис может «работать», но быть непригодным для использования
Сервис может отвечать без ошибок, но при этом быть слишком медленным для клиента. Например, если обработка запроса занимает время, превышающее ожидания клиента, сервис формально работает, но клиент всё равно не получит ответ вовремя.
Как проверять:
- Измерять время ответа на ключевых эндпоинтах (например,
/health,/api/v1/data). - Использовать перцентили для анализа распределения задержек. Например, если большинство запросов отвечают быстро, но есть небольшая доля запросов, которые отвечают значительно медленнее, это уже сигнал о проблеме.
- Источник данных — метрики с балансировщика нагрузки или инструментация кода (например, OpenTelemetry).
Что ловит:
- Медленные запросы к базе данных или внешним сервисам.
- Блокировки в коде (например, deadlock).
- Проблемы с сетью (например, высокая задержка).
Что не ловит:
- Ошибки (сервис может отвечать быстро, но с ошибками).
- Проблемы с данными (например, сервис возвращает успешный код, но данные неверные).
Почему это третье: Задержка ответа — это второй по важности сигнал после доступности. Если сервис отвечает медленно, он может быть непригоден для использования, даже если формально работает.
Свободное место и память: что ломается, когда кончаются ресурсы
Сервис может работать, отвечать без ошибок и быстро, но при этом упасть из-за нехватки ресурсов. Например, если кончилось место на диске, база данных перестанет принимать записи, а если кончилась память, сервис может быть убит системой.
Как проверять:
- Свободное место на диске: устанавливать порог, при котором остаётся достаточно места для работы сервиса и записи логов.
- Использование памяти: устанавливать порог, при котором остаётся запас для обработки пиковых нагрузок.
- Источник данных — системные метрики (например,
df -h,free -m).
Что ловит:
- Падение сервиса из-за нехватки места на диске.
- Падение сервиса из-за нехватки памяти (например, OOM Killer).
- Проблемы с логами (если кончилось место, логи перестанут писаться).
Что не ловит:
- Ошибки в коде (сервис может работать, но возвращать неверные данные).
- Проблемы с сетью (например, высокая задержка).
Почему это четвёртое: Ресурсы — это то, что ломается постепенно, но верно. Если их не мониторить, можно пропустить сбой, который разовьётся медленно, но приведёт к критической проблеме.
Что делать с алертами: правило, которое спасёт от ложных тревог
Мониторинг — это не только про то, что мониторить, но и про то, на что реагировать. Если алерты будут будить людей по ночам без причины, их перестанут слушать. Поэтому правило простое: алерт должен срабатывать только тогда, когда требует немедленного действия.
Что алертить сразу:
- Доступность снаружи (если сервис недоступен, это всегда проблема).
- Ошибки на входе (если доля ошибок превышает уровень, при котором клиенты начинают замечать проблемы).
- Задержка ответа (если перцентиль задержек превышает ожидания клиентов).
Что не алертить сразу:
- Свободное место и память (если ресурсы ещё есть, можно подождать до рабочего времени).
- Метрики, которые не требуют немедленного действия (например, количество запросов в минуту).
Почему это важно: Если алерты будут срабатывать на всё подряд, их перестанут воспринимать всерьёз. А если алерт сработает на реальную проблему, но никто не среагирует, это будет хуже, чем если бы алерта не было вовсе.
Что добавлять на второй неделе: почему не раньше
Первая неделя — это четыре сигнала, которые покрывают большинство критических сбоев. На второй неделе можно добавить:
-
Метрики изнутри сервиса (например, количество запросов к базе данных, время выполнения запросов).
- Зачем: чтобы понимать, что происходит внутри сервиса, а не только снаружи.
- Почему не раньше: если сервис недоступен снаружи, метрики изнутри не помогут диагностировать проблему.
-
Логические проверки (например, проверка данных в базе).
- Зачем: чтобы ловить ошибки, которые не видны в метриках (например, сервис возвращает успешный код, но данные неверные).
- Почему не раньше: если сервис недоступен, логические проверки не имеют смысла.
-
Метрики инфраструктуры (например, нагрузка на CPU, использование сети).
- Зачем: чтобы понимать, что происходит с сервером, а не только с сервисом.
- Почему не раньше: если сервис недоступен, метрики инфраструктуры не помогут понять причину.
Почему не раньше: Если начать с метрик изнутри или логических проверок, можно пропустить сбой, который виден только снаружи. Поэтому сначала — доступность, ошибки, задержка, ресурсы, а потом всё остальное.
Тупик: начать с красивых панелей
Самая распространённая ошибка при внедрении мониторинга — начать с красивых панелей и сотни метрик. Это создаёт иллюзию контроля, но не отвечает на главный вопрос: «работает ли сервис?»
Почему это тупик:
- Панели с метриками не скажут, доступен ли сервис для клиента.
- Они не покажут, возвращает ли сервис ошибки или отвечает слишком медленно.
- Они не предупредят о нехватке ресурсов, которая приведёт к падению сервиса.
Что делать вместо этого: Начинать с четырёх сигналов первой недели: доступность снаружи, ошибки на входе, задержка ответа, свободные ресурсы. Только когда эти сигналы работают, можно добавлять детали.
Позиция редакции
Мониторинг — это не про инструменты, а про порядок. Если начать с красивых панелей и сотни метрик, можно пропустить сбой, который виден только в четырёх сигналах первой недели. Поэтому:
- Сначала — доступность снаружи, ошибки, задержка, ресурсы. Без них мониторинг не имеет смысла.
- Алерты — только на то, что требует немедленного действия. Иначе их перестанут слушать.
- Всё остальное — на второй неделе. Когда базовые сигналы работают, можно добавлять детали.
Когда позиция неверна: Если сервис не критичен (например, внутренний инструмент, который можно починить в рабочее время), можно начать с метрик изнутри или логических проверок. Но для продакшен-сервиса порядок важен: сначала то, что скажет «сервис не работает», потом всё остальное.