n8n para devs: Automatizando a recuperação de incidentes

Webhooks no n8n - Apresentação

Apresentando o curso e o instrutor

Bem-vindos a mais um curso de N8n voltado para pessoas desenvolvedoras aqui na Alura. Eu sou o Ricardo Bugan, responsável pela operação e desenvolvimento, e serei o instrutor deste curso.

Audiodescrição: Ricardo é um homem branco, com cabelo curto castanho e olhos castanhos. Ele veste uma camisa azul e está em um ambiente de escritório com uma parede clara ao fundo.

Introduzindo o fluxo de recuperação de acidentes

Neste curso, vamos abordar a recuperação de acidentes. Vamos montar todo esse fluxo no N8n, simulando um processo que nos ajudará a ter uma recuperação rápida de acidentes que podem ocorrer em nosso sistema em produção. Neste momento, o processo pode parecer complexo e causar certa apreensão devido à quantidade de informações, mas vamos entender passo a passo o que está acontecendo.

Quando executarmos este workflow, que já começa de forma diferente com um webhook, o chamaremos pelo Postman. Vamos acessar a URL pelo Postman e observar que ele executará todo um processo para nos enviar uma mensagem ao nosso time, informando que houve um problema, qual é o problema, a solução proposta, o contexto dos logs que temos e a necessidade de resolvermos, pois se trata de um problema grave que precisamos solucionar.

Explorando o fluxo e os guardrails

Vamos analisar todo esse fluxo novamente, passo a passo, começando pelo webhook que acabamos de chamar. Vamos aprender como executar um comando SSH para acessar uma máquina, obter nossos logs, realizar a transformação de dados e também verificar os guardrails. É importante garantir que não estamos transmitindo informações sensíveis para a IA, pois isso pode resultar em problemas de conformidade e vazamento de dados dos usuários, o que não é o ideal.

Teremos um novo nó de guardrail que vamos explorar para entender seu funcionamento. Este curso é bastante interessante e proporcionará várias ferramentas novas para utilizarmos no dia a dia com o N8n. Nossa imaginação poderá fluir livremente para aplicar o que aprendermos ao nosso contexto e criar automações com essa ferramenta, que é muito útil para integrar diversos sistemas com os quais trabalhamos diariamente.

Iniciando o curso

Vamos começar o curso?

Webhooks no n8n - Entendendo o contexto do projeto

Relembrando o uso do N8n

Antes de continuarmos e iniciarmos efetivamente nosso curso, vamos relembrar o que estamos estudando, por que estamos utilizando o N8n e como o estamos aplicando em nosso dia a dia. Consideramos o N8n como uma ferramenta que pode substituir ou complementar várias outras ferramentas em nosso cotidiano como pessoas desenvolvedoras. Ele nos auxilia a facilitar e organizar processos, além de substituir algumas ferramentas que podem ser mais robustas. No entanto, se estivermos em um time pequeno ou com uma equipe de infraestrutura em fase inicial, o N8n será útil para estabelecer essa infraestrutura, pois é prático e rápido de configurar.

Uma das primeiras aplicações que abordamos foi a organização da comunicação com o time. Observamos o que acontece no GitHub, gerenciamos pull requests (PRs) e organizamos um fluxo de comunicação com o Slack, e-mail e Trello. Isso se refere à gestão do fluxo de informações dentro do time, uma das funcionalidades mais eficazes e comuns do N8n.

Explorando funcionalidades anteriores do curso

Além disso, no curso anterior, exploramos a criação de testes automatizados, utilizando agentes de IA dentro da ferramenta. Também abordamos o acesso à documentação, como criar uma memória para nosso processo, e como modificar a documentação conforme necessário.

Continuaremos explorando o N8n, focando em como ele pode nos auxiliar na recuperação de incidentes. É comum que, durante o desenvolvimento de software, ocorram problemas. Precisamos saber rapidamente como resolvê-los. A ideia é simular um fluxo para recuperação de incidentes, criando um sistema de alerta para problemas em produção. Existem outras ferramentas que podem substituir o N8n, mas ele é uma opção viável para equipes pequenas ou com menos recursos.

