尧图网站建设 
Nightingale 生态 GPU 监控实战Categraf 双方案nvidia_smi 与 DCGM采集 NVIDIA GPU 指标【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingaleNVIDIA GPU 是 AI 训练与推理场景的核心算力资源其利用率、显存、温度、功耗、NVLink 带宽等指标直接决定集群调度效率与硬件健康度。本文基于 Nightingale 监控体系中的 Categraf 采集器完整讲解 NVIDIA GPU 监控的两种主流方案input.nvidia_smi读取 nvidia-smi 命令输出与input.dcgm对接 DCGM 服务从原理、安装前置依赖、采集配置到指标字典、看板与告警规则的完整落地。读完本文你可以根据实际场景在轻量部署与深度可观测之间做出正确选型并在 Nightingale 中完成从指标采集、可视化到告警的全链路配置。一、两种采集方案总览Categraf 采集 NVIDIA GPU 支持两种方式分别对应两个采集插件对比项input.nvidia_smiinput.dcgm数据来源执行本机nvidia-smi命令解析其输出与nvidia-dcgm服务交互获取数据前置依赖仅需 NVIDIA 驱动自带 nvidia-smi 命令需额外安装并启动 nvidia-dcgm 服务Categraf 版本要求普通版本即可需要with-cgo-plugin编译版本指标丰富度基础指标利用率、显存、温度、功耗、时钟等覆盖利用率、显存、温度、功耗、PCIe/NVLink 带宽、各类 Violation 等深度指标定位轻量、开箱即用深度可观测适合大规模 GPU 集群特别提醒DCGM 插件内部与 nvidia-dcgm 的 C 库交互因此必须安装 Categraf 的 with-cgo-plugin 版本才能正常工作这是使用 DCGM 方案前最容易踩的坑。二、方案一nvidia_smi 插件采集2.1 采集原理input.nvidia_smi插件的原理非常直接读取本机nvidia-smi命令的内容输出转换为 Prometheus 格式的监控数据再上报给 Nightingale 夜莺。由于不依赖任何额外的守护进程只要机器装有 NVIDIA 驱动自带 nvidia-smi 命令即可快速接入采集。从实现来源看该插件是对开源项目 nvidia_gpu_exporter 代码的集成集成资源位于 integrations/NVIDIA 目录其中 collect/nvidia_smi/nvidia_smi.toml 为插件采集配置的仓库副本。2.2 采集配置配置文件位于 Categraf 部署目录的conf/input.nvidia_smi/nvidia_smi.toml完整配置如下# # collect interval # interval 15 # 下面这个配置是最重要的配置如果要采集 nvidia-smi 的信息就打开下面的配置 # 给出 nvidia-smi 命令的路径最好是给绝对路径 # 相当于让 Categraf 执行本机的 nvidia-smi 命令获取本机 GPU 的状态信息 # exec local command # nvidia_smi_command nvidia-smi # 如果想远程方式采集远端机器的 GPU 状态信息可以使用 ssh 命令登录远端机器 # 在远端机器执行 nvidia-smi 的命令输出通常 Categraf 是部署在每个物理机上的 # 所以ssh 这种方式理论上用不到 # exec remote command # nvidia_smi_command ssh -o StrictHostKeyCheckingno -o UserKnownHostsFile/dev/null SSH_USERSSH_HOST nvidia-smi # Comma-separated list of the query fields. # You can find out possible fields by running nvidia-smi --help-query-gpu. # The value AUTO will automatically detect the fields to query. query_field_names AUTO核心参数说明interval采集间隔秒默认 15。NVIDIA GPU 指标变化快训练任务调度场景可适当缩短但注意不要过于频繁执行命令造成额外开销。nvidia_smi_command最重要的配置。本地采集时给出nvidia-smi命令路径最好给绝对路径如/usr/bin/nvidia-smiCategraf 会执行该命令获取本机 GPU 状态。远程采集时可用 ssh 命令登录远端机器执行 nvidia-smi 输出。由于 Categraf 通常逐物理机部署ssh 远程方式在理论上基本用不到。query_field_names以逗号分隔的查询字段列表可执行nvidia-smi --help-query-gpu查看支持的全部字段取值为AUTO时自动探测要查询的字段这也是仓库配置中的默认值。2.3 产出指标与可视化看板开启采集后插件会以nvidia_smi_前缀产出指标。从仓库自带的看板 dashboards/nvidia-gpu-metrics-by-categraf.json 的查询表达式可以看到该插件产出的典型指标包括nvidia_smi_utilization_gpu_ratio/nvidia_smi_utilization_memory_ratioGPU / 显存利用率nvidia_smi_memory_used_bytes/nvidia_smi_memory_total_bytes显存使用与总量nvidia_smi_temperature_gpuGPU 温度nvidia_smi_power_draw_watts/nvidia_smi_power_default_limit_watts实时功耗与默认功耗上限nvidia_smi_fan_speed_ratio风扇转速nvidia_smi_clocks_current_graphics_clock_hz/nvidia_smi_clocks_current_memory_clock_hz等显存/图形/SM 时钟频率nvidia_smi_clocks_throttle_reasons_*各类降频原因GPU Idle、热降频、功耗上限、应用时钟设置、功率刹车等nvidia_smi_gpu_infoGPU 基础信息配合uuid标签定位单卡该看板以 GPU uuid 为筛选维度覆盖总览、利用率、温度、功耗、时钟、显存、降频原因等面板可直接在 Nightingale 中导入使用。三、方案二DCGM 插件采集3.1 插件来源与版本要求DCGM 采集插件是 dcgm-exporter 的 fork通过nvidia-dcgmData Center GPU Manager服务获取数据。与 nvidia_smi 方案不同DCGM 提供的是数据中心级的深度指标包含 PCIe/NVLink 吞吐、SM/Tensor/FP16/FP32/FP64 管道活跃度、各类功耗与热限制 Violation 等是规模化 GPU 集群可观测性的标准方案。前提条件需要 Categraf 的with-cgo-plugin版本。普通二进制版本不带 CGO 插件支持直接使用 DCGM 插件会无法工作。3.2 前置依赖安装并启动 nvidia-dcgm 服务DCGM 插件与 nvidia-dcgm 交互获取数据所以必须先安装 nvidia-dcgm 服务Ubuntu 系列系统通过 apt 安装注意版本号不要搞错apt-get install -y datacenter-gpu-manager1:3.3.5理论上升级到大于该版本且低于 4.0.0 的版本也可以但请务必确认版本落在1:3.3.x区间。CentOS 系统需要到 NVIDIA 官方 CUDA 仓库rhel8 的 x86_64 目录下载对应 rpm 包安装。安装完成后启动服务并确认状态systemctl start nvidia-dcgm.service systemctl status nvidia-dcgm.service只有服务处于 active 状态才能进行下一步的采集配置——这也是 DCGM 方案最常见的失败点插件连不上 5555 端口采集直接无数据。3.3 采集配置使用 DCGM 插件前请确保 Categraf 的conf/input.dcgm/目录下包含以下 3 个 CSV 文件它们是 DCGM 指标定义文件1.x-compatibility-metrics.csvdefault-counters.csvdcp-metrics-included.csv采集配置位于conf/input.dcgm/dcgm.toml仓库副本见 collect/dcgm/dcgm.toml完整内容如下[[instances]] # 指定使用的指标定义文件, 一般使用 default-counters.csv就够了也可以尝试用其他两个csv文件 # path to the file, that contains the DCGM fields to collect collectors conf/input.dcgm/default-counters.csv # 是否是K8s环境设置为true会附加Pod的信息 # Enable kubernetes mapping metrics to kubernetes pods # kubernetesfalse # 指标中是否附加 gpu id 作为一个标签 # Choose Type of GPU ID to use to map kubernetes resources to pods. Possible values: uid, device-name # kubernetes-gpu-id-type uid # 是否使用 1.x 的ns # Use old 1.x namespace # use-old-namespace false # 支持的选项是f g i # f: FlexKey 如果MIG被禁用则监控所有GPU如果MIG被启用则监控所有GPU实例 # g: MajorKey 监控top-level entitiesGPU或NvSwitches或CPU # i: MinorKey 监控sub-level entities: GPU实例/NvLinks/CPU核心 - 如果MIG被禁用则不能指定该选项 cpu-devices f # 与cpu-devices的选项一样 # gpu devices devices f # 与cpu-devices的选项一样 switch-devices f # 使用ConfigMap # ConfigMap NAMESPACE:NAME for metric data configmap-data none # 这里就是前置依赖的nvidia-dcgm服务, 如果是本机采集则使用localhost:5555 ,如果是远程采集则使用远端IP:5555 # Connect to remote hostengine at HOST:PORT remote-hostengine-info localhost:5555 # 允许用户在没有实际GPU硬件的环境中模拟GPU, 仅用于测试 # Accept GPUs that are fake, for testing purposes only # fake-gpus false # 将GPU型号名称中的每个空格替换为破折号确保标识符连续且无空格。 # Replaces every blank space in the GPU model name with a dash, ensuring a continuous, space-free identifier. # replace-blanks-in-model-name false关键参数解读collectors指定指标定义 CSV 文件一般使用default-counters.csv就够用也可尝试另外两个 CSV1.x-compatibility-metrics.csv面向 1.x 兼容指标dcp-metrics-included.csv面向 DCP 场景。kubernetes是否 K8s 环境设为true会把指标映射到 Pod 并附加 Pod 信息便于按工作负载维度观测 GPU。kubernetes-gpu-id-typeGPU ID 类型可选uid或device-name用于将 K8s 资源映射到 Pod。use-old-namespace是否使用 1.x 旧命名空间。cpu-devices / devices / switch-devices设备选择层级可选值为f、g、i三种fFlexKeyMIG 禁用时监控所有 GPUMIG 启用时监控所有 GPU 实例gMajorKey监控顶级实体GPU / NvSwitches / CPUiMinorKey监控子级实体GPU 实例 / NvLinks / CPU 核心MIG 被禁用时不能指定该选项。configmap-data使用 ConfigMap 的方式加载指标数据格式为NAMESPACE:NAME不使用则保持none。remote-hostengine-info前置的 nvidia-dcgm 服务地址本机采集用localhost:5555远程采集用远端IP:5555。fake-gpus允许在没有真实 GPU 硬件的环境中模拟 GPU仅用于测试。replace-blanks-in-model-name将 GPU 型号名称中的空格替换为破折号保证标识符连续无空格。3.4 指标字典38 个 DCGM 指标全览仓库在 metrics/dcgm_by_categraf.json 中提供了 DCGM 指标字典含中英文名称、单位、说明可用于 Nightingale 指标视图展示。共 38 个指标按类别归纳如下基础资源类| 指标名 | 含义 | 单位 | | --- | --- | --- | |DCGM_FI_DEV_GPU_UTIL| GPU 利用率核函数 Active 时间占比 | % | |DCGM_FI_DEV_MEM_COPY_UTIL| 内存带宽利用率 | % | |DCGM_FI_DEV_ENC_UTIL/DCGM_FI_DEV_DEC_UTIL| 编码器 / 解码器利用率 | % | |DCGM_FI_DEV_FB_FREE/DCGM_FI_DEV_FB_USED| 显存剩余 / 已使用对应 nvidia-smi Memory-Usage | MiB | |DCGM_FI_DEV_MEMORY_TEMP/DCGM_FI_DEV_GPU_TEMP| 内存温度 / GPU 温度 | °C | |DCGM_FI_DEV_POWER_USAGE/DCGM_FI_DEV_TOTAL_ENERGY_CONSUMPTION| GPU 功率 / 驱动加载以来总能耗 | W / J |性能剖析类PROF 系列来自 DCGM 性能采样| 指标名 | 含义 | 单位 | | --- | --- | --- | |DCGM_FI_PROF_GR_ENGINE_ACTIVE| 图形/计算引擎活跃时间占比 | % | |DCGM_FI_PROF_SM_ACTIVE| SM 活跃时间占比0.5 说明 GPU 利用不高效0.8 为必要 | % | |DCGM_FI_PROF_SM_OCCUPANCY| SM 线程束占用率内存带宽受限负载下越高越有效 | % | |DCGM_FI_PROF_PIPE_TENSOR_ACTIVE| Tensor Core 管道活跃周期占比 | % | |DCGM_FI_PROF_PIPE_FP64/FP32/FP16_ACTIVE| FP64 / FP32 / FP16 管道活跃周期占比 | % | |DCGM_FI_PROF_DRAM_ACTIVE| DRAM 活跃周期占比内存带宽利用率实际峰值约 0.8 | % | |DCGM_FI_PROF_PCIE_TX_BYTES/DCGM_FI_PROF_PCIE_RX_BYTES| PCIe 发送 / 接收数据速率 | B/s | |DCGM_FI_PROF_NVLINK_RX_BYTES/DCGM_FI_PROF_NVLINK_TX_BYTES| NVLink 接收 / 发送数据速率 | B/s |健康与状态类| 指标名 | 含义 | 单位 | | --- | --- | --- | |DCGM_FI_DEV_XID_ERRORS| 最后发生的 XID 错误号counter | - | |DCGM_FI_DEV_CLOCK_THROTTLE_REASONS| 时钟降频原因 | - | |DCGM_FI_DEV_SM_CLOCK/DCGM_FI_DEV_MEM_CLOCK| SM / 内存时钟频率 | MHz | |DCGM_FI_DEV_APP_SM_CLOCK/DCGM_FI_DEV_APP_MEM_CLOCK| SM / 内存应用时钟频率 | MHz | |DCGM_FI_DEV_POWER_VIOLATION/DCGM_FI_DEV_THERMAL_VIOLATION| 功率上限 / 热限制违规时长 | μs | |DCGM_FI_DEV_SYNC_BOOST_VIOLATION/DCGM_FI_DEV_BOARD_LIMIT_VIOLATION| 同步提升 / 电路板限制违规时长 | μs | |DCGM_FI_DEV_LOW_UTIL_VIOLATION/DCGM_FI_DEV_RELIABILITY_VIOLATION| 低利用率 / 电路板可靠性限制违规时长 | μs | |DCGM_FI_DEV_BAR1_USED/DCGM_FI_DEV_BAR1_FREE| 已使用 / 剩余 BAR1 内存 | MB | |DCGM_FI_DEV_RETIRED_SBE/DCGM_FI_DEV_RETIRED_DBE| 单 bit / 双 bit 错误停用页面数 | - |3.5 开箱即用的告警规则仓库在 alerts/gpu_alert.json 中提供了两条可直接导入 Nightingale 的 Prometheus 告警规则GPU XID 错误DCGM_FI_DEV_XID_ERRORS命中 32/38/48/61/62/63/64/68/74/79/92/94/95 等致命错误码即触发prom_for_duration持续 180s评估间隔 15s重复通知间隔 60s。告警的处置建议annotations给出了标准排查路径先用nvidia-smi -q -d PAGE_RETIREMENT,ECC与dmesg -T | grep -i xid确认具体 XID 码和涉及的卡对照 NVIDIA XID 文档区分软件驱动/CUDA与硬件故障Xid 48/63/64ECC与 79掉卡基本可判定硬件问题应先从调度池摘除该卡K8s 上给节点打 taint软件类升级驱动/CUDA 后复测硬件类走返修流程。GPU 温度过高sum by (Hostname, modelName, gpu) (DCGM_FI_DEV_GPU_TEMP 85)即任一 GPU 温度超过 85°C 触发。处置建议包括用nvidia-smi -q -d TEMPERATURE,PERFORMANCE确认是否已触发 SW/HW Slowdown检查机箱风道、风扇转速与滤网积灰多卡机型需区分单卡高温多为散热器接触或风扇问题与整机高温环境问题短期可用nvidia-smi -pl降低功耗上限或降低任务并发为停机除尘争取时间。四、集成资源结构与导入方式本仓库的 integrations/NVIDIA 目录是一个完整的 GPU 监控集成包除上述采集配置、告警、指标字典外还包括看板dashboards/nvidia-gpu-metrics-by-categraf.jsonnvidia_smi 方案看板dashboards/GPU-Overview-dcgm.jsonDCGM 方案 GPU 总览看板dashboards/GPU-Jobs-dcgm.jsonDCGM 方案按作业维度看板。指标字典metrics/dcgm_by_categraf.json38 个 DCGM 指标的中英文名、单位与注释可导入 Nightingale 指标视图。采集配置collect/nvidia_smi/nvidia_smi.toml 与 collect/dcgm/dcgm.toml即前文两份配置的仓库源文件。实际使用中将这些采集配置同步到 Categraf 的conf/input.nvidia_smi/与conf/input.dcgm/目录注意 DCGM 方案同时需要补齐 3 个 CSV 文件并确保 nvidia-dcgm 服务 active重启 Categraf 即可开始上报看板 JSON 和告警 JSON 则可直接导入 Nightingale 的对应模块实现从采集、展示到告警的完整闭环。五、选型建议快速接入 / 环境简单选nvidia_smi。零额外依赖、配置一行即可适用于 GPU 数量不大、只关注利用率/显存/温度/功耗等基础指标的裸机或虚拟机场景。注意采用 with-cgo-plugin 之外的普通 Categraf 版本即可但若要跑 DCGM 方案则必须换用带 CGO 的版本。大规模 GPU 集群 / 深度可观测选DCGM。配合 K8s 环境kubernetestruekubernetes-gpu-id-type可以按 Pod 维度观测覆盖 NVLink 拓扑、PCIe 吞吐、Tensor/SM/FP 各管道活跃度与各类 Violation 指标是定位 GPU 性能瓶颈、功耗异常和硬件亚健康的标准方案。代价是需要额外维护 nvidia-dcgm 服务与版本匹配关系。两者可并存nvidia_smi 与 DCGM 指标互不冲突生产环境可以先用 nvidia_smi 兜底保证有数据再逐步引入 DCGM 补齐深度指标。最终无论是哪种方案采集到的数据都会以 Prometheus 格式进入 Nightingale配合本文所述的看板与告警规则即可构建起一套覆盖采集 → 可视化 → 告警 → 处置建议的完整 GPU 可观测体系。【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingale创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Nightingale 生态 GPU 监控实战：Categraf 双方案（nvidia_smi 与 DCGM）采集 NVIDIA GPU 指标
Nightingale 生态 GPU 监控实战Categraf 双方案nvidia_smi 与 DCGM采集 NVIDIA GPU 指标【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingaleNVIDIA GPU 是 AI 训练与推理场景的核心算力资源其利用率、显存、温度、功耗、NVLink 带宽等指标直接决定集群调度效率与硬件健康度。本文基于 Nightingale 监控体系中的 Categraf 采集器完整讲解 NVIDIA GPU 监控的两种主流方案input.nvidia_smi读取 nvidia-smi 命令输出与input.dcgm对接 DCGM 服务从原理、安装前置依赖、采集配置到指标字典、看板与告警规则的完整落地。读完本文你可以根据实际场景在轻量部署与深度可观测之间做出正确选型并在 Nightingale 中完成从指标采集、可视化到告警的全链路配置。一、两种采集方案总览Categraf 采集 NVIDIA GPU 支持两种方式分别对应两个采集插件对比项input.nvidia_smiinput.dcgm数据来源执行本机nvidia-smi命令解析其输出与nvidia-dcgm服务交互获取数据前置依赖仅需 NVIDIA 驱动自带 nvidia-smi 命令需额外安装并启动 nvidia-dcgm 服务Categraf 版本要求普通版本即可需要with-cgo-plugin编译版本指标丰富度基础指标利用率、显存、温度、功耗、时钟等覆盖利用率、显存、温度、功耗、PCIe/NVLink 带宽、各类 Violation 等深度指标定位轻量、开箱即用深度可观测适合大规模 GPU 集群特别提醒DCGM 插件内部与 nvidia-dcgm 的 C 库交互因此必须安装 Categraf 的 with-cgo-plugin 版本才能正常工作这是使用 DCGM 方案前最容易踩的坑。二、方案一nvidia_smi 插件采集2.1 采集原理input.nvidia_smi插件的原理非常直接读取本机nvidia-smi命令的内容输出转换为 Prometheus 格式的监控数据再上报给 Nightingale 夜莺。由于不依赖任何额外的守护进程只要机器装有 NVIDIA 驱动自带 nvidia-smi 命令即可快速接入采集。从实现来源看该插件是对开源项目 nvidia_gpu_exporter 代码的集成集成资源位于 integrations/NVIDIA 目录其中 collect/nvidia_smi/nvidia_smi.toml 为插件采集配置的仓库副本。2.2 采集配置配置文件位于 Categraf 部署目录的conf/input.nvidia_smi/nvidia_smi.toml完整配置如下# # collect interval # interval 15 # 下面这个配置是最重要的配置如果要采集 nvidia-smi 的信息就打开下面的配置 # 给出 nvidia-smi 命令的路径最好是给绝对路径 # 相当于让 Categraf 执行本机的 nvidia-smi 命令获取本机 GPU 的状态信息 # exec local command # nvidia_smi_command nvidia-smi # 如果想远程方式采集远端机器的 GPU 状态信息可以使用 ssh 命令登录远端机器 # 在远端机器执行 nvidia-smi 的命令输出通常 Categraf 是部署在每个物理机上的 # 所以ssh 这种方式理论上用不到 # exec remote command # nvidia_smi_command ssh -o StrictHostKeyCheckingno -o UserKnownHostsFile/dev/null SSH_USERSSH_HOST nvidia-smi # Comma-separated list of the query fields. # You can find out possible fields by running nvidia-smi --help-query-gpu. # The value AUTO will automatically detect the fields to query. query_field_names AUTO核心参数说明interval采集间隔秒默认 15。NVIDIA GPU 指标变化快训练任务调度场景可适当缩短但注意不要过于频繁执行命令造成额外开销。nvidia_smi_command最重要的配置。本地采集时给出nvidia-smi命令路径最好给绝对路径如/usr/bin/nvidia-smiCategraf 会执行该命令获取本机 GPU 状态。远程采集时可用 ssh 命令登录远端机器执行 nvidia-smi 输出。由于 Categraf 通常逐物理机部署ssh 远程方式在理论上基本用不到。query_field_names以逗号分隔的查询字段列表可执行nvidia-smi --help-query-gpu查看支持的全部字段取值为AUTO时自动探测要查询的字段这也是仓库配置中的默认值。2.3 产出指标与可视化看板开启采集后插件会以nvidia_smi_前缀产出指标。从仓库自带的看板 dashboards/nvidia-gpu-metrics-by-categraf.json 的查询表达式可以看到该插件产出的典型指标包括nvidia_smi_utilization_gpu_ratio/nvidia_smi_utilization_memory_ratioGPU / 显存利用率nvidia_smi_memory_used_bytes/nvidia_smi_memory_total_bytes显存使用与总量nvidia_smi_temperature_gpuGPU 温度nvidia_smi_power_draw_watts/nvidia_smi_power_default_limit_watts实时功耗与默认功耗上限nvidia_smi_fan_speed_ratio风扇转速nvidia_smi_clocks_current_graphics_clock_hz/nvidia_smi_clocks_current_memory_clock_hz等显存/图形/SM 时钟频率nvidia_smi_clocks_throttle_reasons_*各类降频原因GPU Idle、热降频、功耗上限、应用时钟设置、功率刹车等nvidia_smi_gpu_infoGPU 基础信息配合uuid标签定位单卡该看板以 GPU uuid 为筛选维度覆盖总览、利用率、温度、功耗、时钟、显存、降频原因等面板可直接在 Nightingale 中导入使用。三、方案二DCGM 插件采集3.1 插件来源与版本要求DCGM 采集插件是 dcgm-exporter 的 fork通过nvidia-dcgmData Center GPU Manager服务获取数据。与 nvidia_smi 方案不同DCGM 提供的是数据中心级的深度指标包含 PCIe/NVLink 吞吐、SM/Tensor/FP16/FP32/FP64 管道活跃度、各类功耗与热限制 Violation 等是规模化 GPU 集群可观测性的标准方案。前提条件需要 Categraf 的with-cgo-plugin版本。普通二进制版本不带 CGO 插件支持直接使用 DCGM 插件会无法工作。3.2 前置依赖安装并启动 nvidia-dcgm 服务DCGM 插件与 nvidia-dcgm 交互获取数据所以必须先安装 nvidia-dcgm 服务Ubuntu 系列系统通过 apt 安装注意版本号不要搞错apt-get install -y datacenter-gpu-manager1:3.3.5理论上升级到大于该版本且低于 4.0.0 的版本也可以但请务必确认版本落在1:3.3.x区间。CentOS 系统需要到 NVIDIA 官方 CUDA 仓库rhel8 的 x86_64 目录下载对应 rpm 包安装。安装完成后启动服务并确认状态systemctl start nvidia-dcgm.service systemctl status nvidia-dcgm.service只有服务处于 active 状态才能进行下一步的采集配置——这也是 DCGM 方案最常见的失败点插件连不上 5555 端口采集直接无数据。3.3 采集配置使用 DCGM 插件前请确保 Categraf 的conf/input.dcgm/目录下包含以下 3 个 CSV 文件它们是 DCGM 指标定义文件1.x-compatibility-metrics.csvdefault-counters.csvdcp-metrics-included.csv采集配置位于conf/input.dcgm/dcgm.toml仓库副本见 collect/dcgm/dcgm.toml完整内容如下[[instances]] # 指定使用的指标定义文件, 一般使用 default-counters.csv就够了也可以尝试用其他两个csv文件 # path to the file, that contains the DCGM fields to collect collectors conf/input.dcgm/default-counters.csv # 是否是K8s环境设置为true会附加Pod的信息 # Enable kubernetes mapping metrics to kubernetes pods # kubernetesfalse # 指标中是否附加 gpu id 作为一个标签 # Choose Type of GPU ID to use to map kubernetes resources to pods. Possible values: uid, device-name # kubernetes-gpu-id-type uid # 是否使用 1.x 的ns # Use old 1.x namespace # use-old-namespace false # 支持的选项是f g i # f: FlexKey 如果MIG被禁用则监控所有GPU如果MIG被启用则监控所有GPU实例 # g: MajorKey 监控top-level entitiesGPU或NvSwitches或CPU # i: MinorKey 监控sub-level entities: GPU实例/NvLinks/CPU核心 - 如果MIG被禁用则不能指定该选项 cpu-devices f # 与cpu-devices的选项一样 # gpu devices devices f # 与cpu-devices的选项一样 switch-devices f # 使用ConfigMap # ConfigMap NAMESPACE:NAME for metric data configmap-data none # 这里就是前置依赖的nvidia-dcgm服务, 如果是本机采集则使用localhost:5555 ,如果是远程采集则使用远端IP:5555 # Connect to remote hostengine at HOST:PORT remote-hostengine-info localhost:5555 # 允许用户在没有实际GPU硬件的环境中模拟GPU, 仅用于测试 # Accept GPUs that are fake, for testing purposes only # fake-gpus false # 将GPU型号名称中的每个空格替换为破折号确保标识符连续且无空格。 # Replaces every blank space in the GPU model name with a dash, ensuring a continuous, space-free identifier. # replace-blanks-in-model-name false关键参数解读collectors指定指标定义 CSV 文件一般使用default-counters.csv就够用也可尝试另外两个 CSV1.x-compatibility-metrics.csv面向 1.x 兼容指标dcp-metrics-included.csv面向 DCP 场景。kubernetes是否 K8s 环境设为true会把指标映射到 Pod 并附加 Pod 信息便于按工作负载维度观测 GPU。kubernetes-gpu-id-typeGPU ID 类型可选uid或device-name用于将 K8s 资源映射到 Pod。use-old-namespace是否使用 1.x 旧命名空间。cpu-devices / devices / switch-devices设备选择层级可选值为f、g、i三种fFlexKeyMIG 禁用时监控所有 GPUMIG 启用时监控所有 GPU 实例gMajorKey监控顶级实体GPU / NvSwitches / CPUiMinorKey监控子级实体GPU 实例 / NvLinks / CPU 核心MIG 被禁用时不能指定该选项。configmap-data使用 ConfigMap 的方式加载指标数据格式为NAMESPACE:NAME不使用则保持none。remote-hostengine-info前置的 nvidia-dcgm 服务地址本机采集用localhost:5555远程采集用远端IP:5555。fake-gpus允许在没有真实 GPU 硬件的环境中模拟 GPU仅用于测试。replace-blanks-in-model-name将 GPU 型号名称中的空格替换为破折号保证标识符连续无空格。3.4 指标字典38 个 DCGM 指标全览仓库在 metrics/dcgm_by_categraf.json 中提供了 DCGM 指标字典含中英文名称、单位、说明可用于 Nightingale 指标视图展示。共 38 个指标按类别归纳如下基础资源类| 指标名 | 含义 | 单位 | | --- | --- | --- | |DCGM_FI_DEV_GPU_UTIL| GPU 利用率核函数 Active 时间占比 | % | |DCGM_FI_DEV_MEM_COPY_UTIL| 内存带宽利用率 | % | |DCGM_FI_DEV_ENC_UTIL/DCGM_FI_DEV_DEC_UTIL| 编码器 / 解码器利用率 | % | |DCGM_FI_DEV_FB_FREE/DCGM_FI_DEV_FB_USED| 显存剩余 / 已使用对应 nvidia-smi Memory-Usage | MiB | |DCGM_FI_DEV_MEMORY_TEMP/DCGM_FI_DEV_GPU_TEMP| 内存温度 / GPU 温度 | °C | |DCGM_FI_DEV_POWER_USAGE/DCGM_FI_DEV_TOTAL_ENERGY_CONSUMPTION| GPU 功率 / 驱动加载以来总能耗 | W / J |性能剖析类PROF 系列来自 DCGM 性能采样| 指标名 | 含义 | 单位 | | --- | --- | --- | |DCGM_FI_PROF_GR_ENGINE_ACTIVE| 图形/计算引擎活跃时间占比 | % | |DCGM_FI_PROF_SM_ACTIVE| SM 活跃时间占比0.5 说明 GPU 利用不高效0.8 为必要 | % | |DCGM_FI_PROF_SM_OCCUPANCY| SM 线程束占用率内存带宽受限负载下越高越有效 | % | |DCGM_FI_PROF_PIPE_TENSOR_ACTIVE| Tensor Core 管道活跃周期占比 | % | |DCGM_FI_PROF_PIPE_FP64/FP32/FP16_ACTIVE| FP64 / FP32 / FP16 管道活跃周期占比 | % | |DCGM_FI_PROF_DRAM_ACTIVE| DRAM 活跃周期占比内存带宽利用率实际峰值约 0.8 | % | |DCGM_FI_PROF_PCIE_TX_BYTES/DCGM_FI_PROF_PCIE_RX_BYTES| PCIe 发送 / 接收数据速率 | B/s | |DCGM_FI_PROF_NVLINK_RX_BYTES/DCGM_FI_PROF_NVLINK_TX_BYTES| NVLink 接收 / 发送数据速率 | B/s |健康与状态类| 指标名 | 含义 | 单位 | | --- | --- | --- | |DCGM_FI_DEV_XID_ERRORS| 最后发生的 XID 错误号counter | - | |DCGM_FI_DEV_CLOCK_THROTTLE_REASONS| 时钟降频原因 | - | |DCGM_FI_DEV_SM_CLOCK/DCGM_FI_DEV_MEM_CLOCK| SM / 内存时钟频率 | MHz | |DCGM_FI_DEV_APP_SM_CLOCK/DCGM_FI_DEV_APP_MEM_CLOCK| SM / 内存应用时钟频率 | MHz | |DCGM_FI_DEV_POWER_VIOLATION/DCGM_FI_DEV_THERMAL_VIOLATION| 功率上限 / 热限制违规时长 | μs | |DCGM_FI_DEV_SYNC_BOOST_VIOLATION/DCGM_FI_DEV_BOARD_LIMIT_VIOLATION| 同步提升 / 电路板限制违规时长 | μs | |DCGM_FI_DEV_LOW_UTIL_VIOLATION/DCGM_FI_DEV_RELIABILITY_VIOLATION| 低利用率 / 电路板可靠性限制违规时长 | μs | |DCGM_FI_DEV_BAR1_USED/DCGM_FI_DEV_BAR1_FREE| 已使用 / 剩余 BAR1 内存 | MB | |DCGM_FI_DEV_RETIRED_SBE/DCGM_FI_DEV_RETIRED_DBE| 单 bit / 双 bit 错误停用页面数 | - |3.5 开箱即用的告警规则仓库在 alerts/gpu_alert.json 中提供了两条可直接导入 Nightingale 的 Prometheus 告警规则GPU XID 错误DCGM_FI_DEV_XID_ERRORS命中 32/38/48/61/62/63/64/68/74/79/92/94/95 等致命错误码即触发prom_for_duration持续 180s评估间隔 15s重复通知间隔 60s。告警的处置建议annotations给出了标准排查路径先用nvidia-smi -q -d PAGE_RETIREMENT,ECC与dmesg -T | grep -i xid确认具体 XID 码和涉及的卡对照 NVIDIA XID 文档区分软件驱动/CUDA与硬件故障Xid 48/63/64ECC与 79掉卡基本可判定硬件问题应先从调度池摘除该卡K8s 上给节点打 taint软件类升级驱动/CUDA 后复测硬件类走返修流程。GPU 温度过高sum by (Hostname, modelName, gpu) (DCGM_FI_DEV_GPU_TEMP 85)即任一 GPU 温度超过 85°C 触发。处置建议包括用nvidia-smi -q -d TEMPERATURE,PERFORMANCE确认是否已触发 SW/HW Slowdown检查机箱风道、风扇转速与滤网积灰多卡机型需区分单卡高温多为散热器接触或风扇问题与整机高温环境问题短期可用nvidia-smi -pl降低功耗上限或降低任务并发为停机除尘争取时间。四、集成资源结构与导入方式本仓库的 integrations/NVIDIA 目录是一个完整的 GPU 监控集成包除上述采集配置、告警、指标字典外还包括看板dashboards/nvidia-gpu-metrics-by-categraf.jsonnvidia_smi 方案看板dashboards/GPU-Overview-dcgm.jsonDCGM 方案 GPU 总览看板dashboards/GPU-Jobs-dcgm.jsonDCGM 方案按作业维度看板。指标字典metrics/dcgm_by_categraf.json38 个 DCGM 指标的中英文名、单位与注释可导入 Nightingale 指标视图。采集配置collect/nvidia_smi/nvidia_smi.toml 与 collect/dcgm/dcgm.toml即前文两份配置的仓库源文件。实际使用中将这些采集配置同步到 Categraf 的conf/input.nvidia_smi/与conf/input.dcgm/目录注意 DCGM 方案同时需要补齐 3 个 CSV 文件并确保 nvidia-dcgm 服务 active重启 Categraf 即可开始上报看板 JSON 和告警 JSON 则可直接导入 Nightingale 的对应模块实现从采集、展示到告警的完整闭环。五、选型建议快速接入 / 环境简单选nvidia_smi。零额外依赖、配置一行即可适用于 GPU 数量不大、只关注利用率/显存/温度/功耗等基础指标的裸机或虚拟机场景。注意采用 with-cgo-plugin 之外的普通 Categraf 版本即可但若要跑 DCGM 方案则必须换用带 CGO 的版本。大规模 GPU 集群 / 深度可观测选DCGM。配合 K8s 环境kubernetestruekubernetes-gpu-id-type可以按 Pod 维度观测覆盖 NVLink 拓扑、PCIe 吞吐、Tensor/SM/FP 各管道活跃度与各类 Violation 指标是定位 GPU 性能瓶颈、功耗异常和硬件亚健康的标准方案。代价是需要额外维护 nvidia-dcgm 服务与版本匹配关系。两者可并存nvidia_smi 与 DCGM 指标互不冲突生产环境可以先用 nvidia_smi 兜底保证有数据再逐步引入 DCGM 补齐深度指标。最终无论是哪种方案采集到的数据都会以 Prometheus 格式进入 Nightingale配合本文所述的看板与告警规则即可构建起一套覆盖采集 → 可视化 → 告警 → 处置建议的完整 GPU 可观测体系。【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingale创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考