NexTool Solutions

Une alerte qui n'arrive que dans une boîte mail est un incident sans responsable. L'intégration entre Zabbix et GLPI existe pour transformer chaque problème détecté en un ticket traçable - avec un numéro, un affecté, une catégorie, une priorité et un SLA - et pour le clôturer tout seul quand Zabbix confirme la reprise. L'astuce n'est pas de "créer le ticket" : c'est de ne pas en créer quarante.

Ce que l'intégration doit livrer

Un pont Zabbix vers GLPI qui tient en production a besoin de quatre garanties, pas seulement de "poster un ticket" :

• Idempotence : un problème ouvre un ticket, pas un par étape d'escalade.
• Corrélation problème/reprise : l'événement de recovery doit retrouver et clôturer exactement le ticket qu'il a ouvert.
• Mappage de sévérité : la sévérité Zabbix devient une priorité GLPI de façon cohérente, pas à la discrétion de chaque analyste.
• Contexte suffisant : hôte, IP, trigger, horodatage et message dans le corps, pour que l'analyste agisse sans ouvrir Zabbix.

Architecture : où le webhook devient un ticket

Zabbix se déclenche sur une Action ; l'Action exécute une opération de média de type Webhook ; le Webhook est un script JavaScript natif de Zabbix qui POST vers un endpoint côté GLPI. Côté GLPI nous utilisons le receiver du module Automatisations, qui valide la signature HMAC, applique la carte des champs et crée (ou clôture) le ticket. Nous évitons d'appeler l'API REST de GLPI directement depuis Zabbix car chaque appel exigerait le couple app-token/user-token et un couple initSession/killSession - sous une tempête d'alertes cela martèle l'API et épuise les sessions.

Artefact : le Media Type webhook de Zabbix

Les paramètres mappent des macros d'événement ; le script construit le payload et gère le code HTTP. Problème et reprise utilisent le même Media Type - le champ event_value les distingue (1 = problème, 0 = reprise) :

// Zabbix -> Media type -> Webhook -> Parametres
// endpoint     = https://glpi.client.com/plugins/nextool/automations/webhook/zabbix
// event_id     = {EVENT.ID}        // stable sur le couple probleme/recovery
// event_value  = {EVENT.VALUE}     // 1 = probleme, 0 = reprise
// 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 secrete, jamais dans le corps de l'alerte

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] echec HTTP ' + code + ': ' + resp);
    throw 'Envoi vers GLPI echoue: HTTP ' + code;
}
return resp;

Carte sévérité Zabbix vers priorité GLPI

Zabbix a six sévérités ; GLPI, cinq priorités. Nous figeons la carte dans le receiver pour ne pas la laisser à la discrétion de chaque analyste :

Déduplication et clôture automatique

C'est ce qui sépare une intégration jouet d'une intégration qui survit en production. À l'ouverture du ticket, le receiver enregistre le tickets_id de GLPI comme tag d'événement dans Zabbix (ou dans une table de corrélation indexée par event_id). Quand Zabbix envoie le recovery avec le même event_id, le receiver retrouve ce ticket et ajoute un suivi de reprise - ou le clôture, selon la politique du client. Sans cette clé, le recovery ne sait pas quel ticket clôturer et vous accumulez des tickets ouverts pour des problèmes déjà résolus.

Erreurs fréquentes que nous corrigeons en support

Au quotidien en support, l'incident le plus fréquent n'est pas l'alerte qui ne devient jamais un ticket - c'est l'alerte qui en devient quarante. Une interface en flapping à 3 h du matin a ouvert des dizaines de tickets identiques parce que l'Action se déclenchait à chaque étape d'escalade et que le receiver ne dédupliquait pas. La correction a deux côtés : sur Zabbix, dépendance de trigger, hystérésis dans l'expression de recovery et opération de média uniquement à la première étape ; sur GLPI, idempotence par event_id. Deux autres erreurs récurrentes : envoyer la catégorie du ticket en texte libre (GLPI attend un itilcategories_id numérique - un nouveau texte ne correspond pas et le ticket arrive sans catégorie) et mettre le secret HMAC dans le corps de l'alerte au lieu d'une macro protégée comme {$NEXTOOL_HMAC}.

Méthodes d'intégration comparées

Si votre exploitation utilise déjà Zabbix mais que les alertes meurent dans une boîte mail que personne ne lit, NexTool déploie ce pont avec le module Automatisations et garde les règles réglées en support - triggers, carte de sévérité et politique de clôture. Découvrez le module Automatisations.

Ce contenu a été produit avec l'aide de l'intelligence artificielle et revu par l'équipe Nextool Solutions.