Azure App Service Plan CPU突升至100%问题排查求助

可能的诱因 #

• 同计划内跨应用资源消耗：同一App Service Plan下的其他Web App、函数应用的后台进程、站点扩展（如AI代理、自定义扩展）占用CPU，单个App的监控仅覆盖自身进程，无法捕捉这类跨应用的系统级消耗。
• 平台维护/后台任务：Azure平台在实例上执行的维护操作（如补丁更新、实例轮换、备份任务）会短暂占用CPU，这类操作属于主机层面，不会体现在单个App的性能数据中。
• 实例唤醒/缩放操作：启用自动缩放或实例从闲置状态唤醒时，实例初始化、资源加载过程会导致短时间CPU冲高，单个App的监控可能未覆盖该阶段的资源消耗。
• 系统级网络/IO等待：TCP连接处理、负载均衡探测异常、磁盘IO瓶颈引发的CPU等待状态（看似100%使用率但实际是等待IO），这类消耗属于主机系统进程，单个App监控无法统计。
• 第三方扩展或插件：安装在App Service Plan层面的扩展（如安全扫描、日志收集工具）可能在后台运行时占用大量CPU，未被单个App的监控捕获。

进一步诊断步骤 #

• 查看主机级指标：在Azure门户的App Service Plan中，切换到主机指标视图，监控CPU Time、Disk Queue Length、IO Read/Write Latency等指标，对比峰值时段的主机资源消耗与单个App的指标差异。
• 遍历计划内所有应用的日志：在CPU峰值时段，检查计划下所有App的Diagnose and solve problems工具中的性能日志，排查是否有某个App的非业务进程（如scm.exe、扩展进程）占用CPU。
• 使用Kudu进程探查器：通过Kudu控制台的Process Explorer，实时查看实例上所有进程的CPU使用率，包括系统进程和第三方进程，定位具体的CPU消耗来源。
• 检查平台健康事件：在Azure门户的Service Health中，查看峰值时段对应区域的App Service平台是否有维护、故障或性能异常事件。
• 隔离测试验证：将可疑的App临时迁移到单独的App Service Plan，观察CPU峰值是否消失，以此确认是否由同计划内其他应用导致。
• 分析磁盘IO关联：若主机指标显示磁盘IO异常（如队列长度过高、延迟增加），需检查App的磁盘读写逻辑，或关联存储账户的性能指标，排查IO瓶颈是否引发CPU等待。

内容的提问来源于stack exchange，提问作者Tahami Rizwan