从零手搓SNMP温湿度采集：OID定位、MIB解析与Python自动化实战

1. 为什么我要从零手搓一套SNMP采集

机房动环监控这个事，说大不大，说小不小。你如果只是盯着几台服务器看温度，那随便找个带屏幕的温湿度计往机柜上一贴就完事了。但一旦机柜数量上到十几个、几十个，分布在不同的楼层甚至不同的楼宇，靠人肉巡检就彻底不现实了。我最早接触这块的时候，试过用USB温湿度记录仪，便宜是便宜，但每个设备都得插电脑导出数据，而且没法实时告警。后来也考虑过走Modbus RTU转TCP的方案，但布线成本高，而且很多老机房根本没有预留485总线。

最后绕来绕去，还是回到了SNMP这条路上。原因很简单：绝大多数企业级温湿度变送器都自带RJ45网口，支持SNMP协议，你只要给它配个IP，剩下的就是网管软件的事了。而且SNMP是网络设备管理的通用语言，交换机、路由器、UPS、精密空调都在用，学会一套就能通吃。这篇文章就是把我从零搭建SNMP采集温湿度数据的完整过程记录下来，包括OID怎么找、MIB怎么用、数据怎么读、读不到怎么排查。如果你手头正好有一台支持SNMP的温湿度变送器，或者你正准备给机房加一套环境监控，这篇笔记应该能帮你省下不少翻文档的时间。

先说一下我的测试环境，免得后面讲的东西对不上号。我用的是一台常见的壁挂式温湿度变送器，带LCD屏和RJ45网口，支持SNMP v1/v2c/v3，温度量程-20~60℃，湿度量程0~100%RH，精度分别是±0.5℃和±3%RH。采集端我用的是一台Linux服务器，装了net-snmp工具集，后面也会提到用Python的pysnmp库来做自动化采集。整个调试过程大概花了一个下午，其中大部分时间都耗在找OID和排查community配置上，所以这两块我会讲得特别细。

2. SNMP采集的整体设计思路拆解

2.1 为什么选SNMP而不是Modbus或HTTP轮询

在动手之前，先把方案选型的逻辑理清楚，这样后面遇到问题你才知道该往哪个方向调。温湿度采集常见的协议就三种：Modbus、SNMP、HTTP API。Modbus最便宜，但需要额外的串口服务器或者网关，而且每个厂商的寄存器地址定义都不一样，换一个品牌就得重新对文档。HTTP API最灵活，但很多工业级变送器根本不支持，而且HTTP轮询的开销比SNMP大得多，不适合高频采集。

SNMP的优势在于它是为网络管理而生的协议，UDP 161端口，请求响应模型，开销极小。一个GET请求过去，设备回一个GET RESPONSE，整个过程就几个数据包。而且SNMP有标准的MIB结构，虽然温湿度这类环境参数不在标准MIB里，但厂商通常会提供私有MIB文件，你导入之后就能看到可读的OID名称，不用对着数字瞎猜。另外，SNMP v2c支持一次请求多个OID（GetBulk），采集效率比Modbus轮询高不少。

当然SNMP也有坑，最大的问题就是OID不统一。同样是温度，A厂商可能是.1.3.6.1.4.1.XXXX.1.1.1.0，B厂商可能是.1.3.6.1.4.1.YYYY.2.3.4.0，完全没有规律。所以这篇文章的核心价值，就是教你怎么快速定位到正确的OID，而不是给你一个固定的OID列表——因为那个列表换个设备就没用了。

2.2 采集架构的确定

我的采集架构很简单，分三层：设备层、采集层、存储展示层。设备层就是温湿度变送器本身，配好IP和SNMP参数之后就不用管了。采集层是一台Linux服务器，跑一个Python脚本，每隔60秒用SNMP GET请求拉一次数据。存储展示层我用的InfluxDB加Grafana，这个不是本文重点，但我会在最后简单提一下数据怎么落库。

为什么采集间隔定60秒？因为温湿度变化本身就很慢，你就算每秒采一次，数据曲线也不会有明显区别，反而增加设备和网络的负担。60秒对于机房环境监控来说完全够用，告警响应时间也在可接受范围内。如果你有特殊需求，比如要监测空调出风口的温度波动，可以缩短到10秒，但一般没必要。