Configurando o ambiente com Docker

Para simular tudo isso, vamos então configurar nosso ambiente utilizando o Docker. Temos aqui um projeto no qual utilizamos o Docker. Nesse projeto, há um Docker Compose que configura um sistema muito simples, composto por uma aplicação e um banco de dados, onde armazenamos os logs. Os logs são a parte principal que analisaremos para entender se há problemas no sistema, se precisamos agir e com qual urgência.

Vamos começar configurando o nosso ambiente com o Docker Compose. Aqui está o arquivo de configuração:

version: "3.8"

services:
  app-node:
    build: ./service
    container_name: service-app
    networks:
      - service_net
    environment:
      - NODE_ENV=development
      - POSTGRES_USER={POSTGRES_USER:-n8n}
      - POSTGRES_PASSWORD={POSTGRES_PASSWORD:-n8n}
      - POSTGRES_DB={POSTGRES_DB:-incidents}
      - PGDATABASE=postgres-bd
      - PGPORT=5432
      - SSH_PASSWORD={SSH_PASSWORD:-devpass}
    volumes:
      - ./home/usr/app
    ports:
      - "3000:3000"
      - "2222:22"
    depends_on:
      - postgres-bd

  postgres-bd:
    image: postgres:latest
    container_name: service-bd
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: n8n
      POSTGRES_DB: incidents
    networks:
      - service_net
    ports:
      - "5432:5432"
    volumes:
      - ./postgres:/docker-entrypoint-initdb.d
      
networks:
  service_net:
    name: service_network
    driver: bridge

Esse arquivo define dois serviços: um para a aplicação Node.js e outro para o banco de dados Postgres. Ambos estão conectados por uma rede chamada service_network.

Executando e monitorando contêineres Docker

O serviço é bastante simples, com algumas rotas definidas para produtos. No Docker Compose, configuramos nosso serviço e o banco de dados. Ao abrir o terminal e executar o comando sudo docker-compose up, a aplicação será iniciada. Após fornecer a senha, o sistema será levantado. No terminal, podemos visualizar o serviço em execução.

sudo docker compose up

Após iniciar os contêineres, podemos verificar quais estão em execução com o comando:

sudo docker ps

Ao executar sudo docker ps, podemos ver os dois contêineres: o da aplicação e o do Postgres, com suas últimas atualizações. Esses contêineres estão rodando com algumas portas abertas, permitindo a simulação do sistema.

Para visualizar os logs, utilizamos o comando sudo docker-compose logs, que exibe todos os registros do sistema, incluindo todas as requisições recebidas. Esses logs são fundamentais para analisar e entender eventuais erros na aplicação, especialmente quando ela está em produção, pois ajudam a compreender seu comportamento.

sudo docker compose logs

Simulando infraestrutura e configurando o serviço Node.js

Neste cenário, estamos simulando uma infraestrutura com o Docker. Se utilizarmos a AWS com EC2, Google Cloud ou Azure, podemos continuar, mas será necessário adaptar as instruções para o contexto específico, como localizar arquivos e logs e conectar os componentes. A ideia geral e o fluxo devem funcionar da mesma forma para implementar um sistema de alerta.

Embora AWS, Azure e Google Cloud tenham seus próprios sistemas de alerta e ferramentas que podem ser configuradas, aqui simulamos com o Docker dois serviços: um contêiner de aplicação e um contêiner de banco de dados. A execução ocorre para que possamos conectar com o N8n.

Agora, vamos para a configuração do nosso serviço Node.js. Aqui está o código que define o servidor e as rotas:

const { init, log } = require('./logger');
const crypto = require("crypto");
const db = require("./db");
require('dotenv').config();

const app = express();
app.use(express.json());

app.use((req, res, next) => {
    req.requestId = crypto.randomUUID();
    res.setHeader('X-Request-Id', req.requestId);
    next();
});

app.get('/', (req, res) => {
    log('info', {
        requestId: req.requestId,
        route: "GET /",
        message: "Health check ok"
    })
    res.json({ service: "products-service" });
});

