Health Checks & Monitoramento

Dois endpoints de saúde não autenticados existem para monitores, mais um dashboard de saúde de admin dentro do app. Esta página explica o que eles reportam e como conectá-los ao monitoramento.

GET /health, o check completo

O endpoint de saúde da própria instância não é apenas um ping, ele executa um conjunto de checagens e reporta os resultados individualmente:

• Acessibilidade do banco de dados (crítico), o caso majoritário da resposta “ruim” do endpoint.
• Sanidade do motor de templates (uma compilação rápida de um template de teste).
• Memória: o RSS do processo é lido no Linux, comparado contra um limiar de 512 MiB (aviso informativo quando acima).
• Checagens adicionais cobrem o ambiente do script de build/saída; cada checagem carrega seu próprio status, detalhe, severidade (critical/warning/info) e latência medida.

A resposta de topo reporta status como critical se qualquer checagem crítica falhou, warning se apenas avisos dispararam, caso contrário ok, mais um timestamp em UTC, o número de checagens, a lista por checagem e um array de warnings. Um monitor de uptime pode ler apenas o campo status; um engenheiro de plantão recebe a lista de checagens em vez disso.

GET /api/health , o resumo de nível de site

Amigável a monitores de máquina: status (ok ou um estado de aviso se o site tem conteúdo mas nunca teve build), contagem de páginas publicadas, timestamp do último build, e se um build está em andamento. Conecte este aos checkers externos de uptime.

O monitor cron de builds

O repositório embarca um script cron pronto (bin/cron-build-monitor.sh) desenhado para executar a cada 5 minutos: ele monitora que builds completem com sucesso e que páginas existam na árvore de saída (aponta para o diretório de saída da instância via a variável de ambiente CHINASKI_OUTPUT). Agende-o diretamente do crontab ou use-o como template para o seu próprio monitor.

O pedido do checklist de produção

O checklist de go-live do README pede exatamente esta ligação: monitore o endpoint de saúde (/health alcançável a partir do seu monitor; 503 quando o banco de dados está inacessível), verifique que os backups executam no agendamento (systemctl list-timers chinaski-backup@<N> mostra um NEXT), e fique de olho nos logs baseados no journal após mudanças.