机房运维这行干久了最难堪的时刻不是设备故障本身而是故障后给不出过程数据。我有一次处理机房空调停机等赶到现场时设备已经高温自动关机但原有监控系统只能告诉我几点几分超过阈值之前三四个小时温度是怎么一步步涨上去的曲线完全没有。家底薄的监控日志根本经不起审计。后来我决定自己动手做一套带本地存储的POE温湿度记录仪走SNMP协议读历史曲线最后导出机房审计报表前前后后折腾了三个多月硬件、协议、报表链路全部打通。现在把这套方案拆开来说清楚给正在做机房环境监测、边缘数据采集或者物联网记录设备的朋友做个参考。这个项目说白了就干三件事让记录仪通过网线供电POE、数据存本地不死机丢数据SD卡/Flash、对外提供SNMP服务让上层直接读历史数据并生成报表。市面上的商用温湿度记录仪往往只给一个封闭的HTTP接口或者私有协议历史数据被锁在厂商服务器里审计时要么导不出来要么格式不规范。自己做一套的好处是所有OID、存储结构、报表模板都自己说了算后期想接Grafana、Prometheus还是私有运维平台都容易。1. 机房温度审计需求背后的三个隐形痛点1.1 只看实时告警解决不了事后追溯绝大多数机房的温度监控停留在超过阈值就发告警这个层面。实时告警虽然及时但审计问询时往往需要回答三个问题温度是从什么时候开始异常爬升的异常持续了多久期间还有没有其他关联指标变化如果记录仪自身不带本地存储、上层平台也只保留短期的轮询结果这些问题基本答不上来。我最早调研过几款商用POE温湿度传感器它们的本地缓存通常只有几千条记录五分钟采一条只能存三四天想跨月拉曲线要不停翻平台。还有的所谓历史曲线其实依赖服务器端数据库留痕一旦平台迁移、数据库清理或者网络抽风那一小时的数据缺口就永远补不上。而本项目的设备端就是第一手数据源断电断网都不影响数据落盘这是审计安全感的来源。1.2 SNMP协议不是老古董是审计场景的刚需很多做物联网的人觉得SNMP太老都用MQTT了。但机房里的NVR、路由器、UPS、空调监控卡几乎全部支持SNMP。机房审计系统、动环监控平台、网络管理软件如Zabbix、华为esight、SolarWinds对SNMP的兼容性远好于自定义协议。用SNMP对接记录仪的历史数据等于让这台设备天然融入已有运维技术栈不需要额外装Agent不用开放SSH只需要暴露几个OID就够了。在热词里看到华为 snmp实验、stm32 snmp trap v2c 代码这类搜索说明不少同学是在嵌入式设备上实现SNMP或者做网管联调时遇到了需求。实际上SNMP v2c的GET、WALK操作足够读取历史数据TRAP可以作为越限触发的主动通知。用好了一个传感器节点和一个交换机一样管理端无感接入。1.3 本地存储必须跟供电方式一起设计POE供电的优势是省去一根电源线但POE供电本身也有讲究。IEEE 802.3af标准最大提供约13W功率到了802.3atPOE约25.5W一个温湿度记录仪加上SD卡和以太网模块功耗也就两三瓦af足够了。真正要命的是POE交换机的PSE供电策略——有的交换机默认不做PoE定时供电夜晚会断电来节能这对实时性要求不高的传感器也许没事但如果记录仪依赖不断电做数据写入就会在断电瞬间产生文件系统损坏。所以本地存储不能简单插个SD卡就完事必须考虑掉电保护。这个小细节后面硬件章节细说。2. 硬件选型POE供电、本地存储与传感器三者的匹配逻辑2.1 主控与以太网方案STM32F407 W5500 的黄金组合芯片选型时我对比了好几个方案方案成本以太网实现适用场景STM32F407 PHY芯片LAN8720稍高内置MACRMII接PHY需要高速率、大量数据的场景STM32F103 W5500低外挂全硬件TCP/IP低速、并发少、开发周期短ESP32 以太网扩展低外挂MAC/PHY或W5500WiFi/以太网双模但稳定性略弱STM32F407 W5500中外挂全硬件TCP/IP主控资源充裕本项目最终方案我最终选了STM32F407W5500原因是这台设备不仅要跑SNMP Agent还要驱动SD卡记录数据、处理传感器读取、运行简易文件系统而且现场可能出现多个管理端并发轮询。W5500自带完整的TCP/IP协议栈主控不用在协议上投入太多心力开发效率高。F407有足够RAM和Flash后期想加TRAP、加Modbus转发、加Web配置页都能扛得住。2.2 POE供电模块隔离与非隔离的选择POE供电一开始就要确定是用标准802.3af PD方案还是非标准的被动POE。标准PD比如SI3402模块会与PSE做特征电阻识别和分类握手安全可靠45W以内的大功率设备也适用。被动POE虽然便宜但如果插到标准PSE上可能因为电压/极性不匹配直接烧设备机房环境里风险太大不建议用。选型时注意PD模块的输出功率余量。一个模块额定输出13W实际记录仪在SD卡写入瞬间的电流尖峰可能到400mA加上W5500和传感器峰值功耗在1.5W2W之间余量很充足。如果同时还要带一路外接排气扇那就要往POE方向选PD模块否则时序上启动扇子的一刻电压跌破设备工作范围系统可能反复重启。2.3 传感器选型SHT30在精度与成本之间最稳温湿度传感器可选空间很大。DHT11太粗糙SHT31高精度但是贵SHT30在0~60°C范围内典型精度±0.3°C湿度±2%RH机房审计场景已经绰绰有余。关键要选带I2C地址可配置的型号一条I2C总线上可以挂多路传感器。我在项目里预留了两路传感器接口一路测机柜前门温度一路测回风温度后期扩展部署非常方便。传感器读取不能一条I2C命令搞定就完事SHT30在测量后需要等待约4.5ms的数据就绪时间如果固件里不加延时或者不加数据就绪标志判断会出现偶发的读回0xFFFF或数据跳变。另外传感器应远离W5500和变压器的散热区不然测到的温度是板温。2.4 本地存储SD卡还是SPI Flash存储方案我纠结了最久。SPI FlashW25Q64等可靠性高、没有文件系统碎片问题但容量通常只有64Mbit8MB以5分钟一条记录、每条记录约40字节计算存储深度只有约3.7万条记录也就是4个多月的量对审计要求来说偏紧。SD卡容量可以做到32GB直接覆盖十年级别的数据但它有两个致命弱点一是文件系统容易在突然断电时出现FAT表损坏二是廉价SD卡的写寿命和稳定性参差不齐。我的解决办法是双路存储SD卡作为主线存储定期把数据导出到CSV文件板载W25Q64作为循环应急缓冲区当SD卡尚未就绪或者文件系统异常时先写到Flash随后再补录。这个设计在实际运行中帮我挽回过一次因劣质SD卡导致的数据空白功耗也只增加了不到0.3W。2.5 硬件组装的几个关键细节电源去耦在POE模块输出处必须加足够容量的钽电容/电解电容通常330uF起步。POE握手成功后PSE会突然送电瞬间的inrush current会导致输出电压跌落没有储能电容会直接重启。传感器探头用RJ45延长座的方案可以做成外置探头方便卡在机柜前后门。做线的时候注意I2C的SDA/SCL不能超过400kbps线长超过0.5m建议走100kbps。SD卡座要用自弹式带卡检测引脚的类型固件里可以通过卡检测引脚感知SD卡是否插牢减少明明插了卡但上报存储异常的误报。W5500的INT引脚必须接主控的外部中断不然在SNMP并发请求多的时候可能丢包。3. SNMP历史数据读取从设备OID到曲线图的完整链条3.1 私有OID规划不能随手乱写SNMP读取历史数据关键在设计一套合理的OID结构。标准MIB-2如system、interfaces是留给网络设备的温湿度记录仪要做成企业私有MIB一般挂在enterprises节点下面。假设企业号为45214那设备基础信息就可以规划成1.3.6.1.4.1.45214.x.1.0 设备信息厂商、型号、固件版本 1.3.6.1.4.1.45214.x.2.0 当前温度 1.3.6.1.4.1.45214.x.3.0 当前湿度 1.3.6.1.4.1.45214.x.4.1.index 历史记录温度表 1.3.6.1.4.1.45214.x.4.2.index 历史记录湿度表 1.3.6.1.4.1.45214.x.4.3.index 历史记录时间戳表 1.3.6.1.4.1.45214.x.5.0 告警状态时间戳建议用Unix时间戳The unsigned integer type这样管理端不需要处理字符串解析绘图时直接转成本地时区即可。历史记录表可以按记录ID连续递增SNMP WALK顺着表走一遍就能取出所有历史数据。3.2 Agent端实现基于Net-SNMP移植还是手抄协议栈STM32上实现SNMP Agent有两条路子。第一条是用现成的Net-SNMP交叉编译到ARM平台但Net-SNMP体量庞大在STM32上跑吃力第二条是手写一个轻量SNMP Agent只实现需要的MIB子树和GET/WALK操作。本项目我用了自研轻量Agent的思路核心代码只有几百行。理由很直接历史记录表的WALK在SNMP标准协议里逻辑相对简单请求OID、找到对应记录、响应OID和值不需要复杂的SET操作。SNMP v2c消息格式也就BER编码用STM32的C代码完全可以控制住。提供一段核心的GET处理思路示意// 伪代码/核心逻辑示例根据OID定位到历史记录 static int mib_history_lookup(oid *oid_array, size_t oid_len, record_t *rec) { // 判断属于history的哪一列温度/湿度/时间戳 int column oid_array[ARRAY_POS_COLUMN]; int index oid_array[ARRAY_POS_INDEX]; if (index 0 || index get_max_record_index()) return OID_NOT_FOUND; rec-column column; rec-index index; return OK; }真正的实现里还需要处理BER TLV的编解码、OID压缩编码子标识符1234会被编码成0x80, 0x2A等细节很多但想拓展的同学可以先拿现成库比如“lwSNMP”来改。3.3 TRAP主动推送越限不能只靠轮询历史曲线适合用GET/WALK去拉取但实时告警必须有主动推送机制否则轮询周期太长温度突变可能到下一轮才被发现。我在Agent里实现了SNMP TRAP v2c当温度超过设定阈值主动向管理端发送一条包含设备编号、当前温度、湿度、时间戳的TRAP报文。TRAP的实现在STM32上有个坑TRAP报文和普通GET响应的构造过程几乎一样但TRAP目标地址由配置文件指定而且标准UDP端口是162防火墙经常拦。实测发现机房网络里必须提前确认UDP 162端口未被ACL阻断否则告警消息静默丢失。我的做法是在TRAP头里加一个本地性能标志“engine id”的方式避免被部分网管平台因SNMP版本校验直接丢弃。3.4 管理端读取历史数据并绘图管理端我用Python写了一个调度脚本基于pysnmp同步获取每5分钟拉一次数据并写入SQLite配合Grafana或matplotlib绘图。用pysnmp进行历史表WALK的示例from pysnmp.hlapi import * def walk_history(ip, communitypublic): hits [] for (errorIndication, errorStatus, errorIndex, varBinds) in nextCmd( SnmpEngine(), CommunityData(community, mpModel1), UdpTransportTarget((ip, 161)), ContextData(), ObjectType(ObjectIdentity(1.3.6.1.4.1.45214.x.4)) ): if errorIndication or errorStatus: break for varBind in varBinds: hits.append(varBind) return hits曲线绘制我直接用了GrafanaSQLite数据源。如果你不想引入Grafana用matplotlib把SQLite里的数据按天导出成PNG图片然后嵌入网页或邮件发送也能达到审计展示的效果。曲线图的美化不重要关键在时间轴的连续性处理好时区偏移。3.5 历史曲线的完整性校验由于SNMP GET请求的数据包大小有限一次WALK大量历史记录可能因为UDP分片或者Agent处理超时被截断。设计Agent时不能让管理端一次性WALK全部记录而是按时间分页或者按记录ID分段。我在管理端脚本中实现了按日的范围WALK当天记录ID在A到B之间只WALK这个区间第二天再WALK下一个区间。用SQLite存储到本地后我还会做完整性校验如果发现相邻两条记录的时间间隔远大于采集周期例如5分钟采一条却发现间隔30分钟就标记为“疑似异常断档”同时在审计报表最后一行列出断档时间段。机器可以偶尔断网但不能瞒报自己断网了这是审计逻辑里很重要的一环。4. 审计报表导出的设计与自动化实现4.1 报表结构给审计人员看什么报表不是简单把温度表原样导出而是要有摘要明细取证。我设计的报表包含以下几个部分基本信息设备编号、位置、部署时间、固件版本时间范围本次报表覆盖的起止时间温度统计最高/最低/平均温度、发生时间点湿度统计最高/最低/平均湿度、发生时间点越限事件每一次超过温度/湿度阈值的时间段逐个列出断档记录设备离线、存储异常等数据缺口的时间段附录完整的数据明细表4.2 导出格式选型CSV与Excel的取舍审计交付时经常被要求提供Excel文档所以我做了两种格式CSV格式机器可读性最好适合后续二次分析、数据库导入体积小。Excel格式xlsx有固定模版自动带有条件格式比如温度高于设定阈值自动标红适合直接发给人工审计。用Python的pandas和openpyxl可以很轻松地把SQLite数据转成Excel并按条件着色。import pandas as pd from openpyxl import load_workbook from openpyxl.styles import PatternFill df pd.read_sql_query(SELECT * FROM history WHERE ts BETWEEN ? AND ?, conn, params(start_ts, end_ts)) df[time_str] pd.to_datetime(df[ts], units).dt.tz_localize(UTC).dt.tz_convert(Asia/Shanghai) with pd.ExcelWriter(audit_report.xlsx, engineopenpyxl) as writer: df.to_excel(writer, sheet_name明细, indexFalse)如果你想让报表直接通过邮件定时发送用Python的smtplib和email模块打包配合系统的crontab或Windows任务计划就能做到每周一早上9点自动把上周的审计报表发到负责人邮箱。我在项目中就是月度打包成ZIP再发。4.3 越限事件与断档记录怎么自动标记SQLite里我除了历史明细表还维护一张event_log表每次Agent处理过程中发现温度越限、TRAP发送成功/重试失败、SD卡写失败、断电重启都往里写一条事件记录。生成审计报表时直接查询这张表并按时间段归类。需要注意越限事件的时长计算不能简单用“越限时刻减解除时刻”因为可能中间管理端离线Agent端TRAP重发多次但都没收到响应。我的做法是每次轮询都记录一个当前是否越限的布尔字段报表统计时重新从明细数据计算越限时刻和解除时刻保证计算逻辑不受网络抖动影响。4.4 报表自动生成的时间窗口设计审计报表通常按天、按周、按月三个维度生成。我在设计时可没想着每生成一次就全量导出那会让系统在月末那个小时性能很差。更好的方式是把历史数据分成当前月分区和历史月分区日报只读当天数据月报读整月数据后汇总同时增量更新摘要表。一套记录仪可能在现场连续运行一两年报表导出的SQL查询如果没有索引后期会越来越慢。我给历史表建了(ts, device_id)联合索引SQLite查询性能大大改善。数据量在两百万条记录时月报生成时间从最初的十几秒降到两秒内。5. 实测运行效果与现场排查经验5.1 一个真实机柜的24小时曲线部署在通信机房一个标准42U机柜温度采集点后记录了24小时的温湿度数据。温度白天稳定在23.5°C26.8°C之间凌晨空调低负荷运行温度降到22.1°C。湿度基本维持在45%55%RH。整个曲线在Grafana里正常显示SNMP WALK拉取六个月历史记录也没有出现大缺口。对比同机柜原商用传感器的数据温差在0.3°C以内湿度在2%RH以内符合预期。5.2 踩坑记录一POE供电不稳导致SD卡文件系统损坏第一版样机连续跑了十天某天查看历史发现某一段记录全部丢失。检查代码没发现逻辑问题后来查SD卡文件系统发现FAT表异常。原因是这台交换机是支持PoE的8口千兆交换机但有PSE省电策略当负载电流低于阈值时会自动断电再重启。记录仪断电瞬间SD卡正在进行写入于是文件系统崩溃。解决方案是三步走第一SD卡在每次写入前先调用flush确保数据进入物理扇区第二SD卡格式化时预留一段FAT备份区启动时自动做一致性检查第三应急Flash缓冲区优先级更高遇到SD卡写入失败立刻切到Flash不阻塞主流程。经过这轮修改后续三个月没有出现过数据断档。5.3 踩坑记录二SNMP响应速率过快导致UDP丢包W5500硬件协议栈性能很强我刚开始没有限速管理端WALK几百条历史记录时Agent以毫秒级速度连续发送UDP响应结果管理端pysnmp经常报超时。原因是管理端处理SNMP响应需要时间UDP缓冲区溢出。解决方法是Agent响应之间加微延时比如每条记录间隔1ms3msW5500的发送缓冲区分割成多个小段每条记录独立发送。同时管理端WALK时增加下行重试次数观察吞吐量从每秒几十条提升到稳定每秒两百多条再也不丢包。5.4 踩坑记录三传感器受通风道影响读数偏低在调试初期我把传感器板卡直接贴在交换机散热口附近测得的温度始终比机柜前门温度低三四度。实际上传感器探头必须尽量处于空气自由流通的位置不能被机柜钣金遮挡也不要在服务器正面出风直吹的位置附近。后来我把探头用延长线引出到机柜前门进风口的位置读数与机房动环平台的实际温度趋于一致。5.5 关于后续扩展的几个方向方案稳定后我额外做了两件事一是把SNMP Agent的能力延伸到了多设备管理模式一台采集器后面挂多个传感终端走私有协议汇总后统一对外提供SNMP接口二是把历史数据在管理端自动同步一份到对象存储机房现场即使损毁审计数据仍有备份。如果你也准备做一个类似的设备我的核心建议是最开始就分好设备存储模型与管理端读取模型不要把历史数据的组织方式跟报表需求耦合太深。设备端只负责可靠地记录和按OID暴露数据报表是上层的事。切好这一刀后面所有功能都能顺畅加上。