机房温湿度采集：环境数据自动上报

机房环境这块，我们吃了两年"靠人看"的亏。值班表上写着每两小时巡检一次，实际能做到一天两次就不错，温度表挂在门边，数字要凑近才看得清。前年夏天一台空调冷凝水管堵了，回风口滴水，等发现的时候地板下已经积了一层水，两台交换机停摆。之后做了一套温湿度自动采集上报，从采到存到报警形成闭环。结论：这套东西的难点不在采集本身，而在断网补传和告警规则设计。

一、环境监控为什么不能靠人

1.1 巡检表上的一行签名

老机房有一本巡检记录，每天两页，签个名字就算完成。记录上长期写着"温度 24 度，湿度 50%"，不管真实数字是多少，笔迹都一样。这不是态度问题，是人做重复性观察时的自然衰减——看了三年都正常，第四年就不会认真看。而环境事故恰恰是一年不发生、发生一次就够呛的类型。

1.2 环境异常的真实代价

按我们遇到的和同行讲过的，环境异常主要走三条路伤人：温度过高导致设备降频、随机重启，排查时容易误判成软件问题；湿度过高在板卡上结露，腐蚀和短路同时来；湿度过低产生静电，芯片被击穿但不立刻坏，几个月后批量出故障。这三类里，结露和静电尤其阴，因为它不报警、不宕机，只是慢慢地把设备寿命削掉。

1.3 采集的基本闭环

一套能用的环境监控，四件事必须齐：按固定频率采到数、本地存住不至于丢、上报到能查的地方、异常时能叫醒人。很多单位只做了头一步和第三步，看着有曲线，实际上一次断网就丢了半个月数据，或者阈值设得离谱，天天报警到头来没人看。闭环的每一环都得单独设计。

二、采集端怎么搭

2.1 传感器点位比数量重要

开始只在机房中间挂了一个，后来发现那个位置靠近空调出风口，测出来的温度比机柜进风口低三度，报警永远不触发。调整之后定三个点：冷通道中部、热通道回风侧、机房门口。高度都取一米五左右，避开风口直吹、避开阳光、避开人员常站的过道。三个点的数据放在一张图上对比，冷热通道的温差本身就是一个指标，温差拉大说明气流组织出了问题。

2.2 读取与上报脚本

采集机是一台低功耗小主机，通过串口读传感器，读到之后先落本地再上报。这样即使网络断了，数据也不会丢：

import json, sqlite3, time, datetime, urllib.request

DB = sqlite3.connect("env.db", check_same_thread=False)
DB.execute("""CREATE TABLE IF NOT EXISTS sample(
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    point TEXT, ts TEXT, temp REAL, humi REAL, synced INTEGER DEFAULT 0)""")
DB.commit()

def read_sensor(point):
    # 省略具体协议实现：返回 (temp, humi)，读取失败返回 None
    ...

def save(point, temp, humi):
    ts = datetime.datetime.now().astimezone().isoformat(timespec="seconds")
    DB.execute("INSERT INTO sample(point, ts, temp, humi) VALUES(?,?,?,?)",
               (point, ts, temp, humi))
    DB.commit()

def upload(batch=200):
    rows = DB.execute(
        "SELECT id, point, ts, temp, humi FROM sample WHERE synced=0 ORDER BY id LIMIT ?",
        (batch,)).fetchall()
    if not rows:
        return
    payload = [{"point": r[1], "ts": r[2], "temp": r[3], "humi": r[4]} for r in rows]
    req = urllib.request.Request(
        "/api/env",
        data=json.dumps({"samples": payload}).encode(),
        headers={"Content-Type": "application/json"})
    with urllib.request.urlopen(req, timeout=10) as resp:
        if resp.status == 200:
            ids = ",".join(str(r[0]) for r in rows)
            DB.execute("UPDATE sample SET synced=1 WHERE id IN (%s)" % ids)
            DB.commit()

while True:
    for p in ("cold_aisle", "hot_aisle", "door"):
        v = read_sensor(p)
        if v:
            save(p, *v)
    try:
        upload()
    except Exception as e:
        print("upload failed:", e)   # 失败不退出，下一轮继续
    time.sleep(60)

这段的核心是两条：先落本地再上传，上传失败只记日志不退出；同步状态用标记位，成功才改，避免重复上报也避免丢数。批量取两百条，一次请求传完，减少请求次数。

2.3 采集频率与上报频率分开

采集一分钟一次，上报五分钟一次。这么分的原因有两条：一分钟的粒度足够看出温度突变，五分钟一次上报能让请求量降下来，也让服务端写入更平稳。数据在本地保留三十天，超过的按天归档压缩，一台采集机的磁盘用两年也才几个吉字节。

2.4 采集机自己也要被监控

