目录Windows 环境监控的特殊性采集方式选型一句话结论Zabbix Agent 安装与配置系统层监控CPU / 内存 / 磁盘 / 网络服务层监控Windows 服务状态告警进程层监控关键进程存活与资源占用Windows 性能计数器采集定制指标告警规则与分级配置6 个生产踩坑与运维平台结合部署 Checklist1. Windows 环境监控的特殊性Windows 服务器的监控在大多数运维团队里是一个三不管地带Linux 运维不熟 Windows 生态Windows 管理员不碰 Zabbix结果就是几十台跑着 ERP、收银系统、MES、域控的生产服务器在监控平台上只有一个 Ping 状态。如果你打开 Zabbix 主机列表看到一堆 Windows 主机只有绿框的可用标记但 CPU、内存、磁盘、服务状态栏全是空的——那说明你就在这个困境里。这个困境的代价不是抽象的。Windows 服务无声崩溃、磁盘悄悄写满、进程假死——这些问题在 Windows Server 上的发生概率不比 Linux 低但因为监控缺失发现时间往往以小时计。而对于连锁门店、制造工厂这类场景一台门店服务器上的 SQL Server 崩了影响的是几十家门店的收银开票一台产线 MES 服务器内存耗尽卡的是整个班次的生产。本文给出一套完整的 Windows Server 监控配置方案覆盖系统层、服务层、进程层三个维度所有配置均在 Zabbix 6.x 上生产验证。2. 采集方式选型一句话结论Windows 监控有三种采集方式但选型不需要纠结——首选 Zabbix Agent只有两种例外用别的首选Zabbix AgentWindows 版覆盖最全、配置最灵活本文所有配置基于此方式唯一例外不允许安装第三方软件的设备如工控机用 SNMP 做基础 Ping 端口检测即可指标覆盖别指望太多进阶Zabbix Agent 2 的 WMI 模块能采集 IIS 应用池、COM 应用等深度 Windows 指标但 WMI 查询有性能开销一般场景用不到非 IIS/COM 场景直接用 Agent 裸 Key 就够了3. Zabbix Agent 安装与配置3.1 下载安装在 https://www.zabbix.com/download 下载对应版本的 Windows MSI 安装包选Windows Agent注意与 Zabbix Server 版本匹配。或用 PowerShell 直接下载安装# PowerShell以管理员身份运行$version6.4$urlhttps://cdn.zabbix.com/zabbix/binaries/stable/$version/zabbix_agent2-$version.0-windows-amd64-openssl.msiInvoke-WebRequest-Uri$url-OutFileC:\Temp\zabbix_agent2.msi# 静默安装指定 Zabbix Server IPStart-Processmsiexec.exe-ArgumentList (/i,C:\Temp\zabbix_agent2.msi,/qn,SERVER10.0.0.100,# 替换为你的 Zabbix Server IPSERVERACTIVE10.0.0.100,HOSTNAMEWIN-STORE-001,# 设置主机名与 Zabbix 主机名一致LOGFILEC:\Program Files\Zabbix Agent 2\zabbix_agent2.log)-Wait3.2 配置文件关键参数安装后编辑C:\Program Files\Zabbix Agent 2\zabbix_agent2.conf# Zabbix Server / Proxy 地址被动监控用 Server10.0.0.100 # Zabbix Server 主动监控地址主动模式用 ServerActive10.0.0.100 # 主机名必须与 Zabbix 前端添加主机时的名称完全一致 HostnameWIN-STORE-001 # 允许远程命令用于自动化修复脚本 # AllowKeysystem.run[*] # 生产环境谨慎开启有安全风险 # 自定义监控脚本目录 UserParametercustom.*,C:\ZabbixScripts\*.ps1 # 日志级别正常运行后改为 3debug 级别日志量很大 DebugLevel3 # 监听端口 ListenPort10050配置完成后重启服务Restart-ServiceZabbix Agent 2# 验证服务状态Get-ServiceZabbix Agent 2|SelectStatus,StartType3.3 防火墙放行# 放行 Zabbix Agent 默认端口New-NetFirewallRule-DisplayNameZabbix Agent-Direction Inbound -Protocol TCP -LocalPort 10050 -Action Allow# 验证Test-NetConnection-ComputerName 10.0.0.100-Port 10051### 3.4 批量部署PowerShell Remoting 一次覆盖多台 手动逐台安装在管 50 台以上 Windows Server 的场景里完全不现实。用 PowerShell Remoting 可以把 Agent 部署变成流水线作业。 **前提**目标机器已启用 WinRM企业内网域环境默认开启非域环境参考下方一键开启命令。 powershell # 在目标机器上一键开启 WinRM域外环境用管理员身份运行 Enable-PSRemoting -Force Set-Item WSMan:\localhost\Client\TrustedHosts -Value 10.0.0.* -Force# deploy_zabbix_agent.ps1# 批量部署 Zabbix Agent 2 到多台 Windows Server# 在管理机上以管理员身份运行$ZabbixServer10.0.0.100# 你的 Zabbix Server IP$AgentMsiUrlhttps://cdn.zabbix.com/zabbix/binaries/stable/6.4/zabbix_agent2-6.4.0-windows-amd64-openssl.msi$LocalMsiPathC:\Temp\zabbix_agent2.msi$CredentialGet-Credential# 输入有管理员权限的账号# 目标主机列表从 CSV 读取CSV格式: Hostname,IP$TargetsImport-CsvC:\Temp\windows_servers.csv# CSV 示例# Hostname,IP# WIN-STORE-001,192.168.1.101# WIN-STORE-002,192.168.1.102foreach($targetin$Targets){$hostname$target.Hostname$ip$target.IPWrite-Host[$hostname] 开始部署...-ForegroundColor Cyantry{Invoke-Command-ComputerName$ip-Credential$Credential-ScriptBlock{param($ZabbixServer,$AgentMsiUrl,$LocalMsiPath,$HostnameParm)# 1. 下载 MSI如果内网有文件服务器改成 UNC 路径更快if(-not(Test-Path$LocalMsiPath)){New-Item-ItemType Directory-Path(Split-Path$LocalMsiPath)-Force|Out-NullInvoke-WebRequest-Uri$AgentMsiUrl-OutFile$LocalMsiPath-UseBasicParsing}# 2. 静默安装$args/i$LocalMsiPath/qn SERVER$ZabbixServerSERVERACTIVE$ZabbixServerHOSTNAME$HostnameParmStart-Processmsiexec.exe-ArgumentList$args-Wait# 3. 开防火墙New-NetFirewallRule-DisplayNameZabbix Agent-Direction Inbound -Protocol TCP-LocalPort 10050-Action Allow-ErrorAction SilentlyContinue# 4. 确认服务状态$svcGet-ServiceZabbix Agent 2-ErrorAction SilentlyContinueif($svc-and$svc.Status-eqRunning){Write-OutputOK}else{Write-OutputFAILED}}-ArgumentList$ZabbixServer,$AgentMsiUrl,$LocalMsiPath,$hostnameWrite-Host[$hostname] 部署完成-ForegroundColor Green}catch{Write-Host[$hostname] 部署失败:$_-ForegroundColor Red}}选 PowerShell Remoting 而不是 SCCM 或 GPO是因为我们的实际场景是几十台门店服务器分散在不同网段、没有统一域控。SCCM 对这种零散部署太重了GPO 需要域环境。PowerShell Remoting 的代价只是一个Enable-PSRemoting对于没有域的门店/工厂网络是最务实的方案。部署完成后在 Zabbix Server 侧批量注册主机。手工在 Web 前端逐个添加主机同样不现实——好在 Zabbix 提供了完整的 JSON-RPC API一个 bash 脚本就能批量搞定。关键参数说明groupid和templateid需要根据你自己 Zabbix 环境的实际 ID 替换在 Zabbix 前端 URL 中可以看到端口 10050 是 Agent 被动模式的默认监听端口# 用 Zabbix API 批量注册Linux Bash 示例ZABBIX_URLhttp://10.0.0.100/zabbix/api_jsonrpc.phpAUTH_TOKEN$(curl-s-XPOST $ZABBIX_URL\-HContent-Type: application/json\-d{jsonrpc:2.0,method:user.login,params:{user:Admin,password:zabbix},id:1}\|python3-cimport sys,json;print(json.load(sys.stdin)[result]))# 读取 CSV 批量创建主机whileIFS,read-rhostnameip;docurl-s-XPOST$ZABBIX_URL\-HContent-Type: application/json\-d{\jsonrpc\:\2.0\,\method\:\host.create\,\params\:{\host\:\$hostname\,\interfaces\:[{\type\:1,\main\:1,\useip\:1,\ip\:\$ip\,\dns\:\\,\port\:\10050\}],\groups\:[{\groupid\:\10\}],\templates\:[{\templateid\:\10081\}]},\auth\:\$AUTH_TOKEN\,\id\:2}done(tail-n2 windows_servers.csv)4. 系统层监控CPU / 内存 / 磁盘 / 网络在 Zabbix 前端添加主机后应用Windows by Zabbix Agent 2模板Zabbix 内置自动覆盖以下系统层指标指标Zabbix Key说明CPU 使用率system.cpu.util[,idle]建议告警阈值85% 持续 5 分钟内存使用率vm.memory.size[pused]建议告警阈值88% 持续 5 分钟磁盘剩余空间vfs.fs.size[C:,pfree]建议告警阈值剩余 15%磁盘 I/O 等待perf_counter[\PhysicalDisk(_Total)\% Disk Time]持续高于 80% 说明 I/O 瓶颈网络发送速率net.if.out[以太网,bytes]监控各网卡注意接口名称关键注意Windows 磁盘剩余告警要对每个驱动器单独配置。C: 系统盘和数据盘D:、E:有不同的告警阈值。这几个系统层指标看起来和 Linux 监控一样但 Windows 上有两个容易被忽视的差别一是 Windows 的磁盘 I/O 比 Linux 更容易成为瓶颈——NTFS 文件系统在大量小文件场景下的性能退化比 ext4/xfs 更明显二是 Windows 的内存管理机制不同Available MBytes比% Committed Bytes更能反映实际可用内存因为 Windows 会积极使用 SuperFetch 预加载只看空闲内存容易误判。4.1 系统层指标告警阈值速查表指标Zabbix KeyWARNINGCRITICAL第一步排查CPU 使用率system.cpu.util[,idle]75%/5min90%/5minGet-Process | Sort CPU -Desc | Select -First 10内存使用率vm.memory.size[pused]80%/5min92%/5minGet-Process | Sort WorkingSet -Desc | Select -First 10C: 磁盘剩余vfs.fs.size[C:,pfree]15%5%Get-ChildItem C:\ -Recurse -ErrorAction SilentlyContinue | Sort Length -Desc | Select -First 20数据盘剩余vfs.fs.size[D:,pfree]20%8%检查日志/备份目录磁盘 I/O 等待perf_counter[\PhysicalDisk(_Total)\% Disk Time]70%90%找高 I/O 进程Get-Counter \Process(*)\IO Data Bytes/sec网络带宽占用net.if.out[以太网,bytes]70% 链路90% 链路Get-NetAdapterStatistics系统运行时长system.uptime—30min非计划重启查事件日志 6008/1074这张表可以直接打印贴在值班室——告警触发后第一步该查什么一列之内就能确定。4.2 多驱动器磁盘告警注意事项Windows Server 经常有多个驱动器C: 系统盘、D: 数据盘、E: 备份盘Zabbix 内置模板默认只监控 C: 盘。在部署时需要在 Windows 上确认实际有哪些驱动器然后为每个驱动器单独配置告警。快速确认驱动器列表的命令Get-PSDrive -PSProvider FileSystem | Select Name, Used, Free。注意区分系统盘和数据盘的告警阈值C: 盘建议 WARNING 15%、CRITICAL 5%系统盘满了会导致服务不可用数据盘可以放宽到 WARNING 20%、CRITICAL 8%但如果数据盘存的是数据库文件或日志建议和 C: 盘用同样严格的阈值——我们在一个制造业客户那里见过 D: 盘剩余 12% 时 SQL Server 已经开始报空间不足的 Warning 日志了。5. 服务层监控Windows 服务状态告警Windows 服务状态监控是 Linux 监控工程师最容易遗漏的部分。5.1 批量监控所有自动启动服务Zabbix 内置 Keyservice.info[服务名,state]可以采集单个服务状态但手动配置每个服务效率太低。推荐用 LLD低级发现自动发现在 Zabbix 中创建发现规则# Zabbix 发现规则配置在前端操作Discovery Rule Name:Windows Services DiscoveryKey:service.discoveryUpdate interval:1h# 过滤条件只监控启动类型为自动的服务Filter:-Macro:{#SERVICE.STARTUPNAME}Regex:^Auto$发现后自动为每个服务创建监控项和告警触发器。这个 LLD 方案的关键设计决策是只监控启动类型为Auto的服务。为什么不监控所有服务因为 Windows Server 上有大量手动触发器启动的服务平时是停止状态比如 Windows Update、各种一次性任务服务如果全部纳入监控每天会产生大量服务已停止的噪音告警。我们的经验是Auto类型覆盖了所有应该一直运行的服务漏掉的风险极低。5.2 手动监控关键业务服务对 ERP、收银、SQL Server 等关键服务额外创建高优先级触发器# 在 Zabbix 前端创建 ItemItem name:SQL Server Service StatusKey:service.info[MSSQLSERVER,state]Type:Zabbix Agent (active)Value type:Numeric (unsigned)Update interval:60s# 触发器Trigger name:SQL Server Service Down on{HOST.NAME}Expression:last(/主机名/service.info[MSSQLSERVER,state])0Severity:High用 PowerShell 验证服务状态采集# 在 Zabbix Server 侧用 zabbix_get 测试# zabbix_get -s 10.x.x.x -k service.info[MSSQLSERVER,state]# 返回 0 运行中1 已停止2 暂停7 未安装# 本地快速测试在 Windows 上执行Get-ServiceMSSQLSERVER|SelectStatus5.3 Windows 服务状态值速查返回值含义0Running运行中1Stopped已停止2Start Pending3Stop Pending4Continue Pending5Pause Pending6Paused已暂停7Not Installed服务不存在6. 进程层监控关键进程存活与资源占用服务可以运行中但进程已经假死——这个问题在 Windows 上比 Linux 更常见。Windows 服务控制管理器SCM只检测进程是否存在不检测进程是否在正常工作。我们遇到过 SQL Server 服务状态显示 “Running”但实际进程已经死锁CPU 100% 卡死所有查询超时。这就是进程层监控存在的原因——它绕过 SCM直接检查进程本身。6.1 进程存活监控# Item 配置Key:proc.num[sqlservr.exe]# 返回运行中该名称进程的数量# 触发器SQL Server 进程消失Expression:last(/主机名/proc.num[sqlservr.exe])0Severity:Disaster6.2 进程 CPU / 内存占用# 进程 CPU 占用百分比Key:proc.cpu.util[sqlservr.exe]# 进程内存占用字节Key:proc.mem[sqlservr.exe,rss]# 触发器SQL Server 进程内存超过 8GBExpression:last(/主机名/proc.mem[sqlservr.exe,rss])8589934592Severity:Warning6.3 用 PowerShell 自定义进程监控脚本# C:\ZabbixScripts\check_process_cpu.ps1param([string]$ProcessName)$procGet-Process-Name$ProcessName-ErrorAction SilentlyContinueif(-not$proc){Write-Output0exit}# 获取进程 CPU 使用率需要采样间隔计算$cpu(Get-Counter\Process($ProcessName)\% Processor Time-SampleInterval 2-MaxSamples 1).CounterSamples.CookedValue[Math]::Round($cpu/(Get-WmiObjectWin32_ComputerSystem).NumberOfLogicalProcessors,2)在 Agent 配置文件中注册UserParameterproc.cpu.custom[*],powershell -NoProfile -ExecutionPolicy Bypass -File C:\ZabbixScripts\check_process_cpu.ps1 -ProcessName $17. Windows 性能计数器采集定制指标Windows 性能计数器Performance Counter是最完整的指标来源几乎所有 Windows 组件都暴露了 PerfCounter。7.1 常用 PerfCounter Key以下是我们生产环境中实际在用的 PerfCounter 指标每个都附上为什么要监控# ASP.NET 请求队列长度IIS 场景# 队列积压意味着 IIS 处理能力跟不上请求量是应用池回收/死锁的第一信号perf_counter[\ASP.NET\Requests Queued]# IIS 每秒请求数# 建立基线之后突降上游出问题突增可能在被刷perf_counter[\Web Service(_Total)\Get Requests/sec]# SQL Server 每秒事务数# 监控业务量的间接指标突降可能意味着数据库阻塞perf_counter[\SQLServer:Databases(_Total)\Transactions/sec]# SQL Server 缓存命中率越接近100越好低于90需关注# 低于90意味着 SQL Server 经常需要从磁盘读数据页通常是因为内存不够perf_counter[\SQLServer:Buffer Manager\Buffer cache hit ratio]# 磁盘平均读取延迟毫秒# 超过20ms说明存储层有性能问题可能影响所有依赖磁盘的服务perf_counter[\PhysicalDisk(0 C:)\Avg. Disk sec/Read,1000]这些 PerfCounter 路径都是英文版 Windows的格式。如果你在中文版 Windows 上使用记得先用 7.3 节的脚本做路径验证。7.2 如何找到可用的 PerfCounter 路径不同 Windows 版本和已安装组件会影响可用的 PerfCounter 列表。在添加自定义监控项之前先确认目标计数器是否存在# 查看 SQL Server 相关的所有 PerfCounter 指标(Get-Counter-ListSetSQLServer:Buffer Manager).Paths# 实时采样测试——确认路径有效且能返回数值Get-Counter\SQLServer:Buffer Manager\Buffer cache hit ratio如果Get-Counter -ListSet找不到预期的类别说明对应的 Windows 组件没有安装或版本不兼容。比如SQLServer:Buffer Manager只存在于安装了 SQL Server 的机器上Web Service系列只存在于启用了 IIS 的机器上。不要在模板里为所有主机配置这些指标——用主机群组或宏来控制哪些主机启用哪些 PerfCounter 监控项。### 7.3 批量验证 PerfCounter 在中文/英文 Windows 上是否可用 powershell # check_perf_counters.ps1 # 批量检查一组 PerfCounter 路径在当前 Windows 上是否能正常采集 # 在部署 Zabbix 模板前跑这个脚本提前发现 Not Supported 问题 $CountersToCheck ( \Processor(_Total)\% Processor Time, \Memory\Available MBytes, \PhysicalDisk(_Total)\% Disk Time, \PhysicalDisk(_Total)\Avg. Disk sec/Read, \SQLServer:Buffer Manager\Buffer cache hit ratio, \SQLServer:Databases(_Total)\Transactions/sec, \Web Service(_Total)\Get Requests/sec, \ASP.NET\Requests Queued ) Write-Host 检查 PerfCounter 可用性... -ForegroundColor Cyan $results () foreach ($counter in $CountersToCheck) { try { $val (Get-Counter $counter -SampleInterval 1 -MaxSamples 1 -ErrorAction Stop).CounterSamples.CookedValue $results [PSCustomObject]{ Counter$counter; StatusOK; Value[Math]::Round($val,2) } } catch { # 中文版 Windows 路径失败时尝试用 typeperf 找本地化名称 $localName typeperf -q 2$null | Where-Object { $_ -match ($counter -replace .*\\,) } | Select-Object -First 1 $results [PSCustomObject]{ Counter$counter; StatusFAIL; Valueif($localName){可能本地化为: $localName}else{未找到} } } } $results | Format-Table -AutoSize $failCount ($results | Where-Object {$_.Status -eq FAIL}).Count Write-Host 总计: $($results.Count) 个通过: $($results.Count - $failCount) 个失败: $failCount 个 -ForegroundColor $(if($failCount -gt 0){Red}else{Green})这个脚本不是凭空想出来的。有一次我们给一家制造企业部署 30 台车间 Windows Server 的 Zabbix 监控模板批量应用之后有 7 台中文版 Windows 的 PerfCounter 指标全部显示 Not Supported。在 Zabbix 前端排查 Not Supported 的原因很痛苦——你不知道是 Agent 没装好、网络不通、还是路径问题。挨台远程上去用typeperf -q逐个确认3 个人花了整整一个下午才把所有路径纠正过来。那之后我们就把这个检查做成了部署前置脚本——接新机器先跑这个5 秒出结果哪台有问题、哪些路径要本地化一目了然。其实所有看起来很简单的脚本背后都是一个不想再重复的坑。8. 告警规则与分级配置8.1 告警分级参考表级别触发条件示例Disaster核心服务/进程消失SQL Server 进程消失、AD 认证服务停止High磁盘剩余 5%、内存 95%系统盘快满、内存即将耗尽AverageCPU 85%/5min、内存 88%/5min性能指标持续高位Warning磁盘剩余 15%、IIS 请求队列积压容量预警、性能下降Info系统重启、服务重启恢复非预期重启需要关注原因8.2 系统重启检测# Item系统启动时间Key:system.uptimeValue type:Numeric (float)Units:uptime# 触发器检测非计划重启如果 uptime 30 分钟且不在维护期Trigger name:Unexpected reboot on{HOST.NAME}Expression:last(/主机名/system.uptime)1800Severity:Average9. 6 个生产踩坑以下每个坑都是我们在连锁门店、制造业场景中实际踩过的。问题本身可能看起来不大但每个坑的排查过程都至少耗费了半天——分享出来的目的就是让你跳过这些排查。坑1Agent 配置的 Hostname 与 Zabbix 前端主机名不匹配这是最高频的问题。Agent 配置的HostnameWIN-STORE-001但 Zabbix 前端添加主机时写的是win-store-001小写导致主动检测数据无法上报被动检测正常。结果部分指标有值部分指标显示 Not Supported。排查Zabbix Server 日志/var/log/zabbix/zabbix_server.log里搜Hostname。主机名区分大小写。这个坑在批量部署时最容易出现——PowerShell 脚本里用$env:COMPUTERNAME拿到的是全大写而有人手动在前端添加主机时习惯用首字母大写。50台机器部署完发现30台主动监控不工作就是这个原因。坑2磁盘驱动器名称中文乱码部分 Windows Server 的磁盘分区名称包含中文如本地磁盘用 LLD 自动发现时宏{#FSNAME}中的中文在 Zabbix Item Key 里会乱码导致监控项创建失败。解决在 LLD 过滤器里限制只监控字母冒号格式的路径如C:、D:排除中文路径Filter: {#FSNAME} matches ^[A-Za-z]:$坑3性能计数器路径在不同语言版本 Windows 上名称不同中文版 Windows 和英文版 Windows 的 PerfCounter 路径不一样。英文版\Processor(_Total)\% Processor Time中文版可能是\处理器(_Total)\% 处理器时间。Zabbix 内置的 Windows 模板使用的是英文路径在中文 Windows 上会返回 Not Supported。解决用typeperf命令在目标 Windows 上确认实际路径typeperf-qProcessor|Where-Object{$_-matchProcessor Time}然后在 Zabbix Item 里使用本地实际路径或切换使用system.cpu.util等 Agent 内置 Key不依赖 PerfCounter。这个坑我们在第7.3节讲了具体踩坑经历——7台中文版 Windows 全返回 Not Supported排查了整整一个下午。教训就是模板部署之前先跑 check_perf_counters.ps1。坑4Zabbix Agent 在 Windows Server 2022 上无法启动现象安装成功但服务启动失败事件日志里有 “The Zabbix Agent service terminated with service-specific error Incorrect function.”原因通常是 OpenSSL 版本不兼容或下载的 Agent 版本不对分 x86 和 x64以及 OpenSSL / GnuTLS 两个加密库版本。解决从 Zabbix 官方下载页面选择 Windows Server 2022 对应的openssl版本且确认 x64大多数现代 Windows Server 都是 x64。坑5监控 IIS 应用池但实例名包含空格IIS 应用池名称如 “Default App Pool” 含有空格放进 PerfCounter Key 时会报错。解决使用下划线替代空格或用引号包裹perf_counter_en[\Process(w3wp#0)\% Processor Time]用Get-Counter先测试确认实际实例名。坑6Windows 防火墙阻断 Zabbix 主动监控被动模式Server 轮询 Agent可以正常工作但主动模式Agent 向 Server 汇报数据缺失。原因Windows 防火墙的出站规则默认允许所有出站但部分安全加固过的环境限制了出站导致 Agent 无法主动连接 Server 的 10051 端口。解决检查出站规则放行 Zabbix Server IP 的 10051 端口出站连接。这个坑比较隐蔽因为被动监控一切正常很容易让人觉得Agent 配好了。排查技巧在 Windows 上用Test-NetConnection -ComputerName 你的ZabbixServerIP -Port 10051验证出站连通性不通就查防火墙出站规则。10. 与运维平台结合实事求是的说这套方案在 50 台以内的 Windows Server 规模下跑得很稳但当机器数超过 100 台、而且中英文 Windows 版本混布时维护成本会非线性增长新入一台中文版要单独验证 PerfCounter 路径、Zabbix Agent 版本升级要逐台跟进、LLD 规则对不同 Windows Server 版本偶尔不兼容需要单独处理。我们在维护了大概半年之后把这套 Windows Server 监控整体迁移到了冠服云EMS平台的 ITOM 模块主要解决了两件事一是 Windows Server 的纳管变成平台内置能力不再需要单独维护一套 Agent 集群和模板体系二是门店侧有新设备上线时注册一次就能自动下发监控策略不需要走装 Agent → 改配置 → 前端加主机 → 验指标的完整流程。当然如果你已经在用 Zabbix 且规模不大本文的方案完全够用。只是当 Windows 服务器数量开始往 3 位数走的时候值得考虑是否需要把监控能力从手工搭建升级为平台内置。11. 部署 Checklist安装阶段确认 Zabbix Agent 版本与 Server 版本匹配主版本号一致确认下载 x64 版本大多数 Windows Server 是 x64安装后确认Zabbix Agent 2服务为自动启动状态防火墙放行入站 TCP 10050被动模式/ 出站 TCP 10051主动模式配置阶段Hostname参数与 Zabbix 前端主机名大小写完全一致Server和ServerActive填写正确的 Zabbix Server/Proxy IP在 Zabbix 前端添加主机应用Windows by Zabbix Agent 2模板验证等待 5 分钟后主机状态变绿指标有最新数据监控覆盖阶段系统层CPU / 内存 / 磁盘 / 网络 指标均有值不是 Not Supported确认磁盘监控覆盖所有驱动器C: / D: / E: 等关键服务监控SQL Server / IIS / AD 等已单独创建高优先级触发器关键进程存活监控已配置所有 PerfCounter Key 在目标 Windows 语言版本上已验证不报 Not Supported告警阶段Disaster 级别告警测试停止 SQL Server 服务确认告警到达系统重启检测触发器已配置各驱动器磁盘预警阈值已按实际情况设置系统盘和数据盘阈值不同运营阶段告警已对接工单系统或即时通知渠道有明确负责人每季度检查 Not Supported 指标列表修复失效采集新增 Windows 服务器时有标准化注册流程不靠人记觉得有用的话点个赞/收藏Windows Server 监控这套配置跑通之后新机器接入就是套模板的事比每次现查文档快多了。相关内链CSDN-47连锁门店Zabbix架构 https://blog.csdn.net/weixin_70758133/article/details/161445385?spm1011.2415.3001.5331CSDN-04告警降噪https://blog.csdn.net/weixin_70758133/article/details/158572672?spm1011.2415.3001.5331参考资料Zabbix 官方 Windows Agent 安装文档Zabbix API 官方参考往期相关文章连锁门店 Zabbix Proxy 分布式监控架构 多源告警统一接入方案站内链接发布时替换为实际文章 URLWindows Performance Counters 官方文档
Windows Server 监控实战：Zabbix Agent + 性能计数器，服务/进程/系统三层告警完整配置指南
目录Windows 环境监控的特殊性采集方式选型一句话结论Zabbix Agent 安装与配置系统层监控CPU / 内存 / 磁盘 / 网络服务层监控Windows 服务状态告警进程层监控关键进程存活与资源占用Windows 性能计数器采集定制指标告警规则与分级配置6 个生产踩坑与运维平台结合部署 Checklist1. Windows 环境监控的特殊性Windows 服务器的监控在大多数运维团队里是一个三不管地带Linux 运维不熟 Windows 生态Windows 管理员不碰 Zabbix结果就是几十台跑着 ERP、收银系统、MES、域控的生产服务器在监控平台上只有一个 Ping 状态。如果你打开 Zabbix 主机列表看到一堆 Windows 主机只有绿框的可用标记但 CPU、内存、磁盘、服务状态栏全是空的——那说明你就在这个困境里。这个困境的代价不是抽象的。Windows 服务无声崩溃、磁盘悄悄写满、进程假死——这些问题在 Windows Server 上的发生概率不比 Linux 低但因为监控缺失发现时间往往以小时计。而对于连锁门店、制造工厂这类场景一台门店服务器上的 SQL Server 崩了影响的是几十家门店的收银开票一台产线 MES 服务器内存耗尽卡的是整个班次的生产。本文给出一套完整的 Windows Server 监控配置方案覆盖系统层、服务层、进程层三个维度所有配置均在 Zabbix 6.x 上生产验证。2. 采集方式选型一句话结论Windows 监控有三种采集方式但选型不需要纠结——首选 Zabbix Agent只有两种例外用别的首选Zabbix AgentWindows 版覆盖最全、配置最灵活本文所有配置基于此方式唯一例外不允许安装第三方软件的设备如工控机用 SNMP 做基础 Ping 端口检测即可指标覆盖别指望太多进阶Zabbix Agent 2 的 WMI 模块能采集 IIS 应用池、COM 应用等深度 Windows 指标但 WMI 查询有性能开销一般场景用不到非 IIS/COM 场景直接用 Agent 裸 Key 就够了3. Zabbix Agent 安装与配置3.1 下载安装在 https://www.zabbix.com/download 下载对应版本的 Windows MSI 安装包选Windows Agent注意与 Zabbix Server 版本匹配。或用 PowerShell 直接下载安装# PowerShell以管理员身份运行$version6.4$urlhttps://cdn.zabbix.com/zabbix/binaries/stable/$version/zabbix_agent2-$version.0-windows-amd64-openssl.msiInvoke-WebRequest-Uri$url-OutFileC:\Temp\zabbix_agent2.msi# 静默安装指定 Zabbix Server IPStart-Processmsiexec.exe-ArgumentList (/i,C:\Temp\zabbix_agent2.msi,/qn,SERVER10.0.0.100,# 替换为你的 Zabbix Server IPSERVERACTIVE10.0.0.100,HOSTNAMEWIN-STORE-001,# 设置主机名与 Zabbix 主机名一致LOGFILEC:\Program Files\Zabbix Agent 2\zabbix_agent2.log)-Wait3.2 配置文件关键参数安装后编辑C:\Program Files\Zabbix Agent 2\zabbix_agent2.conf# Zabbix Server / Proxy 地址被动监控用 Server10.0.0.100 # Zabbix Server 主动监控地址主动模式用 ServerActive10.0.0.100 # 主机名必须与 Zabbix 前端添加主机时的名称完全一致 HostnameWIN-STORE-001 # 允许远程命令用于自动化修复脚本 # AllowKeysystem.run[*] # 生产环境谨慎开启有安全风险 # 自定义监控脚本目录 UserParametercustom.*,C:\ZabbixScripts\*.ps1 # 日志级别正常运行后改为 3debug 级别日志量很大 DebugLevel3 # 监听端口 ListenPort10050配置完成后重启服务Restart-ServiceZabbix Agent 2# 验证服务状态Get-ServiceZabbix Agent 2|SelectStatus,StartType3.3 防火墙放行# 放行 Zabbix Agent 默认端口New-NetFirewallRule-DisplayNameZabbix Agent-Direction Inbound -Protocol TCP -LocalPort 10050 -Action Allow# 验证Test-NetConnection-ComputerName 10.0.0.100-Port 10051### 3.4 批量部署PowerShell Remoting 一次覆盖多台 手动逐台安装在管 50 台以上 Windows Server 的场景里完全不现实。用 PowerShell Remoting 可以把 Agent 部署变成流水线作业。 **前提**目标机器已启用 WinRM企业内网域环境默认开启非域环境参考下方一键开启命令。 powershell # 在目标机器上一键开启 WinRM域外环境用管理员身份运行 Enable-PSRemoting -Force Set-Item WSMan:\localhost\Client\TrustedHosts -Value 10.0.0.* -Force# deploy_zabbix_agent.ps1# 批量部署 Zabbix Agent 2 到多台 Windows Server# 在管理机上以管理员身份运行$ZabbixServer10.0.0.100# 你的 Zabbix Server IP$AgentMsiUrlhttps://cdn.zabbix.com/zabbix/binaries/stable/6.4/zabbix_agent2-6.4.0-windows-amd64-openssl.msi$LocalMsiPathC:\Temp\zabbix_agent2.msi$CredentialGet-Credential# 输入有管理员权限的账号# 目标主机列表从 CSV 读取CSV格式: Hostname,IP$TargetsImport-CsvC:\Temp\windows_servers.csv# CSV 示例# Hostname,IP# WIN-STORE-001,192.168.1.101# WIN-STORE-002,192.168.1.102foreach($targetin$Targets){$hostname$target.Hostname$ip$target.IPWrite-Host[$hostname] 开始部署...-ForegroundColor Cyantry{Invoke-Command-ComputerName$ip-Credential$Credential-ScriptBlock{param($ZabbixServer,$AgentMsiUrl,$LocalMsiPath,$HostnameParm)# 1. 下载 MSI如果内网有文件服务器改成 UNC 路径更快if(-not(Test-Path$LocalMsiPath)){New-Item-ItemType Directory-Path(Split-Path$LocalMsiPath)-Force|Out-NullInvoke-WebRequest-Uri$AgentMsiUrl-OutFile$LocalMsiPath-UseBasicParsing}# 2. 静默安装$args/i$LocalMsiPath/qn SERVER$ZabbixServerSERVERACTIVE$ZabbixServerHOSTNAME$HostnameParmStart-Processmsiexec.exe-ArgumentList$args-Wait# 3. 开防火墙New-NetFirewallRule-DisplayNameZabbix Agent-Direction Inbound -Protocol TCP-LocalPort 10050-Action Allow-ErrorAction SilentlyContinue# 4. 确认服务状态$svcGet-ServiceZabbix Agent 2-ErrorAction SilentlyContinueif($svc-and$svc.Status-eqRunning){Write-OutputOK}else{Write-OutputFAILED}}-ArgumentList$ZabbixServer,$AgentMsiUrl,$LocalMsiPath,$hostnameWrite-Host[$hostname] 部署完成-ForegroundColor Green}catch{Write-Host[$hostname] 部署失败:$_-ForegroundColor Red}}选 PowerShell Remoting 而不是 SCCM 或 GPO是因为我们的实际场景是几十台门店服务器分散在不同网段、没有统一域控。SCCM 对这种零散部署太重了GPO 需要域环境。PowerShell Remoting 的代价只是一个Enable-PSRemoting对于没有域的门店/工厂网络是最务实的方案。部署完成后在 Zabbix Server 侧批量注册主机。手工在 Web 前端逐个添加主机同样不现实——好在 Zabbix 提供了完整的 JSON-RPC API一个 bash 脚本就能批量搞定。关键参数说明groupid和templateid需要根据你自己 Zabbix 环境的实际 ID 替换在 Zabbix 前端 URL 中可以看到端口 10050 是 Agent 被动模式的默认监听端口# 用 Zabbix API 批量注册Linux Bash 示例ZABBIX_URLhttp://10.0.0.100/zabbix/api_jsonrpc.phpAUTH_TOKEN$(curl-s-XPOST $ZABBIX_URL\-HContent-Type: application/json\-d{jsonrpc:2.0,method:user.login,params:{user:Admin,password:zabbix},id:1}\|python3-cimport sys,json;print(json.load(sys.stdin)[result]))# 读取 CSV 批量创建主机whileIFS,read-rhostnameip;docurl-s-XPOST$ZABBIX_URL\-HContent-Type: application/json\-d{\jsonrpc\:\2.0\,\method\:\host.create\,\params\:{\host\:\$hostname\,\interfaces\:[{\type\:1,\main\:1,\useip\:1,\ip\:\$ip\,\dns\:\\,\port\:\10050\}],\groups\:[{\groupid\:\10\}],\templates\:[{\templateid\:\10081\}]},\auth\:\$AUTH_TOKEN\,\id\:2}done(tail-n2 windows_servers.csv)4. 系统层监控CPU / 内存 / 磁盘 / 网络在 Zabbix 前端添加主机后应用Windows by Zabbix Agent 2模板Zabbix 内置自动覆盖以下系统层指标指标Zabbix Key说明CPU 使用率system.cpu.util[,idle]建议告警阈值85% 持续 5 分钟内存使用率vm.memory.size[pused]建议告警阈值88% 持续 5 分钟磁盘剩余空间vfs.fs.size[C:,pfree]建议告警阈值剩余 15%磁盘 I/O 等待perf_counter[\PhysicalDisk(_Total)\% Disk Time]持续高于 80% 说明 I/O 瓶颈网络发送速率net.if.out[以太网,bytes]监控各网卡注意接口名称关键注意Windows 磁盘剩余告警要对每个驱动器单独配置。C: 系统盘和数据盘D:、E:有不同的告警阈值。这几个系统层指标看起来和 Linux 监控一样但 Windows 上有两个容易被忽视的差别一是 Windows 的磁盘 I/O 比 Linux 更容易成为瓶颈——NTFS 文件系统在大量小文件场景下的性能退化比 ext4/xfs 更明显二是 Windows 的内存管理机制不同Available MBytes比% Committed Bytes更能反映实际可用内存因为 Windows 会积极使用 SuperFetch 预加载只看空闲内存容易误判。4.1 系统层指标告警阈值速查表指标Zabbix KeyWARNINGCRITICAL第一步排查CPU 使用率system.cpu.util[,idle]75%/5min90%/5minGet-Process | Sort CPU -Desc | Select -First 10内存使用率vm.memory.size[pused]80%/5min92%/5minGet-Process | Sort WorkingSet -Desc | Select -First 10C: 磁盘剩余vfs.fs.size[C:,pfree]15%5%Get-ChildItem C:\ -Recurse -ErrorAction SilentlyContinue | Sort Length -Desc | Select -First 20数据盘剩余vfs.fs.size[D:,pfree]20%8%检查日志/备份目录磁盘 I/O 等待perf_counter[\PhysicalDisk(_Total)\% Disk Time]70%90%找高 I/O 进程Get-Counter \Process(*)\IO Data Bytes/sec网络带宽占用net.if.out[以太网,bytes]70% 链路90% 链路Get-NetAdapterStatistics系统运行时长system.uptime—30min非计划重启查事件日志 6008/1074这张表可以直接打印贴在值班室——告警触发后第一步该查什么一列之内就能确定。4.2 多驱动器磁盘告警注意事项Windows Server 经常有多个驱动器C: 系统盘、D: 数据盘、E: 备份盘Zabbix 内置模板默认只监控 C: 盘。在部署时需要在 Windows 上确认实际有哪些驱动器然后为每个驱动器单独配置告警。快速确认驱动器列表的命令Get-PSDrive -PSProvider FileSystem | Select Name, Used, Free。注意区分系统盘和数据盘的告警阈值C: 盘建议 WARNING 15%、CRITICAL 5%系统盘满了会导致服务不可用数据盘可以放宽到 WARNING 20%、CRITICAL 8%但如果数据盘存的是数据库文件或日志建议和 C: 盘用同样严格的阈值——我们在一个制造业客户那里见过 D: 盘剩余 12% 时 SQL Server 已经开始报空间不足的 Warning 日志了。5. 服务层监控Windows 服务状态告警Windows 服务状态监控是 Linux 监控工程师最容易遗漏的部分。5.1 批量监控所有自动启动服务Zabbix 内置 Keyservice.info[服务名,state]可以采集单个服务状态但手动配置每个服务效率太低。推荐用 LLD低级发现自动发现在 Zabbix 中创建发现规则# Zabbix 发现规则配置在前端操作Discovery Rule Name:Windows Services DiscoveryKey:service.discoveryUpdate interval:1h# 过滤条件只监控启动类型为自动的服务Filter:-Macro:{#SERVICE.STARTUPNAME}Regex:^Auto$发现后自动为每个服务创建监控项和告警触发器。这个 LLD 方案的关键设计决策是只监控启动类型为Auto的服务。为什么不监控所有服务因为 Windows Server 上有大量手动触发器启动的服务平时是停止状态比如 Windows Update、各种一次性任务服务如果全部纳入监控每天会产生大量服务已停止的噪音告警。我们的经验是Auto类型覆盖了所有应该一直运行的服务漏掉的风险极低。5.2 手动监控关键业务服务对 ERP、收银、SQL Server 等关键服务额外创建高优先级触发器# 在 Zabbix 前端创建 ItemItem name:SQL Server Service StatusKey:service.info[MSSQLSERVER,state]Type:Zabbix Agent (active)Value type:Numeric (unsigned)Update interval:60s# 触发器Trigger name:SQL Server Service Down on{HOST.NAME}Expression:last(/主机名/service.info[MSSQLSERVER,state])0Severity:High用 PowerShell 验证服务状态采集# 在 Zabbix Server 侧用 zabbix_get 测试# zabbix_get -s 10.x.x.x -k service.info[MSSQLSERVER,state]# 返回 0 运行中1 已停止2 暂停7 未安装# 本地快速测试在 Windows 上执行Get-ServiceMSSQLSERVER|SelectStatus5.3 Windows 服务状态值速查返回值含义0Running运行中1Stopped已停止2Start Pending3Stop Pending4Continue Pending5Pause Pending6Paused已暂停7Not Installed服务不存在6. 进程层监控关键进程存活与资源占用服务可以运行中但进程已经假死——这个问题在 Windows 上比 Linux 更常见。Windows 服务控制管理器SCM只检测进程是否存在不检测进程是否在正常工作。我们遇到过 SQL Server 服务状态显示 “Running”但实际进程已经死锁CPU 100% 卡死所有查询超时。这就是进程层监控存在的原因——它绕过 SCM直接检查进程本身。6.1 进程存活监控# Item 配置Key:proc.num[sqlservr.exe]# 返回运行中该名称进程的数量# 触发器SQL Server 进程消失Expression:last(/主机名/proc.num[sqlservr.exe])0Severity:Disaster6.2 进程 CPU / 内存占用# 进程 CPU 占用百分比Key:proc.cpu.util[sqlservr.exe]# 进程内存占用字节Key:proc.mem[sqlservr.exe,rss]# 触发器SQL Server 进程内存超过 8GBExpression:last(/主机名/proc.mem[sqlservr.exe,rss])8589934592Severity:Warning6.3 用 PowerShell 自定义进程监控脚本# C:\ZabbixScripts\check_process_cpu.ps1param([string]$ProcessName)$procGet-Process-Name$ProcessName-ErrorAction SilentlyContinueif(-not$proc){Write-Output0exit}# 获取进程 CPU 使用率需要采样间隔计算$cpu(Get-Counter\Process($ProcessName)\% Processor Time-SampleInterval 2-MaxSamples 1).CounterSamples.CookedValue[Math]::Round($cpu/(Get-WmiObjectWin32_ComputerSystem).NumberOfLogicalProcessors,2)在 Agent 配置文件中注册UserParameterproc.cpu.custom[*],powershell -NoProfile -ExecutionPolicy Bypass -File C:\ZabbixScripts\check_process_cpu.ps1 -ProcessName $17. Windows 性能计数器采集定制指标Windows 性能计数器Performance Counter是最完整的指标来源几乎所有 Windows 组件都暴露了 PerfCounter。7.1 常用 PerfCounter Key以下是我们生产环境中实际在用的 PerfCounter 指标每个都附上为什么要监控# ASP.NET 请求队列长度IIS 场景# 队列积压意味着 IIS 处理能力跟不上请求量是应用池回收/死锁的第一信号perf_counter[\ASP.NET\Requests Queued]# IIS 每秒请求数# 建立基线之后突降上游出问题突增可能在被刷perf_counter[\Web Service(_Total)\Get Requests/sec]# SQL Server 每秒事务数# 监控业务量的间接指标突降可能意味着数据库阻塞perf_counter[\SQLServer:Databases(_Total)\Transactions/sec]# SQL Server 缓存命中率越接近100越好低于90需关注# 低于90意味着 SQL Server 经常需要从磁盘读数据页通常是因为内存不够perf_counter[\SQLServer:Buffer Manager\Buffer cache hit ratio]# 磁盘平均读取延迟毫秒# 超过20ms说明存储层有性能问题可能影响所有依赖磁盘的服务perf_counter[\PhysicalDisk(0 C:)\Avg. Disk sec/Read,1000]这些 PerfCounter 路径都是英文版 Windows的格式。如果你在中文版 Windows 上使用记得先用 7.3 节的脚本做路径验证。7.2 如何找到可用的 PerfCounter 路径不同 Windows 版本和已安装组件会影响可用的 PerfCounter 列表。在添加自定义监控项之前先确认目标计数器是否存在# 查看 SQL Server 相关的所有 PerfCounter 指标(Get-Counter-ListSetSQLServer:Buffer Manager).Paths# 实时采样测试——确认路径有效且能返回数值Get-Counter\SQLServer:Buffer Manager\Buffer cache hit ratio如果Get-Counter -ListSet找不到预期的类别说明对应的 Windows 组件没有安装或版本不兼容。比如SQLServer:Buffer Manager只存在于安装了 SQL Server 的机器上Web Service系列只存在于启用了 IIS 的机器上。不要在模板里为所有主机配置这些指标——用主机群组或宏来控制哪些主机启用哪些 PerfCounter 监控项。### 7.3 批量验证 PerfCounter 在中文/英文 Windows 上是否可用 powershell # check_perf_counters.ps1 # 批量检查一组 PerfCounter 路径在当前 Windows 上是否能正常采集 # 在部署 Zabbix 模板前跑这个脚本提前发现 Not Supported 问题 $CountersToCheck ( \Processor(_Total)\% Processor Time, \Memory\Available MBytes, \PhysicalDisk(_Total)\% Disk Time, \PhysicalDisk(_Total)\Avg. Disk sec/Read, \SQLServer:Buffer Manager\Buffer cache hit ratio, \SQLServer:Databases(_Total)\Transactions/sec, \Web Service(_Total)\Get Requests/sec, \ASP.NET\Requests Queued ) Write-Host 检查 PerfCounter 可用性... -ForegroundColor Cyan $results () foreach ($counter in $CountersToCheck) { try { $val (Get-Counter $counter -SampleInterval 1 -MaxSamples 1 -ErrorAction Stop).CounterSamples.CookedValue $results [PSCustomObject]{ Counter$counter; StatusOK; Value[Math]::Round($val,2) } } catch { # 中文版 Windows 路径失败时尝试用 typeperf 找本地化名称 $localName typeperf -q 2$null | Where-Object { $_ -match ($counter -replace .*\\,) } | Select-Object -First 1 $results [PSCustomObject]{ Counter$counter; StatusFAIL; Valueif($localName){可能本地化为: $localName}else{未找到} } } } $results | Format-Table -AutoSize $failCount ($results | Where-Object {$_.Status -eq FAIL}).Count Write-Host 总计: $($results.Count) 个通过: $($results.Count - $failCount) 个失败: $failCount 个 -ForegroundColor $(if($failCount -gt 0){Red}else{Green})这个脚本不是凭空想出来的。有一次我们给一家制造企业部署 30 台车间 Windows Server 的 Zabbix 监控模板批量应用之后有 7 台中文版 Windows 的 PerfCounter 指标全部显示 Not Supported。在 Zabbix 前端排查 Not Supported 的原因很痛苦——你不知道是 Agent 没装好、网络不通、还是路径问题。挨台远程上去用typeperf -q逐个确认3 个人花了整整一个下午才把所有路径纠正过来。那之后我们就把这个检查做成了部署前置脚本——接新机器先跑这个5 秒出结果哪台有问题、哪些路径要本地化一目了然。其实所有看起来很简单的脚本背后都是一个不想再重复的坑。8. 告警规则与分级配置8.1 告警分级参考表级别触发条件示例Disaster核心服务/进程消失SQL Server 进程消失、AD 认证服务停止High磁盘剩余 5%、内存 95%系统盘快满、内存即将耗尽AverageCPU 85%/5min、内存 88%/5min性能指标持续高位Warning磁盘剩余 15%、IIS 请求队列积压容量预警、性能下降Info系统重启、服务重启恢复非预期重启需要关注原因8.2 系统重启检测# Item系统启动时间Key:system.uptimeValue type:Numeric (float)Units:uptime# 触发器检测非计划重启如果 uptime 30 分钟且不在维护期Trigger name:Unexpected reboot on{HOST.NAME}Expression:last(/主机名/system.uptime)1800Severity:Average9. 6 个生产踩坑以下每个坑都是我们在连锁门店、制造业场景中实际踩过的。问题本身可能看起来不大但每个坑的排查过程都至少耗费了半天——分享出来的目的就是让你跳过这些排查。坑1Agent 配置的 Hostname 与 Zabbix 前端主机名不匹配这是最高频的问题。Agent 配置的HostnameWIN-STORE-001但 Zabbix 前端添加主机时写的是win-store-001小写导致主动检测数据无法上报被动检测正常。结果部分指标有值部分指标显示 Not Supported。排查Zabbix Server 日志/var/log/zabbix/zabbix_server.log里搜Hostname。主机名区分大小写。这个坑在批量部署时最容易出现——PowerShell 脚本里用$env:COMPUTERNAME拿到的是全大写而有人手动在前端添加主机时习惯用首字母大写。50台机器部署完发现30台主动监控不工作就是这个原因。坑2磁盘驱动器名称中文乱码部分 Windows Server 的磁盘分区名称包含中文如本地磁盘用 LLD 自动发现时宏{#FSNAME}中的中文在 Zabbix Item Key 里会乱码导致监控项创建失败。解决在 LLD 过滤器里限制只监控字母冒号格式的路径如C:、D:排除中文路径Filter: {#FSNAME} matches ^[A-Za-z]:$坑3性能计数器路径在不同语言版本 Windows 上名称不同中文版 Windows 和英文版 Windows 的 PerfCounter 路径不一样。英文版\Processor(_Total)\% Processor Time中文版可能是\处理器(_Total)\% 处理器时间。Zabbix 内置的 Windows 模板使用的是英文路径在中文 Windows 上会返回 Not Supported。解决用typeperf命令在目标 Windows 上确认实际路径typeperf-qProcessor|Where-Object{$_-matchProcessor Time}然后在 Zabbix Item 里使用本地实际路径或切换使用system.cpu.util等 Agent 内置 Key不依赖 PerfCounter。这个坑我们在第7.3节讲了具体踩坑经历——7台中文版 Windows 全返回 Not Supported排查了整整一个下午。教训就是模板部署之前先跑 check_perf_counters.ps1。坑4Zabbix Agent 在 Windows Server 2022 上无法启动现象安装成功但服务启动失败事件日志里有 “The Zabbix Agent service terminated with service-specific error Incorrect function.”原因通常是 OpenSSL 版本不兼容或下载的 Agent 版本不对分 x86 和 x64以及 OpenSSL / GnuTLS 两个加密库版本。解决从 Zabbix 官方下载页面选择 Windows Server 2022 对应的openssl版本且确认 x64大多数现代 Windows Server 都是 x64。坑5监控 IIS 应用池但实例名包含空格IIS 应用池名称如 “Default App Pool” 含有空格放进 PerfCounter Key 时会报错。解决使用下划线替代空格或用引号包裹perf_counter_en[\Process(w3wp#0)\% Processor Time]用Get-Counter先测试确认实际实例名。坑6Windows 防火墙阻断 Zabbix 主动监控被动模式Server 轮询 Agent可以正常工作但主动模式Agent 向 Server 汇报数据缺失。原因Windows 防火墙的出站规则默认允许所有出站但部分安全加固过的环境限制了出站导致 Agent 无法主动连接 Server 的 10051 端口。解决检查出站规则放行 Zabbix Server IP 的 10051 端口出站连接。这个坑比较隐蔽因为被动监控一切正常很容易让人觉得Agent 配好了。排查技巧在 Windows 上用Test-NetConnection -ComputerName 你的ZabbixServerIP -Port 10051验证出站连通性不通就查防火墙出站规则。10. 与运维平台结合实事求是的说这套方案在 50 台以内的 Windows Server 规模下跑得很稳但当机器数超过 100 台、而且中英文 Windows 版本混布时维护成本会非线性增长新入一台中文版要单独验证 PerfCounter 路径、Zabbix Agent 版本升级要逐台跟进、LLD 规则对不同 Windows Server 版本偶尔不兼容需要单独处理。我们在维护了大概半年之后把这套 Windows Server 监控整体迁移到了冠服云EMS平台的 ITOM 模块主要解决了两件事一是 Windows Server 的纳管变成平台内置能力不再需要单独维护一套 Agent 集群和模板体系二是门店侧有新设备上线时注册一次就能自动下发监控策略不需要走装 Agent → 改配置 → 前端加主机 → 验指标的完整流程。当然如果你已经在用 Zabbix 且规模不大本文的方案完全够用。只是当 Windows 服务器数量开始往 3 位数走的时候值得考虑是否需要把监控能力从手工搭建升级为平台内置。11. 部署 Checklist安装阶段确认 Zabbix Agent 版本与 Server 版本匹配主版本号一致确认下载 x64 版本大多数 Windows Server 是 x64安装后确认Zabbix Agent 2服务为自动启动状态防火墙放行入站 TCP 10050被动模式/ 出站 TCP 10051主动模式配置阶段Hostname参数与 Zabbix 前端主机名大小写完全一致Server和ServerActive填写正确的 Zabbix Server/Proxy IP在 Zabbix 前端添加主机应用Windows by Zabbix Agent 2模板验证等待 5 分钟后主机状态变绿指标有最新数据监控覆盖阶段系统层CPU / 内存 / 磁盘 / 网络 指标均有值不是 Not Supported确认磁盘监控覆盖所有驱动器C: / D: / E: 等关键服务监控SQL Server / IIS / AD 等已单独创建高优先级触发器关键进程存活监控已配置所有 PerfCounter Key 在目标 Windows 语言版本上已验证不报 Not Supported告警阶段Disaster 级别告警测试停止 SQL Server 服务确认告警到达系统重启检测触发器已配置各驱动器磁盘预警阈值已按实际情况设置系统盘和数据盘阈值不同运营阶段告警已对接工单系统或即时通知渠道有明确负责人每季度检查 Not Supported 指标列表修复失效采集新增 Windows 服务器时有标准化注册流程不靠人记觉得有用的话点个赞/收藏Windows Server 监控这套配置跑通之后新机器接入就是套模板的事比每次现查文档快多了。相关内链CSDN-47连锁门店Zabbix架构 https://blog.csdn.net/weixin_70758133/article/details/161445385?spm1011.2415.3001.5331CSDN-04告警降噪https://blog.csdn.net/weixin_70758133/article/details/158572672?spm1011.2415.3001.5331参考资料Zabbix 官方 Windows Agent 安装文档Zabbix API 官方参考往期相关文章连锁门店 Zabbix Proxy 分布式监控架构 多源告警统一接入方案站内链接发布时替换为实际文章 URLWindows Performance Counters 官方文档
