azure - 如何处理 Azure 应用服务无法从“Http 错误 500.37 - ANCM 无法在启动时间限制内启动”中恢复
问题描述
我们在使用 .NET Core 3.1 运行的 Azure 应用服务上看到此错误。看起来当 Azure 更新服务器场时,我们的实例会重新启动,并且它会尝试同时重新启动所有应用服务。我们确实有很多服务在 1 个实例上运行,因为它是一个 DEV/QA 实例。该实例有足够的资源进行正常操作,但它看起来在所有东西都同时重新启动时需要更多时间。
问题是应用程序服务无法从中恢复,因此我们的服务只有在我们手动重新启动应用程序时才能重新开始工作。
但这里的指导是“错开多个应用程序的启动过程。”,但在更新服务场时,我认为我们不具备这种能力,对吗?这似乎得到了证实:https ://twitter.com/martincetkovsky/status/1231160330488774657?lang=en
startupTimeLimit
模块等待可执行文件启动侦听端口的进程的持续时间(以秒为单位)。如果超过此时间限制,模块将终止该进程。模块在收到新请求时尝试重新启动进程,并继续尝试在后续传入请求上重新启动进程,除非应用程序在最后滚动分钟内无法启动 rapidFailsPerMinute 次数。
这意味着应用程序将至少在 1 分钟后重试,但对我们来说似乎并非如此。这可能是我们端的错误配置吗?
我可以在更新后得到其中的一些错误(毕竟它是 DEV/QA),但如果它没有恢复,那就是一个问题。在 prod 中我们不应该看到这一点,因为我们有更多可用资源,而且自动恢复也很重要。
如何确保我们的服务不会陷入这种状态?除了拥有过大的服务器场(以及相关成本)之外?
解决方案
根据 Microsoft 的建议,我继续在我们的 Web 应用程序上设置 AutoHeal。
这是我正在使用的 ARM 模板摘录:
"autoHealEnabled": true,
"autoHealRules": {
"triggers": {
"privateBytesInKB": 0,
"statusCodes": [
{
"status": 500,
"subStatus": 37, //Startup time limit 120000 in DEV and QA
"win32Status": 0,
"count": 1,
"timeInterval": "00:01:00"
}
]
},
"actions": {
"actionType": "Recycle",
"minProcessExecutionTime": "00:00:00"
}
}
此更改的部署仍在我们的环境中进行,因此我尚未完全验证这是否可以完全解决问题,但似乎很有希望。
推荐阅读
- c - AUGraphStart 延迟,取决于睡眠
- android - 位置管理器没有一致地返回位置
- r - 计算双峰分布的 2 种模式的半峰全宽 (FWHM)
- windows - 后台下载器,UWP Windows10无法启动下载操作?
- git - Gitversion - 标签前缀的作用
- java - 在图像单击时打开地图位置,但某些具有 Google Map 的设备无法打开意图
- gremlin - 匿名遍历 vs 普通遍历 gremlin
- firebase - 在 GA 中克服 Firebase 限制
- google-sheets - 如何在 Google 表格中保存由 GoogleFinance() API 返回的单元格值
- python-3.x - 如何使用 Python 将列转换为行