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

Базовый мониторинг VDS

Порядок диагностики обычно такой: сначала общая картина по нагрузке (uptime, htop), затем — узкое место по конкретной подсистеме.

# Средняя нагрузка за 1, 5 и 15 минут
uptime

Три числа в выводе uptime — это load average. Если первое число (за минуту) заметно выше числа ядер CPU на сервере, система перегружена прямо сейчас; если растут все три — нагрузка держится долго, а не разовый всплеск.

Загрузка CPU и процессы

htop          # интерактивный монитор с сортировкой и деревом процессов
top           # стандартный монитор, есть везде без установки
ps aux --sort=-%cpu | head -10   # топ-10 процессов по CPU

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

free -h       # человекочитаемый вывод: total, used, free, available
free -m       # то же самое в мегабайтах, удобно для скриптов

Колонка available, а не free, показывает реальный резерв памяти: Linux активно использует свободную RAM под файловый кэш, и низкое значение free при высоком available — это нормально, а не признак нехватки памяти.

Дисковое пространство

df -h            # свободное место по разделам
du -sh /var/www  # размер конкретной директории
du -sh /var/www/* | sort -rh | head -10   # топ самых тяжёлых поддиректорий

Сетевые подключения

netstat -tulpn  # открытые порты и слушающие процессы (устаревающий инструмент)
ss -tulpn       # современная замена netstat, быстрее на серверах с тысячами соединений
ss -s           # сводная статистика по сокетам

Журналы ошибок

tail -f /var/log/nginx/error.log
tail -f /var/log/syslog
journalctl -u nginx -n 50 --no-pager   # для систем с systemd-journal

Разбор типичных ситуаций

Load average выше числа ядер, а CPU в htop почти простаивает — типичный признак не CPU-нагрузки, а ожидания диска (I/O wait). Смотрите колонку wa в выводе top: если она высокая, узкое место — диск, а не процессор, и лечится это не апгрейдом CPU.

Сообщение ядра Out of memory: Killed process 1234 (mysqld) в dmesg означает, что OOM killer принудительно завершил процесс из-за нехватки памяти. Найти это можно командой dmesg | grep -i "killed process" — после такого события стоит проверить, не пора ли добавить swap или ограничить память сервиса, а не просто перезапускать его.

Порт слушается, но снаружи недоступен — ss -tulpn покажет адрес привязки: если сервис слушает на 127.0.0.1:8080, а не на 0.0.0.0:8080, снаружи он не отвечает независимо от настроек файрвола. Это частая причина «сервис вроде запущен, а сайт не открывается».

Сравнение инструментов мониторинга

Инструмент	Что показывает	Формат	Когда использовать
top / htop	CPU, RAM, процессы в реальном времени	Интерактивный, в терминале	Быстрая диагностика прямо сейчас
vmstat / dstat	CPU, память, I/O, swap одной строкой	Периодический вывод	Отследить тренд за минуты
Логи (tail, journalctl)	Ошибки приложений и системы	Текстовый поток	Понять причину, а не только симптом
Netdata / Grafana+Prometheus	Историю метрик с графиками	Веб-интерфейс, хранение данных	Долгосрочные тренды, алерты

Если консольных утилит недостаточно и нужны графики за недели и алерты в мессенджер, следующий шаг — развернуть Netdata или связку Grafana с Prometheus.

Когда консольного мониторинга недостаточно

Нужна история метрик за прошлые недели, а не только текущий снимок — top и free ничего не запоминают после закрытия терминала.
Нужны автоматические уведомления при превышении порога (например, диск заполнен на 90%) — консольные утилиты не умеют присылать алерты сами.
Серверов больше одного, и нужен единый дашборд — смотреть в отдельный SSH-терминал на каждый VDS не масштабируется после 3–4 серверов.
Требуется профилирование на уровне отдельных запросов приложения (APM), а не только системных ресурсов — это отдельный класс инструментов поверх базового мониторинга.

Проверка результата

Соберите базовую картину одной командой: uptime && free -h && df -h — если все три показателя в норме, острой проблемы с ресурсами нет.
Убедитесь, что нужные порты слушаются на правильном адресе: ss -tulpn | grep LISTEN.
Проверьте, что логи не переполнены старыми повторяющимися ошибками — это тоже нагрузка на диск и признак нерешённой проблемы.
Если планируете мониторинг на постоянной основе, настройте автозапуск выбранного инструмента через systemd и проверьте его после перезагрузки сервера.

Для более глубокой диагностики конкретно CPU, диска и памяти с профилированием процессов есть отдельный разбор в статье про профилирование производительности Linux.