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 « J'aime »
This exists, see
/srv/status
15 « J'aime »
Ah, thank you! I was searching “health check” and that didn’t yield any results.
2 « J'aime »
Le message est 404. Quelles sont les points de terminaison ?
J’ai mis à jour mon message.
2 « J'aime »
En fait, je ne pense pas que /srv/status puisse détecter des problèmes de migration comme celui mentionné ci-dessus…
(et il serait assez difficile de créer une vérification capable de détecter ce genre de problème)
2 « J'aime »
Oui… /srv/status est présent en tant que test très léger, il ne fait que s’assurer que la pile de middleware de l’application fonctionne.
Pour détecter les problèmes liés au déploiement automatique, je recommande de surveiller les réponses 200. En cas de forte augmentation des réponses autres que 200, déclenchez une alerte.
5 « J'aime »
L’URL https://discourse.example.org/srv/status serait-elle un bon endroit pour diriger un moniteur de disponibilité ? Je pense qu’il pourrait ne pas suffire d’avoir une mesure fiable de « le site est-il en ligne », mais il serait agréable d’avoir quelque chose qui génère moins de charge sur le système à des fins de surveillance.
(Sinon, y aurait-il des projets pour étendre les composants répertoriés sur ce point de terminaison ?)
3 « J'aime »
Oui, c’est un endroit raisonnable. Vous pouvez également pointer vers un sujet spécifique et rechercher du texte si vous souhaitez quelque chose de plus avancé.
7 « J'aime »
Oui, nous utilisions /about, mais nous penchons plutôt pour cette option.
Mon ancienne mentalité d’ops/on-call s’est réveillée pour me faire penser que cela pourrait encore être intéressant (et parfois utile pour le dépannage) si c’était quelque chose comme :
db ok
middleware ok
whatever-else ok
...
all systems ok
4 « J'aime »