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

Зачем следить за состоянием VPS

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

Мониторинг не предотвращает проблему сам по себе, но даёт время среагировать до того, как она станет критичной. Разница между «диск заполнен на 85% и есть время разобраться» и «сайт лежит, потому что диск заполнен на 100%» — это и есть разница между настроенным мониторингом и его отсутствием.

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

Какие показатели стоит отслеживать в первую очередь

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

Показатель О чём говорит Когда стоит насторожиться
Загрузка CPU Насколько процессор занят обработкой задач Устойчиво высокая загрузка на протяжении долгого времени, а не кратковременный пик
Использование RAM Сколько памяти занято процессами и кэшем Память заканчивается и система начинает использовать swap
Свободное место на диске Сколько места осталось под логи, данные, бэкапы Заполнение выше 80–85% — время разбираться, пока не стало 100%
Load average Средняя очередь задач, ожидающих ресурсов CPU Значение заметно выше числа ядер процессора на протяжении долгого времени
Доступность сервиса Отвечает ли сайт или приложение на внешние запросы Сервис не отвечает или отвечает с ошибкой
Сетевой трафик Объём входящего и исходящего трафика Резкий и необъяснимый рост, особенно исходящего трафика

Конкретные пороговые значения зависят от тарифа, конфигурации и характера нагрузки — единой цифры «нормально/ненормально» для всех серверов не существует. Что вообще означают эти ресурсы и как их выбирать под задачу, подробно разобрано в статье про ресурсы VPS; здесь же речь именно о наблюдении за ними в процессе работы.

Как посмотреть состояние сервера вручную

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

Общая загрузка и список процессов. Показывает CPU, память и какие процессы их расходуют в реальном времени.

top

Более удобный аналог с цветной интерактивной таблицей, если установлен:

htop

Использование оперативной памяти.

free -h

Флаг -h выводит значения в удобных единицах (МБ/ГБ) вместо байтов.

Свободное место на диске.

df -h

Если место закончилось, следующий шаг — найти, что именно его занимает:

du -sh /var/log/* | sort -h

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

Средняя нагрузка системы.

uptime

Команда покажет время работы сервера и load average за последние 1, 5 и 15 минут — три числа подряд.

Состояние конкретной службы. Например, для веб-сервера Nginx:

systemctl status nginx

Так же проверяется состояние любой другой службы — базы данных, приложения, запущенного как systemd-сервис.

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

journalctl -u nginx --since "1 hour ago"

Инструменты для постоянного наблюдения за сервером

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

Панель управления провайдера

У многих провайдеров VPS в личном кабинете уже есть базовые графики загрузки CPU, памяти, диска и сети — это самый быстрый способ начать, не устанавливая ничего на сервер. Набор метрик и глубина истории зависят от конкретного провайдера, это стоит уточнить в его документации.

Лёгкие self-hosted инструменты

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

Внешняя проверка доступности

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

Полноценные системы мониторинга

Zabbix, Prometheus с Grafana и похожие решения дают гибкие дашборды, историю метрик и сложные правила уведомлений, но требуют времени на настройку и обычно оправданы, когда серверов несколько или нагрузка достаточно серьёзная, чтобы обосновать эту сложность. Для одного VPS с сайтом это чаще избыточно на старте.

Как настроить простые уведомления о проблемах

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

Пример простого скрипта, который проверяет заполненность диска и отправляет уведомление в Telegram, если места остаётся меньше 15%:

#!/bin/bash
THRESHOLD=85
USAGE=$(df / --output=pcent | tail -1 | tr -dc '0-9')
BOT_TOKEN="ваш_токен_бота"
CHAT_ID="ваш_chat_id"

if [ "$USAGE" -ge "$THRESHOLD" ]; then
  curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
    -d chat_id="${CHAT_ID}" \
    -d text="Диск заполнен на ${USAGE}%, пора проверить сервер"
fi

Токен бота и chat_id нужно получить заранее через собственного Telegram-бота — это отдельная настройка на стороне Telegram, не относящаяся к самому серверу. Скрипт можно сохранить, например, как /usr/local/bin/check-disk.sh, сделать исполняемым (chmod +x) и добавить в cron на регулярный запуск:

crontab -e

И добавить строку для проверки каждые 30 минут:

*/30 * * * * /usr/local/bin/check-disk.sh

По тому же принципу — проверка значения, сравнение с порогом, отправка уведомления при превышении — можно собрать скрипты и для памяти, и для load average. Если использовать готовые инструменты вроде Netdata или внешние uptime-сервисы, уведомления в них обычно настраиваются через интерфейс, без написания скриптов.

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

Само по себе уведомление не решает проблему — важно понимать, что делать дальше.

  • Диск заполнен. Найти, что занимает место, через du -sh, освободить его за счёт логов, кэша или устаревших бэкапов, затем разобраться в причине — например, настроить ротацию логов, если они растут без ограничений.
  • Высокая нагрузка CPU или load average. Через top или htop найти процесс, который потребляет ресурсы. Если это ожидаемый всплеск (обработка запросов, фоновая задача) — не проблема. Если процесс завис или потребление не спадает — разбираться с конкретным приложением.
  • Память заканчивается, идёт в swap. Проверить, какой процесс потребляет больше всего памяти командой top, сортировкой по столбцу памяти. Часто причина — утечка памяти в конкретном приложении, которую стоит решать на его уровне, а не постоянным перезапуском сервера.
  • Сервис не отвечает. Проверить статус службы через systemctl status, посмотреть логи через journalctl, при необходимости перезапустить службу и разобраться в логах, что стало причиной падения.
  • Резкий рост исходящего трафика. Стоит проверить, не идёт ли с сервера нежелательная активность — иногда это признак взлома или использования сервера для рассылки спама или атак на другие ресурсы. В этом случае мониторинг стоит рассматривать вместе с общим чек-листом из статьи про безопасность VPS.

Типичные ошибки в организации мониторинга VPS

  • Мониторинг без уведомлений. Графики, на которые никто не смотрит регулярно, не спасают от внезапного падения сайта ночью.
  • Слишком чувствительные пороги. Уведомления на каждый мелкий всплеск нагрузки быстро приводят к тому, что их перестают читать вообще.
  • Мониторинг только изнутри сервера. Если сервер полностью завис, локальный агент тоже не сможет прислать сигнал — отсюда важность внешней проверки доступности.
  • Игнорирование постепенного роста. Диск, который заполняется на пару процентов в неделю, — это не разовая случайность, а тенденция, которую стоит проверить заранее, а не ждать, пока место закончится.
  • Отсутствие мониторинга сразу после настройки сервера. Логично включить хотя бы базовое наблюдение сразу, ещё на этапе первоначальной настройки — как выстроить порядок действий с нуля, показано в статье про первую настройку VPS.

Итог

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