>_ DevTrendspt

Idioma

Início

Linguagens

Seções

Frontend Backend Mobile DevOps AI / ML GameDev Blockchain Embarcados Segurança
Unknown

Como ensinar o n8n a corrigir serviços travados no seu servidor para você

Cena familiar: um container com um banco de dados ou servidor de mídia trava no meio da noite. Você acorda com um alerta, abre o terminal, verifica os logs, reinicia o serviço travado e volta a dormir de mau humor. O monitoramento convencional apenas envia mensagens de pânico. Ele enxerga o sintoma, mas não tenta descobrir as causas.

O popular blogger de tecnologia NetworkChuck lançou um repositório interessante chamado n8n-terry-guide. Dentro dele há um guia passo a passo para construir o Terry. Este é um sysadmin virtual dentro do n8n que verifica serviços, acessa servidores via SSH para examinar logs e pede sua permissão no Telegram para reiniciar.

A ideia parece divertida, mas por trás dela há uma arquitetura de agente prática que é fácil de replicar no seu próprio servidor.

Quem é o Terry e por que este não é apenas outro bot

Normalmente, a automação de homelab é construída com scripts rígidos. Serviço trava — dispara o comando docker restart. Se a porta estiver ocupada por outro processo, o script quebra e começa a enviar erros repetidamente.

A abordagem com agente LLM funciona de forma diferente. O autor sugere treinar o modelo como um estagiário de suporte, expandindo gradualmente suas responsabilidades. No repositório, todo o processo é dividido em cinco estágios de evolução:

  1. Verificador básico. O agente faz ping em um endpoint HTTP e verifica uma tag HTML específica.
  2. Diagnóstico. Se o serviço estiver indisponível, o Terry conecta via SSH, executa docker ps, recupera o código de saída e as últimas linhas dos logs.
  3. Reparador automático. O modelo tenta iniciar o container travado e verifica novamente a disponibilidade do site.
  4. Solucionador de problemas. O agente encontra um conflito de porta, identifica o processo responsável usando utilitários do sistema e toma uma decisão.
  5. Humano no loop. O modelo encontra a causa da falha, forma um plano de ação e aguarda confirmação do proprietário no mensageiro.

O principal recurso aqui é o quinto estágio. Nenhuma pessoa sensata daria a um modelo de linguagem acesso root sem controle. O Terry pode realizar diagnósticos de forma independente, mas qualquer comando de modificação deve ser aprovado.

Como a conexão interna do n8n funciona

Toda a lógica é construída usando nodes padrão do n8n sem escrever código personalizado em TypeScript ou Python.

No centro do esquema está um node de Agente de IA com um modelo GPT-4o-mini conectado e um bloco de Memória Simples. Para executar comandos no servidor, o autor teve uma solução elegante: um subworkflow separado com um node SSH.

Quando o agente precisa verificar o estado do sistema, ele chama esse subprocesso como uma Ferramenta, passando o comando necessário:

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

Para automatizar as verificações, um Schedule Trigger é colocado antes do agente, iniciando o cenário a cada 5 minutos. Para evitar que o diálogo se transforme em uma bagunça de texto arbitrário, um Structured Output Parser é usado na saída do modelo. O agente deve retornar JSON em um formato estritamente definido:

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

Graças à estrutura rígida, o próximo node IF ou Switch entende instantaneamente se tudo está bem. Se uma falha for detectada, o cenário envia uma mensagem para o Telegram com botões de confirmação. Se você pressionar "Sim" — o n8n retorna o controle ao agente, e ele executa o reparo.

Conectando hardware real

O autor não se limitou a um site de teste no Nginx. O guia inclui prompts de sistema e exemplos de comandos para quatro sistemas populares:

  • Hypervisor Proxmox. O agente obtém status do nó, lista de VMs via pvesh get /nodes e verifica os containers LXC.
  • Equipamentos de rede UniFi. Requisições à API UniFi Network para monitorar access points, contagem de clientes e consumidores de tráfego.
  • Network Attached Storage (NAS). Verificação de atributos SMART dos discos via smartctl, leitura do status do array RAID do /proc/mdstat e verificação de erros críticos no journalctl.
  • Servidor de mídia Plex. Verificação da interface web e reinicialização adequada quando trava.

Para discos e NAS, o Terry é configurado para funcionar estritamente em modo somente leitura. O prompt proíbe explicitamente a execução de comandos de formatação, remontagem ou parada de pool.

Armadilhas que você pode encontrar

Se você decidir implementar esse tipo de cenário no seu ambiente, preste atenção a alguns detalhes que frequentemente são esquecidos ao configurar agentes de IA.

Primeiro, o limite de iterações. Por padrão, o node de Agente de IA no n8n faz até 10 chamadas de ferramentas por execução. Se o agente ficar confuso com a saída de netstat ou docker ps, ele rapidamente esgotará o limite e travará com um erro. Os prompts precisam ser o mais específicos possível, restringindo o campo para experimentações.

Segundo, o passar de sessão. Ao executar em um agendamento, você não tem um chat ao vivo, então o ID da sessão chatId precisa ser gerado de forma fixa em um node intermediário de Editar Campos antes de enviar para a memória do agente. Caso contrário, o contexto das verificações anteriores será perdido.

Terceiro, o chamado Modo Deus. No repositório, há um prompt com direitos completos para correção automática de qualquer problema. Habilitar isso em um servidor de produção definitivamente não vale a pena: o modelo pode facilmente excluir um container necessário para liberar uma porta ocupada.

Vale a pena tentar

O repositório n8n-terry-guide não contém arquivos de exportação de workflow prontos — é uma coleção de configurações, instruções passo a passo e prompts refinados. Se você já executa o n8n para necessidades pessoais ou de trabalho, o guia oferece uma excelente estrutura para criar um assistente de plantão.

O projeto vai agradar quem está cansado de alertas idiotas e quer receber no Telegram não apenas um grito de "serviço travou", mas um diagnóstico pronto com um botão "corrigir". Comece pequeno: configure a verificação de um container de teste, experimente a integração com o Telegram e avalie o quão conveniente é delegar tarefas rotineiras a um modelo de linguagem.

Projetos relacionados