2026 : OpenClaw sur Mac Mini loué — runbook PagerDuty Events API : escalade, fenêtres de silence et batch nocturne

Public : SRE et plateforme sur launchd et Mini loué. Chaîne reproductible vers l’Events API : OpenClaw, secrets minimaux, payloads, backoff/429, silences batch, matrice, sept étapes, repères, FAQ, accès SSH/VNC RunMini.

Pour prolonger le fil : segments HTTP et alertes, cron, santé agrégée et backoff, énergie, caffeinate et batch.

Trois écueils des webhooks naïfs sur un hôte sans présence locale

1. Secrets. Jeton global sur disque : surface d’attaque si backup ou SSH fuit.
2. Orages. Sans dedup_key ni sévérité, flap ou healthcheck sensible multiplie les incidents.
3. Nuit. Sans maintenance ETL, seuils prévisibles pages sans levier avant fin de segment.

OpenClaw et intégration des gardes

OpenClaw = politique avant POST PagerDuty ; launchd émet des lignes de santé qu’il agrège et filtre selon le runbook.

• Ingress local ou privé ; pas de flux anonyme depuis l’extérieur.
• Logs : haché clé, HTTP, retries, horodatage, répertoire dédié.
• Sévérité + liens runbook SSH/VNC RunMini.

Sur le disque du Mini loué, un socket UNIX ou un port loopback limite l’émission aux seuls binaires autorisés par launchd ; le filtre OpenClaw applique alors votre politique de bruit avant tout appel sortant, ce qui évite d’inonder PagerDuty lorsque plusieurs segments échouent en cascade pendant la même fenêtre.

Clé de routage et moindre privilège

Une intégration Events par service ou tranche ; clé en fichier root-only ou trousseau, lue par le démon émetteur seul.

• routing_key → escalades séparées GPU, CI, batch.
• Rotation trimestrielle ou post-fuite ; 48 h de double clé avant révocation.

Staging et production exigent des intégrations distinctes : même code, routing_key différente, sinon les incidents se mélangent dans une même file d’escalade. Prévoyez un déploiement atomique du secret puis un rechargement du démon sans redémarrage complet du nœud, afin de limiter l’indisponibilité sur un hôte 7×24.

Payload d’événement

JSON avec event_action trigger/acknowledge/resolve ; champs summary, source, severity pour les rulesets.

• dedup_key = hostname + job + signature stable.
• URL OpenClaw pour corrélation.
• custom_details : disque %, file, checkpoint.

Le couple source + component doit rester stable pour que les vues PagerDuty reconstruisent l’historique sans casser les règles ; évitez d’y injecter des horodatages volatils. Pour la résolution automatique, émettez resolve avec la même dedup_key que le trigger initial afin de clore proprement l’incident ouvert.

Recul exponentiel et fenêtres de silence

Backoff exponentiel plafonné 5 min + gigue ; respecter Retry-After sur 429.

1. Maintenances alignées segments ; ajuster si le batch glisse.
2. Baisser sévérité des pics attendus ; critical = perte données.
3. resolve en fin de segment pour clore l’incident.

Après trois échecs réseau consécutifs, basculez vers une file locale append-only sur volume APFS chiffré et reprenez l’envoi au prochain créneau réseau sain, en conservant la même dedup_key pour ne pas multiplier les incidents. Journalisez les rejets 429 avec l’en-tête Retry-After plutôt que de boucler immédiatement.

Couplage avec les tâches longues

Dépassement de stade → un trigger ; escalade seulement sans heartbeat sur la tranche suivante.

• custom_details : index segment, ETA.
• caffeinate/pmset + silences : veille planifiée ≠ panne.
• resolve après retries réussies.

Passez systématiquement un RUN_ID ou un identifiant de lot dans custom_details pour relier segment, journaux système et note d’astreinte, surtout lorsque plusieurs pipelines partagent la même routing_key. Si un segment dépasse 1,5× la durée médiane observée sur les trente dernières nuits, émettez d’abord une severity modérée avant d’autoriser l’escalade critique.

Matrice décisionnelle : appel direct contre relais

Colonne = conformité et egress du Mini loué.

Sept gestes reproductibles

1. Service PagerDuty, intégration Events, routing_key fichier restreint sur le Mini.
2. Émetteur : JSON OpenClaw → Events TLS, timeouts fixés.
3. Tables versionnées dedup_key/severity près du registre jobs.
4. Escalade > segment sain max + marge écrite.
5. Modèles silence/maintenance liés au calendrier batch.
6. Drill staging : trigger puis resolve avant prod.
7. Revue mensuelle incidents par routing_key.

FAQ

OpenClaw doit-il appeler PagerDuty en direct ou via un relais ?

Direct si clé bornée, ACL strictes, TLS ; relais pour audit, multi-locataire ou egress bloqué sur le Mini.

Comment éviter que le batch nocturne réveille l’astreinte ?

Maintenances/silences ruleset sur le batch, sévérité basse sur pics attendus, resolve fin de segment.

Que se passe-t-il si dedup_key entre en collision ?

Fusions bruyantes ; inclure hôte, job, signature ; pivoter la clé si la topologie change.

Faut-il craindre les plafonds de débit sur un seul Mini ?

Oui : une boucle mal bornée peut saturer l’API ; imposez un quota local, respectez Retry-After sur 429 et journalisez les rejets sans multiplier les tentatives aveugles.

Repères citables

• Backoff cap 5 min + gigue (liens grand public).
• Rotation : 48 h double clé staging→prod.
• Escalade ≥ 1,5× segment sain max pour limiter fausses pages.
• File locale de repli : rétention courte, rotation quotidienne, audit des échecs TLS.