Azure Service Bus队列触发函数闲置 手动访问后自动运行问题排查

常见根因 #

• 托管计划的空闲实例回收：如果函数运行在消费计划、未开启Always On的专用计划下，平台判定一段时间无入站请求、无活跃消息处理负载时，会将运行实例挂起/回收，此时队列触发器的消息轮询逻辑会暂停，不会主动拉取消息。手动访问函数相当于触发入站请求，会直接唤醒实例恢复运行，不需要手动重启。
• Service Bus连接静默断开：函数与Service Bus之间的AMQP连接因为网络路径上的中间设备（NAT网关、防火墙、代理）的空闲超时策略被强制断开，而Service Bus SDK的内置重连逻辑没有触发链路重建，此时触发器既不拉取消息，也不会抛出可被应用日志捕获的异常，直到有外部请求触发进程内的网络动作，才会重新建立监听连接。
• 触发器内部退避逻辑卡住：当maxConcurrentCalls、maxAutoRenewDuration等并发配置与Service Bus队列端的锁有效期、最大投递数参数不匹配时，触发器可能进入内部静默退避状态，既不报错也不消费消息，直到外部请求打断当前退避流程。
• 平台健康检查判定异常：如果开启了函数健康检查但路径配置错误，平台会暂时将实例标记为不健康，停止向实例分发触发器负载，但实例进程本身没有退出，手动访问验证实例存活后，平台会恢复负载分发。

可落地排查步骤 #

• 先确认托管计划配置：在函数应用配置页查看托管SKU，如果是专用计划，先确认是否开启Always On选项；如果是消费/弹性高级计划，先核对函数超时配置、实例空闲回收规则，可临时切换到专用计划开启Always On运行一段时间，观察问题是否复现，先排除实例回收类问题。
• 开启Service Bus绑定的详细日志：修改函数host.json文件，将Service Bus相关组件的日志级别调整为Trace，配置示例如下：

{
  "logging": {
    "logLevel": {
      "Microsoft.Azure.WebJobs.ServiceBus": "Trace",
      "Azure.Messaging.ServiceBus": "Trace"
    }
  }
}

等问题复现后，直接拉取应用日志，查找是否存在AMQP连接断开、消息接收链路关闭、重试退避等待的相关记录，确认是否为连接静默断开导致的监听中断。

• 核对网络路径空闲超时规则：如果函数部署在虚拟网络内、访问Service Bus经过企业防火墙/NAT网关，先确认中间设备的TCP空闲超时阈值。Service Bus SDK默认的连接保活间隔为1分钟，如果中间设备的空闲超时小于该值，就会出现无感知断连，可在Service Bus连接字符串中追加IdleTimeout=30参数，让SDK缩短保活包发送间隔，避免连接被中间设备切断。
• 校验触发器参数匹配性：检查host.json中Service Bus触发器的相关配置，重点核对autoCompleteMessages、maxConcurrentCalls、maxAutoRenewDuration几个参数，其中maxAutoRenewDuration的取值不能超过Service Bus队列端设置的消息锁最大时长（队列默认锁时长1分钟，最大支持5分钟），避免因锁过期导致触发器逻辑卡住。
• 查看平台侧诊断记录：进入函数应用的诊断页面，查找触发器同步失败、实例健康异常、消息拉取中断类的检测报告，确认是否存在平台侧的调度异常。
• 验证临时规避方案：如果初步判断是空闲回收导致的问题，可以配置一个1分钟间隔的定时触发器，调用函数自身的健康接口，避免实例进入空闲状态，观察问题是否消失。

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