Статья также доступна на украинском (перейти к просмотру).

Содержание:

• Зачем мониторить сервер

• Что такое Netdata

• Установка на Ubuntu 24.04 / Debian 13

• Первый запуск

• Обзор интерфейса

• Мониторинг CPU, RAM, дисков и сети

• Контроль нагрузки PHP-FPM

• Мониторинг MySQL/MariaDB

• Уведомления о проблемах

• Достоинства и недостатки

• Когда Netdata уже недостаточно

• Что в итоге?

Когда сайт работает на VPS, администратору нужно видеть не только факт доступности сервера. Важно быстро понять, что замедляет сервер: CPU, RAM, диск, сеть, PHP-FPM или база данных. Команды top, free, df и ss помогают, но для нормальной диагностики нужны графики, история метрик и оповещения.

Инструмент отлично подходит для такового старта. Это система мониторинга сервера, которую можно установить через несколько минут и сразу получить мониторинг VPS в веб-панели. Решение удобно для одного Linux-сервера, тестового стенда или небольшого production-проекта. Если вы только запускаете сайт, можно начать с сервера на VPS-хостинга Freehost и сразу настроить базовый контроль состояния сервера.

Зачем мониторить сервер

Мониторинг Linux-сервера требуется для практических задач:

• действительно ли процессор является узким местом;

• не идет ли система в swap после релиза;

• не растут задержки дисковых операций;

• хватает ли PHP-FPM workers под пиковым трафиком;

• не забивается дисковое пространство логами или бекапами;

• есть ли проблемы с cron, backup или деплоем.

Без истории метрик администратор видит только текущее состояние. Поэтому мониторинг производительности сервера должен показывать не только процент CPU, но и load average, iowait, steal time, swap, I/O pressure, сетевой трафик и состояние сервисов. Если одновременно растут load average, iowait и latency диска, следует проверять диск или базу. Если CPU занят, но iowait низкий, ищите процесс, очередь PHP-FPM или трудные запросы приложения. Такой подход делает мониторинг сервера полезным не только при авариях, но и для планового контроля нагрузки сервера.

Что такое Netdata

Это инструмент и веб-интерфейс мониторинга, выполняющий сбор метрик и показывающий серверные метрики почти в реальном времени. После установки сразу доступны системные показатели: CPU, RAM, swap, диски, файловые системы, сеть, сокеты, процессы, systemd-сервисы и Linux PSI.

PSI, или Pressure Stall Information, особенно полезен для VPS: он показывает, сколько времени задачи теряют из-за конкуренции за CPU, память или I/O. Для виртуального сервера это более точный сигнал, чем один график загрузки.

Также есть коллекторы для Nginx, Apache, PHP-FPM, MySQL, MariaDB, PostgreSQL, Redis и Docker. Часть графиков появляется автоматически, а для прикладных сервисов обычно нужно добавить job в конфигурацию YAML.

Установка на Ubuntu 24.04 / Debian 13

Для установки Netdata на Ubuntu 24.04 или Netdata Debian 13 проще всего использовать официальный kickstart.sh. Такой сценарий Netdata Ubuntu 24.04 подходит и для нового VPS, и для тестового стенда. Скрипт автоматически определяет дистрибутив и устанавливает рекомендуемый способ развертывания конкретной системы. Для production-сервера лучше выбрать stable-канал.

wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh
sudo sh /tmp/netdata-kickstart.sh --release-channel stable --non-interactive

Перед запуском install-скрипт можно просмотреть:

less /tmp/netdata-kickstart.sh

После установки проверьте сервис и порт:

systemctl status netdata
netdata -v
ss -lntp | grep 19999

На публичном VPS не стоит открывать порт 19999 для всего интернета. Для первого запуска безопаснее использовать SSH-тоннель:

ssh -L 19999:127.0.0.1:19999 user@server

После этого откройте локально:

http://localhost:19999

Для небольшого сервера обычно достаточно stable-канала и стандартных автообновлений. Если обновления контролируются вручную, во время установки можно добавить --no-updates.

Пакеты для тестовой нагрузки

Чтобы сразу увидеть графики производительности, установите базовые сервисы и утилиты:

sudo apt update
sudo apt install -y nginx php-fpm php-cli php-mysql mariadb-server sudo apt install -y stress-ng fio sysbench apache2-utils iperf3

Этого достаточно, чтобы проверить мониторинг ресурсов сервера, CPU, I/O pressure, сеть, мониторинг PHP-FPM и метрики MySQL/MariaDB.

Первый запуск

После входа в панель видны узел, временной диапазон, live-обновление, аллерты и разделы System, Network, Storage, Applications и Processes. Для начинающих это удобно: основные метрики не нужно собирать вручную из разных утилит. Для администраторов ценность в деталях: можно быстро сопоставить несколько графиков за один промежуток времени и оценить нагрузку на систему.

Первый тест:

stress-ng --cpu 2 --vm 1 --vm-bytes 256M --timeout 90s --metrics-brief

Через несколько секунд в панели будет виден скачок CPU, load average, активность RAM и pressure-метрики. Так работает мониторинг в реальном времени: нагрузка создается сейчас, а график реагирует почти сразу.

