Chapitre 09
Remise en route de bout en bout & méthodologie
Objectifs du chapitre
- Assembler tout le cours en une démarche de diagnostic ordonnée, du laptop jusqu'au conteneur relancé.
- Suivre un arbre de décision « le service edge ne répond plus ».
- Dérouler un cas complet de bout en bout, commande par commande.
- Repartir avec une checklist réutilisable et savoir ce qu'on écrit avant de raccrocher.
1. La démarche : de l'extérieur vers l'intérieur
Le fil rouge de tout le cours : on diagnostique en couches, de l'accès vers l'application, en ne descendant d'un cran qu'une fois le précédent validé. Sauter des étapes, c'est « redémarrer pour voir » — et détruire les indices.
- Accès — est-ce que je joins l'edge en SSH ? (chapitre 2)
- Machine — est-elle saine ? disque, charge, uptime (chapitres 1, 4)
- Services système — Docker, chrony tournent-ils ? (chapitres 3, 5)
- Service edge — le conteneur tourne-t-il et est-il healthy ? (chapitre 6)
- Application — que disent les logs applicatifs ? (chapitres 4, 6)
- En amont — l'automate, le réseau, le broker répondent-ils ? (cours réseau)
À chaque niveau, une seule question : « est-ce sain ? ». Si oui, on descend ; si non, on a trouvé la couche fautive et on s'y arrête pour agir. La panne est presque toujours au premier niveau qui répond « non » — inutile de creuser plus bas.
2. Arbre de décision : « le service edge ne répond plus »
3. Cas complet : du laptop au conteneur relancé
Scénario réel : à 09h12, la supervision signale « plus de données de la cellule 12 depuis 8 minutes ». On est sur le laptop. On déroule l'arbre.
Étape 1 — Est-ce que je joins l'edge ?
laptop:~$ ssh edge12
maint@edge-cell12:~$ # SSH OK → l'edge est vivant et joignable. On descend.Étape 2 — La machine est-elle saine ?
maint@edge-cell12:~$ uptime; df -h /
09:13:44 up 88 days, load average: 0.31, 0.28, 0.25
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 58G 20G 35G 37% /
# Charge normale, disque OK. La machine va bien. On descend.Étape 3 — Les services système ?
maint@edge-cell12:~$ systemctl --failed
0 loaded units listed. # Docker, chrony : rien en échec côté systemd. On descend.Étape 4 — Le conteneur du service ?
maint@edge-cell12:~$ docker ps
CONTAINER ID IMAGE STATUS NAMES
b1f9a2c3d4e5 registry.local/edge:1.8.2 Up 2 hours (unhealthy) edge-gateway
7a2b1c9d8e6f eclipse-mosquitto:2.0.18 Up 88 days edge-mqtt
# Le conteneur tourne MAIS il est unhealthy. Voilà le premier « non ». On s'arrête ici.Étape 5 — Que dit l'application ?
maint@edge-cell12:~$ docker logs --tail 8 edge-gateway
09:05:02Z INFO publish ok (128 tags)
09:05:33Z WARN opc-ua read timeout on opc.tcp://192.168.0.1:4840
09:06:04Z ERROR opc-ua session lost, reconnecting…
09:06:35Z ERROR reconnect failed: connection refused
# L'app n'a pas planté : elle n'arrive plus à joindre le CPU (OPC-UA). Le problème est EN AMONT.Étape 6 — Confirmer que c'est bien l'amont
maint@edge-cell12:~$ ping -c2 192.168.0.1
2 packets transmitted, 0 received, 100% packet loss
maint@edge-cell12:~$ chronyc tracking | grep "Leap\|Stratum"
Stratum : 3
Leap status : Normal # l'heure est bonne, ce n'est pas le NTPDiagnostic : l'edge est sain, son service tourne ; c'est le CPU S7-1500 (192.168.0.1) qui ne répond plus — injoignable en ping. La panne n'est pas sur l'edge : elle est en amont (automate en STOP, câble, port switch). Redémarrer l'edge ou le conteneur n'aurait rien changé — et aurait fait perdre du temps. On bascule sur le diagnostic réseau/automate (cours réseau OT) et on prévient l'automaticien.
La leçon de ce cas : le symptôme « l'edge ne remonte plus rien » ne veut pas dire « l'edge est en panne ». Neuf fois sur dix où l'on est tenté de redémarrer l'edge, la démarche en couches montre que l'edge va très bien et que la cause est ailleurs. Le diagnostic ordonné évite le redémarrage inutile et désigne le bon interlocuteur.
Variante — quand c'est bien l'edge
Si à l'étape 4 le conteneur avait été en Restarting ou Exited, on aurait lu
la dernière erreur (chapitre 6), traité la cause (port occupé, config manquante, OOM…), puis :
maint@edge-cell12:~$ docker logs --tail 20 edge-gateway # cause
# … correction ciblée …
maint@edge-cell12:~$ docker compose -f /opt/edge/compose.yml up -d
maint@edge-cell12:~$ docker logs -f edge-gateway # confirmer la remontée4. Checklist réutilisable
Diagnostic edge — les 6 niveaux (à garder sous la main)
| # | Question | Commande |
|---|---|---|
| 1 | Je joins l'edge ? | ssh edge12 |
| 2 | Machine saine ? | uptime; df -h / |
| 3 | Services système OK ? | systemctl --failed |
| 4 | Conteneur Up & healthy ? | docker ps (puis -a si absent) |
| 5 | Que dit l'app ? | docker logs --tail 30 edge-gateway |
| 6 | L'amont répond ? | ping 192.168.0.1 ; chronyc tracking |
Corréler dans le temps si besoin : journalctl --since "09:00" --until "09:15" tous
services confondus (chapitre 4).
Avant tout redémarrage, trois questions : (1) ai-je lu la cause, ou
je redémarre à l'aveugle ? (2) le redémarrage va-t-il détruire des indices que je n'ai pas encore
recueillis ? (3) si la machine ne remonte pas, ai-je un accès physique de secours ? Un
reboot d'edge en production est un dernier recours, jamais un premier réflexe.
5. Ce qu'on écrit avant de raccrocher
Un diagnostic non consigné est à moitié perdu : le prochain qui tombe sur la même panne repart de zéro. Avant de refermer la session, on note — dans le cahier de maintenance, un ticket, un runbook :
- Symptôme & heure : « 09h12, plus de données cellule 12 ».
- Cause identifiée : « CPU 192.168.0.1 injoignable (ping 100 % perte) ; edge et service sains ».
- Action & résultat : « escaladé à l'automaticien ; aucune action sur l'edge ».
- À améliorer : « ajouter une alerte healthcheck → notification ».
Le meilleur runbook est écrit à froid, après l'incident, quand on a compris. Il transforme un diagnostic d'une heure en une procédure de cinq minutes pour la fois suivante. La checklist du §4 est le squelette ; chaque incident réel y ajoute une branche.
6. Là où ce cours rejoint les autres
L'étape 6 du cas ci-dessus t'a fait sortir de l'edge : ping vers l'automate, état du réseau OT. C'est le territoire du cours Diagnostic réseau OT/IT, qui prend le relais exactement là où celui-ci s'arrête — la capture Profinet, le DCP, l'anneau MRP, l'OPC-UA sur le fil. Les deux cours forment une chaîne : de l'edge (cette formation) au câble (la formation réseau), tu as de quoi diagnostiquer une cellule de bout en bout, depuis ton laptop.
Récapitulatif
- On diagnostique en couches, de l'extérieur vers l'intérieur : accès → machine → services système → conteneur → application → amont. On s'arrête au premier « non ».
- L'arbre de décision « plus de données » : SSH ? disque ? Docker Up ? healthy ? — chaque branche mène à une action ciblée ou au niveau suivant.
- Cas type : le plus souvent, l'edge est sain et la cause est en amont (automate, réseau, NTP) ; le diagnostic ordonné évite le redémarrage inutile.
- Checklist en 6 niveaux à garder sous la main ; lire avant de redémarrer, toujours.
- Consigner symptôme / cause / action / amélioration : un runbook à froid vaut de l'or à la prochaine panne.
- Ce cours (l'edge) et le cours réseau (le fil) se relaient pour couvrir la cellule de bout en bout.
Exercices
Exercice 1 — Où s'arrêter ?
Tu déroules l'arbre : SSH OK, disque OK, systemctl --failed vide,
docker ps montre edge-gateway en Up (healthy). La supervision ne
reçoit toujours rien. Quelle est la couche fautive, et que fais-tu ?
Voir la solution
Tous les niveaux sur l'edge répondent « oui », y compris le healthcheck : le
service edge fonctionne et croit remonter les données. La couche fautive est donc en
aval/amont de l'edge — soit la liaison vers l'IT (broker MQTT, historian, pare-feu) ne passe
plus, soit la supervision elle-même. On teste la cible de la remontée : joignabilité du broker
(docker logs edge-gateway confirme-t-il des « publish ok » ?), du historian,
et on regarde côté supervision. On ne touche pas à l'edge : il fait son travail.
Exercice 2 — La tentation du reboot
Sous pression, on te demande de rebooter l'edge « pour gagner du temps ». Tu n'as pas encore regardé les logs. Donne l'argument en une phrase, et les deux commandes que tu lances à la place.
Voir la solution
Argument : « Un reboot efface les indices et ne corrige rien si la cause est en amont ; 30 secondes de lecture nous diront si c'est même l'edge le problème. »
$ docker ps # conteneur Up/healthy ?
$ docker logs --tail 30 edge-gateway # que dit l'app ?Ces deux commandes tranchent en général immédiatement entre « panne sur l'edge » (on traite et on relance le conteneur, pas la machine) et « panne en amont » (le reboot n'y aurait rien changé).
Exercice 3 — Ton runbook
Rédige, en 4 lignes, l'entrée de runbook pour l'incident du §3 (perte de données à 09h12, CPU injoignable). Quelles rubriques ?
Voir la solution
Quatre rubriques, factuelles :
Symptôme : 2026-07-04 09h12, arrêt remontée cellule 12 (supervision).
Cause : CPU S7-1500 192.168.0.1 injoignable (ping 100% perte).
Edge, service, NTP sains — diagnostic en 6 niveaux, arrêt à l'étape 6.
Action : aucune sur l'edge ; escaladé automaticien (CPU en STOP suite défaut).
Suivi : ajouter alerte sur healthcheck edge-gateway → notification maintenance.L'essentiel : consigner que l'edge était sain (pour que le prochain ne perde pas de temps à le suspecter) et l'action d'amélioration (transformer la détection manuelle en alerte). C'est ce qui fait progresser l'installation d'un incident à l'autre.