2026 Sondes santé et readiness OpenClaw sur Mac cloud de production loué

Faire tourner OpenClaw 24/7 sur un Mac mini M4 loué à Hong Kong, Tokyo, Séoul, Singapour ou aux États-Unis fait de la passerelle sur 127.0.0.1:18789 une pièce d’infrastructure de production. Les équipes Kubernetes parlent déjà de liveness vs readiness ; les ateliers macOS + launchd ont besoin de la même discipline sans kubelet. Ce guide 2026 définit quels signaux grapher, une table des types de sondes, un runbook en six étapes et des seuils d’alerte qui évitent à la fois l’échec silencieux et la fatigue de pager. Croisez-le avec dépannage passerelle, journalisation structurée, ingress nginx pour webhooks et accès mesh Tailscale lorsque les pannes couvrent réseau et processus.

Pourquoi « processus en cours » n’est pas un health check

launchd peut retourner un code 0 alors que la passerelle est bloquée : contexte TLS obsolète, DNS du fournisseur de modèles instable ou écritures partielles sous ~/.openclaw. De bonnes sondes empruntent les mêmes chemins que le trafic client—handlers HTTP, middleware d’auth, pings modèle optionnels—sans marteler les API payantes.

• Liveness répond « faut-il redémarrer la passerelle ? » — peu coûteux, toutes les 60 secondes.
• Readiness répond « le load balancer doit-il envoyer du trafic ? » — plus strict, peut inclure des dépendances.
• Canary envoie un message utilisateur synthétique toutes les 15 minutes ; budgétisez explicitement les tokens.

Signaux à grapher avant la semaine d’astreinte

Tableaux de bord minimum pour les clients MacXCode en production :

• Débit + p95 depuis nginx $request_time lorsqu’un reverse proxy précède la passerelle.
• Taux d’erreur — compter les 5xx sur le total ; alerter si > 2 % pendant 5 minutes hors fenêtres de maintenance connues.
• CPU > 85 % pendant 10 minutes — souvent avant throttling thermique sur petites instances ; M4 limite rarement la chaleur mais les embeddings en rafale piquent.
• Espace disque < 12 Go sur le volume APFS racine — la rotation des logs sous ~/.openclaw/logs coince quand le FS est plein.

Types de sondes : ce que chacune prouve

Sonde	Prouve	Coût / risque
TCP vers 127.0.0.1:18789	Boucle accept vivante	Signal faible ; manque les échecs d’auth
HTTP GET /health (chemin selon build)	Pile HTTP + chargement config	Liveness de base recommandée
Chat synthétique authentifié	Routage modèle + identifiants	Consomme des tokens ; canary basse fréquence
Inœuds disque + espace libre	Santé de la rotation des logs	Garde-fou hôte bon marché

Runbook en six étapes : de zéro à prêt PagerDuty

1. Baseline — capturer openclaw gateway status après boot propre ; stocker dans git.
2. Script de sonde — curl avec --fail et connect-timeout 3 s ; code de sortie non nul si échec.
3. Plist launchd — StartInterval 60 ; ThrottleInterval pour éviter les tempêtes ; logs unifiés.
4. IDs de corrélation — horodatage ISO8601 par check pour corréler avec nginx.
5. Câblage alertes — trois échecs consécutifs = page ; un seul = Slack uniquement.
6. Game day — drill trimestriel : tuer la passerelle volontairement, mesurer MTTR vs SLO 15 minutes.

curl -fsS --max-time 3 http://127.0.0.1:18789/health || exit 1

Composition avec Nginx et Tailscale

Quand nginx termine le TLS, exécutez la liveness sur l’URL interne pour isoler les erreurs de bord des bugs passerelle. Pour les déploiements tailnet-only, lancez les synthétiques depuis un appareil Tailscale tagué probe afin qu’un changement d’ACL ne coupe pas silencieusement les moniteurs.

Seuils d’alerte sans bruit

Condition	Fenêtre suggérée	Gravité
3 échecs de sonde consécutifs	~3 min si intervalle 60 s	Page astreinte
p95 > 800 ms sur saut interne	10 minutes soutenues	Ticket warning
Échec canary LLM	1 échec	Slack + ticket bridge auto

FAQ : sondes sur Mac cloud macOS

Question	Réponse
Les sondes doivent-elles tourner en root ?	Non—utilisez le même utilisateur de service propriétaire de ~/.openclaw pour attraper les régressions de permissions.
Où héberger des observateurs secondaires ?	Un autre nœud MacXCode ou votre VPC d’observabilité ; comparez tarifs pour une petite instance témoin.
Et si les logs explosent après debug ?	Suivez le guide journalisation structurée—debug uniquement sur fenêtres de support.

Pourquoi le bare metal Mac mini M4 aide la fidélité des sondes

Les contrôles synthétiques sont inutiles si l’hôte tremble d’oversubscription. Les nœuds bare metal Mac mini M4 offrent un CPU stable pour curl + JSON, un NVMe prévisible pour l’append des logs et le même comportement Apple Silicon qu’en dev. Les régions MacXCode HK / JP / KR / SG / US placent les observateurs près des utilisateurs tout en documentant l’accès SSH d’urgence dans aide.

En bref : traitez OpenClaw comme toute API de prod—définissez des SLO, prouvez-les par des sondes, répétez les pannes avant que le marketing promette « toujours disponible ». Quand les canaries s’agitent chaque semaine, montez en capacité via tarifs.