app.get('/products', async (req, res) => {
    try {
        // ERRO proposital: coluna `prize` não existe
        const result = await db.query('SELECT id, name, price FROM products ORDER BY id');
        res.json(result.rows);
    } catch (err) {
        log('ERROR', {
            requestId: req.requestId,
            route: "GET /products",
            error_type: "SQL RUNTIME ERROR",
            message: "Query execution failed",
            db: {
                engine: 'postgres',
                operation: 'SELECT',
            },
            error_code: err.code,
            error_message: err.message
        });
        res.status(500).json({ error: 'Internal server error' });
    }
});

const port = process.env.PORT || 3000;
app.listen(port, () => {
    init({
        info: {
            message: `Products service listening on port ${port}`,
            port
        }
    })
});

Esse código configura um servidor Express com duas rotas: uma para verificação de saúde (/) e outra para listar produtos (/products). Note que há um erro proposital na consulta SQL para simular um problema que precisaremos resolver.

Iniciando o fluxo no N8n

Vamos agora para o N8n, onde faremos a primeira chamada e iniciaremos o fluxo para verificar se há algum erro.

Webhooks no n8n - Utilizando webhooks

Definindo o sistema de alerta com N8n

Se temos uma aplicação em execução que está gerando logs e organizando nossa aplicação em produção, precisamos definir quando e como chamar o N8n para identificar um problema. Precisamos que o N8n compreenda qual é o problema, notifique a equipe, emita um alerta para todos e que o processo siga adiante. Como iniciamos esse sistema de alerta?

Para isso, precisamos acessar o N8n e criar um novo workflow. Como vimos, todo o processo e organização no N8n são realizados por meio de workflows, e cada workflow possui um gatilho. Vamos aprender qual é o gatilho que iniciará o workflow de recuperação de acidentes. Esse workflow precisará de um gatilho, e nossa aplicação, que está rodando em produção no servidor ou na cloud, precisará notificar o N8n para dispará-lo. Podemos fazer isso por meio de uma chamada, como faríamos para outro sistema. No final, temos o sistema do N8n rodando e o sistema da nossa aplicação, e é uma comunicação entre dois sistemas.

Utilizando webhooks para comunicação entre sistemas

Para isso, utilizamos webhooks. Um webhook é um tipo de comunicação entre sistemas, onde um sistema avisa o outro sobre algum evento. No nosso gatilho, podemos chamar um webhook, que iniciará nossa aplicação quando for acionado. Ao configurá-lo, recebemos uma URL para o webhook. Se estivermos ouvindo esse webhook, ele ficará aguardando ser chamado. Quando o N8n estiver publicado, ele estará sempre disponível para ser acionado. Se copiarmos esse link, abrirmos em outra aba e o chamarmos, recebemos uma resposta indicando que o workflow foi iniciado.

{"message":"workflow was started"}

No nosso workflow, podemos ver que ele gerou um output com várias informações sobre quem o chamou e iniciou o workflow.

Simulando chamadas de API com Postman

Podemos adicionar informações adicionais, como query params, body params ou parâmetros gerais para essa chamada. Estamos falando de um sistema que chama outro sistema, e podemos fazer uma chamada para uma API. No final, estamos chamando um link como se fosse uma API. Utilizaremos o Postman para simular isso. No Postman, criaremos uma nova aba para chamar a URL fornecida, realizando um GET para essa URL. No body, especificaremos que queremos um body do tipo raw em formato JSON, e passaremos um body para ele.

{
    "messages": "o sistema está com erro"
}

Abriremos e fecharemos as chaves como um body JSON e incluiremos uma mensagem, por exemplo, "o sistema está com erro". Adicionaremos um segundo parâmetro, que são os logs, indicando que o arquivo de logs está em /etc/logs, como se estivéssemos especificando o caminho dos logs.

{
    "messages": "o sistema está com erro",
    "logs": "/etc/logs"
}

Enviando informações adicionais no webhook

