无HTTP端点WebJob应用App Services健康检查方案咨询

App Service 内置的原生健康检查能力不支持基于文件系统状态的健康判定逻辑，其底层实现固定为向配置的路径发起HTTP探测请求，根据响应状态码判断实例健康度，没有内置文件增删/修改时间监测、进程存活探测这类非HTTP探测规则，没法直接通过配置实现你说的文件检测类健康判定。

方案1：本地旁路HTTP探针（改造成本最低，推荐） #

完全不需要改动现有WebJob的业务逻辑，也不需要对外暴露任何公网HTTP端点，只需要在同个App Service实例里部署一个极轻量的本地探针：

• 探针仅监听localhost回环地址的端口，不对公网开放，完全满足你后台作业不暴露公网端点的要求
• 探针逻辑可以自由实现你需要的检测规则：比如定时检查WebJob定期更新的心跳文件最后修改时间，和当前时间差值超过阈值就返回503状态码，正常则返回200
• 将App Service原生健康检查的探测路径配置为这个本地探针的地址即可——原生健康检查的探测请求是从实例本地发出的，不需要端点对公网暴露
  这个方案可以完全复用原生健康检查自带的故障实例重启、负载均衡自动摘流、异常实例替换能力，是性价比最高的方案。
  Windows环境下最简的探针甚至可以用几行PowerShell实现，配成实例启动任务随站点一起启动即可：

$listener = New-Object System.Net.HttpListener
$listener.Prefixes.Add("http://localhost:8080/health/")
$listener.Start()
while ($listener.IsListening) {
    $context = $listener.GetContext()
    $heartbeatFile = "D:\home\site\wwwroot\App_Data\job_heartbeat.log"
    $lastWrite = (Get-Item $heartbeatFile -ErrorAction SilentlyContinue).LastWriteTime
    $isHealthy = $lastWrite -and ((Get-Date) - $lastWrite -lt [TimeSpan]::FromMinutes(5))
    $context.Response.StatusCode = $isHealthy ? 200 : 503
    $context.Response.Close()
}

你只需要在现有WebJob逻辑里加一行，每隔1-2分钟更新一次上述心跳文件的时间戳即可，业务侵入性几乎为0。

方案2：进程监控+自定义定时巡检（完全无HTTP依赖） #

如果你不想引入任何HTTP相关组件，可以放弃使用内置健康检查功能，改用App Service原生诊断+定时WebJob实现健康判定：

• 开启App Service进程级诊断监控，配置对应WebJob进程的存活规则：一旦进程异常退出、或者CPU/内存占用长时间为0（说明作业卡死无响应），直接触发告警或配置自动修复规则重启实例
• 文件检测逻辑可以通过单独的定时触发WebJob实现：每隔固定时间巡检你约定的心跳文件状态，检测到文件长时间未更新、或者标记异常的文件存在时，直接调用App Service管理接口重启当前实例，同时推送告警
  这个方案完全不依赖HTTP端口，但是没法复用原生健康检查自动从负载均衡摘除故障实例的能力，需要自己写少量故障处理逻辑。

方案3：Application Insights自定义心跳上报 #

给WebJob接入Application Insights SDK，在作业逻辑里定期上报自定义心跳事件（比如每完成一批任务、每正常运行一个周期就上报一次心跳），在Application Insights里配置告警规则：如果超过阈值时间没有收到正常心跳，就判定实例异常，触发告警或调用管理接口做实例自愈。这个方案适合需要同时观测作业业务运行指标的场景，同样不需要暴露公网HTTP端点。

你提到的基于文件创建/删除状态、更新时间做健康判定的思路本身完全可行，但App Service原生健康检查没有内置对应的探测能力，必须自行实现探测逻辑。前面提到的本地旁路探针是落地这个思路成本最低的方式，既满足不暴露公网端点的要求，又能完整复用原生健康检查的所有能力。

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