注意：SNMP默认走UDP协议，不保证数据包一定到达。如果你的网络环境丢包率较高，建议在采集脚本里加超时重试机制，一般重试2次、超时3秒就够用了。

2.3 需要提前准备的软硬件清单

在开始之前，你需要准备这些东西。硬件方面：一台支持SNMP的温湿度变送器、一根网线、一台Linux服务器（或者任何能跑Python的机器）。软件方面：net-snmp工具集（包括snmpget、snmpwalk、snmpbulkwalk）、Python 3环境、pysnmp库。如果你用的是Windows，也可以装net-snmp的Windows版本，命令基本一样。

网络方面，确保采集服务器和变送器在同一个网段，或者路由可达。变送器的IP地址最好固定，要么在设备上配静态IP，要么在DHCP服务器上做MAC绑定。我见过太多因为IP变了导致采集断掉的情况，排查半天才发现是DHCP租约到期换了地址。

3. 核心细节解析与实操要点

3.1 变送器端的SNMP配置

拿到变送器之后，第一件事不是急着用snmpwalk去扫，而是先把设备本身的SNMP参数配好。大多数变送器都有一个Web配置页面，你用浏览器访问它的IP就能进去。如果设备没有Web页面，那就需要用厂商提供的配置工具，或者通过串口命令行配置。

在Web页面里，你需要关注这几个参数：SNMP版本、Community字符串、Trap目标地址（可选）、SNMP端口（默认161）。SNMP版本建议选v2c，因为v1不支持GetBulk，v3配置又太复杂，v2c在安全性和便利性之间平衡得最好。Community字符串相当于一个密码，默认通常是public，但强烈建议你改成自定义的，比如monitor@2024之类的。虽然SNMP v2c的Community是明文传输的，但在内网环境下，改掉默认值能挡住大部分扫描器的自动探测。

Trap目标地址是设备主动上报异常时用的，比如温度超过阈值，设备会主动发一个Trap包给采集服务器。这个功能很有用，但需要采集端也配置Trap接收器。我建议先把GET采集跑通，再考虑Trap。

实操心得：有些变送器的Web页面保存配置后需要重启才生效，而且重启过程中SNMP服务会中断十几秒。所以配置完不要马上测试，等设备完全启动后再操作。

3.2 用snmpwalk摸清设备的OID树

配置好设备端之后，下一步就是用snmpwalk把设备的整个OID树扫一遍。这个命令会遍历设备上所有可用的OID，输出可能很长，但这是找到温湿度OID最直接的方法。

snmpwalk -v 2c -c monitor@2024 192.168.1.100

如果设备响应正常，你会看到一大堆输出，格式大概是这样的：

SNMPv2-MIB::sysDescr.0 = STRING: Temperature Humidity Sensor V2.1 SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.12345.1.1 DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (123456) 0:20:34.56 SNMPv2-MIB::sysContact.0 = STRING: admin@example.com SNMPv2-MIB::sysName.0 = STRING: TH-Sensor-01 ...

前面这些是标准MIB里的系统信息，不是我们要找的。温湿度数据通常在enterprises分支下面，也就是.1.3.6.1.4.1开头的OID。你可以用grep过滤一下：

snmpwalk -v 2c -c monitor@2024 192.168.1.100 | grep "enterprises"

这样输出就清爽多了。你会看到类似这样的内容：

SNMPv2-SMI::enterprises.12345.1.1.1.0 = STRING: "TH-Sensor" SNMPv2-SMI::enterprises.12345.1.1.2.0 = INTEGER: 25 SNMPv2-SMI::enterprises.12345.1.1.3.0 = INTEGER: 58 SNMPv2-SMI::enterprises.12345.1.1.4.0 = INTEGER: 1

这里25和58很可能就是温度和湿度，但单位是什么？是摄氏度还是华氏度？湿度是百分比还是原始值？光看数字猜不出来，必须结合厂商的MIB文件来确认。

3.3 MIB文件的导入与OID名称解析

MIB文件就是设备的“字典”，它把数字OID映射成人类可读的名称。厂商通常会在官网提供MIB文件下载，文件名一般是XXXX-MIB.txt或XXXX.mib。拿到MIB文件后，你需要把它放到net-snmp的MIB目录下，通常是/usr/share/snmp/mibs/。

