🌐 También en: English · Deutsch · Français
🔍 A veces un proyecto personal nace de un problema del trabajo, no del homelab. Este fue el caso: ahora mismo estoy lidiando profesionalmente con Graylog como plataforma de gestión de logs y necesitaba plugins de monitorización decentes para él, tanto para Icinga2 como para Zabbix. Seguro que alguien ya lo ha resuelto, ¿verdad? ¿¿Verdad?? 😅
📉 La parte decepcionante: buscar en Google y GitHub
Mi primer paso fue el obvio: encontrar a alguien que ya lo hubiera construido, porque reinventar la rueda es de pardillos. Los resultados fueron, por decirlo con suavidad, decepcionantes. Lo que había era o extremadamente minimalista (un check escrito a fuego, cero umbrales, el equivalente en monitorización a un detector de humo sin pilas) o directamente prehistórico: algunos repos llevaban hasta diez años sin ver un commit. La API REST de Graylog ha cambiado bastante desde la última vez que una mano humana tocó esos plugins. No es precisamente una base de monitorización que inspire confianza. 🦕
💡 La idea ligeramente desquiciada
Así que tuve lo que generosamente llamaré una «idea gloriosa»: que Claude levantara Graylog, Icinga2 y Zabbix en mi propio servidor con Docker Compose y, sin más… construyera los plugins de monitorización desde cero, probándolo todo en directo contra una instancia real en marcha, en lugar de copiar y pegar de un artículo de blog de hace diez años y cruzar los dedos. 🐳
Le pedí a ChatGPT una lista de los checks y métricas más importantes que conviene vigilar en Graylog: uso del journal, salud del clúster de indexación, estado de los inputs, rendimiento, salud de los nodos, ese tipo de cosas. El encargo real para Claude era entonces: implementar los checks, probar las llamadas reales a la API contra una instancia en marcha y corregir/validar el parseo del JSON según lo que Graylog devuelve de verdad, no según lo que asegura una documentación de hace tres versiones mayores.
🧠 Donde se acabó el conocimiento del entrenamiento
Claude traía de su entrenamiento bastante conocimiento previo sobre la API REST de Graylog: nombres de endpoints, la estructura general. Parte de él aguantó bien. Otra parte, para nada: un par de nombres de campos JSON que daba por hechos ya no existen, y al menos un endpoint (un check de estado para balanceador de carga que indica su estado mediante el código de estado HTTP en bruto en lugar de un cuerpo JSON, porque para qué ponerlo fácil) estaba mal desde el primer día sin que nadie lo notara. Resulta que adivinar de memoria solo te lleva hasta cierto punto frente a una API que ha tenido tres años para ir a la deriva. 🎯
Lo que de verdad cerró la brecha: le pasé a Claude una exportación OpenAPI completa sacada directamente de mi propia instancia de Graylog. Con eso pudo contrastar cada endpoint y cada nombre de campo que suponía con la especificación real y actual; y como además le había dejado construir el entorno de pruebas con Docker, pudo ir un paso más allá y ejecutar de verdad las llamadas en lugar de limitarse a leer sobre ellas como una especie de turista de APIs. Los dos bugs reales que encontró así solo aparecieron en tiempo de ejecución, no leyendo la documentación. 🐛➡️✅
Giro de guion extra: a mitad del camino me di cuenta de que todo el banco de pruebas llevaba un buen rato corriendo contra Graylog 6.1, mientras que la especificación OpenAPI que le había pasado era de la 7.1.3. El clásico momento «en mi máquina (equivocada) funciona». Lo pillé en plena revisión, hice reconstruir el entorno con la versión correcta y le pedí a Claude que repitiera toda la batería de pruebas de principio a fin, por pura paranoia. La buena noticia: los dos bugs encontrados eran idénticos en ambas versiones; nada específico de una versión, simplemente suposiciones erróneas desde el principio. Aun así, mejor confesar el despiste que hacer como si nunca hubiera pasado. 🙈
✅ El resultado
De todo esto salieron dos implementaciones de checks separadas y realmente nativas, no una pegada con cinta americana alrededor de la otra y a correr. Icinga2 recibe un plugin clásico al estilo Nagios (códigos de salida, OK/WARNING/CRITICAL, perfdata, todo el paquete). Zabbix, en cambio, recibe su propia versión idiomática, en la que cada check devuelve un valor en bruto y los umbrales de verdad viven en triggers de Zabbix, porque así es como Zabbix quiere que lo alimenten, y no porque el modo nativo fuera la opción cómoda (que no lo fue en absoluto: pregúntame algún día por parsear el formato JSON del Low-Level Discovery de Zabbix). Ambos se probaron también contra una instancia real de Icinga2/Zabbix en marcha, no solo contra Graylog de forma aislada, incluido ver cómo un trigger real de Zabbix pasaba al estado «problema» justo cuando yo lo quería, lo que me produjo una satisfacción desproporcionada para un sábado. 📡
Todo (plugins, instrucciones de instalación y documentación completa) es público:
github.com/aptupgrademe/graylog-checks
Si estás atascado monitorizando Graylog con un script de Nagios de hace diez años sacado de un repo cualquiera de GitHub, ojalá esto te ahorre la arqueología. 🏺
