Cómo vigilaría un clúster Proxmox con Checkmk (y por qué le pondría Pulse al lado)

Un clúster Proxmox con Ceph tiene muchas piezas que pueden fallar en silencio: un OSD que se cae, un disco que se llena, una copia que falla una noche sí y otra no, un nodo que pierde el quórum. La interfaz de Proxmox te lo enseña si entras a mirarlo, pero nadie entra a mirarlo a las tres de la mañana. Si tuviera que montarlo desde cero, usaría dos herramientas con trabajos distintos: Checkmk para las alertas y el histórico, y Pulse para ver el estado de todo de un vistazo. Aquí te cuento cómo, paso a paso, y las trampas que conviene conocer antes de caer en ellas.

Todo lo que sale aquí es genérico: nada de nombres de servidores ni de la organización. Los nombres de nodos, el sitio de Checkmk y el dominio son de ejemplo.

1. Por qué dos herramientas y no una

Parece redundante, pero cada una hace bien una cosa:

• Checkmk es la monitorización “de verdad”: vigila Proxmox, pero también los switches, los Windows, las impresoras y lo que haga falta. Tiene umbrales, histórico, paradas programadas y notificaciones con reglas. Su punto débil es que la interfaz no está pensada para echar un vistazo rápido a un clúster de virtualización.
• Pulse es un panel hecho para Proxmox (también vale para Docker, PBS y algunas cosas más). En una pantalla ves los nodos, qué VM come más CPU, cómo va el almacenamiento y qué copias han fallado. Se instala en cinco minutos y lee la API con un token de solo lectura.

La regla que seguiría: Checkmk avisa, Pulse se mira. Lo explico al final.

2. Un usuario de solo lectura para Checkmk

Checkmk habla con Proxmox por la API mediante su agente especial. No le des el usuario root: créale uno propio con el rol PVEAuditor, que solo puede leer. En cualquier nodo del clúster:

pveum user add checkmk@pve --password 'UNA_CLAVE_LARGA' --comment "Monitorización (solo lectura)"
pveum acl modify / --users checkmk@pve --roles PVEAuditor

El realm @pve es el de usuarios propios de Proxmox: así no depende del sistema del nodo ni del directorio. Como el clúster comparte la configuración, con hacerlo en un nodo vale para todos.

Si ya seguiste la parte 2 de la serie de Proxmox, este paso te sonará: es el mismo usuario.

3. Dar de alta los nodos en Checkmk

En Checkmk, crea un host por cada nodo (pve-nodo1, pve-nodo2, pve-nodo3). En Monitoring agents, elige Configured API integrations and Checkmk agent, porque vamos a usar las dos cosas.

Después, la regla del agente especial:

1. Setup > Agents > VM, cloud, container > Proxmox VE > Add rule.
2. Usuario checkmk@pve y su contraseña (mejor desde el almacén de contraseñas de Checkmk que escrita en la regla).
3. En Conditions, limita la regla solo a los hosts de los nodos. Si no, Checkmk intentará hablar con la API de Proxmox en todos los hosts de la carpeta.
4. Deja la verificación del certificado activada si los nodos tienen uno válido. Desactivarla es la salida fácil, pero acabas confiando en cualquier cosa que responda en el puerto 8006.

Guarda, haz un descubrimiento de servicios en los nodos y activa los cambios. Ya deberías ver el estado del clúster, el almacenamiento y las copias de seguridad.

La primera trampa: el DNS

Si el descubrimiento falla sin dar mucha pista, mira primero si el servidor de Checkmk resuelve los nombres de los nodos. Proxmox devuelve los nodos por su nombre corto, y si Checkmk no sabe qué IP tiene pve-nodo2, la consulta falla. La solución correcta es meterlos en el DNS. El apaño rápido es ponerlos en el /etc/hosts del servidor (o del contenedor) de Checkmk:

192.168.10.11  pve-nodo1.tu-dominio.es  pve-nodo1
192.168.10.12  pve-nodo2.tu-dominio.es  pve-nodo2
192.168.10.13  pve-nodo3.tu-dominio.es  pve-nodo3

4. El agente clásico y Ceph

Aquí está la segunda trampa: la API de Proxmox no cuenta cómo está Ceph con el detalle que necesitas. Para saber si hay OSD caídos, placement groups degradados o el clúster en HEALTH_WARN, hace falta el agente clásico de Checkmk en cada nodo, con el plugin mk_ceph.

El paquete del agente lo descargas de tu propio servidor de Checkmk (en Setup > Agents > Linux tienes el enlace exacto de tu versión):

# En cada nodo; cambia el servidor, el sitio y la versión por los tuyos
wget https://checkmk.tu-dominio.es/monitor/check_mk/agents/check-mk-agent_2.5.0-1_all.deb
dpkg -i check-mk-agent_2.5.0-1_all.deb

# Registrarlo para que la conexión vaya cifrada
cmk-agent-ctl register --hostname pve-nodo1 \
  --server checkmk.tu-dominio.es --site monitor --user automation

Y el plugin de Ceph, que viene con el propio servidor de Checkmk:

wget -O /usr/lib/check_mk_agent/plugins/mk_ceph.py \
  https://checkmk.tu-dominio.es/monitor/check_mk/agents/plugins/mk_ceph.py
chmod +x /usr/lib/check_mk_agent/plugins/mk_ceph.py

# Comprobar que el agente ya devuelve la sección de Ceph
check_mk_agent | grep -A3 '<<<ceph'

