An einen Coding-Agent übergeben

Ein Bericht ist eine Markdown-Zusammenfassung eines Alarms oder einer Ressource und ihrer jüngsten Historie. Schick ihn an ein Teammitglied oder füg ihn in einen Coding-Agent wie Claude Code ein. Der Agent kann damit die Ursache finden und den Fix in deinem Infrastruktur-Code als Pull Request vorschlagen. Vaicoa liest nur: Die Änderung erreicht Produktion, wenn ein Mensch sie mergt.

Einen Bericht holen

Alarmansicht → Teilen in der oberen Leiste.
Ressourcen-Ansicht → Menü ⋯. Sind Alarme an der Ressource aktiv, kommen sie mit hinein, und der Bericht ist als Vorfallsbericht formuliert. Sind keine aktiv, steht das im Bericht. Kürzlich beendete Alarme stehen unter „Recent alert history (7 days)“. Das Menü hat außerdem In Hetzner Console öffnen und ID kopieren.
Dashboard → eine Flottenzeile antippen, um sie aufzuklappen. Die Aktionen zum Teilen stehen am Ende der Karte.
Die Detailansicht eines Prüfziels, für einen Endpunkt, der von außen überwacht wird.
Dashboard → Aktive Alarme → Teilen-Symbol in der Kopfzeile: eine Zusammenfassung aller aktuellen Alarme.

Alarme brauchen Vaicoa Pro oder Vaicoa Team, Prüfziele ein Vaicoa-Konto. Im Gerätemodus, ohne Konto, teilst du Ressourcenberichte aus der Ressourcen-Ansicht und dem Dashboard.

An jeder Stelle gibt es zwei Aktionen:

Bericht teilen schickt den Bericht als Text oder als .md-Datei über das Teilen-Menü.
Für Coding-Agent kopieren kopiert denselben Bericht mit einem kurzen Anweisungsblock davor: woher die Daten kommen, was sie abdecken und dass die Überwachung read-only ist. So kann der Agent schon mit dem ersten Einfügen arbeiten. Ist an der Ressource nichts aktiv, stellt der Block den Bericht als Durchsicht dar, nicht als Vorfall.

Was ein Bericht enthält