Нагрузка CPU и RAM во время stress-ng: виден скачок использования процессора, load average, активность памяти и CPU pressure в реальном времени.

Обзор интерфейса

Панель управления мониторингом построена вокруг интерактивных графиков. В каждом блоке можно изменить временной диапазон, остановить live-обновление, посмотреть отдельные dimensions и увеличить нужный промежуток.

После установки в первую очередь следует проверить:

• CPU usage, load average, interrupts, softirqs;

• memory, swap, available RAM, page faults;

• disks, IOPS, bandwidth, utilization, latency;

• filesystem usage та inode usage;

• network traffic, drops, errors, TCP sockets;

• PSI для CPU, memory та I/O;

• alerts, которые уже активны.

Такой веб-интерфейс мониторинга не заменяет логи, но сокращает путь поиска проблемы: диагностика неисправностей начинается с графиков, а не с предположений. Если в логах Nginx видны медленные ответы, в панели можно сразу проверить, что в этот момент было с PHP-FPM, диском, базой данных и RAM.

Мониторинг CPU, RAM, дисков и сети

Для CPU смотрите не только на "100%". Важны user/system/steal/iowait, load average, runnable processes и CPU pressure. Для мониторинга ресурсов сервера это базовые метрики, без которых контроль загрузки сервера будет неточным. На VPS отдельно полезен steal time: если он растет, часть процессорного времени отнимает гипервизор или соседнюю нагрузку на физическом узле, а общая нагрузка на систему выглядит нестабильной.

Для RAM главные сигналы – available memory, загрузка оперативной памяти, swap activity, major page faults и memory pressure. Linux активно использует кэш, поэтому "used memory" сам по себе не проблема. Проблема начинается тогда, когда процессы ждут память или система активно работает со swap.

Для дисков запустите короткий fio:

fio --name=netdata-disk-demo --filename=/tmp/netdata-fio-demo \
--size=512M --rw=randrw --bs=4k --runtime=90 \
--time_based --group_reporting
rm -f /tmp/netdata-fio-demo

В Storage проверьте IOPS, read/write bandwidth, utilization, latency и I/O pressure. Если диск перегружен, CPU может просто ждать завершения операций, а производительность сайта будет падать без очевидного процессорного пика.

I/O pressure и дисковые метрики во время fio: виден рост задержек дисковых операций, IOPS и активности чтения/записи. Такой экран помогает оценить, не стал ли накопитель узким местом VPS.

Для сети смотрите inbound/outbound traffic, packets, drops, errors, TCP sockets и retransmits. Если одновременно растут HTTP-запросы, активны PHP-FPM connections и сетевой трафик, нагрузка идет от реальных пользователей или ботов. Если сеть тихая, а CPU и диск заняты, проверяйте cron, backup, очереди или импорт фона.

Контроль нагрузки PHP-FPM

