生产环境监控怎么做，Prometheus 加 Grafana 守护 AMD 集群

从“盲跑”到“可观测”AMD 集群监控实战在 AMD Instinct GPU 集群上跑通 vLLM 只是第一步真正让团队安心的是知道它在生产环境里到底“稳不稳”。之前我们花了不少时间解决 ROCm 7.x 的编译坑和显存优化问题但服务上线后如果缺乏有效的监控手段一旦遇到显存泄漏或温度异常往往只能等到用户投诉才发现。对于承载大模型推理的生产集群而言可观测性不是锦上添花而是生存底线。今天就来聊聊如何基于 Prometheus 和 Grafana为 AMD 集群搭建一套轻量却硬核的监控体系重点解决 GPU 核心指标的采集与告警落地。为什么 AMD 集群监控容易“踩空”很多开发者习惯了 NVIDIA 生态下的 DCGM 工具链切换到 AMD 平台时容易陷入误区。虽然 ROCm 提供了rocm-smi等命令行工具查看实时状态但在生产环境中靠人工轮询或写脚本抓取日志显然无法应对高并发场景。我们需要的是能够持续采集历史数据、支持多维度聚合分析并能即时触发告警的系统。AMD 官方其实已经提供了对应的 exporter 方案关键在于如何将其无缝集成到现有的 Prometheus 栈中。不同于 CPU 监控的通用性GPU 监控需要关注更细粒度的指标不仅仅是利用率更重要的是显存碎片化趋势、功耗波动曲线以及温度阈值。特别是在运行 vLLM 这种对显存管理极其敏感的服务时任何微小的显存泄漏都可能在数小时后导致 OOMOut Of Memory崩溃而传统的系统监控往往无法在早期捕捉到这一征兆。部署 DCGM Exporter 采集核心指标在 AMD 环境下我们通常使用适配后的 DCGM exporter或 ROCm 自带的监控导出组件来暴露指标。假设你的集群已经安装了 ROCm 驱动并能正常识别显卡第一步是确保 exporter 能正确读取硬件传感器数据。可以通过 Docker 快速部署 exporter 容器注意需要以特权模式运行并挂载相关设备文件dockerrun-d--gpusall--pidhost\-p9400:9400\--namedcgm-exporter\nvcr.io/nvidia/k8s/dcgm-exporter:3.1.7-3.1.5-ubuntu22.04\# 注此处需替换为适配 AMD 的 exporter 镜像或使用社区维护版本注实际生产中建议使用社区针对 ROCm 适配的 exporter 版本确保能识别gfx942等架构代码。启动后访问http://node-ip:9400/metrics应该能看到类似DCGM_FI_DEV_GPU_TEMP、DCGM_FI_DEV_POWER_USAGE和DCGM_FI_DEV_FB_USED等指标。这些分别对应显卡温度、实时功耗和显存使用量。为了验证数据准确性可以同时在终端运行rocm-smi --showall进行比对确保 exporter 上报的数值与底层驱动一致。配置 Prometheus 抓取与告警规则数据采集上来后需要在 Prometheus 的配置文件中添加新的 job 来定期拉取 metrics。在prometheus.yml中加入scrape_configs:-job_name:amd-gpu-clusterstatic_configs:-targets:[exporter-node-ip:9400]scrape_interval:15s接下来是最关键的告警策略。根据我们在生产环境的经验显存使用率是最需要警惕的指标。vLLM 在高负载下可能会因为 KV Cache 动态增长而瞬间吃满显存。我们设置了一条规则当显存使用率超过 95% 且持续时间达到 1 分钟时立即触发告警。这给了系统一定的缓冲期避免因瞬时尖刺误报又能及时拦截真正的泄漏风险。Prometheus 告警规则示例groups:-name:gpu_alertsrules:-alert:HighGpuMemoryUsageexpr:(DCGM_FI_DEV_FB_USED / DCGM_FI_DEV_FB_TOTAL)0.95for:1mlabels:severity:criticalannotations:summary:GPU 显存使用率过高description:实例 {{ $labels.instance }} 的 GPU 显存使用率已超过 95%持续 1 分钟。此外温度告警也不容忽视。AMD Instinct 系列虽然散热设计优秀但在密闭机柜中长时间满载仍可能触发热节流。建议将温度阈值设定在 85°C 左右提前介入干预。Grafana 可视化面板搭建技巧有了数据和告警最后一步是通过 Grafana 让运维人员一眼看清集群健康度。创建一个全新的 Dashboard添加 Prometheus 数据源后重点构建以下几个面板全局概览使用 Stat 面板展示集群整体平均温度、总功耗和显存剩余容量用颜色区分健康状态绿/黄/红。单卡详情利用 Time series 图表绘制每张卡的显存使用率曲线。这里有个小技巧开启Fill below to zero并设置透明度可以直观看到显存波动的“水位线”。热力图分布如果集群规模较大可以用 Heatmap 展示不同时间段内 GPU 利用率的分布情况帮助识别业务高峰期和资源闲置时段。在面板变量设置中建议加入GPU_ID和Hostname的下拉筛选器方便快速定位特定故障节点。曾经有一次我们通过面板发现某张卡的功耗曲线异常平缓即使在高负载请求下也没有波动最终排查发现是该卡进入了降频保护模式及时更换避免了更大范围的服務中断。让监控成为稳定性基石监控系统的价值不在于展示漂亮的图表而在于它能帮你把故障消灭在萌芽状态。通过 Prometheus Grafana DCGM exporter 的组合我们不仅实现了对 AMD 集群温度的实时监控更重要的是建立了一套基于数据的运维决策机制。当显存告警响起时运维人员不再是盲目重启服务而是能依据历史曲线判断是流量突增还是内存泄漏从而采取扩容或回滚等精准措施。在大模型推理这条赛道上硬件性能决定了上限而监控体系决定了下限。只有把“黑盒”变成“白盒”才能让 AMD 集群真正成为生产环境中可靠的生产力工具。200小时GPU算力已就位快来领取https://marketing.csdn.net/questions/Q2604140858304426315?utm_sourceAIpaper