我们在UAT和Prod上有一个分支,BRANCH-X。当我在UAT上部署新分支BRANCH-Y时,CPU利用率达到100%,并在Azure自动修复处于ON状态时重新启动应用程序,这会导致数千个503-Service Unavailable错误。最初我以为我的新更改会导致这种情况,但当我查看代码时,似乎没有任何问题-功能良好,所有异常都得到处理,并且没有应用程序退出。
为了调试代码问题或内部发生的事情,我对BRANCH-X做了一个小的更改并部署在UAT上。变化很小,如下图所示--
分支-X:
return 5;
字符串
UAT上用于调试的新代码:
int x = 5;
return x;
型
现在任何人都会认为新代码会像Branch-X一样工作,没有503。但事实并非如此,新代码自动重启,命中CPU 100%并抛出503。为了确认,我再次部署了BRANCH-X --没有自动重启,没有100%的CPU,也没有503。我不明白为什么任何新的代码更改都会在Azure上给我503。我试着浏览一个好的答案,但没有运气。所以把它贴在这里。
1条答案
按热度按时间ovfsdjhp1#
除了上面的建议之外,如果您还没有这样做,请利用
Diagnose and Solve Problems
获取有关Web App Restarted
的更多详细信息我理解一个简单的代码更改导致重新启动,正如你提到的自动修复启用。
您提到了UAT和Prod上的BRANCH-X和BRANCH-Y(如果是插槽交换)。
要最大限度地减少这些类型的重启,请在所有插槽上设置
WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1
应用程序设置,并查看是否有任何差异。为了隔离问题,您可以尝试使用proactive CPU monitoring设置自己的CPU阈值规则,以暂时缓解高CPU问题(以缩小范围,直到找到问题的真实的原因)
另一方面,重新启动应用程序可能会导致资源消耗增加,并且根据应用程序的不同,有时这些额外资源可能会很高,因此请注意,即使重新启动插槽不应影响其他插槽,但资源仍然是共享的,因此如果应用程序服务计划没有足够的资源,它可能会间接影响其他插槽。
大多数配置更改都会触发某种重新启动。
App Service Restarts-本文档涵盖了可以在App Service中执行的一些常见操作,以及在可用性和重启操作方面的影响。可以手动或通过配置更改来触发App Service上的重新启动。
参考:交换故障排除