给 Windows 补齐系统和硬件监控

Checo2026/8/25大约 6 分钟

给 Windows 补齐系统和硬件监控

Windows 的 CPU、内存、磁盘指标可以由 windows_exporter 提供，但温度、GPU 功耗和显存需要另外确认传感器来源。我在一台 Ryzen 5600H / RTX 3050 Ti 笔记本上采用两个 exporter，再由同一个 Prometheus 抓取。

系统指标以 windows_exporter 0.30.7 为基准；硬件使用 HardwareExporterWindows / LibreHardwareMonitor。8 月部署记录在 9 月 15 日复核了端点。以下配置是可调整的示例，不代表在线面板的完整配置，也不保证其他硬件有相同传感器。

同一主机，两个数据源

Windows
  ├─ windows_exporter :9182 → CPU/内存/磁盘/网络/服务
  └─ HardwareExporter :9888 → 温度/GPU/功耗/显存
                ↓
            Prometheus → Grafana
                └─ 告警规则 → Alertmanager

两进程是本次选型，不是 Windows 监控的唯一架构。WMI thermalzone 不能直接当作 CPU 核心温度，传感器的名称、单位和实际变化都要验证。

安装后先读真实 metrics

管理员 cmd.exe 的 MSI 示例，文件需从官方发布下载，允许来源替换为实际 Prometheus 地址：

msiexec /i windows_exporter-0.30.7-amd64.msi /qn /norestart ENABLED_COLLECTORS=cpu,memory,logical_disk,net,os,service,system LISTEN_PORT=9182 REMOTE_ADDR=192.0.2.30

检查所有已有入站规则：新增窄规则不会覆盖旧的宽泛允许。两个端点应只供监控路径访问。

Get-Service windows_exporter,HardwareExporter,PawnIO
Invoke-WebRequest http://localhost:9182/metrics -UseBasicParsing
Invoke-WebRequest http://localhost:9888/metrics -UseBasicParsing

硬件 exporter 的 Runtime、驱动和安装步骤随版本变化，应核对下载版本。本机链路使用 .NET 10 与 PawnIO；驱动运行仍不能保证某种芯片必有读数。HardwareExporterWindows

系统指标（0.30.7）	含义
`windows_cpu_time_total{mode="idle"}`	CPU 空闲累计时间
`windows_memory_available_bytes`	可用内存
`windows_memory_physical_total_bytes`	总物理内存
`windows_logical_disk_free_bytes` / `size_bytes`	卷空间
`windows_system_boot_time_timestamp`	开机 Unix 时间
`windows_service_state`	由 state 标签区分的 0/1 状态

0.30.7 仍可输出一些弃用别名，不能把“弃用”写成“不存在”。查询以实际版本输出为准。版本说明

本机硬件指标包括 hardware_gpu_temperature_gpu_core、hardware_gpu_memory_used_bytes 和 hardware_cpu_power_package。温度 °C、显存 bytes、功耗 W，各自用正确单位；有多个传感器时保留 name 等标签，不要把不同读数随意相加。

用 job 分来源，instance 分机器

下面地址属于文档网段，应替换为真实机器。此示例保留全部服务状态，避免丢失告警所需数据：

global:
  scrape_interval: 60s

scrape_configs:
  - job_name: windows
    static_configs:
      - targets: ['192.0.2.20:9182']
        labels:
          instance: legion
  - job_name: hardware-lhm
    static_configs:
      - targets: ['192.0.2.20:9888']
        labels:
          instance: legion

相同 instance 便于按设备展示，job 保留数据来源，up 也分别记录两个端点。检查配置并在 Prometheus targets 页面验证实际抓取，不能只看 exporter 服务 Running。

可直接检查的 PromQL

# Per-instance CPU utilization (%)
100 * (1 - avg by (instance) (
  rate(windows_cpu_time_total{job="windows",mode="idle"}[5m])
))

# Memory utilization (%)
100 * (1 - windows_memory_available_bytes{job="windows"}
  / windows_memory_physical_total_bytes{job="windows"})

# Per-volume usage (%)
100 * (1 - windows_logical_disk_free_bytes{job="windows"}
  / windows_logical_disk_size_bytes{job="windows"})

# One measured GPU sensor family
hardware_gpu_temperature_gpu_core{job="hardware-lhm",instance="legion"}

