半夜两点机房空调压缩机故障停机UPS在市电恢复前把电池跑得一干二净第二天上午到现场一看一排服务器全部断电机柜顶部温度已经飙到四十多度。这种场景对无人值守机房来说并不算罕见也是我在做了好几个机房项目之后下定决心把UPS和精密空调联动监控这件事彻底打通的原因。这篇文章就聊聊我落地的一套“UPS 一主一备精密空调智能联动监控方案”从设备选型、数据采集、监控配置到联动策略把完整思路和实操细节写下来给同样在做无人值守机房监控的朋友一个直接能抄的作业。1. 需求拆解与整体方案选型1.1 无人值守机房到底在守什么先说清楚一个概念所谓无人值守不代表设备不出问题而是希望在设备出问题的时候系统能第一时间感知、判断、甚至自动处理。对一个小型边缘机房来说最怕的不是设备性能差而是三件事市电断了没人管、空调停了没人管、电池耗尽了没人管。这三件事单独出现还好一旦叠加起来比如市电停电后UPS转电池供电空调压缩机又恰好停机机柜温度会在很短时间内超过设备允许的工作范围硬盘故障、交换机过热重启、业务服务全部挂掉都很有可能。我在规划这套方案的时候把目标拆成了三层第一层是“看得见”UPS和精密空调的运行状态、关键指标必须能被远程采集实时展示在监控大屏或手机端第二层是“响得了”出现异常要能通过电话、微信、短信等渠道告警不能只靠机房里的声光报警器第三层是“会联动”市电断电后UPS电池剩余多少、精密空调是否故障、备机是否需要启动这些逻辑要能够在平台上自动触发而不是等人到现场再操作。三层目标说穿了就是一个完整的“监控—告警—处置”闭环。1.2 为什么是“UPS一主一备精密空调”组合很多朋友会问为什么UPS用单机、空调反而要一主一备这里有个简单的逻辑UPS在市电断电后提供的是应急供电时间它的可靠性可以通过定期巡检和电池健康管理来保证而精密空调承担的是持续散热任务只要机房在运行它就一刻不能停一旦单台空调故障机柜温度上升速度远比想象中快尤其是在夏季高负载场景下。用一主一备精密空调是最常见也最划算的冗余方案。主空调常年运行备机平时处在待命状态主空调故障或者温度异常升高时备机自动投入运行。这么做的好处是既不需要像大型数据中心那样做N1的复杂空调群控也能在无人值守场景下保证温控不出现空窗期。这里还需要提醒一句有人会把UPS和EPS搞混EPS应急电源切换时间通常是秒级服务器这种设备一秒断电可能就直接掉电重启了UPS的优势是毫秒级切换所以机房供电保障必须用UPS不能用EPS替代。1.3 整体监控架构与数据流向整套监控架构我用的是Zabbix作为统一监控平台设备侧分两路接入UPS通过自带的管理软件生成日志文件由Zabbix Agent读取精密空调通过RS485 Modbus协议接入再经过Modbus网关转换成Modbus TCPZabbix直接通过网口轮询采集。两台精密空调分别设置不同的从站地址这样同一个网关就能同时管理一主一备两台设备。数据流向大致是设备 → 采集通道 → Zabbix平台 → 触发器判断 → 告警动作/联动脚本。所有数据在Zabbix里统一展示告警和联动策略也在Zabbix的触发器与动作里统一配置。整个架构的好处是没有引入太多专用硬件也没有绑定某个厂商的封闭协议后续换设备品牌也不用推翻重来性价比和灵活性都很好。2. 设备侧数据采集是联动的根基2.1 UPS侧数据采集山特WinPower G2市面上UPS品牌很多山特是机房场景里最常见的老牌选手。我用的这台山特UPS自带管理软件WinPower G2很多人不知道G2除了可以在局域网内做Web管理以外还会在本地安装目录下生成一个实时刷新的LOG文件夹里面按日期记录UPS的运行状态、输入输出电压、电池容量、负载百分比等信息。正是这个日志文件成了Zabbix采集UPS数据的关键通道。具体来说WinPower安装之后默认会有一个Web服务访问它的管理页面如果出现502 Bad Gateway或者其他无法访问的情况一般不是UPS本身的问题而是WinPower的Web管理服务挂了或者被Windows更新中断重启服务就能解决。我在集成时没有走它的Web接口而是直接读取日志文件这类文件通常存放在WinPower安装目录下的LOG文件夹内文件名类似于“UPSLog_20250115.log”里面每一行都包含时间戳和一条状态记录比如市电电压、电池容量、负载百分比、电池状态等。2.2 精密空调侧数据采集Modbus网关精密空调不像家用空调它基本都支持RS485 Modbus RTU通信协议这是机房设备的标准接口。我的两台精密空调都配有RS485通信口用一条双绞线并接到一台Modbus网关的RS485端网关另外一端通过网线接入交换机给网关分配一个固定IP这样Zabbix就能通过网络用Modbus TCP协议直接读取空调的运行数据。这里有一个非常重要的参数——从站地址。RS485总线上的每一台设备都必须有唯一的从站地址我是通过空调控制面板上的通信设置项把主空调设为1备机设为2然后在网关里分别映射两个设备的寄存器区间。不同品牌的精密空调寄存器地址会不一样比如有些品牌把回风温度放在40001有些放在40002所以在配置之前一定要先找到厂商提供的Modbus通信协议手册对照手册确认每个参数对应的寄存器地址、数据类型和缩放系数否则读出来就是一堆乱七八糟的数字。2.3 环境温湿度的补充采集精密空调自带的温湿度传感器通常安装在空调回风口附近反映的是整个机房回风温度的平均水平但机房里的设备布局往往会形成局部热点比如靠近服务器出风口的位置温度会比回风温度高出好几度。为了让联动逻辑更准确我额外加了两套环境温湿度传感器一套挂在机柜正面中间高度的进风侧另一套放在机柜背面排风侧同样通过RS485接到Modbus网关。为什么要这样补因为联动策略里的温度阈值不能只看空调自己的回风温度比如主空调还在运行但机柜进风侧温度已经超过28度这说明空调制冷量不够或者说气流组织有问题此时应该触发报警提醒检查甚至启动备机辅助降温。环境传感器的位置也很有讲究不要放在空调出风口正前方那样测到的是空调吹出来的冷风温度不代表设备实际进风温度。3. 监控平台实操Zabbix接入配置3.1 基础环境准备监控平台我是用一台小主机装的Zabbix Server配置不用太高四核CPU、8G内存就够跑了操作系统用的Ubuntu Server LTS数据库用的MySQLZabbix版本是6.0系列。之所以单独用一台小主机而不是把Zabbix装在跑业务的服务器上是为了避免监控系统本身成为业务系统的负担无人值守机房里监控平台自己必须先稳定。装好Zabbix之后第一步是把UPS所在的那台Windows管理主机装好Zabbix Agent这台Windows主机负责运行WinPower G2也负责被Zabbix采集日志。精密空调这边不需要在设备上装AgentZabbix Server直接通过Modbus TCP去轮询Modbus网关即可。两个采集通道的端口注意要提前在防火墙上放通Windows主机放通10050端口给Agent通信Modbus网关放通502端口给Modbus TCP通信。3.2 从WinPower日志到Zabbix的配置读取WinPower日志这块为了不让Zabbix的item配置过于复杂我是先用脚本把实时日志里最新的几个关键参数抽取出来写到一个独立的文本文件中再用Zabbix Agent去读这个文本文件。抽取脚本用PowerShell写的设置成系统计划任务每隔30秒执行一次把电池容量、市电状态、负载百分比这几个字段分别写到“C:\ups_status\current.txt”这样的文件里内容格式就一行简单明了比如“battery85,utilityok,load32”。在Zabbix配置端为这台Windows主机添加几个item类型选择“Zabbix Agent”键值用vfs.file.contents[C:\\ups_status\\current.txt]读取整个文件然后在预处理里通过正则表达式把对应的数字字段取出来。比如提取电池容量正则就可以写battery([0-9])提取后保存为“UPS电池剩余容量”。这样处理的优点是灵活后续如果换了UPS品牌只要改一下抽取脚本Zabbix侧的item不用大改。3.3 精密空调Modbus TCP Register模板配置Zabbix 6.0自带“Modbus TCP”的模板不需要额外装插件但需要手动配置连接参数和轮询地址。我建了两台“精密空调主机”对应的就是主空调和备机每台主机添加相同的item模板只是IP地址相同网关IP从站地址不同1和2寄存器地址根据空调厂商的协议手册来填。以我用的空调为例关键参数和寄存器对应关系是这样一张表参数名称寄存器地址数据类型缩放系数说明回风温度4000116位无符号0.1实际值寄存器值/10回风湿度4000216位无符号0.1实际值寄存器值/10压缩机运行状态4000516位无符号10-停机1-运行整机故障状态4001016位无符号10-正常1-故障需要注意不同品牌的寄存器地址和缩放系数差异很大有个朋友用的另一品牌空调温度寄存器需要除以100而不是10如果没看手册直接套模板读出来的温度会差出好几倍。所以在配置之前一定要先用Modbus调试工具比如Modbus Poll手动读一遍确认每一个寄存器读出来的数值跟空调面板显示的值一致再填到Zabbix里。3.4 触发器与联动动作的设计Zabbix的价值在于触发器也就是“什么情况算异常”的判断规则。我针对每项数据都设计了至少两级阈值避免一有点波动就报警刷屏。以UPS电池容量为例触发器表达式大概是{ups_host:last(ups_battery_capacity)}50触发“电池容量低于50%”动作是发送告警并执行降载脚本再往下{ups_host:last(ups_battery_capacity)}20触发“电池容量低于20%”动作升级为电话通知并执行核心业务安全关闭流程。温度侧也类似回风温度超过26度告警超过30度触发备机启动联动温度恢复低于24度后再延迟一段时间自动关闭备机防止频繁启停。动作里可以配置远程命令执行联动脚本。这里有一个建议不要直接用Zabbix Agent的远程命令去写精密空调的寄存器万一写错把空调关了反而引发故障。我采用的是“Zabbix动作触发 → 调用一个独立的联动控制脚本 → 脚本通过Modbus写寄存器或通过Windows主机的脚本来控制”的方式脚本本身加日志每次联动都有记录可查。4. 一主一备的联动控制逻辑4.1 主备切换的完整流程一主一备空调联动最核心的一点是判断“什么时候备机该起来”。我定义了三种触发场景第一种是主空调故障Modbus读到整机故障状态为1第二种是主空调回风温度持续两分钟超过28度说明主机制冷能力不够第三种是机柜进风侧环境温度超过30度即使主机显示正常也要启动备机辅助降温。备机启动后并不是一直运行下去我设了一个自动恢复条件主空调故障恢复且回风温度降到24度以下并稳定运行10分钟或者进风温度降到26度以下备机才自动停机回到待命状态。这个逻辑很关键如果不加恢复条件备机一旦启动就要等到人去手动关反而失去“无人值守”的意义。实际操作中还有个细节两台空调的RS485通信是共用一条总线的如果备机启动后总线通信压力变大偶发读超时会拖慢整个轮询周期。针对这个问题我把Zabbix对每台空调的轮询周期从默认的30秒调到了60秒并且把“超时时间”从默认的3秒调到5秒实测下来稳定性明显提升没有再出现误报通信故障的情况。4.2 断电降载的联动流程市电断电后UPS切到电池供电此时机房设备继续运行但电池容量是有限的这套机房的UPS满配续航大约40分钟在满负载情况下可能还不到30分钟。无人值守的逻辑就是一定要在电池耗尽之前分阶段把不重要的负载切掉把宝贵电力留给核心设备。我定义的联动流程分四步市电断电且UPS电池容量低于80%给运维人员发通知提醒确认是否需要远程关闭部分非关键设备。电池容量低于50%自动执行降载脚本由Zabbix远程命令触发Windows管理机上预设的批处理或PowerShell命令关闭视频监控存储服务器、测试虚拟机、备用网络存储等非关键负载。电池容量低于20%进入紧急保护模式向所有核心业务服务器发送安全关机指令让操作系统正常关停避免强断电损坏系统和硬盘。市电恢复且电池容量回到80%以上再按相反顺序远程启动设备先启动核心基础设施再逐台拉起业务服务。这个流程我在平时做过多次模拟演练把UPS输入开关直接拉掉观察整套联动是不是按预期执行。第一次演练就发现一个问题降载脚本执行后有一台存储设备没有正常关机排查发现是Windows主机的计划任务权限不足脚本运行账户没有关机权限。解决方法是把计划任务配置成使用系统账户运行并勾选“最高权限运行”。5. 告警触达与无人值守体验5.1 告警分级与触达渠道监控数据有了联动逻辑有了最后还差一环——怎么把异常告诉人。无人值守机房的告警触达渠道我建议至少保证两条一主一备因为单一渠道飞到故障的时候再指望它也有点风险。我用的是微信通知加电话语音通知的组合Zabbix的告警动作通过Webhook调用企业微信机器人把告警标题、触发时间、设备名称、关键数值推送到企业微信群对于P1级紧急告警电池容量低于20%、机房温度高于30度、空调故障且备机启动失败另加一路电话语音外呼通过调用云服务商的语音通知API直接把预设的告警文案用电话念出来。配置上有个要注意的点Zabbix动作的通知模板里宏的使用要规范比如把机房名称、设备IP、当前数值都放到通知内容里这样运维人员收到告警不用再去翻监控就能快速判断。我在模板里固定写法是“【告警级别】机房名称-设备名称-告警描述当前值xx”这种格式很短在微信和电话里都能完整展示。5.2 告警风暴的规避刚开始上线这套监控的时候最让我头疼的不是设备故障而是告警风暴。有一回市电波动UPS在电池供电和市电供电之间来回切换了几次触发器每反转一次就发一条告警十分钟不到手机弹了二十多条消息结果真正的关键告警反被淹没在一堆重复通知里。解决告警风暴我在Zabbix触发器上做了“依赖关系”把低级别的告警去掉重复通知并且在动作里开启“升级为故障后不重复发送”的限制。另外在触发器表达式里加了持续时间条件比如市电状态异常要持续60秒以上才触发告警瞬时抖动不产生动作。这样既保证了敏感度又过滤掉了瞬时的干扰信息。还有一个技巧是给每个动作设置独立的恢复通知只有在确认故障恢复后才发一条“恢复”消息这样整个告警链路是闭环的运维人手上有一条清晰的故障处理时间线。6. 常见问题与实战排查6.1 高频问题速查表问题现象可能原因排查思路与解决方法Zabbix读不到WinPower日志Agent路径配置错误或抽取脚本未运行先在Windows主机上手动运行抽取脚本确认输出文件有内容再看Zabbix Server上item的“最后一次数据”是什么时报错Modbus网关每过几小时就不响应网关TCP连接未释放或端口冲突重启网关临时恢复检查是否多个采集端同时连接同一网关给网关设置空闲连接超时参数温度读数与实际面板显示不一致寄存器缩放系数不对用Modbus Poll工具手动读取确认实际值除以缩放系数后应与面板一致备机启动后又立刻停机恢复条件不满足或触发器误判断检查备机启动后回风温度传感器位置确认是否因为传感器距离过近导致降温过快触发恢复市电断电后没有收到告警UPS日志抽取异常或触发器阈值设置过高检查WinPower G2服务是否假死Windows更新后服务没有自动恢复是常见原因重启并设为自动启动Web管理页面502 Bad GatewayWinPower G2的Web服务异常中断重启WinPower服务防火墙放行对应端口注意Windows更新可能重置服务状态6.2 实操心得与推荐扩展整套方案跑了大半年我自己最大的体会是联动监控的可靠性不在于用了多贵的设备而在于每一层都需要有兜底。数据采集要有冗余告警触达要有双通道联动执行要有日志可查任何一个环节出错无人值守就变成了无人知道。另外UPS和精密空调这类设备只要协议是开放的不管品牌怎么换这套架构都能平滑迁移这也是我为什么坚持用Zabbix加Modbus加日志文件这类“通用语言”来集成的原因。最后再分享一个扩展思路。如果预算有限或者想先在测试环境验证联动逻辑可以考虑用磷酸铁锂电池和MOSFET切换电路DIY一个小型12V UPS成本很低配合树莓派跑Zabbix Agent同样能模拟市电断电、电池容量下降等场景把Zabbix侧的触发器、动作、通知渠道全部调通之后再搬到生产机房对接正式UPS设备。我后来复盘的时候发现很多联动脚本的边界条件就是通过这种低成本模拟环境提前暴露出来的真到生产现场踩坑的代价可比这高多了。