简介网络监控拓扑图是信息技术运维中的关键可视化工具这份资源将其整理为一份二十四页的专业文档面向网络管理员、运维工程师与网络架构学习者。内容系统梳理了物理拓扑、逻辑拓扑、层次拓扑、功能拓扑、混合拓扑、流量拓扑、虚拟化拓扑以及服务依赖性拓扑等常见类型并结合主流网络监控软件说明这些拓扑图如何在故障定位、性能优化、资源规划、安全审计与合规性检查中发挥实际作用。文档还涉及流量分布与虚拟化环境下的监控要点有助于读者理解设备、服务器与线路之间的连接关系提升网络排障和规划能力。资源为单个doc文档文件体积约2.61MB属于轻量级文档型资源适合按章节精读或作为工具手册查阅。目前已有七十人学习下载可作为日常运维和网络方案设计的参考。1. 网络监控拓扑图为什么先于监控系统落地如果只是给运维平台画几张展示用的大屏拓扑这件事不值得单独写。真正要紧的是在监控系统上线之前网络监控拓扑图就应该把节点、链路、冗余关系全部定下来因为告警聚合、影响范围分析、根因定位都依赖这张关系图而不是依赖设备 IP 列表。没有拓扑关系Zabbix、Prometheus 这类平台里再多的指标也只是散点一旦发生核心设备故障值班人员只能逐台点开设备看曲线效率会非常低。这里说的网络监控拓扑图最终通常还要沉淀成一份 .doc 或 .docx 文档供机房运维、交接人员和变更评审使用。也就是说它不是一次性示意图而是后续持续更新的基线。下面从拓扑分层、邻居信息采集、SNMP 自动更新到日常校验把最常见的落地路径完整走一遍。2. 网络监控拓扑图的类型与分层物理、逻辑与状态不能混画2.1 物理拓扑图端口、光纤和堆叠线缆要画到什么粒度物理拓扑图回答的是“网络是怎么连起来的”画的是交换机与交换机、交换机与路由器之间真实的接口连接关系。监控场景下不需要把每台服务器的网卡到 ToR 交换机的每一根网线都画出来但核心、汇聚、接入三层之间的互联端口必须标清楚。链路聚合、双上联、堆叠这些冗余设计是判断故障影响范围的核心依据物理图里如果漏掉一条链路监控告警分析时会直接判断成设备断连。物理拓扑里粒度要落到接口级。只画两台设备之间“连着”不够还得标出本端和对端的端口名比如“GE0/0/1 — GE0/0/2”这样在监控平台上查接口流量、查 up/down 告警时拓扑图和监控对象能一一对应。我一般不会在物理拓扑图上标 IP 和 VLAN这些信息属于逻辑层混在一起会让图面快速变乱也会让后续自动化维护变得更难。2.2 逻辑拓扑图VLAN、路由邻居与 VRF 如何进入监控视野逻辑拓扑图描述的是业务视角下的可达性关系。同一个 VLAN 内是二层互通两个核心之间跑 OSPF 或 BGP不同的业务系统分别走独立的 VRF这些都不受物理端口位置影响用物理图看不出来。监控系统在做告警关联时往往需要先判断“哪些业务在同一广播域、哪些路由域可能受影响”这时逻辑拓扑的价值就体现出来了。画逻辑层时节点通常代表子网、VRF 或路由实例边代表邻居关系或路由条目。举个例子两台汇聚路由器建立 OSPF 邻居物理图上要画出两台设备各自的上联端口和中间链路逻辑图上只需画一条标记为“OSPF area 0”的邻居边。注意最容易画错的是把二层接入交换机上的 trunk 口当成业务子网直接相连这样逻辑拓扑会和真实广播域不一致后续按图分析告警范围时容易误判。2.3 状态叠加层在关系图上叠加丢包、时延与接口 up/down真正用于监控大屏和值班判断的拓扑是在物理或逻辑关系之上叠加动态运行数据包括接口状态、丢包率、时延、带宽利用率。关系是相对固定的运行数据是分钟级变化的所以实现上应该把静态关系图和动态数据源解耦。静态关系存成一份文档或配置文件动态数据由监控系统定时拉取后渲染到对应边上两边通过设备名和接口名关联。这一层最常见的误区是信息过载。拓扑图不是性能大盘边上保留丢包率、时延、剩余带宽这些直接影响连通性判断的指标就够了日常内存和 CPU 指标放在主机监控页里。动态状态采集可以很简单用 ping 就能做最基础的链路状态探测关键在于持续性和数据落盘。2.3.1 用一个最小脚本为状态层准备基础数据# 对若干监控目标做连续 ping把平均时延写入 status.csv for target in 10.10.1.1 10.10.1.2 10.10.2.1; do avg$(ping -c 5 -W 1 $target | tail -1 | awk -F/ {print $5}) echo $target,$avg status.csv done这段脚本通过每轮 5 个探测包计算平均延迟awk -F/ {print $5}从rtt min/avg/max/mdev输出里取平均段。-W 1把超时设为 1 秒避免某个目标失效时整轮探测被拖住。如果某个目标完全不通tail -1取到的不是 rtt 行avg会是空值后续在拓扑图渲染层把空值显示为“不可达”即可。注意这只是状态层的数据来源之一完整场景还需要从 SNMP 采集接口流量。拓扑层关注对象数据来源更新频率主要用途物理层接口、链路、堆叠LLDP/CDP、端口配置变更时排障、端口定位逻辑层VLAN、VRF、路由邻居路由表、配置每日或变更时告警聚合、业务分析状态层up/down、时延、丢包ping、SNMP、流数据分钟级监控大屏、值班判断3. 从 LLDP/CDP 邻居数据生成拓扑图并导出 .doc 文档3.1 采集之前确认 LLDP 已开启并理解邻居表输出绘制物理拓扑最可靠的数据来源是链路层邻居协议思科设备上叫 CDP通用厂商基本支持 LLDP。相比 ping 探测LLDP 能直接给出对端设备主机名和接口名不需要知道 IP 地址段也不会因为防火墙策略造成误判。先到核心和汇聚交换机上确认 LLDP 处于开启状态再查看邻居表格式。# 进入交换机配置模式启用 LLDP以常见厂商命令为例 enable configure terminal lldp run interface range GigabitEthernet0/0/1-48 lldp transmit lldp receive end # 查看本设备通过 LLDP 发现的邻居 show lldp neighborslldp run是全局开关接口下的lldp transmit和lldp receive分别控制本端发送和接收。部分设备默认只开了一个方向未收到对端信息时优先检查这两个配置。show lldp neighbors输出可以整理为一张表记录本端设备名、本端端口、对端设备名、对端端口这四列数据就是后续拓扑图的全部连接信息。3.2 把邻居表转成 mermaid 格式拓扑图生成源文件拿到邻居表后常见做法是整理成 CSV然后通过脚本转成 mermaid 格式的文本。mermaid 的好处是纯文本可进 Git转换工具成熟配合 mermaid-cli 能直接渲染出 PNG适合再嵌入 Word 文档。# gen_topology.py # 读取 neighbors.csv生成 mermaid 图形描述文件 # CSV 表头: local_device, local_port, remote_device, remote_port import csv def load_neighbors(path): links [] nodes set() with open(path, newline, encodingutf-8) as f: for row in csv.DictReader(f): local row[local_device].strip() remote row[remote_device].strip() links.append((local, row[local_port].strip(), remote, row[remote_port].strip())) nodes.add(local) nodes.add(remote) return sorted(nodes), links def render_mermaid(nodes, links): # 先给每个节点分配一个纯数字安全 id设备名只出现在标签中 # 避免设备名中的连字符、空格或中文导致 mermaid 解析失败 node_id {name: fn{i} for i, name in enumerate(nodes)} lines [graph LR] for name, nid in node_id.items(): lines.append(f {nid}[{name}]) for local, lp, remote, rp in links: src, dst node_id[local], node_id[remote] lines.append(f {src} -- {lp} -- {rp} -- {dst}) return \n.join(lines) \n if __name__ __main__: nodes, links load_neighbors(neighbors.csv) with open(topology.mmd, w, encodingutf-8) as f: f.write(render_mermaid(nodes, links)) print(f输出完成: {len(nodes)} 个节点, {len(links)} 条链路)脚本先建立设备名到安全 id 的映射再输出节点和边。mermaid 对节点 id 的字符要求比标签严格如果直接用包含连字符的设备名作为 id渲染时可能报错这里用n0、n1这种索引做 id设备名放进[...]标签里是最稳妥的写法。边的标签“GE0/0/1 -- GE0/0/24”直观展示两端端口监控人员在图上就能对照设备端口确认链路。要调整展示层级就把graph LR改成graph TB方向从左右变为从上到下。3.3 渲染成图片并导出 .doc 文档的完整链路mermaid 文本生成后用 mermaid-cli 渲染成 PNG再用 pandoc 把 Markdown 报告连同图片转为 .docx这是目前最省事的导出路径。单位要求 .doc 格式的话Word 或 WPS 打开 .docx 后另存为 .doc 即可不必刻意追求二进制旧格式。# 安装并调用 mermaid-cli 渲染 PNG-b white 避免透明背景 npx -y mermaid-js/mermaid-cli -i topology.mmd -o topology.png -b white # 用 pandoc 把报告含图转成 .docx pandoc topology_report.md -o network_topology.docx-b white值得说明很多绘图工具默认输出透明背景直接嵌入 Word 后到了深色主题或打印场景会看不清强制白色背景是最少踩坑的做法。npx -y会在首次运行时自动拉取 mermaid-cli需要本机有 Node.js如果公司内网不允许可以改用 draw.io Desktop 打开 .mmd 再手动导出 PNG但这样会失去命令行自动化能力。pandoc 转换时也会自动解析 Markdown 里的图片路径让图片随文档一起打包。验证项检查方法通过标准节点完整性show lldp neighbors的设备数 vs 图上节点数二者一致链路方向在设备上show lldp neighbors detail抽查关键链路两端端口能对上文档可打开用 Word/WPS 打开导出的 .docx图片显示、无乱码版本可追溯给图片文件名加日期或 commit 号能定位到采集时间4. 自动更新网络监控拓扑图SNMP 轮询、定时任务与变更同步4.1 静态图形文档的最大风险是上次变更后已失真手工采集 neighbors.csv 再生成拓扑适合一次性交付但真实网络里每周都会有设备上下线、接口调整、链路扩容。静态图过了两三个月就和实际对不上了监控值班人员照着图去核对告警时越看越疑惑最终的归宿是废弃。所以网络监控拓扑图在一开始就应该按自动化来设计而不是按静态文档来设计。自动化有两层意思一层是每台设备的邻居数据通过 SNMP 自动采集另一层是采集完成后自动执行拓扑生成和文档导出。数据采集是源头源头的自动化解决了后面都是脚本拼接的问题。SNMP 采集相比 SSH 登录采集更轻量不需要在交换机上配置账号且轮询逻辑在监控平台里本身就是成熟模式。4.2 用 snmpwalk 自动采集 LLDP MIB 数据LLDP 信息在标准 LLDP-MIB 里有定义Net-SNMP 的 snmpwalk 可以直接读取。周期性对全网交换机执行轮询把结果落盘即可拿到想要的邻居信息。#!/bin/bash # lldp_snmp_scan.sh # 对交换机列表逐个执行 SNMP 轮询抓取 LLDP 邻居信息并落盘 COMMUNITYpublic VERSION2c OUT_DIR./lldp_raw mkdir -p $OUT_DIR for ip in $(cat switches.txt); do # 每个交换机输出一个独立文件文件名用 IP 标识 snmpwalk -v$VERSION -c $COMMUNITY -On $ip \ LLDP-MIB::lldpRemSysName $OUT_DIR/$ip.lldp 2/dev/null doneswitches.txt里每行写一个交换机管理 IP-On让输出显示完整数字 OID方便解析索引。LLDP-MIB::lldpRemSysName返回对端设备名2/dev/null 丢弃超时和认证失败等噪音输出。采集完成后每个文件的每一行都会带上一个形如“时间标记.本地端口号.对端索引”的尾部索引中间的本地端口号就是链路在本机的出接口编号解析时把它提取出来。OID数字表示MIB 对象含义在拓扑中的用途.1.0.8802.1.1.2.1.4.1.1.5lldpRemPortId对端端口标识生成边标签.1.0.8802.1.1.2.1.4.1.1.6lldpRemPortDesc对端端口描述人工核对.1.0.8802.1.1.2.1.4.1.1.9lldpRemSysName对端设备名识别节点.1.0.8802.1.1.2.1.4.1.1.10lldpRemSysDesc对端设备型号区分设备角色4.3 把采集、解析、制图与文档导出串成一条定时链路snmpwalk 落盘的是原始文本需要解析出“本地设备、本地端口、对端设备、对端端口”四个字段再复用第 3 章的生成脚本。解析时通过正则把每行 OID 末尾的三个索引数字分离中间的本地端口号用来关联本机接口名。# 解析全部 lldp 原始文件生成邻居 CSV python3 parse_lldp.py ./lldp_raw/*.lldp neighbors.csv # 由邻居 CSV 更新 mermaid 源文件再渲染成 PNG python3 gen_topology.py npx -y mermaid-js/mermaid-cli -i topology.mmd -o topology.png -b white # 生成最终 .docx 监控拓扑文档 pandoc topology_report.md -o network_topology.docxparse_lldp.py中我常用的解析思路是对每行snmpwalk输出做正则匹配形如.*\.(\d)\.(\d)\.(\d) STRING: ?([^]*)?第一组数字是时间标记第二组是本地端口号第三组是对端索引最后是对端系统名。三个数字从行尾反向提取最稳定因为 MIB 树前缀再长也不影响索引区。这样一个交换机一个文件全量重跑后 CSV 自然只保留当前存活的邻居下线的链路自动消失不需要额外做增量比对。提示如果 snmpwalk 输出了数据但对端名为空先检查交换机的 community 是否具备只读权限再检查LLDP-MIB是否被某些厂商私有用 MIB 遮蔽。多数情况下把lldpRemSysName换成对应厂商的私有 OID 就能拿到完整数据。最后用 crontab 把整条流水线定时执行例如每天凌晨 2 点 30 分跑一次并给导出的文档加上日期后缀便于历史追溯。30 2 * * * cd /opt/monitor ./lldp_snmp_scan.sh \ python3 parse_lldp.py ./lldp_raw/*.lldp neighbors.csv \ python3 gen_topology.py \ npx -y mermaid-js/mermaid-cli -i topology.mmd -o topology_$(date \%Y\%m\%d).png -b whitecrontab 里%需要转义为\%否则会被 crontab 当成换行符处理这是最容易忽略的细节。整个链路没有人工介入每天早上打开文档目录就能看到昨日最新状态。如果监控平台已经有完整资产数据库也可以不跑 SNMP 轮询改为直接查询 CMDB 接口导出邻居关系链路结构完全一致只是数据源变了。5. 网络监控拓扑图维护中常见的误区和三个快速校验技巧5.1 节点超过 50 就拆图不要追求一张图塞满很多网络拓扑图的问题是节点太多链路交叉重叠最终谁都不愿意看。以我的经验单张物理拓扑图节点控制在 50 个以内多出的设备按区域或业务线拆成子图在 .doc 文档里按章节组织比一张巨型图更实用。监控大屏展示核心层和汇聚层节点接入设备折叠进对应汇聚节点的展开视图人员定位故障时路径短也更容易自动化生成。5.2 用 LLDP 原始数据校验静态图是否漂移校验静态拓扑图是否过期的技术手段是对比两次采集的 lldp 文本。把上一次采集的 lldp_raw 目录和最新的做一次 diff新增行说明多了新链路消失行说明链路已被拆除。只跑一次 diff 就能找出哪些设备标识尚未维护。# 对比两个时刻的 LLDP 采集结果快速识别链路变化 diff (sort lldp_raw/before.lldp) (sort lldp_raw/after.lldp) | head -205.3 变更窗口后把重新生成文档当成发布动作每次网络变更操作后在变更单里附带新增一条重新生成拓扑的产物清单包括当晚重新跑采集、重新生成 PNG、替换 .doc 附件、提交到文档库。只有把文档更新绑定到变更流程里拓扑图才可能长期存活而不是靠某个人定期想起来手动改一遍。本文还有配套的精品资源点击获取 网络监控拓扑图自动生成与维护：从LLDP到SNMP的实践
简介网络监控拓扑图是信息技术运维中的关键可视化工具这份资源将其整理为一份二十四页的专业文档面向网络管理员、运维工程师与网络架构学习者。内容系统梳理了物理拓扑、逻辑拓扑、层次拓扑、功能拓扑、混合拓扑、流量拓扑、虚拟化拓扑以及服务依赖性拓扑等常见类型并结合主流网络监控软件说明这些拓扑图如何在故障定位、性能优化、资源规划、安全审计与合规性检查中发挥实际作用。文档还涉及流量分布与虚拟化环境下的监控要点有助于读者理解设备、服务器与线路之间的连接关系提升网络排障和规划能力。资源为单个doc文档文件体积约2.61MB属于轻量级文档型资源适合按章节精读或作为工具手册查阅。目前已有七十人学习下载可作为日常运维和网络方案设计的参考。1. 网络监控拓扑图为什么先于监控系统落地如果只是给运维平台画几张展示用的大屏拓扑这件事不值得单独写。真正要紧的是在监控系统上线之前网络监控拓扑图就应该把节点、链路、冗余关系全部定下来因为告警聚合、影响范围分析、根因定位都依赖这张关系图而不是依赖设备 IP 列表。没有拓扑关系Zabbix、Prometheus 这类平台里再多的指标也只是散点一旦发生核心设备故障值班人员只能逐台点开设备看曲线效率会非常低。这里说的网络监控拓扑图最终通常还要沉淀成一份 .doc 或 .docx 文档供机房运维、交接人员和变更评审使用。也就是说它不是一次性示意图而是后续持续更新的基线。下面从拓扑分层、邻居信息采集、SNMP 自动更新到日常校验把最常见的落地路径完整走一遍。2. 网络监控拓扑图的类型与分层物理、逻辑与状态不能混画2.1 物理拓扑图端口、光纤和堆叠线缆要画到什么粒度物理拓扑图回答的是“网络是怎么连起来的”画的是交换机与交换机、交换机与路由器之间真实的接口连接关系。监控场景下不需要把每台服务器的网卡到 ToR 交换机的每一根网线都画出来但核心、汇聚、接入三层之间的互联端口必须标清楚。链路聚合、双上联、堆叠这些冗余设计是判断故障影响范围的核心依据物理图里如果漏掉一条链路监控告警分析时会直接判断成设备断连。物理拓扑里粒度要落到接口级。只画两台设备之间“连着”不够还得标出本端和对端的端口名比如“GE0/0/1 — GE0/0/2”这样在监控平台上查接口流量、查 up/down 告警时拓扑图和监控对象能一一对应。我一般不会在物理拓扑图上标 IP 和 VLAN这些信息属于逻辑层混在一起会让图面快速变乱也会让后续自动化维护变得更难。2.2 逻辑拓扑图VLAN、路由邻居与 VRF 如何进入监控视野逻辑拓扑图描述的是业务视角下的可达性关系。同一个 VLAN 内是二层互通两个核心之间跑 OSPF 或 BGP不同的业务系统分别走独立的 VRF这些都不受物理端口位置影响用物理图看不出来。监控系统在做告警关联时往往需要先判断“哪些业务在同一广播域、哪些路由域可能受影响”这时逻辑拓扑的价值就体现出来了。画逻辑层时节点通常代表子网、VRF 或路由实例边代表邻居关系或路由条目。举个例子两台汇聚路由器建立 OSPF 邻居物理图上要画出两台设备各自的上联端口和中间链路逻辑图上只需画一条标记为“OSPF area 0”的邻居边。注意最容易画错的是把二层接入交换机上的 trunk 口当成业务子网直接相连这样逻辑拓扑会和真实广播域不一致后续按图分析告警范围时容易误判。2.3 状态叠加层在关系图上叠加丢包、时延与接口 up/down真正用于监控大屏和值班判断的拓扑是在物理或逻辑关系之上叠加动态运行数据包括接口状态、丢包率、时延、带宽利用率。关系是相对固定的运行数据是分钟级变化的所以实现上应该把静态关系图和动态数据源解耦。静态关系存成一份文档或配置文件动态数据由监控系统定时拉取后渲染到对应边上两边通过设备名和接口名关联。这一层最常见的误区是信息过载。拓扑图不是性能大盘边上保留丢包率、时延、剩余带宽这些直接影响连通性判断的指标就够了日常内存和 CPU 指标放在主机监控页里。动态状态采集可以很简单用 ping 就能做最基础的链路状态探测关键在于持续性和数据落盘。2.3.1 用一个最小脚本为状态层准备基础数据# 对若干监控目标做连续 ping把平均时延写入 status.csv for target in 10.10.1.1 10.10.1.2 10.10.2.1; do avg$(ping -c 5 -W 1 $target | tail -1 | awk -F/ {print $5}) echo $target,$avg status.csv done这段脚本通过每轮 5 个探测包计算平均延迟awk -F/ {print $5}从rtt min/avg/max/mdev输出里取平均段。-W 1把超时设为 1 秒避免某个目标失效时整轮探测被拖住。如果某个目标完全不通tail -1取到的不是 rtt 行avg会是空值后续在拓扑图渲染层把空值显示为“不可达”即可。注意这只是状态层的数据来源之一完整场景还需要从 SNMP 采集接口流量。拓扑层关注对象数据来源更新频率主要用途物理层接口、链路、堆叠LLDP/CDP、端口配置变更时排障、端口定位逻辑层VLAN、VRF、路由邻居路由表、配置每日或变更时告警聚合、业务分析状态层up/down、时延、丢包ping、SNMP、流数据分钟级监控大屏、值班判断3. 从 LLDP/CDP 邻居数据生成拓扑图并导出 .doc 文档3.1 采集之前确认 LLDP 已开启并理解邻居表输出绘制物理拓扑最可靠的数据来源是链路层邻居协议思科设备上叫 CDP通用厂商基本支持 LLDP。相比 ping 探测LLDP 能直接给出对端设备主机名和接口名不需要知道 IP 地址段也不会因为防火墙策略造成误判。先到核心和汇聚交换机上确认 LLDP 处于开启状态再查看邻居表格式。# 进入交换机配置模式启用 LLDP以常见厂商命令为例 enable configure terminal lldp run interface range GigabitEthernet0/0/1-48 lldp transmit lldp receive end # 查看本设备通过 LLDP 发现的邻居 show lldp neighborslldp run是全局开关接口下的lldp transmit和lldp receive分别控制本端发送和接收。部分设备默认只开了一个方向未收到对端信息时优先检查这两个配置。show lldp neighbors输出可以整理为一张表记录本端设备名、本端端口、对端设备名、对端端口这四列数据就是后续拓扑图的全部连接信息。3.2 把邻居表转成 mermaid 格式拓扑图生成源文件拿到邻居表后常见做法是整理成 CSV然后通过脚本转成 mermaid 格式的文本。mermaid 的好处是纯文本可进 Git转换工具成熟配合 mermaid-cli 能直接渲染出 PNG适合再嵌入 Word 文档。# gen_topology.py # 读取 neighbors.csv生成 mermaid 图形描述文件 # CSV 表头: local_device, local_port, remote_device, remote_port import csv def load_neighbors(path): links [] nodes set() with open(path, newline, encodingutf-8) as f: for row in csv.DictReader(f): local row[local_device].strip() remote row[remote_device].strip() links.append((local, row[local_port].strip(), remote, row[remote_port].strip())) nodes.add(local) nodes.add(remote) return sorted(nodes), links def render_mermaid(nodes, links): # 先给每个节点分配一个纯数字安全 id设备名只出现在标签中 # 避免设备名中的连字符、空格或中文导致 mermaid 解析失败 node_id {name: fn{i} for i, name in enumerate(nodes)} lines [graph LR] for name, nid in node_id.items(): lines.append(f {nid}[{name}]) for local, lp, remote, rp in links: src, dst node_id[local], node_id[remote] lines.append(f {src} -- {lp} -- {rp} -- {dst}) return \n.join(lines) \n if __name__ __main__: nodes, links load_neighbors(neighbors.csv) with open(topology.mmd, w, encodingutf-8) as f: f.write(render_mermaid(nodes, links)) print(f输出完成: {len(nodes)} 个节点, {len(links)} 条链路)脚本先建立设备名到安全 id 的映射再输出节点和边。mermaid 对节点 id 的字符要求比标签严格如果直接用包含连字符的设备名作为 id渲染时可能报错这里用n0、n1这种索引做 id设备名放进[...]标签里是最稳妥的写法。边的标签“GE0/0/1 -- GE0/0/24”直观展示两端端口监控人员在图上就能对照设备端口确认链路。要调整展示层级就把graph LR改成graph TB方向从左右变为从上到下。3.3 渲染成图片并导出 .doc 文档的完整链路mermaid 文本生成后用 mermaid-cli 渲染成 PNG再用 pandoc 把 Markdown 报告连同图片转为 .docx这是目前最省事的导出路径。单位要求 .doc 格式的话Word 或 WPS 打开 .docx 后另存为 .doc 即可不必刻意追求二进制旧格式。# 安装并调用 mermaid-cli 渲染 PNG-b white 避免透明背景 npx -y mermaid-js/mermaid-cli -i topology.mmd -o topology.png -b white # 用 pandoc 把报告含图转成 .docx pandoc topology_report.md -o network_topology.docx-b white值得说明很多绘图工具默认输出透明背景直接嵌入 Word 后到了深色主题或打印场景会看不清强制白色背景是最少踩坑的做法。npx -y会在首次运行时自动拉取 mermaid-cli需要本机有 Node.js如果公司内网不允许可以改用 draw.io Desktop 打开 .mmd 再手动导出 PNG但这样会失去命令行自动化能力。pandoc 转换时也会自动解析 Markdown 里的图片路径让图片随文档一起打包。验证项检查方法通过标准节点完整性show lldp neighbors的设备数 vs 图上节点数二者一致链路方向在设备上show lldp neighbors detail抽查关键链路两端端口能对上文档可打开用 Word/WPS 打开导出的 .docx图片显示、无乱码版本可追溯给图片文件名加日期或 commit 号能定位到采集时间4. 自动更新网络监控拓扑图SNMP 轮询、定时任务与变更同步4.1 静态图形文档的最大风险是上次变更后已失真手工采集 neighbors.csv 再生成拓扑适合一次性交付但真实网络里每周都会有设备上下线、接口调整、链路扩容。静态图过了两三个月就和实际对不上了监控值班人员照着图去核对告警时越看越疑惑最终的归宿是废弃。所以网络监控拓扑图在一开始就应该按自动化来设计而不是按静态文档来设计。自动化有两层意思一层是每台设备的邻居数据通过 SNMP 自动采集另一层是采集完成后自动执行拓扑生成和文档导出。数据采集是源头源头的自动化解决了后面都是脚本拼接的问题。SNMP 采集相比 SSH 登录采集更轻量不需要在交换机上配置账号且轮询逻辑在监控平台里本身就是成熟模式。4.2 用 snmpwalk 自动采集 LLDP MIB 数据LLDP 信息在标准 LLDP-MIB 里有定义Net-SNMP 的 snmpwalk 可以直接读取。周期性对全网交换机执行轮询把结果落盘即可拿到想要的邻居信息。#!/bin/bash # lldp_snmp_scan.sh # 对交换机列表逐个执行 SNMP 轮询抓取 LLDP 邻居信息并落盘 COMMUNITYpublic VERSION2c OUT_DIR./lldp_raw mkdir -p $OUT_DIR for ip in $(cat switches.txt); do # 每个交换机输出一个独立文件文件名用 IP 标识 snmpwalk -v$VERSION -c $COMMUNITY -On $ip \ LLDP-MIB::lldpRemSysName $OUT_DIR/$ip.lldp 2/dev/null doneswitches.txt里每行写一个交换机管理 IP-On让输出显示完整数字 OID方便解析索引。LLDP-MIB::lldpRemSysName返回对端设备名2/dev/null 丢弃超时和认证失败等噪音输出。采集完成后每个文件的每一行都会带上一个形如“时间标记.本地端口号.对端索引”的尾部索引中间的本地端口号就是链路在本机的出接口编号解析时把它提取出来。OID数字表示MIB 对象含义在拓扑中的用途.1.0.8802.1.1.2.1.4.1.1.5lldpRemPortId对端端口标识生成边标签.1.0.8802.1.1.2.1.4.1.1.6lldpRemPortDesc对端端口描述人工核对.1.0.8802.1.1.2.1.4.1.1.9lldpRemSysName对端设备名识别节点.1.0.8802.1.1.2.1.4.1.1.10lldpRemSysDesc对端设备型号区分设备角色4.3 把采集、解析、制图与文档导出串成一条定时链路snmpwalk 落盘的是原始文本需要解析出“本地设备、本地端口、对端设备、对端端口”四个字段再复用第 3 章的生成脚本。解析时通过正则把每行 OID 末尾的三个索引数字分离中间的本地端口号用来关联本机接口名。# 解析全部 lldp 原始文件生成邻居 CSV python3 parse_lldp.py ./lldp_raw/*.lldp neighbors.csv # 由邻居 CSV 更新 mermaid 源文件再渲染成 PNG python3 gen_topology.py npx -y mermaid-js/mermaid-cli -i topology.mmd -o topology.png -b white # 生成最终 .docx 监控拓扑文档 pandoc topology_report.md -o network_topology.docxparse_lldp.py中我常用的解析思路是对每行snmpwalk输出做正则匹配形如.*\.(\d)\.(\d)\.(\d) STRING: ?([^]*)?第一组数字是时间标记第二组是本地端口号第三组是对端索引最后是对端系统名。三个数字从行尾反向提取最稳定因为 MIB 树前缀再长也不影响索引区。这样一个交换机一个文件全量重跑后 CSV 自然只保留当前存活的邻居下线的链路自动消失不需要额外做增量比对。提示如果 snmpwalk 输出了数据但对端名为空先检查交换机的 community 是否具备只读权限再检查LLDP-MIB是否被某些厂商私有用 MIB 遮蔽。多数情况下把lldpRemSysName换成对应厂商的私有 OID 就能拿到完整数据。最后用 crontab 把整条流水线定时执行例如每天凌晨 2 点 30 分跑一次并给导出的文档加上日期后缀便于历史追溯。30 2 * * * cd /opt/monitor ./lldp_snmp_scan.sh \ python3 parse_lldp.py ./lldp_raw/*.lldp neighbors.csv \ python3 gen_topology.py \ npx -y mermaid-js/mermaid-cli -i topology.mmd -o topology_$(date \%Y\%m\%d).png -b whitecrontab 里%需要转义为\%否则会被 crontab 当成换行符处理这是最容易忽略的细节。整个链路没有人工介入每天早上打开文档目录就能看到昨日最新状态。如果监控平台已经有完整资产数据库也可以不跑 SNMP 轮询改为直接查询 CMDB 接口导出邻居关系链路结构完全一致只是数据源变了。5. 网络监控拓扑图维护中常见的误区和三个快速校验技巧5.1 节点超过 50 就拆图不要追求一张图塞满很多网络拓扑图的问题是节点太多链路交叉重叠最终谁都不愿意看。以我的经验单张物理拓扑图节点控制在 50 个以内多出的设备按区域或业务线拆成子图在 .doc 文档里按章节组织比一张巨型图更实用。监控大屏展示核心层和汇聚层节点接入设备折叠进对应汇聚节点的展开视图人员定位故障时路径短也更容易自动化生成。5.2 用 LLDP 原始数据校验静态图是否漂移校验静态拓扑图是否过期的技术手段是对比两次采集的 lldp 文本。把上一次采集的 lldp_raw 目录和最新的做一次 diff新增行说明多了新链路消失行说明链路已被拆除。只跑一次 diff 就能找出哪些设备标识尚未维护。# 对比两个时刻的 LLDP 采集结果快速识别链路变化 diff (sort lldp_raw/before.lldp) (sort lldp_raw/after.lldp) | head -205.3 变更窗口后把重新生成文档当成发布动作每次网络变更操作后在变更单里附带新增一条重新生成拓扑的产物清单包括当晚重新跑采集、重新生成 PNG、替换 .doc 附件、提交到文档库。只有把文档更新绑定到变更流程里拓扑图才可能长期存活而不是靠某个人定期想起来手动改一遍。本文还有配套的精品资源点击获取