Мониторинг CPU, дискового I/O и трафика VPS (htop, iotop, vnStat, Netdata) и соблюдение правил fair use

Чтобы облачный VPS JUSTG оставался в рамках fair use, следите за тремя показателями: средней загрузкой CPU за час (не выше 50%), длительной нагрузкой на диск (не выше 100 MiB/s в течение 4 часов и дольше) и сетью (не больше 70% общего порта в течение долгого времени), а также за месячным трафиком. В этой инструкции показано, как измерить каждый показатель стандартными инструментами Linux на Debian, Ubuntu и Rocky Linux / AlmaLinux, как получить предупреждение до достижения лимита и как ограничить собственные задачи.

Правила fair use и лимиты тарифов

В каждый тариф также входит месячная квота трафика:

Цены и подробности — в статье о тарифах облачных VPS.

Шаг 1: Установите инструменты

# Debian / Ubuntu
apt update && apt install -y htop sysstat iotop vnstat nload iftop

# Rocky Linux / AlmaLinux (htop, vnstat, nload and iftop come from EPEL)
dnf install -y epel-release && dnf install -y htop sysstat iotop vnstat nload iftop

Шаг 2: Проверьте загрузку CPU и среднее значение за час

Правило fair use касается среднего значения за час, поэтому одного взгляда на top мало. Используйте эти команды:

nproc                        # number of vCPU cores
uptime                       # load average over 1, 5 and 15 minutes
top -b -n 1 | head -n 5      # %Cpu(s) line: us sy ni id wa ... st
mpstat 60 60                 # one hour of 1-minute samples, then an "Average" line
pidstat -u 5 3               # which processes use the CPU

• %Cpu(s) в top — это весь VPS. Загрузка CPU равна 100 - id, так что id ниже 50 в течение часа означает превышение лимита.
• htop показывает каждое ядро отдельной полосой. Один процесс может показывать больше 100%, потому что 100% — это одно полное ядро. Нажмите P, чтобы отсортировать по CPU, и M — по памяти.
• Load average учитывает процессы, ожидающие CPU и диск, поэтому высокое значение при низкой загрузке CPU обычно указывает на медленный I/O.
• st (steal) — время, которое гипервизор отдал другим. Если оно долго остаётся высоким при вашей низкой нагрузке, создайте тикет и приложите вывод команд.

Чтобы смотреть прошедшие часы, включите историю sar. Она сохраняет замер каждые 10 минут, и любой час можно проверить задним числом:

# Debian / Ubuntu: turn on history collection (Rocky/Alma: only enable the service)
sed -i 's/^ENABLED="false"/ENABLED="true"/' /etc/default/sysstat
systemctl enable --now sysstat

sar -u                           # CPU every 10 minutes today, plus an Average
sar -u -s 13:00:00 -e 14:00:00   # one specific hour
sar -d -p                        # disk throughput history (rkB/s, wkB/s)
sar -n DEV                       # network history per interface (rxkB/s, txkB/s)

Шаг 3: Измерьте дисковый I/O с помощью iostat, iotop и pidstat

iostat -xm 5        # per disk (e.g. vda): rMB/s, wMB/s, %util, r_await, w_await
iotop -oPa          # only processes doing I/O, with accumulated totals
pidstat -d 5        # per-process kB_rd/s and kB_wr/s

# If iotop warns about CONFIG_TASK_DELAY_ACCT, enable it until the next reboot:
sysctl -w kernel.task_delayacct=1

В выводе iostat сложите rMB/s и wMB/s для своего диска. Короткие пики нормальны; важно, держится ли сумма около 100 и выше часами. Типичные причины: большие бэкапы, импорт баз данных, лавина логов, активный swap на маленьком тарифе или краулер, создающий миллионы файлов. iotop и pidstat -d покажут виновный процесс.

Шаг 4: Следите за месячным трафиком с vnStat

vnStat в фоне учитывает трафик по каждому интерфейсу почти без нагрузки и сохраняет историю после перезагрузок.

systemctl enable --now vnstat
ip -br link              # interface name, e.g. eth0 or ens3

