Azure WebJobs异常：ServiceBusTrigger触发失效排查求助

针对你遇到的WebJob偶发停止处理Service Bus队列消息的问题，结合你的配置和业务逻辑，我整理了几个最可能的原因，以及对应的排查和解决思路：

1. 并发槽位被阻塞导致无法接收新消息 #

你的WebJob配置了MaxConcurrentCalls = 3，意味着同一时间最多有3个函数实例处理消息。如果这3个槽位被阻塞的线程占满（没有正常释放），WebJob就无法拉取新消息：

• 你的单用户Lease逻辑如果存在未处理的异常或无限等待（比如续租Lease时遇到存储服务故障、没有设置超时），会导致对应的函数线程一直挂起，无法释放槽位。
• 即使SDK的自动续租机制正常，若函数内部逻辑陷入死循环或长时间阻塞（比如超过AutoRenewTimeout但未正确处理），也会占用槽位不释放。

排查&解决：

• 在函数入口和出口添加日志，用Interlocked.Increment/Decrement维护一个静态并发计数器，记录当前活跃的函数实例数。当出现问题时，查看计数器是否一直停留在3，确认槽位被占满。
• 给Lease的获取/续租操作添加超时和异常捕获：比如设置30秒超时，超时后手动调用message.Abandon()释放消息，同时终止当前函数执行，避免占用槽位。

2. Service Bus连接丢失且未自动恢复 #

WebJob的Service Bus SDK依赖于与Service Bus命名空间的持久连接，如果连接因以下原因断开且SDK未自动重建，就会停止接收消息：

• 网络波动、Service Bus命名空间临时故障；
• App Service宿主环境异常（比如你提到的“App被错误停止但WebJobs仍在运行”）：此时WebJob进程脱离了正常的App Service宿主，可能无法访问Azure服务、无法获取必要的环境配置，导致连接无法重建；
• 旧版本SDK的连接恢复bug。

排查&解决：

• 在Azure Portal的Service Bus命名空间中查看消息锁丢失、连接关闭等指标，是否有异常波动；
• 升级Service Bus SDK到最新稳定版本（注意旧的Microsoft.ServiceBus已被弃用，建议迁移到Microsoft.Azure.ServiceBus），新版本SDK优化了连接管理和自动恢复逻辑；
• 确保App Service的始终开启功能已启用，避免App因空闲被休眠；同时配置WebJob的自动重启规则（比如CPU超过80%或内存超过90%时重启）。

3. 未处理异常导致SDK接收管道终止 #

如果函数内部抛出未捕获的异常，可能会中断SDK的消息接收循环：

• 比如处理消息时出现未捕获的Exception，导致SDK的OnMessage处理线程崩溃，而WebJob主机没有自动重启接收管道；
• 自动续租失败时，SDK内部可能抛出异常，如果未被正确捕获，也会导致接收逻辑终止。

排查&解决：

• 启用WebJob的详细日志记录，在JobHostConfiguration中开启日志：

  config.DashboardConnectionString = "your-storage-connection-string";
  config.UseSerilog(); // 或其他日志框架，记录所有未处理异常
  

• 在函数内部添加全局异常捕获，确保所有异常都被处理，并在异常发生时手动释放消息（message.Abandon()或message.DeadLetter()），避免影响整个接收管道。

4. 关于“App被错误停止但WebJobs仍在运行”的影响 #

你提到的这个场景确实很可能是问题根源：当App Service被异常停止（比如自动缩放失败、资源限制强制停止），WebJob进程可能没有被正常终止，此时它处于一个“孤立”的状态：

• 无法访问App Service的配置、密钥等资源；
• 与Azure服务的网络连接可能被宿主环境切断；
• 缺少App Service的心跳和健康检查支持，无法自动恢复。

这种情况下，WebJob的消息接收逻辑会逐渐失效，只有手动重启WebJob才能让它重新接入正常的宿主环境，恢复与Service Bus的通信。

解决建议：

• 配置App Service的监控警报，当App Service状态变为“停止”时触发通知，及时手动重启WebJob；
• 利用Azure Automation或Logic Apps创建自动化流程，检测WebJob的运行状态（比如通过Kudu API），当发现异常时自动重启WebJob。

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