# Guia V9.2 — Monitorização de websites

## 1. Acesso

No backoffice:

```text
Infraestrutura
├── Centro de monitorização
├── Monitores de websites
├── Verificações
└── Incidentes
```

Na área do cliente:

```text
Estado dos websites
```

## 2. Criar um monitor

Antes de criar o monitor, o serviço deve possuir um ativo técnico do tipo **Website**.

Campos principais:

- ativo técnico;
- nome;
- URL HTTP ou HTTPS;
- método GET ou HEAD;
- intervalo;
- timeout;
- códigos HTTP esperados;
- texto que deve existir na página;
- limiar de resposta lenta;
- validação e inspeção SSL;
- número de falhas para abrir incidente;
- número de sucessos para resolver;
- notificações internas e ao cliente;
- visibilidade no portal.

Exemplo de códigos esperados:

```text
200-399
```

ou:

```text
200,204,301,302
```

## 3. Estados

- **Por verificar:** ainda sem resultado.
- **Operacional:** HTTP/conteúdo/SSL válidos e resposta dentro do limiar.
- **Desempenho degradado:** resposta lenta ou SSL próximo da expiração.
- **Indisponível:** falha confirmada após o limiar configurado.
- **Em manutenção:** janela técnica ativa.
- **Pausado:** monitor desligado.

## 4. Incidentes

Um incidente pode ficar:

```text
Aberto → Reconhecido → Resolvido
```

ou ser marcado como ignorado.

Quando abre, o sistema pode:

- criar uma tarefa interna urgente;
- preparar aviso interno;
- preparar aviso para o cliente;
- atualizar o estado do ativo técnico;
- mostrar o incidente no portal do cliente.

Quando o website recupera, o incidente é resolvido automaticamente após o número de sucessos definido.

## 5. Execução manual

No centro de monitorização:

- **Executar monitores vencidos**;
- botão de execução em cada website.

No terminal:

```bash
python manage.py run_website_monitors
python manage.py run_website_monitors --all
python manage.py run_website_monitors --id 3
python manage.py run_website_monitors --limit 20
```

## 6. Automação

Criar ou atualizar a agenda:

```bash
python manage.py setup_monitoring_schedule
```

Processos necessários em produção:

```bash
celery -A config worker -l info
celery -A config beat -l info --scheduler django_celery_beat.schedulers:DatabaseScheduler
```

O Beat chama o despachante a cada minuto. O despachante só executa monitores cuja `next_check_at` já chegou.

## 7. Retenção

Configuração no `.env`:

```env
K4W_MONITOR_HISTORY_DAYS=180
```

A limpeza preserva as verificações ligadas ao início e ao fim de incidentes.

## 8. Segurança

Por defeito, destinos que resolvam para IPs privados, loopback, link-local, multicast ou reservados são bloqueados.

Ativação global, apenas para redes internas autorizadas:

```env
K4W_MONITOR_ALLOW_PRIVATE_NETWORKS=True
```

Também existe uma opção individual no monitor. Não deve ser ativada para URLs fornecidas por utilizadores não confiáveis.

## 9. Configurações adicionais

```env
K4W_MONITOR_USER_AGENT=Kreate4Web-Monitor/9.2
K4W_MONITOR_MAX_BODY_BYTES=1048576
K4W_MONITOR_HISTORY_DAYS=180
K4W_MONITOR_ALLOW_PRIVATE_NETWORKS=False
```

## 10. Área do cliente

O cliente vê apenas monitores:

- associados aos seus serviços;
- marcados como visíveis no portal;
- com incidentes também marcados como visíveis.

Não vê IPs internos, cabeçalhos, detalhes técnicos de erros ou configuração do monitor.