`/srv/status` restituisce OK anche se il database è rotto

Sviluppatore
1

Questa mattina un aggiornamento su un’installazione a 2 container è andato storto. L’avvio di un nuovo container ha migrato il database in uno stato danneggiato (forse non sarebbe successo se avessi usato SKIP_POST_DEPLOYMENT_MIGRATIONS=1, ma questa è un’altra questione), cosicché il container in esecuzione ha mostrato il messaggio “oops, questo sito è rotto”.

Questo aspetto è previsto, ma il mio monitor controlla /srv/status e restituisce tranquillamente un OK anche quando Rails è piuttosto compromesso.

È un bug? Vorrei davvero che i miei monitor sapessero se c’è un problema; dovrei invece controllare qualcos’altro, come /about.json (per i siti che non richiedono il login)?

2

In che modo esattamente era rotto? Puoi essere più specifico? Com’era la homepage?

3

Sì, “ok” significa che il “unicorno” sta funzionando. Se ricordo bene, puoi spegnere Postgres e Redis e continuerà a dire “ok”.

4

Sono abbastanza sicuro che sia corretto. Ha senso, è solo che non era quello che pensavo.

5

Non sono sicuro di quale sia lo stato di questa cosa @sam @eviltrout? Ricordo vagamente una discussione al riguardo in passato.

6

Sì, non controlla Redis o PG. Penso che usiamo un plugin che esegue User.find(1) e $redis.get al posto di ciò. Questo non rileva comunque il caso di @pfaffman, ma potrebbe essere un po’ eccessivo: non ci si può aspettare che effettui un controllo completo della coerenza del database.
discourse/app/controllers/forums_controller.rb at main · discourse/discourse · GitHub

7

Il endpoint /srv/status controlla solo il processo locale, non le dipendenze. “Lo stack HTTP è bloccato?”, più “sono in fase di dismissione?”. Nella terminologia di Kubernetes, questo è il livenessProbe, non il readinessProbe.

Se vogliamo introdurre un readinessProbe, dovrebbe risiedere su un URL diverso.

Probabilmente Discourse.system_user.id invece di 1.