`/srv/status` renvoie OK même si la base de données est cassée

Dev
1

Cette matinée, une mise à niveau sur une installation à deux conteneurs a mal tourné. Le démarrage d’un nouveau conteneur a migré la base de données vers un état cassé (peut-être pas si j’avais utilisé SKIP_POST_DEPLOYMENT_MIGRATIONS=1, mais c’est un autre problème), si bien que le conteneur en cours d’exécution a affiché le message « oups, ce site est cassé ».

Cela est attendu, mais mon moniteur vérifie /srv/status et il renvoie joyeusement un OK même lorsque Rails est assez cassé.

Est-ce un bug ? Je veux vraiment que mes moniteurs sachent s’il y a un problème. Devrais-je plutôt interroger autre chose comme /about.json (pour les sites qui ne nécessitent pas de connexion) ?

1 « J'aime »
2

Comment exactement était-ce cassé ? Pouvez-vous être plus précis ? À quoi ressemblait la page d’accueil ?

3

Oui, « ok » signifie que le service fonctionne. Vous pouvez arrêter Postgres et Redis, et il affichera toujours « ok », si ma mémoire est bonne.

3 « J'aime »
4

Je suis assez certain que c’est correct. Cela a du sens, c’est juste que ce n’est pas ce que je pensais.

1 « J'aime »
5

Je ne suis pas sûr de l’état actuel de cette question @sam @eviltrout ? Je me souviens vaguement d’une discussion à ce sujet par le passé.

1 « J'aime »
6

Oui, cela ne vérifie pas Redis ni PostgreSQL. Je pense que nous utilisons un plugin qui effectue User.find(1) et un $redis.get à la place. Cela ne couvre toujours pas le cas de @pfaffman, mais cela pourrait être un peu trop ; on ne peut pas s’attendre à ce que cela réalise une vérification complète de la cohérence de la base de données.
discourse/app/controllers/forums_controller.rb at main · discourse/discourse · GitHub

2 « J'aime »
7

Le point de terminaison /srv/status vérifie uniquement le processus local, et non les dépendances. « Le stack HTTP est-il bloqué ? » et « suis-je en mode canard boiteux ? ». Dans la terminologie Kubernetes, il s’agit de la livenessProbe, et non de la readinessProbe.

Si nous souhaitons introduire une readinessProbe, elle doit être située à une URL différente.

Il s’agit probablement de Discourse.system_user.id plutôt que de 1.

5 « J'aime »