Servidores cloud (VPS)

Monitoriza CPU, E/S de disco y ancho de banda del VPS (htop, iotop, vnStat, Netdata) y cumple el uso justo

0 lo encontraron útil
VPS fair use, monitor VPS bandwidth, vnstat monthly traffic, iotop disk usage, VPS CPU limit, Netdata install, limit bandwidth Linux
Imprimir

Para cumplir el uso justo en un VPS cloud de JUSTG, vigila tres cifras: la media de CPU de 1 hora (como mucho 50 %), el rendimiento sostenido del disco (no más de 100 MiB/s durante 4 horas o más) y el uso de red (no más del 70 % del puerto compartido durante periodos largos), además de tu tráfico mensual. Esta guía explica cómo medir cada una con herramientas estándar de Linux en Debian, Ubuntu y Rocky Linux / AlmaLinux, cómo recibir un aviso antes de llegar al límite y cómo frenar tus propias tareas.

Las reglas de uso justo y los límites de cada plan

Recurso	Regla en un VPS cloud
CPU	Los picos cortos al 100 % no son problema. Si la media de 1 hora supera el 50 %, la CPU se limita al 50 % automáticamente.
E/S de almacenamiento	No debe mantenerse por encima de 100 MiB/s durante 4 horas o más.
Puerto de red	El puerto es compartido: no uses más del 70 % durante periodos largos. Todos los planes tienen un puerto de 500 Mbps, así que el 70 % son unos 350 Mbps.

Cada plan incluye además una cuota de tráfico mensual:

Plan	CPU	RAM	Tráfico mensual
mini	1 núcleo	512 MB	500 GB
01	2 núcleos	1 GB	1 TB
02	3 núcleos	2 GB	2 TB
03	4 núcleos	4 GB	3 TB
04	5 núcleos	8 GB	4 TB
05	6 núcleos	16 GB	5 TB
06	7 núcleos	24 GB	6 TB

Consulta precios y detalles en la guía de planes de VPS cloud.

Paso 1: Instala las herramientas

# 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

Paso 2: Revisa la carga de CPU y la media de 1 hora

La regla de uso justo habla de la media de una hora, así que no basta con mirar top un momento. Usa estos comandos:

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) en top es el VPS completo. El uso de CPU es 100 - id, así que un id por debajo de 50 durante una hora significa que superas el límite.
htop muestra cada núcleo como una barra. Un proceso puede marcar más del 100 % porque 100 % equivale a un núcleo entero. Pulsa P para ordenar por CPU y M por memoria.
Load average cuenta los procesos que esperan CPU y disco, así que un valor alto con poca CPU suele indicar E/S lenta.
st (steal) es el tiempo que el hipervisor dio a otros. Si se mantiene alto mientras tu uso es bajo, abre un ticket con la salida.

Para ver horas pasadas, activa el historial de sar. Guarda una muestra cada 10 minutos, así puedes revisar cualquier hora después:

# 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)

Paso 3: Mide la E/S de disco con iostat, iotop y 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

En iostat, suma rMB/s y wMB/s de tu disco. Los picos cortos son normales; lo que importa es un total que se mantiene en torno a 100 o más durante horas. Las causas típicas son copias de seguridad grandes, importaciones de bases de datos, avalanchas de logs, uso intenso de swap en un plan pequeño o un crawler que escribe millones de archivos. iotop y pidstat -d te dicen qué proceso es el responsable.

Un %util alto y un await largo con pocos MB/s suelen indicar muchas escrituras pequeñas y aleatorias: se nota lento, pero no es lo mismo que un rendimiento sostenido alto.

Paso 4: Controla el tráfico mensual con vnStat

vnStat registra el tráfico de cada interfaz en segundo plano, casi sin consumo, y conserva el historial tras los reinicios.

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 muestra el tráfico recibido (rx), enviado (tx) y total por mes, y una línea estimated con la previsión del mes actual. Compara esa previsión con la cuota de tu plan. vnStat cuenta ambas direcciones; si no tienes claro cómo se cuenta tu cuota, pregúntalo por ticket.

