Mode opératoire — Transformer les alertes de la supervision en tickets GLPI, ouverts et résolus automatiquement

Document autonome. Partie théorique, puis mise en œuvre telle qu’elle a été réalisée et vérifiée le 06/11/2026 sur le lab : supervision Grafana sur srv-supervision (10.0.30.15, zone ADM), gestion de parc et assistance GLPI 11 sur les serveurs web (glpi.sio.internal, derrière HAProxy srv-ha, 10.0.10.5). Tâche 11.10 du suivi (SUIVI-TP.md), étape 70 de la documentation. Prérequis : Grafana envoie déjà ses alertes par mail (MO-17) ; GLPI est en service et son API REST activée, filtrée dans HAProxy (étape 69).
Aucun jeton ici : ils sont dans Bitwarden (registre des comptes, G-17 et G-18).
Dernière mise à jour : 06/11/2026 (version finale : rattachement du ticket à la fiche de la machine)

Sommaire

§	Contenu
1	Pourquoi des tickets, et pourquoi pas un ticket par alerte
2	Le cheminement complet, de l’événement au ticket résolu
3	Le script du relais, bloc par bloc
4	Mise en place pas à pas
5	Vérifier : trois essais et un test réel
6	Exploiter, régler, dépanner
7	Pièges et checklist

1 · Pourquoi des tickets, et pourquoi pas un ticket par alerte

Le mail d’alerte	Le ticket
prévient tout de suite	garde la trace : quand, combien de temps, quelle solution
se lit, puis se perd dans la boîte	se suit, s’attribue, se rouvre, se compte (statistiques)
propre à une personne	partagé par le service (techniciens)

Un service d’assistance (le cas GSB) doit pouvoir dire « combien d’incidents ce mois-ci, combien de temps chacun ». Le ticket répond à cette question ; le mail non.

Mais un ticket par alerte noierait GLPI. Mesure faite sur l’historique des 17 règles (29/10 → 06/11, 8 jours) :

	Nombre
alertes déclenchées	62
revenues à la normale en moins de 30 min	57 (92 %)
restées actives 2 h ou plus	1

La plupart des alertes sont des redémarrages ou des pics qui se règlent seuls : elles méritent un mail, pas un ticket.

La règle retenue (décision d’Axel, 06/11)

Alertes	Ticket
Sécurité : « Intrusion détectée (Wazuh) », « Connexions refusées en rafale »	tout de suite : un événement de sécurité doit être regardé par un humain ; ces alertes retombent seules en 15 min par construction (fenêtre de la règle), elles n’atteindraient jamais un délai
Toutes les autres	seulement si l’alerte est encore active 2 h après son déclenchement : elle ne s’est pas réglée seule, il faut agir
Retour à la normale	une solution automatique est ajoutée au ticket (statut « Résolu »), avec la durée ; un technicien peut le rouvrir
Rattachement	le ticket est lié à la fiche « Ordinateur » de la machine concernée (inventaire GLPI, étape 69) : depuis la fiche, on voit l’historique de ses incidents

Principe à retenir — Un ticket = un problème qui demande une action humaine. Le mail prévient, le ticket trace ; on ne transforme pas chaque mail en ticket.

2 · Le cheminement complet, de l’événement au ticket résolu

srv-metriques          srv-supervision (10.0.30.15)                                   srv-ha        srv-web-01      Galera
─────────────          ─────────────────────────────────────────────────────          ──────        ──────────      ──────
sshd refuse      ①     rsyslog ──► base syslog ◄── ② Grafana (règle SQL, 1 fois/min)
6 connexions  ──514──►                 (Galera)            │ ③ alerte « Connexions refusées en rafale »
                                                            ├──► mail (Gmail)
                                                            └──► ④ relais (127.0.0.1:9095)
                                                                     │ ⑤ API GLPI, en HTTPS ──► HAProxy ──► GLPI (PHP) ──► ticket écrit

