`/srv/status` возвращает OK, даже если база данных повреждена

Разработка
1

Сегодня утром обновление на установке с двумя контейнерами пошло не по плану. При инициализации нового контейнера база данных была перенесена в нерабочее состояние (возможно, этого удалось бы избежать, если бы я использовал SKIP_POST_DEPLOYMENT_MIGRATIONS=1, но это уже другая история), из-за чего работающий контейнер выдавал сообщение «ой, сайт сломан».

Само по себе это ожидаемо, но мой монитор проверяет /srv/status, и он спокойно возвращает OK, даже когда Rails работает с серьёзными сбоями.

Это баг? Мне очень важно, чтобы мои мониторы знали о проблемах. Может, мне стоит проверять что-то другое, например /about.json (для сайтов, не требующих авторизации)?

2

Как именно оно сломалось? Можете быть более конкретным? Как выглядела главная страница?

3

Да, «ok» означает, что «Unicorn работает». Если я не ошибаюсь, можно остановить Postgres и Redis, и статус всё равно будет «ok».

4

Я вполне уверен, что это правильно. Это логично, просто это не то, что я ожидал.

5

Я не уверен, какой сейчас статус у этого вопроса @sam @eviltrout? Я смутно помню, что мы обсуждали это раньше.

6

Да, проверка Redis или PG не выполняется. Я думаю, мы используем плагин, который делает User.find(1) и $redis.get вместо этого. Это всё равно не покрывает случай @pfaffman, но это может быть уже слишком много — нельзя ожидать, что это обеспечит полную проверку согласованности базы данных.
discourse/app/controllers/forums_controller.rb at main · discourse/discourse · GitHub

7

Эндпоинт /srv/status проверяет только локальный процесс, а не зависимости. «Застрял ли HTTP-стек?» и «нахожусь ли я в режиме утихания?». В терминологии Kubernetes это livenessProbe, а не readinessProbe.

Если мы хотим внедрить readinessProbe, он должен находиться по другому URL.

Скорее всего, Discourse.system_user.id вместо 1.