我有一个运行两个节点的应用服务，但与我拥有的其他服务不同，它最终只保持一个节点运行。为了让两个节点再次运行，我不得不扩大规模并缩小规模，这不知何故会“触发”两个节点运行。您可以在下图中看到，一切看起来都很好，直到下午 6 点左右，看起来一个节点死机了，另一个节点启动了。这种情况在 7:10 左右再次发生，到 7:30 时，只有一个节点在处理请求。
尝试诊断这种情况令人抓狂。我为 SignalR 启用了粘性会话（通过 Redis 的背板），但我从其他应用程序知道这应该无关紧要。日志显示新容器正在启动，但我找不到任何可以告诉我为什么之前的容器会死掉的信息。此应用服务计划中还有另一个应用似乎可以一致地分配请求负载，因此我不认为这是 Azure 基础架构的问题。我认为这是我的应用的问题，但我找不到合适的日志记录来提供帮助。
那么问题是，我如何找到一个节点出现故障的原因？
编辑：我不太确定这一定是我的应用程序的问题。我可以深入查看健康检查 UI 并重新启动未获得流量的特定实例，但没有任何变化。
答案1
这是因为我没有阅读手册简而言之，事情的经过如下：
- 健康检查被重定向，因为我的中间件会重定向到除规范目标域之外的任何内容。然而，健康检查却命中了该
*.azurewebistes.net域。 - 健康检查认为任何非 2xx 响应都是不健康的，包括我的 301。
- 系统每天、每小时或其他情况下“不健康”的实例数量是有限制的（文档不清楚）。显然，如果你只剩下一个实例，它不会把它拆除。
- 我之所以能弄清楚这一点，是因为其中一个诊断工具显示了一条 3xx 请求的直线，这肯定是机械的。然后我想起了规范重定向，健康检查是我能想到的唯一与这种节奏有关的东西。
- 我添加了一个不会重定向的端点，仅用于 ping 健康检查，并且两个实例看起来都很健康并且一切正常。
我写详细的博客文章如果你真的觉得无聊的话。