`/srv/status` devuelve OK incluso si la base de datos está rota

Desarrollador
1

Hoy por la mañana, una actualización en una instalación de 2 contenedores salió mal. Al crear un nuevo contenedor, la base de datos se migró a un estado roto (quizás no habría ocurrido si hubiera usado SKIP_POST_DEPLOYMENT_MIGRATIONS=1, pero ese es otro problema), de modo que el contenedor en ejecución mostró el mensaje «ups, este sitio está roto».

Esto es lo esperado, pero mi monitor verifica /srv/status y devuelve tranquilamente un OK incluso cuando Rails está bastante roto.

¿Es esto un error? Realmente quiero que mis monitores sepan si hay un problema; ¿debería consultar en su lugar algo como /about.json (para sitios que no requieren inicio de sesión)?

1 me gusta
2

¿Cómo exactamente se rompió? ¿Puedes ser más específico? ¿Cómo se veía la página de inicio?

3

Sí, ‘ok’ significa que el unicornio está funcionando. Puedes detener Postgres y Redis y aún así seguirá diciendo ‘ok’, si recuerdo bien.

3 Me gusta
4

Estoy bastante seguro de que eso es correcto. Tiene sentido, simplemente no es lo que yo pensaba.

1 me gusta
5

No estoy seguro de cuál es el estado de esto @sam @eviltrout. Vaguemente recuerdo que se habló de esto en el pasado.

1 me gusta
6

Sí, no verifica Redis ni PostgreSQL. Creo que usamos un plugin que hace User.find(1) y $redis.get en su lugar. Eso aún no cubre el caso de @pfaffman, pero quizás sea demasiado; no se puede esperar que esto realice una verificación completa de consistencia de la base de datos.
discourse/app/controllers/forums_controller.rb at main · discourse/discourse · GitHub

2 Me gusta
7

El endpoint /srv/status verifica solo el proceso local, no las dependencias. ¿Está el stack HTTP bloqueado? ¿Estoy en modo de pato cojo? En la terminología de Kubernetes, esto es el livenessProbe, no el readinessProbe.

Si queremos introducir un readinessProbe, debería estar en una URL diferente.

Probablemente Discourse.system_user.id en lugar de 1.

5 Me gusta