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

CPU: средняя нагрузка и пики

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

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

• смотрите среднее и максимальное значение
• сравнивайте CPU с TTFB и HTTP-ошибками
• учитывайте cron, деплои и фоновые задачи
• проверяйте повторяемость пиков

RAM: свободная память, swap и рост потребления

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

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

• контролируйте процент использования RAM
• ищите постепенный рост без освобождения
• проверяйте swap и OOM
• сопоставляйте память с логами приложения

Disk: занятое место и риск аварии

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

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

• ставьте warning до критического порога
• следите за скоростью роста
• проверяйте логи и бэкапы
• не допускайте заполнения до 100%

Load average, IO wait и CPU steal

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

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

• сравнивайте load с числом CPU-ядер
• IO wait помогает найти дисковые задержки
• CPU steal важен для виртуальных серверов
• эти метрики полезны при разборе медленного TTFB

Network: входящий и исходящий трафик

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

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

• отслеживайте входящий и исходящий трафик
• сравнивайте сетевые пики с ошибками сайта
• ищите повторяемые аномалии
• учитывайте бэкапы и внешние интеграции

Heartbeat и история инцидентов

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

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

• heartbeat нужен для контроля живости агента
• история показывает длительность и повторяемость
• метрики в момент инцидента помогают найти причину
• уведомления должны вести к конкретному действию

Как читать метрики без ложных выводов

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

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

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

• не делайте вывод по одной метрике
• сравнивайте графики с HTTP-ошибками и TTFB
• учитывайте деплои, бэкапы и cron-задачи
• проверяйте свежесть данных через heartbeat