2026 OpenClaw MeshMac in der Praxis: Mattermost Incoming Webhook — minimale Schritte für Mehrknoten-Build-Status

Kurzüberblick: fünf Schritte bis zum ersten Post

1. Gateway bereitstellen: OpenClaw auf stabilem Ingress wie im Mehrknoten-Installationspfad; openclaw doctor und Healthchecks grün.
2. Mattermost Webhook erzeugen: Integration → Incoming Webhook im Zielkanal; vollständige https://…/hooks/…-URL einmal kopieren.
3. Egress zum Chat-Server: Nur das Gateway darf HTTPS zu Ihrem Mattermost-FQDN öffnen — siehe Abschnitt „Gateway“.
4. Events vereinheitlichen: Runner schreiben in die gemeinsame Queue (Deploy und Task-Queue-Sync), das Gateway rendert text oder attachments.
5. Betrieb: Retries mit Dedupe-Key, Metriken, vierteljährliche URL-Rotation im Kalender.

Gateway und Webhook-Konfiguration

Stellen Sie genau einen HTTPS-Endpunkt nach außen bereit (Reverse Proxy oder Ingress), der POST mit Content-Type: application/json annimmt — dort validiert OpenClaw eingehende Build-Events (HMAC, langer Header oder mTLS). Im Mattermost-Client wählen Sie Integrationen → Eingehender Webhook, aktivieren den Kanal und notieren die ausgegebene URL. Diese URL enthält den geheimen Token im Pfad; speichern Sie sie ausschließlich auf dem Gateway unterhalb von /etc/openclaw/secrets.d mit Rechten 0440 und einer Gruppe wie openclaw. Committen Sie niemals Webhook-Zeichenketten.

Ausgehend postet das Gateway mit application/json — typischerweise {"text": "…"} oder strukturierte attachments mit fallback für Mobilgeräte. Optional setzen Sie username und icon_url, um Staging vs. Produktion oder Repos zu unterscheiden. Hinter einem Forward-Proxy muss dieselbe HTTPS_PROXY-Konfiguration wie der OpenClaw-Dienst gelten; testen Sie mit curl -v vom Gateway-Subnetz, nicht vom Entwickler-Laptop. Details zu Sitzungen und Raten: Gateway Rate-Limit FAQ.

• TLS-Inspection: Wenn der Proxy eigene CAs einspielt, CA-Bundle auf dem Gateway pflegen.
• Self-hosted Mattermost: Zertifikatskette und SNI zum internen FQDN prüfen; ggf. nicht-Standard-Port in Firewall und Webhook-Test explizit setzen.

Implementieren Sie auf dem Gateway eine klare Route (z. B. POST /hooks/mattermost/build-status), die nur validierte Events aus der Worker-Queue annimmt und sie unmittelbar in den Mattermost-POST übersetzt. So bleibt die Latenz vorhersehbar: der Webhook-Handler antwortet dem Broker schnell mit einer Bestätigung, während der eigentliche Chat-POST asynchron oder in derselben Transaktion mit kurzem Timeout erfolgt — aber niemals blockiert ein Mac-Runner direkt auf die Mattermost-Antwort.

Mehrknoten-Statusaggregation: Mindestschritte

Jeder MeshMac sendet keine Rohtexte an Mattermost, sondern ein normiertes Ereignis an die zentrale Queue (Redis, NATS, RabbitMQ — konsistent mit Ihrem Deploy- und Queue-Setup). Der Gateway-Worker liest daraus, faltet Zwischenstände pro logischem Lauf zusammen (z. B. gleicher provider_run_id) und erzeugt einen sichtbaren Post pro relevanter Zustandsänderung — nicht pro internem Retry eines Knotens.

Praktisch bedeutet das: Wenn Knoten A und B dieselbe Pipeline parallel starten, sehen Sie im Kanal keine zwei widersprüchlichen Zeilen, sondern eine Aktualisierung, die den Gesamtstatus widerspiegelt (z. B. „noch laufend“ bis alle mesh_node_id-Teilresultate eingetroffen sind, oder „fehlgeschlagen“, sobald der erste relevante Fehler vorliegt — je nach Team-Policy). Halten Sie diese Policy im Repository oder Config-Repo dokumentiert, damit On-Call nicht raten muss, warum ein Kanal plötzlich „stiller“ wirkt als ein anderes Dashboard.

Implementieren Sie exponentielles Backoff mit Jitter bei HTTP 429 oder 5xx von Mattermost, maximal fünf Versuche innerhalb weniger Minuten. Den Dedupe-Schlüssel bilden Sie aus provider_run_id plus normalisiertem state; verworfene Duplikate können Sie 72 Stunden vorhalten. Fehlgeschlagene Zustellungen landen in einer Dead-Letter-Queue, damit Ops zwischen „Chat limitiert“ und „Payload ungültig“ unterscheiden können. Wenn Sie sehr große attachments-Blöcke nutzen, prüfen Sie die Markdown-Limits von Mattermost, damit mobile Clients nicht nur leere Karten rendern.

Tokens und Mindestberechtigungen

Trennen Sie eingehende Authentifizierung (HMAC/Header für Runner → Gateway) strikt von der Mattermost Webhook-URL. Letztere ist gleichzeitig Secret — behandeln Sie sie wie ein API-Token. Kein CI-Container und kein Xcode-Runner soll diese Variable standardmäßig erben; nur der Gateway-Prozess liest die Datei beim Start. Vertiefung: Secrets und Mindestrechte auf Knoten sowie IM-Benachrichtigungen und Token-Rotation.

Bei Rotation: neuen Webhook in Mattermost erzeugen, neue Datei atomar neben die alte legen, Gateway mit Dual-Read für ein Übergangszeitfenster neu laden, alte URL in Mattermost deaktivieren, alte Datei entfernen. Loggen Sie Antwortkörper redigiert — nie vollständige Hook-URLs. Für getrennte Umgebungen (Dev/Staging/Prod) nutzen Sie Env-Templates und Secrets je Umgebung, damit nicht versehentlich Produktions-Posts im Testkanal landen.

FAQ: Keine Nachrichten erhalten

Gehen Sie die Kette Runner → Queue → Gateway → Mattermost von hinten nach vorne durch: zuerst HTTP-Status und Antworttext des ausgehenden POST, dann Gateway-Logs, dann ob der Build überhaupt ein Queue-Event erzeugt hat.

Referenz für den Betrieb: fünf Retries, 72 Stunden Dedupe-Fenster, TLS 1.2+ zum Mattermost-Host, Gateway-Secret 0440. Vertiefung und weitere Szenarien im OpenClaw-Themenhub und in der Blog-Übersicht.