今朝、2コンテナ構成のアップグレードがうまくいかなくなりました。新しいコンテナのブートストラップ中にデータベースが破損した状態に移行されてしまいました（SKIP_POST_DEPLOYMENT_MIGRATIONS=1 を使っていれば回避できたかもしれませんが、それはまた別の問題として）。その結果、稼働中のコンテナが「おっと、このサイトが破損しています」というメッセージを表示してしまいました。
これは想定内のことですが、私の監視システムが /srv/status をチェックしているところ、Rails がかなり破損していても問題なく OK を返してしまいます。
これはバグでしょうか？監視システムに問題があることを確実に通知したいのですが、ログインが不要なサイトの場合、代わりに /about.json などをチェックするべきでしょうか？
具体的にどのように不具合が発生しましたか？もっと詳しく教えてください。ホームページの表示はどのようでしたか？
「ok」は「Unicorn が動作中」を意味します。Postgres と Redis を停止しても、私の記憶が正しければ、まだ「ok」と表示されます。
それは間違いなく正しいと思います。理にかなっていますし、ただ私が思っていたこととは違うだけです。
@sam @eviltrout、この件は現在どのような状況でしょうか？以前、この話題について少し議論したことをぼんやりと覚えています。
はい、Redis や PG のチェックは行っていません。おそらく、User.find(1) と $redis.get を実行するプラグインを使用しているのだと思います。それでも @pfaffman さんのケースは検出できませんが、それは少しやりすぎかもしれません。これで完全なデータベース整合性チェックを行うことは期待できません。
discourse/app/controllers/forums_controller.rb at main · discourse/discourse · GitHub
/srv/status エンドポイントは、依存関係ではなくローカルプロセスのみをチェックします。「HTTP スタックがフリーズしているか？」と「私はレームダック状態か？」という点です。Kubernetes の用語では、これは readinessProbe ではなく livenessProbe です。
readinessProbe を導入したい場合、それは別の URL に配置する必要があります。
おそらく 1 ではなく Discourse.system_user.id です。