很多团队把"网络可视化"做成了"画一张拓扑图"——静态、无告警、无依赖关系。这篇从工程实现角度讲清楚三件事：拓扑数据怎么采、边集怎么存、告警怎么落到图上。
核心要点
- 拓扑数据来自两块：SNMP 轮询拿端口与地址表，CDP／LLDP 拿邻接关系。
- 拓扑建议存"边集"而非"图"，更新时 diff 边集，天然支持变更追溯。
- 告警与拓扑必须共享资产标识，否则无法自动落到节点上。
- 依赖关系要建"影响关系"（有方向），不是"连接关系"（对称）。
- MTTR 拆成两个可测指标：定位时长 + 影响面确认时长。
一、拓扑数据从哪里来
拓扑由两部分拼成：设备自身的端口与地址信息，以及设备之间的邻接关系。前者靠 SNMP 轮询，后者靠邻居发现协议。
# 1) 拿接口清单（ifDescr / ifOperStatus），OID 来自 MIB-II snmpwalk -v2c -c public 10.0.0.1 1.3.6.1.2.1.2.2.1.2 snmpwalk -v2c -c public 10.0.0.1 1.3.6.1.2.1.2.2.1.8 # 2) 拿 ARP / 邻居地址表，建立 IP - MAC - Port 关系 snmpwalk -v2c -c public 10.0.0.1 1.3.6.1.2.1.4.22.1.2 # 3) 拿 LLDP 邻居（远端设备名 / 远端端口号）——邻接关系的主要来源 snmpwalk -v2c -c public 10.0.0.1 1.0.8802.1.1.2.1.4.1.1.5 snmpwalk -v2c -c public 10.0.0.1 1.0.8802.1.1.2.1.4.1.1.7读数要点：LLDP 的远端设备名与远端端口号是成对的，拿到这一对就能确定一条边。如果某台设备只返回本端信息、远端字段为空，说明对端没开 LLDP——这类"半条边"要单独标记，不能当成孤立节点丢掉。
二、拓扑存"边集"而不是"图"
这是整个实现里最值得强调的一个设计选择。把拓扑存成"节点 + 边"的表结构，比存成一张渲染好的图要灵活得多。
-- 边集表：一条记录 = 一条链路 CREATE TABLE topo_edge ( src_dev VARCHAR(64), src_port VARCHAR(64), dst_dev VARCHAR(64), dst_port VARCHAR(64), proto VARCHAR(8), -- lldp / cdp / manual first_seen TIMESTAMP, last_seen TIMESTAMP, PRIMARY KEY (src_dev, src_port, dst_dev, dst_port) ); -- 端点在设备上做全局唯一标识：设备ID + 端口标识 -- 用它去和告警系统对齐，避免"图上有的设备告警系统不认"这样设计有三个直接好处：更新时只需对比last_seen做增量；能回答"这条链路是什么时候接上的"；渲染层可以按视图自由组合（全量图、按机房过滤、按业务过滤），而不需要为每种视图单独存一份数据。
三、告警怎么落到图上
关键是共享资产标识。告警记录里带上设备标识，渲染时按标识匹配节点。判断标准很直接：故障发生时，你需不需要切换系统？
# 渲染时把告警按节点聚合（伪 SQL） SELECT t.src_dev, t.src_port, a.severity, COUNT(*) AS alert_cnt FROM topo_edge t JOIN alert a ON a.device_id = t.src_dev -- 共享资产标识是关键 WHERE a.state = 'open' AND a.raised_at >= NOW() - INTERVAL '15 minutes' GROUP BY t.src_dev, t.src_port, a.severity;四、影响关系：有方向的依赖
很多人把"依赖关系"理解成"连接关系"，这两者不等价。连接关系是对称的（A—B 等于 B—A），影响关系是有方向、有层级的（核心交换机挂影响接入层，反过来不成立）。
| 视图类型 | 数据结构 | 回答的问题 |
|---|---|---|
| 连接关系 | 无向边集 | 谁和谁连在一起 |
| 影响关系 | 有向图 + 层级 | 谁挂了会影响谁 |
| 业务映射 | 多对多映射表 | 哪台设备承载哪个业务 |
只有把影响关系建出来，才能实现"故障发生时自动列出受影响业务清单"。这一步通常需要人工确认层级，无法完全自动推导。
五、六个视图的落地顺序
推荐自下而上，每一步都能独立产生价值：资产发现 → L2 拓扑 → 虚拟化与业务视图 → 地理与机房视图 → 容量趋势视图。资产发现是唯一不能跳的一步——没有完整清单，后面所有视图都是残缺的。
四个常见坑：节点爆炸（上万节点需要分层聚合，默认只展开核心层）；邻接采集不全（不支持 LLDP 的老设备要单独标记）；业务映射没人维护（改为从 CMDB 同步或按责任人分片）；只做展示不做联动（图与告警两套系统，投入产出比最差）。
六、常见问题（FAQ）
Q1：怎么用命令行确认一台设备支持 LLDP？
直接对该设备的 LLDP 远端表做一次 walk（OID1.0.8802.1.1.2.1.4.1）。如果返回空或超时，说明未开启或不支持。可以配合本端的lldpRemSysName判断对端是否也开了 LLDP——只有两端都开，才能形成一条完整的边。
Q2：拓扑图里的孤立节点怎么排查？
按三类原因分组：设备未开启邻居发现协议；邻居发现被 ACL 或安全策略阻断；设备本身不在业务转发路径上（仅管理面可达）。先按厂商分组统计孤立率，若某厂商整体偏高，问题在协议支持度上。
Q3：为什么建议存边集而不是直接存渲染好的图？
因为视图需求会变。存边集的话，渲染层可以自由组合出全量图、按机房过滤、按业务过滤等多种视图，且更新时只需 diff 边集，成本极低。存渲染好的图则每加一种视图都要重做数据。
Q4：告警落到图上，一定要改告警系统吗？
不一定。如果两边资产命名不一致，可以在中间加一层标识映射表，把告警里的设备名归一化成拓扑里的设备 ID。但这层映射表本身需要维护，长期看不如统一资产主数据省事。
Q5：怎么衡量可视化对 MTTR 的实际贡献？
拆成两个可测指标：定位时长（告警产生到确定故障点）、影响面确认时长（确定故障点到列出受影响业务）。分别对应拓扑关联与业务映射的收益。只看总体 MTTR 会被其他因素干扰，拆开看才能归因。
参考来源
- IETF RFC 2922——物理拓扑 MIB（PTOPO）
- IETF RFC 3418——SNMP MIB-II 管理信息库
- 厂商实现文档（仅作技术对照，非推荐）：OpManager 帮助文档
一句话总结
网络可视化的工程要点就三条：邻接关系用 LLDP／CDP 采、拓扑按边集存、告警靠共享资产标识落到节点上。再把影响关系（有方向的依赖）建模出来，六类视图才有意义。
如果这篇对你有帮助，欢迎点赞收藏。
