InforSupports

Etiqueta: diagnostico

  • Herramientas de monitoreo para homelab: vnStat, cAdvisor, Netdata y más

    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 vnstat

    Consultar 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 monitoreadas

    Interpretando las interfaces detectadas

    En un host con Docker, vnstat --iflist típicamente muestra algo como:

    ens6
docker0
veth55b218c
vetha4d99c4
vethcb08ffb
    InterfazDescripción
    ens6Interfaz de red física principal del servidor
    docker0Bridge virtual principal que usa Docker por defecto
    vethXXXXInterfaces 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 scripts

    3. 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 ens6

    iftop — 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 ens6

    4. 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 stats

    Muestra 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:latest

    Acceso 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.cloud

    Permite 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:

    ComponenteFunción
    PrometheusBase de datos de series temporales que almacena las métricas
    Node ExporterExpone métricas del sistema operativo host para que Prometheus las recolecte
    cAdvisorExpone métricas específicas de contenedores Docker
    GrafanaCapa 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 -w

    Acceso 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:

    1. 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.
    2. cAdvisor — se agrega cuando se necesita métricas Docker más detalladas y con algo más de historial que docker stats.
    3. 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.

  • Diagnóstico de memoria y versión en SQL Server

    Contexto

    Servidor de ejemplo con las siguientes características: 30GB de disco, 2 vCPU, 4GB de RAM, collation Modern_Spanish_CI_AS. Este tipo de diagnóstico es útil cuando un servidor de SQL Server empieza a mostrar señales de presión de memoria, o simplemente para confirmar exactamente qué versión y edición está corriendo antes de planificar un cambio.

    1. Versión y edición del motor

    Lo primero es confirmar exactamente qué se está ejecutando — la edición determina límites como cuánta RAM puede usar el buffer pool:

    SELECT
    SERVERPROPERTY('Edition')       AS edition,
    SERVERPROPERTY('ProductVersion') AS version,
    SERVERPROPERTY('EngineEdition') AS engine_edition;

    2. Límite de memoria configurado (max server memory)

    SQL Server, por defecto, puede intentar usar prácticamente toda la RAM disponible del servidor si no se configura un límite explícito. Esta consulta muestra qué valor está configurado actualmente:

    SELECT name, value_in_use
FROM sys.configurations
WHERE name = 'max server memory (MB)';

    3. Uso total de memoria del proceso SQL Server

    Para ver cuánta memoria está usando realmente el proceso completo, incluyendo memoria virtual comprometida:

    SELECT
    physical_memory_in_use_kb   / 1024 AS memory_in_use_MB,
    large_page_allocations_kb   / 1024 AS large_page_MB,
    locked_page_allocations_kb  / 1024 AS locked_page_MB,
    total_virtual_address_space_kb / 1024 AS total_virtual_MB,
    virtual_address_space_committed_kb / 1024 AS committed_virtual_MB
FROM sys.dm_os_process_memory;

    4. Uso de memoria por tipo (memory clerks)

    SQL Server organiza internamente su consumo de memoria en «clerks» según el componente que la usa (buffer pool, caché de planes de ejecución, etc.). Esta consulta agrupa el consumo por tipo, de mayor a menor:

    SELECT
    type,
    SUM(pages_kb) / 1024 AS memory_MB
FROM sys.dm_os_memory_clerks
GROUP BY type
ORDER BY memory_MB DESC;

    5. Buffer pool específico

    El buffer pool es el componente que cachea páginas de datos en memoria para evitar lecturas a disco — es justo lo que las ediciones Express y Standard limitan agresivamente. Esta consulta aísla específicamente cuánto está usando:

    SELECT
    SUM(pages_kb) / 1024 AS buffer_pool_MB
FROM sys.dm_os_memory_clerks
WHERE type = 'MEMORYCLERK_SQLBUFFERPOOL';

    Resumen de lo que responde cada consulta

    PreguntaDMV / Vista utilizada
    ¿Qué edición y versión está corriendo?SERVERPROPERTY
    ¿Cuánto está configurado como límite de RAM?sys.configurations
    ¿Cuánta RAM usa el proceso completo de SQL?sys.dm_os_process_memory
    ¿Qué componentes están consumiendo más memoria?sys.dm_os_memory_clerks
    ¿Cuánto usa el buffer pool (el que se limita)?sys.dm_os_memory_clerks