Problema

En infraestructuras que combinan Proxmox, TrueNAS, Docker, servidores Linux y Windows, cada componente genera su propio conjunto de métricas y eventos. Cuando el número de nodos crece, la rutina de abrir la consola de cada host, revisar el estado de los backups, validar los scrubs de ZFS, inspeccionar logs de contenedores y comprobar la salud de discos se vuelve una tarea diaria que consume tiempo y, lo peor, se abandona. La consecuencia típica es que fallos críticos (una copia de seguridad corrupta, un disco a punto de morir, un contenedor atrapado en bucle de reinicio) pasan desapercibidos hasta que provocan una interrupción visible.

El desafío no es solo la cantidad de fuentes, sino la falta de un punto único donde consolidar la información y generar alertas sólo cuando algo realmente necesita atención. Sin una solución centralizada, el administrador termina confiando en “miradas rápidas” que no garantizan cobertura completa.

Causa

  1. Fragmentación de herramientas – Proxmox ofrece su propio panel, ZFS se controla con zpool y smartctl, Docker tiene docker ps y healthchecks, y Windows expone eventos a través del Event Viewer. Cada una requiere comandos o APIs diferentes.

  2. Ausencia de correlación – Un backup exitoso no implica que la verificación haya pasado; un scrub puede terminar con errores que solo aparecen en los logs de ZFS. Cuando los datos se revisan por separado, la correlación se pierde.

  3. Escalabilidad manual – Añadir un nuevo nodo implica replicar la misma lista de chequeos en la cabeza del administrador. Con cada host extra, la probabilidad de omitir un chequeo aumenta.

  4. Seguridad del agente – Para leer SMART, ZFS y métricas de hypervisor, el agente necesita privilegios de root. Si el proceso de recolección no está bien aislado, se abre una superficie de ataque.

Solución

Implementar un agente ligero en cada host que exporte, mediante HTTPS, un JSON estructurado con los indicadores críticos y un servidor central que reciba esos datos, los almacene y genere alertas sólo cuando se cumplan condiciones definidas. El modelo se basa en tres capas:

  1. Agente de recolección – Script o binario que:

    • Ejecuta pvesh o la API de Proxmox para obtener estado de VMs y tareas.
    • Llama a zpool status -x y zpool list -H para salud de pools y scrubs.
    • Usa smartctl -A /dev/sdX para errores SMART.
    • Consulta docker ps --filter "status=running" y docker inspect --format "{{.State.Health.Status}}" para healthchecks.
    • En Windows, emplea Get-WinEvent (via PowerShell) para errores críticos y Get-PhysicalDisk para SMART.

    Cada dato se normaliza en un esquema común (component, status, message, timestamp) y se envía a la URL del servidor central con un token de autenticación.

  2. Servidor de ingestión – Servicio HTTP (por ejemplo, una pequeña aplicación Go o Node) que:

    • Valida el token y el origen IP.
    • Almacena los eventos en una base ligera (SQLite o InfluxDB) para consultas históricas.
    • Evalúa reglas definidas en YAML (por ejemplo, “si backup_status != ok → alerta”).

  3. Motor de alertas – Conexión a SMTP o a ntfy.sh para notificaciones. El motor revisa la tabla de eventos cada minuto y dispara correos o push solo cuando una regla se cumple.

Ventajas clave

  • Un solo punto de verdad: todas las métricas llegan al mismo servidor, lo que permite dashboards y búsquedas unificadas.
  • Escalabilidad horizontal: agregar un host solo implica instalar el agente y registrar su token.
  • Seguridad mínima: el agente solo abre conexiones salientes; no escucha puertos internos, reduciendo la superficie de exposición.
  • Flexibilidad de reglas – Puedes crear alertas específicas (p.ej., “alerta si cualquier disco SMART tiene Reallocated_Sector_Ct > 0”).

Cuándo aplicar esta solución

  • Entornos heterogéneos donde coexisten hipervisores, sistemas de archivos avanzados y contenedores.
  • Número de nodos ≥ 5 y la carga de revisión manual supera 30 minutos al día.
  • Políticas de SLA que requieren notificaciones proactivas de fallos de backup, degradación de discos o contenedores inestables.
  • No aplicable si la infraestructura es monolítica (único servidor con un solo stack) y ya cuenta con una solución de monitoreo integral (p.ej., Zabbix o Prometheus con exporters) que cubra todos los componentes.

Código

