It would be nice to have some sort of health check API. We recently faced an issue with an update and Discourse was producing 500 errors.
However, curl returned 200:
curl -I https://forum.gitlab.com
HTTP/2 200
server: nginx
2 curtidas
This exists, see
/srv/status
15 curtidas
Ah, thank you! I was searching “health check” and that didn’t yield any results.
2 curtidas
Post não encontrado (404). Quais são os endpoints?
Atualizei minha postagem.
2 curtidas
Na verdade, não acho que /srv/status capturaria problemas de migração como o mencionado acima…
(e seria bastante difícil criar uma verificação que capture problemas como esse)
2 curtidas
Sim… /srv/status está lá como um teste muito simples; tudo o que ele faz é garantir que a pilha de middleware do aplicativo esteja funcionando.
Para detectar problemas em implantações automáticas, recomendo monitorar os códigos 200; se houver um aumento significativo em códigos diferentes de 200, configure um alerta.
5 curtidas
Seria https://discourse.example.org/srv/status um bom local para apontar um monitor de disponibilidade? Estou pensando que pode não ser suficiente ter uma medida confiável de “se o site está no ar”, mas seria bom ter algo que gere menos carga no sistema para fins de monitoramento.
(Alternativamente, haveria algum plano para expandir os componentes listados neste endpoint?)
3 curtidas
Sim, esse é um ponto razoável. Você também pode apontar para um tópico específico e pesquisar por texto, se quiser algo mais avançado.
7 curtidas
Sim, estávamos usando /about, mas inclinados a usar isso aqui em vez disso.
Minha antiga mente de ops/on-call despertou e me fez pensar que poderia ser interessante (e às vezes útil para solução de problemas) se fosse algo como:
db ok
middleware ok
qualquer-coisa-outra ok
...
todos os sistemas ok
4 curtidas