Para ver el puerto en directo, usa estos comandos. Velocidades sostenidas cercanas a 350 Mbps en el puerto de 500 Mbps significan que superas la referencia del 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

Paso 5: Paneles opcionales: Netdata o Prometheus node_exporter

Netdata

Netdata dibuja gráficas en tiempo real de CPU, disco, red y servicios sin configurar nada. Puede usar 100 MB de RAM o más, así que encaja en planes de 2 GB o más; en mini y 01 te conviene quedarte con las herramientas de consola anteriores. Nunca expongas su puerto a internet:

# 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

Si ya tienes Prometheus y Grafana en otro servidor, en el VPS basta con el ligero node_exporter. Escucha en el puerto 9100 en todas las interfaces, así que permite solo a tu servidor Prometheus (en Rocky/Alma, usa el binario oficial de la página de versiones de 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

Las páginas de métricas revelan nombres de procesos, la estructura de los discos y los patrones de tráfico. Vincúlalas a 127.0.0.1 o restríngelas a una sola IP de origen. Consulta la guía de UFW y firewalld.

Paso 6: Configura una alerta sencilla

Este pequeño script avisa cuando la carga de 15 minutos supera la mitad de tus núcleos, el disco raíz llega al 85 % o el tráfico mensual pasa del 80 % de la cuota. La carga es solo una señal temprana aproximada; confirma la media real de CPU con sar -u. Los avisos van al log del sistema y, si quieres, a un webhook (chat, pasarela de correo, etc.):

#!/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

El campo 11 de vnstat --oneline b es el total del mes actual en bytes. Ajusta QUOTA_GB e IFACE a tu VPS.

Paso 7: Limita tus propias tareas

La mayoría de los problemas de uso justo vienen de una sola tarea pesada. Frena esa tarea, no todo el servidor.

CPU y disco para un solo comando

# 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 e ionice solo bajan la prioridad: si nada compite, la tarea sigue a toda velocidad, y ionice no tiene efecto con los planificadores none o mq-deadline, habituales en discos virtuales. systemd-run con CPUQuota e IO*BandwidthMax pone límites reales. CPUQuota=100% equivale a un núcleo completo.

Un límite permanente para un servicio

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

Transferencias de red

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

El límite de tc afecta a todo lo que sale por la interfaz, incluido SSH. Pruébalo con la sesión abierta y mantén una segunda sesión por si tienes que quitarlo. Para contenedores Docker, usa --cpus y límites de memoria.

Paso 8: Mejora el plan o pasa a un servidor dedicado

Limitar ayuda con picos ocasionales. Si tu carga normal mantiene la media horaria de CPU por encima del 50 %, necesita mucho rendimiento de disco sostenido o llena a menudo el puerto o la cuota mensual, el servidor se queda pequeño:

Mejora el plan desde la página del servicio para tener más núcleos, RAM, SSD y tráfico. Consulta cómo mejorar un VPS y ampliar la partición.
Elige un servidor dedicado si usas CPU, disco o ancho de banda de forma intensa y constante: el hardware es solo tuyo. Hay servidores dedicados en Tokio, Seúl y Johannesburgo desde $199/mes y en Moscú desde $299/mes. Pide consejo a Sales/Inquiries con un ticket.

FAQ

Mi VPS se vuelve lento tras un rato de mucha carga. ¿Es el límite de CPU?

Puede ser: si la media de CPU de 1 hora supera el 50 %, la CPU se limita al 50 % automáticamente. Busca el proceso ocupado con htop o pidstat -u, redúcelo o limítalo, y revisa el historial por horas con sar -u.

¿La regla del 70 % del puerto es la cuota de tráfico mensual?

No, son cosas distintas. La regla del 70 % habla de velocidad durante periodos largos (unos 350 Mbps en el puerto de 500 Mbps), y la cuota es el volumen total del mes. Vigila lo primero con vnstat -l o nload, y lo segundo con vnstat -m.

¿Quién me ayuda a interpretar las cifras?

Abre un ticket a Technical support con la IP del servicio, la hora con zona horaria y la salida de los comandos. JUSTG ofrece soporte con IA 24/7 por ticket, y los ingenieros intervienen cuando hace falta una persona.

Centro de ayuda