vnstat -i eth0           # summary (data appears after about 5 minutes)
vnstat -m                # per month, with an estimate for the current month
vnstat -d                # per day
vnstat -h                # per hour
vnstat -l                # live rate in Mbit/s, Ctrl+C to stop

vnstat -m показывает полученный (rx), отправленный (tx) и общий трафик по месяцам, а также строку estimated — прогноз на текущий месяц. Сравните прогноз с квотой своего тарифа. vnStat считает оба направления; если не уверены, как считается ваша квота, уточните в тикете.

Для наблюдения за портом в реальном времени подойдут команды ниже. Если скорость долго держится около 350 Mbps на порту 500 Mbps, вы выходите за ориентир в 70%:

nload eth0               # live in/out graph for one interface
iftop -i eth0 -P         # live traffic per connection, with ports
ss -tnp state established | head -n 20   # which processes hold connections

Шаг 5: Дашборды по желанию: Netdata или Prometheus node_exporter

Netdata

Netdata без настройки рисует графики CPU, диска, сети и сервисов в реальном времени. Ему может понадобиться 100 MB RAM и больше, поэтому он подходит для тарифов от 2 GB; на mini и 01 лучше обойтись консольными утилитами выше. Никогда не открывайте его порт в интернет:

# Debian / Ubuntu (Rocky/Alma: dnf install -y netdata from EPEL)
apt install -y netdata

# /etc/netdata/netdata.conf - listen on localhost only
[web]
    bind to = 127.0.0.1

systemctl restart netdata
ss -tlnp | grep 19999        # must show 127.0.0.1:19999, not 0.0.0.0 or *

# On your own computer: open a tunnel, then browse http://localhost:19999
ssh -N -L 19999:127.0.0.1:19999 [email protected]

Prometheus node_exporter

Если Prometheus и Grafana у вас уже работают на другом сервере, на VPS достаточно лёгкого node_exporter. Он слушает порт 9100 на всех интерфейсах, поэтому разрешите доступ только серверу Prometheus (на Rocky/Alma используйте официальный бинарный файл со страницы релизов Prometheus):

apt install -y prometheus-node-exporter
ss -tlnp | grep 9100

# Allow only your Prometheus server to scrape it
ufw allow from 203.0.113.30 to any port 9100 proto tcp
# firewalld (Rocky/Alma):
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.30" port port="9100" protocol="tcp" accept'
firewall-cmd --reload

Шаг 6: Настройте простое оповещение

Этот небольшой скрипт предупреждает, когда load average за 15 минут превышает половину числа ядер, корневой диск заполнен на 85% или месячный трафик превысил 80% квоты. Load — лишь грубый ранний признак; реальную среднюю загрузку CPU уточняйте через sar -u. Предупреждения пишутся в системный журнал и, по желанию, отправляются на webhook (чат, почтовый шлюз и т. п.):

#!/bin/bash
# /usr/local/sbin/vps-alert.sh - simple early warnings, run from cron
QUOTA_GB=1000        # your plan's monthly traffic, e.g. plan 01 = 1 TB
IFACE=eth0
WEBHOOK=             # optional, e.g. https://hooks.example.com/REPLACE-ME

alert() {
  logger -t vps-alert "$1"
  [ -n "$WEBHOOK" ] && curl -fsS -m 10 --data-urlencode "text=$(hostname): $1" "$WEBHOOK" >/dev/null
}

CORES=$(nproc)
LOAD15=$(cut -d' ' -f3 /proc/loadavg)
awk -v l="$LOAD15" -v c="$CORES" 'BEGIN { exit !(l > c * 0.5) }' \
  && alert "15-minute load $LOAD15 on $CORES cores"

DISK=$(df --output=pcent / | tail -n 1 | tr -dc '0-9')
[ "$DISK" -ge 85 ] && alert "root file system ${DISK}% full"

USED=$(vnstat -i "$IFACE" --oneline b | cut -d';' -f11)
[ -n "$USED" ] && [ "$USED" -gt $(( QUOTA_GB * 800000000 )) ] \
  && alert "over 80% of monthly traffic: $(( USED / 1000000000 )) GB"
