omni_health_check.md

Documento de Requisitos Funcionais - Sistema de Health Check

Objetivo

Criar um sistema de monitoramento de serviços similar ao "GitHub Status" para a empresa, permitindo monitoramento de URLs, registro e resolução automática de incidentes, e notificação de contatos associados.

---

Requisitos Funcionais

1. Painel Administrativo (Django Admin)

1.1 Cadastro de Serviços e URLs Monitoradas

• Possibilidade de cadastrar serviços com as seguintes informações:
  • Nome do serviço.
  • Lista de URLs (sub_urls) monitoradas.
• Cada URL deve conter:
  • URL.
  • Tipo de teste (test_type, ex.: Backend, Frontend).
  • Método de requisição (request_type, ex.: GET, POST, PATCH).
  • Intervalo de checagem em segundos (interval).
  • Body da requisição (opcional).

1.2 Cadastro de Contatos para Notificação

• Possibilidade de cadastrar contatos para recebimento de alertas.
• Cada contato deve conter:
  • Nome.
  • Email.
  • Telefone.

2. API de Health Check

• Endpoint: /health-check.
• Retorna a estrutura abaixo:

[
  {
    "service": "nome_do_serviço",
    "sub_urls": [
      {
        "url": "https://exemplo.com",
        "test_type": "Backend",
        "request_type": "GET",
        "interval": 60,
        "status": "UP"
      },
      {
        "url": "https://exemplo2.com",
        "test_type": "Frontend",
        "request_type": "GET",
        "interval": 60,
        "status": "DOWN"
      }
    ]
  }
]

---

3. Registro de Histórico de Incidentes

• Quando uma checagem retorna erro, um registro é criado no histórico de incidentes com a seguinte estrutura:

{
  "id": 1,
  "service_name": "nome_do_serviço",
  "url": "https://exemplo.com",
  "test_type": "Backend",
  "request_type": "GET",
  "status_code": 500,
  "error_message": "Internal Server Error",
  "timestamp": "2024-12-17T12:00:00Z",
  "resolved": false
}

• Campos adicionais:
  • resolved: Indica se o incidente foi resolvido.
  • resolved_timestamp (opcional): Registra a data e hora da resolução, se aplicável.

4. Notificação de Incidentes

• Sempre que um incidente é registrado:
  • Um email é disparado para todos os contatos cadastrados.
  • O email deve conter:
    • Nome do serviço.
    • URL afetada.
    • Tipo de teste.
    • Método de requisição.
    • Código de status.
    • Mensagem de erro.
    • Link para a página de detalhes do incidente no front-end.

---

5. API de Incidentes

• Endpoint: /incidentes.
• Retorna a seguinte estrutura:

[
  {
    "service_name": "nome_do_serviço",
    "url": "https://exemplo.com",
    "test_type": "Backend",
    "request_type": "GET",
    "status_code": 500,
    "error_message": "Internal Server Error",
    "timestamp": "2024-12-17T12:00:00Z",
    "resolved": false
  },
  {
    "service_name": "nome_do_serviço",
    "url": "https://exemplo2.com",
    "test_type": "Frontend",
    "request_type": "GET",
    "status_code": 404,
    "error_message": "Not Found",
    "timestamp": "2024-12-16T15:30:00Z",
    "resolved": true,
    "resolved_timestamp": "2024-12-16T15:45:00Z"
  }
]

6. Tratativa Automática de Incidentes

• Requisitos:
  • Para cada teste periódico de uma URL:
    • Se o teste for bem-sucedido (ex.: status_code=200):
      • Verificar se há incidentes não resolvidos para essa URL.
      • Se houver, marcar o incidente como:
        • resolved=true.
        • Registrar o timestamp de resolução (resolved_timestamp).
    • Se o teste falhar:
      • Registrar um novo incidente apenas se o erro for diferente de erros já registrados (baseado em status_code e error_message).

---

7. Front-End React

7.1 Visualização de Health Checks

• Consumir o endpoint /health-check e exibir:
  • Nome do serviço.
  • Status das URLs monitoradas (UP/DOWN).
  • Tipo de teste e intervalo configurado.

7.2 Visualização de Incidentes

• Consumir o endpoint /incidentes e exibir:
  • Incidentes pendentes e resolvidos.
  • Detalhes de cada incidente, incluindo timestamp e mensagem de erro.
  • Status atual da URL associada ao incidente.