Introduction

Le watchdog est le mécanisme de récupération de secours de Level pour le service agent. Si le service agent s'arrête, le gestionnaire de services du système d'exploitation gère la récupération dans la plupart des cas (le Gestionnaire de contrôle des services sur Windows le relance en moins de 60 secondes via les options de récupération du service). Le watchdog s'exécute selon un calendrier et existe pour le cas rare où le gestionnaire de services n'a pas relancé le service de lui-même.

Il s'exécute silencieusement en arrière-plan et vous ne le remarquerez pas dans des conditions normales. Si le watchdog redémarre fréquemment l'agent sur un appareil donné, le gestionnaire de services et le watchdog travaillent tous deux plus que nécessaire, ce qui signifie que quelque chose dans l'environnement interfère avec Level.

Ce que fait le watchdog

Deux systèmes fonctionnent ensemble pour maintenir le service Level en marche. Le gestionnaire de services du système d'exploitation est la première ligne : lorsque le service s'arrête, il le redémarre automatiquement (généralement en moins de 60 secondes sur Windows via les options de récupération du service). Le watchdog est la deuxième ligne, s'exécutant toutes les 10 minutes pour vérifier que le gestionnaire de services a bien fait son travail.

À chaque cycle de 10 minutes, le watchdog répond à une seule question : le service agent de Level est-il en cours d'exécution, et dans le cas contraire, peut-il être redémarré ? Il utilise le gestionnaire de services pour lire l'état actuel, puis effectue l'une des actions suivantes :

Si le service est en cours d'exécution, ne rien faire.
Si le service est arrêté, le démarrer.
Si le service est en pause, le reprendre.
Si l'enregistrement du service est entièrement manquant (l'agent a été désinstallé ou corrompu), désinstaller le watchdog lui-même afin que l'appareil ne reste pas bloqué à exécuter une tâche orpheline.

Le watchdog ne communique pas avec Level, ne génère pas d'alertes et ne réinstalle pas l'agent. C'est une boucle d'auto-guérison locale, rien de plus.

ℹ️ REMARQUE : Le watchdog redémarre le service. Il ne réinstalle pas l'agent. Si le binaire a été supprimé, mis en quarantaine par un AV/EDR, ou corrompu, vous devrez effectuer une réinstallation à l'aide du programme d'installation approprié pour la plateforme. Voir Installation Windows, Installation macOS, ou Installation Linux.

Comportement sur Windows

Les détails ci-dessous sont spécifiques à Windows. Sur macOS et Linux, la récupération est gérée directement par le gestionnaire de services du système d'exploitation (voir la section suivante).

Sur Windows, le watchdog est une tâche planifiée Windows qui se déclenche toutes les 10 minutes et exécute la --check-service routine. Chaque exécution passe par trois étapes.

Étape 1 : Interroger l'état du service

