node_exporter añade el detalle del sistema operativo de cada nodo.Hay una conversación que se repite en todo equipo de infraestructura tras el primer susto serio: «¿cómo no lo vimos venir?». El disco de un nodo se llenó durante días, la métrica estaba ahí, pero nadie la miraba. O un clúster perdió un nodo de madrugada y el aviso llegó cuando el cliente ya había llamado. Monitorizar no es un lujo de equipos grandes: es la diferencia entre gestionar tu infraestructura y que tu infraestructura te gestione a ti a base de sustos.
Este artículo explica cómo montar observabilidad de verdad sobre un cloud privado con Proxmox: el trío Prometheus + Grafana + Alertmanager, qué mide cada pieza, qué métricas vigilar y —lo más ignorado— cómo alertar sin generar tanto ruido que las alertas acaben en una carpeta silenciada. Encaja de forma natural con lo que ya cubrimos sobre alta disponibilidad e infraestructura como código: un clúster que aguanta y que se despliega por código también tiene que verse.
La confusión habitual es tratar «Prometheus», «Grafana» y «alertas» como si fueran lo mismo. Son tres trabajos distintos que encajan.
Prometheus es el motor. Recoge métricas y las guarda en una base de datos de series temporales. Su rasgo definitorio: trabaja por pull, no por push. En lugar de que cada máquina le envíe datos, Prometheus va a buscarlos —sondea (scrapes) cada objetivo cada pocos segundos—. Eso simplifica mucho: para monitorizar algo nuevo, basta con exponer sus métricas en un endpoint HTTP y decirle a Prometheus dónde mirar.
Grafana es los ojos. No guarda nada; consulta a Prometheus y lo pinta en dashboards. Gráficas, paneles, mapas de calor, umbrales en color. Es la capa que convierte miles de números en «esto va bien / esto va mal» de un vistazo.
Alertmanager es la voz. Recibe de Prometheus las condiciones de alerta que se cumplen, las agrupa para no repetir, las silencia cuando toca (mantenimiento) y las enruta a donde haga falta: correo, Slack, Telegram, un webhook. Sin él, una monitorización solo sirve si alguien está mirando la pantalla. Con él, la pantalla te avisa a ti.
La regla mental: Prometheus sabe, Grafana enseña, Alertmanager avisa. Los tres, o tienes datos que nadie mira.
Aquí Proxmox pone las cosas fáciles, porque trae exportación de métricas de serie.
Proxmox VE incluye un servidor de métricas externo configurable en Datacenter → Métrica Server. Soporta formatos como InfluxDB y Graphite, y desde las versiones recientes se integra bien en pipelines Prometheus. Con esto, el propio clúster empuja métricas de VMs, contenedores, nodos y almacenamiento sin instalar nada dentro de las máquinas. Es el nivel «qué está haciendo la plataforma de virtualización».
Las métricas nativas cuentan lo que ve Proxmox, pero no todo el detalle del sistema operativo de cada nodo. Para eso está el node_exporter, el exportador estándar de Prometheus para máquinas Linux. Se instala en cada nodo y expone en un puerto HTTP cientos de métricas: uso de CPU por núcleo, memoria, swap, I/O de disco, temperatura, estado de los sistemas de ficheros, tráfico de red. Es el nivel «qué le pasa a este servidor por dentro».
# En cada nodo Proxmox (sobre Debian)
apt install prometheus-node-exporter
# Expone métricas en http://<nodo>:9100/metricsY en la configuración de Prometheus, cada nodo como objetivo:
# prometheus.yml
scrape_configs:
- job_name: 'proxmox-nodes'
static_configs:
- targets:
- 'pve-nodo1:9100'
- 'pve-nodo2:9100'
- 'pve-nodo3:9100'Una decisión de diseño importante: Prometheus, Grafana y Alertmanager NO deben vivir en el clúster que monitorizan. Si el clúster cae, tu monitorización cae con él justo cuando más la necesitas. Se despliegan aparte —una VM pequeña externa, otro clúster, un servidor dedicado— para que sean el testigo independiente que sobrevive al problema que están vigilando. Es el mismo principio que el QDevice de HA: el vigilante no puede depender de lo vigilado.
Prometheus puede recoger miles de series. La trampa es creer que vigilarlas todas es mejor. No lo es: vigilar todo es vigilar nada. Estas son las que evitan la mayoría de los incidentes reales.
| Métrica | Por qué importa | Umbral orientativo |
|---|---|---|
| Espacio en disco | El fallo nº 1. Un disco lleno tumba VMs, corrompe backups y bloquea logs | Avisar al 80 %, urgente al 90 % |
| RAM y swap | Si un nodo empieza a hacer swap intensivo, el rendimiento se desploma | Swap activo sostenido = revisar |
| Carga de CPU | Saturación mantenida = VMs lentas y clientes quejándose | Load average > nº de núcleos, sostenido |
| Estado del clúster / quorum | Perder quorum es perder HA. Hay que saberlo al segundo | Cualquier nodo fuera de quorum = urgente |
| Salud del almacenamiento | Un disco degradado en Ceph o ZFS es aviso previo de fallo | Estado distinto de OK/HEALTHY = revisar |
| Estado de los backups | Un backup que falla en silencio no existe. Vigila la última ejecución correcta | Sin backup correcto en 24-48 h = urgente |
Fíjate en la última fila. Es la más olvidada y la más peligrosa: un backup que lleva días fallando sin que nadie lo sepa convierte tu estrategia 3-2-1 en una ilusión. Monitorizar el éxito de los backups es tan importante como hacerlos.
Casi todo el mundo monta la monitorización pensando en no perderse nada. Y acaba en el problema contrario: tantas alertas que el equipo las ignora. La «fatiga de alertas» es el fallo silencioso de la observabilidad. Cuando llegan cincuenta avisos al día y cuarenta y ocho son ruido, los dos importantes se pierden entre ellos.
Cómo alertar bien:
La prueba del algodón: si el equipo ha aprendido a ignorar las alertas, la monitorización ya no sirve, por muchos datos que recoja. Menos alertas y mejores vale más que un muro de avisos.
Sin sobreingeniería, el orden que lleva de cero a útil:
node_exporter en cada nodo Proxmox. El detalle del sistema operativo, gratis.node_exporter; empieza por uno y ajústalo, no lo construyas desde cero.Con eso, la próxima vez que algo vaya mal no te enterarás por una llamada. Te enterarás por un aviso, con tiempo para actuar. Que es exactamente lo que separa operar de apagar fuegos.
¿Necesito Prometheus si Proxmox ya tiene gráficas en su interfaz? Las gráficas nativas de Proxmox sirven para mirar el momento, pero no guardan histórico largo, no alertan y no unifican varios clústeres. Prometheus da retención de datos, alertas automáticas y una vista única de toda tu infraestructura. Son complementarios: la interfaz para mirar, Prometheus para vigilar.
¿Puedo poner el stack de monitorización en el propio clúster? No es recomendable. Si el clúster cae, tu monitorización cae con él justo cuando la necesitas. Despliégalo en una VM o servidor externo, para que sea un testigo independiente que sobrevive al problema que vigila.
¿Qué diferencia hay entre las métricas nativas de Proxmox y node_exporter?
Las nativas cuentan lo que ve la plataforma de virtualización (VMs, contenedores, almacenamiento del clúster). El node_exporter añade el detalle del sistema operativo de cada nodo (CPU por núcleo, memoria, swap, I/O, temperatura). Se complementan: usa ambos.
¿Cómo evito que me lleguen demasiadas alertas? Alerta sobre síntomas accionables, no sobre cada métrica cruda. Usa umbrales con duración («10 minutos por encima», no «un segundo»), define severidades reales y deja que Alertmanager agrupe avisos relacionados. Menos alertas y mejores; si el equipo aprende a ignorarlas, la monitorización deja de servir.
¿Grafana guarda las métricas? No. Grafana solo visualiza; los datos los guarda Prometheus (o la fuente que configures). Si Grafana se cae, no pierdes histórico. Si pierdes Prometheus sin respaldo, sí.
node_exporter.¿Gestionas un cloud privado y te enteras de los problemas cuando ya son incidentes? Montamos contigo la observabilidad sobre Proxmox —métricas, dashboards y alertas que avisan con tiempo, sin ahogarte en ruido—. Empieza por nuestra comparativa de cloud o hablemos de tu proyecto.
Proxmox VE 9.2 estrena versión oficial para ARM64 (AArch64), la primera fuera de x86-64 en la historia del producto. Misma base de código, mismos repositorios y mismo soporte, con NVIDIA Grace y NVIDIA Vera como plataformas certificadas de salida. Repasamos qué hardware cumple los requisitos, qué funciones se quedan en x86 y qué cambia (poco, de momento) para quien ya tiene un clúster en producción.
Haces backup de la VM cada noche y duermes tranquilo. Hasta que restauras y la base de datos arranca corrupta o pierde las últimas transacciones. Un snapshot de disco no es lo mismo que un backup consistente de una base de datos. Explicamos la diferencia entre backup consistente por caída, por sistema de ficheros y por aplicación, y cómo conseguir el bueno en Proxmox con el agente invitado, hooks y volcados nativos.
Una red IP enrutada abajo, los servicios de cada cliente encapsulados arriba y BGP distribuyendo dónde está cada MAC. Qué resuelve EVPN-VXLAN, cómo encajan underlay y overlay, qué detalles rompen un fabric (la MTU, siempre la MTU) y cuándo no compensa montarlo.