sudo cp VENDOR-MIB.txt /usr/share/snmp/mibs/

然后在使用snmpwalk时加上-m参数指定MIB文件，或者用-M指定MIB目录：

snmpwalk -v 2c -c monitor@2024 -m VENDOR-MIB 192.168.1.100

如果MIB文件正确加载了，输出就会变成这样：

VENDOR-MIB::temperature.0 = INTEGER: 25 VENDOR-MIB::humidity.0 = INTEGER: 58 VENDOR-MIB::tempUnit.0 = INTEGER: celsius

看到temperature和humidity这两个名字，就说明MIB导入成功了。但这里有个细节要注意：MIB文件里的OID定义必须和设备的实际OID完全对应。有些厂商的MIB文件版本和固件版本不匹配，导入后名称对不上，这时候你就得手动对比MIB文件里的定义和设备实际返回的OID。

常见坑：MIB文件里的温度OID可能是.1.3.6.1.4.1.12345.1.1.2.0，但设备实际返回的是.1.3.6.1.4.1.12345.1.1.2.1，差了一个数字。这种情况通常是固件升级后OID变了但MIB文件没更新。解决办法是直接用数字OID去GET，不要依赖MIB名称。

3.4 温度值的单位换算与精度处理

找到OID之后，还有一个容易被忽略的问题：原始值的单位换算。很多变送器为了节省传输字节，会把温度值乘以10之后再发送。比如实际温度是25.3℃，设备返回的是253。如果你直接把这个值当温度用，就会得到253℃这种离谱的结果。

怎么判断是否需要除以10？看MIB文件里的描述。如果MIB里写的是INTEGER类型，并且描述里有unit: 0.1 celsius或者scale: 10之类的字样，那就需要除以10。如果MIB里写的是Gauge32或者INTEGER但没有缩放说明，那可能就是直接值。

湿度也是同样的道理。有些设备返回58表示58%RH，有些返回580表示58.0%RH。我遇到过一台设备，温度返回253，湿度返回580，两个都需要除以10。也遇到过温度返回25，湿度返回58，都是直接值。所以不要假设，一定要看MIB文档或者用已知环境验证。

验证方法很简单：拿一个校准过的温湿度计放在变送器旁边，等读数稳定后对比。如果SNMP读到的值是25，温湿度计显示25.3，那说明设备返回的是整数摄氏度，精度到1℃。如果SNMP读到的值是253，温湿度计显示25.3，那就需要除以10。

4. 实操过程与核心环节实现

4.1 用snmpget精确读取温湿度OID

摸清OID之后，就可以用snmpget来精确读取了。假设温度OID是.1.3.6.1.4.1.12345.1.1.2.0，湿度OID是.1.3.6.1.4.1.12345.1.1.3.0，命令如下：

snmpget -v 2c -c monitor@2024 192.168.1.100 .1.3.6.1.4.1.12345.1.1.2.0 .1.3.6.1.4.1.12345.1.1.3.0

输出：

SNMPv2-SMI::enterprises.12345.1.1.2.0 = INTEGER: 253 SNMPv2-SMI::enterprises.12345.1.1.3.0 = INTEGER: 580

一次GET请求可以带多个OID，这样比分开两次请求效率高。如果你要采集的OID比较多，比如还有电池电压、信号强度等，都可以加在后面。

4.2 Python脚本实现自动化采集

命令行测试通过之后，就可以写Python脚本做自动化采集了。我用的是pysnmp库，安装很简单：

pip install pysnmp

下面是一个最小可用的采集脚本：

