Ir para o conteúdo

MonitorOPS — Runbooks e solução de falhas

Guia passo a passo para operação do MonitorOPS (porta 9090) e resolução dos problemas mais comuns do stack.

MonitorOPS ≠ MonitorCTI (Portal /cti/, API :8090).

Acesso rápido

Item Valor
URL http://IP_DA_VPS:9090/
Health http://IP_DA_VPS:9090/health
Credenciais .env → MONITOR_ADMIN_USER / MONITOR_ADMIN_PASSWORD

Painéis do dashboard

Painel Função
Visão Geral Status containers, recursos VPS, ligar/desligar stack e serviços
Diagnóstico Verificação automática (containers, portas, SQL, AMI)
Logs Últimas linhas de log por container
Ferramentas Scripts admin (validação, bootstrap SQL, fix Issabel, etc.)
Ajuda / Runbooks Passo a passo interativo para cada falha conhecida

Runbook 1 — Issabel PBX unhealthy

Sintomas

  • Container issabel-prod com health unhealthy
  • Portas 443, 5038 ou 5060 fechadas
  • Log: call center schema dump not found

Causa

Firstboot do Issabel falha no módulo Call Center (incompatível com Asterisk 18).

Passo a passo

  1. SSH na VPS: 
    cd ~/omnichannel/lorentz-vps-stack
  2. Execute o fix (ou use Ferramentas → Corrigir Issabel no monitor): 
    ./scripts/fix-issabel-firstboot.sh
  3. Aguarde 2–5 minutos e verifique: 
    docker ps --filter name=issabel
curl -sk -o /dev/null -w '%{http_code}\n' https://127.0.0.1/
    Esperado: status healthy e HTTP 200.
  4. No monitor, atualize a página — Issabel deve aparecer healthy.

Runbook 2 — LorentzCTI sem eventos AMI

Sintomas

  • CTI running mas sem FullyBooted nos logs
  • Porta 5038 não responde
  • Log: Authentication failed

Causa

AMI não configurado ou secret incorreto no LorentzCTI.ini.

Passo a passo

  1. Confirme Issabel healthy e porta 5038 aberta no host.
  2. No Issabel: PBX → Ferramentas → Asterisk Manager Users — usuário admin.
  3. Senha AMI = LORENTZ_CTI_AMI_SECRET no .env (padrão amp111).
  4. Regenerar config: 
    cd ~/omnichannel/lorentz-vps-stack
./scripts/render-config.sh
docker compose restart lorentz-cti
  5. Verifique logs: 
    docker logs lorentz-cti 2>&1 | tail -30

Runbook 3 — Tabelas SQL ausentes

Sintomas

  • Erro Invalid object name CTI_ATENDIMENTO
  • Login Supervisor falha ou tabelas SAC_* ausentes
  • Diagnóstico alerta bootstrap SQL

Causa

Schema LorentzCTI não aplicado após primeiro deploy.

Passo a passo

Opção A — pelo monitor: Ferramentas → Bootstrap SQL → aguardar conclusão.

Opção B — manual:

cd ~/omnichannel/lorentz-vps-stack
docker cp docker/sqlserver/init/01-bootstrap-homolog.sql lorentz-sqlserver:/tmp/
docker cp docker/sqlserver/init/02-cti-core-tables.sql lorentz-sqlserver:/tmp/
docker exec lorentz-sqlserver /opt/mssql-tools18/bin/sqlcmd \
  -S localhost -U sa -P 'SENHA_SA' -C -i /tmp/01-bootstrap-homolog.sql
docker exec lorentz-sqlserver /opt/mssql-tools18/bin/sqlcmd \
  -S localhost -U sa -P 'SENHA_SA' -C -i /tmp/02-cti-core-tables.sql

Para schema completo de produção, restaure o .bak do cliente — ver 05 — SQL Server.

Runbook 4 — Supervisor inacessível externamente

Sintomas

  • HTTP 200 local mas timeout de fora
  • validate-install.sh --external falha na porta 8080

Causa

