Eri*_*ach 6 azure azure-web-app-service asp.net-core
我们在运行 .NET Core 3.1 的 Azure 应用服务上看到此错误。看起来当 Azure 更新服务器场时,我们的实例会重新启动并尝试同时重新启动所有应用程序服务。我们确实在 1 个实例上运行了很多服务,因为它是一个 DEV/QA 实例。实例有足够的资源用于正常操作,但看起来当所有东西同时重新启动时需要更多时间。
问题是应用程序服务无法从中恢复,因此我们的服务只有在我们手动重新启动应用程序时才会重新开始工作。
他们在这里提到了错误:https : //docs.microsoft.com/en-us/aspnet/core/test/troubleshoot-azure-iis?view=aspnetcore-3.1# :~: text=500.37%20ANCM%20Failed%20to %20Start%20Within%20Startup%20Time%20Limit&text=By%20default%2C%20the%20timeout%20is,startup%20process%20of%20multiple%20apps。
但是这里的指导是“错开多个应用程序的启动过程。”,但是在更新服务场时,我认为我们没有这种能力对吗?这似乎在这里得到证实:https : //twitter.com/martincetkovsky/status/1231160330488774657?lang=en
基于此:https : //docs.microsoft.com/en-us/aspnet/core/host-and-deploy/aspnet-core-module?view=aspnetcore-3.1#attributes-of-the-aspnetcore-element
startupTimeLimit
模块等待可执行文件启动侦听端口的进程的持续时间(以秒为单位)。如果超过此时间限制,模块将终止该进程。模块在收到新请求时尝试重新启动进程,并继续尝试在后续传入请求上重新启动进程,除非应用程序在最后滚动分钟内未能启动 RapidFailsPerMinute 次数。
这意味着应用程序至少会在 1 分钟后重试,但对我们来说似乎并非如此。这可能是我们最后的错误配置吗?
我可以在更新后收到其中一些错误(毕竟它是 DEV/QA),但如果它没有恢复,那就是一个问题。在 prod 中我们不应该看到这一点,因为我们有更多可用资源,但自动恢复也很重要。
我怎样才能确保我们的服务不会陷入这种状态?除了拥有过大的服务器群(以及相关的成本)?
根据微软的建议,我继续在我们的网络应用程序上设置 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"
}
}
Run Code Online (Sandbox Code Playgroud)
此更改的部署仍在我们的环境中进行,因此我尚未完全验证这是否完全解决了问题,但似乎很有希望。
| 归档时间: |
|
| 查看次数: |
1482 次 |
| 最近记录: |