Problema

En cualquier homelab que combine varios nodos Proxmox, máquinas virtuales y servicios de monitoreo, el panel de Grafana tiende a convertirse en una hoja de cálculo gigante. Se añaden métricas por curiosidad, se importan dashboards completos y, al final, la vista principal está saturada de gráficas que rara vez indican un problema real. El reto es identificar, de forma reproducible, qué indicadores deben estar presentes en el dashboard de visión general para que sirvan como primer nivel de detección de fallos, sin perder claridad ni generar ruido visual.

Causa

  1. Sobrecarga de paneles – Importar dashboards de la comunidad (por ejemplo, IDs 10347 o 1860) sin filtrar los paneles que realmente importan al entorno propio. Cada panel añade consultas a Prometheus que consumen recursos y distraen al operador.
  2. Falta de criterios de selección – No hay una regla clara que distinga “métrica interesante” de “métrica crítica”. Sin un umbral de acción, cualquier fluctuación se interpreta como alarma.
  3. Inconsistencia en la recolección – Node Exporter y el exporter de Proxmox pueden exponer métricas con nombres diferentes o con etiquetas que cambian entre versiones, lo que genera paneles rotos o datos incompletos.
  4. Alertas ausentes o mal definidas – Un dashboard sin alertas pierde su valor de “detección temprana”. Cuando la alerta está basada en una métrica que nunca cruza su umbral, el panel se vuelve decorativo.

Solución

Adoptar un enfoque basado en tres capas de monitoreo:

Capa Propósito Métricas clave
Infraestructura Salud del hardware y del sistema operativo node_cpu_seconds_total, node_memory_MemAvailable_bytes, node_disk_io_time_seconds_total, node_network_receive_bytes_total
Virtualización Estado de los nodos y contenedores Proxmox proxmox_node_up, proxmox_vm_status, proxmox_storage_usage_bytes
Servicios críticos Disponibilidad de los componentes que realmente importan al usuario up{job="prometheus"}, http_requests_total{handler="/api"}, node_exporter_build_info

Paso a paso

  1. Definir umbrales de acción

    • CPU: alerta cuando el promedio de 5 min supera el 85 % en cualquiera de los nodos.
    • Memoria disponible: alerta si cae por debajo del 10 % de la RAM total.
    • Disco: alerta cuando el uso supera el 80 % en cualquier partición crítica (/, /var/lib/vz).
    • Red: alerta si la tasa de errores (*_err_total) supera 100 en 5 min.

  2. Crear paneles minimalistas

    • Un “Gauge” para cada umbral (CPU, Mem, Disco).
    • Un “Stat” que muestre el número de VMs en estado running vs paused.
    • Un “Table” con los últimos 5 eventos de proxmox_node_up que indique si algún nodo está down.

  3. Agrupar por etiquetas
    Usa la etiqueta instance para distinguir cada host y la etiqueta job para separar node_exporter de proxmox_exporter. Así, un mismo panel puede mostrar la métrica de todos los nodos en una sola visualización.

  4. Implementar alertas en Prometheus
    Define reglas de alerta que disparen notificaciones a Alertmanager. Mantén las reglas en un archivo separado (alerts.yml) para versionado y reutilización.

  5. Validar la carga de consultas
    Usa la vista “Query Inspector” de Grafana para medir el tiempo de respuesta de cada panel. Elimina o simplifica los que superen 2 s de latencia.

Ejemplo de regla de alerta

# alerts.yml
groups:
  - name: homelab-infra
    rules:
      - alert: HighCPUUsage
        expr: avg by (instance) (rate(node_cpu_seconds_total{mode!="idle"}[5m])) > 0.85
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "CPU usage > 85% on {{ $labels.instance }}"
          description: "El nodo {{ $labels.instance }} ha mantenido un uso de CPU superior al 85 % durante los últimos 5 minutos."

      - alert: LowMemoryAvailable
        expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.10
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Memoria disponible < 10% en {{ $labels.instance }}"
          description: "El nodo {{ $labels.instance }} tiene menos del 10 % de memoria disponible."

Cuándo aplicar esta solución

  • Entornos con varios nodos Proxmox y al menos un exporter de Node Exporter activo.
  • Cuando el dashboard actual está saturado y el tiempo de respuesta supera 2 s.
  • Si ya tienes Alertmanager configurado; de lo contrario, la solución sigue siendo útil, pero perderás la notificación automática.
  • No es adecuada para entornos extremadamente simples (un solo servidor sin virtualización), donde un panel único de “uptime” basta.

Verificación

  1. Revisa los paneles: cada gauge debe mostrar valores dentro del rango esperado; si alguno está en rojo sin razón, revisa la regla de alerta asociada.
  2. Simula una condición: por ejemplo, ejecuta stress --cpu 2 --timeout 60 en un nodo y verifica que la alerta HighCPUUsage se dispara y aparece en Alertmanager.
  3. Mide la latencia: abre “Query Inspector” y confirma que todas las consultas se completan en < 2 s.
  4. Comprueba la cobertura: revisa que cada nodo tenga al menos un panel de CPU, Mem, Disco y Red. Si falta alguno, añádelo.

Notas adicionales

  • Etiquetas consistentes: al actualizar Node Exporter, revisa que los nombres de métricas no hayan cambiado (node_cpu_seconds_total sigue siendo el mismo, pero a veces aparecen prefijos).
  • Dashboards de la comunidad: pueden servir como punto de partida, pero siempre elimina paneles que no tengan una regla de alerta asociada.
  • Persistencia de datos: asegúrate de que Prometheus tenga suficiente espacio en disco; un historial corto dificulta la detección de tendencias.
  • Escalado futuro: si añades más nodos o servicios (por ejemplo, un cluster Kubernetes), replica la misma estructura de capas y umbrales; solo añade nuevas métricas bajo la capa “Servicios críticos”.