选择器写在指标后，不能写成 (a+b)/c {instance="legion"}。保留 instance 分组，避免多台机器被平均成一个看似正常的值。磁盘 free/size 需要相同卷标签匹配；面板 No data 时先查询原始系列和标签。

服务告警要处理“0”和“不存在”

windows_service_state{state="running"} 对停止服务一般为 0；如果服务被卸载、collector 关闭或系列被过滤，则可能根本不存在。默认 == 0 不会自动捕获后者。service collector 文档

下面只针对必须存在的单个示例服务，名称大小写需与端点一致，并挂载到 Prometheus 的 rule_files：

groups:
  - name: windows-example
    rules:
      - alert: WindowsExporterScrapeFailed
        expr: up{job="windows"} == 0
        for: 2m
        labels:
          severity: warning
      - alert: RequiredWindowsServiceUnavailable
        expr: |
          windows_service_state{job="windows",instance="legion",name="mssqlserver",state="running"} == 0
          or absent(windows_service_state{job="windows",instance="legion",name="mssqlserver",state="running"})
        for: 2m
        labels:
          severity: warning

SQL 服务仅是示例，不表示本机安装了它。up=0 是抓取失败，不能直接叫“主机关机”。目标从服务发现移除、Prometheus 本身停止、远端写入失败，也要分别监控。

promtool check config prometheus.yml
promtool check rules windows-rules.yml

这两个检查是部署步骤，不表示本文写作时在真实 Prometheus 上执行过。规则检查文档

No data 要沿链路查，不要用零掩盖

先看目标能不能被 Prometheus 抓到，再看所需 collector 和指标，再看标签，最后查面板变量与表达式。up=1 只说明这次抓取成功，不保证硬件传感器存在；up=0 也无法区分主机关机、端口阻断、exporter 崩溃或响应超时。

层次	验证方式	常见误判
Windows 本机	两端 metrics 原文、服务与设备	服务 Running 就一定有全部指标
抓取端网络	targets 错误、超时与可达性	本机 localhost 可读等于远端可读
Prometheus 数据	原始 metric、job/instance/传感器标签	对不存在的 metric 写 rate
Grafana	变量实际值、查询预览、单位	No data 设成 0 后认为温度很低
告警通知	规则 pending/firing、接收器与抑制	规则出现就等于通知发出

传感器重命名、系统升级或 exporter 版本改变，可能让旧图“没有数据”。保存本机真实 metrics 样本作为版本契约，再对比变更；不要把缺失温度当 0°C，也不要因为功耗为 0 就断言设备已断电。

从示例告警到可以交付的规则

针对一个 instance 写 absent() 可以检查该预期系列是否消失，但不能自动给整个机群生成每台主机的缺失告警。目标列表变化后，要有独立的预期清单或规则生成机制；完全被服务发现删除的 target 不会继续产生 up=0。

停止服务、卸载服务和停止 exporter 是三种测试，分别会影响 state、系列存在性与抓取状态。先在测试环境控制一种变化，等待超过 scrape interval 与 for 窗口，核对 alert labels、恢复通知和去重，再扩大部署。不要为了验证告警把生产必需服务随意停掉。

阈值同样要对应持续时间：温度瞬间尖峰与长期高温不同，磁盘百分比也需结合容量和增长速度。网络 counter 用 rate 时保留接口与机器维度，服务 state 是 gauge，不应再对它求 rate。最后把配置、规则、面板源码、版本样本和通知接收配置一起备份；有面板截图不等于能恢复整条链路。

面板和保留策略

Grafana 按机器分行，CPU/GPU 温度可放同图观察联动，字节和百分比则分图或明确独立轴。先验证单位与传感器语义，再设置阈值和 for 时长。Alertmanager 用 instance/alertname 分组，限制重复通知。

process collector 和服务系列会增加基数，按实际需求启用。remote_write 可以提供远端存储，但不会自动消除抓取端开销。面板 JSON 从可维护源码生成，不能把公开面板 API 的脱敏输出当成完整备份写回。

最终验收至少包括：两个端点可读、实际抓取 UP、查询有数据、单位正确、停止/缺失服务两种告警都验证，以及旧宽泛防火墙规则已收紧。装了 exporter 只是链路起点。

本文日期采用主 KB 首次 Git 提交日期 2026-08-25（UTC+8），提交 c2ae3ba。操作与评测时间在正文单独注明；写作期间未连接或修改生产设备。