超算多域数据智能分析与主动服务系统——异常作业闭环治理阶段性总结

发布者:张运动发布时间:2026-09-09浏览次数:11

总结对象:超算多域数据智能分析与主动服务系统(异常作业闭环治理模块)

数据口径:完整自然周同口径对比,基线 2026-07-20 至 08-02,观察期 08-03 至 08-30,观察日期截至 2026-09-01

超算多域数据智能分析与主动服务系统

系列总结之一:异常作业闭环治理——系统架构、智能判定、闭环服务与阶段成效

超级计算中心管理运行瀚海25、瀚海22、瀚海20三套超算系统,长期面临一类共性运行问题:部分用户作业的实际负载远低于其向 Slurm 调度器申请的 CPU 资源与 MPI 并行参数,形成资源闲置;也有作业反向超载运行,带来稳定性风险。这两类异常作业既浪费用户机时与计算费,也降低全中心资源实际使用效率。为此建设了超算多域数据智能分析与主动服务系统:将操作系统日志、Slurm 调度日志、用户计算作业指标等多个数据域统一汇聚,通过指标体系与告警规则智能判定异常作业,自动经中心管理邮箱向用户发送提醒,并持续跟踪恢复情况,形成系统监控、数据智能分析、用户邮件通知、用户检查处理、回到系统监控的完整闭环。异常作业治理是该系统的首个落地工作模块,本篇为该系列阶段性总结的第一篇。

一、系统总体架构:多域采集、统一指标、自动闭环

系统建设在运维管理平台之上,自底向上分为数据源层、指标与字段层、智能判定层、通知服务层四层。数据源层将三套系统的多域数据统一只读接入;指标与字段层把原始日志加工为以作业为中心的稳定字段;智能判定层通过平台变量规则对每个运行作业给出健康判定;通知服务层以自动化流程驱动邮件提醒与投递跟踪。各层职责与实测构成如下。

