Моніторинг 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.