今天早上，我在一个双容器部署的升级过程中遇到了问题。新容器的引导过程将数据库迁移到了损坏状态（如果我使用了 SKIP_POST_DEPLOYMENT_MIGRATIONS=1 或许就不会发生这种情况，但那是另一个问题），导致运行中的容器显示了“哎呀，此站点已损坏”的错误信息。
这种情况本就在预期之中，但我的监控工具正在检查 /srv/status，即使 Rails 已经严重损坏，它仍然愉快地返回了 OK 状态。
这是一个 bug 吗？我真的很希望监控工具能在出现问题时及时告警。我是否应该改为检查其他端点，例如 /about.json（针对无需登录的站点）？
具体是哪里出了问题？能更详细一点吗？首页看起来是什么样的？
没错，“ok”表示“unicorn 正在运行”。如果你记得没错的话，即使把 Postgres 和 Redis 停掉，它仍然会显示“ok”。
我相当确定那是正确的。这很合理，只是和我想的不一样。
我不确定这个的当前状态如何 @sam @eviltrout？我隐约记得过去曾讨论过这个问题。
没错，它不会检查 Redis 或 PostgreSQL。我想我们使用的是一个插件，它会执行 User.find(1) 和 $redis.get。但这仍然无法覆盖 @pfaffman 遇到的情况，不过这可能要求过高了，不能指望它能进行完整的数据库一致性检查。
discourse/app/controllers/forums_controller.rb at main · discourse/discourse · GitHub
/srv/status 端点仅检查本地进程，不检查任何依赖项。即“HTTP 栈是否卡死？”以及“我是否处于跛行模式？”。在 Kubernetes 术语中，这是 livenessProbe，而非 readinessProbe。
如果我们想引入 readinessProbe，它应该位于不同的 URL。
可能应该是 Discourse.system_user.id 而不是 1。