2026 OpenClaw « guardian » sur Mac Mini loué : healthcheck, launchd et alertes webhook reproductibles

Lecture : 9 min

Les équipes qui hébergent OpenClaw sur un Mac Mini loué cherchent une automatisation « mains dans les poches » : redémarrage propre, sonde qui reflète la réalité métier, et alerte structurée lorsque le service dérive. Ce tutoriel 2026 regroupe ce qu’il faut pour une intégration reproductible — installation et démarrage, logique daemon ou LaunchAgent, healthcheck HTTP ou CLI, exemple de payload webhook et table de codes de sortie pour le triage. En prolongement, consultez le blog, la page achat sans connexion préalable (parcours express RunMini), et le guide installation, doctor et surveillance métier.

Pourquoi un « guardian » mérite d’être intégré tôt

  1. SSH fermé. Un processus lancé à la main meurt souvent avec la session ; en production sur nœud distant, seul un daemon ou un LaunchAgent garantit la survie après déconnexion.
  2. Pas de sonde. Sans endpoint HTTP, test de socket ou sortie doctor interprétable, la charge CPU élevée, l’espace disque critique et une simple coupure réseau produisent des symptômes indistinguables pour l’astreinte.
  3. Alertes vagues. Un courriel « process down » sans exit_code, ni version, ni identifiant de machine oblige à ouvrir une session interactive — ce que l’on voulait justement éviter sur une location 7×24.

Matrice décisionnelle : encapsuler la surveillance sur macOS

Sur macOS, launchd offre RunAtLoad, intervalles réguliers et chemins de log standardisés ; cron convient aux équipes qui versionnent déjà des crontab dans Git. Un superviseur externe n’apporte un gain net que si votre stack impose déjà conteneurs ou une VM Linux adjacente au Mac loué.

Approche Avantage principal Limite
LaunchAgent utilisateur Redémarrage login, ThrottleInterval, journaux StandardOutPath Plist XML verbeux ; tests sur compte dédié « automation »
crontab Familiarité équipe, diff trivial en Git Moins fin pour relance au boot ; attention fuseau UTC vs local
Processus sous tmux / screen Debug rapide Pas une stratégie de production sur nœud loué 7×24

Étapes reproductibles : de l’installation à la boucle de garde

  1. Installer et démarrer. Canal npm ou binaire, puis openclaw doctor ; notez port ou commande « OK ».
  2. Journaux. Répertoire dédié sous ~/Library/Logs/openclaw-guardian/ avec rotation pour ne pas saturer le disque loué.
  3. Sonde. Exemple : curl -fsS --max-time 5 http://127.0.0.1:PORT/health ; le code retour de curl ou du script enveloppe devient la vérité opérationnelle transmise au webhook.
  4. Script gardien. Si la sonde échoue, appelez curl vers votre endpoint avec un corps JSON et propagez $? ; après trois succès consécutifs post-incident, un événement resolved réduit le bruit dans Slack ou PagerDuty.
  5. LaunchAgent. Plist dans ~/Library/LaunchAgents/, StartInterval 60–120 s, RunAtLoad true, logs StandardOutPath ; launchctl bootstrap / kickstart.
  6. Secrets. URL webhook et jeton hors dépôt (trousseau ou fichier chmod 600).
  7. Test. Stoppez OpenClaw, attendez deux cycles, vérifiez le JSON reçu ; relancez et validez la clôture si implémentée.

Combinez avec cron et watchdog 7×24 : relance du binaire d’un côté, preuve métier et webhook de l’autre.

Exemple de champs JSON pour une alerte webhook homogène

Le récepteur doit pouvoir router par service, prioriser par severity et corréler avec exit_code sans relire les journaux SSH. Le contrat minimal couvre aussi l’horodatage ISO 8601 et un message lisible humain ; enrichissez via metadata (version OpenClaw, région, identifiant de location).

{
  "event": "openclaw.health.failed",
  "severity": "critical",
  "service": "openclaw",
  "host": "runmini-mac-01",
  "timestamp": "2026-03-24T14:32:01Z",
  "exit_code": 7,
  "probe": "http://127.0.0.1:18789/health",
  "message": "HTTP 000 connection refused",
  "metadata": {
    "openclaw_version": "x.y.z",
    "region": "eu",
    "rental_provider": "RunMini"
  }
}

Tableau des codes de sortie fréquents (sonde ou shell)

Ces valeurs ne sont pas propres à OpenClaw : elles forment un langage commun entre votre shell, les codes de curl, les signaux du noyau et le tableau de bord qui consomme le webhook.

Code Interprétation usuelle Piste de remédiation
0 Succès de la sonde Aucune alerte ; considérer compteur de résilience si vous gérez le flapping
1 Échec générique script set -euxo pipefail + logs
6 DNS / hôte (curl) Résolveur, proxy, pare-feu
7 Connexion refusée Service arrêté ou mauvais port
22 HTTP 4xx/5xx (curl -f) Route /health, TLS, amont
124 Timeout Seuil max-time, I/O disque
130 SIGINT Test manuel, pas cron
137 SIGKILL / OOM Mémoire unifiée, quotas
143 SIGTERM Mise à jour, reboot, maintenance

Repères citables et synthèse opérationnelle

  • Intervalle : soixante à cent vingt secondes équilibrent réactivité et charge CPU sur un Mac Mini loué souvent partagé avec d’autres tâches.
  • Timeouts : environ cinq secondes pour un healthcheck loopback ; quinze à trente secondes si la sonde valide une API SaaS critique en sortie.
  • Logs : conservez au moins une semaine de fichiers compressés pour aligner un incident nocturne avec les fenêtres de maintenance du fournisseur ou les pics réseau observés.

Conclusion et commande

En combinant launchd, une sonde qui reflète votre charge réelle et un webhook JSON stable, vous transformez la location en poste d’automatisation prévisible plutôt qu’en machine à reconnecter après chaque week-end. L’effort d’écriture du plist et du script tient généralement en une demi-journée pour une première version exploitable.

Pour obtenir un nœud Apple Silicon prêt SSH sans investissement bare-metal immédiat, ouvrez achat RunMini — le parcours permet de parcourir les offres sans connexion préalable — puis affinez la configuration sur tarifs ; l’accueil résume l’écosystème console et support.

Après validation du guardian, commandez un Mac Mini loué ; autres guides sur le blog et l’accueil.

Achat sans connexion