Watchdog des routeurs industriels : détection, reprise et essais
Dernière mise à jour : il y a 6 jours
Un routeur peut répondre au ping alors que la collecte de données est bloquée. Il peut aussi redémarrer en boucle parce qu'un serveur distant est indisponible, tout en étant lui-même en bon état. Une surveillance utile distingue ces situations avant de choisir une action de reprise.
Un watchdog attend un signal périodique indiquant que la tâche surveillée progresse. Si ce signal cesse, une action configurée se déclenche. Il peut raccourcir certaines interruptions ; il ne garantit pas un service continu et ne corrige pas toutes les causes de panne.
Ce que le temporisateur détecte réellement
Le temporisateur détecte une réinitialisation de son compteur absente ou tardive, pas la cause du défaut. Son utilité dépend de ce qui autorise ce signal. Une boucle qui continue à le réarmer alors que l'application est bloquée peut masquer le problème recherché.
Une passerelle qui lit un automate et transmet ses mesures doit, par exemple, distinguer la progression de l'acquisition, l'envoi et la mise en mémoire locale. Si le serveur est indisponible mais que l'acquisition et le stockage fonctionnent, redémarrer toute la passerelle peut perdre des données sans rétablir la livraison.
Distinguer la reprise du service, du système et du réseau
L'API watchdog de Linux explique comment un processus en espace utilisateur peut réarmer un watchdog via /dev/watchdog. Cette interface ne prouve pas que le temporisateur se trouve dans une puce séparée, dans le processeur ou dans un mécanisme logiciel. La documentation du pilote et du matériel précise son indépendance réelle et la portée de la réinitialisation.
État surveillé | Réponse possible | Vérification attendue |
|---|---|---|
L'application ne progresse plus | Redémarrer le service concerné | Les autres services continuent ; l'acquisition reprend |
Le système ne réarme plus le temporisateur matériel | Réinitialiser le système | Le temporisateur reste actif face au défaut visé ; le démarrage aboutit |
Le chemin cellulaire ou VPN échoue | Reconnecter le chemin ou utiliser une alternative configurée | L'application fonctionne à nouveau, pas seulement l'interface |
Le serveur distant est indisponible | Conserver les données, espacer les essais et alerter si possible | Le travail local continue sans boucle de redémarrage |
La supervision d'un service constitue un mécanisme distinct. Les watchdogs de service systemd utilisent par exemple des notifications WATCHDOG=1 périodiques ; la politique configurée détermine le redémarrage du service défaillant. Cet exemple de système d'exploitation ne signifie pas qu'un firmware Wavetel donné expose ces réglages.
Les contrôles réseau doivent aussi avoir une portée définie. Le ping observe une accessibilité limitée, DNS teste la résolution de noms et une requête applicative un autre chemin. Joindre un serveur public ne prouve pas que l'automate ou le serveur métier est accessible. Consultez le guide de basculement avant de lier un contrôle à un changement de route.
Définir les délais à partir de mesures
Mesurez le fonctionnement normal avec le trafic, la charge CPU et les opérations de maintenance prévus. Tenez compte du démarrage et des opérations longues légitimes, puis comparez le délai de détection à l'interruption acceptable pour l'application. Un délai de 30 secondes ou une marge fixe en pourcentage ne convient pas à tous les routeurs.
Pour la surveillance réseau, précisez la cible, le délai par essai, l'intervalle, le nombre d'échecs requis et la période de grâce au démarrage. Notez si les essais se chevauchent et si l'intervalle part du début ou de la fin d'un essai. Ces choix modifient le délai avant action.
Commencez par l'action la moins perturbatrice susceptible de traiter le défaut observé. Limitez les tentatives, imposez une pause avant l'escalade suivante et prévoyez une alerte en cas d'échec persistant. Ne redémarrez pas indéfiniment l'équipement parce qu'un service amont est en maintenance.
Valider la reprise avec l'application réelle
Notez le modèle, le firmware, le type de watchdog, la configuration et l'action attendue. Utilisez un montage contrôlé avec un moyen de récupération.
Établissez une référence avec l'automate, le tunnel, le serveur et le trafic prévus. Mesurez la plus longue opération normale et le temps de démarrage.
Introduisez un seul défaut convenu à la fois : arrêt d'un service surveillé, coupure de liaison ou indisponibilité d'un serveur de test. Un essai réseau ne prouve pas la reprise après blocage du noyau.
Mesurez du dernier échange valide au retour de données fraîches. Distinguez détection, action, démarrage, enregistrement réseau, établissement du tunnel et reprise applicative.
Répétez avec un défaut persistant. Vérifiez les limites de tentatives, les alertes et la possibilité de diagnostiquer encore l'équipement.
Un résultat exploitable inclut les reprises échouées et les interventions manuelles. Un voyant ou une connexion d'administration après redémarrage ne suffit pas. Le guide des essais de fiabilité relie ces observations à des critères d'acceptation explicites.
Préserver les données et analyser les réinitialisations répétées
Le contenu non sauvegardé de la RAM peut être perdu au redémarrage. Les données en mémoire non volatile dépendent encore de la fin des écritures, du système de fichiers et de la reprise applicative.
Testez les mesures en attente, les changements de configuration et les écritures interrompues ; ne promettez pas que toutes les données flash sont automatiquement protégées.
Recueillez, si l'équipement le permet, la cause du reset, le dernier échange réussi, la version du firmware, les observations utiles sur les ressources et les liaisons, puis le résultat de la reprise. Un défaut brutal peut empêcher la dernière écriture de journal. Des resets répétés sont un symptôme à analyser, pas une preuve d'autoréparation réussie.
Le guide de gestion à distance aide à définir les événements et les confirmations nécessaires après une reprise sans opérateur. Conservez les éléments du défaut initial avant de modifier les délais ou le firmware.
FAQ
Un watchdog matériel est-il toujours une puce séparée ?
Non. Il peut être intégré au processeur ou à un autre composant. Vérifiez ses dépendances d'horloge, d'alimentation et de reset, ainsi que les défauts détectables.
Un ping réussi prouve-t-il que l'application fonctionne ?
Non. Vérifiez une transaction applicative valide et des données fraîches. Choisissez des contrôles distinguant service local, chemin réseau et extrémité distante.
Toute panne réseau doit-elle provoquer un redémarrage ?
Non. Une panne serveur ou un problème de routage peut persister après chaque redémarrage. Adaptez l'action au défaut et limitez les escalades répétées.
Un watchdog garantit-il la disponibilité ou la sécurité fonctionnelle ?
Non. Sa contribution doit être évaluée dans le système complet et selon les hypothèses de défaillance retenues. Cette fonction seule ne prouve ni un pourcentage de disponibilité ni la conformité à une norme de sécurité fonctionnelle.