Мониторинг PHP-FPM нуждается в status page. В pool-конфигурации, обычно /etc/php/*/fpm/pool.d/www.conf, включите:

pm.status_path = /status

Перезапустите службу:

sudo systemctl restart php*-fpm

Endpoint лучше отдать через Nginx только для localhost. Socket измените под свою версию PHP:

location ~ ^/(status|ping)$ {
    allow 127.0.0.1;
    deny all;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

Проверка:

curl http://127.0.0.1/status

Далее откройте конфигурацию collector:

cd /etc/netdata 2>/dev/null || cd /opt/netdata/etc/netdata
sudo ./edit-config go.d/phpfpm.conf

Минимальный job:

jobs:

  - name: local     url: http://localhost/status?full&json

Однако конкретный формат конфигурации зависит от версии Netdata. Актуальный пример можно просмотреть в файле phpfpm.conf. 

Перезапустите агент и создайте HTTP-нагрузку:

sudo systemctl restart netdata
ab -n 5000 -c 40 http://127.0.0.1/

В Applications -> PHP-FPM должны появиться active/idle connections, requests per second, slow requests, max children reached, request duration, request CPU и request memory. Для WordPress, Laravel или Symfony это быстрый способ понять, хватает ли pm.max_children, требуется кэширование или проблема ниже - в SQL-запросах или диске.

Графики PHP-FPM под тестовой HTTP-нагрузкой: видны активные подключения, requests per second, request duration и возможные срабатывания max children reached.

Мониторинг MySQL/MariaDB

Мониторинг MySQL и мониторинг MariaDB работает через collector mysql. Он подключается через TCP или Unix socket и читает global status, InnoDB status, переменные сервера, replication status, connections, queries, handlers и locks.

Для production создайте отдельного пользователя. Для MySQL и MariaDB до 10.5.9:

CREATE USER 'netdata'@'localhost';
GRANT USAGE, REPLICATION CLIENT, PROCESS ON *.* TO 'netdata'@'localhost';
FLUSH PRIVILEGES;

Для MariaDB 10.5.9+ используйте SLAVE MONITOR:

CREATE USER 'netdata'@'localhost';
GRANT USAGE, SLAVE MONITOR, PROCESS ON *.* TO 'netdata'@'localhost';
FLUSH PRIVILEGES;

Конфигурация:

cd /etc/netdata 2>/dev/null || cd /opt/netdata/etc/netdata
sudo ./edit-config go.d/mysql.conf

TCP-пример:

jobs:
  - name: local
    dsn: netdata@tcp(127.0.0.1:3306)/

Unix socket:

jobs:
  - name: local
    dsn: netdata@unix(/run/mysqld/mysqld.sock)/

Для теста используйте sysbench:

sudo mariadb -e "CREATE DATABASE IF NOT EXISTS sbtest;"
sudo sysbench oltp_read_write --db-driver=mysql \
  --mysql-socket=/run/mysqld/mysqld.sock --mysql-user=root \
  --mysql-db=sbtest --tables=2 --table-size=20000 prepare
sudo sysbench oltp_read_write --db-driver=mysql \
  --mysql-socket=/run/mysqld/mysqld.sock --mysql-user=root \
  --mysql-db=sbtest --tables=2 --table-size=20000 \
  --time=90 --threads=4 run
sudo sysbench oltp_read_write --db-driver=mysql \
  --mysql-socket=/run/mysqld/mysqld.sock --mysql-user=root \
  --mysql-db=sbtest --tables=2 cleanup

Во время теста смотрите не только queries per second. Более полезные связи: InnoDB reads/writes, buffer pool, locks, temporary tables, threads connected/running и одновременная активность диска. Если база упирается в I/O, то это будет видно и в графиках Storage.

Метрики MariaDB во время sysbench: видны активные подключения, SQL-запросы, InnoDB-активность и связь с дисковой нагрузкой.

Уведомления о проблемах

Инструмент имеет health monitoring. Типовые правила уже настроены из коробки, а собственные alert definitions лучше хранить в /etc/netdata/health.d, чтобы обновления пакета не перезаписывали изменения.

На старте проверьте аллерты для следующих ситуаций:

• заполнение диска и inode usage;

• RAM, swap і memory pressure;

• CPU load, iowait і steal time;

• disk latency та I/O utilization;

• недоступность сервисов;

• ошибки collector jobs.

Автоматические аллерты не заменяют анализ, но ускоряют обнаружение перегрузок. Если система мониторинга сервера сообщает о диске, памяти или latency, админ реагирует до того, как проблема станет инцидентом для пользователей. Для одного сервера достаточно оставить стандартные правила, настроить критический канал сообщений и в течение недели посмотреть, какие повторения warnings. Это простой способ поддерживать контроль загрузки сервера без постоянного ручного просмотра графиков.

Достоинства и недостатки

Преимущества

• установка Netdata занимает несколько минут;

• базовый мониторинг VPS появляется без длинной конфигурации;

• мониторинг в реальном времени с высокой детализацией;

• CPU, RAM, диски, сеть и PSI доступны сразу после запуска;

• можно добавить PHP-FPM, MySQL, MariaDB и другие коллекторы;

• локальный доступ через SSH-тоннель не требует открывать порт.

Недостатки

• прикладные сервисы часто нуждаются в отдельном collector job;

• большое количество графиков сперва может перегружать;

• для командной работы и централизованных нотификаций удобнее подключать Cloud;

• на слабых VPS нужно смотреть за retention и дисковым пространством;

• порт 19999 нельзя оставлять публичным без контроля доступа;

• это не полная observability-платформа для большого кластера.

Когда Netdata уже недостаточно

Для одного VPS или нескольких серверов этого инструмента обычно достаточно. Но если нужно централизованно управлять десятками узлов, строить сложные SLA-отчеты, интегрировать мониторинг с процессами NOC или подробно контролировать инфраструктуру предприятия, то стоит смотреть в сторону Zabbix. Если команда уже работает с Kubernetes, микросервисами и time-series метриками, логическим выбором часто становится Prometheus + Grafana.

Что в итоге?

Это хороший вариант, когда требуется быстрый мониторинг сервера без сложной архитектуры. Через несколько минут можно получить данные по серверу, увидеть CPU, RAM, I/O pressure, диски, сеть, PHP-FPM и MariaDB, а затем постепенно добавить аллерты и собственные настройки. Для небольшого проекта это практичная система мониторинга сервера, с которой можно начинать мониторинг Linux-сервера без отдельного стека observability.

Ценность этого инструмента в простоте: установил агент, открыл панель, увидел графики производительности. Для опытных админов польза в деталях: PSI, iowait, steal time, InnoDB, активные PHP-FPM connections, системные показатели и быстрая корреляция между событиями. Именно поэтому этот инструмент следует ставить сразу после запуска VPS.

Подписывайтесь на наш Telegram-канал https://t.me/freehostua, чтобы быть в курсе новых полезных материалов

Смотрите наш канал YouTube на https://www.youtube.com/freehostua.

Мы в чем ошиблись, или что-то пропустили?

Дата: 15.06.2026 Автор: Илья Пигович #automation#cloud#debian#linux#ubuntu

Голосование 1 2 3 4 5