Étape	Qui	Ce qui se passe
① le fait	la machine (`srv-metriques`)	le service SSH écrit `Failed password` dans son journal ; rsyslog en envoie une copie à `srv-supervision` (port 514), qui la range dans la table `journaux_auth` de la base `syslog` (cluster Galera)
② la détection	Grafana	chaque minute, la règle compte par SQL les `Failed password` des 5 dernières minutes, par machine ; plus de 4 → « en attente » ; toujours vrai 1 minute après → « en alerte »
③ l’envoi	Grafana	la politique de notification (alerte critique : envoi après 10 s) l’envoie au point de contact `mail-axel`, qui a deux canaux : le mail et un webhook, c’est-à-dire l’envoi de l’alerte en JSON à une adresse web, ici `http://127.0.0.1:9095/`
④ la décision	le relais (programme Python, même machine que Grafana)	il lit l’alerte (statut, nom, machine, empreinte) et applique la règle du §1 : ticket tout de suite, plus tard, ou jamais
⑤ la création	le relais, sous le compte GLPI `api-alertes`	il appelle l’API REST de GLPI en HTTPS : ouverture de session, `POST /Ticket`, recherche de la fiche « Ordinateur » portant le nom de la machine (`GET /Computer`) et lien (`POST /Item_Ticket`), fermeture ; HAProxy laisse passer (l’API n’est ouverte qu’au bastion et à `srv-supervision`) ; GLPI écrit le ticket dans sa base
⑥ la résolution	Grafana puis le relais	quand la règle redevient fausse, Grafana renvoie la même alerte avec le statut `resolved` ; le relais retrouve le ticket par l’empreinte et lui ajoute une solution (`POST /ITILSolution`) : GLPI le passe à « Résolu »

Qui fait quoi : la machine produit un journal ; Grafana détecte et prévient ; le relais décide et crée le ticket ; GLPI garde. Grafana ne connaît pas GLPI, GLPI ne connaît pas Grafana : si le relais tombe, les mails continuent ; si GLPI tombe, la supervision continue.

Mot	Sens
webhook	envoi automatique d’un message (ici du JSON) à une adresse web quand un événement survient
API REST	l’interface qui permet à un programme de lire et d’écrire dans GLPI par des requêtes web
jeton (token)	une longue clé qui remplace un mot de passe pour un programme ; ici, deux : celui de l’application (le client d’API `bastion-lab`) et celui de l’utilisateur (`api-alertes`)
empreinte (fingerprint)	identifiant que Grafana donne à chaque alerte (règle + étiquettes) : la même panne garde la même empreinte, ce qui évite les doublons

3 · Le script du relais, bloc par bloc

Fichier : scripts/glpi/relais-alertes-glpi.py (186 lignes, Python, aucune bibliothèque à installer : seulement celles fournies avec Python). Installé sur srv-supervision dans /usr/local/bin/.

Lignes	Bloc	Ce qu’il fait, en clair
1-15	en-tête	commentaire qui résume la règle (§1), le rattachement et les fichiers utilisés
16-29	lecture des réglages	lit `/etc/glpi-relais/relais.conf` (adresse d’écoute, adresse de l’API, délai, liste des alertes immédiates, entité) et `/etc/glpi-relais/api.env` (les deux jetons) ; prépare la vérification du certificat du lab ; crée un verrou pour que deux notifications simultanées ne modifient pas l’état en même temps
32-47	`log`, `charger`, `sauver`	écrire une ligne datée dans le journal ; lire et réécrire le fichier d’état `/var/lib/glpi-relais/etat.json`, qui retient les alertes en cours (début, contenu, numéro de ticket). Écriture dans un fichier temporaire puis renommage : jamais de fichier à moitié écrit
49-56	`glpi`	une requête vers l’API de GLPI : ajoute les en-têtes (jeton d’application, puis jeton utilisateur ou jeton de session), envoie, renvoie la réponse
58-67	`avec_session`	ouvre une session (`initSession`), fait le travail demandé, ferme toujours la session (`killSession`), même en cas d’erreur
69-76	`heure`	transforme l’heure de Grafana (UTC) en heure locale lisible
78-107	`ouvrir_ticket`	construit le ticket : titre `[Supervision] <règle> — <machine>`, contenu (résumé, description, heure de déclenchement, étiquettes), entité GSB, type Incident, urgence et impact hauts si l’alerte est critique, moyens sinon ; `POST /Ticket` ; puis cherche la fiche « Ordinateur » dont le nom est celui de l’étiquette `host` (sans tenir compte des majuscules) et rattache le ticket (`POST /Item_Ticket`) ; sans fiche, le ticket est ouvert quand même et le journal le signale ; renvoie le numéro
109-116	`resoudre`	calcule la durée de l’incident, ajoute une solution au ticket (`POST /ITILSolution`) : GLPI passe le ticket à « Résolu »
118-148	`traiter` (le cœur)	pour chaque alerte reçue : si elle se déclenche et est nouvelle, la noter ; si elle est dans la liste « immédiates », ouvrir le ticket tout de suite. Si elle revient à la normale : ticket existant → `resoudre` ; pas de ticket → rien (« revenue avant le délai »). Une alerte déjà connue n’est jamais traitée deux fois
150-165	`surveiller`	tourne en arrière-plan : toutes les 5 minutes, ouvre le ticket des alertes encore actives depuis plus que le délai (120 min)
168-179	`Reception`	le petit serveur web : reçoit le `POST` de Grafana, appelle `traiter`, répond `200` (ou `500` en cas d’erreur)
182-186	démarrage	lance `surveiller` en arrière-plan, puis écoute sur `127.0.0.1:9095`