from pysnmp.hlapi import * def get_snmp_data(ip, community, oids): results = {} for oid in oids: errorIndication, errorStatus, errorIndex, varBinds = next( getCmd(SnmpEngine(), CommunityData(community, mpModel=1), # mpModel=1 表示 v2c UdpTransportTarget((ip, 161), timeout=3, retries=2), ContextData(), ObjectType(ObjectIdentity(oid))) ) if errorIndication: print(f"Error: {errorIndication}") return None elif errorStatus: print(f"Error: {errorStatus.prettyPrint()}") return None else: for varBind in varBinds: results[oid] = varBind[1].prettyPrint() return results if __name__ == "__main__": ip = "192.168.1.100" community = "monitor@2024" oids = [ "1.3.6.1.4.1.12345.1.1.2.0", # 温度 "1.3.6.1.4.1.12345.1.1.3.0", # 湿度 ] data = get_snmp_data(ip, community, oids) if data: temp_raw = int(data["1.3.6.1.4.1.12345.1.1.2.0"]) humi_raw = int(data["1.3.6.1.4.1.12345.1.1.3.0"]) temperature = temp_raw / 10.0 humidity = humi_raw / 10.0 print(f"温度: {temperature}°C, 湿度: {humidity}%RH")

这个脚本每次运行采集一次数据。如果你要持续采集，可以在外面套一个while True循环加time.sleep(60)。但更优雅的做法是用schedule库或者直接写进crontab。

实操心得：pysnmp的getCmd默认是同步阻塞的，如果你要同时采集几十台设备，建议用异步模式或者多线程。不过对于十几台设备的场景，同步循环完全够用，没必要过度设计。

4.3 数据落库与可视化

采集到的数据我一般直接写进InfluxDB，因为它的时序特性很适合这种场景。写入的代码很简单：

from influxdb_client import InfluxDBClient, Point from influxdb_client.client.write_api import SYNCHRONOUS client = InfluxDBClient(url="http://localhost:8086", token="your-token", org="your-org") write_api = client.write_api(write_options=SYNCHRONOUS) point = Point("environment") \ .tag("device", "TH-Sensor-01") \ .field("temperature", temperature) \ .field("humidity", humidity) write_api.write(bucket="monitoring", record=point)

Grafana那边配置一个InfluxDB数据源，然后画两条曲线就完事了。温度用红色，湿度用蓝色，再设个阈值线，超过就变黄。这套组合我用下来很稳，数据保留策略设成30天，磁盘占用几乎可以忽略。

4.4 采集频率与超时参数的调优

前面提到采集间隔定60秒，但超时和重试参数也需要调。默认的timeout=1秒和retries=0在某些网络环境下不够用，尤其是变送器本身处理能力较弱的时候。我一般设成timeout=3、retries=2，这样即使偶尔丢一个包，也能在两次重试内拿到数据。

但重试也不是越多越好。如果你设了retries=5，而设备恰好宕机了，那每次采集都会卡15秒以上，整个采集周期就被拖长了。所以超时和重试要配合采集间隔来设，总耗时不能超过采集间隔的一半。比如60秒采集一次，那超时加重试的总时间最好控制在10秒以内。

5. 常见问题与排查技巧实录

5.1 SNMP连接超时的排查思路

这是最常见的问题，snmpget返回Timeout: No Response from 192.168.1.100。排查顺序如下：

我遇到最多的情况是Community字符串配错了。有些设备的Web页面保存后不会立即生效，需要点“应用”或者重启。还有一种情况是设备端配了SNMP ACL，只允许特定IP访问，而采集服务器的IP不在白名单里。

避坑技巧：如果你不确定Community是什么，可以先试试public和private这两个默认值。如果都不行，就只能重置设备或者翻配置文档了。

5.2 OID返回noSuchObject的解决方法

snmpget返回No Such Object available on this agent at this OID，说明这个OID在设备上不存在。可能的原因有三个：OID写错了、MIB版本不对、设备固件不支持这个OID。

解决办法是先用snmpwalk扫一遍enterprises分支，看看设备实际返回了哪些OID。然后拿这些OID和MIB文件里的定义对比，找到对应的那个。如果MIB文件里定义的OID在设备上不存在，那可能是固件版本太老，需要升级固件。

还有一种情况是OID的末尾.0的问题。有些OID是标量，需要加.0，有些是表格，需要加索引。比如.1.3.6.1.4.1.12345.1.1.2是标量，实际读取时要写成.1.3.6.1.4.1.12345.1.1.2.0。如果你漏了.0，就会返回noSuchObject。

5.3 温度值明显异常的排查

如果读到的温度是253或者-1000这种明显不合理的值，先别急着怀疑设备坏了。按这个顺序排查：

1. 确认单位换算：253可能是25.3℃，需要除以10。
2. 确认符号位：有些设备用-1000表示传感器故障，-2000表示未校准。
3. 确认量程：如果设备量程是-20~60℃，那-1000肯定不是正常温度值。
4. 确认OID：你可能读到了错误的OID，比如读到了湿度值或者状态寄存器。

我遇到过一台设备，温度OID返回的值一直是32767，查了MIB才知道这是“传感器未连接”的故障码。所以MIB文件里的枚举值定义一定要看，不能只看OID名称。

5.4 采集脚本长时间运行的稳定性问题

Python脚本跑几天之后可能会因为内存泄漏或者网络异常而挂掉。解决办法有两个：一是用systemd或者supervisor做进程守护，挂了自动重启；二是在脚本里加异常捕获和日志记录，方便排查问题。

import logging logging.basicConfig(filename='snmp_collector.log', level=logging.INFO) try: data = get_snmp_data(ip, community, oids) if data: # 处理数据 pass else: logging.warning(f"采集失败: {ip}") except Exception as e: logging.error(f"异常: {e}")

日志文件建议按天切割，不然时间长了会占满磁盘。用logrotate配置一下就行，很简单。

5.5 常见问题速查表

6. 一些关于SNMP采集的零散经验

SNMP v3比v2c安全得多，它支持认证和加密，但配置也复杂得多。你需要配用户名、认证协议（MD5或SHA）、认证密码、加密协议（DES或AES）、加密密码。如果你的环境对安全要求不高，v2c完全够用。但如果你的采集流量会经过不可信网络，那还是上v3。

另外，有些变送器支持SNMP Trap主动上报，比如温度超过阈值时主动发一个Trap包。这个功能在告警场景下很有用，因为不需要采集端轮询就能第一时间知道异常。但Trap是UDP单包，不保证到达，所以通常还是配合轮询一起用。

最后说一个我踩过的坑：变送器的SNMP服务在设备重启后可能需要几十秒才能就绪。如果你在设备刚上电就开始采集，前几次请求可能会超时。所以采集脚本最好加一个启动延迟，或者把超时重试设得宽松一点。这个细节在设备文档里通常不会写，但实际部署时很容易遇到。

数据落库这块，如果你不想用InfluxDB，也可以用MySQL或者SQLite。但时序数据用关系型数据库存，查询效率会随着数据量增长而下降。InfluxDB的压缩率很高，30天的温湿度数据也就几十MB，非常省空间。Grafana的告警功能也很完善，可以配邮件或者Webhook通知，比你自己写告警逻辑省事得多。

采集频率方面，我再啰嗦一句：不要盲目追求高频采集。温湿度变化本身就很慢，60秒一次已经能捕捉到所有有意义的变化。如果你采得太频繁，不仅增加设备负担，还会产生大量冗余数据，后期查询和分析都麻烦。我见过有人设成1秒采集一次，结果一天下来几百万条数据，Grafana画图都卡。后来改成60秒，曲线一模一样，数据量少了60倍。

关于OID的稳定性，不同批次的同一型号设备，OID可能不一样。我遇到过同一厂商同一型号的两台变送器，一台温度OID是.1.3.6.1.4.1.12345.1.1.2.0，另一台是.1.3.6.1.4.1.12345.1.2.2.0。原因是固件版本不同。所以不要假设同型号设备的OID一定相同，每台设备上线前都要用snmpwalk确认一遍。这个工作量不大，但能避免很多后期排查的麻烦。

如果你要采集的设备数量比较多，建议做一个设备清单表格，记录每台设备的IP、Community、温度OID、湿度OID、单位换算系数。这样后面加设备或者换设备的时候，直接查表就行，不用重新扫OID。这个表格用CSV或者YAML存都行，Python脚本读进来批量采集。

devices: - ip: 192.168.1.100 community: monitor@2024 temp_oid: 1.3.6.1.4.1.12345.1.1.2.0 humi_oid: 1.3.6.1.4.1.12345.1.1.3.0 temp_scale: 0.1 humi_scale: 0.1 - ip: 192.168.1.101 community: monitor@2024 temp_oid: 1.3.6.1.4.1.12345.1.2.2.0 humi_oid: 1.3.6.1.4.1.12345.1.2.3.0 temp_scale: 1.0 humi_scale: 1.0

这样脚本就通用了，加设备只需要改YAML文件，不用动代码。这个做法我从第一次部署就沿用到现在，省了很多重复劳动。