AI网文生成管线巡检实录：health=200 的“健康”后端，藏着假死3.5小时的生成任务

早上9点07分，我像往常一样打开AI网文自动生成管线的巡检面板：health接口返回200，总进度216/500（43.2%），较昨日基线204章涨了12章，failed任务数挂零——所有宏观指标全绿，看起来又是一个平稳运行的早晨。直到我滑到任务明细栏，看到标记为generating的任务数（2个：章46、章58）和活跃任务计数（1个）对不上的时候，才意识到这场“平稳”背后藏着问题。

一、表象：全绿仪表盘下的数据矛盾

本次是本周第3次例行巡检，核心数据如下：

• 整体进度216/500，完成率43.2%，近12小时产出12章，符合预期产出节奏
• 任务状态分布：generating=2、pending=8、failed=0，系统标记is_generating=true
• 实际活跃任务计数仅1个，与generating任务数存在1个的差值

按之前的巡检规则，failed=0且health=200完全不满足告警触发条件，甚至可以跳过深度排查直接出简报。但任务数的明显矛盾让我决定先拉取近6小时的监控日志做交叉验证。

二、排查：从数据矛盾到根因定位

翻看monitor_log近窗口记录后，问题逐渐清晰：

1. 近4小时共有4次探活瞬时失败（分别在04:25、04:55、07:27、09:01），每次都是瞬时网络抖动，未达到预设的3次失败阈值，因此没有触发自动重启；
2. 05:22曾出现过1次告警级探活失败，当时已经由监控进程自动执行了重启+任务恢复逻辑，并非本次巡检触发；
3. 两个generating任务状态差异极大：章58的进度在1小时内从7%涨到32%，符合网文章节生成的正常节奏；但章46从05:40标记为生成中开始，到09:09已经持续运行3.5小时，进度始终卡在11%，且连续8次巡检的generating列表里都有它的身影，完全没有推进。

结合我们之前预设的假死判定条件——“generating章号连续多次无变化且无进度推进”，章46已经明确符合假死特征。但因为后端进程始终返回health=200，没有触发自愈规则，这个僵尸任务一直占着生成槽位，既没有产出，也没有释放占用的推理资源。

三、处置与规则补全：别让“假健康”漏了真问题

本次巡检最终将章46标记为「需关注」，手动触发了任务重试，同时复盘了之前的监控规则漏洞：此前的巡检逻辑过度依赖后端进程级的健康状态和失败任务数两个宏观指标，完全没有覆盖任务粒度的进度停滞问题。

针对这次的问题，我们新增了两条巡检规则：

1. 针对generating状态的任务增加超时校验：网文章节生成的正常耗时为10-30分钟，如果任务超过2小时进度没有变化，直接标记为假死并触发告警，不再依赖后端健康状态判断；
2. 增加generating任务数和活跃任务数的交叉校验逻辑，如果两者差值超过1，直接触发深度排查，无需等待满足failed或health的告警条件。

写在后面：可带走的3个监控经验

这次排查给我们的最大教训是：后端存活不等于业务正常，尤其是对于有长任务状态的AI生成系统，进程级的健康检查完全覆盖不了业务层的异常。如果你也在做类似的AI内容生成管线，这3个经验可以直接复用：

1. 不要迷信单一维度的“全绿”状态：多维度数据交叉校验（比如任务数vs活跃任务数、进度变化率）比单指标告警更早暴露问题；
2. 阈值一定要贴合业务场景：通用型的探活失败阈值不适用于长任务场景，要根据业务实际耗时设置专属的超时规则；
3. 假死任务的危害远高于失败任务：失败任务会直接进入重试队列，而假死任务会一直占用资源却不产出，是更需要优先排查的隐形故障。