Zabbix devient une supervision proactive lorsque l'alerte cesse d'etre un e-mail que personne ne lit et devient un ticket GLPI avec un responsable, une priorite et du contexte. Chez NexTool, Zabbix ne fonctionne pas de maniere isolee : il se place a cote du GLPI que nous maintenons deja pour le client, et chaque trigger pertinent nait relie a un flux de reponse. Cet article montre comment nous deployons et maintenons ce duo - de l'architecture au trigger reel et a l'integration avec le module Automatisations de NexTool.
Architecture : Zabbix a cote de GLPI, sans le concurrencer
L'erreur classique est de traiter Zabbix et GLPI comme des mondes separes : Zabbix crie, quelqu'un le voit et ouvre le ticket a la main. Cela ajoute des minutes (ou des heures) entre la detection et l'action, et cela depend d'un humain qui surveille le tableau de bord. Dans notre deploiement, Zabbix Server tourne dans un conteneur a cote de la stack du client, avec Zabbix Agent 2 sur les hotes supervises. Le point d'integration est le media type webhook de Zabbix, qui declenche un POST vers le endpoint stateless du module Automatisations de NexTool - et c'est Automatisations qui cree le ticket GLPI, avec une authentification HMAC SHA-256 par flux.
Cette separation des roles compte : Zabbix decide ce qui est un signal digne d'action (le trigger) ; Automatisations decide comment cela devient du travail dans le service desk (categorie, entite, urgence, technicien). Modifier l'un sans toucher a l'autre devient trivial.
Triggers qui comptent : fenetre temporelle et recovery, pas un pic isole
En maintenance, la cause numero un du "tout le monde coupe le son de Zabbix" est le flapping : un pic CPU de 2 secondes leve et efface l'alerte des dizaines de fois par heure. La defense est double - evaluer sur une fenetre temporelle et utiliser une expression de recovery distincte (hysteresis), afin que le probleme ne se ferme que lorsqu'il s'est reellement stabilise. Un trigger de disque qui se remplit, ecrit pour predire la panne avant qu'elle n'arrive, ressemble a ceci :
# Trigger : le filesystem racine se remplira dans les 24h a venir (prediction, pas reaction)
# name: "Disque {HOST.NAME} : prediction de saturation de / sous 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 avec hysteresis (recovery different du probleme) pour eviter le flapping CPU
# Expression de probleme :
avg(/Linux by Zabbix agent/system.cpu.util,5m)>90
# Expression de recovery (n'efface que si ca baisse vraiment) :
avg(/Linux by Zabbix agent/system.cpu.util,5m)<70La fonction timeleft() est le coeur du "proactif" : a partir de la tendance, elle projette combien de temps il reste avant que le disque ne se remplisse - et alerte tant qu'il est encore temps d'agir, pas quand le service est deja tombe. L'erreur courante ici est d'utiliser last() sur une valeur d'usage de 95% et d'appeler cela proactif ; ce n'est pas le cas, c'est du reactif avec un seuil plus lache.
Modeles et macros : coherence entre hotes
Nous standardisons serveurs, reseau et applications via un modele (template) lie, avec les seuils exposes sous forme de macros ({$CPU.UTIL.CRIT}, {$VFS.FS.PUSED.MAX.CRIT}). Ainsi un hote qui vit legitimement avec un usage eleve (une base de donnees, par exemple) recoit un override de la macro sur l'hote lui-meme, sans dupliquer le trigger ni casser le modele des 200 autres hotes. Cela accelere l'onboarding des nouveaux hotes et evite la derive silencieuse qui corrompt toute supervision mature.
Integration avec GLPI : le webhook qui devient un ticket
Le media type webhook de Zabbix est un script JavaScript qui construit le payload et fait le POST. Ce que nous envoyons a Automatisations porte de quoi faire naitre le ticket avec du contexte - severite, hote, item, valeur et le {EVENT.ID}, que nous utilisons comme cle d'idempotence pour ne pas ouvrir deux tickets pour le meme evenement :
// Zabbix media type (webhook) -> Automatisations 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}', // cle d'idempotence
severite: '{EVENT.SEVERITY}', // mappee vers l'urgence GLPI
hote: '{HOST.NAME}',
declencheur:'{TRIGGER.NAME}',
valeur: '{ITEM.VALUE}',
statut: '{EVENT.VALUE}' // 1=probleme, 0=retabli
});
var resp = req.post('https://glpi.client.com/automatisations/hook/zabbix', payload);
return JSON.stringify({ tags: [{ tag: '__glpi_ticket', value: resp }] });Cote GLPI, le flux Automatisations mappe la severite Zabbix a l'urgence du ticket, choisit la bonne categorie et la bonne entite et l'assigne au groupe technique responsable. Quand l'evenement se retablit (statut : 0), le meme flux peut ajouter un suivi "resolu automatiquement" ou fermer le ticket - bouclant le cycle detection -> action -> resolution sans intervention manuelle.
Reactif vs proactif, en pratique
| Dimension | Supervision reactive | Supervision proactive |
|---|---|---|
| Declencheur | Service deja tombe (last() = 0) | La tendance predit la panne (timeleft(), forecast()) |
| Fenetre | Valeur instantanee, pic isole | Moyenne/tendance sur une fenetre (5m, 1h) |
| Faux positif | Eleve (flapping) | Faible (hysteresis/recovery) |
| Resultat dans GLPI | Ticket ouvert tard, sans contexte | Ticket avec responsable, urgence et valeur de l'evenement |
| Effet sur l'equipe | Fatigue d'alerte, tableau de bord ignore | Peu d'alertes, toutes actionnables |
Erreurs courantes que nous corrigeons en maintenance
- Sans expression de recovery : probleme et retablissement utilisent la meme condition, l'alerte clignote. Definissez toujours une hysteresis sur les metriques volatiles (CPU, latence).
- Severite sans mapping : tout arrive dans GLPI en "moyenne". Mappez
Disaster/Highvers une urgence elevee et laissezInformationsur le tableau de bord seulement, sans creer de ticket. - Sans idempotence : les reessais du webhook creent des tickets en double. Utiliser
{EVENT.ID}comme cle resout le probleme. - Alerter sans responsable : un trigger qui ne pointe pas vers un groupe/technicien est du bruit. Toute alerte actionnable a besoin d'une route d'assignation dans le flux Automatisations.
Si vous avez deja GLPI et voulez que Zabbix cesse de produire des e-mails ignores et se mette a produire des tickets avec un responsable et du contexte, ce travail de deploiement et de maintenance est ce que NexTool livre - du modele au flux d'integration. Parlez-nous du support et maintenance de votre environnement GLPI + supervision.
Ce contenu a ete produit avec l'aide de l'intelligence artificielle et revise par l'equipe Nextool Solutions.
