Skip to content

Latest commit

 

History

History
155 lines (115 loc) · 6.19 KB

File metadata and controls

155 lines (115 loc) · 6.19 KB

<<<<<<< HEAD

vr_monitor_softwarecontrol

Sistema de monitoramento de servidores

VR Monitor

Plataforma de monitoramento de infraestrutura com visual premium (glassmorphism, estilo Apple/Linear/Vercel), conforme o prompt original.

Status: escopo completo implementado

  • Backend (FastAPI): auth JWT + RBAC, CRUD de servidores, ingestão de métricas, dashboard em tempo real, alertas (regras + avaliação automática + email), mapa de infraestrutura, gestão de usuários, relatórios em PDF (manual e automático toda segunda-feira)
  • Collector service: agente Python que faz polling de Windows Exporter / Node Exporter
  • Frontend (Next.js 15 + TypeScript + Tailwind): login, dashboard, lista/detalhe de servidores com gráfico de histórico, alertas, mapa de infraestrutura, usuários, relatórios, modo NOC/TV — todas as telas com o design system glass (dark/light mode, blur, cards translúcidos) definido nas Fases 5-7
  • Docker Compose: Postgres+TimescaleDB, Redis, API, collector e frontend, todos orquestrados juntos

Estrutura

vr-monitor/
├── apps/api/          # Backend FastAPI
├── apps/web/          # Frontend Next.js
├── agent/             # Collector service (polling dos exporters)
└── infra/docker/       # Docker Compose

Pré-requisitos

  • Docker e Docker Compose
  • (Opcional, só se quiser rodar sem Docker) Python 3.12+, Node.js 20+, Postgres 16 com extensão TimescaleDB, Redis 7

Como colocar tudo rodando (via Docker — recomendado)

1. Configurar variáveis de ambiente do backend

cd vr-monitor/apps/api
cp .env.example .env

Edite o .env e defina dois segredos (qualquer string aleatória longa serve):

  • JWT_SECRET_KEY
  • INTERNAL_SERVICE_TOKEN

(Opcional) Preencha SMTP_HOST/SMTP_USER/SMTP_PASSWORD se quiser que alertas e relatórios sejam enviados por email de verdade. Sem isso, o sistema funciona normalmente — só loga em vez de enviar.

2. Configurar o frontend

cd vr-monitor/apps/web
cp .env.local.example .env.local

O padrão (http://localhost:8000) já funciona se você não mudar as portas do Compose.

3. Configurar o collector

Edite vr-monitor/agent/config.yaml:

  • api.service_token deve ser idêntico ao INTERNAL_SERVICE_TOKEN do .env da API
  • Ajuste a lista servers com os hostnames e URLs reais dos seus Windows Exporter / Node Exporter (porta padrão: 9100 para Node Exporter, 9182 para Windows Exporter)

O hostname no config.yaml precisa ser exatamente igual ao hostname cadastrado via API — é assim que o collector sabe para qual servidor enviar cada métrica.

4. Subir a infraestrutura e rodar as migrações

cd vr-monitor/infra/docker
docker compose up -d db redis
docker compose run --rm api alembic upgrade head
docker compose run --rm api python -m scripts.seed_admin "Admin" admin@empresa.com "senha-forte-123"

5. Subir tudo

docker compose up -d api agent web
  • Frontend: http://localhost:3000
  • API: http://localhost:8000 (documentação interativa em /docs)

Abra http://localhost:3000/login e entre com o admin criado no passo 4. Cadastre servidores pela própria interface (Servidores → Novo servidor) — depois disso o collector já consegue enviar métricas para eles.

Para o modo NOC/TV (sem menus, cards grandes), acesse http://localhost:3000/noc.

Parar tudo

cd vr-monitor/infra/docker
docker compose down          # mantém os dados
docker compose down -v       # remove também os volumes (apaga banco e relatórios gerados)

Rodando sem Docker (desenvolvimento local)

Backend:

cd vr-monitor/apps/api
python3 -m venv venv && source venv/bin/activate
pip install -r requirements.txt
cp .env.example .env   # edite DATABASE_URL e REDIS_URL para localhost
alembic upgrade head
python -m scripts.seed_admin "Admin" admin@empresa.com "senha-forte-123"
uvicorn app.main:app --reload

Requer um Postgres local com a extensão timescaledb habilitada e um Redis em localhost:6379.

Frontend:

cd vr-monitor/apps/web
cp .env.local.example .env.local
npm install
npm run dev

Collector:

cd vr-monitor/agent
pip install -r requirements.txt
python collector.py config.yaml

Testando a API diretamente (sem o frontend)

# Login
curl -X POST http://localhost:8000/api/v1/auth/login \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "username=admin@empresa.com&password=senha-forte-123"

# Cadastrar um servidor
curl -X POST http://localhost:8000/api/v1/servers \
  -H "Authorization: Bearer <access_token>" \
  -H "Content-Type: application/json" \
  -d '{"name":"srv-web-01","hostname":"srv-web-01.empresa.local","ip_address":"10.0.1.15","os_type":"linux","os_version":"Ubuntu 24.04"}'

# Criar uma regra de alerta (CPU > 90%)
curl -X POST http://localhost:8000/api/v1/alerts/rules \
  -H "Authorization: Bearer <access_token>" \
  -H "Content-Type: application/json" \
  -d '{"metric_type":"cpu","operator":"gt","threshold":90,"severity":"critical","notify_emails":["infra@empresa.com"]}'

# Gerar um relatório manualmente
curl -X POST http://localhost:8000/api/v1/reports/generate \
  -H "Authorization: Bearer <access_token>"

O que foi (e não foi) testado neste ambiente

Este ambiente de desenvolvimento não tem acesso à rede (não dá para pip install nem npm install) nem Postgres/Redis/Node disponíveis para rodar o sistema de ponta a ponta. O que foi validado aqui:

  • Backend: sintaxe de 100% dos arquivos Python (python -m py_compile), mais um teste isolado da lógica de parsing do collector (parsing do formato Prometheus + cálculo de CPU/RAM/disco).
  • Frontend: sintaxe de 100% dos arquivos TypeScript/TSX (via ts.transpileModule, que não depende dos pacotes instalados) — mas isso não verifica tipos nem imports quebrados. Rode npm install && npm run build no seu ambiente para pegar qualquer erro de tipo antes de ir para produção.

Recomendo seguir o passo a passo acima e me avisar se algo der erro — ajusto rapidamente.

origin/master