Jak nauczyć n8n naprawiać usługi które uległy awarii na serwerze za Ciebie

Znana sytuacja: kontener z bazą danych lub serwerem multimedialnym ulega awarii w środku nocy. Budzisz się z alertem, otwierasz terminal, sprawdzasz logi, restartujesz awaryjną usługę i wracasz spać w złym nastroju. Zwykłe monitorowanie potrafi tylko wysyłać wiadomości o panice. Widzi objaw, ale nawet nie próbuje dociec przyczyn.

Popularny bloger technologiczny NetworkChuck opublikował interesujące repozytorium o nazwie n8n-terry-guide. Znajduje się w nim instrukcja krok po kroku budowy Terry'ego. To wirtualny admin systemowy wewnątrz n8n, który sprawdza usługi, łączy się przez SSH z serwerami, aby zbadać logi, i pyta Cię w Telegramie o pozwolenie na restart.

Pomysł brzmi zabawnie, ale za nim kryje się praktyczna architektura agenta, którą łatwo odtworzyć na własnym serwerze.

Kim jest Terry i dlaczego to nie jest zwykły bot

Zwykle automatyzacja w homelab jest budowana na sztywnych skryptach. Usługa ulega awarii — wywołuje polecenie docker restart. Jeśli port jest zajęty przez inny proces, skrypt się psuje i zaczyna spamować błędami.

Podejście LLM-agenta działa inaczej. Autor sugeruje trenowanie modelu jak stażysty wsparcia technicznego, stopniowo rozszerzając jego obowiązki. W repozytorium cały proces jest podzielony na pięć etapów ewolucji:

1. Podstawowy checker. Agent pinguje endpoint HTTP i sprawdza obecność konkretnego tagu HTML.
2. Diagnosta. Jeśli usługa jest niedostępna, Terry łączy się przez SSH, uruchamia docker ps, pobiera kod wyjścia i ostatnie linie logów.
3. Automatyczny naprawiacz. Model próbuje uruchomić crashed kontener i ponownie sprawdza dostępność strony.
4. Rozwiązywacz problemów. Agent napotyka konflikt portów, znajduje winowajcę używając narzędzi systemowych i podejmuje decyzję.
5. Human-in-the-Loop. Model znajduje przyczynę awarii, tworzy plan działania i czeka na potwierdzenie od właściciela w komunikatorze.

Główną cechą tutaj jest piąty etap. Żaden rozsądny człowiek nie dałby modelowi językowemu root access bez kontroli. Terry może przeprowadzać diagnostykę samodzielnie, ale jakiekolwiek modyfikujące polecenia muszą zostać zatwierdzone.

Jak wewnątrz n8n są połączone elementy

Cała logika jest zbudowana przy użyciu standardowych węzłów n8n bez pisania własnego kodu TypeScript ani Python.

W centrum schematu znajduje się węzeł AI Agent z podłączonym modelem GPT-4o-mini i blokiem Simple Memory. Do wykonywania poleceń na serwerze autor wymyślił eleganckie rozwiązanie: osobny subworkflow z węzłem SSH.

Gdy agent potrzebuje sprawdzić stan systemu, wywołuje ten podproces jako Tool, przekazując wymagane polecenie:

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

Aby zautomatyzować sprawdzanie, przed agentem umieszczony jest Schedule Trigger, który uruchamia scenariusz co 5 minut. Aby zapobiec zamienieniu dialogu w chaos dowolnego tekstu, na wyjściu modelu używany jest Structured Output Parser. Agent musi zwrócić JSON w ściśle określonym formacie:

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

Dzięki ścisłej strukturze następny węzeł IF lub Switch natychmiast rozumie, czy wszystko jest w porządku. Jeśli wykryto awarię, scenariusz wysyła wiadomość do Telegrama z przyciskami potwierdzenia. Naciśnięcie "Tak" — n8n zwraca kontrolę agentowi, a on wykonuje naprawę.

Podłączanie prawdziwego sprzętu

Autor nie ograniczył się do testowej strony na Nginx. W przewodniku znajdują się prompty systemowe i przykłady poleceń dla czterech popularnych systemów:

• Hypervisor Proxmox. Agent pobiera status węzła, listę VM-ek przez pvesh get /nodes i sprawdza kontenery LXC.
• Sprzęt sieciowy UniFi. Zapytania do UniFi Network API do monitorowania punktów dostępowych, liczby klientów i konsumentów ruchu.
• Network Attached Storage (NAS). Sprawdzanie atrybutów SMART dysków przez smartctl, odczytywanie statusu macierzy RAID z /proc/mdstat i sprawdzanie krytycznych błędów w journalctl.
• Serwer multimedialny Plex. Sprawdzanie interfejsu web i właściwy restart gdy się zawiesi.

Dla dysków i NAS, Terry jest skonfigurowany do pracy ściśle w trybie tylko do odczytu. Prompt jawnie zabrania wykonywania poleceń formatowania, ponownego montowania lub zatrzymywania pul.

Z czym można się spotkać

Jeśli zdecydujesz się wdrożyć taki scenariusz na własną rękę, zwróć uwagę na kilka niuansów, które często są zapominane przy konfigurowaniu agentów AI.

Po pierwsze, limit iteracji. Domyślnie węzeł AI Agent w n8n wykonuje do 10 wywołań narzędzi na jedno uruchomienie. Jeśli agent pogubi się w wynikach netstat lub docker ps, szybko wyczerpie limit i zawiesi się z błędem. Prompty muszą być jak najbardziej konkretne, zawężając pole do eksperymentów.

Po drugie, przekazywanie sesji. Przy uruchomieniu według harmonogramu nie masz żywego czatu, więc ID sesji chatId trzeba generować na twardo w pośrednim węźle Edit Fields przed wysłaniem do pamięci agenta. W przeciwnym razie kontekst poprzednich sprawdzeń zostanie utracony.

Po trzecie, tak zwany God-Mode. W repozytorium znajduje się prompt z pełnymi prawami do automatycznego naprawiania dowolnych problemów. Włączenie tego na serwerze produkcyjnym zdecydowanie nie jest tego warte: model może łatwo usunąć potrzebny kontener, aby zwolnić zajęty port.

Czy warto próbować

Repozytorium n8n-terry-guide nie zawiera gotowych plików eksportu workflow — to zbiór konfiguracji, instrukcji krok po kroku i dopracowanych promptów. Jeśli już używasz n8n do potrzeb domowych lub służbowych, przewodnik daje doskonały szkielet do stworzenia asystenta dyżurnego.

Projekt spodoba się tym, którzy są zmęczeni głupimi alertami i chcą otrzymywać w Telegramie nie tylko krzyk "usługa uległa awarii", ale gotową diagnozę z przyciskiem "napraw to". Zacznij od małych rzeczy: skonfiguruj sprawdzanie jednego testowego kontenera, wypróbuj integrację z Telegramem i oceń, jak wygodnie jest delegować rutynowe zadania do modelu językowego.