`/srv/status` retorna OK mesmo se o banco de dados estiver quebrado

Dev
1

Hoje de manhã, uma atualização em uma instalação com 2 containers deu errado. Ao inicializar um novo container, o banco de dados foi migrado para um estado quebrado (talvez não teria acontecido se eu tivesse usado SKIP_POST_DEPLOYMENT_MIGRATIONS=1, mas isso é outro problema), de modo que o container em execução exibiu a mensagem “ops, este site está quebrado”.

Isso é esperado, mas meu monitor está verificando /srv/status e ele retorna alegremente um OK, mesmo quando o Rails está bastante quebrado.

Isso é um bug? Quero realmente que meus monitores saibam se há um problema. Deveria estar consultando algo como /about.json (para sites que não exigem login)?

2

Como exatamente foi quebrado? Você pode ser mais específico? Como era a página inicial?

3

Sim, “ok” significa que o Unicorn está funcionando. Você pode derrubar o Postgres e o Redis e ele ainda dirá “ok”, se eu me lembrar corretamente.

4

Tenho quase certeza de que está correto. Faz sentido, só não é o que eu pensava.

5

Não tenho certeza sobre o status disso @sam @eviltrout? Lembro vagamente de uma discussão sobre isso no passado.

6

Sim, não verifica o Redis ou o PG. Acho que usamos um plugin que faz User.find(1) e uma $redis.get em vez disso. Isso ainda não captura o caso do @pfaffman, mas isso pode ser um pouco demais; não se pode esperar que isso faça uma verificação completa de consistência do banco de dados.
discourse/app/controllers/forums_controller.rb at main · discourse/discourse · GitHub

7

O endpoint /srv/status verifica apenas o processo local, não qualquer dependência. “A pilha HTTP está travada?” e “estou em modo de pato manco?”. Na terminologia do Kubernetes, isso é o livenessProbe, não o readinessProbe.

Se quisermos introduzir um readinessProbe, ele deve estar em uma URL diferente.

Provavelmente Discourse.system_user.id em vez de 1.