我们现在有了GPU，那么就要把它监控起来，但是传统的promethus是无法直接读取到显卡硬件的数据的。我们这里需要加入一个“翻译官” – DCGM-Exporter。
为什么Prometheus 不能读取到GPU的数据?
因为Promethus的核心工作模式是 HTTP Pull（拉取）。它像一个只会打固定电话的接线员，它要求被监控的对象必须提供一个 HTTP 接口（通常是 /metrics 页面），并且数据格式必须符合 Prometheus 的标准（即明文的 Key-Value 键值对）。
GPU 是底层硬件：GPU 的数据（温度、显存、功耗）锁在硬件寄存器里，或者通过 NVIDIA 的驱动接口（NVML）暴露。
通信协议不通：Prometheus 听不懂驱动层面的 C 语言接口，它只懂 HTTP。
DCGM-Exporter 的翻译官角色：
DCGM-Exporter 就像是一个翻译官。它一边通过 NVIDIA 的 DCGM (Data Center GPU Manager) 库读取显卡的原始硬件数据，另一边把它转换成 Prometheus 能听懂的文本格式，并开启一个 HTTP 服务（默认 9400 端口）等着 Prometheus 来抓。
DCGM-Exporter 到底抓取什么？
它不是只读一个“温度”那么简单。它利用了 NVIDIA 专门为数据中心设计的管理工具，抓取的数据极其详尽：
核心指标：DCGM_FI_DEV_GPU_UTIL（利用率）、DCGM_FI_DEV_FB_USED（显存占用）。
状态指标：DCGM_FI_DEV_GPU_TEMP（温度）、DCGM_FI_DEV_POWER_USAGE（实时功耗）。
健康指标：DCGM_FI_DEV_XID_ERRORS（这非常关键，如果报错，说明显卡硬件可能坏了）。
进阶指标：甚至能抓到张量核心（Tensor Core）的利用率，这对你跑 Ollama 的推理性能分析极其重要。
在 Kubernetes 环境下，DCGM-Exporter 还有一个“特异功能”：它能识别 Pod 与 GPU 的绑定关系。
Prometheus 如果直接看宿主机，它只知道“这台机器 GPU 满了”。但有了 DCGM-Exporter，它能告诉你：“是命名空间 default 里的那个 ollama-gpu-pod 占用了 12GB 显存。” 这种“容器感知”能力是 SRE 进行资源审计和排障的命脉。
具体操作
首先我们要创建一个dcgm-exporter的ds，ds本身的用途是“集群里的每一个满足条件的node运行且只运行一个pod”，但是前面说了我们只用dcgm-exporter来监控GPU，所以我们这里可以做一个nodeSelector，让ds只在固定的accelerator出现。
有了这个ds，GPU的服务上就会生成一个pod来采集服务器上Tesla T4的数据。我们还要创建一个service 来对应这个pod，因为ds生成的Pod 身上贴着这个标签（Label），Service 就会把它的 IP 记录到自己的 Endpoints 列表里。无论 Pod 怎么重启、IP 怎么变，Prometheus 只需要访问 http://dcgm-svc:接口 ， 就能找到背后的那个（或那群）Pod。
然后我们再创建一个promethus，它定时“抓取”数据，并建立 TSDB 索引。创建一个grafana，毕竟promethus不能提供动态的图板，所以grafana可以通过 PromQL 向 Prometheus 要数据，并实时绘制出温度、显存曲线。
对应的yaml都在：https://github.com/BruceWayne2099/gpu-test-main/tree/main 里。
然后我们来到promethus的url，对应输入DCGM_FI_DEV_GOU_TEMP就能看到GPU温度了,如图：
然后在gradana的页面里，在左侧菜单栏connection里添加promethus这个数据源，然后save and test看到测试成功，就可以创建图板了：
如何打通内网
我这个CPU master服务器是没有公网IP的，所以我这里要做一个转发，这样就可以让我的工作电脑能打开promethus和grafana的url，进行可视化管理：
首先，我的promethus的service端口是9090，deployment 也是9090。那么转发方法如下：
1 | kubectl port-forward deployment/prometheus-core 9090:9090 -n monitoring # 在k8s master服务器上执行这一步 |
然后在本地电脑浏览器里输入localhost:9090就能看到promethus了。
