Files
Rui 599d8339ef
continuous-integration/webhook Deploy concluido com sucesso (VPS 4)
docs: adiciona guia de auto-cura à wiki
2026-05-12 06:15:32 +02:00

3.7 KiB

🔄 Loop de Auto-Cura (Self-Healing DevOps)

Este documento documenta o funcionamento e a arquitetura do Loop de Auto-Cura (Self-Healing) implementado na infraestrutura do Clube67. O objetivo é fazer com que erros críticos de execução em nossos containers de produção (Docker) abram chamados automáticos (Issues) no Gitea para que nossos Agentes de IA façam a correção de forma autônoma.


🗺️ Fluxo Geral da Arquitetura

graph TD
    A["🐳 Docker Container (VPS 1)"] -->|Gera Logs de Erro| B["📊 Loki + Promtail"]
    B -->|Avalia Regra de Erro| C["📈 Grafana Alerting"]
    C -->|Webhook de Alerta (Local)| D["🔌 Gitea-Bridge (Docker)"]
    D -->|API POST /issues| E["🎫 Gitea Server (VPS 3)"]
    E -->|Abre Issue de Bug| F["🤖 Agente de IA (SRE)"]
    F -->|Corrige, Comita e Dá Push| A

Como o formato de payload de alertas do Grafana é incompatível com o formato que a API de Issues do Gitea espera, a Gitea-Bridge atua como o tradutor inteligente desse fluxo, formatando o erro em um relatório Markdown completo.


🚀 Instalação do Gitea-Bridge (Na VPS 1)

Como a VPS 1 adota o padrão "Runtime Puro (Bunker)", rodamos a bridge de forma isolada dentro do Docker (sem instalar Node.js no sistema real).

Rode os comandos abaixo no terminal da VPS 1:

# 1. Crie a pasta do projeto
mkdir -p /home/deploy/gitea-bridge && cd /home/deploy/gitea-bridge

# 2. Baixe o código fonte diretamente do Gitea
curl -H "Authorization: token ada47ca2fb196319dd10245cc216a327dac857ec" \
     http://10.99.0.3:3000/ruicesar/clube67_newwhats.local/raw/branch/main/self-healing/bridge.js \
     -o bridge.js

# 3. Suba o container da Bridge rodando em segundo plano
docker run -d \
  --name gitea-bridge \
  --restart always \
  -p 127.0.0.1:9091:9091 \
  -v /home/deploy/gitea-bridge/bridge.js:/app/bridge.js \
  -e GITEA_TOKEN="ada47ca2fb196319dd10245cc216a327dac857ec" \
  -e PORT=9091 \
  node:alpine node /app/bridge.js

⚙️ Configuração do Canal de Alertas (Grafana - VPS 1)

O Grafana foi configurado programmaticamente via API REST para enviar notificações de erro para a bridge local.

  • Canal de Alerta (Contact Point) Criado: Gitea-Bridge
  • URL de Destino: http://localhost:9091/alerts
  • Política de Notificação Root (Padrão): Alterada para usar o Gitea-Bridge como o destinatário padrão para todos os alertas que dispararem no cluster.

🚨 Alertas Ativos e Monitorados

Os seguintes alertas já estão monitorando seus respectivos containers e abrirão Issues no Gitea de forma automática ao falharem:

  1. BACKEND - Exceção Não Tratada
    • Foco: Monitora exceções não tratadas (TypeError, ReferenceError, UncaughtException, etc.) no container newwhats-backend-prod.
  2. BACKEND - Colisão Prisma P2002
    • Foco: Monitora violações de chaves únicas no PostgreSQL do WhatsApp.
  3. BACKEND - Erros HTTP 5xx
    • Foco: Captura instabilidades de requisições web gerando erros 500 para clientes.
  4. FALCO CRITICAL & POSSÍVEL CRYPTOJACKING
    • Foco: Monitoramento do EDR contra invasões de sistema e mineradores de criptomoedas ilegais nas VPSs.

🤖 Como o Agente Interage com a Issue

Ao ser notificado de que uma Issue automática foi aberta, o Agente de IA SRE deve:

  1. Ler a Issue no Gitea de baixo para cima.
  2. Analisar a stack trace ou log de erro anexado no corpo da Issue.
  3. Acessar a VPS 4 (Dev/Builder) para corrigir o código defeituoso.
  4. Realizar o commit e push com a correção.
  5. O webhook de deploy enviará o código saudável de volta para a VPS 1 (Produção) e o Grafana resolverá o alerta automaticamente!