Observabilidad de una flota de GPU: alertas que dicen qué hacer

Por qué este laboratorio

Se apoya en años de monitorización y cuadros de Grafana. Aquí las métricas vienen de NVIDIA DCGM, y la pregunta es cuáles merecen una alerta y quién debe recibirla.

Qué he hecho

• Un simulador en Go de 4 nodos × 8 GPU que usa los nombres y etiquetas de métricas de dcgm-exporter, pod y namespace incluidos, con inyección de fallos.
• 17 recording rules y 10 alertas, cada una con su runbook (docs/alerts.md) y una etiqueta action: drain, quarantine o cordon.
• Alertmanager con rutas a guardia, ticket y equipo, e inhibiciones para que una GPU rota no avise además de "GPU ociosa" al equipo.
• Un dashboard de Grafana generado por script y fleetreport con GPU-horas y GPU-horas ociosas por namespace.

Cómo se prueba

7 casos de promtool test rules, tests en Go, comprobaciones de configuración, shellcheck y una prueba de punta a punta con Docker Compose (Prometheus, Alertmanager, Grafana): 32 comprobaciones, en verde a la primera.

Qué aprendí

La comprobación de energía frente a potencia daba falsos fallos con una sola muestra por el jitter del scrape. Ahora usa 1 minuto sobre 2 minutos de datos.

Siguientes pasos

• Cambiar el simulador por dcgm-exporter en tus nodos.
• Importar el cuadro de Grafana y las recording rules.
• Enrutar las alertas de Alertmanager a tus herramientas de guardia y de tickets.

¿Quieres llevarlo a tu entorno o adaptarlo a tu caso? Escríbeme y lo vemos.