exit 0

chmod 700 /usr/local/sbin/vps-alert.sh
echo '*/15 * * * * root /usr/local/sbin/vps-alert.sh' > /etc/cron.d/vps-alert
journalctl -t vps-alert --since today      # see past warnings

Поле 11 в выводе vnstat --oneline b — общий трафик за текущий месяц в байтах. Укажите QUOTA_GB и IFACE для своего VPS.

Шаг 7: Ограничьте собственную нагрузку

Большинство проблем с fair use создаёт одна тяжёлая задача. Притормозите её, а не весь сервер.

CPU и диск для одной команды

# Lowest CPU and disk priority for a one-off job
nice -n 19 ionice -c3 tar -czf /root/site.tar.gz /var/www

# Hard caps for a one-off job (cgroup v2: Debian 11+, Ubuntu 22.04+, Rocky/Alma 9)
lsblk -d -o NAME,SIZE        # disk name, usually vda
systemd-run --scope -p CPUQuota=50% \
  -p IOReadBandwidthMax="/dev/vda 50M" -p IOWriteBandwidthMax="/dev/vda 50M" \
  tar -czf /root/site.tar.gz /var/www

nice и ionice лишь понижают приоритет: если конкурентов нет, задача всё равно работает на полной скорости, а ionice не действует при планировщиках none и mq-deadline, типичных для виртуальных дисков. systemd-run с CPUQuota и IO*BandwidthMax задаёт настоящие лимиты. CPUQuota=100% — это одно полное ядро.

Постоянный лимит для сервиса

systemctl edit myapp.service
# add in the editor:
[Service]
CPUQuota=100%
IOReadBandwidthMax=/dev/vda 80M
IOWriteBandwidthMax=/dev/vda 80M

systemctl restart myapp.service
systemctl show myapp.service -p CPUQuotaPerSecUSec

Сетевые передачи

rsync -a --bwlimit=20M /var/www/ [email protected]:/srv/www/   # about 170 Mbit/s
wget --limit-rate=20m https://example.com/big.iso
curl --limit-rate 20M -O https://example.com/big.iso

# Cap ALL outgoing traffic on eth0 at 300 Mbit/s (lost on reboot)
tc qdisc replace dev eth0 root tbf rate 300mbit burst 256kb latency 50ms
tc -s qdisc show dev eth0
tc qdisc del dev eth0 root        # remove the cap

Шаг 8: Повысьте тариф или перейдите на выделенный сервер

Ограничения помогают при редких пиках. Если обычная нагрузка держит среднюю загрузку CPU за час выше 50%, требует длительной высокой скорости диска или регулярно заполняет порт или месячную квоту, сервер просто мал для задачи:

• Повысьте тариф на странице услуги, чтобы получить больше ядер, RAM, SSD и трафика. См. как повысить тариф VPS и расширить раздел.
• Выберите выделенный сервер для постоянной высокой нагрузки на CPU, диск или канал: всё оборудование будет только вашим. Выделенные серверы доступны в Токио, Сеуле и Йоханнесбурге от $199/мес и в Москве от $299/мес. За советом обратитесь в Sales/Inquiries через тикет.

FAQ

VPS начинает тормозить после долгой нагрузки. Это лимит CPU?

Возможно: если средняя загрузка CPU за час превышает 50%, CPU автоматически ограничивается до 50%. Найдите загруженный процесс через htop или pidstat -u, уменьшите или ограничьте его нагрузку и проверьте почасовую историю через sar -u.

Правило 70% порта — это про месячную квоту трафика?

Нет, это разные вещи. Правило 70% касается скорости на протяжении долгого времени (около 350 Mbps на порту 500 Mbps), а квота — общего объёма за месяц. Первое отслеживайте через vnstat -l или nload, второе — через vnstat -m.

Кто поможет разобраться в цифрах?

Создайте тикет в Technical support и укажите IP услуги, время с часовым поясом и вывод команд. У JUSTG работает AI-поддержка 24/7 по тикетам, а инженеры подключаются, когда нужен человек.