NexTool Solutions

Zabbix diventa monitoraggio proattivo quando l'allarme smette di essere un'e-mail che nessuno legge e diventa un ticket GLPI con un responsabile, una priorita e del contesto. In NexTool, Zabbix non gira isolato: si colloca accanto al GLPI che gia manteniamo per il cliente, e ogni trigger rilevante nasce collegato a un flusso di risposta. Questo articolo mostra come implementiamo e manteniamo questa coppia - dall'architettura al trigger reale e all'integrazione con il modulo Automazioni di NexTool.

Architettura: Zabbix accanto a GLPI, senza competere con esso

L'errore classico e trattare Zabbix e GLPI come mondi separati: Zabbix grida, qualcuno se ne accorge e apre il ticket a mano. Questo aggiunge minuti (o ore) tra la rilevazione e l'azione, e dipende da un umano che guarda il pannello. Nella nostra implementazione, Zabbix Server gira in un contenitore accanto allo stack del cliente, con Zabbix Agent 2 sugli host monitorati. Il punto di integrazione e il media type webhook di Zabbix, che scatena un POST verso l'endpoint stateless del modulo Automazioni di NexTool - ed e Automazioni che crea il ticket GLPI, con autenticazione HMAC SHA-256 per flusso.

Questa separazione dei ruoli conta: Zabbix decide cosa e un segnale degno di azione (il trigger); Automazioni decide come cio diventa lavoro nel service desk (categoria, entita, urgenza, tecnico). Cambiare uno senza toccare l'altro diventa banale.

Trigger che contano: finestra temporale e recovery, non un picco isolato

In manutenzione, la causa numero uno del "tutti silenziano Zabbix" e il flapping: un picco di CPU di 2 secondi solleva e cancella l'allarme decine di volte all'ora. La difesa e doppia - valutare su una finestra temporale e usare un'espressione di recovery separata (isteresi), cosi che il problema si chiuda solo quando si e davvero stabilizzato. Un trigger di disco che si riempie, scritto per prevedere il guasto prima che accada, e cosi:

# Trigger: il filesystem radice si riempira nelle prossime 24h (previsione, non reazione)
# name: "Disco {HOST.NAME}: previsione di saturazione di / entro 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 isteresi (recovery diverso dal problema) per evitare il flapping della CPU
# Espressione di problema:
avg(/Linux by Zabbix agent/system.cpu.util,5m)>90
# Espressione di recovery (cancella solo quando scende davvero):
avg(/Linux by Zabbix agent/system.cpu.util,5m)<70

La funzione timeleft() e il cuore del "proattivo": dalla tendenza, proietta quanto tempo manca al riempimento del disco - e allerta finche c'e ancora tempo di agire, non quando il servizio e gia caduto. L'errore comune qui e usare last() su un valore di utilizzo del 95% e chiamarlo proattivo; non lo e, e reattivo con una soglia piu larga.

Template e macro: coerenza tra gli host

Standardizziamo server, rete e applicazioni tramite un template collegato, con le soglie esposte come macro ({$CPU.UTIL.CRIT}, {$VFS.FS.PUSED.MAX.CRIT}). Cosi un host che vive legittimamente con un utilizzo elevato (un database, ad esempio) riceve un override della macro sull'host stesso, senza duplicare il trigger ne rompere il modello degli altri 200 host. Questo accelera l'onboarding di nuovi host ed evita la deriva silenziosa che corrompe qualsiasi monitoraggio maturo.

Integrazione con GLPI: il webhook che diventa un ticket

Il media type webhook di Zabbix e uno script JavaScript che costruisce il payload e fa il POST. Cio che inviamo ad Automazioni porta abbastanza perche il ticket nasca con contesto - severita, host, item, valore e l'{EVENT.ID}, che usiamo come chiave di idempotenza per non aprire due ticket per lo stesso evento:

// Zabbix media type (webhook) -> Automazioni 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({
  event_id:   '{EVENT.ID}',        // chiave di idempotenza
  severita:   '{EVENT.SEVERITY}',  // mappata sull'urgenza GLPI
  host:       '{HOST.NAME}',
  trigger:    '{TRIGGER.NAME}',
  valore:     '{ITEM.VALUE}',
  stato:      '{EVENT.VALUE}'      // 1=problema, 0=ripristinato
});

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

Sul lato GLPI, il flusso Automazioni mappa la severita di Zabbix sull'urgenza del ticket, sceglie la categoria e l'entita corrette e lo assegna al gruppo tecnico responsabile. Quando l'evento si ripristina (stato: 0), lo stesso flusso puo aggiungere un follow-up "risolto automaticamente" o chiudere il ticket - chiudendo il ciclo rilevazione -> azione -> risoluzione senza intervento manuale.

Reattivo vs proattivo, in pratica

Errori comuni che correggiamo in manutenzione

• Senza espressione di recovery: problema e ripristino usano la stessa condizione, l'allarme lampeggia. Definisci sempre l'isteresi su metriche volatili (CPU, latenza).
• Severita senza mappatura: tutto arriva in GLPI come "media". Mappa Disaster/High su urgenza alta e lascia Information solo sul pannello, senza generare un ticket.
• Senza idempotenza: i retry del webhook creano ticket duplicati. Usare {EVENT.ID} come chiave lo risolve.
• Allertare senza responsabile: un trigger che non punta a un gruppo/tecnico e rumore. Ogni allarme azionabile ha bisogno di una rotta di assegnazione nel flusso Automazioni.

Se hai gia GLPI e vuoi che Zabbix smetta di produrre e-mail ignorate e inizi a produrre ticket con un responsabile e del contesto, questo lavoro di implementazione e manutenzione e cio che NexTool consegna - dal template al flusso di integrazione. Parlaci del supporto e manutenzione del tuo ambiente GLPI + monitoraggio.

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