Exploite les actions automatiques et diagnostique les files d'attente

L’idée reçue

« Si les utilisateurs naviguent dans GLPI, les actions automatiques finiront bien par s’exécuter. »

Le mode GLPI dépend de l’activité des utilisateurs. Pour les tâches critiques, un scheduler externe en mode CLI fournit un déclenchement plus prévisible.

01Comprends les deux modes

Mode GLPI
- déclenché occasionnellement par la navigation
- dépend du trafic utilisateur
- peu prévisible

Mode CLI
- déclenché par cron ou scheduler externe
- session dédiée
- fréquence observable
- recommandé pour l'exploitation

02Relie cron et moteur interne

Exemple Linux à adapter au chemin réel et à l’utilisateur du serveur web :

* * * * * php /var/www/glpi/front/cron.php

Ce cron fréquent ne signifie pas que chaque action s’exécute chaque minute. GLPI décide quelles actions sont dues selon leur propre configuration.

03Connais les actions critiques

mailgate
- récupère les messages des collecteurs

queuedmail
- envoie les notifications en attente

queuemailclean
- nettoie les anciennes entrées de file

contract
- traite les alertes d'échéance des contrats

watcher
- signale certaines actions bloquées ou en erreur

04Définis la santé d’une action

OK
- dernière exécution compatible avec la fréquence

LATE
- dernière réussite trop ancienne

STUCK
- statut running depuis plusieurs fréquences

DISABLED
- action désactivée intentionnellement ou par erreur

REVIEW
- mode ou plage horaire non adaptés au besoin

05Ne force pas sans diagnostic

php /var/www/glpi/front/cron.php --force mailgate

Avant de forcer :

- vérifier qu'aucune exécution n'est encore active ;
- lire les journaux de l'action ;
- vérifier dépendances, droits et connectivité ;
- comprendre les conséquences d'un nouveau batch ;
- conserver l'heure, le code retour et le nombre d'objets traités.

06Diagnostique une file

Q-005
status=pending
past_due=yes
retry_count=3
→ ESCALATE

Une entrée rejetée par une règle prévue n’est pas équivalente à une exécution en erreur. Sépare : rejet fonctionnel, retry technique, retard et blocage.

07Exécute le contrôle

bash module4-glpi-automation-reporting.sh run "$lab"
column -s, -t "$lab/output/automatic-action-health.csv"
column -s, -t "$lab/output/queue-health.csv"

Le lab détecte watcher comme bloquée et Q-005 comme queue à escalader. Il ne lance aucun cron réel.

08Crée un runbook

1. identifier l'action et son rôle
2. vérifier fréquence, mode, plage horaire et statut
3. consulter statistiques et journaux
4. vérifier le scheduler système
5. traiter la cause racine
6. réinitialiser ou forcer seulement si sûr
7. contrôler le résultat et la queue
8. documenter l'incident

Mission

Diagnostique une automatisation silencieuse

Choisis mailgate ou queuedmail, définis les signaux de santé, les commandes de contrôle, le seuil d’escalade et la preuve de retour à la normale.

✓À retenir

Une action automatique fiable a un scheduler, une fréquence, des logs, un seuil de retard et une procédure de récupération. La relancer sans diagnostic peut amplifier la panne.