Azure App Service运行exe随机切换引发高延迟问题排查咨询

你观察到的监控蓝绿指标线交叉、exe随机切换现象，本质是新旧工作进程/部署实例之间发生流量切流，切流过程中新进程冷启动会直接触发高延迟，按以下优先级排查即可：

• 核查部署槽自动交换规则：进入App Service部署槽配置页，检查是否开启自动交换，以及是否配置了基于CPU、内存、请求错误率等指标的自动交换触发规则。这类规则触发时会直接在生产槽和预备槽之间切流，两个槽的进程指标会出现明显交叉，切流期间未预热的新进程接收请求就会产生高延迟。
• 排查进程回收触发记录：
  1. 进入平台自带的「诊断并解决问题」面板，检索进程回收日志，对齐高延迟时间点，确认是否存在工作进程（包括你部署的自定义exe、托管w3wp进程）被回收的记录。常见触发回收的原因包括：进程私有内存/虚拟内存占用超过配置阈值、低流量场景下触发默认20分钟空闲回收规则、web.config/服务配置中预设的定时回收规则触发、平台底层例行维护做实例迁移。
  2. 如果你部署的是独立运行的自托管exe（非IIS直接托管），额外检查健康检查配置：健康检查路径连续探测失败时，平台会判定实例异常，自动重启异常实例并把流量切到正常实例，过程中也会出现进程切换、指标交叉的现象。
• 检查ARR亲和性配置：如果部署了多实例且关闭了应用请求路由（ARR）亲和性，负载均衡会随机将请求分发到不同实例，若部分实例因回收刚启动，请求落到未预热完成的实例上就会出现随机高延迟，同时多实例的进程指标会出现交叉，可以临时开启ARR亲和性验证问题是否复现。
• 核查自动修复规则：进入「配置-常规设置」页，检查是否开启了自动修复功能。如果配置了基于请求耗时、失败率、内存占用阈值的自动修复规则，触发时平台会自动回收工作进程甚至切换实例，和你观察到的现象完全匹配。
• 验证定位手段：开启Web服务器日志与应用程序日志，投递到Log Analytics工作区，查询高延迟时间段的请求关联的进程ID，如果高延迟请求全部集中在进程启动后的1-3分钟内，即可确认根因是进程/实例切流导致的冷启动延迟，后续针对性关闭非必要的自动回收、自动交换规则，补充应用预启动预热逻辑即可彻底解决。

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