干运维这些年服务器监控这事我从最早的脚本巡检一路折腾到集中式管理平台中间踩过的坑能写满一个笔记本。今天要分享的是我刚落地的一套 V5.0 集中式监控方案。这个版本的核心思路就一句话所有采集动作都收敛到监控服务器这一台机器上被监控的 Windows 业务机器除了开放必要的远程管理端口之外不再安装任何额外组件。整套方案重点解决的是两类高频需求一是服务器监控数据的统一汇聚二是 Zabbix 监控 Windows 服务器 TCP 连接数这类细粒度指标的落地。这套方案适合谁适合那些被 agent 版本碎片化折腾到崩溃的运维同学适合生产环境不允许随便装第三方软件但又必须有监控数据的团队也适合刚接手监控平台、想把采集架构收敛干净的人。我会把这套 V5.0 的部署细节、exporter 进程的集中部署思路、TCP 连接数的完整采集链路全部拆开讲透包括我实际踩过的坑和排查过程你可以直接照着落地。1. 整体设计与架构思路拆解1.1 从“遍地装 Agent”到“集中采集”的演进逻辑早期做服务器监控最直接的办法就是每台 Windows 业务机器上装一个采集 agent让 agent 把指标推给监控服务端。这个方案在前几年没什么问题但规模上来了之后痛点会越来越明显。首先是版本碎片化。几十台甚至上百台 Windows 服务器agent 版本很难保持完全一致。今天这台机器升级了明天那台机器的 agent 进程不知被谁杀了后天又有安全扫描发现某台机器的 agent 存在漏洞需要升级。每次排查问题都要先确认各台机器上的 agent 版本光对齐版本这件事就能消耗大半天。其次是“业务机器上不让装东西”这个现实约束。很多生产环境的 Windows 服务器有严格的白名单机制尤其是数据库服务器、域控服务器、核心业务应用服务器申请安装第三方软件要走很长的审批流程。有些安全团队直接规定业务服务器上只允许运行业务相关进程监控采集一律不准落地。还有一层是安全审计层面的考量。业务机器上跑的外来进程越多被攻击面就越大。哪怕 agent 本身没有漏洞多一个进程就多一份被利用的风险。V5.0 的核心思路就是把这些采集组件全部搬到监控服务器上业务机器只开放标准管理协议端口这样一来业务机器干净了安全审计也好交代。1.2 V5.0 的整体架构与组件划分这套 V5.0 架构我拆成三个角色监控服务端跑 Zabbix Server 和数据库负责存储、告警、图表展示。采集端也就是热词里说的 exporter 进程部署在监控服务器上集中承担所有远程采集任务。它通过 SNMP、WinRM、数据库协议等去连接被监控的 Windows 机器把数据取回来。被监控端Windows 服务器只需要开启 WinRM 服务、SNMP 服务并在防火墙放通相应端口不需要安装任何 agent 或 exporter。用一张通俗的话来类比以前是每个店员手里都拿着一个计数器在店里数顾客现在的做法是店里只在大门口装了一个摄像头数据统一回到监控室分析。采集端就是那个摄像头监控服务端就是监控室。数据流向是这样的Zabbix Server 主动调取采集端上定义好的自定义键值采集端脚本收到请求后通过远程协议到 Windows 机器上抓取指标拿到结果返回给 Zabbix Server。组件清单大概是组件数量用途Zabbix Server1监控核心负责数据存储、告警、展示MySQL/PostgreSQL1存储监控数据建议同机部署或独立服务器exporter 采集进程1可扩展集中部署在监控服务器远程采集 Windows 指标Windows 业务机器N仅开启 SNMP/WinRM 服务不装任何采集组件1.3 为什么选择“采集端集中”而不是“每机一个 exporter”也有人问我Prometheus 生态里 exporter 不都是部署在被监控机器上的吗为什么这里要反过来原因有三点。第一Prometheus 生态的标准做法确实是 exporter 跟随目标机部署但那是基于目标机器可以自由部署组件的假设。在 Windows 生产环境这个假设经常不成立。第二exporter 部署在监控服务器上相当于把采集工具的升级、维护、排障都收敛到一个点。我只需要维护监控服务器这一台机器上的脚本和依赖库而不是去几十台 Windows 机器上分别维护。第三从监控数据的一致性来看所有采集都从一个点位发出网络路径相对固定排查问题的时候链路更短、变量更少。当然这种做法也有代价。监控服务器会成为采集的单点如果它挂了整套监控就没了。所以我在生产环境做了主备两个监控节点这个后面在维护部分会细讲。2. 监控服务器端部署全流程2.1 Zabbix Server 安装与基础调优Zabbix Server 的安装本身不复杂我这边用的是 CentOS 7.9 Zabbix 6.0 LTS PostgreSQL 14 的组合。6.0 是长期支持版本用起来比较放心。安装步骤简要记录一下# 安装 Zabbix 仓库 rpm -Uvh https://repo.zabbix.com/zabbix/6.0/rhel/7/x86_64/zabbix-release-6.0-4.el7.noarch.rpm # 安装服务端组件 yum install zabbix-server-pgsql zabbix-web-pgsql zabbix-nginx-conf zabbix-sql-scripts zabbix-selinux-policy zabbix-agent2 # 初始化数据库 zcat /usr/share/doc/zabbix-sql-scripts/postgresql/create.sql.gz | psql -U zabbix -d zabbix装完之后有几处调优是必须做的。一个在/etc/zabbix/zabbix_server.conf重点调这几个参数StartPollers8 StartPollersUnreachable2 CacheSize256M HistoryCacheSize128M TrendCacheSize64M ValueCacheSize64M Timeout10StartPollers 默认只有 3如果管理的 Windows 机器超过 30 台明显不够用。监控项一多polling 队列会堆积告警延迟就到分钟级了。我这边直接拉到 8实测下来 polling 队列基本是空的。Timeout 默认 4 秒对于远程 WMI 采集来说太短。你想想监控服务器发起一个 WinRM 请求Windows 那边要认证、要执行 PowerShell 脚本、要把结果封装回来4 秒经常不够。我改成 10 秒采集稳定性明显提升。2.2 集中部署 exporter 进程目录结构与运行方式这是 V5.0 的核心。exporter 进程本质上是一组 Python 脚本集中放在监控服务器上通过 systemd 管理成常驻服务。它的职责是接收 Zabbix Server 的采集请求代为执行对 Windows 机器的远程查询。我的目录结构是/opt/windows_exporter/ ├── exporter_server.py # 主进程HTTP服务监听 9271 端口 ├── collectors/ │ ├── tcp_connections.py # TCP连接数采集器 │ ├── cpu_memory.py # CPU内存采集器 │ ├── disk_io.py # 磁盘IO采集器 │ └── system_uptime.py # 系统运行时间采集器 ├── config/ │ ├── servers.ini # 被监控Windows服务器清单 │ └── credentials.ini # 远程连接凭据加密存储 ├── requirements.txt └── run.sh主进程是一个 Flask 应用暴露一个 HTTP 接口Zabbix Server 通过web.page.get或web.page.perf之类的键值来获取数据。实际上我更推荐的方式是让 exporter 主动把数据推给 Zabbix Server也就是用zabbix_sender做主动上报这样 Zabbix Server 那边不用频繁发起 HTTP 调用采集频率可以做得更高。exporter 进程的运行方式用 systemd 管理[Unit] DescriptionWindows Exporter Collector Afternetwork.target [Service] ExecStart/usr/bin/python3 /opt/windows_exporter/exporter_server.py WorkingDirectory/opt/windows_exporter Restartalways RestartSec10 Userzabbix [Install] WantedBymulti-user.target这里有一个细节值得注意进程用户我用的是zabbix而不是root。因为 exporter 需要访问 Zabbix 的配置文件、调用zabbix_sender二进制用 zabbix 用户最合适。同时它也避免了用 root 跑 Web 服务的风险。依赖库方面我的requirements.txt很简单flask2.2.5 pywinrm0.4.3 pysnmp4.4.12 cryptography41.0.7pywinrm是连接 Windows WinRM 的库pysnmp用来做 SNMP 采集。注意cryptography的版本旧版本在 Python 3.11 上会有兼容性问题。2.3 exporter 如何安全保存远程凭据这是容易被忽视但很重要的一点。exporter 要远程连到 Windows 机器上执行 WMI 查询就必须有凭据。我开始图省事直接写在 Python 脚本里后来做安全评审被打了回来。现在我用的是加密存储方案凭据文件用cryptography库的 Fernet 对称加密密钥单独放在一个只有 zabbix 用户可读的文件里。系统启动时 exporter 进程读取密钥解密凭据文件加载到内存里。密钥文件和凭据文件分离即使源码泄露没有密钥也解不出凭据。2.4 Windows 被监控端的准备工作被监控的 Windows 机器需要开启 WinRM 和 SNMP 服务。WinRM 主要用于 WMI 类的指标采集比如 TCP 连接状态分布、进程列表SNMP 用于快速获取 tcpCurrEstab 这类标准 MIB 数据。开启 WinRM 在 Windows 上用管理员 PowerShell 执行Enable-PSRemoting -Force winrm set winrm/config/winrs {MaxMemoryPerShellMB1024} winrm set winrm/config {MaxTimeoutms60000} Set-Item WSMan:\localhost\Client\TrustedHosts -Value 监控服务器IP -ForceTrustedHosts一定要配不配的话监控服务器发起的 WinRM 请求会被拒绝。如果能走 Kerberos 认证最好但多数内网环境没有域用 TrustedHosts 基本认证是最省事的方案。SNMP 服务的开启路径是“服务器管理器 - 添加角色和功能 - 勾选 SNMP 服务”。装好后需要在“服务”里找到 SNMP Service配置“安全”选项卡填上团体名Community比如monitor_ro并限制只接受来自监控服务器 IP 的请求。防火墙要放通的端口协议端口用途TCP5985WinRM HTTPUDP/TCP161SNMPTCP135WMI DCOM可选用WinRM可不开注意如果用 WinRM 执行 WMI 查询不一定要开 135 端口因为 WinRM 走的是 5985。但如果你打算直接开 WMI 的远程调用就必须放通 135 和动态端口范围那个范围很麻烦我建议全部走 WinRM别直接用 DCOM。3. Windows TCP 连接数监控的完整实现3.1 TCP 连接数监拉的需求与常见方式TCP 连接数是 Windows 服务器运维里非常关键的指标。连接数异常暴涨往往意味着程序出现了连接泄漏、被扫描攻击或者某种业务异常。传统方式是在 Windows 本机用netstat -an | find /c ESTABLISHED来数但在集中式监控架构下我们不能到每台机器上去敲命令必须通过远程协议来采集。常用的远程采集方式有四个方式原理优点缺点Zabbix Agent在Windows装agent执行自定义脚本采集数据精确细腻业务机器要装组件违背V5.0原则SNMP直接查询 tcpCurrEstab OID实现最简单标准协议只能拿总连接数拿不到状态分布WinRM WMI远程执行PowerShell查询性能计数器能拿到各状态的连接数分布依赖WinRM配置速度稍慢WMI 性能计数器直接拉取通过 DCOM 远程查询不依赖WinRM防火墙端口麻烦架构不干净在这套 V5.0 方案里我 SNMP 和 WinRM 两条路都做了。SNMP 作为快速通道用于实时获取总连接数WinRM 作为详细通道用于获取 ESTABLISHED、TIME_WAIT、CLOSE_WAIT 等各状态的分布值。两条路都由监控服务器上的 exporter 统一发起。3.2 通过 SNMP 采集 tcpCurrEstabTCP 连接总数这个指标SNMP 里有一个现成的对象就是tcpCurrEstabOID 是1.3.6.1.2.1.6.9.0。它直接返回当前处于 ESTABLISHED 状态的 TCP 连接数量。exporter 里用 pysnmp 拉取from pysnmp.hlapi import * def get_tcp_cur_estab(ip, community): iterator getCmd( SnmpEngine(), CommunityData(community, mpModel1), UdpTransportTarget((ip, 161), timeout5, retries1), ContextData(), ObjectType(ObjectIdentity(1.3.6.1.2.1.6.9.0)) ) errorIndication, errorStatus, errorIndex, varBinds next(iterator) if errorIndication or errorStatus: return None for varBind in varBinds: return int(varBind[1])这里是mpModel1对应 SNMPv2c。如果 Windows 上配了 SNMPv3就需要换成UsmUserData。多数内网环境为了省事还是 v2c但我建议生产环境用 v3安全性高不少。拿到指标后exporter 把这个值在内存缓存起来Zabbix Server 通过自定义键值读取时直接返回缓存避免每次都去远程 SNMP 走一趟。SNMP 虽然有 timeout 机制但网络抖动的情况还是会有缓存一分钟能有效降低失败率。3.3 通过 WinRM 采集 TCP 连接状态分布要拿到 TIME_WAIT、CLOSE_WAIT 这种状态分布SNMP 是做不到的必须用 WinRM 执行 PowerShell 脚本。核心是利用 Windows 自带的性能计数器TCPv4/Connection Established只能拿总数要看状态分布得用Get-NetTCPConnection。在被监控机器上执行这条命令Get-NetTCPConnection | Group-Object State | Select-Object Name, Count返回结果会是一个类似这样格式的文本Name Count ---- ----- Established 139 TimeWait 205 CloseWait 7 Listen 12 SynSent 0exporter 通过 pywinrm 远程执行这条命令解析返回文本import winrm def get_tcp_state_distribution(ip, username, password): session winrm.Session(ip, auth(username, password), transportbasic) ps_script Get-NetTCPConnection | Group-Object State | Select-Object Name, Count result session.run_ps(ps_script) if result.status_code ! 0: raise Exception(result.std_err) # 解析输出返回字典 output result.std_out.decode(utf-8) lines [line.strip() for line in output.strip().splitlines() if line.strip()] dist {} # 跳过表头 for i, line in enumerate(lines): if line.startswith(----): continue parts line.split() if len(parts) 2 and parts[0] not in (Name, Count): try: dist[parts[0]] int(parts[1]) except ValueError: pass return dist这段代码是原理解析用的生产环境里我做了更严格的输出格式化处理。一种更稳的做法是让 PowerShell 输出 JSONGet-NetTCPConnection | Group-Object State | Select-Object Name, Count | ConvertTo-Json -Compress这样 Python 端直接json.loads解析不会有文本对齐问题。强烈建议用这种方式因为 PowerShell 表格输出在不同版本 Windows 上格式会有细微差异解析文本很容易翻车。3.4 exporter 缓存层与 zabbix_sender 主动上报exporter 采集到数据之后怎么进入 Zabbix 有两种路径。我两个都搭了最后选择的是主动上报方式。被动方式最简单Zabbix Server 上定义UserParameter让 Zabbix Server 去调 exporter 的 HTTP 接口拿数据。这种方式部署快但 Zabbix Server 每个轮询周期都要发起 HTTP 请求CPU 占用略高而且采集频率受轮询频率限制。主动方式更高效exporter 内部维护一个定时任务每 30 秒采集一轮所有 Windows 机器的 TCP 连接指标然后调用zabbix_sender主动推送到 Zabbix Server。这样 Zabbix Server 不需要到 exporter 上拉取exporter 自己控制采集节奏还能把数据批量打包在一起网络开销小得多。主动上报的配置示例zabbix_sender -z 127.0.0.1 -p 10051 -s Windows-Server-01 \ -k windows.tcp.established -o 139-s参数必须和 Zabbix 前端里配置的“主机名称”完全一致否则数据会因为找不到主机而丢弃。这是我刚开始经常搞错的地方。3.5 Zabbix 模板监控项、宏与触发器配置数据推上来之后要在 Zabbix 里把监控项、触发器配好。我建议建一个独立的模板“Windows TCP Monitor”然后把所有 Windows 服务器主机关联到这个模板上。监控项配置名称键值数据类型更新间隔TCP Established 连接数windows.tcp.established数值无符号30sTCP TimeWait 连接数windows.tcp.timewait数值无符号30sTCP CloseWait 连接数windows.tcp.closewait数值无符号30sTCP 总连接数windows.tcp.total数值无符号30s如果用的主动上报这些键值不需要在模板里配 UserParameter只需要在监控项里声明“类型为 Zabbix 采集端主动上报”即可。Zabbix 6.0 的监控项类型里有一个“Zabbix trapper”就是这个用途。触发器方面我配置了几个核心的告警规则总连接数超过 5000触发 warning总连接数超过 10000触发 highCLOSE_WAIT 大于 100触发 warning因为这很可能表示程序没有正确关闭连接TIME_WAIT 大于 2000触发 warning常见于高并发短连接场景严重等级和阈值需要根据业务情况来回调。比如那些业务本身就大量使用短连接的服务器TIME_WAIT 平时就有几千阈值设 2000 就太低了。最好先观察两周基线数据再定阈值。4. 常见问题与排查技巧实录4.1 WinRM 连接失败与 TrustedHosts 问题这个问题的现象是 exporter 日志里报winrm.exceptions.InvalidCredentialsError或者Unauthorized。排查时我从三层来确认。第一层确认防火墙。从监控服务器 telnet Windows 机器的 5985 端口不通就是防火墙没放通。第二层确认凭据。在监控服务器上用 pywinrm 写个单行测试脚本直接连一下看报错。第三层确认 TrustedHosts。Windows 机器上执行winrm get winrm/config/client查看 TrustedHosts 是否包含监控服务器的 IP。我遇到最隐蔽的情况是TrustedHosts 配置的是主机名但 exporter 里连的是 IP。WinRM 的认证机制会把 IP 和主机名当成不同的 host匹配不上就拒绝。解决方法是 TrustedHosts 里同时写上 IP 和主机名或者直接用通配符*内网环境可以考虑但安全上我给不出满分建议。4.2 SNMP 超时采集失败SNMP 超时的原因通常有三类网络不通、团体名不匹配、防火墙只放通了 UDP 没放通 TCP。注意 SNMP 默认走的 UDP 161但有些 Windows 机器配置了 SNMP 服务的同时也开了 TCP 161两头都要确认。另外Windows 的 SNMP 服务在收到请求后如果团体名不对会直接丢弃包不返回任何错误。所以超时的表象背后可能是团体名配置不一致。排查方法是先在监控服务器上手动跑一遍snmpwalksnmpwalk -v2c -c monitor_ro -t 5 -r 1 Windows_IP 1.3.6.1.2.1.6.9.0手动跑通了再排查 Zabbix 和 exporter 那一层。手动跑不通问题基本就在 Windows 端。4.3 PowerShell 脚本返回乱码或解析失败Get-NetTCPConnection在 Windows Server 2012 R2 上有一个已知问题需要先判断对象是否存在。因为该命令只在 Windows 8 / Server 2012 及以后版本才可用老系统上会直接报“无法将 Get-NetTCPConnection 识别为 cmdlet 的名称”。针对老系统的方案是用netstat加正则解析$states netstat -an | Select-String -Pattern TCP | ForEach-Object { if ($_ -match \s(LISTENING|ESTABLISHED|TIME_WAIT|CLOSE_WAIT|SYN_SENT)$) { $matches[1] } } $states | Group-Object | Select-Object Name, Count | ConvertTo-Json -Compress另外PowerShell 输出编码要注意。中文系统上ConvertTo-Json的输出如果包含中文Python 端可能解析出错。解决办法是统一用-Compress并且输出 ASCII 安全的内容或者把运行区域设置改成 UTF-8。4.4 zabbix_sender 数据不显示这个问题排查思路是这样的先确认 Zabbix Server 的 trapper 接收到数据没有。在 Zabbix Server 上执行tail -f /var/log/zabbix/zabbix_server.log | grep windows.tcp如果看到received data from localhost之类的记录说明数据到了问题在主机名或监控项配置。如果日志里没有记录说明 zabbix_sender 发出来的数据源就有问题。-s参数的主机名必须与 Zabbix 前端配置完全一致这是最常见的坑。还有一种是监控项的类型配错了如果监控项配成 Zabbix agent 类型trapper 数据就不会匹配上。4.5 连接数采集到了但图表是断线这个现象通常是间歇性的一会儿有数据一会儿没有。原因一般是采集脚本执行时间不稳定导致两次上报之间的间隔超过 Zabbix 对监控项定义的数据超时时间。解决办法是把 Zabbix 监控项的“允许数据丢失时间”从默认的 1 分钟放大到 3 分钟。另外一个原因是被监控 Windows 机器开启了节能策略没事就休眠网络适配器导致连接超时。把 Windows 电源计划改为“高性能”通常能解决。5. 批量管理、可视化与维护心得5.1 用配置驱动方式管理批量 Windows 主机exporter 的servers.ini采用配置驱动新增一台 Windows 机器只需要在这个文件里加一行[windows_server_202] ip 192.168.30.24 snmp_community monitor_ro winrm_user monitor_user然后执行systemctl restart windows-exporterexporter 会自动加载新配置。Zabbix 前端那边需要手动创建一台主机并关联模板或者用 Zabbix 的自动发现功能根据某种规则自动添加。我在生产环境用了一个更省事的组合Zabbix API Python 脚本把服务器清单自动同步到 Zabbix 主机配置里。新增服务器只需要维护一份 Excel 台账脚本自动生成主机、关联模板、设置宏。这套流程把新服务器接入监控的时间从半小时压缩到了五分钟以内。5.2 告警去重与值班体验优化连接数告警有个特点容易重复报。服务器连接数超标之后可能每 30 秒就触发一次值班人员手机能被震没电。我在 Zabbix 里三个手段来优化。第一触发器表达式加“持续 N 次才告警”的逻辑比如 3 次连续采集高于阈值才算故障。第二设置告警升级机制同一个触发器在 10 分钟内重复触发不重复发通知只把问题的严重级别升级一次。第三把所有连接数相关的触发器设置单独的告警媒介方便值班人员快速归类处理。5.3 Grafana 展示面板的核心指标布局数据进 Zabbix 之后可视化我推荐把 Grafana 面板直接对接 Zabbix 数据源。TCP 连接数的面板我一般做两行第一行是总览卡片显示当前所有 Windows 服务器的 TCP 总连接数、审计状态、最大值和最小值。第二行是分服务器的连接状态趋势图按 ESTABLISHED、TIME_WAIT、CLOSE_WAIT 三条线展示颜色分别用绿、黄、红一眼就能看出有没有异常状态堆积。CLOSE_WAIT 堆积是排查应用问题的利器。这个状态表示对端已经关闭连接但本端程序没有调用 close。一旦 CLOSE_WAIT 持续走高且不下降基本可以断定业务代码存在连接释放漏洞。这时候看趋势图上那条红线往上飘比你去翻业务日志快得多。5.4 后续扩展方向这套 V5.0 的采集架构搭好之后可以横向扩展很多指标。CPU、内存、磁盘 IO 都可以通过 WinRM 远程采集。Windows 服务状态监控也可以做用 PowerShell 的Get-Service。我目前已经加了 CPU、内存和磁盘空间监控采集方式是一样的。还有一个实用的扩展是 TCP 连接状态的时间序列异常检测。可以写一个简单的基线算法把每个小时连接数的平均值算出来当前值超过基线的三倍标准差就告警。这个对流量突增的感知特别快。做完整套方案之后我自己最大的体会有两点。第一集中式采集架构刚开始搭建的时候很多人会担心远程采集的性能问题但实测下来 WinRM 和 SNMP 的消耗对于一台监控服务器来说完全可接受。真正要花心思的是把脚本的异常处理做扎实比如超时重试、结果缓存、错误日志这些才是稳定性的关键。第二TCP 连接数这个指标表面看只是数字实际是应用健康状况的晴雨表。我靠这套方案不止一次提前发现了业务异常避免了事故扩大。监控不只是为了出图表最终目的是在业务出问题之前让运维能提前看到苗头。
干运维这些年服务器监控这事我从最早的脚本巡检一路折腾到集中式管理平台中间踩过的坑能写满一个笔记本。今天要分享的是我刚落地的一套 V5.0 集中式监控方案。这个版本的核心思路就一句话所有采集动作都收敛到监控服务器这一台机器上被监控的 Windows 业务机器除了开放必要的远程管理端口之外不再安装任何额外组件。整套方案重点解决的是两类高频需求一是服务器监控数据的统一汇聚二是 Zabbix 监控 Windows 服务器 TCP 连接数这类细粒度指标的落地。这套方案适合谁适合那些被 agent 版本碎片化折腾到崩溃的运维同学适合生产环境不允许随便装第三方软件但又必须有监控数据的团队也适合刚接手监控平台、想把采集架构收敛干净的人。我会把这套 V5.0 的部署细节、exporter 进程的集中部署思路、TCP 连接数的完整采集链路全部拆开讲透包括我实际踩过的坑和排查过程你可以直接照着落地。1. 整体设计与架构思路拆解1.1 从“遍地装 Agent”到“集中采集”的演进逻辑早期做服务器监控最直接的办法就是每台 Windows 业务机器上装一个采集 agent让 agent 把指标推给监控服务端。这个方案在前几年没什么问题但规模上来了之后痛点会越来越明显。首先是版本碎片化。几十台甚至上百台 Windows 服务器agent 版本很难保持完全一致。今天这台机器升级了明天那台机器的 agent 进程不知被谁杀了后天又有安全扫描发现某台机器的 agent 存在漏洞需要升级。每次排查问题都要先确认各台机器上的 agent 版本光对齐版本这件事就能消耗大半天。其次是“业务机器上不让装东西”这个现实约束。很多生产环境的 Windows 服务器有严格的白名单机制尤其是数据库服务器、域控服务器、核心业务应用服务器申请安装第三方软件要走很长的审批流程。有些安全团队直接规定业务服务器上只允许运行业务相关进程监控采集一律不准落地。还有一层是安全审计层面的考量。业务机器上跑的外来进程越多被攻击面就越大。哪怕 agent 本身没有漏洞多一个进程就多一份被利用的风险。V5.0 的核心思路就是把这些采集组件全部搬到监控服务器上业务机器只开放标准管理协议端口这样一来业务机器干净了安全审计也好交代。1.2 V5.0 的整体架构与组件划分这套 V5.0 架构我拆成三个角色监控服务端跑 Zabbix Server 和数据库负责存储、告警、图表展示。采集端也就是热词里说的 exporter 进程部署在监控服务器上集中承担所有远程采集任务。它通过 SNMP、WinRM、数据库协议等去连接被监控的 Windows 机器把数据取回来。被监控端Windows 服务器只需要开启 WinRM 服务、SNMP 服务并在防火墙放通相应端口不需要安装任何 agent 或 exporter。用一张通俗的话来类比以前是每个店员手里都拿着一个计数器在店里数顾客现在的做法是店里只在大门口装了一个摄像头数据统一回到监控室分析。采集端就是那个摄像头监控服务端就是监控室。数据流向是这样的Zabbix Server 主动调取采集端上定义好的自定义键值采集端脚本收到请求后通过远程协议到 Windows 机器上抓取指标拿到结果返回给 Zabbix Server。组件清单大概是组件数量用途Zabbix Server1监控核心负责数据存储、告警、展示MySQL/PostgreSQL1存储监控数据建议同机部署或独立服务器exporter 采集进程1可扩展集中部署在监控服务器远程采集 Windows 指标Windows 业务机器N仅开启 SNMP/WinRM 服务不装任何采集组件1.3 为什么选择“采集端集中”而不是“每机一个 exporter”也有人问我Prometheus 生态里 exporter 不都是部署在被监控机器上的吗为什么这里要反过来原因有三点。第一Prometheus 生态的标准做法确实是 exporter 跟随目标机部署但那是基于目标机器可以自由部署组件的假设。在 Windows 生产环境这个假设经常不成立。第二exporter 部署在监控服务器上相当于把采集工具的升级、维护、排障都收敛到一个点。我只需要维护监控服务器这一台机器上的脚本和依赖库而不是去几十台 Windows 机器上分别维护。第三从监控数据的一致性来看所有采集都从一个点位发出网络路径相对固定排查问题的时候链路更短、变量更少。当然这种做法也有代价。监控服务器会成为采集的单点如果它挂了整套监控就没了。所以我在生产环境做了主备两个监控节点这个后面在维护部分会细讲。2. 监控服务器端部署全流程2.1 Zabbix Server 安装与基础调优Zabbix Server 的安装本身不复杂我这边用的是 CentOS 7.9 Zabbix 6.0 LTS PostgreSQL 14 的组合。6.0 是长期支持版本用起来比较放心。安装步骤简要记录一下# 安装 Zabbix 仓库 rpm -Uvh https://repo.zabbix.com/zabbix/6.0/rhel/7/x86_64/zabbix-release-6.0-4.el7.noarch.rpm # 安装服务端组件 yum install zabbix-server-pgsql zabbix-web-pgsql zabbix-nginx-conf zabbix-sql-scripts zabbix-selinux-policy zabbix-agent2 # 初始化数据库 zcat /usr/share/doc/zabbix-sql-scripts/postgresql/create.sql.gz | psql -U zabbix -d zabbix装完之后有几处调优是必须做的。一个在/etc/zabbix/zabbix_server.conf重点调这几个参数StartPollers8 StartPollersUnreachable2 CacheSize256M HistoryCacheSize128M TrendCacheSize64M ValueCacheSize64M Timeout10StartPollers 默认只有 3如果管理的 Windows 机器超过 30 台明显不够用。监控项一多polling 队列会堆积告警延迟就到分钟级了。我这边直接拉到 8实测下来 polling 队列基本是空的。Timeout 默认 4 秒对于远程 WMI 采集来说太短。你想想监控服务器发起一个 WinRM 请求Windows 那边要认证、要执行 PowerShell 脚本、要把结果封装回来4 秒经常不够。我改成 10 秒采集稳定性明显提升。2.2 集中部署 exporter 进程目录结构与运行方式这是 V5.0 的核心。exporter 进程本质上是一组 Python 脚本集中放在监控服务器上通过 systemd 管理成常驻服务。它的职责是接收 Zabbix Server 的采集请求代为执行对 Windows 机器的远程查询。我的目录结构是/opt/windows_exporter/ ├── exporter_server.py # 主进程HTTP服务监听 9271 端口 ├── collectors/ │ ├── tcp_connections.py # TCP连接数采集器 │ ├── cpu_memory.py # CPU内存采集器 │ ├── disk_io.py # 磁盘IO采集器 │ └── system_uptime.py # 系统运行时间采集器 ├── config/ │ ├── servers.ini # 被监控Windows服务器清单 │ └── credentials.ini # 远程连接凭据加密存储 ├── requirements.txt └── run.sh主进程是一个 Flask 应用暴露一个 HTTP 接口Zabbix Server 通过web.page.get或web.page.perf之类的键值来获取数据。实际上我更推荐的方式是让 exporter 主动把数据推给 Zabbix Server也就是用zabbix_sender做主动上报这样 Zabbix Server 那边不用频繁发起 HTTP 调用采集频率可以做得更高。exporter 进程的运行方式用 systemd 管理[Unit] DescriptionWindows Exporter Collector Afternetwork.target [Service] ExecStart/usr/bin/python3 /opt/windows_exporter/exporter_server.py WorkingDirectory/opt/windows_exporter Restartalways RestartSec10 Userzabbix [Install] WantedBymulti-user.target这里有一个细节值得注意进程用户我用的是zabbix而不是root。因为 exporter 需要访问 Zabbix 的配置文件、调用zabbix_sender二进制用 zabbix 用户最合适。同时它也避免了用 root 跑 Web 服务的风险。依赖库方面我的requirements.txt很简单flask2.2.5 pywinrm0.4.3 pysnmp4.4.12 cryptography41.0.7pywinrm是连接 Windows WinRM 的库pysnmp用来做 SNMP 采集。注意cryptography的版本旧版本在 Python 3.11 上会有兼容性问题。2.3 exporter 如何安全保存远程凭据这是容易被忽视但很重要的一点。exporter 要远程连到 Windows 机器上执行 WMI 查询就必须有凭据。我开始图省事直接写在 Python 脚本里后来做安全评审被打了回来。现在我用的是加密存储方案凭据文件用cryptography库的 Fernet 对称加密密钥单独放在一个只有 zabbix 用户可读的文件里。系统启动时 exporter 进程读取密钥解密凭据文件加载到内存里。密钥文件和凭据文件分离即使源码泄露没有密钥也解不出凭据。2.4 Windows 被监控端的准备工作被监控的 Windows 机器需要开启 WinRM 和 SNMP 服务。WinRM 主要用于 WMI 类的指标采集比如 TCP 连接状态分布、进程列表SNMP 用于快速获取 tcpCurrEstab 这类标准 MIB 数据。开启 WinRM 在 Windows 上用管理员 PowerShell 执行Enable-PSRemoting -Force winrm set winrm/config/winrs {MaxMemoryPerShellMB1024} winrm set winrm/config {MaxTimeoutms60000} Set-Item WSMan:\localhost\Client\TrustedHosts -Value 监控服务器IP -ForceTrustedHosts一定要配不配的话监控服务器发起的 WinRM 请求会被拒绝。如果能走 Kerberos 认证最好但多数内网环境没有域用 TrustedHosts 基本认证是最省事的方案。SNMP 服务的开启路径是“服务器管理器 - 添加角色和功能 - 勾选 SNMP 服务”。装好后需要在“服务”里找到 SNMP Service配置“安全”选项卡填上团体名Community比如monitor_ro并限制只接受来自监控服务器 IP 的请求。防火墙要放通的端口协议端口用途TCP5985WinRM HTTPUDP/TCP161SNMPTCP135WMI DCOM可选用WinRM可不开注意如果用 WinRM 执行 WMI 查询不一定要开 135 端口因为 WinRM 走的是 5985。但如果你打算直接开 WMI 的远程调用就必须放通 135 和动态端口范围那个范围很麻烦我建议全部走 WinRM别直接用 DCOM。3. Windows TCP 连接数监控的完整实现3.1 TCP 连接数监拉的需求与常见方式TCP 连接数是 Windows 服务器运维里非常关键的指标。连接数异常暴涨往往意味着程序出现了连接泄漏、被扫描攻击或者某种业务异常。传统方式是在 Windows 本机用netstat -an | find /c ESTABLISHED来数但在集中式监控架构下我们不能到每台机器上去敲命令必须通过远程协议来采集。常用的远程采集方式有四个方式原理优点缺点Zabbix Agent在Windows装agent执行自定义脚本采集数据精确细腻业务机器要装组件违背V5.0原则SNMP直接查询 tcpCurrEstab OID实现最简单标准协议只能拿总连接数拿不到状态分布WinRM WMI远程执行PowerShell查询性能计数器能拿到各状态的连接数分布依赖WinRM配置速度稍慢WMI 性能计数器直接拉取通过 DCOM 远程查询不依赖WinRM防火墙端口麻烦架构不干净在这套 V5.0 方案里我 SNMP 和 WinRM 两条路都做了。SNMP 作为快速通道用于实时获取总连接数WinRM 作为详细通道用于获取 ESTABLISHED、TIME_WAIT、CLOSE_WAIT 等各状态的分布值。两条路都由监控服务器上的 exporter 统一发起。3.2 通过 SNMP 采集 tcpCurrEstabTCP 连接总数这个指标SNMP 里有一个现成的对象就是tcpCurrEstabOID 是1.3.6.1.2.1.6.9.0。它直接返回当前处于 ESTABLISHED 状态的 TCP 连接数量。exporter 里用 pysnmp 拉取from pysnmp.hlapi import * def get_tcp_cur_estab(ip, community): iterator getCmd( SnmpEngine(), CommunityData(community, mpModel1), UdpTransportTarget((ip, 161), timeout5, retries1), ContextData(), ObjectType(ObjectIdentity(1.3.6.1.2.1.6.9.0)) ) errorIndication, errorStatus, errorIndex, varBinds next(iterator) if errorIndication or errorStatus: return None for varBind in varBinds: return int(varBind[1])这里是mpModel1对应 SNMPv2c。如果 Windows 上配了 SNMPv3就需要换成UsmUserData。多数内网环境为了省事还是 v2c但我建议生产环境用 v3安全性高不少。拿到指标后exporter 把这个值在内存缓存起来Zabbix Server 通过自定义键值读取时直接返回缓存避免每次都去远程 SNMP 走一趟。SNMP 虽然有 timeout 机制但网络抖动的情况还是会有缓存一分钟能有效降低失败率。3.3 通过 WinRM 采集 TCP 连接状态分布要拿到 TIME_WAIT、CLOSE_WAIT 这种状态分布SNMP 是做不到的必须用 WinRM 执行 PowerShell 脚本。核心是利用 Windows 自带的性能计数器TCPv4/Connection Established只能拿总数要看状态分布得用Get-NetTCPConnection。在被监控机器上执行这条命令Get-NetTCPConnection | Group-Object State | Select-Object Name, Count返回结果会是一个类似这样格式的文本Name Count ---- ----- Established 139 TimeWait 205 CloseWait 7 Listen 12 SynSent 0exporter 通过 pywinrm 远程执行这条命令解析返回文本import winrm def get_tcp_state_distribution(ip, username, password): session winrm.Session(ip, auth(username, password), transportbasic) ps_script Get-NetTCPConnection | Group-Object State | Select-Object Name, Count result session.run_ps(ps_script) if result.status_code ! 0: raise Exception(result.std_err) # 解析输出返回字典 output result.std_out.decode(utf-8) lines [line.strip() for line in output.strip().splitlines() if line.strip()] dist {} # 跳过表头 for i, line in enumerate(lines): if line.startswith(----): continue parts line.split() if len(parts) 2 and parts[0] not in (Name, Count): try: dist[parts[0]] int(parts[1]) except ValueError: pass return dist这段代码是原理解析用的生产环境里我做了更严格的输出格式化处理。一种更稳的做法是让 PowerShell 输出 JSONGet-NetTCPConnection | Group-Object State | Select-Object Name, Count | ConvertTo-Json -Compress这样 Python 端直接json.loads解析不会有文本对齐问题。强烈建议用这种方式因为 PowerShell 表格输出在不同版本 Windows 上格式会有细微差异解析文本很容易翻车。3.4 exporter 缓存层与 zabbix_sender 主动上报exporter 采集到数据之后怎么进入 Zabbix 有两种路径。我两个都搭了最后选择的是主动上报方式。被动方式最简单Zabbix Server 上定义UserParameter让 Zabbix Server 去调 exporter 的 HTTP 接口拿数据。这种方式部署快但 Zabbix Server 每个轮询周期都要发起 HTTP 请求CPU 占用略高而且采集频率受轮询频率限制。主动方式更高效exporter 内部维护一个定时任务每 30 秒采集一轮所有 Windows 机器的 TCP 连接指标然后调用zabbix_sender主动推送到 Zabbix Server。这样 Zabbix Server 不需要到 exporter 上拉取exporter 自己控制采集节奏还能把数据批量打包在一起网络开销小得多。主动上报的配置示例zabbix_sender -z 127.0.0.1 -p 10051 -s Windows-Server-01 \ -k windows.tcp.established -o 139-s参数必须和 Zabbix 前端里配置的“主机名称”完全一致否则数据会因为找不到主机而丢弃。这是我刚开始经常搞错的地方。3.5 Zabbix 模板监控项、宏与触发器配置数据推上来之后要在 Zabbix 里把监控项、触发器配好。我建议建一个独立的模板“Windows TCP Monitor”然后把所有 Windows 服务器主机关联到这个模板上。监控项配置名称键值数据类型更新间隔TCP Established 连接数windows.tcp.established数值无符号30sTCP TimeWait 连接数windows.tcp.timewait数值无符号30sTCP CloseWait 连接数windows.tcp.closewait数值无符号30sTCP 总连接数windows.tcp.total数值无符号30s如果用的主动上报这些键值不需要在模板里配 UserParameter只需要在监控项里声明“类型为 Zabbix 采集端主动上报”即可。Zabbix 6.0 的监控项类型里有一个“Zabbix trapper”就是这个用途。触发器方面我配置了几个核心的告警规则总连接数超过 5000触发 warning总连接数超过 10000触发 highCLOSE_WAIT 大于 100触发 warning因为这很可能表示程序没有正确关闭连接TIME_WAIT 大于 2000触发 warning常见于高并发短连接场景严重等级和阈值需要根据业务情况来回调。比如那些业务本身就大量使用短连接的服务器TIME_WAIT 平时就有几千阈值设 2000 就太低了。最好先观察两周基线数据再定阈值。4. 常见问题与排查技巧实录4.1 WinRM 连接失败与 TrustedHosts 问题这个问题的现象是 exporter 日志里报winrm.exceptions.InvalidCredentialsError或者Unauthorized。排查时我从三层来确认。第一层确认防火墙。从监控服务器 telnet Windows 机器的 5985 端口不通就是防火墙没放通。第二层确认凭据。在监控服务器上用 pywinrm 写个单行测试脚本直接连一下看报错。第三层确认 TrustedHosts。Windows 机器上执行winrm get winrm/config/client查看 TrustedHosts 是否包含监控服务器的 IP。我遇到最隐蔽的情况是TrustedHosts 配置的是主机名但 exporter 里连的是 IP。WinRM 的认证机制会把 IP 和主机名当成不同的 host匹配不上就拒绝。解决方法是 TrustedHosts 里同时写上 IP 和主机名或者直接用通配符*内网环境可以考虑但安全上我给不出满分建议。4.2 SNMP 超时采集失败SNMP 超时的原因通常有三类网络不通、团体名不匹配、防火墙只放通了 UDP 没放通 TCP。注意 SNMP 默认走的 UDP 161但有些 Windows 机器配置了 SNMP 服务的同时也开了 TCP 161两头都要确认。另外Windows 的 SNMP 服务在收到请求后如果团体名不对会直接丢弃包不返回任何错误。所以超时的表象背后可能是团体名配置不一致。排查方法是先在监控服务器上手动跑一遍snmpwalksnmpwalk -v2c -c monitor_ro -t 5 -r 1 Windows_IP 1.3.6.1.2.1.6.9.0手动跑通了再排查 Zabbix 和 exporter 那一层。手动跑不通问题基本就在 Windows 端。4.3 PowerShell 脚本返回乱码或解析失败Get-NetTCPConnection在 Windows Server 2012 R2 上有一个已知问题需要先判断对象是否存在。因为该命令只在 Windows 8 / Server 2012 及以后版本才可用老系统上会直接报“无法将 Get-NetTCPConnection 识别为 cmdlet 的名称”。针对老系统的方案是用netstat加正则解析$states netstat -an | Select-String -Pattern TCP | ForEach-Object { if ($_ -match \s(LISTENING|ESTABLISHED|TIME_WAIT|CLOSE_WAIT|SYN_SENT)$) { $matches[1] } } $states | Group-Object | Select-Object Name, Count | ConvertTo-Json -Compress另外PowerShell 输出编码要注意。中文系统上ConvertTo-Json的输出如果包含中文Python 端可能解析出错。解决办法是统一用-Compress并且输出 ASCII 安全的内容或者把运行区域设置改成 UTF-8。4.4 zabbix_sender 数据不显示这个问题排查思路是这样的先确认 Zabbix Server 的 trapper 接收到数据没有。在 Zabbix Server 上执行tail -f /var/log/zabbix/zabbix_server.log | grep windows.tcp如果看到received data from localhost之类的记录说明数据到了问题在主机名或监控项配置。如果日志里没有记录说明 zabbix_sender 发出来的数据源就有问题。-s参数的主机名必须与 Zabbix 前端配置完全一致这是最常见的坑。还有一种是监控项的类型配错了如果监控项配成 Zabbix agent 类型trapper 数据就不会匹配上。4.5 连接数采集到了但图表是断线这个现象通常是间歇性的一会儿有数据一会儿没有。原因一般是采集脚本执行时间不稳定导致两次上报之间的间隔超过 Zabbix 对监控项定义的数据超时时间。解决办法是把 Zabbix 监控项的“允许数据丢失时间”从默认的 1 分钟放大到 3 分钟。另外一个原因是被监控 Windows 机器开启了节能策略没事就休眠网络适配器导致连接超时。把 Windows 电源计划改为“高性能”通常能解决。5. 批量管理、可视化与维护心得5.1 用配置驱动方式管理批量 Windows 主机exporter 的servers.ini采用配置驱动新增一台 Windows 机器只需要在这个文件里加一行[windows_server_202] ip 192.168.30.24 snmp_community monitor_ro winrm_user monitor_user然后执行systemctl restart windows-exporterexporter 会自动加载新配置。Zabbix 前端那边需要手动创建一台主机并关联模板或者用 Zabbix 的自动发现功能根据某种规则自动添加。我在生产环境用了一个更省事的组合Zabbix API Python 脚本把服务器清单自动同步到 Zabbix 主机配置里。新增服务器只需要维护一份 Excel 台账脚本自动生成主机、关联模板、设置宏。这套流程把新服务器接入监控的时间从半小时压缩到了五分钟以内。5.2 告警去重与值班体验优化连接数告警有个特点容易重复报。服务器连接数超标之后可能每 30 秒就触发一次值班人员手机能被震没电。我在 Zabbix 里三个手段来优化。第一触发器表达式加“持续 N 次才告警”的逻辑比如 3 次连续采集高于阈值才算故障。第二设置告警升级机制同一个触发器在 10 分钟内重复触发不重复发通知只把问题的严重级别升级一次。第三把所有连接数相关的触发器设置单独的告警媒介方便值班人员快速归类处理。5.3 Grafana 展示面板的核心指标布局数据进 Zabbix 之后可视化我推荐把 Grafana 面板直接对接 Zabbix 数据源。TCP 连接数的面板我一般做两行第一行是总览卡片显示当前所有 Windows 服务器的 TCP 总连接数、审计状态、最大值和最小值。第二行是分服务器的连接状态趋势图按 ESTABLISHED、TIME_WAIT、CLOSE_WAIT 三条线展示颜色分别用绿、黄、红一眼就能看出有没有异常状态堆积。CLOSE_WAIT 堆积是排查应用问题的利器。这个状态表示对端已经关闭连接但本端程序没有调用 close。一旦 CLOSE_WAIT 持续走高且不下降基本可以断定业务代码存在连接释放漏洞。这时候看趋势图上那条红线往上飘比你去翻业务日志快得多。5.4 后续扩展方向这套 V5.0 的采集架构搭好之后可以横向扩展很多指标。CPU、内存、磁盘 IO 都可以通过 WinRM 远程采集。Windows 服务状态监控也可以做用 PowerShell 的Get-Service。我目前已经加了 CPU、内存和磁盘空间监控采集方式是一样的。还有一个实用的扩展是 TCP 连接状态的时间序列异常检测。可以写一个简单的基线算法把每个小时连接数的平均值算出来当前值超过基线的三倍标准差就告警。这个对流量突增的感知特别快。做完整套方案之后我自己最大的体会有两点。第一集中式采集架构刚开始搭建的时候很多人会担心远程采集的性能问题但实测下来 WinRM 和 SNMP 的消耗对于一台监控服务器来说完全可接受。真正要花心思的是把脚本的异常处理做扎实比如超时重试、结果缓存、错误日志这些才是稳定性的关键。第二TCP 连接数这个指标表面看只是数字实际是应用健康状况的晴雨表。我靠这套方案不止一次提前发现了业务异常避免了事故扩大。监控不只是为了出图表最终目的是在业务出问题之前让运维能提前看到苗头。
