作业失败一键根因:智能诊断的证据链设计与 33 次带标准答案的实测

📅 2026/8/5 7:59:01
作业失败一键根因:智能诊断的证据链设计与 33 次带标准答案的实测
凌晨告警,核心链路的 Spark 作业挂了:一万行日志里找几行有用的;driver 侧只有一句包装异常,真正的报错在某个 executor 里,而那个 executor 的 pod 已经被引擎删掉;Flink 重启循环把异常历史刷成 14 条,心跳超时、状态恢复失败、连接池关闭——哪条是因,哪条是果?排障的本质是取证 归因:取证是体力活,归因是经验活。LLM 恰好擅长归因这一半,前提是证据喂得对。这篇讲清楚一件事:可私有化部署的数据平台「我的数据空间」(datastudiohappy.cn)里,智能诊断是怎么把「作业失败,点一下按钮,给出根因和修法」做到有据可依的。不谈概念,只讲机制和实测数字。一、价值重心在取证,不在 prompt微软 RCACopilot(EuroSys 2024,653 起真实事故验证)的消融实验给出过一个悬殊数字:结构化证据采集把根因分类 Micro-F1 从裸 GPT-4 的 0.026 拉到 0.766——证据采集的贡献,远大于让 LLM 自由发挥。智能诊断的架构因此定为四段:一句话:19 个证据工具真连现场,启发式提取先降噪,再交给 LLM 做 agentic 归因,输出结构化的「故障类目 根因 修复建议」——每一步查了什么、拿到什么,全程可审计。二、证据采集:真连引擎,覆盖「已消失的现场」19 个证据工具不是读几个日志文件:Spark 经引擎 REST 取失败 stage、task 明细、executor GC 占比;Flink 经 JobManager REST 取 checkpoint 成败、反压状态、异常历史;再加上 pod 死因与退出码、血缘、表结构、数据采样、作业配置、资源趋势,按作业类型精准暴露。最难的一段是证据经常物理上不存在:executor、TaskManager 都由引擎创建、死后被引擎删除;容器因超内存被 cgroup 杀死时是 SIGKILL,进程一个字日志都来不及写,唯一证据是退出码 137。两条对策:节点级日志留底:采集器常驻每个节点,日志边产边收,容器被删除后仍能读完最后一行。实测闭合过一个案例:真因异常的 7 条日志,全部来自一个当时已被删除的 executor;死因先落库:容器终止原因与真实退出码,在清理动作之前写进任务记录——失败后点诊断,读到的是真实死因,不是空白。三、提取与归因:结构判据 agentic 工具循环上万行日志不能整段扔给模型。提取用结构判据定位错误锚点——日志级别、异常类形态、traceback 头——不靠关键词表,没见过的故障类型也认得出;再按「形状」归并:重启循环刷屏的次生错误塌成一条带次数,只出现一次的真因不被淹没。Flink 重启循环是典型场景:14 条异常历史的真实结构是「症状 → 真因 → 次生」,归并后压成 3 类,OOM 真因清清楚楚列在其中。归因这一段是真 agentic:模型自主决定查哪些证据、查几次(带步数硬顶),还能带参数深挖——点名查某张表某个字段的采样分布、某个 stage 的全量 task 明细,像一个顺着线索追问的工程师。而证据面本就窄的入口(即席查询、Notebook)走固定序列一次采完,不为 agentic 而 agentic。证据之间还有一条定权规则:同名配置往往同时存在平台默认值、作业自定义参数和引擎运行期有效值,归因一律以引擎自报的运行期值为准。一个 Flink 实测案例:checkpoint 超时被自定义成远小于实际所需的值,补齐运行期有效配置与实际耗时两项证据后,诊断直接点名这个参数、给出正确的调整建议——结论引用的是权威配置和真实耗时,不是推测。两条底线贯穿始终:证据不足就如实说「无证据」,绝不编结论;未配大模型时自动降级为规则诊断,基于同一批真实证据做模式匹配,永远有结果可看。四、实测长什么样在「我的数据空间」(datastudiohappy.cn)里,失败实例详情点「智能诊断」即可;调度作业之外,即席查询失败、Notebook cell 失败同样一键可诊。一个数据倾斜引发 OOM 的 Spark 作业:展开「诊断过程」,能看到每一步调了哪个工具、拿到什么证据——「申请内存 512MB」「失败任务数 7」「GC 耗时 29183ms」这些具体数字直接支撑结论,而不是模型现编:Flink 流作业的 checkpoint 持续失败——作业不崩溃、不重启,却在悄悄丢失容错能力——同样能被定位:五、数字说了算:ground truth 审计演示效果好,不等于真的准。智能诊断的准确率由一套 ground truth 审计裁决:11 个真实失败案例(cgroup OOM、数据倾斜、DNS 解析失败、越权操作被拒、质量门禁失败……),逐条人工核实标准答案;每次评测真调诊断接口、真调 LLM,固定连跑 3 轮共 33 次,对比输出的故障类目是否精确匹配——LLM 有运行间波动,单轮数字不可信,报区间才诚实。项数字分类准确率基线 63.6% → 修复后最高81.8%(三轮均值 72.7%)JSON 解析失败0/33,内容正确的结论一条不丢已删除容器的证据实测闭合:真因日志全部来自已删 executor证据工具19 个,按作业类型精准暴露两条评测纪律值得同类系统直接抄:结论文字质量的 LLM 裁判分永远单列,不与硬指标合并成一个好看的总分;每次改动前后跑同一基线,diff 数字拍板。六、三句话总结LLM 诊断的上限由证据决定,不由 prompt 决定;最值钱的证据在「已消失的现场」——日志留底与死因落库必须先行;没有带标准答案的评测,「诊断得准」只是一种感觉。这套智能诊断是「我的数据空间」的一部分——一套可私有化部署的数据平台,支持 OEM 合作。产品介绍:https://datastudiohappy.cn/。