Представь: у тебя на VPS ночь, клиенты жалуются, а в дашборде — сотня метрик и ни одной осмысленной подсказки. Знакомая картина? Внимание! Слишком много данных убивает оперативность не хуже, чем их полное отсутствие.
В этой статье я расскажу, что реально помогает решать проблемы, а что — просто мусор в мониторинге.
Раньше я сам грешил: настрою 200 графиков за один вечер и гордо чувствую себя «про». Результат — оповещения лезут каждую минуту, и в конце концов на реальные инциденты реагируют через час. Однажды мы пропустили падение базы, потому что бригаду отвлекали сотни низкоприоритетных WARN-ов. Это был хороший урок: мониторинг должен экономить время, а не быть механической помойкой.
Главный принцип прост: мониторь то, что ломается и влияет на клиента
Задай себе вопрос прямо сейчас — какие метрики действительно приводят тебя к решению проблемы? Все остальное — шум. Если метрика не подсказывает действие «проверить X / перезапустить Y / открыть тикет», ей не место в алертах.
Инфраструктурный минимум, который должен быть везде: загрузка CPU и нагрузка (load average) — не просто проценты, а тенденция и контекст; память — не только free, но и swap и cache, потому что cached не значит «нужно чистить»; диск — свободное место на партициях и inode, ведь переполнение /var/log убьет всё; I/O latency — секунды ожидания чтения/записи важнее, чем сотни метрик о чтениях в секунду.
Сеть и сервисы, без которых клиенты заметят падение: пропускная способность интерфейсов и рост RTT/packet loss; ошибки TCP, DROPS и ретрансмиссии — они сигналят о проблемах с сетью или перегрузке виртуалки; здоровье процессов и сервисов — uptime, restart count и состояние systemd; проверка приложений сверху — простой HTTP-эндпоинт с проверкой кода ответа и времени ответа.
Не пренебрегай логикой «сердцебиения» (heartbeat)
Как понять, что сервис жив, если процесс висит, а отвечает по таймауту? Простой пинг/health-check каждые несколько секунд решает это. Дополнительно полезно следить за ошибочными ответами приложения — рост 5xx и latency P95/P99 важнее среднего P50, потому что среднее часто скрывает пики.
А теперь о том, что обычно мешает:
метрики уровня «каждый поток по каждой функции» или куча процентов по каждому контейнеру без контекста — это шум. Температура CPU на VPS, расположенном у провайдера, обычно бесполезна и только нагружает систему сбора метрик. Ещё один антипаттерн — алерты на кратковременные спайки без учета времени и повторяемости: сработал один раз — проигнорируй; сработал 3 раза за 5 минут — уже повод.
Как настраивать пороги и алерты?
Применяй правило трех вопросов:
1) Что сломается, если метрика будет такой?
2) Что я (или on-call) сделаю при получении этого алерта?
3) Как быстро нужно реагировать? Если ответ «ничего» — пусть метрика в дашборде, но не в алертах. Если действие простое и автоматическое — делай ремедиацию, а не пушь человека по ночам.
Практическая рекомендация:
держи 3–5 ключевых панелей, они должны показывать состояние «в целом» и давать путь к корню проблемы. Периодически чисть дашборды и отключай старые алерты; раз в квартал устраивай «аудит сигналов» и спрашивай: почему это всё ещё висит в списке? Не бойся удалять метрики — их можно заново добавить, если действительно понадобятся.
В конце: мониторинг — это инструмент для сокращения времени на поиск и исправление проблем, а не соревнование по количеству графиков. Сфокусируйся на доступности, латентности, ошибках и ресурсах, которые реально ограничивают твою систему. И помни: лучше несколько понятных сигналов, чем сотня пустых тревог.