Security Group AWS ou firewall bloqueando TCP 8080.

Passo a passo

  1. AWS: EC2 → Security Groups → Inbound → adicionar TCP 8080 (restrito ao IP da equipe).
  2. Ou script: 
    ./scripts/open-aws-port-8080.sh SEU_IP/32
  3. Teste: 
    curl -I http://IP_PUBLICO:8080/login.php

Runbook 5 — MonitorOPS inacessível (9090)

Sintomas

  • Dashboard não abre de fora da VPS
  • curl timeout em IP:9090

Causa

Porta 9090 não liberada no Security Group.

Passo a passo

  1. Libere TCP 9090 restrito ao IP da equipe: 
    ./scripts/open-aws-port-9090.sh SEU_IP/32
  2. Confirme container: 
    docker compose ps monitor
curl http://127.0.0.1:9090/health

Runbook 6 — Disco cheio na VPS

Sintomas

  • Recursos VPS critical no monitor
  • Docker não inicia, serviços param
  • SSH lento

Causa

ISO Issabel, imagens Docker ou logs consumindo disco.

Passo a passo

  1. Diagnóstico: 
    df -h /
du -xh /var/lib/docker | sort -h | tail -10
  2. Limpar journal: 
    sudo journalctl --vacuum-size=200M
  3. Prune Docker (cuidado — remove imagens não usadas): 
    docker system prune -af
    Ou use Ferramentas → Limpar Docker no monitor (prune -f apenas).
  4. Remova ISO antiga se build Issabel já concluiu.
  5. Considere aumentar volume EBS na AWS.

Runbook 7 — CTI Authentication failed (INI)

Sintomas

  • Log lorentz-cti: Authentication failed
  • Secret em texto plano no INI

Causa

LorentzCTI.ini gerado sem criptografia ou encoding errado.

Passo a passo

cd ~/omnichannel/lorentz-vps-stack
./scripts/render-config.sh
grep '^Secret=' config/runtime/LorentzCTI.ini
docker compose restart lorentz-cti

O campo Secret não deve ser amp111 em texto puro.

Runbook 8 — Base Histórica (LorentzDB.Worker) indisponível

Sintomas

  • Container lorentz-basehistorica com status diferente de running
  • Supervisor retorna erro ao consultar a API de Base Histórica
  • Health check http://127.0.0.1:8091/health falhando

Causa

O worker LorentzDB.Worker (.NET 9, "Montar Base Histórica") não subiu — erro de conexão com o SQL Server, LORENTZ_BASEHISTORICA_API_KEY ausente no .env ou build desatualizado.

Passo a passo

  1. Verifique logs: 
    docker logs lorentz-basehistorica --tail 50
  2. Confirme LORENTZ_BASEHISTORICA_API_KEY definido no .env.
  3. Confirme que o sqlserver está healthy (o worker depende dele): 
    docker compose ps sqlserver
  4. Teste local (dentro da VPS): 
    curl -fsS http://127.0.0.1:8091/health
  5. Reinicie: 
    docker compose restart lorentz-basehistorica

A porta 8091 tem bind local (127.0.0.1) por design — só o Supervisor deve acessá-la. Por isso ela não aparece no teste de portas do painel Diagnóstico (mesmo padrão do sqlserver/1433); o status do container é a fonte de verdade nesse caso.

Ferramentas admin (painel)

Botão Script equivalente Uso
Validação validate-install.sh Checagem pós-deploy
Bootstrap SQL sqlcmd 01 + 02 Primeira instalação
Corrigir Issabel fix-issabel-firstboot.sh Call Center / Asterisk 18
Render config render-config.sh Regenera INI e att_config.php
Limpar Docker docker system prune -f Libera espaço (seguro)

Após atualizar o monitor

Sync do lab para a VPS e rebuild:

# No lab (Windows/Linux com chave SSH)
./scripts/sync-stack-to-vps.sh

# Na VPS
cd ~/omnichannel/lorentz-vps-stack
docker compose up -d --build monitor

Referências