Les vérifications de santé d’OpenClaw

La page de santé de la documentation est un court guide pour vérifier la santé de la passerelle et des canaux sans deviner : les vérifications en CLI, les points d’accès de sonde HTTP, la commande de santé dédiée, et la surveillance de disponibilité. Voici les vérifications rapides, les diagnostics plus profonds, le moniteur de santé et l’échelle de redémarrages qu’il attend, le domaine de panne de l’admission que la santé du transport ne couvre pas, les trois sondes et celle qu’un orchestrateur devrait utiliser, la règle de surveillance qui sauve votre magasin de sessions, et les avertissements de file cachés dans un instantané qui dit ok.

Vérifications rapides

• Status donne un résumé local, joignabilité et mode, une indication de mise à jour, l’âge de l’authentification des canaux liés, les sessions et l’activité récente ; l’option all est le diagnostic complet en lecture seule, l’option deep demande à la passerelle en marche une sonde en direct avec des sondes de canaux par compte, et l’option usage montre les instantanés d’usage et de quota des fournisseurs.
• Health demande à la passerelle en marche son instantané par le WebSocket, sans jamais ouvrir de sockets de canaux depuis la CLI ; verbose force une sonde en direct et affiche les détails de connexion, et JSON donne un instantané lisible par machine. Une commande status seule dans n’importe quel chat renvoie une réponse d’état sans invoquer l’agent.
• Les lignes de session ne sont pas la vie du socket : un fournisseur peut se reconnecter et paraître sain avant qu’une nouvelle ligne de session n’existe, donc la connectivité en direct vient des commandes d’état de canal et de santé, pas de la liste des sessions. Les comptes par agent ne couvrent que cet agent, et le résumé de session de premier niveau est celui de l’agent par défaut, pas un total de flotte.
• Diagnostics approfondis : les dates des fichiers d’identifiants sur le disque, le magasin de sessions par agent, le flux de reliaison pour les codes d’état 409 à 515 ou un marqueur de déconnexion, des diagnostics actifs par défaut avec des événements de mémoire, de vivacité et de charges surdimensionnées qui n’enregistrent jamais de texte de message ni de secrets, un enregistreur de stabilité borné dont les paquets persistent après des sorties fatales, et un export de diagnostics en zip pour les rapports de bogues avec le texte des discussions, les corps, les identifiants et les secrets expurgés.

Les services externes de surveillance de disponibilité devraient utiliser le point d’accès dédié /health, pas /v1/chat/completions.

Le moniteur de santé et l’admission

Les redémarrages du moniteur de santé peuvent être désactivés par canal ou par compte sur les canaux qui exposent le réglage, Discord, Google Chat, iMessage, IRC, Teams, Signal, Slack, Telegram et WhatsApp ; un canal qui plante est d’abord récupéré par son propre recul de redémarrage automatique, dix tentatives journalisées une à une, et le moniteur reste à l’écart jusqu’à ce que cette échelle abandonne, puis prend le relais comme dernier responsable du redémarrage. La connectivité du canal et l’admission des entrants sont des domaines de panne distincts : un canal peut tenir un transport sain et envoyer des réponses normalement pendant que sa file d’admission durable est indisponible, si bien qu’aucun message entrant n’est admis. Un tel compte est malsain quel que soit l’état du transport, la disponibilité le rapporte en échec, l’état du canal nomme la condition, et la récupération est automatique par le chemin de redémarrage ordinaire, journalisé avec une raison d’admission indisponible ; des redémarrages qui se répètent veulent dire que la cause n’est pas passagère, par exemple une extension qui a refusé la capacité de file. Les canaux qui ne rapportent jamais d’état d’admission ne sont pas concernés, parce que l’absence veut dire aucun signal, jamais cassé, et il n’y a pas d’heuristique d’inactivité du trafic, donc un canal calme n’est jamais marqué malsain pour n’avoir rien reçu.

Les trois sondes

• Health, à deux chemins, veut dire que le serveur HTTP est vivant : utilisez-la pour la vie du processus et les décisions de redémarrage. Startup, à deux chemins, veut dire que le travail de démarrage est terminé et que la passerelle ne se vide pas, sans consulter la santé des canaux : utilisez-la pour le démarrage par un orchestrateur et l’admission du trafic sur Kubernetes, Fly, Render et semblables, puisqu’elle renvoie 503 en démarrage ou en vidange et 200 une fois démarrée.
• Ready, à deux chemins, ajoute des vérifications de disponibilité approfondies sur les comptes de canaux configurés : utilisez-la pour la surveillance par les opérateurs qui doit faire remonter les pannes dures de canaux, puisqu’un compte Telegram cassé peut la faire renvoyer 503 sans retirer du service une interface de contrôle saine par la sonde de démarrage. Les réponses distantes non authentifiées ne contiennent que l’indicateur ok et l’état ; les appelants locaux ou authentifiés reçoivent aussi la version, la durée de fonctionnement et une raison d’attente, et les détails de disponibilité suivent la même barrière parce qu’ils peuvent nommer les sous-systèmes en échec.
• La disponibilité détaillée peut inclure un instantané de la boucle d’événements : un ratio de cœurs de processeur mesuré sur tout le processus en équivalents de cœurs, si bien que des valeurs au-dessus de un veulent dire du travail parallèle, plus le délai et l’utilisation du fil principal ; la superposition d’activité de l’interface de contrôle lit le même échantillonneur et montre un tiret jusqu’à la fin de la première fenêtre.

Le docteur d’OpenClaw est le côté réparation des mêmes vérifications, et Les journaux d’OpenClaw le flux que les vérifications rapides vous disent de filtrer.

Moniteurs de disponibilité et avertissements de file

La règle de surveillance a une raison : une requête au point d’accès de complétion de chat sans en-tête de session ni champ d’utilisateur crée une nouvelle session aléatoire avec un instantané de compétences, un assemblage de contexte et des appels de modèle, si bien qu’un moniteur qui interroge toutes les quinze minutes crée environ quatre-vingt-seize sessions par jour de quatre à vingt-deux kilooctets chacune, gonflant le magasin et finissant par déborder le contexte, tandis que le point d’accès de santé répond instantanément sans session ni appel de modèle. La commande de santé renvoie un instantané en cache que la passerelle rafraîchit en arrière-plan à une cadence d’une minute, les sondes en direct utilisent une concurrence bornée par compte et un délai possédé par la passerelle pour qu’un compte lent renvoie un délai structuré, et la commande sort avec un code non nul quand la passerelle est injoignable. Un ok de premier niveau veut dire que l’instantané a été produit, pas que chaque file de livraison est vide : le champ de pression d’admission liste les voies entrantes durables où une ligne active a atteint huit tentatives avec une erreur enregistrée ou où une réclamation n’a pas été rafraîchie depuis trente minutes, groupées par compte de canal avec les comptes en attente, réclamés et bloqués et jamais de charge ni d’identifiant. OpenClaw ne répond pas est le parcours par symptôme des mêmes signaux, et OpenClaw sur Kubernetes le déploiement où la sonde de démarrage est la barrière de disponibilité.

Sur Diali

Sur Diali, les sondes sont à nous de les surveiller : les points d’accès de démarrage et de disponibilité de l’instance alimentent notre surveillance, et le tableau de bord montre l’assistant en marche, en mise à jour ou arrêté à partir des mêmes signaux. OpenClaw hébergé sur Diali est l’assistant.

• Health pour la vie, startup pour l’admission, ready pour les opérateurs.
• Transport sain n’est pas admission saine.
• Surveillez le point d’accès de santé, jamais celui du chat.