2026 OpenClaw sur Mac Mini loué : Grafana OnCall, webhooks 7×24, silence nocturne, escalade et retries à backoff — guide minimal reproductible
Les développeurs indépendants qui louent un Mac Mini pour des lots OpenClaw en 7×24 ont besoin d’une astreinte qui respecte le silence, l’escalade et le budget de retries — pas d’un script curl répété à deux heures du matin.
Ce guide livre une conclusion opérationnelle : « branchez Grafana OnCall via un seul module webhook, figez la matrice de routage, segmentez le DAG nocturne ».
Matrice OnCall, six étapes, repères citables — liens : accueil, matrice 7×24, achat.
Pourquoi les scripts webhook naïfs échouent la nuit
- Retries sans borne. Un segment bloqué réémet le même payload OnCall chaque minute jusqu’au rate limit — faute de clé de déduplication liée à
batch_id. - Décalage de politique. Les fenêtres silencieuses Grafana OnCall ne suivent plus le calendrier launchd réel ; la pression disque attendue devient incident pendant qu’un vrai échec reste masqué.
- Passerelle trop exposée. Lier OpenClaw sur toutes les interfaces transforme le Mac loué en relais ouvert dès qu’une règle pare-feu glisse.
Mac Mini loué : openclaw onboard --install-daemon et exposition loopback sécurisée
Épinglez Node 24, installez OpenClaw v2026.5.x, puis openclaw onboard --install-daemon sous un compte automation ; OPENCLAW_HOME via EnvironmentVariables launchd.
- Passerelle 127.0.0.1 +
X-OpenClaw-Secretsur les routes OnCall sortantes. - Reverse proxy TLS seulement si un SaaS POST en entrant ; sinon loopback seul.
- Logs JSON :
batch_id,segment,oncall_group.
openclaw onboard --install-daemon
openclaw gateway status
# attendu : bind 127.0.0.1:18789, keepalive launchd
Grafana OnCall : routage, fenêtres silencieuses et politique d’escalade
Figez ces paramètres dans le contrôle de version. Les ratios tiennent sur un uplink domestique et un seul disque APFS loué.
| Contrôle | Valeur de départ | Note opérationnelle |
|---|---|---|
| Webhook entrant | Une intégration par environnement | URL dans le trousseau ; rotation trimestrielle. |
| Clé dedup | hôte:batch_id:segment |
Évite les incidents parallèles sur retries de segment. |
| Silence UTC (batch nuit) | 22:00–06:00 + 30 min tampon | Tag night_batch ; P1 data loss contourne le silence. |
| Délais d’escalade | 15 → 30 → 60 minutes | Alignés sur le segment le plus long + plafond retry. |
| Route pression disque jaune | Politique notify différée | Rouge APFS contourne le silence. |
| Resolve au succès | Obligatoire | OpenClaw POST resolve quand le checkpoint avance. |
DAG nocturne : checkpoints segmentés et modèle de backoff
Découpez chaque couloir nocturne en trois à six segments. Persistez les checkpoints sous $OPENCLAW_HOME/checkpoints pour reprendre après redémarrage passerelle sans re-déclencher OnCall sur les tranches déjà vertes.
# modèle backoff (esquisse bash)
BASE=3; CAP=60; MAX=5; JITTER=0.2
for attempt in $(seq 1 $MAX); do
sleep $(( BASE * 2 ** (attempt-1) < CAP ? BASE * 2 ** (attempt-1) : CAP ))
curl -fsS -X POST "$ONCALL_URL" -d @"payload.json" && break
done
- firing seulement après budget segment ; une description OnCall fusionnée.
- Honorez 429 et
Retry-Afteravant le backoff maison. - Voir throttle launchd I/O sur NVMe partagé.
Seuils disque APFS et rotation des journaux launchd
Les tempêtes d’alertes naissent souvent sur disque plein, pas sur un webhook capricieux. Verrouillez des garde-fous locaux avant tout emit.
- Jaune à quinze pour cent d’espace APFS libre ; rouge à dix pour cent — pause des nouveaux segments et page via la route non différée.
- Faites tourner
~/Library/Logs/openclaw/gateway.logvia newsyslog à 256 Mo avec sept copies quotidiennes. - Réglez
ThrottleIntervallaunchd entre 90 et 120 secondes sur le label passerelle pour amortir les boucles de redémarrage.
Six étapes reproductibles de déploiement
- Provisionner le nœud. Finalisez l’achat, validez SSH depuis le centre d’aide, relevez
df -hdepuis l’accueil onboarding. - Onboard OpenClaw. Lancez
openclaw onboard --install-daemon, vérifiez le bind loopback, installez le plist KeepAlive. - Créer l’intégration OnCall. Mintez l’URL webhook entrante, mappez sévérité, attachez la chaîne d’escalade et le silence UTC pour le tag
night_batch. - Un seul module émetteur. Mappez les événements internes vers un JSON figé ; incluez dedup key et payload resolve au succès checkpoint.
- Câbler le DAG. Segments, fichiers d’état, backoff plafonné à cinq tentatives et soixante secondes.
- Exercice de tir. Alerte staging, silence effectif, escalade seulement après délai politique ; tracez la latence emit.
Repères citables : bind loopback 127.0.0.1 ; silence 22:00–06:00 UTC plus 30 minutes de dépassement ; escalade 15 / 30 / 60 minutes ; backoff base 3 s, plafond 60 s, max 5 tentatives, jitter ±20 % ; APFS jaune 15 % rouge 10 % ; rotation gateway 256 Mo × 7 jours ; ThrottleInterval 90–120 s.
FAQ tempête d’alertes
- OnCall a accepté le webhook mais personne n’a été notifié — que faire ?
- Vérifiez routage, planning astreinte et silences OnCall ; journalisez
alert_group_id+batch_id. - Puis-je réutiliser le chemin Uptime Kuma pour OnCall ?
- Séparez les chemins : Kuma sur
/hooks/uptime; OnCall utilise son URL d’intégration et son schéma — voir le guide Upptime / Uptime Kuma côté moniteurs uniquement. - Quand passer à un forfait Mac Mini longue durée ?
- Lorsque checkpoints, intégrations OnCall et labels launchd doivent survivre des mois — comparez les paliers dans la matrice location longue durée avant de figer les calendriers de silence.
Louer un Mac Mini pour OpenClaw et Grafana OnCall 7×24
RunMini maintient l’Apple Silicon en ligne pour gardiens et couloirs DAG nocturnes. Comparez la matrice hébergement longue durée, les forfaits et l’achat forfait long ; lisez le guide launchd watchdog après commande.
En synthèse : associez la passerelle loopback OpenClaw aux webhooks Grafana OnCall, une table de routage figée, des checkpoints nocturnes segmentés et un backoff plafonné. Dimensionnez le nœud avec la matrice batch 7×24, puis revenez à l’accueil après votre première nuit silencieuse.