Les réponses aux questions qu’on peut te poser

Question	Réponse
Pourquoi un programme à part et pas Grafana directement ?	Grafana ne sait que prévenir ; il ne sait ni attendre 2 h ni retrouver le ticket d’une alerte pour le résoudre. Le relais porte cette logique, et Grafana comme GLPI restent intacts
Qui peut lui envoyer une fausse alerte ?	personne d’autre que la machine elle-même : il n’écoute que sur `127.0.0.1`
Que se passe-t-il s’il redémarre ?	rien n’est perdu : l’état des alertes est dans `etat.json`
Et si la même alerte revient en rappel (toutes les heures pour une alerte critique, chaque jour pour un avertissement) ?	même empreinte : le relais l’ignore, pas de doublon
Pourquoi un compte `api-alertes` et pas le compte d’administration ?	moindre privilège : profil Technicien, il ne peut que créer, suivre et résoudre des tickets ; s’il fuit, il ne donne pas les clés de GLPI
Que faire si GLPI est en panne ?	le relais note l’erreur dans son journal ; le mail est parti quand même
Comment le ticket trouve-t-il la machine ?	par le nom : l’étiquette `host` de l’alerte (ex. `srv-metriques`) est comparée aux fiches « Ordinateur » créées par l’inventaire (étape 69). Une machine non inventoriée donne un ticket sans élément lié

4 · Mise en place pas à pas

Contexte : srv-supervision (Debian 13, Grafana), en root par la console ou sudo. Objectif : le relais en service, branché sur Grafana à côté du mail.

4.1 Le compte GLPI dédié (interface de GLPI, par l’administrateur)

Administration → Utilisateurs → Ajouter : identifiant api-alertes, sans mot de passe, profil Technicien sur l’entité racine, récursif. Dans la fiche : Mot de passe et jeton d’accès → Jeton API → Regénérer, sauvegarder, copier le jeton dans Bitwarden.

4.2 Compte système et dossiers

useradd --system --no-create-home --shell /usr/sbin/nologin glpi-relais

install -d -m 750 -o root -g glpi-relais /etc/glpi-relais && install -d -m 750 -o glpi-relais -g glpi-relais /var/lib/glpi-relais

Le relais tourne sous ce compte sans connexion possible ; il ne peut écrire que dans /var/lib/glpi-relais.

4.3 Fichiers

Source (annexes)	Destination	Droits
`scripts/glpi/relais-alertes-glpi.py`	`/usr/local/bin/relais-alertes-glpi.py`	`755`
`scripts/glpi/relais.conf`	`/etc/glpi-relais/relais.conf`	`640 root:glpi-relais`
`scripts/glpi/glpi-lab.pem` (certificat public de `glpi.sio.internal`)	`/etc/glpi-relais/glpi-lab.pem`	`644`
`scripts/glpi/relais-alertes-glpi.service`	`/etc/systemd/system/relais-alertes-glpi.service`	`644`

Réglages de relais.conf : ecoute = 127.0.0.1:9095, delai_minutes = 120, immediates = Intrusion détectée (Wazuh)|Connexions refusées en rafale (noms exacts des règles), entite = 2 (GSB).

4.4 Les jetons (par l’administrateur ; rien ne s’affiche)

read -rsp "Jeton application (bastion-lab) : " A && echo && read -rsp "Jeton api-alertes : " U && echo && printf 'APP_TOKEN=%s\nUSER_TOKEN=%s\n' "$A" "$U" | sudo tee /etc/glpi-relais/api.env >/dev/null && sudo chown root:glpi-relais /etc/glpi-relais/api.env && sudo chmod 640 /etc/glpi-relais/api.env && echo "longueurs : ${#A} ${#U}"; unset A U

longueurs : 40 40. Un jeton GLPI fait 40 caractères : une autre longueur signale un collage raté.

4.5 Démarrer

systemctl daemon-reload && systemctl enable --now relais-alertes-glpi.service && systemctl is-active relais-alertes-glpi.service

journalctl -u relais-alertes-glpi.service -n 3 --no-pager

active et relais prêt sur 127.0.0.1:9095 | délai 120 min | immédiates : [...].

4.6 Brancher Grafana

Grafana → Alerting → Contact points → mail-axel → Edit → Add contact point integration : type Webhook, URL http://127.0.0.1:9095/, méthode POST, « Disable resolved message » décoché (sinon pas de résolution). Au lab, fait par l’API de Grafana (compte de service claude). Le mail reste : on ajoute un canal, on n’en retire aucun.

