So bringst du n8n bei, abgestürzte Dienste auf deinem Server selbst zu reparieren

Vertraute Szene: Ein Container mit einer Datenbank oder einem Medienserver stürzt mitten in der Nacht ab. Du wachst mit einer Warnung auf, öffnest das Terminal, überprüfst die Logs, startest den abgestürzten Dienst neu und gehst schlecht gelaunt wieder schlafen. Normales Monitoring kann nur Panik-Nachrichten senden. Es erkennt das Symptom, versucht aber nicht einmal, die Ursachen herauszufinden.

Der beliebte Tech-Blogger NetworkChuck hat ein interessantes Repository namens n8n-terry-guide veröffentlicht. Darin befindet sich eine Schritt-für-Schritt-Anleitung zum Bau von Terry. Das ist ein virtueller Sysadmin innerhalb von n8n, der Dienste überprüft, per SSH auf Servern die Logs untersucht und in Telegram um Erlaubnis zum Neustart bittet.

Die Idee klingt spaßig, aber dahinter steckt eine praktische Agent-Architektur, die du leicht auf deinem eigenen Server nachbauen kannst.

Wer ist Terry und warum das nicht nur ein weiterer Bot ist

Normalerweise basiert Homelab-Automatisierung auf starren Skripten. Dienst stürzt ab – führe den Befehl docker restart aus. Wenn der Port von einem anderen Prozess belegt ist, bricht das Skript ab und spammt Fehler.

Der LLM-Agent-Ansatz funktioniert anders. Der Autor schlägt vor, das Modell wie einen Support-Azubi zu trainieren und seine Aufgaben schrittweise zu erweitern. Im Repository ist der gesamte Prozess in fünf Evolutionsstufen aufgeteilt:

1. Basic Checker. Der Agent pingt einen HTTP-Endpunkt an und prüft auf ein bestimmtes HTML-Tag.
2. Diagnostiker. Wenn der Dienst nicht verfügbar ist, verbindet sich Terry per SSH, führt docker ps aus, ruft den Exit-Code und die letzten Log-Zeilen ab.
3. Automatischer Installateur. Das Modell versucht, den abgestürzten Container wieder hochzufahren und überprüft die Website-Verfügbarkeit erneut.
4. Fehlerbeheber. Der Agent stößt auf einen Portkonflikt, findet den schuldigen Prozess mit System-Tools und trifft eine Entscheidung.
5. Human-in-the-Loop. Das Modell findet die Ursache des Fehlers, erstellt einen Aktionsplan und wartet auf die Bestätigung des Besitzers im Messenger.

Das Hauptmerkmal hier ist die fünfte Stufe. Kein vernünftiger Mensch würde einem Sprachmodell Root-Zugriff ohne Kontrolle geben. Terry kann Diagnosen selbstständig durchführen, aber alle modifizierenden Befehle müssen genehmigt werden.

Wie die n8n-Interna verdrahtet sind

Die gesamte Logik wird mit Standard-n8n-Nodes aufgebaut, ohne benutzerdefinierten TypeScript- oder Python-Code zu schreiben.

Im Zentrum des Schemas befindet sich ein KI-Agent-Node mit einem verbundenen GPT-4o-mini-Modell und einem Simple-Memory-Block. Für die Ausführung von Befehlen auf dem Server hat der Autor eine elegante Lösung gefunden: ein separates Subworkflow mit einem SSH-Node.

Wenn der Agent den Systemzustand prüfen muss, ruft er diesen Subprozess als Tool auf und übergibt den erforderlichen Befehl:

docker inspect website --format='{{.State.ExitCode}}'
docker logs website --tail 10

Um die Prüfungen zu automatisieren, wird ein Schedule Trigger vor dem Agenten platziert, der das Szenario alle 5 Minuten startet. Um zu verhindern, dass der Dialog zu einem Chaos aus beliebigem Text wird, wird am Modellausgang ein Structured Output Parser verwendet. Der Agent muss JSON in einem strikt definierten Format zurückgeben:

