Azure Container Apps设最小副本数1时服务异常停止如何诊断

• 先核对平台层事件日志
  不要只看应用输出的业务日志，直接查询Container Apps的平台事件流，筛选ContainerAppReplicaStarted、ContainerAppReplicaRemoved、ContainerAppContainerStopped三类事件，重点看事件附带的原因字段：
  • 如果原因标注为缩放操作触发，先确认你配置的最小副本数是修订版生效的配置，不是草稿配置——很多人会把全局环境配置、修订版配置、缩放规则里的最小副本参数搞混，出现配置了最小1副本但实际生效为0的情况。同时检查缩放规则里是否残留默认的HTTP流量、CPU/内存阈值触发规则，纯空闲的Worker Service CPU占用通常低于5%，很容易触发低资源阈值的缩容逻辑。
• 排查存活探针配置错误
  这是无HTTP端点的后台服务在ACA上最常踩的坑：ACA默认会为容器配置TCP类型的存活探针，默认探测80端口，初始延迟10秒、探测间隔10秒、连续2次失败就重启容器，时间窗口刚好匹配你观察到的20-30秒启动后终止的现象。连续重启失败后ACA会触发指数退避重启策略，最长退避间隔就是5分钟左右，和你描述的5-6分钟无运行记录的特征完全吻合。可以先临时关闭所有存活、就绪探针，或者为Worker Service添加一个极简的健康检查端点监听80端口固定返回200状态码，复现看问题是否消失。
• 核对容器退出码
  在ACA的副本历史列表里找到被终止的副本记录，查看容器的退出码：
  • 退出码为137：代表平台发送SIGKILL强制终止容器，原因基本是探针失败、资源超限、缩放操作三类
  • 退出码为0：代表应用进程自行正常退出，需要回头检查.NET Worker Service的代码逻辑：确认BackgroundService的ExecuteAsync方法是否存在长期阻塞逻辑，标准的常驻Worker写法需要在方法内用while (!stoppingToken.IsCancellationRequested)循环包裹调度逻辑，避免方法执行完成后主机直接退出；同时注册IHostApplicationLifetime的停止事件打日志，确认进程是否收到了平台的停止信号。
• 排除应用自身静默退出的可能
  给Program.cs加全局未观察任务异常、未处理异常捕获日志，重点排查cron调度组件、Timer组件抛出的未捕获异常——这类异常如果没有被日志组件记录，会导致进程静默退出，在业务日志里查不到任何致命错误记录。可以临时在本地用docker run --cpus 0.1 --memory 128m限制容器资源运行，模拟ACA上的低资源环境，看是否能复现进程退出的问题。
• 做固定副本对照测试
  临时把ACA的缩放规则改成固定1副本（最小副本=1、最大副本=1，删除所有自定义缩放触发条件），连续运行15分钟观察是否还会出现重启、长时间不运行的情况，如果问题消失，就可以确定根因在缩放规则配置；如果问题依旧，再排查容器镜像的启动命令、工作目录、权限配置是否和ACI、本地运行的配置一致。

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