1. 为什么AI开发平台比普通业务系统更需要监控告警AI开发平台的监控告警表面上看起来像是在做“老本行”——采集指标、设阈值、发通知但真正上手之后你会发现它和监控一个普通Web业务系统完全是两码事。先说说我自己的经历。我们团队负责的AI开发平台上线初期沿用了一套通用监控方案指标采集、图表展示、告警通知一应俱全。结果上线不到一周就出了两次事故一次是分布式训练任务因为某个节点显存耗尽被反复重启作业队列堆积了上百个任务平台用户在线吐槽“训练任务排不上队”另一次是数据预处理管道因为上游数据源格式变化直接卡死模型评估结果延迟了整整半天业务侧以为模型效果退化差点把回滚流程都走了。事后复盘的时候大家才发现传统监控方案里那几个CPU、内存、磁盘的告警规则根本覆盖不了AI平台的真实风险点。GPU利用率、训练任务状态、推理服务延迟、数据管道积压量、模型版本漂移这些指标才是AI平台能不能稳定跑起来的关键。这篇文章我会用一线运维和平台建设的视角把AI开发平台异常指标实时监控告警体系从设计到落地的完整思路拆开讲清楚。不管你是平台工程师、算法工程师还是运维负责人只要日常工作需要和AI开发平台打交道这篇文章都能给你一套可以直接参考的落地方案。注意这里讨论的“AI开发平台”指的是承载模型训练、模型推理、数据集管理、自动化测试等功能的统一平台它是算法团队的日常作业系统和单纯跑一两个模型脚本完全是两个量级的基础设施。2. 监控体系设计AI平台需要盯住哪些异常指标2.1 先搞清楚AI平台的分层结构一个典型的AI开发平台从上到下大致可以分为四层应用接入层模型训练任务入口、推理服务调用API、数据标注/数据管理界面、自动化测试执行引擎平台能力层任务调度器、资源配额管理器、模型仓库、特征存储、实验跟踪组件资源调度层Kubernetes集群、GPU资源池、分布式存储、消息队列基础设施层物理服务器、操作系统、网络、GPU/NPU等异构加速设备每一层都有各自的异常模式而且异常往往会跨层传导。比如底层一台GPU服务器温控异常触发降频中层任务调度器感知到节点资源异常开始驱逐Pod上层训练任务被频繁重调度最终用户看到的就是“训练速度变慢”“任务老是中断”。所以监控指标的设计不能只看单点数据必须分层覆盖同时建立跨层关联分析能力。2.2 基础设施层GPU/NPU资源的专项监控普通业务平台的监控重点在CPU、内存、磁盘IO、网络带宽AI平台在此基础上还要增加对GPU/NPU这类异构加速设备的专项监控而且这部分的指标远比常规硬件监控复杂。GPU相关指标至少需要覆盖以下几类指标类别具体指标异常含义利用率GPU利用率、显存使用率、GPU显存带宽利用率长时间为0说明任务未跑起来显存占用过高容易OOM温度与功耗GPU温度、核心温度、功耗温度过高会触发降频训练速度断崖式下跌硬件健康ECC错误计数、PCIe链路错误、NVLink带宽ECC错误持续增长是硬件即将故障的前兆任务状态SM占用率、张量核心利用率、显存分配失败次数判断训练是否真正利用了GPU算力这里有个典型的误区很多人只看GPU利用率觉得利用率高就万事大吉。实际上GPU利用率高也可能是在空转。有些训练脚本因为数据加载IO瓶颈GPU每个step都在等待数据利用率曲线呈现密集的锯齿状。表面看利用率在80%以上实际有效计算时间只有一半。所以GPU监控建议同时看利用率和等待时长两个维度配合训练日志的数据加载耗时才能定位真正的瓶颈。2.3 平台能力层调度、队列与训练任务的健康指标平台层最核心的是任务调度器。无论是自研调度器还是基于K8s都需要关注以下指标Pending任务数量排队中的任务数量异常增长说明资源不足或调度策略异常任务调度时延从提交到开始执行的时间差正常情况下应该在秒级到分钟级任务失败率与重试次数失败率突增通常是代码问题、资源问题或数据问题的信号任务运行时长分布同类任务运行时长突然翻倍大概率是资源被抢占或性能劣化训练任务的状态监控也很关键。一个训练任务从提交到完成会经过Pending、Running、Succeeded、Failed等状态每个状态转换都应该有记录。实际操作中我习惯给任务状态转换加一个时间戳监控比如一个任务在Pending状态卡了超过30分钟就触发告警。这个阈值不能设得太激进因为有些大模型训练任务在排队等资源时本身就是设计好的优先级调度卡个把小时也是正常的。2.4 应用层推理服务、模型效果和数据管道AI平台除了训练还有很大一部分业务在推理服务上。推理服务的核心指标包括推理请求QPS与RT响应时间RT出现长尾用户体验会明显劣化推理错误率5xx错误率超过0.1%就要警惕GPU显存占用趋势推理服务显存缓慢增长大概率存在内存泄漏模型版本分布线上跑了多个版本时要监控版本切换是否有异常回退数据管道这块容易被忽略。AI平台的自动化测试、数据预处理、特征工程往往依赖管道任务。管道任务的关键指标是积压量和处理时延。我用过一个很简单的告警方式给每个管道任务的积压消息数设一个阈值连续3个采集周期超过阈值就告警。听起来很简单但实际排查问题时这个指标帮我快速定位过多次数据源故障。2.5 监控指标维度的两个“坑”指标设计得再全维度选不对也白搭。两个常见问题第一个是维度过粗。比如只按整个集群汇总GPU利用率某台机器已经因为硬件故障导致利用率归零汇总数据可能只是在95%掉到93%完全看不出异常。我建议至少按节点、按GPU卡两个维度分别建立监控高级一点还可以按训练任务维度打标签这样一张GPU利用率曲线拉出来哪台机器、哪张卡、哪个任务有问题一目了然。第二个是维度爆炸。标签设计要克制有些团队为了将来回溯方便把几十个标签全都打上。采集端倒是无所谓但告警规则一旦涉及多标签聚合PromQL查询性能会肉眼可见地变差。我的经验是核心指标标签控制在5-8个预留两个扩展位就够用了。3. 实时监控与告警从数据采集到通知触达的完整链路3.1 技术选型为什么我选择Prometheus Grafana AlertmanagerAI开发平台的监控告警组件选型我个人推荐Prometheus Grafana Alertmanager这套组合它的优势非常明显Prometheus是云原生监控的事实标准K8s生态天然适配AI平台基本都跑在K8s上采集指标直接走服务发现零配置介入Alertmanager是Prometheus官方告警组件负责告警路由、分组、抑制、静默AI平台告警量大的场景下表现稳定Grafana的图表生态足够丰富GPU监控、训练任务看板、推理服务SLO看板这类可视化需求都能满足这三者都是开源组件社区资料丰富遇到问题网上基本都能找到解决方案如果团队预算充足也可以考虑引入商业化APM或者云厂商托管监控服务但底层逻辑和告警策略设计和开源方案是相通的。下面的内容我以Prometheus生态为例展开。3.2 告警规则的阈值计算逻辑告警阈值设多少直接决定这套系统的实用程度。阈值设太高故障瞒报设太低告警轰炸到没人看。阈值的设定不能拍脑袋我习惯分三步走第一先采集两周以上的指标基线数据。监控系统上线初期先只采集不告警把各项指标的正常波动范围摸清楚。比如训练任务调度时延正常情况下P99在15秒左右高峰期偶尔到45秒那初始阈值可以设在60秒。第二用统计学方法确定阈值。对基线数据计算均值和标准差初始阈值设为均值加3倍标准差。这个数值不是一成不变的后续根据实际告警准确率持续调优。第三区分“绝对值阈值”和“相对变化阈值”。有些指标适合用绝对值比如GPU温度大于85度告警有些指标则要看相对变化比如推理错误率在5分钟内上升了3倍才告警单纯设绝对值容易误报。3.3 告警规则配置的实战写法下面是一段我在训练任务监控场景中实际用过的Prometheus告警规则配置groups: - name: ai-platform-training rules: - alert: TrainingTaskPendingTooLong expr: time() - max(ai_task_status_change_time{statusPending}) by (task_id) 1800 for: 5m labels: severity: warning component: scheduler annotations: summary: 训练任务 {{ $labels.task_id }} 排队超过30分钟 description: 任务已等待 {{ $value }} 秒请检查资源池是否有可用GPU资源 - alert: GPUUtilizationDropToZero expr: avg(ai_gpu_utilization{jobgpu-exporter}) by (instance, gpu_id) 0 for: 10m labels: severity: critical component: gpu annotations: summary: GPU {{ $labels.instance }} / {{ $labels.gpu_id }} 利用率持续为0 description: GPU利用率连续10分钟为0训练任务可能已挂起或存在硬件故障这里几个细节值得说明一下for: 5m的作用是“持续时间”过滤。瞬时抖动不告警持续5分钟才告警能过滤掉大量噪声expr中要善用by (task_id)等聚合操作告警的内容才会带着足够多的上下文信息labels里打上severity和component标签方便后面告警路由做分组匹配3.4 告警分组、抑制与静默的实际配置Alertmanager最容易被忽视的功能是分组、抑制和静默但恰恰是这三个功能决定了告警系统能不能真正投入使用。分组grouping把同类告警合并成一条通知。比如Grafana里同时有20个GPU节点温度过高如果不分组值班人员的钉钉会被20条消息刷屏。配置示例route: group_by: [alertname, component] group_wait: 30s group_interval: 5m repeat_interval: 4h receiver: webhook-dingtalk抑制inhibition解决的是根因和衍生告警的噪音问题。比如某个节点宕机了那么该节点的所有Pod、GPU、训练任务都会相继告警这些衍生告警对定位问题没有帮助。配置一个抑制规则让“节点宕机”这个高优先级告警抑制掉同节点上的低优先级告警inhibit_rules: - source_matchers: - severity critical - alertname NodeDown target_matchers: - severity ~ warning|info equal: - instance静默silencing用于已知维护窗口的屏蔽。比如GPU服务器计划内升级提前在Alertmanager上配置一条静默规则避免维护期间误报打扰。3.5 告警通知渠道钉钉/Webhook的接入方式通知渠道这块AI平台团队的实际情况是告警接收者可能分布在大群、专项群、个人钉钉等多个场景。我建议按告警级别区分通知渠道告警级别通知方式场景说明P0 紧急钉钉群所有人 电话平台不可用、大量训练失败、数据丢失P1 严重钉钉群值班人GPU故障、调度器异常、推理服务错误率超标P2 警告钉钉群普通消息资源紧张、任务排队超时、特征管道积压P3 提示邮件/站内信模型版本变化、训练任务正常结束等生命周期信息钉钉Webhook的接入方式比较简单Alertmanager配置一个webhook receiver把告警消息POST到钉钉机器人的Webhook地址即可。关键是对消息体做一次格式化处理让告警内容在钉钉里清晰易读。我自己写了一个简单的转换组件把Prometheus的告警内容转成钉钉Markdown格式效果远好于直接发原始JSON。4. AI开发平台监控告警的落地实践4.1 部署架构与组件清单落地这套监控体系建议的部署拓扑如下Prometheus主实例负责指标采集、存储和告警规则计算数据保留15天每天约50GB数据量因平台规模而异可调GPU Exporter部署在每个GPU节点上采集GPU温度、利用率、显存、ECC错误等指标Node Exporter部署在每个节点上采集CPU、内存、磁盘、网络等基础指标平台业务Exporter部署在AI平台服务中暴露任务调度、队列长度、推理服务等业务指标Alertmanager负责告警路由、分组、抑制、静默Grafana负责可视化看板如果平台规模较大还可以加一套Thanos或VictoriaMetrics做长期存储和横向扩展。小规模环境少于30个节点直接用单机Prometheus就够了不用过度设计。4.2 核心采集配置GPU Exporter的部署要点GPU指标采集我用的最顺手的是nvidia_gpu_exporter配合Prometheus的K8s服务发现。部署要点apiVersion: apps/v1 kind: DaemonSet metadata: name: nvidia-gpu-exporter namespace: monitoring spec: selector: matchLabels: app: nvidia-gpu-exporter template: metadata: labels: app: nvidia-gpu-exporter spec: containers: - name: nvidia-gpu-exporter image: nvidia/gpu-prometheus-exporter:latest securityContext: capabilities: add: [SYS_ADMIN] env: - name: NVIDIA_VISIBLE_DEVICES value: all volumeMounts: - name: nvidia mountPath: /usr/local/nvidia readOnly: trueDaemonSet方式部署的好处是每个GPU节点自动拉起一个exporter不用手动给每台机器配IP。注意securityContext的SYS_ADMIN权限是必需的没有这个权限exporter读不到GPU的NVML库信息。4.3 从“能看”到“能用”可视化看板的设计思路Grafana看板不是数据图表堆得越多越好。我实际使用的看板分三个层级第一层是总览看板整个平台的核心健康状态一屏显示包括GPU总量/已分配/空闲、运行中任务数、Pending任务数、推理服务QPS与错误率。这是给平台负责人和管理者看的一眼扫过去就能知道平台整体是否正常。第二层是专项看板按主题拆分的详细看板比如“训练任务状态看板”“GPU资源健康看板”“推理服务性能看板”“数据管道积压看板”。每个专项看板针对一个技术方向给对应的工程师团队使用。第三层是单任务/单节点下钻看板从总览看板点击任务ID或节点名能下钻到具体任务或节点的详细指标。这个下钻能力不需要额外开发通过Grafana的变量联动就能实现。4.4 告警配置模板化版本管理与批量更新告警规则多起来之后配置管理就变成了一个隐形问题。我和团队的做法是把所有告警规则按组件拆分成独立YAML文件存到Git仓库里走GitOps流程管理。每次修改规则交PR审查合并然后通过CI流水线自动reload到Prometheus。模板化之后的告警规则看起来是这样的结构monitoring/ ├── rules/ │ ├── base-node.yaml │ ├── gpu-health.yaml │ ├── training-job.yaml │ ├── inference-service.yaml │ ├──># 1. 本地起一个Prometheus容器挂载规则文件进行语法检查 docker run --rm -v $(pwd)/rules:/etc/prometheus/rules \ -v $(pwd)/prometheus.yml:/etc/prometheus/prometheus.yml \ prom/prometheus --config.file/etc/prometheus/prometheus.yml --dry-run # 2. 在Prometheus UI的Alerts页面查看规则加载状态 # 每个规则的状态如果是OK表示正常加载 # 3. 用promtool做规则单元测试 promtool test rules test.ymlpromtool支持编写测试用例可以预先定义一组模拟指标数据验证告警规则是否正确触发。这个功能对于告警阈值的调优特别实用不用等真实故障发生再验证规则是否合理。6.4 Grafana看板变量联动失效的排查现象在下拉框选择某个训练任务后看板数据不变化。排查思路检查变量定义的query是否符合Grafana的语法比如Prometheus数据源的变量查询必须以label_values()或query_result()开头检查panel的查询语句是否引用了变量比如$task_id是否出现在PromQL中确认变量的“刷新”设置是否合理如果设置了“On Time Range Change”但时间范围没变化数据就不会刷新多数情况下变量联动问题出在PromQL里变量名的引用方式上。在Prometheus数据源中字符串类型的变量要用双引号包起来比如{task_id$task_id}。7. 我的几点实操心得这个监控告警体系从想法到落地前后经历了大半年时间中间踩过不少坑。最后分享几个我认为最值得注意的经验。第一监控体系上线初期不要太追求“完美覆盖”。先把最核心的GPU异常、训练任务失败、推理服务不可用这几个告警做扎实跑一两个月再逐步扩充。一上来就想把所有指标都配上告警大概率会因为误报太多被团队抵制。第二告警阈值的调优是个持续过程。第一次设定的阈值只是起点要结合每次故障复盘和告警准确率持续调整。我见过很多团队一开始把阈值设得很敏感天天告警后来慢慢麻木也有团队一开始太保守重要故障漏报。合理的状态是“一周有几条大家会认真看的告警”而不是“一天几十条没人理会的打扰”。第三监控告警系统本身也是系统需要和业务平台一起纳入运维保障范围。Prometheus挂了我们怎么知道Alertmanager服务挂了谁在接收通知Grafana看板打不开怎么办这些监控系统自身的可用性问题要提前想好预案。最后想说的一点是AI开发平台的监控告警它的目标不是把所有指标都监控起来而是在故障发生的时候让人能更快地知道发生了什么、哪里出了问题、应该找谁。如果把AI开发平台比作一条生产线监控告警就是产线上的仪表盘和报警灯。仪表盘做得再漂亮报警灯不响或者乱响生产线照样会出事。所以做这套系统别追求做得“多”要追求做得“准”和“稳”。希望这篇分享能给你一些启发。如果后续你在落地过程中遇到什么问题欢迎在评论区留言交流。
AI开发平台监控告警实战：从GPU指标到精准告警体系
1. 为什么AI开发平台比普通业务系统更需要监控告警AI开发平台的监控告警表面上看起来像是在做“老本行”——采集指标、设阈值、发通知但真正上手之后你会发现它和监控一个普通Web业务系统完全是两码事。先说说我自己的经历。我们团队负责的AI开发平台上线初期沿用了一套通用监控方案指标采集、图表展示、告警通知一应俱全。结果上线不到一周就出了两次事故一次是分布式训练任务因为某个节点显存耗尽被反复重启作业队列堆积了上百个任务平台用户在线吐槽“训练任务排不上队”另一次是数据预处理管道因为上游数据源格式变化直接卡死模型评估结果延迟了整整半天业务侧以为模型效果退化差点把回滚流程都走了。事后复盘的时候大家才发现传统监控方案里那几个CPU、内存、磁盘的告警规则根本覆盖不了AI平台的真实风险点。GPU利用率、训练任务状态、推理服务延迟、数据管道积压量、模型版本漂移这些指标才是AI平台能不能稳定跑起来的关键。这篇文章我会用一线运维和平台建设的视角把AI开发平台异常指标实时监控告警体系从设计到落地的完整思路拆开讲清楚。不管你是平台工程师、算法工程师还是运维负责人只要日常工作需要和AI开发平台打交道这篇文章都能给你一套可以直接参考的落地方案。注意这里讨论的“AI开发平台”指的是承载模型训练、模型推理、数据集管理、自动化测试等功能的统一平台它是算法团队的日常作业系统和单纯跑一两个模型脚本完全是两个量级的基础设施。2. 监控体系设计AI平台需要盯住哪些异常指标2.1 先搞清楚AI平台的分层结构一个典型的AI开发平台从上到下大致可以分为四层应用接入层模型训练任务入口、推理服务调用API、数据标注/数据管理界面、自动化测试执行引擎平台能力层任务调度器、资源配额管理器、模型仓库、特征存储、实验跟踪组件资源调度层Kubernetes集群、GPU资源池、分布式存储、消息队列基础设施层物理服务器、操作系统、网络、GPU/NPU等异构加速设备每一层都有各自的异常模式而且异常往往会跨层传导。比如底层一台GPU服务器温控异常触发降频中层任务调度器感知到节点资源异常开始驱逐Pod上层训练任务被频繁重调度最终用户看到的就是“训练速度变慢”“任务老是中断”。所以监控指标的设计不能只看单点数据必须分层覆盖同时建立跨层关联分析能力。2.2 基础设施层GPU/NPU资源的专项监控普通业务平台的监控重点在CPU、内存、磁盘IO、网络带宽AI平台在此基础上还要增加对GPU/NPU这类异构加速设备的专项监控而且这部分的指标远比常规硬件监控复杂。GPU相关指标至少需要覆盖以下几类指标类别具体指标异常含义利用率GPU利用率、显存使用率、GPU显存带宽利用率长时间为0说明任务未跑起来显存占用过高容易OOM温度与功耗GPU温度、核心温度、功耗温度过高会触发降频训练速度断崖式下跌硬件健康ECC错误计数、PCIe链路错误、NVLink带宽ECC错误持续增长是硬件即将故障的前兆任务状态SM占用率、张量核心利用率、显存分配失败次数判断训练是否真正利用了GPU算力这里有个典型的误区很多人只看GPU利用率觉得利用率高就万事大吉。实际上GPU利用率高也可能是在空转。有些训练脚本因为数据加载IO瓶颈GPU每个step都在等待数据利用率曲线呈现密集的锯齿状。表面看利用率在80%以上实际有效计算时间只有一半。所以GPU监控建议同时看利用率和等待时长两个维度配合训练日志的数据加载耗时才能定位真正的瓶颈。2.3 平台能力层调度、队列与训练任务的健康指标平台层最核心的是任务调度器。无论是自研调度器还是基于K8s都需要关注以下指标Pending任务数量排队中的任务数量异常增长说明资源不足或调度策略异常任务调度时延从提交到开始执行的时间差正常情况下应该在秒级到分钟级任务失败率与重试次数失败率突增通常是代码问题、资源问题或数据问题的信号任务运行时长分布同类任务运行时长突然翻倍大概率是资源被抢占或性能劣化训练任务的状态监控也很关键。一个训练任务从提交到完成会经过Pending、Running、Succeeded、Failed等状态每个状态转换都应该有记录。实际操作中我习惯给任务状态转换加一个时间戳监控比如一个任务在Pending状态卡了超过30分钟就触发告警。这个阈值不能设得太激进因为有些大模型训练任务在排队等资源时本身就是设计好的优先级调度卡个把小时也是正常的。2.4 应用层推理服务、模型效果和数据管道AI平台除了训练还有很大一部分业务在推理服务上。推理服务的核心指标包括推理请求QPS与RT响应时间RT出现长尾用户体验会明显劣化推理错误率5xx错误率超过0.1%就要警惕GPU显存占用趋势推理服务显存缓慢增长大概率存在内存泄漏模型版本分布线上跑了多个版本时要监控版本切换是否有异常回退数据管道这块容易被忽略。AI平台的自动化测试、数据预处理、特征工程往往依赖管道任务。管道任务的关键指标是积压量和处理时延。我用过一个很简单的告警方式给每个管道任务的积压消息数设一个阈值连续3个采集周期超过阈值就告警。听起来很简单但实际排查问题时这个指标帮我快速定位过多次数据源故障。2.5 监控指标维度的两个“坑”指标设计得再全维度选不对也白搭。两个常见问题第一个是维度过粗。比如只按整个集群汇总GPU利用率某台机器已经因为硬件故障导致利用率归零汇总数据可能只是在95%掉到93%完全看不出异常。我建议至少按节点、按GPU卡两个维度分别建立监控高级一点还可以按训练任务维度打标签这样一张GPU利用率曲线拉出来哪台机器、哪张卡、哪个任务有问题一目了然。第二个是维度爆炸。标签设计要克制有些团队为了将来回溯方便把几十个标签全都打上。采集端倒是无所谓但告警规则一旦涉及多标签聚合PromQL查询性能会肉眼可见地变差。我的经验是核心指标标签控制在5-8个预留两个扩展位就够用了。3. 实时监控与告警从数据采集到通知触达的完整链路3.1 技术选型为什么我选择Prometheus Grafana AlertmanagerAI开发平台的监控告警组件选型我个人推荐Prometheus Grafana Alertmanager这套组合它的优势非常明显Prometheus是云原生监控的事实标准K8s生态天然适配AI平台基本都跑在K8s上采集指标直接走服务发现零配置介入Alertmanager是Prometheus官方告警组件负责告警路由、分组、抑制、静默AI平台告警量大的场景下表现稳定Grafana的图表生态足够丰富GPU监控、训练任务看板、推理服务SLO看板这类可视化需求都能满足这三者都是开源组件社区资料丰富遇到问题网上基本都能找到解决方案如果团队预算充足也可以考虑引入商业化APM或者云厂商托管监控服务但底层逻辑和告警策略设计和开源方案是相通的。下面的内容我以Prometheus生态为例展开。3.2 告警规则的阈值计算逻辑告警阈值设多少直接决定这套系统的实用程度。阈值设太高故障瞒报设太低告警轰炸到没人看。阈值的设定不能拍脑袋我习惯分三步走第一先采集两周以上的指标基线数据。监控系统上线初期先只采集不告警把各项指标的正常波动范围摸清楚。比如训练任务调度时延正常情况下P99在15秒左右高峰期偶尔到45秒那初始阈值可以设在60秒。第二用统计学方法确定阈值。对基线数据计算均值和标准差初始阈值设为均值加3倍标准差。这个数值不是一成不变的后续根据实际告警准确率持续调优。第三区分“绝对值阈值”和“相对变化阈值”。有些指标适合用绝对值比如GPU温度大于85度告警有些指标则要看相对变化比如推理错误率在5分钟内上升了3倍才告警单纯设绝对值容易误报。3.3 告警规则配置的实战写法下面是一段我在训练任务监控场景中实际用过的Prometheus告警规则配置groups: - name: ai-platform-training rules: - alert: TrainingTaskPendingTooLong expr: time() - max(ai_task_status_change_time{statusPending}) by (task_id) 1800 for: 5m labels: severity: warning component: scheduler annotations: summary: 训练任务 {{ $labels.task_id }} 排队超过30分钟 description: 任务已等待 {{ $value }} 秒请检查资源池是否有可用GPU资源 - alert: GPUUtilizationDropToZero expr: avg(ai_gpu_utilization{jobgpu-exporter}) by (instance, gpu_id) 0 for: 10m labels: severity: critical component: gpu annotations: summary: GPU {{ $labels.instance }} / {{ $labels.gpu_id }} 利用率持续为0 description: GPU利用率连续10分钟为0训练任务可能已挂起或存在硬件故障这里几个细节值得说明一下for: 5m的作用是“持续时间”过滤。瞬时抖动不告警持续5分钟才告警能过滤掉大量噪声expr中要善用by (task_id)等聚合操作告警的内容才会带着足够多的上下文信息labels里打上severity和component标签方便后面告警路由做分组匹配3.4 告警分组、抑制与静默的实际配置Alertmanager最容易被忽视的功能是分组、抑制和静默但恰恰是这三个功能决定了告警系统能不能真正投入使用。分组grouping把同类告警合并成一条通知。比如Grafana里同时有20个GPU节点温度过高如果不分组值班人员的钉钉会被20条消息刷屏。配置示例route: group_by: [alertname, component] group_wait: 30s group_interval: 5m repeat_interval: 4h receiver: webhook-dingtalk抑制inhibition解决的是根因和衍生告警的噪音问题。比如某个节点宕机了那么该节点的所有Pod、GPU、训练任务都会相继告警这些衍生告警对定位问题没有帮助。配置一个抑制规则让“节点宕机”这个高优先级告警抑制掉同节点上的低优先级告警inhibit_rules: - source_matchers: - severity critical - alertname NodeDown target_matchers: - severity ~ warning|info equal: - instance静默silencing用于已知维护窗口的屏蔽。比如GPU服务器计划内升级提前在Alertmanager上配置一条静默规则避免维护期间误报打扰。3.5 告警通知渠道钉钉/Webhook的接入方式通知渠道这块AI平台团队的实际情况是告警接收者可能分布在大群、专项群、个人钉钉等多个场景。我建议按告警级别区分通知渠道告警级别通知方式场景说明P0 紧急钉钉群所有人 电话平台不可用、大量训练失败、数据丢失P1 严重钉钉群值班人GPU故障、调度器异常、推理服务错误率超标P2 警告钉钉群普通消息资源紧张、任务排队超时、特征管道积压P3 提示邮件/站内信模型版本变化、训练任务正常结束等生命周期信息钉钉Webhook的接入方式比较简单Alertmanager配置一个webhook receiver把告警消息POST到钉钉机器人的Webhook地址即可。关键是对消息体做一次格式化处理让告警内容在钉钉里清晰易读。我自己写了一个简单的转换组件把Prometheus的告警内容转成钉钉Markdown格式效果远好于直接发原始JSON。4. AI开发平台监控告警的落地实践4.1 部署架构与组件清单落地这套监控体系建议的部署拓扑如下Prometheus主实例负责指标采集、存储和告警规则计算数据保留15天每天约50GB数据量因平台规模而异可调GPU Exporter部署在每个GPU节点上采集GPU温度、利用率、显存、ECC错误等指标Node Exporter部署在每个节点上采集CPU、内存、磁盘、网络等基础指标平台业务Exporter部署在AI平台服务中暴露任务调度、队列长度、推理服务等业务指标Alertmanager负责告警路由、分组、抑制、静默Grafana负责可视化看板如果平台规模较大还可以加一套Thanos或VictoriaMetrics做长期存储和横向扩展。小规模环境少于30个节点直接用单机Prometheus就够了不用过度设计。4.2 核心采集配置GPU Exporter的部署要点GPU指标采集我用的最顺手的是nvidia_gpu_exporter配合Prometheus的K8s服务发现。部署要点apiVersion: apps/v1 kind: DaemonSet metadata: name: nvidia-gpu-exporter namespace: monitoring spec: selector: matchLabels: app: nvidia-gpu-exporter template: metadata: labels: app: nvidia-gpu-exporter spec: containers: - name: nvidia-gpu-exporter image: nvidia/gpu-prometheus-exporter:latest securityContext: capabilities: add: [SYS_ADMIN] env: - name: NVIDIA_VISIBLE_DEVICES value: all volumeMounts: - name: nvidia mountPath: /usr/local/nvidia readOnly: trueDaemonSet方式部署的好处是每个GPU节点自动拉起一个exporter不用手动给每台机器配IP。注意securityContext的SYS_ADMIN权限是必需的没有这个权限exporter读不到GPU的NVML库信息。4.3 从“能看”到“能用”可视化看板的设计思路Grafana看板不是数据图表堆得越多越好。我实际使用的看板分三个层级第一层是总览看板整个平台的核心健康状态一屏显示包括GPU总量/已分配/空闲、运行中任务数、Pending任务数、推理服务QPS与错误率。这是给平台负责人和管理者看的一眼扫过去就能知道平台整体是否正常。第二层是专项看板按主题拆分的详细看板比如“训练任务状态看板”“GPU资源健康看板”“推理服务性能看板”“数据管道积压看板”。每个专项看板针对一个技术方向给对应的工程师团队使用。第三层是单任务/单节点下钻看板从总览看板点击任务ID或节点名能下钻到具体任务或节点的详细指标。这个下钻能力不需要额外开发通过Grafana的变量联动就能实现。4.4 告警配置模板化版本管理与批量更新告警规则多起来之后配置管理就变成了一个隐形问题。我和团队的做法是把所有告警规则按组件拆分成独立YAML文件存到Git仓库里走GitOps流程管理。每次修改规则交PR审查合并然后通过CI流水线自动reload到Prometheus。模板化之后的告警规则看起来是这样的结构monitoring/ ├── rules/ │ ├── base-node.yaml │ ├── gpu-health.yaml │ ├── training-job.yaml │ ├── inference-service.yaml │ ├──># 1. 本地起一个Prometheus容器挂载规则文件进行语法检查 docker run --rm -v $(pwd)/rules:/etc/prometheus/rules \ -v $(pwd)/prometheus.yml:/etc/prometheus/prometheus.yml \ prom/prometheus --config.file/etc/prometheus/prometheus.yml --dry-run # 2. 在Prometheus UI的Alerts页面查看规则加载状态 # 每个规则的状态如果是OK表示正常加载 # 3. 用promtool做规则单元测试 promtool test rules test.ymlpromtool支持编写测试用例可以预先定义一组模拟指标数据验证告警规则是否正确触发。这个功能对于告警阈值的调优特别实用不用等真实故障发生再验证规则是否合理。6.4 Grafana看板变量联动失效的排查现象在下拉框选择某个训练任务后看板数据不变化。排查思路检查变量定义的query是否符合Grafana的语法比如Prometheus数据源的变量查询必须以label_values()或query_result()开头检查panel的查询语句是否引用了变量比如$task_id是否出现在PromQL中确认变量的“刷新”设置是否合理如果设置了“On Time Range Change”但时间范围没变化数据就不会刷新多数情况下变量联动问题出在PromQL里变量名的引用方式上。在Prometheus数据源中字符串类型的变量要用双引号包起来比如{task_id$task_id}。7. 我的几点实操心得这个监控告警体系从想法到落地前后经历了大半年时间中间踩过不少坑。最后分享几个我认为最值得注意的经验。第一监控体系上线初期不要太追求“完美覆盖”。先把最核心的GPU异常、训练任务失败、推理服务不可用这几个告警做扎实跑一两个月再逐步扩充。一上来就想把所有指标都配上告警大概率会因为误报太多被团队抵制。第二告警阈值的调优是个持续过程。第一次设定的阈值只是起点要结合每次故障复盘和告警准确率持续调整。我见过很多团队一开始把阈值设得很敏感天天告警后来慢慢麻木也有团队一开始太保守重要故障漏报。合理的状态是“一周有几条大家会认真看的告警”而不是“一天几十条没人理会的打扰”。第三监控告警系统本身也是系统需要和业务平台一起纳入运维保障范围。Prometheus挂了我们怎么知道Alertmanager服务挂了谁在接收通知Grafana看板打不开怎么办这些监控系统自身的可用性问题要提前想好预案。最后想说的一点是AI开发平台的监控告警它的目标不是把所有指标都监控起来而是在故障发生的时候让人能更快地知道发生了什么、哪里出了问题、应该找谁。如果把AI开发平台比作一条生产线监控告警就是产线上的仪表盘和报警灯。仪表盘做得再漂亮报警灯不响或者乱响生产线照样会出事。所以做这套系统别追求做得“多”要追求做得“准”和“稳”。希望这篇分享能给你一些启发。如果后续你在落地过程中遇到什么问题欢迎在评论区留言交流。