vnstat y nethogs: monitoreá el tráfico de red en tu servidor 2026
Cuando el ISP te avisa que pasaste el límite de datos o un servicio está lento, necesitas dos herramientas: vnstat para ver cuánto consumiste, y nethogs para ver quién lo está consumiendo. Acá te explico cómo armar el combo.
TL;DR — Lo que vas a tener al final
- Tiempo de setup: 1.5-2 horas para stack funcional.
- Requisitos: Server con 2+ GB RAM, Docker, root.
- Resultado: Stack Prometheus + Grafana + Alertmanager con alertas a Telegram.
- Troubleshooting: promtool query, métricas de exporters, log de alertmanager.
Por qué dos herramientas y no una
El monitoreo de red tiene dos preguntas distintas: 1. Cuánto: histórico, acumulado, ideal para graficar y detectar tendencias 2. Quién: en tiempo real, ideal para encontrar al proceso que está chupando banda ahora mismo
vnstat es la respuesta a la primera. Corre como daemon, lee contadores del kernel cada 5 minutos, y guarda base de datos local en /var/lib/vnstat/. Es best-effort, no requiere SNMP ni agentes, y te da reportes por hora/día/mes.
nethogs es la respuesta a la segunda. Es un top para red: muestra cada proceso, su PID, usuario, y cuántos KB/s está bajando/subiendo ahora. Ideal para encontrar ese container Docker que se descontroló o un script de backup que quedó corriendo.
Los dos se complementan: con vnstat ves si hubo pico ayer a las 3 AM, y con nethogs ves qué proceso es ahora mismo.
Índice
- Instalar vnstat y nethogs
- vnstat: histórico de tráfico
- nethogs: tráfico por proceso en tiempo real
- Automatizar reportes y alertas
- Troubleshooting común
1. Instalar vnstat y nethogs
Antes de instalar, fíjate qué versión de vnstat te queda. La v2.x es la actual y trae json output, mejor parsing, y es lo que viene en repos modernos. Si te queda v1.18 (vieja), algunas flags no existen.
# Verificar si ya hay algo instalado
which vnstat nethogs
# Instalar (Debian/Ubuntu)
sudo apt install -y vnstat nethogs
# Instalar (Fedora/RHEL)
sudo dnf install -y vnstat nethogs
Después de instalar vnstat, hay que inicializar la base de datos para cada interfaz que quieres monitorear. El daemon solo no escanea interfaces nuevas; tienes que decirselo explícitamente.
# Ver interfaces disponibles
ip -br link show
# Inicializar la base para una interfaz
sudo vnstat -u -i eth0
# Arrancar y habilitar el servicio
sudo systemctl enable --now vnstat
Si vnstat -u -i eth0 falla con “permission denied”: vnstat necesita acceso a /var/lib/vnstat/. Si el directorio no existe, crealo con sudo mkdir -p /var/lib/vnstat && sudo chown vnstat:vnstat /var/lib/vnstat.
2. vnstat: histórico de tráfico
Reporte básico
Una vez que vnstat lleva unos minutos recolectando datos, puedes consultar. La salida sin flags te da un resumen rápido del día en curso, el anterior, y el mes.
# Resumen rápido
vnstat
# Solo una interfaz
vnstat -i eth0
La salida muestra RX (recibido, descarga) y TX (transmitido, subida) en columnas separadas. Eso es clave: muchos problemas de ISP son por subir datos sin darte cuenta (backups, syncs, telemetría), y vnstat te lo muestra claramente.
Si la salida dice “no data available”: el daemon no está corriendo o la interfaz no se inicializó. verifica systemctl status vnstat y que la interfaz en -i exista.
Reportes por período
Para análisis real necesitas granularidad distinta. Las opciones principales son -h (hora), -d (día), -m (mes), y -t (top, los días con más tráfico). Cada una te da una tabla navegable.
# Tráfico de las últimas 24 horas (por hora)
vnstat -h
# Por día del mes en curso
vnstat -d
# Histórico mensual (ideal para ver tendencias)
vnstat -m
# Top 10 días con más tráfico
vnstat -t
Si ves números raros (gigas transferidos cuando no hiciste nada): probablemente vnstat está contando loopback (lo) o alguna interfaz virtual de Docker. Filtrá con -i y listá las interfaces primero: vnstat --iflist.
Exportar a JSON y graficar
vnstat v2 trae --json que es ideal para meter en Grafana, scripts de Python, o lo que sea. También tiene --xml si tu sistema viejo lo prefiere.
# Export a JSON para análisis
vnstat --json -i eth0 > trafico.json
# Solo el día de hoy
vnstat --json -d -i eth0 | jq '.interfaces[0].traffic.day[0]'
# Gráfico de texto en consola (ASCII art)
vnstat -hg # horas con gráfico
vnstat -dg # días con gráfico
Si quieres un gráfico visual real en la web: vnstat tiene vnstat.cgi (paquete separado) que genera imágenes PNG. O instala vnstat-dashboard que es un frontend web moderno. Para Grafana, hay un plugin oficial que consulta la DB directamente.
3. nethogs: tráfico por proceso en tiempo real
Uso básico
A diferencia de vnstat, nethogs es interactivo y se queda corriendo hasta que lo mates. La salida se refresca cada segundo y lista cada proceso con su consumo actual en KB/s.
# Monitorear todas las interfaces
sudo nethogs
# Solo una interfaz específica
sudo nethogs eth0
La salida muestra columnas: PID, usuario, programa, interfaz, KB/s enviados/recibidos. Es muy útil para responder “¿qué está usando mi ancho de banda ahora mismo?”.
Si la salida está vacía o muestra ? en lugar del programa: probablemente el proceso está corriendo como otro usuario y nethogs no puede leer su /proc/PID/exe. Corré siempre con sudo para ver todos.
Opciones de display
nethogs tiene varias teclas de control y flags útiles. -d te da modo daemon (un solo snapshot, ideal para scripts), -t tracemode (más detalle).
# Un solo snapshot cada 5 segundos, salir después
sudo nethogs -d 5 eth0
# Modo trace (más información)
sudo nethogs -t eth0
# Especificar velocidad de refresco
sudo nethogs -d 5 eth0 # refresh cada 5 segundos
Si quieres un solo momento y guardar en archivo: sudo nethogs -d 5 eth0 > snapshot.txt te da un snapshot de 5 segundos y termina. Después puedes parsearlo con awk para alertas automáticas.
Filtrar por aplicación
Si ya sabes que quieres mirar solo tráfico de Docker o solo SSH, puedes usar -p para filtrar. Útil cuando sabes qué proceso sospechás pero quieres confirmar.
# Modo promiscuo (no es filtro por nombre — escucha todo el tráfico de la interfaz)
sudo nethogs -p eth0
# Combinado con interfaz y delay
sudo nethogs -p -d 3 eth0
Si nethogs no muestra tráfico de containers Docker: Docker corre los procesos en network namespaces separados. Si el container tiene su propia interfaz virtual, nethogs en la interfaz del host no la ve. Para monitorear containers, usa docker stats en paralelo o nethogs docker0.
4. Automatizar reportes y alertas
Cron con vnstat para reporte diario
Lo más útil es un script que corra a la madrugada, guarde el reporte del día anterior, y te lo mande por mail o lo deje en un directorio accesible.
# Crear script /usr/local/bin/trafico-diario.sh
sudo tee /usr/local/bin/trafico-diario.sh > /dev/null <<'EOF'
#!/bin/bash
FECHA=$(date -d "yesterday" +%Y-%m-%d)
REPORTE=$(vnstat -d -i eth0 | tail -n 5)
echo "Tráfico del día $FECHA:" > /var/log/trafico-diario.log
echo "$REPORTE" >> /var/log/trafico-diario.log
EOF
sudo chmod +x /usr/local/bin/trafico-diario.sh
# Agregar a cron (corre a las 23:55)
echo "55 23 * * * root /usr/local/bin/trafico-diario.sh"
| sudo tee /etc/cron.d/trafico-diario
Después puedes hacer que ese archivo sea leído por un script que te mande mail, lo suba a un webhook de Discord/Slack, o lo grafique.
Si el cron no corre: revisa que el servicio cron esté activo (sudo systemctl status cron). En algunas distros (Fedora, RHEL modernas) hay que habilitar crond en vez de cron.
Alertas con nethogs y watchdog
Para alertas en tiempo real cuando un proceso supera X MB/s, combinás nethogs -d N con un script que mate al proceso o mande notificación. El siguiente ejemplo mata cualquier proceso que pase de 50 MB/s sostenido por 10 segundos (¡cuidado!, esto es agresivo).
sudo tee /usr/local/bin/watchdog-banda.sh > /dev/null <<'EOF'
#!/bin/bash
# Capturar 10 snapshots de 5s cada uno
for i in $(seq 1 10); do
sudo nethogs -d 5 eth0 | tail -n +3
done | awk '
$4 > 50 { print $2, $4, $5 }
' | sort -u | while read pid rx tx; do
echo "$(date): Proceso $pid pasó umbral - RX:$rx TX:$tx MB/s"
# kill -TERM $pid # descomentar si quieres matar
done
EOF
sudo chmod +x /usr/local/bin/watchdog-banda.sh
Si quieres solo alertar sin matar: cambiá kill -TERM $pid por un curl a un webhook de Slack/Discord. Es más seguro y reversible.
Exportar a Prometheus con vnstat-exporter
Si ya tienes Prometheus + Grafana, hay exporters oficiales que leen la DB de vnstat y exponen métricas. La integración es directa con node_exporter o con vnstat-exporter standalone.
# Instalar vnstat-exporter (ejemplo con docker)
docker run -d --name vnstat-exporter
-p 9095:9095
-v /var/lib/vnstat:/var/lib/vnstat:ro
ngosang/vnstat-exporter:latest
Después agregás vnstat-exporter:9095 como target en Prometheus y tienes métricas de tráfico listas para Grafana.
Si Prometheus no scrapea el exporter: verifica que el contenedor esté corriendo (docker ps), que el puerto sea accesible desde el servidor Prometheus (curl http://localhost:9095/metrics), y que el target esté bien definido en prometheus.yml.
5. Troubleshooting común
“vnstat muestra cero bytes aunque la red funciona”
El daemon no está recolectando datos. Tres causas típicas: 1. Servicio no está corriendo (systemctl status vnstat) 2. Interfaz no inicializada (vnstat -u -i eth0) 3. Permisos en el directorio de DB
# Ver estado del servicio
sudo systemctl status vnstat
# Ver logs del daemon
sudo journalctl -u vnstat -n 30
# Ver si la DB tiene datos
sudo vnstat --dbdir /var/lib/vnstat --query list
Si el servicio está corriendo pero no recolecta: probablemente el nombre de la interfaz cambió. vnstat guarda el nombre en la DB; si tu interface pasó de eth0 a enp3s0 (udev rule nueva), tienes que migrar la DB: sudo vnstat --rename eth0 enp3s0.
“nethogs no muestra nada”
Puede ser que el kernel no esté exponiendo la información que nethogs necesita. verifica que /proc/net/dev tenga datos:
# Ver contadores por interfaz
cat /proc/net/dev
# Ver tráfico por socket
ss -s
Si /proc/net/dev muestra datos pero nethogs no: estás corriendo sin sudo. nethogs necesita leer /proc/PID/net/dev de cada proceso, y eso requiere root o capabilities específicas. Sin sudo, solo ves tus propios procesos.
“Los números de vnstat no coinciden con el ISP”
Los ISPs cuentan distinto. Ellos suelen contar el tráfico total (incluyendo headers Ethernet, PPPoE, retransmisiones TCP), mientras que vnstat cuenta los bytes IP que vio el kernel. La diferencia puede ser 5-15%.
Si la diferencia es muy grande (>30%): probablemente estás contando loopback o una interfaz virtual de Docker/bridge. Listá las interfaces que vnstat monitorea: vnstat --iflist y deshabilitá las que no te interesan con vnstat --remove -i docker0.
“Quiero monitorear varios servidores desde un lugar”
vnstat es local por diseño. Para vista centralizada tienes tres caminos: 1. Centralizar DBs: rsync de /var/lib/vnstat/ a un servidor central, leer con vnstat ahí 2. vnstat-exporter + Prometheus: cada nodo con exporter, Grafana agrega 3. API propia: vnstat tiene --xml y --json, fácil de scrapear con un cron y meter en una DB central
# Opción 1: rsync diario de las DBs
rsync -avz servidor:/var/lib/vnstat/ /central/vnstat/
Si quieres empezar simple: la opción 1 (rsync + vnstat central) te da visibilidad agregada sin instalar nada. Después migrás a Prometheus si necesitas alertas.
Resumen
vnstat y nethogs cubren los dos ángulos del monitoreo de red: histórico y en tiempo real. vnstat te dice cuánto consumiste (y cuándo); nethogs te dice quién lo está consumiendo ahora. Los dos juntos son suficientes para diagnosticar la mayoría de los problemas de tráfico en un homelab o servidor chico.
Para reportes visuales más serios, exportá a Prometheus + Grafana. Para alertas en tiempo real, combiná nethogs con un script en cron y un webhook de Slack/Discord. Y para entender los picos que detectes con vnstat, usa [mtr y traceroute](/mtr-traceroute-diagnostico-red-linux-2026/) para ver si el problema es de red o local.
Preguntas frecuentes
¿Por qué vnstat y nethogs: monitoreá el tráfico de red en tu servidor 2026 es relevante para sysadmins Linux?
Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.
¿Qué necesito para empezar con vnstat y nethogs: monitoreá el?
Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.
¿Cuáles son los errores más comunes con vnstat y nethogs: monitoreá el?
Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.
¿Cuándo usar vnstat y nethogs: monitoreá el y cuándo una alternativa?
Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.
¿Cómo migro desde una configuración previa a vnstat y nethogs: monitoreá el?
Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.
Lee también
- Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
- Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
- Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
- Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
- Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux
