Какие метрики сервера важно отслеживать

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

Высокий CPU сам по себе не всегда плохо. Если это короткая задача бэкапа или индексации ночью, возможно, всё нормально. Но если CPU растёт вместе с TTFB, 502 или 503, это уже сильный сигнал для расследования.

RAM влияет на стабильность приложения, базы данных и кешей. Когда памяти мало, сервер может начать использовать swap, а процессы могут завершаться аварийно. Для пользователя это проявляется как медленная работа, периодические 5xx или внезапные падения.

Особенно полезно смотреть тренд RAM после деплоя. Если потребление стабильно растёт и не возвращается к норме, возможна утечка памяти. Если RAM скачет в определённые часы, нужно проверить фоновые задачи и импорты.

Диск часто вспоминают слишком поздно. Когда место заканчивается, сервер может перестать писать логи, база данных может перейти в аварийное состояние, загрузка файлов ломается, кеш не обновляется. Это превращается в пользовательские ошибки даже при живом CPU и RAM.

Для диска важен не только текущий процент, но и скорость роста. Если за сутки занятость выросла на десятки гигабайт, нужно искать источник: логи, бэкапы, временные файлы, дампы, Docker images или пользовательские загрузки.

Load average показывает очередь задач и помогает понять, насколько серверу тяжело относительно числа CPU-ядер. IO wait указывает, что процессы ждут диск. CPU steal важен для VPS: он показывает, что виртуальная машина ждёт ресурсы гипервизора.

Эти метрики помогают отличить проблему приложения от проблемы инфраструктуры. Например, высокий load при умеренном CPU и заметном IO wait может говорить о медленном диске. CPU steal может объяснять деградацию на VPS, даже если внутри сервера всё настроено правильно.

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

Сеть нужно смотреть вместе с HTTP-статусами. Если трафик вырос и одновременно увеличились timeout, 5xx или TTFB, вероятно, сервер или приложение не справляется с нагрузкой.

Heartbeat показывает, что агент мониторинга жив и сервер продолжает отправлять состояние. Это базовый сигнал доверия к данным. Если heartbeat пропал, текущие графики могут быть устаревшими, а реальное состояние сервера неизвестно.

История инцидентов превращает метрики в рабочий инструмент. Важно видеть не только текущие значения, но и когда началась проблема, сколько длилась, какие метрики были в момент старта и что изменилось после восстановления.

Частая ошибка в мониторинге — делать вывод по одному графику. Высокий CPU может быть нормальной фоновой задачей, а умеренный CPU при высоком IO wait может означать проблемы с диском. Заполненный диск может объяснить ошибки базы, а пропавший heartbeat говорит не о стабильности, а об отсутствии свежих данных.

Правильная диагностика строится на связке сигналов. Смотрите, что происходило одновременно: HTTP-статусы, TTFB, CPU, RAM, диск, load, сетевой трафик, деплои и фоновые задачи. Чем больше контекста собрано автоматически, тем меньше времени уходит на ручное расследование.

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