Essas são duas informações que podemos enviar: uma mensagem e, possivelmente, várias mensagens, pois podemos ter diferentes webhooks configurados para cada situação. Neste caso, passaremos os logs, que seriam o caminho dos logs para nossa aplicação. Podemos ter um local específico, uma pasta ou arquivo específico para passar ao sistema em caso de erro. No caso do Docker, não precisaremos disso, pois ele possui comandos próprios, como docker compose logs ou docker logs, que fornecem os logs de tudo ou de um contêiner específico. Isso dependerá do contexto.

Não devemos nos ater exatamente ao projeto ou à forma como estamos fazendo. A ideia é traduzir isso para o nosso contexto. Com esse bot, podemos deixá-lo ouvindo novamente e fazer a requisição para ver a resposta. Ele nos dará uma resposta indicando que o workflow foi iniciado.

{"message": "workflow was started"}

Se verificarmos o webhook novamente, agora temos no body a mensagem e os logs, duas informações que, ao avançarmos para um próximo nó, podemos simular. Vamos pegar um nó de código simples para ver. Ele nos fornece todos os headers e, no body, temos a mensagem e os logs separados. Podemos usar essas informações no nosso workflow. Se quisermos usar apenas os logs, ele nos fornecerá apenas as informações específicas do log.

"body": {
    "messages": "o sistema está com erro",
    "logs": "/etc/logs"
}

Personalizando o fluxo de trabalho com informações de erro

No código, ele não traduz, apenas deixa o código direto, pois será usado como variável. Podemos ter essa informação separada para trabalhar no nosso workflow. Precisamos pensar em que informações colocar no body em caso de erro, para que o N8n possa trabalhar conforme esperado e montar o fluxo de aviso. Podemos incluir questões de gravidade ou nível, por exemplo, para indicar se é urgente ou apenas um aviso.

{
    "messages": "o sistema está com erro",
    "logs": "/etc/logs",
    "level": "urgente"
}

Podemos adicionar informações para ter um sistema de aviso robusto e flexível no N8n.

Explorando a versatilidade dos webhooks

Estamos usando o Postman para chamar uma URL com um body, mas qualquer sistema pode fazer uma chamada GET para essa URL com um body de requisição. No caso do Docker, seria um health check ou um sidecar de health check, que verifica o sistema periodicamente e, em caso de problema, faz a requisição. Podemos ter um local diferente, na própria URL ou código, para indicar que algo não funcionou e chamar o N8n em caso de erro crítico. Existem várias possibilidades para inserir essa chamada, e devemos analisar o contexto. O sistema precisa ter um mecanismo de auto-monitoramento para identificar problemas e tentar resolvê-los.

O webhook é versátil e pode ser usado para integração de sistemas. Por exemplo, ao cadastrar um novo cliente, podemos chamar o webhook para integração com o N8n e sistemas de marketing ou CRM. Ele é útil em diversos momentos, e estamos usando-o especificamente para iniciar o fluxo de prevenção de acidentes e entender o que está acontecendo. No entanto, essa não é sua única função.

Automatizando integrações com N8n

Esse é o jeito mais simples de automatizar o sistema e iniciar o fluxo do N8n para integração com CRM, ferramentas terceiras, disparo de mensagens importantes ou comunicação interna de eventos relevantes. O webhook é extremamente versátil e vale a pena explorar maneiras de integrá-lo com muitos aplicativos via N8n. Isso facilita a integração solicitada por algum time, em vez de entender e integrar diretamente com a API de um serviço específico, como o Freshdesk. O N8n pode substituir o Zapier para esse tipo de integração.

Começamos aqui com nossa chamada e fluxo, e o gatilho será o webhook. Nossa aplicação precisará se monitorar e chamar o N8n em caso de problema para tentar resolvê-lo.

Sobre o curso n8n para devs: Automatizando a recuperação de incidentes

O curso n8n para devs: Automatizando a recuperação de incidentes possui 125 minutos de vídeos, em um total de 35 atividades. Gostou? Conheça nossos outros cursos de Automação e Produtividade em Programação, ou leia nossos artigos de Programação.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Webhooks no n8n
• Coleta de evidências do servidor
• Tratamento dos dados
• IA no direcionamento de incidentes
• Comunicação com a equipe