Azure Linux计划下WebJob运行一段时间后异常失效求助

问题概述 #

部署在Linux应用服务计划上的持续型Azure WebJob（.NET 8.0，读取Azure Service Bus Basic队列，单实例，启用Always On），运行2-3天到1周后会出现异常：

• Kudu API、Azure Management API及官方查询WebJob的API均返回504网关超时
• Azure门户无法找到该WebJob，但WebJob进程仍在正常消费Service Bus消息
• 重启应用服务后，WebJob重新显示但状态变为InactiveInstance，停止处理消息，仅能通过重新部署恢复
• 此前使用预览版Linux WebJob功能时就出现过InactiveInstance导致消息堆积，切换到Windows计划后稳定运行2个月；GA后再次尝试仍出现问题

Kudu日志片段 #

[06/16/2025 00:40:47 > 985515: SYS INFO] WebJob is still running
[06/16/2025 09:19:21 > 985515: SYS INFO] Status changed to Starting
[06/16/2025 09:19:22 > 985515: SYS INFO] WebJob singleton setting is True
[06/16/2025 09:19:26 > 985515: SYS INFO] Status changed to InactiveInstance

可行解决方案 #

1. 调整Singleton锁机制

从日志可见WebJob singleton setting is True，Linux环境下Singleton的本地文件锁可能出现异常：

• 禁用Singleton模式：修改settings.job文件，设置"is_singleton": false（单实例部署无需锁也能保证唯一运行）
• 若需保留Singleton，切换锁存储到Azure Blob：在应用服务配置中添加WEBJOBS_SINGLETON_STORAGE，值为Azure存储账户连接字符串

2. 优化健康检查与自动修复

• 配置应用服务自定义健康检查：直接检测WebJob业务状态（比如Service Bus队列消费速率、WebJob暴露的健康端点），替代仅依赖Kudu API的检查
• 启用自动修复功能：当健康检查失败时自动重启应用服务，避免手动干预

3. 迁移到Azure Functions（Service Bus触发器）

将持续型WebJob替换为Azure Functions的Service Bus队列触发器：

• Functions针对事件驱动场景深度优化，Linux环境稳定性更优
• 自带缩放与健康管理机制，避免进程与管控面失联的问题
• .NET 8.0完全兼容，迁移成本低，仅需将消息处理逻辑迁移到Function方法中

4. 开启详细日志排查根因

• 启用WebJob详细系统日志：在应用服务配置中添加WEBJOBS_LOGS_DETAILED=true，收集更多状态变更细节
• 查看容器日志：排查是否存在容器资源耗尽或网络问题，导致管控面无法连接WebJob进程

5. 升级应用服务计划层级

若当前使用基础层（Basic）Linux计划，升级到标准层（Standard）：标准层提供更稳定的资源隔离和管控面通信机制，可能解决504超时问题

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