Validation — Contact points : mail-axel affiche deux intégrations, Email et Webhook.

5 · Vérifier : trois essais et un test réel

Les trois premiers essais envoient au relais, sur la machine, une notification fabriquée au format de Grafana (un POST JSON vers 127.0.0.1:9095) ; le quatrième passe par toute la chaîne.

Essai (06/11)	Attendu	Obtenu
alerte de sécurité déclenchée puis résolue	ticket tout de suite, puis Résolu	ticket 5 (15:17:56 → 15:18:01)
alerte ordinaire qui dure (délai mis à 1 min pour l’essai, puis remis à 120)	ticket au premier contrôle après le délai, puis Résolu	ticket 8 (15:23:38 → 15:23:40)
alerte ordinaire courte	aucun ticket	« revenue à la normale avant le délai, pas de ticket »
réel : 6 connexions SSH refusées sur `srv-metriques` (compte inexistant, depuis le bastion)	Grafana → mail + ticket, puis Résolu	tentatives 15:37:37 → ticket 11 à 15:39:13 → Résolu à 15:44:13
rattachement (version finale du relais) : alerte de sécurité sur `srv-metriques`, puis sur une machine inconnue	ticket lié à la fiche de la machine ; sans fiche, ticket ouvert quand même	ticket 14 lié à l’ordinateur `srv-metriques` (« rattaché à la fiche srv-metriques (ordinateur 26) ») ; ticket 17 : « pas de fiche ordinateur nommée machine-inconnue » ; les deux Résolus

Dans GLPI → Assistance → Tickets : les tickets [Supervision] …, entité GSB, type Incident, créés par api-alertes, priorité Haute (critique) ou Moyenne (avertissement), statut Résolu ; onglet Éléments : la machine. Dans la fiche de la machine (Parc → Ordinateurs), onglet Tickets : ses incidents. 240-alerte-vers-ticket-glpi.png, 241-ticket-rattache-machine.png

Les 1 min 36 entre les tentatives et le ticket : évaluation de la règle (chaque minute) + 1 minute de confirmation (« pending ») + 10 s de regroupement de la notification critique.

6 · Exploiter, régler, dépanner

Besoin	Où
voir ce que fait le relais	`journalctl -u relais-alertes-glpi.service -f`
voir les alertes en attente de délai	`cat /var/lib/glpi-relais/etat.json`
changer le délai ou la liste des alertes immédiates	`relais.conf`, puis `systemctl restart relais-alertes-glpi.service`
suspendre les tickets sans toucher aux mails	`systemctl stop relais-alertes-glpi.service` (Grafana signalera une erreur d’envoi webhook, les mails partent)
refaire un jeton	Bitwarden + §4.4, puis redémarrer le relais

Renommer une règle Grafana qui figure dans immediates : le relais ne la reconnaît plus et elle passe au délai de 2 h. Mettre relais.conf à jour en même temps.

7 · Pièges et checklist

Piège	Symptôme	Où
Jeton collé avec un caractère en trop	`ERROR_GLPI_LOGIN_USER_TOKEN`	§4.4 (vérifier les 40 caractères)
API non autorisée pour `srv-supervision` dans HAProxy	`403` à l’ouverture de session	étape 69 (ACL `api_glpi_autorisee`)
« Disable resolved message » coché dans Grafana	tickets jamais résolus	§4.6
Nom de règle mal recopié dans `immediates`	alerte de sécurité traitée au délai de 2 h	§6
Tester avec une vraie panne sans prévenir	mails et tickets inattendus	§5 : prévenir, ou tester en local
Machine non inventoriée, ou nommée autrement dans GLPI	ticket sans élément lié	§3 (`ouvrir_ticket`) ; installer l’agent d’inventaire (MO-18 §4.4)

 Compte GLPI api-alertes (Technicien, racine, récursif), jeton dans Bitwarden
 Compte système glpi-relais ; /etc/glpi-relais (750) ; /var/lib/glpi-relais (750)
 Programme, relais.conf, certificat du lab, service systemd en place
 api.env : deux jetons de 40 caractères, 640 root:glpi-relais
 Service actif ; « relais prêt sur 127.0.0.1:9095 » dans le journal
 Grafana : webhook ajouté au point de contact, à côté du mail ; « resolved » non désactivé
 Essais : sécurité → ticket immédiat ; alerte longue → ticket après délai ; alerte courte → rien
 Test réel de bout en bout : ticket ouvert puis Résolu
 Ticket lié à la fiche « Ordinateur » de la machine (onglet Éléments)

La règle à retenir en une phrase : Grafana prévient, le relais décide, GLPI garde la trace — et seul ce qui ne se règle pas seul (ou touche à la sécurité) devient un ticket.