Azure App Service上的AspNet Core达到100%的CPU峰值并且App Gateway负载均衡器不起作用

时间:2018-07-16 19:56:31

标签: azure asp.net-core garbage-collection azure-web-sites azure-application-gateway

我们很少有内部业务服务托管在Azure中的隔离ASE上。
这些服务在具有2个实例的中型应用程序服务计划上运行。
这种环境已经投入生产和使用了不到一个月,并且在偶尔导致CPU突然中断达到100%的情况(除了其中之一)导致服务中断的情况下,运行良好。
我们没有自动缩放设置,但是一直有2个实例在运行。

服务是`aspnetcore` webapi,运行时是dotnet core 2.0。
在过去几周中,每次遇到此问题时,我都没有足够的幸运地登录kudu并获得一个进程转储以进行进一步调查。从根本上说,企业要让服务尽快启动并运行,而最简单的方法是用预先生产的环境重新启动故障服务之一或交换插槽。

我们的网络也限制了对ASE的访问,这使我更难切换到WiFi,然后通过跳转框登录到kudu,我曾要求我们的Ops工程师在发生以下情况时让我转储已报告此问题,但他也没有听我讲话,主要是出于与我自己无法做到这一点相同的原因。

我在Application Insights中看到的所有异常都是由于服务本身崩溃而导致的,没有任何异常可以首先导致该问题(至少我还没有发现)

这使我几乎不去猜测并寻找指标,这是唯一引起我注意的事情 怀疑是垃圾收集。我也没有看到GC图表中突然出现峰值,每次重新启动服务时,该图表都是一条直线(24小时),但是每天都在增加,最终如下图所示。

但是工作内存是一个正弦图,让我认为没有内存泄漏。但是,以上图表在3天内正常吗?
当我重新启动该服务时,该消息就会消失。但是所有服务都具有相似的轨迹,即使没有下降。
我不确定这是否是我忽略的单个服务或环境配置的问题。

API端点是简单的CRUD操作,并且在每个操作之后将事件发布到服务总线主题。有一个静态的“ HttpClient”实例,用于从另一个服务中获取数据。除此之外,没有任何非托管资源,并且数据库连接始终包装在“ using”语句中。

我知道我需要一个进程转储来进行进一步调查,但我最大的担心是为什么应用程序网关(负载均衡器)不向正常实例发送流量。由于网关运行不正常,cloudflare使用api向客户端返回了“ 502”响应。 如果我们的负载均衡器正常工作,MS支持部门将无法提供帮助并且没有答案。 平均请求数约为每分钟50-60。 突然之间,CPU的运行速度相差不到10%。

谢谢

enter image description here

1 个答案:

答案 0 :(得分:0)

可能后端固定在100%CPU上,无法响应Application Gateway运行状况探测。发生此类问题时,您是否能够使用后端运行状况日志验证后端的运行状况?如果两个后端实例都不正常,则可以解释502。如果其中一个运行状况良好并响应探测,则发送到Application Gateway的新请求实际上将流向运行状况良好的实例。如果您怀疑不是这种情况,请回复订阅ID,网关名称和事件的大致时间窗口,以供我们查看。