1. 为什么Windows监控值得单独折腾一套方案很多人第一次接触Prometheus生态都是在Linux环境下node_exporter一个二进制文件扔进去、systemd一挂就完事了。等到要把公司那批Windows Server也纳入监控大盘的时候才发现事情没那么简单——Windows没有systemd服务管理是另一套逻辑防火墙默认拦得死死的采集器还分了好几个版本。我自己第一次给一台Windows Server 2016配windows_exporter的时候光排查“为什么9090端口通了但targets里显示down”就花了一个下午。这套方案的核心价值在于用Prometheus做指标采集和存储用Grafana做可视化展示用windows_exporter也就是大家常说的node_exporter在Windows上的对应实现做数据暴露三者组合起来能把Windows主机的CPU、内存、磁盘、网络、服务状态、IIS站点、SQL Server性能计数器等指标全部纳入统一监控。它解决的是“Windows机器像黑盒一样出了问题只能远程登上去看任务管理器”这个痛点。适合谁来参考如果你手里有3台以上的Windows服务器或者你所在的环境是混合架构LinuxWindows又或者你单纯想给自己家里的Windows主机做一套性能趋势记录这套方案都能直接抄作业。不需要你懂Go语言不需要你改源码全部用现成的二进制和配置文件搞定。我下面会从整体设计思路开始拆然后一步步走完安装、配置、对接Grafana、配告警的完整流程最后把我踩过的坑和排查方法整理成速查表。你跟着做大概率能一次跑通。2. 整体架构设计与组件选型思路2.1 三个组件各自扮演什么角色先把角色分清楚不然后面配置的时候容易搞混。windows_exporter是跑在每一台被监控Windows主机上的采集代理。它启动后会开一个HTTP端口默认9182把Windows的性能计数器、服务状态、磁盘空间等信息转换成Prometheus能识别的文本格式暴露出来。你可以把它理解成一个“翻译官”把Windows那套WMI和性能计数器的数据翻译成Prometheus能读的metrics。Prometheus是服务端负责定时去每个exporter的端口拉数据pull模式存进自己的时序数据库然后根据你写的规则判断是否触发告警。它不负责画图画图是Grafana的事。Grafana是展示层从Prometheus的HTTP API里查数据渲染成各种图表和仪表盘。它自带很多现成的Dashboard模板导入就能用不需要你从零画图。三者关系用一句话概括exporter暴露数据Prometheus拉取并存储Grafana查询并展示。2.2 为什么选pull模式而不是push模式Prometheus默认是pull模式也就是服务端主动去拉数据。这个设计在Windows场景下有个明显好处你不需要在每台Windows主机上配置“往哪里推数据”只需要保证Prometheus能访问到exporter的端口就行。反过来如果某台机器网络不通Prometheus的targets页面会直接显示down排查起来很直观。当然pull模式也有代价Prometheus必须能网络可达每台被监控主机。如果你的Windows机器在NAT后面或者防火墙策略很严那就需要额外打通网络策略。我实际项目中遇到过Windows机器在独立VLAN里最后是在防火墙上开了Prometheus服务器到被监控主机9182端口的单向访问。2.3 版本选型与兼容性考量截至我写这篇内容时windows_exporter的稳定版本是0.25.x系列Prometheus是2.50.xGrafana是10.x。这三个版本组合在一起是经过验证的不建议混用太老的版本。有一个细节要注意windows_exporter从0.20版本开始默认启用的collector集合发生了变化。早期版本默认开启所有collector后来为了减少资源占用改成只开启一部分。如果你发现某些指标采集不到大概率是collector没开。这个后面会详细讲。另外Windows Server 2012 R2及更早版本对windows_exporter的新版本支持有限如果你还在跑2012 R2建议用0.18.x或更早的版本。2016及以上版本用最新版没问题。3. Windows端exporter安装与配置实操3.1 下载与安装MSI还是免安装包windows_exporter提供两种分发形式MSI安装包和免安装的exe。我推荐用MSI因为它会自动注册为Windows服务开机自启省去手动配服务的麻烦。下载地址在GitHub的prometheus-community/windows_exporter仓库的Releases页面。选windows_exporter-0.25.x-amd64.msi这个文件。如果你的Windows是ARM架构比如某些Surface设备选arm64版本。安装命令很简单用管理员权限打开PowerShell或CMDmsiexec /i windows_exporter-0.25.0-amd64.msi ENABLED_COLLECTORScpu,cs,logical_disk,net,os,service,system,textfile LISTEN_PORT9182这里ENABLED_COLLECTORS参数指定了要开启的采集器。我列出的这几个是最常用的cpuCPU使用率、cs计算机系统信息、logical_disk逻辑磁盘、net网络、os操作系统信息、service服务状态、system系统信息、textfile自定义文本文件采集。如果你需要监控IIS加上iis需要监控SQL Server加上mssql。LISTEN_PORT9182指定监听端口默认就是9182写不写都行但显式写出来更清晰。安装完成后服务会自动启动。你可以用浏览器访问http://localhost:9182/metrics如果能看到一大堆以windows_开头的指标文本说明exporter工作正常。注意如果你在安装时没有指定ENABLED_COLLECTORS默认只开启cpu、cs、logical_disk、net、os、service、system这几个。textfile默认不开需要手动加上。3.2 防火墙放行与端口验证Windows防火墙默认会拦截9182端口的入站连接。你需要加一条入站规则netsh advfirewall firewall add rule namewindows_exporter dirin actionallow protocolTCP localport9182加完之后从Prometheus服务器上用curl或浏览器访问http://Windows主机IP:9182/metrics确认能拿到数据。如果访问不通按这个顺序排查exporter服务是否在运行、端口是否在监听netstat -ano | findstr 9182、防火墙规则是否生效、中间是否有网络设备拦截。我遇到过一种情况Windows主机有多块网卡exporter默认监听所有网卡但防火墙规则只对某一块网卡生效。后来在规则里指定了localip参数才解决。如果你也遇到类似问题可以在防火墙规则里加上localip具体IP。3.3 collector配置的取舍与资源占用windows_exporter的collector不是开得越多越好。每开一个collectorexporter就会多采集一组性能计数器CPU和内存占用会相应增加。我实测下来在一台4核8G的Windows Server 2016上开启默认collector集合时exporter自身占用约30MB内存、CPU占用不到1%。如果开启全部collector包括iis、mssql、ad等内存占用会涨到80MB左右CPU占用在采集瞬间会有小幅波动。我的建议是只开你真正需要的collector。比如你不需要监控IIS就别开iis不需要监控SQL Server就别开mssql。textfile这个collector比较特殊它不采集系统指标而是读取你指定目录下的文本文件适合用来暴露自定义指标。如果你没有自定义指标需求也可以不开。修改collector配置有两种方式重新运行MSI安装包并指定新的ENABLED_COLLECTORS参数或者直接改注册表。注册表路径在HKLM:\SYSTEM\CurrentControlSet\Services\windows_exporter\Parameters里面有个EnabledCollectors键值。改完之后重启windows_exporter服务。3.4 以服务方式运行与开机自启确认MSI安装会自动注册服务服务名是windows_exporter。你可以用以下命令确认服务状态sc query windows_exporter如果状态是RUNNING说明服务正常。如果没启动用sc start windows_exporter手动启动。开机自启是默认配置的不需要额外设置。如果你用的是免安装exe版本那就需要手动注册服务。可以用sc create命令也可以用NSSM这类工具。我一般推荐MSI省事。实操心得在批量部署场景下我会把MSI安装命令写成一个PowerShell脚本通过组策略或远程管理工具推送到所有Windows主机。脚本里统一指定ENABLED_COLLECTORS和LISTEN_PORT保证每台机器的配置一致。这样后面在Prometheus里配targets的时候不用每台机器单独调。4. Prometheus服务端部署与采集配置4.1 Prometheus安装与基础配置Prometheus的安装很简单从官网下载Windows版的zip包解压到任意目录里面有个prometheus.exe和默认的prometheus.yml配置文件。双击exe就能启动但这样启动的窗口关掉就停了。生产环境建议注册成Windows服务可以用sc create或者NSSM。默认的prometheus.yml长这样global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090]scrape_interval是采集间隔默认15秒。对于Windows主机监控15秒足够了。如果你监控的主机数量很多比如超过100台可以适当放宽到30秒减少Prometheus的负载。4.2 添加Windows主机targets的两种方式最简单的方式是静态配置直接在scrape_configs下面加一段- job_name: windows static_configs: - targets: - 192.168.1.101:9182 - 192.168.1.102:9182 - 192.168.1.103:9182 labels: env: production role: weblabels里的内容会附加到所有从这个target采集到的指标上方便后面在Grafana里按环境或角色筛选。如果你的Windows主机数量多、经常变动静态配置就不太合适了。这时候可以用基于文件的服务发现file_sd_configs把targets写在一个单独的JSON或YAML文件里Prometheus会定期读取这个文件。修改targets时只需要改这个文件不用重启Prometheus。- job_name: windows file_sd_configs: - files: - windows_targets.yml refresh_interval: 30swindows_targets.yml的内容- targets: - 192.168.1.101:9182 - 192.168.1.102:9182 labels: env: production role: web注意file_sd_configs的文件路径是相对于Prometheus工作目录的。如果你把Prometheus注册成了服务工作目录可能和exe所在目录不一致建议用绝对路径。4.3 采集间隔与超时参数调优scrape_interval和scrape_timeout是两个关键参数。默认scrape_interval是15秒scrape_timeout是10秒。如果某台Windows主机响应慢10秒内没返回数据Prometheus会标记这次采集失败target状态变成down。我遇到过一台Windows Server 2008 R2的机器性能计数器采集特别慢经常超过10秒。后来把scrape_timeout调到20秒scrape_interval调到30秒就稳定了。但这样做的代价是数据点变稀疏Grafana图表看起来会有断点。调优的原则是先保证采集成功率再考虑数据密度。如果某台机器实在慢可以单独给它配一个job用更长的超时时间。- job_name: windows_slow scrape_interval: 30s scrape_timeout: 25s static_configs: - targets: [192.168.1.200:9182]4.4 验证targets状态与指标抓取配置改完后重启Prometheus服务然后访问http://Prometheus服务器IP:9090/targets。如果一切正常你会看到windows这个job下面所有target的状态都是UPLast Scrape显示几秒前。如果状态是DOWN把鼠标悬停在Error那一列上会显示具体错误信息。常见的错误有connection refusedexporter没启动或端口不对、context deadline exceeded超时、no route to host网络不通。根据错误信息去排查对应的环节。确认targets都UP之后可以在Prometheus的Graph页面输入一个指标名比如windows_cpu_time_total点Execute如果能看到数据说明采集链路完全通了。5. Grafana接入与Dashboard配置5.1 Grafana安装与数据源添加Grafana的Windows安装也是MSI包从官网下载后双击安装默认监听3000端口。安装完成后访问http://localhost:3000默认账号密码都是admin首次登录会要求改密码。登录后第一件事是添加数据源。点左侧齿轮图标进入Configuration选Data Sources点Add data source选Prometheus。在URL栏填http://Prometheus服务器IP:9090其他保持默认点Save Test。如果显示“Data source is working”说明Grafana能正常连上Prometheus。注意如果Prometheus和Grafana不在同一台机器上确保Prometheus的9090端口对Grafana服务器开放。Prometheus默认监听0.0.0.0:9090不需要额外配置。5.2 导入现成的Windows监控DashboardGrafana社区有很多现成的Windows监控Dashboard模板最常用的是ID为10467的那个Windows Exporter Dashboard。导入方法点左侧加号图标选Import在“Import via grafana.com”输入框里填10467点Load然后选择Prometheus数据源点Import。导入后你会看到一整套图表CPU使用率、内存使用率、磁盘空间、磁盘IO、网络流量、服务状态等。这些图表都是基于windows_exporter暴露的指标画的不需要你手动调整。如果某些图表显示“No data”大概率是对应的collector没开。比如磁盘IO图表没数据检查一下是否开启了logical_disk和disk相关的collector。5.3 自定义Panel与常用PromQL示例现成的Dashboard虽然全但有时候你需要加一些自己的Panel。比如你想看某台机器上特定服务的运行状态可以用这样的PromQLwindows_service_state{nameW3SVC, staterunning}这个查询会返回IIS服务的运行状态1表示运行中0表示停止。再比如你想看磁盘剩余空间的百分比windows_logical_disk_free_bytes / windows_logical_disk_size_bytes * 100这个查询会返回每个逻辑磁盘的剩余空间百分比。你可以把它做成一个Gauge面板设置阈值低于20%变黄低于10%变红。还有一个常用的查询是CPU使用率100 - (avg by (instance) (rate(windows_cpu_time_total{modeidle}[5m])) * 100)这个查询计算的是过去5分钟的平均CPU使用率非空闲时间占比。rate函数用来计算每秒的变化率avg by (instance)表示按实例分组求平均。5.4 告警规则配置与Alertmanager对接Grafana自身可以配告警但更常见的做法是在Prometheus里配告警规则然后通过Alertmanager发送通知。Prometheus的告警规则写在单独的yml文件里在prometheus.yml中通过rule_files引用。一个典型的Windows磁盘空间告警规则groups: - name: windows_alerts rules: - alert: WindowsDiskSpaceLow expr: windows_logical_disk_free_bytes / windows_logical_disk_size_bytes * 100 10 for: 5m labels: severity: warning annotations: summary: 磁盘空间不足 (实例 {{ $labels.instance }}) description: 磁盘 {{ $labels.volume }} 剩余空间低于10%当前值 {{ $value }}%for: 5m表示条件持续5分钟才触发告警避免因为瞬时波动误报。annotations里的{{ $labels.instance }}和{{ $value }}会被实际值替换。Alertmanager的配置稍微复杂一点需要配路由route和接收器receiver。接收器可以配邮件、Webhook、企业微信等。这部分内容比较多我建议先跑通Prometheus自身的告警页面http://Prometheus:9090/alerts确认规则能正常触发再去配Alertmanager的通知渠道。6. 常见问题与排查技巧实录6.1 targets显示down的排查顺序这是最常见的问题。我整理了一个排查顺序按这个走基本能定位到原因排查步骤检查内容常用命令1exporter服务是否运行sc query windows_exporter2端口是否监听netstat -ano | findstr 91823本机能否访问浏览器打开http://localhost:9182/metrics4远程能否访问从Prometheus服务器curl http://IP:9182/metrics5防火墙规则netsh advfirewall firewall show rule namewindows_exporter6Prometheus配置检查prometheus.yml中targets的IP和端口是否正确如果本机能访问但远程不能问题一定在防火墙或网络策略。如果本机都不能访问问题在exporter本身。6.2 指标缺失与collector未开启前面提过windows_exporter默认只开启一部分collector。如果你发现某个指标查不到先去exporter的metrics页面搜一下有没有这个指标。如果没有就是collector没开。比如你想监控IIS但搜不到windows_iis_开头的指标那就是iis collector没开。重新运行MSI安装包在ENABLED_COLLECTORS里加上iis重启服务即可。有一个容易忽略的点某些collector之间有依赖关系。比如servicecollector依赖oscollector如果你只开service不开osservice collector可能无法正常工作。所以修改collector配置时最好保留默认的那几个基础collector。6.3 Grafana图表No data的几种原因Grafana图表显示No data原因可能出在三个环节数据源、查询语句、时间范围。先检查数据源是否正常在Grafana的Explore页面选Prometheus数据源输入一个简单的查询比如up看有没有数据。如果没有说明数据源配置有问题。如果up有数据但你的查询没数据那就是PromQL写错了。常见的错误包括指标名拼写错误、标签值不匹配、函数参数不对。建议先在Prometheus的Graph页面验证查询语句确认能出数据后再放到Grafana里。如果查询语句没问题但图表还是No data检查一下Grafana右上角的时间范围。有时候默认选的是“Last 5 minutes”而你的数据采集间隔是30秒可能刚好赶上没有数据点的窗口。把时间范围放宽到“Last 1 hour”试试。6.4 性能计数器采集超时的处理前面提到过某些老版本Windows的性能计数器采集特别慢导致Prometheus采集超时。除了调整scrape_timeout还有一个办法是减少collector数量。采集的计数器越少单次采集耗时越短。我实测过在一台Windows Server 2008 R2上开启全部collector时单次采集耗时约12秒只开cpu、cs、logical_disk、net、os、service、system这七个时耗时降到3秒左右。所以如果你的机器性能有限精简collector是最有效的优化手段。6.5 服务重启后配置丢失的预防windows_exporter的配置存在注册表里MSI安装时写入。如果你手动改了注册表重启服务后配置会保留。但如果你是通过命令行参数启动的免安装版本重启后参数就丢了。预防措施如果用MSI安装配置写在注册表里不会丢。如果用免安装版本建议用NSSM注册服务在NSSM的配置里写死启动参数。或者写一个启动脚本放到Windows的计划任务里开机自动执行。实操心得我在批量部署时会把所有配置项ENABLED_COLLECTORS、LISTEN_PORT、TEXTFILE_DIR都写进MSI安装命令里然后用PowerShell脚本统一推送。这样每台机器的配置完全一致后面维护起来也方便。如果某台机器需要特殊配置单独在那台机器上改注册表不影响其他机器。7. 监控体系扩展与长期维护建议7.1 从单机监控到批量管理的演进一开始你可能只监控两三台Windows机器静态配置就够了。但随着机器数量增加手动维护targets列表会变得越来越痛苦。这时候可以考虑几种方案一是用file_sd_configs把targets写在一个单独的YAML文件里用脚本定期更新这个文件。这个方案简单适合几十台机器的规模。二是用Consul或etcd做服务发现Prometheus从这些注册中心自动发现targets。这个方案适合大规模、动态变化的环境但需要额外部署和维护Consul/etcd。三是用Prometheus的HTTP SD接口自己写一个简单的HTTP服务返回targets列表。这个方案灵活性最高但需要写代码。我的建议是50台以下用file_sd_configs50台以上考虑Consul。不要一上来就搞最复杂的方案够用就行。7.2 数据保留周期与存储规划Prometheus默认保留15天的数据。对于Windows主机监控15天通常够用但如果你需要做月度趋势分析就得延长保留周期。修改保留周期在启动参数里加--storage.tsdb.retention.time30d。但要注意保留周期越长磁盘占用越大。我实测下来监控10台Windows主机、采集间隔15秒、保留30天Prometheus的数据目录大约占用2GB左右。如果监控100台就是20GB。规划磁盘空间时要把这个考虑进去。如果磁盘空间有限可以配远程存储把数据写到对象存储或时序数据库里。但这会增加架构复杂度建议先跑通本地存储有需求再扩展。7.3 告警规则的持续迭代告警规则不是配一次就完事了。随着你对系统行为的了解加深需要不断调整阈值和条件。比如一开始你设磁盘剩余空间低于10%告警后来发现业务高峰期磁盘写入很快10%可能只够撑半小时那就得把阈值提到20%。我习惯每季度回顾一次告警规则看看哪些规则经常误报、哪些规则从来没触发过。误报多的规则要么调阈值要么加for时间从来没触发过的规则要么是阈值太宽松要么是监控的指标根本不重要可以考虑删掉。还有一个技巧给告警规则加severity标签分warning和critical两级。warning级别的告警只发邮件critical级别的告警发短信或打电话。这样既能及时响应严重问题又不会被大量warning淹没。7.4 监控大盘的日常使用习惯最后说一点使用习惯。监控大盘不是配好就放在那里不管了日常要养成看的习惯。我每天早上到工位第一件事就是打开Grafana的Windows总览大盘扫一眼CPU、内存、磁盘的曲线有没有异常波动。很多时候问题在触发告警之前就能从曲线上看出来。另外Grafana的Dashboard支持变量Variables可以做一个实例下拉框方便快速切换查看不同机器。配置方法是在Dashboard设置里加一个变量类型选Query查询语句写label_values(up{jobwindows}, instance)这样下拉框里就会自动列出所有Windows实例。这套方案我从第一次配到现在前后迭代了大概半年时间中间踩过的坑基本都写在上面的内容里了。如果你照着做的时候遇到新的问题大概率也能在“常见问题”那一节找到对应的排查思路。监控这件事配起来不难难的是持续维护和根据业务变化调整。先把基础跑通后面的事情慢慢来。