La surveillance sans opérateur répond à des questions oui-non répétées à cadence fixe : le processus Gateway est-il supervisé, les sondes réussissent-elles dans la SLA, les signatures de logs ont-elles changé depuis le dernier échantillon vert. L'échelle de diagnostic répond pourquoi quelque chose a cassé et autorise des sauts intuitifs entre couches. Mélanger ces missions donne soit une automation fragile soit du bruit taille échelle dans syslog. Sur Gateway remote—Gateway sur silicium dédié, portables en gateway.mode remote—une boucle locale côté serveur peut rester verte alors que les WebSocket externes échouent parce que terminateurs TLS, tunnels SSH ou chemins Tailscale dérivent ; les jobs sans opérateur doivent encoder quelle perspective ils représentent et éventuellement coupler un job client léger utilisant la même URL que les ingénieurs le jour.

Traitez la liste suivante comme des barrières de publication pour tout nouveau script de santé entrant en production.

La planification de capacité pour l'automation doit inclure budgets IO et inodes : des logs verbeux sur hôtes chargés peuvent saturer le disque plus vite que les humains ne le remarquent parce que la fréquence d'échantillonnage multipliée par le volume stdout croît linéairement avec la taille d'équipe même si les sessions Gateway restent plates.

La sécurité demandera qui peut lire les logs de santé ; restreignez les permissions au compte de service façon CI et faites tourner les fichiers avec la même discipline que les logs applicatifs contenant des métadonnées de canaux, en documentant finalités et durées de conservation lorsque des données personnelles transitent.

Le routage dalertes mérite une propriété explicite : quelle équipe acquitte les régressions de sondes versus les escalades échelle, et configurez la politique de paging pour que le batôlement peu grave parte vers le chat plutôt que la voix sauf si des échecs consécutifs dépassent le seuil documenté deux fois en une heure.

Quand plusieurs environnements existent—staging contre production—ne réutilisez jamais le même nom de fichier de log sans préfixes hôte ; les logs fusionnés pendant une enquête gaspillent des heures à séparer les flux.

Si les installs ne sont pas complètes, terminez le dépannage d'installation avant d'étendre la couverture cron.

Les runbooks doivent aussi spécifier le rollback de l'automation elle-même : si un mauvais déploiement double la fréquence des sondes ou introduit des boucles de redémarrage récursives, la garde doit disposer d'un fichier drapeau unique ou d'un mode maintenance qui suspend les scripts sans toucher l'état Gateway.

Corrélez enfin les échecs de sondes avec les incidents fournisseur LLM amont lorsque les canaux proxifient le trafic modèle—sinon les ingénieurs traquent les binaires Gateway pendant des incidents vendor.

Trois couches traitent des risques différents. L'échelle poursuit la cause racine pendant les incidents. Les sondes détectent vite une régression avec peu de contexte. Les moniteurs synthétiques valident les chemins observables utilisateur hors frontière VM. Documentez quelle couche possède quelle route dalerte pour garder les runbooks de garde minces.

La finance questionne parfois pourquoi des moniteurs synthétiques persistent quand des scripts existent ; la réponse est la perspective : les sondes internes ne voient pas une mauvaise configuration TLS au bord que votre téléphone utilise. Pourtant les sondes internes attrapent des problèmes minutes plus tôt et moins cher—combinez les deux délibérément.

La maturité opérationnelle signifie aussi étiqueter chaque sonde avec des instantanés type nomenclature logicielle : capturez les hash openclaw --version chaque semaine pour que les alertes de dérive corrèlent avec les upgrades de paquets plutôt quavec un mardi rouge mystérieux.

Les tableaux de bord gagnent à coupler latence de sonde et steal time CPU ou métriques hyperviseur—même sur hôtes loués bare-metal, les voisins bruyants sont rares mais les litiges de facturation surgissent sans graphes.