Le watchdog utilise le Gestionnaire de contrôle des services (SCM) pour ouvrir le service Level et lire son état actuel (En cours d'exécution, Arrêté, En pause ou manquant). C'est la source de vérité pour savoir si le service est actif.

Étape 2 : Valider la connexion de surveillance locale

Si le SCM signale que le service est En cours d'exécution, le watchdog tente brièvement de se connecter à l'agent via le canal de surveillance locale/RPC. Cela détecte les cas où le processus du service est actif mais a cessé de répondre en interne.

Si cette connexion échoue, le watchdog enregistre une erreur et passe à la suite. Il n'arrête pas le service sur la base de cette seule vérification. La récupération est toujours pilotée par l'étape suivante.

ℹ️ REMARQUE : Cette validation de connexion est une vérification souple. Un échec RPC passager ne déclenche pas à lui seul un redémarrage, ce qui empêche le watchdog de fluctuer sur des systèmes sains qui n'ont pu répondre que brièvement.

Étape 3 : Exécuter EnsureRunning

Après la vérification de l'état, le watchdog appelle toujours la EnsureRunning routine. C'est là que se produit la récupération effective :

Durée de fonctionnement du système inférieure à 60 secondes. Ignore toute la routine pour éviter les conflits au démarrage anticipé, où le service peut ne pas avoir encore démarré par conception.
Enregistrement du service manquant. Traite cela comme un état défectueux ou désinstallé et supprime la tâche watchdog elle-même. L'appareil n'est plus surveillé par un watchdog car il n'y a plus rien à surveiller.
Service arrêté. Démarre le service.
Service en pause. Reprend le service.
En attente de l'état En cours d'exécution. Interroge en boucle courte jusqu'à ce que le service signale En cours d'exécution avant de se terminer.

La description intégrée de la tâche résume bien la situation : le watchdog existe pour aider à maintenir le service Windows de Level en cours d'exécution.

Comportement sur macOS et Linux

Level s'appuie sur le gestionnaire de services du système d'exploitation pour la récupération sur les plateformes de type Unix. L'agent n'exécute pas de vérification planifiée séparée comme il le fait sur Windows.

🖥️ NOTE DE PLATEFORME :

Windows : Implémenté en tant que tâche planifiée Windows s'exécutant toutes les 10 minutes. Séquence de vérification complète décrite ci-dessus.
macOS : Géré par le LaunchDaemon à /Library/LaunchDaemons/Level.plist. Si le service s'arrête, launchd le redémarre conformément à la configuration du daemon.
Linux : Géré par systemd. Si le service s'arrête, systemd le redémarre conformément à la configuration de l'unité de service.

Le résultat final est le même sur toutes les plateformes : un service arrêté reprend sans intervention manuelle. Le mécanisme diffère.

Veille, reprise et ce pour quoi le watchdog n'est pas fait

Le watchdog ne comporte aucune logique de veille ou de reprise après mise en veille. Il exécute la même vérification de 10 minutes que l'appareil vienne de se réveiller ou soit en fonctionnement depuis une semaine.

L'agent gère normalement la veille de lui-même sans intervention. Le processus du service Level continue de s'exécuter pendant la mise en veille, de sorte que la reprise ne nécessite généralement rien de spécifique pour la récupération. La veille semble toutefois corrélée à des problèmes réseau inhabituels (un état DNS obsolète en est un exemple courant), mais la récupération pour ceux-ci n'est pas spécifique à la veille.

L'agent dispose d'un observateur de connexion distinct s'exécutant en interne. Son rôle principal est de détecter les connexions obsolètes : lorsque certaines connexions sortantes fonctionnent et d'autres non (le cache DNS en est un exemple typique), l'observateur redémarre l'agent pour forcer un état actualisé. Il ne s'agit pas d'une fonctionnalité de récupération après veille, même si elle aide parfois avec les problèmes réseau induits par la veille en tant qu'effet secondaire.

💡 CONSEIL : Désactivez la veille sur les endpoints gérés dans la mesure du possible. C'est ce que nous faisons en interne chez Level et ce que font la plupart de nos clients les plus importants (5 000+ appareils). Cela élimine une catégorie de problèmes de connectivité intermittents qui ne valent pas la peine d'être dépannés appareil par appareil.

Quand le watchdog se déclenche

Un redémarrage occasionnel est normal et mérite rarement d'être investigué. Un crash passager, un pic de ressources, un processus interférant brièvement : l'un quelconque de ces éléments peut provoquer un redémarrage ponctuel, et l'agent reprend sans que personne ne le remarque.

Un schéma de redémarrages fréquents est différent. Le SCM devrait gérer la plupart des crashes du service en moins de 60 secondes, et le watchdog devrait rarement avoir besoin d'intervenir. Si le watchdog relance le service à plusieurs reprises sur le même appareil, quelque chose sur cet appareil empêche l'agent de fonctionner normalement.

Causes courantes :

Interférence AV/EDR. Un logiciel de sécurité qui met fin à l'agent Level ou le met en quarantaine. C'est la cause la plus fréquente et elle est généralement basée sur le comportement, ce qui explique pourquoi elle peut affecter un seul appareil dans un parc par ailleurs uniforme. Voir Fausses détections AV/EDR.
Autres outils de gestion. Une autre tâche planifiée, un GPO ou un RMM arrêtant le service Level.
Problèmes matériels. Disque défaillant, erreurs mémoire ou autres pannes matérielles provoquant le crash du service.

⚠️ AVERTISSEMENT : Nous ne recommandons pas de désactiver le watchdog. Le SCM ramène le service Level en moins de 60 secondes dans presque tous les cas. Le watchdog est le filet de sécurité pour le rare cas où le SCM ne l'a pas fait. Le laisser activé ne coûte rien.

FAQ

Puis-je désactiver le watchdog ? Vous le pouvez, mais nous ne le recommandons pas. Le SCM est le principal mécanisme de récupération du service Level et le relance en moins de 60 secondes dans presque tous les cas. Le watchdog est le filet de sécurité pour le rare cas où le SCM n'a pas récupéré le service. Le désactiver supprime ce filet de sécurité. Le laisser activé ne coûte rien.
Le watchdog a redémarré l'agent sur l'un de mes appareils. Dois-je m'inquiéter ? Un redémarrage isolé ne mérite généralement pas d'investigation. Il peut provenir d'un crash passager, d'un pic de ressources ou d'un autre processus interférant brièvement. Si vous constatez que le watchdog redémarre l'agent à plusieurs reprises sur le même appareil, c'est le signal pour approfondir l'investigation. L'interférence AV/EDR est la cause la plus fréquente. Voir Fausses détections AV/EDR.
Mon appareil ne revient pas en ligne après la veille. Le watchdog n'est-il pas censé gérer cela ? Non. Le watchdog ne comporte aucune logique de veille ou de reprise après mise en veille. La récupération après reprise est gérée par l'observateur de connexion et le client temps réel de l'agent, ainsi que par le fait que le processus du service Level continue généralement de s'exécuter pendant la veille. Si un appareil ne se reconnecte pas après le réveil, le watchdog n'est pas là où il faut chercher. Commencez par le réseau et l'état de connexion de l'agent. Voir Dépannage hors ligne.
Le watchdog réinstalle-t-il l'agent si le binaire est manquant ? Non. Il ne fait que démarrer ou reprendre un service existant. Si l'enregistrement du service est entièrement manquant, le watchdog se supprime lui-même et l'appareil doit avoir l'agent réinstallé. Consultez les articles d'installation pour votre plateforme.
Où puis-je voir si le watchdog est en bonne santé sur un appareil ? Exécutez la --check commande de diagnostic sur l'appareil. La sortie comprend une section de vérifications Level qui indique si le service agent et la tâche watchdog sont dans l'état attendu (Running / Ready). Voir Dépannage hors ligne pour le parcours de diagnostic complet.
Les techniciens ont-ils besoin de permissions dans Level pour interagir avec le watchdog ? Le watchdog s'exécute localement sur chaque appareil et n'est pas configurable depuis l'interface web de Level. Il n'y a aucune permission à accorder ou à révoquer. L'interaction directe avec lui (inspection de la tâche planifiée Windows, du LaunchDaemon macOS ou de l'unité systemd Linux) nécessite un accès administrateur local sur l'appareil.

Tâche Watchdog de Level