采集机挂掉是隐蔽的故障：没有数据上报，平台上看是"没有新数据"，很容易被当成网络问题忽略。解法是心跳：脚本每五分钟往平台写一条心跳，平台侧超过十五分钟没收到就报警。另外给采集机配了自动重启的看门狗，脚本异常退出后一分钟内拉起，日志里记一次重启，一个月重启超过三次要人工查原因。

三、告警规则怎么定

3.1 阈值加持续时间

只设阈值必然误报。夏天开门搬设备，门口点位三分钟就能升到三十度。规则改成阈值加持续时间：温度超过二十八度并持续十分钟才报警，回落到二十六度以下并持续十分钟才恢复。两个数字之间留两度回差，避免在阈值附近反复触发、反复恢复。

3.2 温升速率是更早的信号

等温度到阈值才报，往往已经晚了。加一条速率规则：十分钟内上升超过三度就预警。空调故障初期，温度爬升速度比绝对值更早暴露问题。我们靠这条规则提前发现过一次压缩机异常，当时温度还在二十四度，只是爬得比平时快。

3.3 告警要收敛

三个点位、两个指标、若干规则，很容易在同一时刻发出一堆通知。做法是按机房聚合：同一机房五分钟内的多条告警合成一条，列出触发的点位和指标。恢复通知同样聚合。收敛之后，值班的人愿意看了，这比规则调得多精准都重要。

四、运行两年遇到的坑

4.1 传感器会漂移

便宜的温湿度传感器，一年下来温度能偏一度多，湿度偏五个点。表现是三个点位的数据整体走势一致，但其中一个常年偏高。后来定了一年校准一次，用一台经过校准的手持仪器做比对，偏差超过零点五度就在平台里填一个补偿值。补偿值要留记录，否则时间长了没人知道这个偏是校准的还是故障的。

4.2 网络断了才知道本地缓存的重要

有次机房改造，网络断了六小时。因为先落本地，六小时的数据在恢复后自动补传，曲线是连续的。同一次改造中，另一个用直传方案的楼层丢了全部数据。这件事之后，所有采集类脚本我都要求先落本地，这个习惯后来在设备振动采集上也用上了。

4.3 时钟不准会让曲线错位

采集机断网时间长了，系统时钟会漂，补传上来的数据时间戳和实际对不上，曲线会出现回勾。之后统一走时间同步，补传时以样本里记录的时间戳为准，不用上报时间。这一条和日志、监控里的时间处理是同一个道理，凡是时间序列数据，时间戳必须在采集端就固定下来。

五、两年之后的效果

三个点位、两台采集机，跑了两年，数据可用率九成九。真正抓到的问题有三次：一次空调压缩机异常、一次冷通道被临时堆放的纸箱挡住、一次加湿器故障导致湿度掉到三成以下。这三次如果靠巡检，很可能要等到设备出问题才发现。值班方式也变了：原来每两小时走一圈，现在每天看两次曲线，省下的时间用来做别的事。还有一点体会是数据本身会说话：把三个点位的曲线放在同一张图上，冷热通道温差长期偏大，说明机柜气流组织有问题，这个结论不是靠一次巡检能得出的，得靠连续数据对比。

六、总结

机房环境采集是典型的"小系统、长期活"。方案上记住四点：点位要避开风口、先落本地再上报、阈值配持续时间并加温升速率、采集机自己要有心跳。设备本身不贵，贵的是两年后还准、还连着、还有人看。做到这四点，这套东西才能真正替掉那本巡检记录。

常见问题

问:只有一个机柜的小机房,值得做采集吗?

答:值得,但可以极简。一个点位、一个带网络接口的温湿度传感器,直连平台,不配采集机。规则只设两条:超阈值持续十分钟、十分钟温升超过三度。成本很低,但能在空调故障时争取到处理时间,对小机房来说,这半小时往往就是全部缓冲。

问:温湿度传感器怎么选,看哪些参数?

答:看四项:测量范围要覆盖机房实际区间,精度标注到温度零点五度、湿度三个点以内,通讯接口与采集方式匹配,长期稳定性有明确说明。价格差十倍的传感器,差别主要在长期漂移和一致性上,不是初始精度。预算有限时,宁可少布点位选好传感器,也不要多点位选便宜货。

问:断网时间很长,补传会不会把平台冲垮?

答:要限速。补传按批次走,每批两百条,两批之间加一秒间隔,几千条数据几分钟补完,不会形成尖峰。同时平台侧对同一采集机的写入做限流,超出部分排队。另外补传的数据要带原始时间戳,平台按时间戳写入,不要用接收时间,否则曲线会错位。

问:告警发到手机上,半夜要不要叫醒人?

答:分两级。温度超过阈值持续十分钟,发消息不打电话,值班的人早上看;温度超过三十二度或十分钟上升超过五度,直接打电话,因为这种情况往往意味着空调已经停了,设备随时可能出问题。分级之后,半夜被叫醒的次数一年不到五次,每次都是真事。