Si salen secciones de Ceph, vuelve a hacer el descubrimiento en Checkmk y te aparecerán los servicios de Ceph.

5. Las VMs como hosts (piggyback)

El agente especial no solo trae datos del nodo: también trae datos de cada VM y contenedor (CPU, memoria, disco, si está encendida, su última copia). Checkmk los guarda como datos piggyback, “a caballito” de otro host. Para verlos, tienes que crear en Checkmk un host por VM con el mismo nombre exacto que tiene en Proxmox.

• Si la VM no tiene agente de Checkmk dentro, en Monitoring agents pon No API integrations, no Checkmk agent y en Piggyback, Always use and expect piggyback data, para que avise si dejan de llegar.
• Si los nombres no coinciden (en Proxmox web01 y en Checkmk web01.tu-dominio.es), usa la regla Hostname translation for piggybacked hosts: quitar el dominio, pasar a minúsculas o una expresión regular. Aplícala solo a los nodos de Proxmox.
• Para ver qué VMs envían datos que nadie recoge:

# En el servidor de Checkmk, como usuario del sitio
cmk-piggyback list orphans

Si la VM es importante, instálale también su propio agente: el piggyback te dice cómo la ve Proxmox desde fuera, y el agente te dice qué pasa dentro (servicios, disco del sistema, actualizaciones).

6. Pulse en un LXC

Pulse se instala como servicio en un contenedor LXC o con Docker, y escucha en el puerto 7655. Yo lo pondría en un LXC pequeño (1 núcleo, 1 GB, 8 GB de disco), igual que hice con PegaProx. El instalador oficial va firmado. El bloque de su README lo descarga, comprueba la firma y solo entonces lo ejecuta. Cópialo de la página del proyecto con la versión exacta de la última release; no lo pego aquí porque cambia con cada versión y te quedaría uno viejo.

Después:

1. Abre http://IP_DEL_LXC:7655 y pega el token de primera configuración (sudo pulse bootstrap-token dentro del LXC).
2. Crea tu cuenta de administrador.
3. Settings > Infrastructure > Add infrastructure y elige Proxmox VE. Pulse te da un script que crea en el nodo un usuario de monitorización con un token de solo lectura. Revísalo antes de pegarlo: es tu clúster.

En un par de minutos tienes todos los nodos, VMs, almacenamiento y copias en una sola pantalla, con siete días de histórico en la edición gratuita. Para Proxmox no hace falta instalar ningún agente: lee la API.

Un aviso que da el propio proyecto y que conviene leer: si Pulse pregunta a las VMs a través del QEMU Guest Agent, ese canal es el mismo que usan las copias con freeze. No toques permisos ni reinicies agentes en plena copia.

7. Quién avisa de qué

Con las dos herramientas funcionando, lo fácil es activar notificaciones en las dos. No lo haría: dos avisos por el mismo disco lleno a las tres de la mañana es la forma más rápida de que alguien acabe silenciando los dos.

Mi reparto:

• Checkmk notifica: nodo caído, Ceph en HEALTH_WARN o HEALTH_ERR, almacenamiento por encima del 80 %, copia fallida, quórum perdido. Con escalado si nadie hace caso.
• Pulse se mira: cuando hay una incidencia o antes de una tarea de mantenimiento, para ver en diez segundos qué VM está dónde y cuánto come. Como mucho le dejaría alguna alerta que Checkmk no cubra, como avisos de actualizaciones.

Paradas programadas en el mantenimiento

Cuando vayas a reiniciar un nodo, pon antes el flag noout de Ceph (para que no empiece a mover datos en cuanto el nodo desaparezca) y programa una parada en Checkmk para ese nodo y sus servicios de Ceph:

ceph osd set noout     # antes de apagar el nodo
# ... mantenimiento ...
ceph osd unset noout   # cuando el nodo vuelva y los OSD estén "up"

Con noout puesto, Ceph se queda en HEALTH_WARN a propósito. Sin parada programada, Checkmk te avisará de algo que ya sabes, y la próxima vez que avise de verdad nadie le hará caso. Y, sobre todo, que no se te olvide el unset: Checkmk te seguirá marcando el aviso hasta que lo quites, y para eso sirve.

Lo que no hay que hacer

• Usar root@pam para la monitorización. Si alguien saca la contraseña del servidor de monitorización, tiene tu clúster entero. PVEAuditor y a correr.
• Confiar solo en la API para Ceph. Sin el agente y mk_ceph, puedes tener un OSD caído y todo en verde.
• Crear hosts de VM con nombres “parecidos”. El piggyback va por nombre exacto; si no coincide, los datos se quedan huérfanos y no te avisa nadie.
• Desactivar el certificado “porque así funciona”. Pon uno válido en los nodos o importa la CA en Checkmk.
• Notificar lo mismo desde dos sitios. Una sola fuente de alertas.

Resumen

1. Usuario checkmk@pve con el rol PVEAuditor en /.
2. Nodos en Checkmk con agente especial + agente clásico, y la regla limitada a los nodos.
3. mk_ceph en cada nodo para saber de verdad cómo está Ceph.
4. VMs como hosts piggyback con el nombre exacto, y cmk-piggyback list orphans para las que faltan.
5. Pulse en un LXC pequeño, con token de solo lectura, para mirar de un vistazo.
6. Checkmk avisa, Pulse se mira, y parada programada siempre que toques un nodo.

Checkmk cuesta más de montar, pero es el que te despierta cuando toca. Pulse es el que abres cuando ya estás despierto y quieres entender qué pasa. Juntos cubren las dos cosas sin pisarse.