层次构成与职责(实测)
数据源层Prometheus Main 指标源(http://127.0.0.1:9090,只读接入,覆盖瀚海22、瀚海25),汇聚节点侧 Job 指标、Slurm 调度状态、作业历史采样归档等多域数据;配套监控模板、调度任务、缓存观测、数据存储等平台配置模块
指标与字段层10 个作业稳定字段(job.allocated_cpu_cores、job.cpu_usage_cores、job.cpu_usage_percent、job.gpu_usage_percent、job.gpu_processes、job.health、job.state 等)与 7 个指标定义(job.allocated_cpu、job.runtime_cpu、job.scheduler_info 等),由 job_monitoring_aggregation_postprocess 至 job_monitoring_derived_field 运行阶段聚合生成
智能判定层8 条告警规则(其中作业相关 4 条),基于 job.health 健康态与利用率阈值持续判定:持续疑似超额、窗口期疑似闲置、CPU 利用率异常偏高等,触发后生成告警事件并进入恢复跟踪
通知服务层运维邮件通知通道(SMTP)+ 平台内告警消息通道;自动化流程版本16,8 节点 8 连线编排,从告警事件消费到用户邮箱投递全链路自动执行
系统四层架构与数据流数据源层多域数据只读接入:操作系统指标、Slurm 调度日志、作业历史采样(Prometheus,覆盖瀚海25/22/20)指标与字段层10 个作业稳定字段 + 7 个指标定义,聚合后处理生成(allocated_cpu / cpu_usage_percent / health / state 等)智能判定层8 条告警规则持续判定(持续超额 1800 秒 critical、窗口期闲置 360 分钟占比不低于 60%、CPU 利用率不低于 200% 等)通知服务层自动化流程 8 节点编排:加载作业、生成资源曲线、解析用户邮箱、渲染提醒、SMTP 发送、投递记录判定结果经管理邮箱触达用户,用户处理后回到系统监控,形成闭环

二、多域数据采集:三系统、双源汇、细粒度

数据采集体现多域、大量、复杂三个特征。多域:同一作业同时采集调度域(Slurm 队列、申请资源、运行节点)、节点域(进程级 CPU、内存、IO、GPU)、历史域(作业历史 272 页乘以每页 50 行量级的全量记录)。大量:作业历史按系统全量归档,支持按作业 ID、用户、分区、记录类型、终态、原因、起止时间多维检索。复杂:数组作业拆分为子任务逐项追踪(如某数组作业的 _2、_3 子任务各自独立判定),GPU 作业单独核对 GPU 进程是否真实运行。实时作业监控页面当前即呈现一个典型样本:19 个运行作业申请 CPU 合计 208 核而实际使用 0 核,全部标记为低利用;其中某用户作业在 3 个节点各分配约 32 核,节点侧检测到的使用量为 0。

数据域采集内容作用
Slurm 调度域作业 ID、分区、申请 CPU 与 GPU、MPI 并行参数、运行节点、排队与运行时长、终态与原因异常判定的申请侧基准
节点执行域进程级 CPU 使用核数与利用率、内存使用、读写速率、进程数、GPU 进程数异常判定的实际侧基准
作业历史域全部历史作业归档(272 页量级每系统),普通作业与数组子任务分别记录窗口期判定与趋势分析

异常判定之所以可靠,关键在于申请侧与实际侧的双源交叉核对:只看 Slurm 会把空转作业当作正常,只看节点会丢失申请基准。系统对每个作业计算实际使用与申请量之比,再叠加时间维度持续观察,避免瞬时抖动误报。判定标准全部显式配置在告警规则中,可审计、可调整。

异常类型判定标准(告警规则实测)持续条件等级
资源闲置(持续)job.health 判定为 idle(实际负载远低于申请 CPU 与 MPI 并行参数)持续 1800 秒warning
资源闲置(窗口期)最近 360 分钟内低利用采样占比不低于 60%(作业历史采样)立即触发warning
资源超载(持续)job.health 判定为 overloaded持续 1800 秒critical
CPU 利用率异常偏高job.cpu_usage_percent 不低于 200%(超出申请核数运行)持续 600 秒warning
双源交叉判定:申请侧与实际侧对比Slurm 申请侧申请 96 核 CPU3 节点 MPI 并行节点实际侧实际使用 0 核进程数 0,GPU 进程 0判定:申请 96 核,实际 0 核,利用率 0%持续 1800 秒或窗口期低利用占比不低于 60% 即判为资源闲置异常时间维度持续观察消除瞬时抖动,GPU 作业另核对其 GPU 进程真实性

三、闭环服务机制:从告警事件到用户恢复的全自动链路

异常被判定后,系统并不停留在平台内报警,而是自动完成到用户的触达。自动化流程以作业健康事件为触发器,顺序执行 6 个工作节点并设 2 个异常出口:加载作业上下文失败或历史采样缺失时走忽略出口不发送邮件;解析不到用户邮箱同样静默跳过,保证不误发、不空发。邮件发送后进入投递记录与恢复跟踪,构成发现、提醒、处理、确认的闭环。流程运行记录显示 9 月 1 日至 2 日 30 次触发全部成功走完;投递记录显示邮件按用户逐一投递至 mail.ustc.edu.cn 等邮箱并返回成功响应。

任务异常用户邮件通知流程(8 节点 8 连线)作业健康触发(持续闲置/超额事件)trigger加载作业上下文load_job(失败则转忽略出口)生成资源曲线resource_chart(附于提醒邮件)解析用户邮箱resolve_email(未匹配则转忽略出口)渲染提醒内容render_message发送邮件(SMTP 运维通道)send_email完成,进入投递记录与恢复跟踪忽略出口:数据缺失不误发不空发

该闭环把传统的用户报障式运维反转为平台主动服务式运维:过去资源闲置要等用户自己发现问题或管理员人工巡查,现在系统在异常持续出现的第一时间即主动通知,并随邮件附上资源曲线等上下文,帮助用户快速定位是程序并行参数设置不当还是数据依赖未就绪。用户处理完成后,系统监测到恢复即自动关闭事件,全过程无需人工介入。

四、阶段成效:规模、速度、覆盖三维改善

采用完整自然周同口径比较,以前期两个完整周(7 月 20 日至 8 月 2 日)为基线,治理机制运行后的四个完整周(8 月 3 日至 8 月 30 日)为观察期。规模上,周均异常作业由 217.5 个降至 158.8 个,下降 27.0%;周均异常用户由 42.0 位降至 26.8 位,下降 36.3%;周均新出现异常由 204.5 个降至 151.3 个,下降 26.0%。速度上,平均恢复时长由 177.4 分钟缩短至 29.5 分钟,缩短 83.4%;6 小时内恢复比例由 82.9% 提升至 98.5%。覆盖上,近期纳入跟踪的 31 位用户共 118 个异常作业项全部恢复,恢复覆盖率 100%,恢复时长中位数 15.2 分钟,65.3% 在一小时内恢复。

周均异常作业下降 27.0%217.5 个 降至 158.8 个
周均异常用户下降 36.3%42.0 位 降至 26.8 位
平均恢复时长缩短 83.4%177.4 分钟 降至 29.5 分钟
6 小时内恢复比例提升至 98.5%较前期提高 15.6 个百分点
每周异常作业与异常用户变化(完整自然周)2332021601621651631487/207/278/038/108/178/248/31异常作业异常用户高点 233 个降至 148 个,下降 36.5%;异常用户由 44 位降至 28 位,下降 36.4%
维度指标基线观察期变化
规模收敛周均异常作业217.5 个158.8 个下降 27.0%
周均异常用户42.0 位26.8 位下降 36.3%
周均新出现异常204.5 个151.3 个下降 26.0%
恢复提速平均恢复时长177.4 分钟29.5 分钟缩短 83.4%
6 小时内恢复比例82.9%98.5%提高 15.6 个百分点
用户侧覆盖跟踪异常作业项118 个(31 位用户),均已恢复覆盖率 100%
恢复时长中位数15.2 分钟65.3% 一小时内恢复
周度高点对比233 个148 个下降 36.5%

五、工作意义与下一步:从治理一个异常到服务全量业务

本模块的意义不止于数据改善。对用户,异常作业意味着白花的机时费与排队等待,提醒闭环直接帮助用户减少浪费、更快修正程序并行设置,中位数 15.2 分钟的恢复速度让用户几乎无感完成调整。对中心,208 核申请零使用这类闲置被及时释放,同一硬件承载更多有效计算,资源实际使用效率提升。对运维模式,从被动报障转向主动服务、从人工巡查转向数据智能判定,这套多域数据加智能分析加闭环服务的方法论可复制到更多场景。

异常作业治理只是超算多域数据智能分析与主动服务系统的首个工作模块。基于同一套多域采集、统一指标、规则判定、自动触达的平台能力,后续将依次落地系列工作,每个工作均以同样的维度(架构、判定标准、闭环机制、阶段成效)形成系列性总结与宣传报道,包括:存储与配额的主动服务(用户配额将满、异常占用的提前提醒)、排队体验优化(长排队作业的原因分析并与用户协同调度)、节点健康治理(故障节点自动识别与作业迁移建议)、计费透明化(用户计算费的周期性分析与优化建议)等方向。系统将持续滚动观察异常作业指标,并将观察口径、判定标准与通知模板沉淀为可复用配置,支撑后续模块快速接入。

说明:本文为系列总结第一篇(异常作业闭环治理模块)。数据按完整自然周匿名去重统计,不含用户名、邮箱、作业名称等个人与业务明细;异常作业指资源闲置与资源超载两类,判定标准见文中告警规则实测记录。系统名称:超算多域数据智能分析与主动服务系统。