Das Projekt und den Zeitpunkt; den Alarm (Zustand, Schwere, wann er begonnen hat, die Beschreibung, wie oft er diese Woche ausgelöst hat); die Ressource (Name, ID, Typ, Standort, Status und Zustand, die Angaben, die ihre Ansicht zeigt, Labels, verwandte Ressourcen, Agent-Status); Uptime-Checks, den jüngsten Alarmverlauf und Links zur Hetzner Console und zur Ressource in der App (cloudviewer://resource/…). Bei Pro und Team enthält der Bericht außerdem bis zu 5 aktuelle Log-Zeilen, gleich maskiert, sofern der Log-Kontext der Ressource auf dem Bildschirm geladen war. Ein Bericht enthält nur, was die App schon geladen hat; beim Erstellen wird nichts abgerufen. Im Gerätemodus enthält er die Ressource und die Links.

Ein Bericht enthält nie dein Hetzner-Token, Session-Tokens oder andere Zugangsdaten für Vaicoa. Um auch IP-Adressen wegzulassen, etwa bevor du in einen öffentlichen Kanal teilst, schalte Einstellungen → Datenschutz → IPs in geteilten Berichten enthalten aus.

Die Übergabehinweise deines Teams

Team-Admins können den eingebauten Anweisungsblock im Portal unter Agent-Übergabehinweise durch einen eigenen Text des Teams ersetzen. Es gibt je einen Hinweis für die Übergabe von Alarmen, Ressourcen und Uptime-Checks, als reinen Text mit bis zu 2.000 Zeichen. Ein leerer Hinweis behält den eingebauten Text. Für Coding-Agent kopieren nutzt dann bei allen im Team den Hinweis des Teams.

Sag dem Agent darin, wo das Infrastruktur-Repository liegt, welches Runbook er zuerst lesen soll und dass Änderungen über einen Pull Request laufen. Den Hinweis für Uptime-Checks lohnt es sich eigens zu schreiben: Ein geprüfter Endpunkt wird von außen überwacht und ist vielleicht keine Maschine, auf der sich dein Team anmelden kann.

Der Ablauf

Du siehst das Problem in Vaicoa. Ein Alarm wird aktiv, ein Uptime-Check schlägt fehl, ein Job meldet sich nicht mehr, oder die Kosten steigen.
Du übergibst es an den Agent. Nutz Für Coding-Agent kopieren und füg den Bericht ein. Mit dem Claude-Connector (Pro und Team) kann der Agent Vaicoa auch selbst abfragen.
Der Agent sucht die Ursache. Er liest den Bericht, holt sich über den Connector Metriken, Log-Zeilen oder den Alarmverlauf und gleicht sie mit deinem Infrastruktur-Code ab.
Der Agent schlägt eine Änderung als Pull Request vor. Er ändert den Code, der den Server oder Dienst beschreibt, etwa eine Ansible-Rolle, ein OpenTofu-Modul oder ein Kubernetes-Manifest, auf einem Branch und öffnet einen Pull Request. Darin steht, was er gefunden und was er geändert hat.
Die CI prüft die Änderung. Deine Pipeline führt den Plan oder Dry Run aus (tofu plan, ansible-playbook --check, ein serverseitiger Dry Run der Manifeste) und hängt das Ergebnis an den Pull Request.
Ein Mensch prüft und mergt, bittet um Änderungen oder schließt den Pull Request.
Der Merge rollt die Änderung aus. Deine Deployment-Pipeline oder dein GitOps-Controller wendet den gemergten Code an.
Vaicoa zeigt das Ergebnis. Die Metrik normalisiert sich, der Alarm ist beendet, der Check wird grün. Wenn nicht, fang wieder bei Schritt 2 an.

Ein Alarmziel kann den Bericht auch mit jedem Alarm schicken, für einen Endpunkt, der Alarme an einen Agent weitergibt (Pro und Team). Dieser Bericht ist kürzer als der aus der App: Er enthält nur den Alarm, die Ressource, die Links und den Hinweis deines Teams. Siehe Alarm-Webhook.

Was der Agent von dir braucht

Zugriff auf das Repository, das deine Infrastruktur beschreibt, mit dem Recht, einen Branch zu pushen und einen Pull Request zu öffnen.
Keine Zugangsdaten für Produktion. Gib dem Agent das Recht, eine Änderung vorzuschlagen, nicht, sie auszurollen.
Eine CI, die einen Plan oder Dry Run ausführt, bei jedem Pull Request.
Branch-Schutz für den Hauptbranch, damit nur ein geprüfter Pull Request gemergt werden kann.
Ein Deployment, das mit dem Merge startet, damit der Merge der einzige Schritt ist, der Produktion verändert.

Wo du die Kontrolle behältst

Bericht, Connector und Webhook geben dem Agent nur Informationen. Keiner davon kann einen Server, ein Projekt oder eine Einstellung ändern.
Nichts erreicht Produktion, bevor ein Mensch den Pull Request mergt, und der Plan in der CI zeigt vorher seine Wirkung.

Beispiel: eine Festplatte läuft voll

Auf app-2 wird ein Festplatten-Alarm aktiv: Das Root-Dateisystem ist zu 91 % belegt, Tendenz steigend. Das nutzt die Festplatten-Metriken des Vaicoa-Agents, einen Alarm und den Claude-Connector und braucht deshalb Pro oder Team.

Du öffnest den Alarm und nutzt Für Coding-Agent kopieren. Der Bericht zeigt, dass die Belegung seit drei Tagen gleichmäßig steigt.
Du fügst ihn in den Agent ein, der in einem Checkout deines Ansible-Repositorys läuft. Der Übergabehinweis deines Teams sagt, dass die Server über die Rolle app konfiguriert werden und Änderungen über Pull Requests laufen.
Über den Connector liest der Agent die Festplatten-Metriken einer Woche: Die Belegung wächst jeden Tag um etwa denselben Betrag. Im Repository findet er, dass die Anwendung eigene Log-Dateien nach /var/log/app/ schreibt und die Rolle app für sie keine Log-Rotation einrichtet.
Der Agent ergänzt die Rolle um eine logrotate-Konfiguration und öffnet einen Pull Request, der die Ursache erklärt. Die CI führt das Playbook im Check-Modus gegen Staging aus.
Du liest den Diff und die Ausgabe des Check-Modus und mergst.
Die Pipeline wendet die Rolle an. Die Belegung auf app-2 sinkt, und der Alarm ist beendet.

Grenzen

Agents können sich irren. Ein Agent kann eine Metrik falsch lesen, die falsche Ursache wählen oder eine Änderung vorschlagen, die zu weit geht. Das Review und die Plan-Ausgabe sind dafür da, das zu bemerken. Merge nur, was du auch von einem Teammitglied mergen würdest.
Halte Geheimnisse aus dem Gespräch heraus. Der Bericht enthält keine Zugangsdaten; füg auch selbst keine in den Agent ein.
Vaicoa sieht, was es überwacht: deine Hetzner-Ressourcen, die Server mit dem Vaicoa-Agent, deine Uptime-Checks und deine Jobs. Deinen Anwendungscode und dein Repository kennt es nicht.

Claude nach deinen Servern fragenVerbinde Claude mit Vaicoa, damit der Agent selbst nachschlagen kann.

Wenn etwas Aufmerksamkeit brauchtDerselbe Weg vom Alarm zur Ursache, ohne Agent.