Formez le support de premier niveau à interpréter les codes de sortie : publiez une antisèche reliant sous-types de code 2 aux points d'entrée probables de l'échelle.

Placez les scripts sous des chemins non synchronisés utilisateur comme /usr/local/libexec et exécutez via launchd avec EnvironmentVariables explicites. Les utilisateurs cron doivent exporter PATH et OPENCLAW_STATE_DIR inline—jamais compter sur les shells de login. Convention des codes : zéro sain, un auto-remédié, deux nécessite humain. Enveloppez chaque appel CLI avec timeout et append stderr vers des fichiers tournants.

#!/bin/bash
set -euo pipefail
LOG=/var/log/openclaw-health.log
export PATH="/usr/local/bin:/opt/homebrew/bin:$PATH"
timeout 60s openclaw gateway status >>"$LOG" 2>&1 || exit 2
timeout 60s openclaw channels status --probe >>"$LOG" 2>&1 || exit 2
exit 0

Les déploiements remote devraient ajouter une seconde plist sur un hôte client dédié effectuant des contrôles symétriques pour refléter la connectivité visible utilisateur, en écho au article upgrade tunnel.

Envisagez des résumés JSON légers en fin de cycle de sonde—des fragments analysables par machine permettent aux règles SIEM aval de déclencher des automatisations précises sans regex sur de la prose.

Pendant les journées de répétition dincident, faites échouer volontairement des sondes en staging pour vérifier la déduplication des alertes et sassurer que la documentation cite les derniers drapeaux CLI plutôt que des synonymes dépréciés.

Avec les gestionnaires de secrets, assurez-vous que les jetons courts se renouvellent sans invite graphique ; les flux sans opérateur ne peuvent pas attendre un clic Autoriser.

Capturez linode disque en plus des pourcentages despace libre parce que logs de sondes plus archives retenues peuvent épuiser les métadonnées avant les octets.

Les échelles manuelles ne montent pas à l'échantillonnage cinq minutes ; l'automation aveugle crée fatigue pager. Héberger Gateway sur Apple Silicon dédié sous contrat avec régions explicites, paliers de mémoire unifiée configurables et fenêtres de location du pic journalier au pool stable rend les plans de contrôle Agent exploitables. Les équipes couvrant Singapour, Tokyo, Séoul, Hong Kong, US Est et Ouest qui ont besoin de sondes résilientes plus marge de montée en charge trouvent typiquement que les locations cloud Mac mini KVMNODE offrent le meilleur alignement opérationnel : Apple Silicon bare-metal, géographie transparente et flux de procurement alignés avec les contrats d'automation.

Les revues trimestrielles doivent tailler les sondes obsolètes et aligner les planifications sur les changements dheure été où siègent les opérateurs, évitant un double tir accidentel.

Documentez les budgets de temps dexécution attendus des sondes dans les dossiers achat pour que la finance comprenne pourquoi certains SKU incluent des paliers de mémoire unifiée plus élevés liés aux objectifs de concurrence Agent plutôt quaux seuls tests GUI interactifs.

Ajoutez des rappels calendrier pour renouveler le matériel TLS utilisé par les clients automatisés afin que les sondes ne dépassent jamais silencieusement la validité des certificats.

Archivez trimestriellement des sorties de sondes redactées pour les auditeurs qui demandent une preuve de contrôle continu.

Gestion du changement pour les ordonnanceurs eux-mêmes est souvent sous-documentée : si les ops décalent des timings plist sans pull request, le wiki diverge de la réalité et les équipes de garde suivent des schémas périmés. Gardez planifications et codes de sortie dans le même dépôt que linfrastructure-as-code avec barrières de fusion et résumés de diff annotés.

Intégration ticket : créez automatiquement des tickets seulement après deux exit 2 consécutifs avec extrait de log joint ; les premiers incidents isolés restent dans le chat. Étiquetez la perspective serveur versus client pour ne pas mélanger exécutions remote et problèmes bare-metal.