Un recorrido por las herramientas de monitoreo de red y contenedores más comunes en un homelab, desde lo más simple (vnStat) hasta stacks completos de observabilidad (Prometheus + Grafana), pasando por opciones intermedias que dan buena visibilidad sin tanta configuración.
1. vnStat: monitoreo básico de tráfico de red
vnStat es un contador de tráfico ligero que corre como servicio en segundo plano, acumulando estadísticas de consumo por interfaz sin necesidad de capturar paquetes activamente — esto lo hace muy liviano en recursos comparado con herramientas de captura en tiempo real.
Verificar que esté funcionando
sudo systemctl status vnstat
sudo systemctl start vnstat
sudo systemctl enable vnstatConsultar tráfico
vnstat # resumen general
vnstat -h # por horas
vnstat -d # por días
vnstat -w # por semanas
vnstat -m # por meses
vnstat -l # en tiempo real (modo "live")
vnstat -i ens6 # interfaz específica
vnstat -i ens6 -hg # gráfico horario en texto
vnstat --iflist # listar interfaces monitoreadasInterpretando las interfaces detectadas
En un host con Docker, vnstat --iflist típicamente muestra algo como:
ens6
docker0
veth55b218c
vetha4d99c4
vethcb08ffb| Interfaz | Descripción |
|---|---|
ens6 | Interfaz de red física principal del servidor |
docker0 | Bridge virtual principal que usa Docker por defecto |
vethXXXX | Interfaces virtuales, una por cada contenedor conectado al bridge |
2. Docker: comandos básicos de inspección
# Contenedores activos
docker ps
# Solo IDs
docker ps -q
# Detalle completo de un contenedor
docker inspect <container_id>
# Nombre y MAC address de todos los contenedores activos
docker ps -q | xargs -n1 docker inspect --format '{{.Id}} - {{.Name}} - {{range .NetworkSettings.Networks}}{{.MacAddress}}{{end}}'# Ver todas las interfaces de red del sistema
ip link show
ip -o link show # formato de una línea por interfaz, más fácil de leer en scripts3. Monitoreo por proceso o por conexión
nethogs — tráfico por proceso
Muestra qué proceso específico está generando el tráfico de red, en tiempo real — útil para identificar qué aplicación está consumiendo ancho de banda cuando no está claro a simple vista:
sudo apt install nethogs
sudo nethogs ens6iftop — tráfico por conexión
En vez de agrupar por proceso, muestra el tráfico desglosado por cada conexión activa (IP origen/destino), ordenado por consumo — más útil para identificar con qué host específico se está intercambiando más datos:
sudo apt install iftop
sudo iftop -i ens64. La limitación real de Docker: sin historial por contenedor
Un punto importante a entender: Docker no mantiene estadísticas históricas por contenedor de forma nativa. Las interfaces vethXXXXXX son temporales — se crean y destruyen dinámicamente con cada contenedor, cambian de nombre al reiniciarlo, y por diseño no suelen quedar registradas de forma persistente en herramientas como vnStat. Esto significa que, si se necesita saber «cuánto tráfico consumió tal contenedor la semana pasada», vnStat por sí solo no puede responder esa pregunta — para eso hacen falta herramientas específicas de monitoreo de contenedores.
docker stats: métricas en tiempo real, sin historial
docker statsMuestra CPU, RAM, tráfico de red (Network I/O) y disco por contenedor, pero solo mientras el comando está corriendo — no guarda ningún historial una vez que se cierra la terminal.
5. cAdvisor: métricas Docker con algo de historial
cAdvisor (Container Advisor, de Google) sí guarda un historial reciente de métricas por contenedor y las expone en una interfaz web propia, sin necesidad de configurar nada adicional:
docker run \
--detach \
--volume=/:/rootfs:ro \
--volume=/var/run:/var/run:ro \
--volume=/sys:/sys:ro \
--volume=/var/lib/docker/:/var/lib/docker:ro \
--volume=/dev/disk/:/dev/disk:ro \
--publish=8080:8080 \
--name=cadvisor \
gcr.io/cadvisor/cadvisor:latestAcceso vía navegador en http://IP_SERVIDOR:8080. Los volúmenes montados en modo solo lectura (:ro) le dan a cAdvisor visibilidad sobre el sistema de archivos raíz, los procesos, cgroups y discos del host — necesarios para poder atribuir el consumo de recursos a cada contenedor individualmente.
6. Netdata: monitoreo integral con la instalación más simple
bash <(curl -Ss https://my-netdata.io/kickstart.sh)Acceso en http://IP_SERVIDOR:19999. Netdata destaca por dar visibilidad amplia (CPU, RAM, disco, red, Docker, procesos, servicios, ZFS, temperaturas) con una sola instalación y configuración mínima — es la opción con mejor relación esfuerzo/beneficio para un homelab que no necesita retención de datos a muy largo plazo ni dashboards altamente personalizados.
Centralizar varios servidores con Netdata Cloud
sudo netdata-claim.sh \
-token <TOKEN> \
-rooms <ROOM_ID> \
-url https://app.netdata.cloudPermite ver el estado de múltiples nodos Netdata desde un único panel centralizado en la nube, sin tener que abrir cada instancia por separado.
7. Alternativa «enterprise»: Prometheus + Grafana
Cuando se necesita retención de métricas a largo plazo, dashboards altamente personalizables, y alertas configurables con reglas propias, el stack recomendado combina varias piezas especializadas:
| Componente | Función |
|---|---|
| Prometheus | Base de datos de series temporales que almacena las métricas |
| Node Exporter | Expone métricas del sistema operativo host para que Prometheus las recolecte |
| cAdvisor | Expone métricas específicas de contenedores Docker |
| Grafana | Capa de visualización, dashboards y alertas sobre los datos de Prometheus |
La diferencia clave frente a Netdata: este stack separa la recolección (exporters), el almacenamiento (Prometheus) y la visualización (Grafana) en piezas independientes — más trabajo de configuración inicial, pero mucho más flexible y con retención de datos configurable a voluntad (semanas, meses), en vez de la ventana más corta que suele manejar Netdata por defecto.
8. Opción ligera adicional: Glances
pip install glances[all]
glances -wAcceso en http://IP_SERVIDOR:61208. Glances es una alternativa liviana en Python, útil como panel rápido de estado general del sistema sin necesitar instalar un stack completo.
Recomendación para un homelab típico
Para una infraestructura con Proxmox como hipervisor, corriendo Docker y varios contenedores/servicios en un único nodo físico, la mejor relación esfuerzo/beneficio suele ser progresiva:
- Netdata — cubre aproximadamente el 80% de lo que normalmente se necesita para administrar un homelab completo, con la instalación más simple de todas.
- cAdvisor — se agrega cuando se necesita métricas Docker más detalladas y con algo más de historial que
docker stats. - Grafana + Prometheus — se justifica cuando se necesita histórico avanzado, dashboards personalizados a medida, y alertas con reglas propias — el paso natural cuando un homelab crece más allá de unos pocos servicios.