Detalhe do registo

ID

Data/hora

Utilizador

IP

Ação

Entidade

ID entidade

Descrição


      
      

      
        
      
    

Exportar

Novo domínio (lote de subdomínios)

Cria várias entradas (modelo em Personalização) com o mesmo IP interno. Ex.: eve, img, … sobre o domínio pai.

Com HTTPS activo, o painel emite um certificado Let's Encrypt (SAN) para todos os hostnames do lote; o nome na pasta live/ será san-… (não use o campo abaixo salvo saiba o que faz).

Remover certificado Let's Encrypt

Apenas super-admin. Isto executa certbot delete no servidor. Confirme com a sua palavra-passe.

Entrada

Para emitir um certificado: DNS do hostname deve apontar para este servidor. O e-mail pode vir de Personalização, de CERTBOT_EMAIL no .env ou do campo abaixo.

Certificado no servidor

Saída de openssl x509 -noout -text sobre o fullchain.pem. Inclui Subject, datas de validade e Subject Alternative Name (SAN), ou seja, os nomes cobertos por este ficheiro.


      
        
      
    

Certificado Let's Encrypt

Utilizador

Alterar senha

Requisitos: 8+ caracteres, maiúscula, minúscula, número e símbolo.

Como interpretar as métricas

Resumo dos campos do cartão Access log — falhas e latência e dos critérios Bom / Aceitável / Ruim.

Campos de tempo no log (access-timing.log)

rt (request time)
Tempo total do pedido no Nginx: desde receber o pedido do cliente até enviar a resposta completa. É o que o utilizador “sente”.
urt (upstream response time)
Tempo que o backend (MediaMTX, Next.js, etc.) demorou a responder.
uct / uht
Tempo para ligar ao upstream e tempo até ao primeiro byte do upstream.
us
Código HTTP devolvido pelo upstream (ex.: 200, 500, 504).

Se rt ≈ urt, o atraso está quase todo no backend, não no proxy.

p50, p95 e média

Ordenam-se todos os rt da amostra e escolhe-se um ponto da fila (percentil):

  • p50 (mediana): metade dos pedidos foi mais rápida; metade, mais lenta. É o tempo “típico”.
  • p95: 95% dos pedidos foram mais rápidos; só os 5% piores ficam acima. Mostra a cauda lenta sem um único pico extremo.
  • Média: soma ÷ quantidade. Um único index.m3u8 a 8 s puxa a média para cima — por isso o cartão usa p50/p95 para serviço e mostra a média bruta à parte.

Três tipos de tráfego

  • Serviço — páginas, login, API (/api/…, /login, etc.). Entra no tom Bom/Ruim e nas linhas “latência serviço”.
  • HLS — playlists e segmentos (.m3u8, .ts, .mp4…). Volume alto e timeouts de 8 s em câmaras mortas; fica no HLS top 10, fora da latência de serviço.
  • Probe — health checks automáticos, não utilizadores reais:
    • Blackbox — Prometheus Blackbox Exporter
    • Kuma — Uptime Kuma
    • LT-SYS — monitor de câmaras (User-Agent node)

Falhas 5xx

  • 5xx (serviço) — erros de browsers ou apps reais. Contam para o tom Ruim/Aceitável. A lista por host indica quem puxa o número.
  • 5xx de probe — Blackbox/Kuma/LT-SYS a bater em backends em baixo. Aparecem separados (Aceitável): não significam que o Nginx esteja lento.
  • 502 / 503 / 504 (serviço) — gateway/upstream indisponível ou timeout. Só pedidos de serviço; a lista mostra o host e a mistura de códigos.

Critérios de cor (latência de serviço)

  • Bom — p50/p95 < 400 ms
  • Aceitável — 400–750 ms
  • Ruim — ≥ 750 ms, ou muitos 5xx de serviço

Latência bruta (incl. HLS) inclui streams e probes — útil para diagnóstico, não para julgar a experiência do site.

HLS top 10 (pendurados)

Playlists/segmentos com rt ≥ 2,5 s ou 504 na amostra. Típico de MediaMTX a segurar index.m3u8 até ao timeout de 8 s. Mostra host, código da câmara, se veio de probe ou browser.

Amostra

Últimas ~4000 linhas de access.log (5xx) e access-timing.log (latência). Atualização ~2 s; leitura em cache ~8 s para não sobrecarregar o disco.