NexTool Solutions

Zabbix se convierte en monitoreo proactivo cuando la alerta deja de ser un correo que nadie lee y pasa a ser un ticket en GLPI con responsable, prioridad y contexto. En NexTool, Zabbix no funciona aislado: se ubica junto al GLPI que ya mantenemos para el cliente, y cada trigger relevante nace conectado a un flujo de respuesta. Este articulo muestra como implantamos y mantenemos esa dupla - desde la arquitectura hasta el trigger real y la integracion con el modulo Automatizaciones de NexTool.

Arquitectura: Zabbix junto a GLPI, no compitiendo con el

El error clasico es tratar Zabbix y GLPI como mundos separados: Zabbix grita, alguien lo ve y abre el ticket a mano. Eso agrega minutos (u horas) entre la deteccion y la accion, y depende de que un humano este mirando el panel. En nuestra implantacion, Zabbix Server corre en un contenedor junto al stack del cliente, con Zabbix Agent 2 en los hosts monitoreados. El punto de integracion es el media type de webhook de Zabbix, que dispara un POST al endpoint stateless del modulo Automatizaciones de NexTool - y es Automatizaciones quien crea el ticket en GLPI, con autenticacion HMAC SHA-256 por flujo.

Esa separacion de roles importa: Zabbix decide que es una senal digna de accion (el trigger); Automatizaciones decide como eso se convierte en trabajo en el service desk (categoria, entidad, urgencia, tecnico). Cambiar uno sin tocar el otro se vuelve trivial.

Triggers que importan: ventana temporal y recovery, no un pico aislado

En el mantenimiento, la causa numero uno de "todos silencian Zabbix" es el flapping: un pico de CPU de 2 segundos levanta y limpia la alerta decenas de veces por hora. La defensa es doble - evaluar sobre una ventana temporal y usar una expresion de recovery separada (histeresis), para que el problema solo cierre cuando de verdad se estabilizo. Un trigger de disco llenandose, escrito para predecir la falla antes de que ocurra, se ve asi:

# Trigger: el filesystem raiz se llenara en las proximas 24h (prediccion, no reaccion)
# name: "Disco {HOST.NAME}: prediccion de saturacion de / en 24h"
timeleft(/Linux by Zabbix agent/vfs.fs.size[/,pfree],1h,0)<24h
  and
last(/Linux by Zabbix agent/vfs.fs.size[/,pused])>80

# Trigger con histeresis (recovery distinto del problema) para evitar flapping de CPU
# Expresion de problema:
avg(/Linux by Zabbix agent/system.cpu.util,5m)>90
# Expresion de recovery (solo limpia cuando baja de verdad):
avg(/Linux by Zabbix agent/system.cpu.util,5m)<70

La funcion timeleft() es el corazon de lo "proactivo": a partir de la tendencia, proyecta cuanto tiempo falta para que el disco se llene - y alerta mientras aun hay tiempo de actuar, no cuando el servicio ya cayo. El error comun aqui es usar last() sobre un valor de 95% de uso y llamarlo proactivo; no lo es, es reactivo con un umbral mas holgado.

Plantillas y macros: consistencia entre hosts

Estandarizamos servidores, red y aplicaciones mediante una plantilla vinculada, con los umbrales expuestos como macros ({$CPU.UTIL.CRIT}, {$VFS.FS.PUSED.MAX.CRIT}). Asi un host que legitimamente vive con uso alto (una base de datos, por ejemplo) recibe un override de la macro en el propio host, sin duplicar el trigger ni romper el patron de los otros 200 hosts. Esto acelera el onboarding de nuevos hosts y evita la divergencia silenciosa que corrompe cualquier monitoreo maduro.

Integracion con GLPI: el webhook que se vuelve ticket

El media type de webhook de Zabbix es un script JavaScript que arma el payload y hace el POST. Lo que enviamos a Automatizaciones lleva lo suficiente para que el ticket nazca con contexto - severidad, host, item, valor y el {EVENT.ID}, que usamos como clave de idempotencia para no abrir dos tickets del mismo evento:

// Zabbix media type (webhook) -> Automatizaciones NexTool -> GLPI
var req = new HttpRequest();
req.addHeader('Content-Type: application/json');
req.addHeader('X-Signature: ' + hmacSha256(params.payload, params.secret));

var payload = JSON.stringify({
  evento_id:  '{EVENT.ID}',        // clave de idempotencia
  severidad:  '{EVENT.SEVERITY}',  // mapeada a urgencia GLPI
  host:       '{HOST.NAME}',
  disparador: '{TRIGGER.NAME}',
  valor:      '{ITEM.VALUE}',
  estado:     '{EVENT.VALUE}'      // 1=problema, 0=recuperado
});

var resp = req.post('https://glpi.cliente.com/automatizaciones/hook/zabbix', payload);
return JSON.stringify({ tags: [{ tag: '__glpi_ticket', value: resp }] });

Del lado de GLPI, el flujo de Automatizaciones mapea la severidad de Zabbix a la urgencia del ticket, elige la categoria y la entidad correctas y lo asigna al grupo tecnico responsable. Cuando el evento se recupera (estado: 0), el mismo flujo puede agregar un seguimiento de "resuelto automaticamente" o cerrar el ticket - cerrando el ciclo deteccion -> accion -> resolucion sin intervencion manual.

Reactivo vs proactivo, en la practica

Errores comunes que corregimos en el mantenimiento

• Sin expresion de recovery: problema y recuperacion usan la misma condicion, la alerta parpadea. Siempre defina histeresis en metricas volatiles (CPU, latencia).
• Severidad sin mapeo: todo llega a GLPI como "media". Mapee Disaster/High a urgencia alta y deje Information solo en el panel, sin generar ticket.
• Sin idempotencia: los reintentos del webhook crean tickets duplicados. Usar {EVENT.ID} como clave lo resuelve.
• Alertar sin responsable: un trigger que no apunta a grupo/tecnico es ruido. Toda alerta accionable necesita una ruta de asignacion en el flujo de Automatizaciones.

Si ya tienes GLPI y quieres que Zabbix deje de generar correos ignorados y empiece a generar tickets con responsable y contexto, ese trabajo de implantacion y mantenimiento es lo que NexTool entrega - desde la plantilla hasta el flujo de integracion. Habla con nosotros sobre soporte y mantenimiento de tu entorno GLPI + monitoreo.

Este contenido fue producido con ayuda de inteligencia artificial y revisado por el equipo de Nextool Solutions.