{
  "website_up": false,
  "message": "Контейнер остановлен из-за нехватки памяти",
  "applied_fix": false,
  "needs_approval": true,
  "commands_requested": "docker start website"
}

Dank der strikten Struktur versteht der nächste Node IF oder Switch sofort, ob alles in Ordnung ist. Wenn ein Defekt erkannt wird, sendet das Szenario eine Nachricht an Telegram mit Bestätigungsschaltflächen. "Ja" gedrückt – n8n gibt die Kontrolle an den Agenten zurück, und er führt die Reparatur durch.

Echte Hardware anschließen

Der Autor hat sich nicht auf eine Testseite auf Nginx beschränkt. Die Anleitung enthält System-Prompts und Befehlsbeispiele für vier beliebte Systeme:

• Proxmox-Hypervisor. Der Agent erhält den Node-Status, die Liste der VMs über pvesh get /nodes und prüft LXC-Container.
• UniFi-Netzwerkgeräte. Anfragen an die UniFi Network API zur Überwachung von Access Points, Client-Anzahl und Traffic-Verbrauchern.
• Network Attached Storage (NAS). SMART-Attribute der Festplatten über smartctl prüfen, RAID-Array-Status aus /proc/mdstat auslesen und kritische Fehler in journalctl prüfen.
• Plex-Medienserver. Die Weboberfläche prüfen und bei Hängern ordnungsgemäß neu starten.

Für Festplatten und NAS ist Terry so konfiguriert, dass es strikt im Nur-Lese-Modus arbeitet. Der Prompt verbietet explizit das Ausführen von Formatierungs-, Remount- oder Pool-Stopp-Befehlen.

Fallstricke, auf die man stoßen kann

Wenn du dich entscheidest, ein solches Szenario selbst bereitzustellen, achte auf einige Nuancen, die bei der Konfiguration von KI-Agenten oft vergessen werden.

Erstens das Iterationslimit. Standardmäßig führt der KI-Agent-Node in n8n bis zu 10 Tool-Aufrufe pro Ausführung durch. Wenn der Agent von der Ausgabe von netstat oder docker ps verwirrt wird, erschöpft er schnell das Limit und stürzt mit einem Fehler ab. Prompts müssen so spezifisch wie möglich sein und den Spielraum für Experimente einschränken.

Zweitens die Session-Übergabe. Bei der Ausführung nach Zeitplan hast du keinen Live-Chat, daher muss die Session-ID chatId in einem Zwischen-Edit-Fields-Node vor dem Senden an den Speicher des Agenten hart generiert werden. Andernfalls geht der Kontext vorheriger Prüfungen verloren.

Drittens der sogenannte God-Mode. Im Repository gibt es einen Prompt mit vollen Rechten für automatisches Beheben beliebiger Probleme. Dies auf einem Produktionsserver zu aktivieren, ist definitiv nicht empfehlenswert: Das Modell kann leicht einen benötigten Container löschen, um einen belegten Port freizumachen.

Lohnt es sich, es zu versuchen

Das Repository n8n-terry-guide enthält keine fertigen Workflow-Exportdateien – es ist eine Sammlung von Konfigurationen, Schritt-für-Schritt-Anleitungen und verfeinerten Prompts. Wenn du n8n bereits für private oder berufliche Zwecke betreibst, bietet die Anleitung einen ausgezeichneten Rahmen für die Erstellung eines Erreichbarkeitsassistenten.

Das Projekt wird diejenigen ansprechen, die es leid sind, dumme Alarme zu erhalten und in Telegram nicht nur ein "Dienst abgestürzt" geschrien zu bekommen, sondern eine fertige Diagnose mit einem "Reparieren"-Button. Fang klein an: Konfiguriere die Prüfung eines Test-Containers, probiere die Telegram-Integration aus und bewerte, wie bequem es ist, Routineaufgaben an ein Sprachmodell zu delegieren.