1. 监控方案整体拆解为什么Windows监控不用Zabbix而选Prometheus全家桶很多朋友一提到Windows监控第一反应是用Zabbix Agent或Windows自带的性能监视器。这两个方案其实都有明显痛点Zabbix的Windows模板维护成本高自定义指标要写脚本和键值映射性能监视器纯手动数据只存在本机没法做历史回溯和跨机器聚合。我在某公司帮一个业务团队搭监控的时候他们最高频的需求就三条CPU跑满要立刻知道、内存泄漏要能预警、磁盘满了别等用户报障。就这么点需求用传统方案折腾了两周还是觉得别扭——直到我把Prometheus全家桶搬上Windows服务器半天就全部搞定。这套方案的指标采集链路大致是windows_exporter负责从操作系统取性能数据并暴露成标准Prometheus格式Prometheus按固定频率拉取这些指标做时间序列存储Grafana把时序数据可视化成图表Alertmanager根据Prometheus推送过来的告警条件执行邮件通知。四个组件各司其职且全部开源免费在Windows环境上的部署难度可以说非常低。适合这套方案的人群很明确手上有两三台以上Windows服务器的运维或开发需要跨机器统一看资源水位被Zabbix模板维护搞烦了想换个轻量方案的人想快速做出像样监控大屏但不想花采购费的团队。哪怕你完全没有接触过Prometheus照着下面的步骤来半天时间就能把整套链路跑通——前提是老老实实跟着我标注的注意点操作别跳步。这套方案能解决的问题非常实在不用再挨个远程桌面连服务器看任务管理器不用等用户说系统卡死了你才去查日志。CPU、内存、磁盘三大核心资源全部可视化告警邮件直接进邮箱晚上睡觉都能踏实不少。2. 组件选型与准备工作四个工具的分工和版本选择2.1 四个组件的核心分工与数据流向先理解一下这套体系的数据流走向。windows_exporter是个采集器它在Windows服务器上注册服务通过内置的采集模块读取系统的CPU、内存、磁盘、网络等性能计数器然后以http://服务器IP:9182/metrics的形式暴露指标。Prometheus是个时序数据库加采集调度器它根据配置文件里写的抓取目标按设定间隔通常15秒去拉取windows_exporter暴露的指标存在本地。Grafana负责把Prometheus里存的数据画成图形支持拖拽创建仪表盘。Alertmanager是告警分发中枢Prometheus里写入告警规则后满足条件就推给Alertmanager由它负责往邮箱发邮件。这四个组件的关系用一句话概括windows_exporter是眼睛Prometheus是大脑Grafana是显示器Alertmanager是广播员。它们之间全部走HTTP协议通信不像Zabbix那样需要装Agent到被监控机器上做主动汇报——这点在防火墙策略严格的生产环境尤其方便。2.2 版本选择与下载渠道版本选择这块我踩过坑多说几句。Prometheus和Alertmanager的版本尽量保持大版本一致避免出现配置格式不兼容的问题。目前我在用的组合是Prometheus 2.53.x系、Alertmanager 0.26.x系、windows_exporter 0.25.x系、Grafana 10.x系这个组合实测几个月非常稳。Windows服务器有32位和64位之分windows_exporter的MSI安装包一定选对架构。另外注意windows_exporter从0.22版本之后默认开启的参数发生变化旧版常见--collectors.enabled这种写法新版全部改成--collectors.enabled后面直接跟采集器名列表虽然名字一样但格式有变化按官方文档来就行。Grafana可以选Windows版本直接绿色解压运行不用安装程序。我个人喜欢用解压版方便迁移和回滚——把整个文件夹打包带走换个机器解压就恢复完了。Prometheus和Alertmanager本身就是绿色二进制下载解压即用。提示各组件下载时优先选GitHub Releases页面的正式发行包不要碰RC版和Beta版生产环境稳定优先。进入下载页面后看文件后缀Windows系选amd64对应的文件386对应32位。2.3 端口规划与防火墙预配置端口规划要在部署前想好避免装完互相访问不通再去排查浪费时间。我的分配方案windows_exporter监听9182端口负责暴露Windows性能指标Prometheus监听9090端口自带一个简单Web界面用来查看抓取状态和指标查询Grafana监听3000端口提供可视化面板Alertmanager监听9093端口接收告警并发送邮件通知如果这些组件不在同一台服务器上务必在各自的Windows防火墙入站规则里放开对应的端口。比如Prometheus在机器Awindows_exporter装在被监控机器B上那么机器B的防火墙要放行9182端口Prometheus所在机器A才能拉取数据。别小看这一步我见过有人折腾了一晚上发现是Windows防火墙默认拦住了外部访问。放开防火墙端口的具体操作是打开Windows Defender防火墙→高级设置→入站规则→新建规则→选端口→填TCP和对应的端口号→选允许连接→勾选所有配置文件。最简单的方式是运行还一条netsh advfirewall firewall add rule namewindows_exporter dirin actionallow protocolTCP localport9182命令一键搞定。3. windows_exporter部署与指标验证把Windows系统的性能数据翻译出来3.1 安装windows_exporter服务拿到MSI安装包后在需要监控的Windows服务器上双击安装或者用命令行静默安装。命令行方式我更喜欢因为可以直接指定监听端口和启用的采集器集合。推荐的安装命令msiexec.exe /i windows_exporter-0.25.2-amd64.msi /qn LISTEN_PORT9182 ENABLED_COLLECTORScpu,memory,os,logical_disk,net,process这条命令的作用是静默安装服务监听9182端口只启用CPU、内存、系统信息、逻辑磁盘、网络、进程六个采集模块。有些同学喜欢把采集器全部打开真没必要——开的采集器越多指标数量越大对Prometheus存储的压力也随之增加。只需要监控CPU、内存、磁盘三个核心项的话cpu,memory,os,logical_disk这四个采集器就够用。os和logical_disk这俩属于强相关组件os提供系统版本号、开机时间、系统名称这些描述性信息logical_disk负责把磁盘分区大小和剩余空间暴露出来。3.2 验证指标是否正确暴露安装完成后打开浏览器访问http://localhost:9182/metrics如果看到大量带#开头注释的文本每条文本形如windows_cpu_time_total{cpu0,modeidle} 3.14159e06说明安装成功。验证时重点看几个关键指标路径# 机器CPU的整体使用时间单位秒需要计算to get利用率 windows_cpu_time_total{cpu_total,modeidle} # 每个CPU核心各自的时间统计 windows_cpu_time_total{cpu0,modeidle} # 内存总量与可用量单位字节 windows_memory_available_bytes windows_os_physical_memory_free_bytes # 磁盘分区总量与剩余量单位字节 windows_logical_disk_size_bytes{volumeC:} windows_logical_disk_free_bytes{volumeC:}有经验的同学可能注意到windows_cpu_time_total不是直接给你一个百分比而是一个累加秒数。CPU利用率需要PromQL里用rate()函数去计算后面告警规则里我会给出完整写法。这种累加值的设计在Prometheus生态里很常见比如Counter类型天生就适合做速率计算。3.3 被监控机器没有外网时的离线安装生产环境经常有完全内网隔离的Windows机器没法直接从GitHub下载安装包。这时候在能访问外网的机器上把安装包下载好用U盘或内部传输通道把MSI文件拷过去再静默安装就行静默安装参数全部嵌在命令行里装完不需要进界面设置任何东西。我在给内网机器批量部署时会把安装包放到内网共享目录然后通过远程命令循环执行静默安装大概一分钟一台机器的节奏。4. Prometheus部署与抓取配置让监控数据存起来4.1 Prometheus下载解压与基础配置Prometheus在Windows上就是解压即用的绿色程序。下载Windows amd64版本的zip包解压到D:\prometheus目录里面除了prometheus.exe可执行文件还有一个prometheus.yml配置文件这是整个监控体系的指挥中枢。我习惯把服务器的所有组件目录统一规划比如D:\monitor\prometheus、D:\monitor\grafana、D:\monitor\alertmanager管理起来清爽。编辑prometheus.yml核心配置采用如下框架global: scrape_interval: 15s # 指标抓取频率默认15秒一次 evaluation_interval: 15s # 告警规则评估频率决定告警判定间隔 alerting: alertmanagers: - static_configs: - targets: - localhost:9093 # Alertmanager服务地址 rule_files: - alert_rules.yml # 告警规则文件路径后面我们会创建 scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090] - job_name: windows_server static_configs: - targets: - 192.168.1.10:9182 # 替换为实际Windows服务器IP - 192.168.1.11:9182 relabel_configs: - source_labels: [__address__] regex: (.*):9182 target_label: instance replacement: $1scrape_interval是全局限定一般不要低于10秒。Windows的很多指标已经做了缓存15秒一次足够监控需求。15秒看起来简单实际上决定了CPU、内存、磁盘的利用率曲线分辨率拉太勤会无谓增加存储量拉太慢会漏掉短时突发资源尖峰。15秒是实际运维里被验证过的折中方案。relabel_configs这段配置是很多人看不懂但实际很有用的功能水平线的目标地址是192.168.1.10:9182这样的形式如果不处理Prometheus里记录的instance标签就会包含端口号通过重打标签把端口去掉Grafana面板里的服务器名称就显示的是192.168.1.10而不是192.168.1.10:9182视觉上清爽很多多台机器并列查看时不至于满屏都是端口。4.2 启动Prometheus与验证抓取状态在解压目录打开当前文件夹的PowerShell窗口执行.\prometheus.exe --config.fileprometheus.yml看到日志输出Server is ready to receive web requests说明启动成功。浏览器访问http://localhost:9090这就是Prometheus自带的初版Web界面。重点看两个地方一是顶部菜单栏Status→Targets页面列出所有抓取目标及其健康状态目标状态为UP说明链路正常状态为DOWN说明拉取失败把鼠标悬停在Error信息上查看具体原因通常的原因有端口不通、防火墙拦截、服务未启动。二是切到Graph页面在输入框敲一个指标名称点Execute再点Graph标签页就能看到这个指标过去一段时间的趋势线。这一步验证通过说明数据管道已经打通。4.3 Prometheus配置为Windows服务Prometheus在控制台窗口运行有个问题——关掉窗口服务就停了这在生产环境不可接受。推荐用NSSMNon-Sucking Service Manager把Prometheus封装为Windows服务。解压NSSM后执行nssm.exe install Prometheus弹出的图形界面中Path选D:\prometheus\prometheus.exeStartup directory填D:\prometheusStartup parameters填--config.fileprometheus.yml点Install service就完成了。之后在Windows服务管理器里把Prometheus设为自动启动类型重启机器后服务自动拉起不用人工干预。Alertmanager也可以同样用NSSM封装成服务。Grafana因为自带grafana-server的Windows服务安装支持可以执行.\bin\grafana.exe server install然后服务管理器里启用。注意在PowerShell里执行exe文件时如果路径带空格要用 完整路径的方式调用。Windows上部署开源Go程序时经常遇到路径问题习惯性把组件放在纯英文无空格路径下最省事。5. Grafana可视化配置做出第一块监控仪表盘5.1 启动Grafana与初始账号登录Grafana 10.x解压后执行.\bin\grafana-server.exe启动首次访问http://localhost:3000会进入初始化页面。默认管理员账号密码是admin/admin第一次登录会强制要求修改密码改成强密码保存好。这一步不做的话监控数据裸奔在公网内容特别危险——如果端口被端口扫描探测到被别人登录进去改掉你的告警配置后果很严重。5.2 添加Prometheus数据源登录后左侧菜单齿轮图标选Data Sources点Add data source类型选PrometheusURL填http://localhost:9090注意不要漏掉http://前缀。填完点Save Test页面显示绿色的Successfully queried the Prometheus API说明数据源连接成功。如果测试失败大概率是Prometheus没启动或者是从Grafana所在机器访问Prometheus的9090端口不通。Grafana和Prometheus装在同一台机器上时最常见的原因是Prometheus程序没正常运行重新检查一遍控制台日志就行。5.3 导入现成的Windows监控Dashboards自己从零画一张面板可是不小的体力活但Grafana社区已经有人做好的现成模板导入即可用。左侧菜单Dashboards→Import在Import via grafana.com框里直接填入Dashboard ID12685点击Load数据源选之前配好的Prometheus点Import完成导入。模板导入之后顶部通常会有一个变量过滤器比如Host选择一个Windows服务器实例后下面所有图表CPU使用率、内存使用率、磁盘剩余空间、系统开机时长、网络流量等就全部联动切换。我用过很多社区的Windows监控模板12685这套覆盖比较全信息密度合理关键图表都有CPU按核数的使用率热力图、内存可用量趋势、每个磁盘分区的剩余空间饼图、网络收发速率、系统日志相关的异常指标等。提示模板导入后不要急着用先核对数据是否符合预期。比如CPU图表的PromQL表达式如果用了windows_cpu_time_total注意是否需要乘以100变成百分比格式。模板难免有和当前版本指标结构不一样的地方学会简单改PromQL非常重要。5.4 关键图表背后的PromQL逻辑监控面板的价值取决于PromQL写的对不对这里给出三个最核心的查询表达式理解了它们后续改面板就很顺手。CPU使用率Gauge类型不需要rate直接取除以总核数100 - (avg(rate(windows_cpu_time_total{modeidle}[2m])) * 100)这段意思先算各CPU核的空闲时间的每秒增速然后取所有核的平均值再乘以100变成百分比最后用100减去这个值得到使用率。为什么用rate()而不是直接用值因为windows_cpu_time_total是累加秒数只有算增速才能反映当前负荷。内存使用率100 - (windows_os_physical_memory_free_bytes / windows_os_physical_memory_free_bytes * 100)严格讲上面写法不太对正确处理方式是100 * (1 - (windows_os_physical_memory_available_bytes / windows_os_physical_memory_total_bytes))注意指标名称别混windows_os_physical_memory_free_bytes有时比windows_memory_available_bytes数值偏低官方推荐以后者为准做可用内存判断——它包含备用列表里的可用内存也就是被缓存的工厂数据实际可以立即释放的部分。内存总量用windows_os_physical_memory_total_bytes这个指标。磁盘使用率按卷分组100 * (1 - (windows_logical_disk_free_bytes{volumeC:} / windows_logical_disk_size_bytes{volumeC:}))如果有多个分区可以把volumeC:标签去掉加上by (instance, volume)做分组展示100 * (1 - (windows_logical_disk_free_bytes / windows_logical_disk_size_bytes)) by (instance, volume)这几条查询在调试时会非常有用。Grafana里可以直接在面板的Edit界面改查询表达式并实时预览改到符合预期再保存。6. Alertmanager邮件告警配置故障信息真正送达6.1 Alertmanager核心模块的配置结构Alertmanager的职责是把Prometheus推送过来的告警去重、分组、抑制后通过配置好的接收器发送出去。它的配置文件叫alertmanager.yml核心分成三块route用来路由分组receivers用来定义通知渠道inhibit_rules用来做抑制避免告警轰炸。这里看一个能直接用于邮件告警的配置实例global: smtp_smarthost: smtp.qq.com:465 smtp_from: monitorexample.com smtp_auth_username: monitorexample.com smtp_auth_password: 邮箱SMTP授权码 smtp_require_tls: false route: group_by: [alertname, instance] group_wait: 10s group_interval: 30s repeat_interval: 1h receivers: - name: email-notify email_configs: - to: opsexample.com send_resolved: true这里用465端口做发信。大多数免费邮箱的SMTP发信为了防垃圾邮件不用明文密码而是用一个固定长度的授权码比如某常用邮箱在设置里开启SMTP服务后会给你一串授权码。smtp_require_tls建议设false因为现代邮箱在465端口本身就强制加密不需要额外声明STARTTLS。如果设成true反而会出现握手失败等着收报错。route段参数是告警系统生命周期最关键的部分。group_wait: 10s表示一个分组内的第一条告警出现后等10秒再发送这样同一时段触发的多条相近告警比如多台机器一起磁盘满会被合并成一条邮件而不是轰炸N封。repeat_interval: 1h表示同一组告警在发送过之后至少间隔1小时才重复提醒否则CPU持续跑满时你的邮箱每隔15秒就被轰炸一次结果往往是心态崩了把规则一删了之。send_resolved: true必须打开这是很多人忽略的亮点当告警恢复比如磁盘被清理了、CPU降下来了时Alertmanager会再给你发一条恢复通知。这条恢复邮件可能比告警邮件更让人舒心——意味着故障处理流程可以关闭了。6.2 Prometheus告警规则文件的具体写法Prometheus这边需要单独准备一个规则文件alert_rules.yml用来定义什么条件算告警。这里直接给一套完整的三大资源告警规则groups: - name: windows_alert_rules rules: - alert: CPUUsageHigh expr: 100 - (avg(rate(windows_cpu_time_total{modeidle}[5m])) * 100) 85 for: 5m labels: severity: warning annotations: summary: {{ $labels.instance }} CPU使用率过高 description: CPU使用率已持续超过85%达5分钟当前值{{ $value | humanizePercentage }} - alert: MemoryUsageHigh expr: 100 * (1 - (windows_os_physical_memory_available_bytes / windows_os_physical_memory_total_bytes)) 90 for: 5m labels: severity: warning annotations: summary: {{ $labels.instance }} 内存使用率过高 description: 内存使用率已持续超过90%达5分钟当前值{{ $value | humanizePercentage }} - alert: DiskSpaceLow expr: 100 * (1 - (windows_logical_disk_free_bytes / windows_logical_disk_size_bytes)) by (instance, volume) 90 for: 10m labels: severity: critical annotations: summary: {{ $labels.instance }} 磁盘{{ $labels.volume }} 空间不足 description: 磁盘{{ $labels.volume }}使用率已持续超过90%达10分钟当前值{{ $value | humanizePercentage }}这三个规则分别对应三大监控目标。注意两个关键设计一是for参数它要求条件连续满足一段时间才触发告警能有效过滤瞬时尖峰干扰。CPU负载偶尔闪到95%可能只是临时任务持续5分钟才需要人工介入。二是告警规则里使用模板标签{{ $labels.instance }}会动态替换成实际触发告警的服务器IP{{ $value }}是当前的实际数值这样收到的邮件信息完整不用打开电脑查是哪台机器的问题。6.3 规则与配置的校验机制配置完写错是家常便饭好在两个关键命令工具都能帮忙校验。Prometheus提供了promtool check config命令Alertmanager也提供了类似功能.\promtool.exe check config prometheus.yml .\amtool.exe check-config alertmanager.yml执行后看到SUCCESS相关的措辞说明配置语法错误、格式没问题可以启动服务了。我建议每次改完配置都先跑一遍检查不到半分钟的动作可以省去一晚上的调试时间。promtool还能检查告警规则文件.\promtool.exe check rules alert_rules.yml把规则单独拆出来检查尤其重要——规则文件里的PromQL都是比较复杂的聚合表达式括号、引号、标签匹配一处写错你的告警条件就隐身了表面上一切正常实际告警永远不触发。规则语法错误会被Prometheus踢出加载列表在Status→Rules页面就能看到红色报错信息。6.4 告警触发流程的全链路验证把所有组件都启动好后可以做一次规则验证验证告警链路是否通。方法是用配置里告警阈值的两倍来临时构造一条测试看Alertmanager能不能收到邮件。更快的测试方法是用Windows的性能工具人为制造高负载比如安装一个压测工具把CPU占满等规则条件达到后看告警邮件是否发出。压测能扰动业务的就不要直接生产环境做可以往规则里临时塞一条prometheus_tsdb_head_samples_appended_total 0这种必然满足的规则触发后马上关掉验证邮件通道通畅即可。7. 常见问题与排查技巧实录这套监控玩了半年踩过的坑7.1 数据采集链路问题速查现象可能原因排查方法Prometheus Targets页面显示DOWNwindows_exporter服务未启动在目标Windows机器上执行net start windows_exporter访问9182端口验证Targets页面显示UP但图表无数值指标名称不匹配在Prometheus Graph页面用{__name__~windows_.*}查一下实际存在什么指标磁盘图表显示空白采集器未启用logical_disk检查安装MSI时是否加了ENABLED_COLLECTORS参数少了的话重新安装服务Grafana表格显示NaNPromQL除法分母为零服务器重启瞬间计数值为0图表时间范围拉长点看趋势即可Alertmanager收到告警但没邮件SMTP授权码错误或端口不通看Alertmanager日志levelerror报错信息telnet测试SMTP端口连通性7.2 Prometheus自身占用的资源问题很多人在小型Windows服务器上部署Prometheus会忽略监控工具自身的资源开销。Prometheus对内存的消耗随指标基数增大而明显尤其是当你的scrape_interval设置过短、抓取目标过多时。我见过有台只有2GB内存的老服务器装了全套监控后内存直接吃掉800MB于是把抓取间隔从15秒改到30秒把5个不需要的采集器关掉总算控制住。Grafana是另一个吃内存大户尤其是同时开了多个大表盘每个图表每次刷新都要往Prometheus发起查询请求。相对经济的方式是把Grafana面板的自动刷新时间从默认5秒改成30秒或者1分钟对于看水位这种低频变化的监控需求刷新太频繁除了费资源没什么额外收益。7.3 邮件告警偶尔延迟或重复的玄学问题邮件告警系统跑起来之后经常遇到的两类玄学问题第一类是告警邮件延迟到达正常情况下Alertmanager发送邮件是秒级的但SMTP服务器如果一段时间内发信太多容易被发信方限流。解决方法是限制告警数量而不是调整发信频率比如把多个告警合并成摘要。第二类是重复发信让人烦躁本质是repeat_interval的时间设置不当——设置的比告警持续时间短时一个持续1小时的故障就按1小时N次的频率重复通知。我这里统一用repeat_interval: 24h来配置极端故障场景下一天最多一条邮件提醒不刷屏出了问题也有历史记录可查。7.4 邮件安全的小白级注意事项邮箱授权码千万不要和账户密码等同对待。GitHub公开的项目里面有各种配置文件如果把授权码明文写在alertmanager.yml里再误传到公开仓库你的邮箱会成为垃圾邮件发送源的肉鸡。稳妥的做法是把授权码配置在环境变量里或者至少把配置文件权限收紧到只有管理员账号能读。7.5 服务器重启后监控恢复的自动化保障把四个组件全装好、配置调通之后最后一步也是很多人会忘的确保服务器重启后监控服务能自动启动。Prometheus和Alertmanager通过NSSM注册为Windows服务后要在服务管理器中把启动类型设为自动同时确认登录身份是Local System就可以读到本地磁盘配置。Windows服务管理器会操心开机顺序的问题服务间的依赖关系不用卡太死——Alertmanager启动晚一点没关系Prometheus一开始连不上也没什么因为它会不断重试。真正要紧的是各项服务本身能自动拉起省的半夜机器重启了你第二天爬起来开监控。8. 这套方案还能往哪里扩展整套监控跑通了之后我发现这套体系最值钱的不是那几个图表而是这个框架本身可以无痛承载更多监控维度。以后如果要加新的监控项无非就三步给目标机器装对应exporter、在prometheus.yml加一组job、在Grafana导入一张新面板。比如想监控Windows机器的网络流量只需在安装windows_exporter时不要关掉net采集器然后在Grafana里加一个网络吞吐量图表。想监控某台机器的特定Windows服务是否在运行也可以用windows_exporter的service采集器配合告警规则。指标库里点一下都能找到对应的数据动动PromQL就能出你想要的面板。如果想往更深方向走还可以给这套框架加一层自定义节点监控——比如自己写一个小脚本定期往某个Pushgateway推业务数值Prometheus照常从Pushgateway拉数据一套框架就把系统和业务监控全包了。这个扩展思路在后期会非常实用。截止到这里Prometheus采集数据、Grafana展示图表、Alertmanager发送邮件这条完整链路已经全部跑通。我最初在给那台业务服务器部署这套监控时从零开始到邮件告警落地前后也就用了四五个小时。中间最大的心得是配置项本身就那些上手最大的障碍不是技术难度而是对组件间关系的熟悉程度。先把数据流走向记清楚哪一步该看哪个组件的日志部署起来自然顺畅。