这个项目难在哪
每个案例的难点都不一样。先把难点说清楚，方案才有意义。
三家厂商各带一套网管，运维要在三个界面之间来回切，故障定位时无法横向对比同一时刻的数据。
厂商随设备附带的 MIB 文档版本落后于实际固件，华为 S12700E 的 OID 偏移与文档对不上，直接照文档采会拿到空值。
最容易算错的地方是流量口径：取接口总流量会得到远大于实际用户流量的数字，必须聚合 VAP 和 Radio 子表的 Counter64 才能还原真实值。
运行环境锁死在 Java 1.8，不能引入依赖新版本 JDK 的 SNMP 库。
项目背景
这所学校在五年内分三批建设无线网络，每次招标中标的厂商不同。结果是一张校园网里同时存在锐捷、华三、华为三套无线控制器，各自的管理系统只能看到自己的设备。网络中心要回答「教学楼三楼现在有多少人连着 WiFi、哪个 AP 快撑爆了」这种问题，得先登录三个系统分别查，再手工拼起来。
需求本身不复杂：把三家的数据统一采到一个地方，按统一口径展示。难点全在「统一」两个字上——三家厂商对同一个指标的定义、OID 位置、数据类型都不一样。
第一步不是写代码，是把 MIB 摸清
很多采集项目失败在起手就写程序。这次我们先做了一轮纯探测：对 7 台设备逐台执行 SNMP walk，把返回结果落成日志，再对着日志反推哪张表有数据、字段是什么类型。
11 张 MIB 表探测下来，真正有用的是 5 张核心表。以锐捷为例：
| 表名 | OID 根 | 用途 | 关键点 |
|---|---|---|---|
| ruijieStaTable | .56.5.1.1.1.1 | 在线终端列表 | 26 列 MIB 定义，含 MAC / IP / 所属 AP / 信号强度 |
| apStationInfoGetTable | .2.81.6.1.1.1 | 终端详细信息 | 补 Radio、SSID、认证方式 |
| apLinkStatisticsTable | .2.81.10.2.1.1 | AP 链路统计 | 按 AP 聚合的上下行字节数 |
| DHCP 地址池表 | .2.58.1.3.1.1 | 地址池状态 | 池名、网关、DNS、已用/可用数 |
| 标准 ifTable | .2.10.1.1.1 | 接口流量 | Counter64，必须处理 32 位回绕 |
厂商随设备附带的 MIB 文档是旧版本的，按文档给的 OID 去采，返回全空。我们把 v3 固件实际支持的 OID 重新走了一遍 walk，逐个比对后才确定偏移量，修正后采集正常。这件事的教训是：MIB 文档只能当参考，真值必须从设备上取。
流量口径：这是最容易算错的一步
如果直接取 AP 所在接口的 ifInOctets / ifOutOctets，会得到一个比实际用户流量大一个数量级的数字——因为接口流量里混了管理报文、广播、以及上下行重复计数。
正确做法是聚合 VAP 子表和 Radio 子表的 Counter64 值求和。每个 AP 下有多个 VAP（每个 SSID 一个），每个 VAP 又按 Radio 频段分成多条记录，把这些叶子节点的字节数加起来，才是这台 AP 真正承载的用户流量。
- 必须用 Counter64 而不是 Counter32，否则 1Gbps 链路上几十秒就会回绕一次，算出来的流量是负值。
- 轮询周期不能短于 60 秒，否则同一采集周期内多次回绕无法判断，只能丢弃该样本。
- 设备重启会导致计数器归零，需要识别 sysUpTime 跳变并跳过该周期，否则会算出一个巨大的负向差值。
实现：三套程序，一套口径
最终交付的是三套独立的 Java 采集程序（按厂商分），共用一套数据模型和输出格式。分三套而不是一套的原因很实际：三家设备的表结构差异太大，硬塞进一个类里会变成一堆 if-else，后续加一家厂商就得改主流程。分开之后，新增厂商只需要新写一个采集器实现统一接口。
- 1采集层：SNMP4J 走 v2c / v3，按表批量 walk，单台 AC 全量采集控制在 8 秒内。
- 2归一化层：把三家的原始字段映射到统一模型（设备、AP、终端、流量四类实体）。
- 3输出层：按阿里云物模型规范输出，同时生成电表类设备和 AC 类设备两套物模型。
- 4调度层：用固定间隔轮询，采集失败自动重试两次，仍失败则标记设备离线并告警。
运行环境是客户既有服务器，JDK 版本不能动。SNMP4J 选了兼容 1.8 的版本，同时避开了所有 JDK 9+ 才有的 API。这一点在方案阶段就确认过，避免开发完才发现跑不起来。
实测结果
项目已完成全量实测，7 台 AC 全部接入，数据准确性经过与厂商自带网管的交叉核对。
| 指标 | 实测值 | 说明 |
|---|---|---|
| 接入 AC 数量 | 7 台 | 锐捷 / 华三 / 华为，全部通过 v3 认证 |
| 纳管 AP 数量 | 2226 台 | 与厂商网管显示一致 |
| 在线终端数 | 4172 个 | 峰值快照，含有线与无线 |
| 单台 AC 全量采集耗时 | ≤ 8 秒 | 含 5 张核心表 walk |
| 华为 S12700E | OID 已修正 | v3 固件实际偏移，非文档值 |
交付物包括三套可执行程序、完整的 OID 映射表、以及一份实测报告——报告里记录了每张表在每家设备上的实际返回样例，后续换固件或加设备可以直接对照。
用到的技术
这些技术在其他项目里也用过，完整的协议支持清单和已实测规模见技术能力
有类似的项目？
把你的现场情况说清楚就行，不用先写需求文档。我们会告诉你从哪切入最划算、哪些环节其实可以不花钱。