Supervision¶

Savoir en un coup d'œil si le domaine fonctionne, et être prévenu avant l'utilisateur.

Les trois indicateurs de vie d'un agent¶

Indicateur	Mécanisme	Où le voir
Service actif	`systemd`	`systemctl status` sur la machine
Heartbeat	Publication MQTT périodique	Console, page Agents
Testament	Last will MQTT `{"status": "dead"}`	Console, l'agent passe hors service

Le testament est publié par le broker lui-même lorsque la connexion de l'agent tombe. Un agent qui n'est plus visible dans la Console alors que le service tourne a donc perdu sa liaison MQTT vers l'API, pas forcément son fonctionnement local.

Depuis la Console¶

La page Agents liste tous les agents du domaine avec leur état, leur version et la date de leur dernier heartbeat.

Le tableau de bord donne une vue synthétique temps réel : nombre d'agents et de threads actifs, tours par seconde du moteur D.L.S, temps d'attente, consommation mémoire, erreurs de compilation.

Les deux chiffres à surveiller

Tours par seconde : s'il s'effondre sous la consigne (tps, 50 par défaut), le moteur D.L.S n'arrive plus à suivre. Cherchez un module trop coûteux ou une machine sous-dimensionnée.
Max RSS : une croissance continue signale une fuite mémoire ; remontez-la au projet.

Depuis la machine¶

# Vue d'ensemble
systemctl list-units 'abls-agent-*' --all

# Services en échec
systemctl list-units 'abls-agent-*' --state=failed

# Redémarrages récents
sudo journalctl -u 'abls-agent-*' --since '1 hour ago' | grep -i 'starting\|stopping'

Superviser depuis un outil externe¶

Sonde simple : l'état systemd¶

systemctl is-active abls-agent-modbus@MODBUS_CHAUFFERIE.service

Retourne active ou failed, exploitable par n'importe quelle sonde Nagios/Icinga/Zabbix.

Sonde de bout en bout : le bus MQTT¶

Observer le heartbeat est plus significatif que l'état du processus, car il valide toute la chaîne (processus, réseau, broker, API) :

mosquitto_sub -h <broker-api> -u '<domain_uuid>-agent' -P '<mot-de-passe>' \
              -t '<domain_uuid>/AGENT/+/STATUS' -v

Sonde du socle auto-hébergé¶

curl -sS -o /dev/null -w '%{http_code}' https://votre-api.example.com/status

Être notifié¶

Le système sait se superviser lui-même : les bits système exposent en D.L.S l'état de la connexion MQTT, la mémoire consommée, les erreurs de compilation. Un module D.L.S peut donc déclencher un message et une notification SMS.

C'est le moyen le plus direct d'être prévenu : demandez au technicien de mettre en place un module de supervision sur le modèle de l'exemple SYS.

Ne vous reposez pas uniquement sur l'auto-supervision

Si l'agent qui envoie les SMS est lui-même en panne, personne ne sera prévenu. Doublez par une sonde externe indépendante du domaine.

Le watchdog matériel¶

Pour les agents pilotant un automate, un watchdog peut être armé côté équipement : si l'agent cesse de le rafraîchir, l'automate bascule de lui-même en position de repli. Ce réglage relève du technicien, mais l'administrateur doit savoir qu'il existe : un automate qui « retombe tout seul » peut être un watchdog qui a fait son travail.

Liste de contrôle hebdomadaire¶

[ ] Aucun service abls-agent-* en état failed
[ ] Tous les agents visibles et à jour dans la Console
[ ] Tours par seconde conformes à la consigne
[ ] Aucune erreur de compilation D.L.S signalée
[ ] Espace disque suffisant (journaux et base d'archives)
[ ] Sauvegarde de la veille présente et de taille cohérente