第一次在GitHub上翻到OpenMontage这个项目是当时手头正压着一个挺头疼的活整理某园区网两百多台设备的资产台账和链路关系。传统方式就是用Excel一张张登记IP、型号、位置、上联设备再拿Visio手工画拓扑。两三个人忙了一周画出来的图还跟实际网络对不上。后来我试着把OpenMontage部署起来用SNMP自动扫了一遍资产清单和分层拓扑图基本是自动生成的那张手工画了一周的图我再也没更新过。OpenMontage本质上是一个基于Django的开源网络运维辅助系统帮你把“机房和网络里到底有什么设备、它们之间怎么连、当前状态如何”这三个问题一次性回答掉。它能做的不是像Zabbix那样盯着性能指标做告警也不是像SolarWinds那样重型的商业NPM平台而是落在两者之间自动发现网络设备、录入资产信息、绘制拓扑图、生成健康度报告。对做网络运维、弱电项目交付、数据中心管理的人来说这个定位非常实用。这篇算是我从部署、配置、踩坑到二次开发的完整使用笔记尽量把我实际遇到的细节都写出来。1. OpenMontage是什么它和传统监控系统到底有什么不一样1.1 一个“轻量但全能”的IT资产可视化入口很多人第一次看到OpenMontage的界面会下意识拿它跟Zabbix、Nagios比觉得功能不够“监控”。这种对比其实方向不太对。OpenMontage更像是一个“带监控能力的网络资产管理系统”它的核心逻辑是先把你网络里的设备找全再说监控的事而不是反过来。我用一个实际场景解释。传统监控系统的逻辑是你先手工录入每台设备的IP、端口、监控模板它才肯开始采集数据。设备一多录入本身就是灾难。OpenMontage的思路是给你一个网段它自己用SNMP、ICMP去发现设备然后主动采集每台设备的系统信息、接口信息、型号、位置描述再把这些数据整理成统一的资产台账。它内部有Django自带的管理后台所有设备、报告、拓扑都能在一个Web界面上查看和导出。从技术实现上看OpenMontage使用了Django框架数据层默认支持SQLite和MySQL采集任务靠Python的SNMP库和ICMP探测完成。前端展示部分用SVG绘制网络拓扑报告可以用HTML方式打开也能导出Excel和PDF格式。这样一套组合装下来部署成本很低最适合那种“我需要快速摸清网络家底”的运维场景。1.2 最适合用OpenMontage的几类场景结合我的实际使用体验它不是拿来替代现有监控体系的而是恰好补齐了几个空白项目交付和网络验收弱电工程收尾时需要给甲方提供一份完整的设备清单和拓扑图OpenMontage扫一遍就能导出来做验收材料特别省事。老网络资产梳理很多单位网络经过多年迭代设备台账早就乱了。用OpenMontage对新老网段做一次自动发现几分钟就能比对手工记录找出差异。中小规模日常巡检几十到几百台设备的量级专门上SolarWinds太贵Zabbix配置又太重。OpenMontage提供的基础健康度检查、接口状态、连通性检测正好够用。数据中心机房的链路可视化管理配合LLDP/CDP邻居信息它能自动画出设备之间的物理链路不用再爬进桥架里对着标签猜线。我并不是说OpenMontage一定比Zabbix优秀。真实体会是它的定位更聚焦在“从网络里自动长出资产和链路信息”这件事上而这恰恰是传统监控系统最不擅长、最费人工的环节。2. 部署落地从零到能扫出全网设备的完整过程2.1 环境准备Python、数据库和系统选择OpenMontage是Python项目基于Django框架开发部署环境不算挑Linux和Windows都能跑。我自己是在CentOS 7和Ubuntu 20.04上都部署过对比下来Ubuntu更省心一点主要原因是Python环境干净OpenSSL和编译工具链都齐全。数据库方面默认用SQLite就能启动但如果你要管理上千台设备建议直接上MySQL。要注意的是OpenMontage在初始化数据库时依赖Django的ORM建表如果原本库里有同名旧表migration容易报冲突最好是给这个系统单独建一个库和一个专用账号不要跟其他业务系统共用。字符集一定选utf8mb4否则设备描述里带中文或特殊符号时采集数据入库会直接报错。Python版本我建议用3.6到3.9之间依赖库和Django版本对这个区间兼容性最好。太新的Python版本容易让个别依赖包编译失败反而给自己添麻烦。2.2 安装和初始化步骤安装流程整体不复杂核心步骤如下git clone https://github.com/OpenMontage/OpenMontage.git cd OpenMontage pip install -r requirements.txt cp settings.example.py settings.py配置文件里重点修改三处数据库连接信息、ALLOWED_HOSTS、时区。时区一定要改成Asia/Shanghai默认UTC导致报告时间比北京时间慢8小时我第一次没注意生成的报告时间全不对排查了半天才发现是这个问题。配置改完之后执行数据库初始化和启动python manage.py migrate python manage.py createsuperuser python manage.py runserver 0.0.0.0:8000启动成功后浏览器访问http://服务器IP:8000用刚才创建的超级管理员账号登录进入管理后台接下去就可以开始配置扫描任务了。2.3 第一个坑管理后台登录后页面空白我第一次部署完登录后台后页面白屏浏览器控制台报了一堆JS加载错误。排查半天发现是静态文件没有收集。Django生产模式需要执行python manage.py collectstatic把项目里的静态资源统一拷贝到STATIC_ROOT指定目录。测试环境里如果改了DEBUG配置也要重新执行一次否则CSS和JS文件全部指向不存在的路径。还有一个容易踩的权限问题OpenMontage的定时扫描任务如果通过crontab调度脚本执行时会以系统普通用户身份运行而Web服务可能是root起的两者对SQLite文件或日志目录的写权限不一样。最典型的表现就是Web端手动扫描正常但定时任务一跑就报数据库锁或权限拒绝。解决方法是统一启动用户或者把日志和数据库文件的属主改成运行cron的用户。3. 设备发现与拓扑绘制的核心原理SNMP和邻居协议的双轮驱动3.1 SNMP发现真正的资产采集手段网络里ping一通的在线设备只是最基本的发现动作。想拿到设备名称、型号、操作系统、接口信息这些管理数据靠的是SNMP协议。OpenMontage的发现机制默认会尝试用SNMP v2c的公共团体串通常是public去读取设备的几个核心OID比如系统描述和接口表。我的实践体会是扫描参数直接决定资产数据质量。SNMP超时时间默认比较保守在跨三层设备扫描时路由器或核心交换机的响应可能超过500毫秒如果超时设置太短很多设备会被误判为SNMP不可达。并发数也要控制我曾把并发调到50去扫一个千兆核心下的汇聚交换机结果部分老设备CPU直接飙高SNMP响应反而变慢。后来稳定在20并发每个OID查询间隔50毫秒效果最好。SNMP团体串是发现能否成功的关键。很多历史遗留设备的团体串仍然是public但如果设备改过团体串需要在OpenMontage里提前配置对应的团体串列表。它虽然支持多个团体串但我建议还是先用一个统一的团体串把全网基础信息扫出来再对特殊设备单独调整这样排查问题更容易。3.2 LLDP和CDP邻居信息拓扑图为什么能画得准拓扑图不是靠猜的它是读取设备的邻居表拼出来的。大多数可网管交换机支持LLDP思科设备还支持CDPOpenMontage通过SNMP读取这些协议的邻居信息比如lldpRemTable或cdpCacheTable能知道当前设备哪个端口连着对端设备的哪个端口。把所有设备采集到的邻居关系合并就是一张完整的物理链路图。这里的逻辑有点像拼图每一台设备只告诉系统它自己这个端口跟谁是邻居OpenMontage把全网设备的邻居条目汇总起来就能按设备之间发现出一条条边。如果某台设备不支持LLDP/CDP那它连接到核心的这段链路就是断的拓扑图上会出现一个孤立节点。这种情况下就得靠配置里的手工链路补充功能把缺失的连线补上。拓扑图的横纵布局用的是分层算法自动根据设备层级关系分配到画布不同位置。生成的是SVG图形好处是放大不失真浏览器直接打开后还能点选节点查看设备详情。我实际用下来的建议是自动布局能用但设备超过300台时SVG的节点排布会比较密建议导出后再按业务区域整理一份。3.3 关键配置项网段扫描、发现深度和隐身设备网段扫描配置有几个参数需要理解透不是设置完就万事大吉网段和掩码定义了扫描范围。建议按实际VLAN划分来建比如一个扫描任务对应一个办公网段另一个对应服务器网段避免把无用网段也扫进去。发现深度控制递归发现层数。正常情况下设为2-3层足够从核心到接入通常不超过3层。设得过深会耗费大量时间在SNMP轮询上而且容易扫到跨网段的安全设备。端口探测不是所有设备都会在第一时间响应ICMP比如禁ping的Windows服务器。建议把TCP端口探测加上对22、80、443、3389这类常用端口做轻量探测能够识别出部分SNMP不可达但端口开放的设备。我自己在扫一个隔离网段时发现一台核心设备始终没有出现在拓扑里排查后发现是有ACL规则过滤了来自采集服务器的SNMP请求。这类“隐身设备”靠工具本身是扫不出来的只能定期对比交换机ARP表和扫描结果来发现。这也是自动化资产梳理始终需要人工复核一点的原因。4. 从监控数据到报告OpenMontage输出物的使用心得4.1 健康度报告重点看哪些指标OpenMontage采集完设备后会生成一份综合健康度报告。报告不是简单罗列ONLINE/OFFLINE状态而是把每台设备的SNMP可达性、接口状态、CPU内存负载如果设备支持综合起来打分。这个分数不能完全等同于设备真实健康度因为部分简单设备不支持读取性能OID它只能判定“在线且可管理”而无法覆盖设备深层故障。我的经验是重点看三个维度接口错误包增长趋势、设备掉线历史记录、拓扑中节点的可管理状态变化。前两个直接反映链路质量和设备稳定性。相比之下单纯在线状态的意义有限因为一台设备在线不代表网络质量没问题入口方向丢包严重时SNMP轮询照样可能超时。报告支持导出Excel和PDF。我实际给别人交付项目时更多采用Excel格式导出资产清单因为甲方通常要拿去做二次筛选和补充。PDF格式更适合给领导做汇报打印出来也比较正式。4.2 拓扑图的迭代更新机制OpenMontage不会在每次扫描后立即覆盖原有拓扑图而是根据配置的扫描周期频繁更新节点状态和链路关系。新发现的设备会被自动添加上去失联设备会标记为异常而不是直接删除。这个设计我觉得很合理网络运维里设备临时离线太常见直接删除会造成历史记录断裂标记异常反而能追溯从什么时候开始不稳定的。拓扑图还有一个容易被忽略的价值就是链路变更审计。网络团队调整过接线后自动生成的拓扑里链路关系会和之前版本不同。对比两次扫描的拓扑差异可以在没有一个字变更记录的情况下还原出什么时候发生了什么链路变化。对于没有CMDB的小团队这个功能等于白送了一套变更溯源能力。4.3 把报告接入自己的巡检流程报告生成以后不要只丢在服务器上隔几天手动看一次。我把它做进了日常巡检流程里每天自动扫描结束后导出当天的资产在线率汇总对比前一天数据每周导出一次完整资产清单做差异比对每月导出一份PDF健康度报告归档。这样虽然没做什么复杂开发但巡检记录一下子规范了很多被问到“这个月网络稳定吗”的时候手头随时有数据可以回答。5. 我踩过的几个坑完整的排查链路和修复方案5.1 SNMP超时导致设备状态误报第一次部署完我设置了一个覆盖全网的扫描任务结果报告里显示有二十几台设备离线。我以为是网络故障跑到机房逐个看发现设备都正常运行。当时挺困惑回到服务器手动snmpwalk其中一台设备IP却发现能正常读到数据。排查过程是这样的先看采集日志发现这些设备在扫描时SNMP响应超时再对比配置发现我把SNMP超时设成了300毫秒然后手动用300毫秒超时去请求这两台设备果然超时。原因是核心层到接入层区隔了三层路由加上部分设备在认证后响应较慢正常响应时间就要600毫秒左右。最终我把超时调整到1500毫秒重试次数从1次改成2次重新扫描后再也没有误报。这个坑提醒我扫描参数必须基于现场网络延迟特征来调整不能直接照抄默认值。5.2 拓扑图上出现奇怪的跨网段连线拓扑图生成后我发现有几台设备之间连着一条完全说不通的链路比如数据中心的一台存储交换机跟办公楼的一台接入交换机显示直连。按物理网络规划这俩根本不可能直接相连。我一开始怀疑LLDP数据解析错误后来逐台设备检查邻居表发现交换机上有一个三层VLAN接口系统把VLAN接口当作物理链路参与了拓扑拼接。OpenMontage对接口类型的判断依赖SNMP的ifType字段如果设备接口表里没有正确标识物理口和VLAN口就会发生跨网段连线的错误。解决办法有两个方向一是扫描完成后在设备详情里把VLAN接口标记为“非物理接口”系统就不会再拿它生成链路二是检查交换机是否启用了CDP/LLDP over VLAN有些情况下VLAN接口本身确实会通告邻居消息。手动修正一次后后续扫描会继承修改结果不会每次都被覆盖。5.3 定时任务形同虚设cron环境变量问题我还遇到过OpenMontage定时扫描任务完全不工作的情况。Web界面上手动点扫描是好的但cron日志里只记录了任务开始然后就没有任何后续输出。折腾了一两个小时才发现本质上是cron执行时缺少Python虚拟环境的PATH和LD_LIBRARY_PATH导致采集脚本实际运行时报导入库失败但错误被系统日志吞掉了。排查链路的最后一个关键环节是我在crontab里加了完整的环境变量定义后才恢复0 2 * * * source /opt/venv/bin/activate cd /opt/OpenMontage python manage.py scan --all /var/log/openmontage/scan.log 21cron环境和交互式shell环境完全不同这个问题在Django类项目里太常见了。我后来给自己定了个规矩所有定时任务脚本脚本第一行先加载虚拟环境所有日志明确写绝对路径。从那以后再没出现过“任务执行了但其实什么都没干”的尴尬。6. 二次开发与扩展让OpenMontage适配企业环境6.1 基于Django Admin做资产字段扩展OpenMontage的资产模型字段对普通梳理够用但如果要做企业级资产管理通常需要扩展。它基于Django开发意味着你可以在项目里新增自己的模型定义主机负责人、业务所属部门、维保合同编号、物理位置坐标等字段然后和OpenMontage原始的设备表建立外键关联。我自己做的是新增了一个business_info表把每个网段的业务归属人、联系电话、设备采购日期维护进去。然后用Django Admin自带的list_display和list_filter给资产列表页加上按部门筛选、按网段分组的功能。这样每周导出报告时HTML页面里就能直接按业务线查看不用再导到Excel重新透视。如果你不想改动源码更好的做法是写一个独立的小脚本定频从OpenMontage数据库里读取设备表内容写入外部的CMDB系统。尽量不修改核心源码这样以后版本升级不会遇到合并冲突。6.2 通过API把数据送给其他监控平台OpenMontage本身没有完整的对外REST API但Django应用可以很方便地增加一个只读接口。我在项目里写了一个简单的视图返回JSON格式的设备在线状态和拓扑链路列表。这个接口主要供两个地方调用一个是办公楼的综合告警大屏把核心设备在线状态做成大屏看板另一个是内部的网络变更审批流程提交变更前自动检查目标设备是否在线、是否存在关联链路告警。设计这个接口时我额外加了一层Token认证而不是直接用Django的Session认证因为外部系统调用时不会去登录页面敲账号密码。只读接口也不开放写操作避免外部误操作改了资产数据。如果你对二次开发不熟最简单的扩展方式是用定时器导出数据再写脚本导入其他平台。虽然不够实时但对于资产数据这类低频变更的信息完全足够了。6.3 实际运维流程中怎么安排扫描频率关于扫描频率我的建议是分三层资产发现扫描一周一次状态检测五到十分钟一次深度SNMP采集一天一次。资产发现扫描比较重需要遍历网段和读设备邻居表太频繁反而影响设备性能。状态检测轻量ping一下或者尝试连接端口就能判断适合高频执行。深度采集负责收集CPU、内存、接口流量这些信息一天一次已经能形成趋势曲线。我见过有些朋友把资产发现设置成每十分钟一次结果设备侧SNMP进程疯狂响应核心交换机CPU负载上升了好几个百分点。扫描工具的节奏应该跟着监控需求和网络承载能力走不是越频繁越好。7. 一些不是必要但很好用的周边做法7.1 把扫描服务器单独放一个管理网段OpenMontage的扫描流量如果全部走业务网络容易被防火墙和安全设备拦而且SNMP请求本身是明文协议安全风险也得考虑。我以前图省事直接部署在一台办公网内的机器上结果总有一些设备SNMP协议被安全策略误拦扫描结果时好时坏。后来把采集服务器挪到带外管理网段并且只允许从这台服务器向目标设备发起SNMP和ICMP请求问题一下子少了很多。7.2 数据定期备份要按天做OpenMontage的数据库是所有扫描成果的唯一存储点一旦损坏整个网络资产信息都得重来。我用crontab每天凌晨把数据库文件复制到备份目录再用rsync同步到远程备份服务器恢复时直接替换文件重启服务就行。这种方案简单粗暴但在我维护的多个实例里它真的救过我两次数据库损坏的命。7.3 日志要单独开一个文件如果你同时维护多个OpenMontage实例建议每个实例的日志都写到独立路径文件名带上IP或机房标识。否则多个实例共用一套日志配置排查问题时所有任务记录混在一起根本分不清哪条扫描日志是哪台服务器的。我在实际使用中最大的感受是OpenMontage这类工具的价值不在于替换已有监控体系而是承担“自动把物理网络变成可管理数据”这种脏活累活。只要部署时把SNMP参数、定时任务、数据库备份这三件事做好它就能成为一个长期发挥作用的资产盘点基础设施给后面的监控、变更、巡检流程打底。