#!/usr/bin/env bash
# agente.sh – versión mínima para Linux
# Requiere: curl, jq, smartctl, pvesh, docker, zpool
TOKEN="YOUR_SECRET_TOKEN"
SERVER="https://monitor.example.com/ingest"

collect_proxmox() {
  pvesh get /nodes --output=json | jq -c '.[] | {component:"proxmox", host:.node, status:"ok", message:"node reachable", timestamp:now}'
  pvesh get /nodes/$(hostname)/qemu --output=json | jq -c '.[] | {component:"vm", vmid:.vmid, status:.status, message:"VM state", timestamp:now}'
}

collect_zfs() {
  zpool status -x | grep -q "all pools are healthy"
  HEALTH=$([ $? -eq 0 ] && echo "ok" || echo "degraded")
  zpool list -H -o name,health,scrub_status | while read -r name health scrub; do
    echo "{\"component\":\"zfs\",\"pool\":\"$name\",\"status\":\"$health\",\"scrub\":\"$scrub\",\"timestamp\":$(date +%s)}"
  done
}

collect_smart() {
  for dev in /dev/sd?; do
    ERR=$(smartctl -A "$dev" | awk '/^ 5 /{print $10}')
    [[ $ERR -gt 0 ]] && STATUS="warning" || STATUS="ok"
    echo "{\"component\":\"smart\",\"device\":\"$dev\",\"status\":\"$STATUS\",\"reallocated\":$ERR,\"timestamp\":$(date +%s)}"
  done
}

collect_docker() {
  docker ps --format '{{json .}}' | jq -c '{component:"docker",container:.Names,status:.State,health:(.Status|match("healthy")?.string // "unhealthy")}'
}

payload=$(printf "[%s]" "$( (collect_proxmox; collect_zfs; collect_smart; collect_docker) | paste -sd, - )")
curl -s -X POST "$SERVER" -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -d "$payload"

Nota: El script anterior es intencionalmente simple; en producción se recomienda empaquetarlo como binario con verificación de integridad y manejo de reintentos.


## Verificación
1. **Instalación del agente**  
   - Copiar `agente.sh` a `/usr/local/bin/monitor-agent` y marcarlo ejecutable.  
   - Crear un `systemd` unit:

   ```bash
   cat > /etc/systemd/system/monitor-agent.service <<'EOF'
   [Unit]
   Description=Monitor de Proxmox/ZFS/Docker
   After=network-online.target
   Wants=network-online.target

   [Service]
   ExecStart=/usr/local/bin/monitor-agent
   Restart=on-failure
   User=root

   [Install]
   WantedBy=multi-user.target
   EOF
   systemctl daemon-reload
   systemctl enable --now monitor-agent.service

  1. Comprobar envío

    • Ejecutar journalctl -u monitor-agent -f y observar que la respuesta HTTP sea 200 OK.
    • En el servidor central, consultar la tabla events (p.ej., SELECT * FROM events LIMIT 5;) y validar que los campos component, status y timestamp aparecen correctos.

  2. Probar regla de alerta

    • Simular un fallo: smartctl -t offline /dev/sdb y esperar a que el agente reporte status":"warning".
    • Verificar que llega un correo o notificación ntfy con el asunto “SMART warning on /dev/sdb”.

Notas adicionales

  • Seguridad del token: almacénalo en /etc/monitor-agent/token con permisos 600. El agente lo lee en tiempo de ejecución y nunca lo escribe en logs.
  • Compatibilidad Windows: la lógica es idéntica, pero el agente se implementa como script PowerShell que usa Invoke-RestMethod. Mantén la misma estructura JSON para que el servidor no necesite adaptaciones.
  • Escalado de almacenamiento: si el número de eventos supera varios miles por día, migra de SQLite a InfluxDB o Prometheus Remote Write; la API de ingestión sigue siendo la misma.
  • Desactivación de componentes: el archivo de configuración /etc/monitor-agent/config.yaml permite habilitar o deshabilitar bloques (zfs: false, docker: true). Útil en hosts que no ejecutan ciertos servicios.
  • Auditoría: registra cada envío con hash SHA256 del payload; facilita la detección de manipulaciones en tránsito.

Con este enfoque, la supervisión pasa de ser una lista de comandos manuales a un flujo automatizado que solo interrumpe al administrador cuando algo realmente necesita su intervención. La reducción de ruido y la centralización de datos hacen que la gestión de entornos mixtos sea sostenible a medida que la infraestructura crece.