NexTool Solutions

Un avviso che arriva solo via e-mail è un incidente senza responsabile. L'integrazione tra Zabbix e GLPI serve a trasformare ogni problema rilevato in un ticket tracciabile - con numero, assegnatario, categoria, priorità e SLA - e a chiuderlo da solo quando Zabbix conferma il ripristino. Il trucco non è "creare il ticket": è non crearne quaranta.

Cosa deve garantire l'integrazione

Un ponte Zabbix verso GLPI che regge in produzione ha bisogno di quattro garanzie, non solo di "pubblicare un ticket":

• Idempotenza: un problema apre un ticket, non uno per ogni passo di escalation.
• Correlazione problema/ripristino: l'evento di recovery deve ritrovare e chiudere esattamente il ticket che ha aperto.
• Mappatura della severità: la severità di Zabbix diventa priorità di GLPI in modo coerente, non a discrezione del singolo analista.
• Contesto sufficiente: host, IP, trigger, orario e messaggio nel corpo, così l'analista agisce senza aprire Zabbix.

Architettura: dove il webhook diventa ticket

Zabbix scatta su una Action; la Action esegue un'operazione di media di tipo Webhook; il Webhook è uno script JavaScript nativo di Zabbix che fa un POST verso un endpoint sul lato GLPI. Sul lato GLPI usiamo il receiver del modulo Automazioni, che valida la firma HMAC, applica la mappa dei campi e crea (o chiude) il ticket. Evitiamo di chiamare l'API REST di GLPI direttamente da Zabbix perché ogni chiamata richiederebbe la coppia app-token/user-token e una coppia initSession/killSession - sotto una tempesta di avvisi questo martella l'API ed esaurisce le sessioni.

Artefatto: il Media Type webhook di Zabbix

I parametri mappano macro dell'evento; lo script costruisce il payload e gestisce il codice HTTP. Problema e ripristino usano lo stesso Media Type - il campo event_value li distingue (1 = problema, 0 = ripristino):

// Zabbix -> Media type -> Webhook -> Parametri
// endpoint     = https://glpi.cliente.com/plugins/nextool/automations/webhook/zabbix
// event_id     = {EVENT.ID}        // stabile nella coppia problema/recovery
// event_value  = {EVENT.VALUE}     // 1 = problema, 0 = ripristino
// host_name    = {HOST.NAME}
// host_ip      = {HOST.IP}
// trigger_name = {TRIGGER.NAME}
// severity     = {TRIGGER.SEVERITY}
// occurred     = {EVENT.DATE} {EVENT.TIME}
// message      = {ALERT.MESSAGE}
// hmac         = {$NEXTOOL_HMAC}    // macro segreta, mai nel corpo dell'avviso

var p = JSON.parse(value);
var req = new HttpRequest();
req.addHeader('Content-Type: application/json');
req.addHeader('X-Nextool-Signature: ' + p.hmac);

var payload = JSON.stringify({
    event_id: p.event_id,
    recovery: p.event_value === '0',
    host:     p.host_name,
    host_ip:  p.host_ip,
    trigger:  p.trigger_name,
    severity: p.severity,
    occurred: p.occurred,
    message:  p.message
});

var resp = req.post(p.endpoint, payload);
var code = req.getStatus();
if (code < 200 || code >= 300) {
    Zabbix.log(3, '[nextool] errore HTTP ' + code + ': ' + resp);
    throw 'Invio a GLPI fallito: HTTP ' + code;
}
return resp;

Mappa severità Zabbix verso priorità GLPI

Zabbix ha sei severità; GLPI, cinque priorità. Fissiamo la mappa nel receiver per non lasciarla alla discrezione del singolo analista:

Deduplicazione e chiusura automatica

Questo è il punto che separa un'integrazione giocattolo da una che sopravvive in produzione. All'apertura del ticket, il receiver salva il tickets_id di GLPI come tag dell'evento in Zabbix (o in una tabella di correlazione indicizzata per event_id). Quando Zabbix invia il recovery con lo stesso event_id, il receiver individua quel ticket e aggiunge un follow-up di ripristino - oppure lo chiude, secondo la policy del cliente. Senza quella chiave, il recovery non sa quale ticket chiudere e accumuli ticket aperti per problemi già risolti.

Errori comuni che correggiamo in assistenza

Nell'assistenza quotidiana, l'incidente più comune non è l'avviso che non diventa mai ticket - è l'avviso che ne diventa quaranta. Un'interfaccia in flapping alle 3 di notte ha aperto decine di ticket identici perché la Action scattava a ogni passo di escalation e il receiver non deduplicava. La correzione ha due lati: su Zabbix, dipendenza di trigger, isteresi nell'espressione di recovery e operazione di media solo al primo passo; su GLPI, idempotenza per event_id. Altri due errori ricorrenti: inviare la categoria del ticket come testo libero (GLPI si aspetta un itilcategories_id numerico - un testo nuovo non corrisponde e il ticket arriva senza categoria) e mettere il segreto HMAC nel corpo dell'avviso invece che in una macro protetta come {$NEXTOOL_HMAC}.

Metodi di integrazione a confronto

Se la tua operatività usa già Zabbix ma gli avvisi muoiono in una casella e-mail che nessuno legge, NexTool implementa questo ponte con il modulo Automazioni e mantiene le regole calibrate in assistenza - trigger, mappa di severità e policy di chiusura. Scopri il modulo Automazioni.

Questo contenuto è stato prodotto con l'aiuto dell'intelligenza artificiale e revisionato dal team di Nextool Solutions.