简介面向企业网络管理员与运维人员FPinger是一款轻量级网络监控工具通过持续ping探测交换机等关键设备在线状态结合长ping技术实时反馈延迟与丢包率并以网络拓扑视图辅助快速定位故障节点适合数据中心、企业内网及云计算环境的日常巡检与排障。压缩包为rar格式共7个文件包含多个版本的可执行程序、注册表配置、txt说明文档及htm帮助页面整体仅3.31MB轻量易部署。资源中收录了不同历史版本的工具可对比功能演进配合注册表项和文档可快速完成环境配置并理解长ping监控机制与拓扑图在故障排查中的实际用法。目前已有194人学习下载适合需要低成本搭建网络连通性监控的IT人员参考有助于提升故障发现效率与网络运行稳定性。 做了几年网络运维最头疼的事之一就是半夜被电话叫醒“某某区域的网又卡了/断了是不是交换机挂了” 这时候如果手边没有一张清晰的网络拓扑图排查起来就得靠 ping 加 telnet 挨个设备试效率低不说还容易被业务部门催得心浮气躁。后来我用 FPinger 搭了一套轻量级的网络拓扑监控系统把“设备在不在线”“链路通不通”这些问题用一张图和一个告警消息解决掉这里把完整的搭建思路、踩坑记录和最终效果整理出来希望能给同样在做网络运维、或者正在选型监控方案的朋友一些参考。这套方案的核心思路就一句话用 fping 的高效探测能力加上拓扑发现逻辑和一个简单的展示前端做成一套能自己掌控、不依赖商业网管软件的监控系统。它适合几十到上千台设备的网络环境无论是办公室网络、园区网还是 IDC 机房的接入层都能用得上。不需要昂贵的商业网管授权也不需要很强的开发基础有一台 Linux 服务器和基本的 Python/Shell 能力就能跑起来。1. 项目整体设计与方案选型思路1.1 为什么不用现成的商业网管软件市面上的网管软件比如 SolarWinds、WhatsUp Gold 或者国内的某些网管平台功能确实全但问题也很明显授权费用不低、部署架构重、对硬件要求高而且很多功能在中小型网络里根本用不上。开源的监控系统也有不少比如 Zabbix、Nagios但这些东西更偏“监控”而不是“拓扑”。Zabbix 要监控一台设备得先手动添加主机、配置模板、设置触发器一套流程走下来几百台设备光是录入就要花不少时间。FPinger 的思路不一样它把“探测在线”和“发现拓扑”这两件事合在一起做尽量减少人工介入。设备上线了自动发现链路断了自动告警拓扑图自动生成运维只需要在异常时看一眼图确认影响范围就行。这套逻辑对 100~2000 台设备的规模来说完全够用而且运维成本远低于商业方案。1.2 整体架构拆解三条链路搞定监控闭环这套系统我分成三个部分来设计每个部分职责单一出了问题也好排查探测层负责周期性 ping 所有已知 IP 和网段输出在线状态、响应时延、丢包率。底层用 fping因为它在批量探测场景下比普通 ping 快一个数量级。数据层把探测结果存进 SQLite 或者 MySQL同时维护一张设备表IP、MAC、位置、类型和一张链路表两端设备 ID、状态、最后更新时间拓扑关系就在这一层生成。展示层用一个轻量的 Web 页面把拓扑图渲染出来设备挂没挂、链路通不通一眼就能看出来同时支持告警记录查询。三个部分之间用最简单的“定时任务 API”方式串联。探测层每 30 秒跑一轮结果写入数据库展示层读取数据库把拓扑和状态渲染成页面。没有复杂的消息队列也没有微服务因为这种规模的服务根本不需要那些东西越简单越不容易出故障。1.3 为什么选 fping 而不是 namp/ping最初我也考虑过用 nmap 做探测毕竟它的 -sn 参数也能扫网段还能顺带识别端口。但实测下来nmap 的扫网段耗时要做到稳定需要开多线程而且探测 ICMP 的同时还会尝试做主机发现的各种探测包在防火墙上容易产生误报。普通 ping 命令更不用说了串行探测几百台设备一轮下来几十秒就过去了做不到 30 秒一个周期。fping 的优势在于它默认就是并发探测。给一个 IP 列表文件fping 会同时向多个目标发 ICMP 请求然后统一汇总结果。以 /24 网段为例fping 一轮全段探测大概只要 1~2 秒批量处理能力完全是另一个量级。而且它的退出码和输出格式非常稳定方便脚本解析这是我最终选它的核心原因。2. 核心细节解析探测、拓扑发现与数据建模2.1 在线探测的关键参数与原理fping 的常用组合我一般是这样写fping -f /etc/fpinger/ip_list.txt -c 3 -t 500 -r 1 -q 2/dev/null这行命令的参数含义分别是-f指定 IP 列表文件每行一个 IP 或网段。-c每台设备发 3 个包避免单包丢失造成误判。-t单包超时 500 毫秒超过就认为这个包丢了。-r每个目标最多重试 1 次如果 3 个包加一次重试都失败判定为离线。-q安静模式不在终端逐一打印结果输出只保留汇总行这是为了减少日志量。这里有个细节需要注意-t的单位是毫秒但不同版本的 fping 对-t的语义有细微差别。老版本的-t是“单个目标的超时时间”新版本则可能表现为“每个包的往返超时时间”。如果你的环境中设备跨三层较多、链路延迟略高建议把-t调到 800~1000 毫秒否则会出现“设备明明是好的但因为响应稍微慢了一点就被标记成离线”的误报。在解析 fping 输出时会有两种典型格式。一种是“普通文本模式”输出行类似192.168.1.1 : xmt/rcv/%loss 3/3/0%另一种是-e参数附加的“每个目标响应时间”模式。我在采集脚本里直接按空格做字段切割把丢包率和平均时延取出来写入数据库。2.2 拓扑发现怎么知道谁连着谁拓扑发现是整个项目里最“技术”的部分也是我最想展开讲的一个点。网管系统做拓扑通常依赖两类信息一类是 LLDP/CDP 协议。交换机、路由器如果开启了 LLDP 或 CDP会定期向邻居设备发送包含自己设备名、端口号、VLAN、IP 等信息的报文。只要在交换机上执行show lldp neighbors之类的命令或者通过 SNMP 拉取lldpRemTable就能拿到“哪台设备的哪个口连着哪台设备的哪个口”的精确关系。另一类是 MAC 地址表和 ARP 表。如果设备不支持 LLDP比如一些老款交换机、傻瓜交换机或者纯二层设备就需要靠 MAC 表来推断设备位置。核心思路是所有接入设备的 MAC 地址最终会在交换机上留下记录一台主机如果出现在交换机 A 的某个 VLAN 下同时又在交换机 B 的同一个 VLAN 下出现过那它大概率是接在离它更近的那台交换机上。更精确一点可以用“MAC 地址漂移”检测——如果一个 MAC 在两台交换机上反复出现说明这两台交换机之间可能存在链路或环路这个信息也能用来补拓扑边。我的 FPinger 实现里对两类数据做了融合优先尝试通过 SNMP 拉取所有三层设备的dot1dTpFdbTableMAC 表和lldpRemTable能拉到的设备之间直接生成链路。对拉不到 SNMP 的设备退而求其次通过“交换机端口流量 设备 MAC 出现位置”做关联分析给出一条置信度较高的推断链路。拓扑发现不会做得太频繁一般每小时跑一次就够了。网络结构变化不那么快太频繁反而会增加设备负载而且容易产生链路抖动误报。2.3 数据模型三张核心表的设计思路直接放我用的建表 SQL方便你照着做CREATE TABLE devices ( id INTEGER PRIMARY KEY AUTOINCREMENT, ip TEXT NOT NULL UNIQUE, mac TEXT, hostname TEXT, device_type TEXT, location TEXT, first_seen DATETIME DEFAULT CURRENT_TIMESTAMP, last_seen DATETIME ); CREATE TABLE links ( id INTEGER PRIMARY KEY AUTOINCREMENT, device_a_id INTEGER, device_b_id INTEGER, a_port TEXT, b_port TEXT, status TEXT, last_update DATETIME, FOREIGN KEY (device_a_id) REFERENCES devices(id), FOREIGN KEY (device_b_id) REFERENCES devices(id) ); CREATE TABLE probe_history ( id INTEGER PRIMARY KEY AUTOINCREMENT, device_id INTEGER, probe_time DATETIME, online INTEGER, avg_rtt_ms REAL, loss_percent REAL );这套模型不复杂但足够覆盖核心需求。devices表存资产信息links表存拓扑关系probe_history表存每次探测的原始记录方便回溯“设备到底是从什么时候开始不稳定的”。如果后续想做告警统计也可以基于probe_history做聚合查询不需要额外加表。3. 实操过程从零搭建一套 FPinger 监控3.1 环境准备与依赖安装我用的是 CentOS 7 服务器2 核 4G 内存跑 500 台设备的探测和展示毫无压力。系统层面只需要装三个东西fping、Python 3、以及一个轻量级 Web 框架我用 Flask也可以用 FastAPI。yum install -y fping python3 python3-pip pip3 install flask如果在 Ubuntu/Debian 上把 yum 换成 apt 就行。安装完成后验证一下 fping 是否正常fping -v输出类似fping: Version 4.2就说明装好了。3.2 探测脚本的核心实现探测脚本用 Python 写核心逻辑是读取设备表 → 构造 fping 命令 → 执行并解析 → 写入数据库。为了不让探测阻塞太久我对所有 /24 网段直接用 fping 批量扫而不是逐台设备单独 ping。这里有个小技巧如果网络里同时存在多个不连续的网段可以把网段写进ip_list.txtfping 会自动展开。import subprocess, sqlite3, time def run_probe(): conn sqlite3.connect(/etc/fpinger/fpinger.db) cur conn.cursor() ip_list [row[0] for row in cur.execute(SELECT ip FROM devices)] if not ip_list: return # 每行一个 IP写入临时文件 with open(/tmp/ip_list.txt, w) as f: f.write(\n.join(ip_list)) # 执行 fping cmd [fping, -f, /tmp/ip_list.txt, -c, 3, -t, 500, -r, 1, -q] result subprocess.run(cmd, capture_outputTrue, textTrue, timeout30) # 解析结果把设备状态更新到数据库 for line in result.stderr.strip().split(\n): # 格式: 192.168.1.1 : xmt/rcv/%loss 3/3/0% parts line.split(:) if len(parts) 2: continue ip parts[0].strip() status_part parts[1] # 提取丢包率 if %loss in status_part: loss status_part.split()[1].strip().split(/)[2].replace(%, ) else: loss 100 online 1 if loss 0 else 0 cur.execute( UPDATE devices SET last_seen ? WHERE ip ?, (time.strftime(%Y-%m-%d %H:%M:%S), ip) ) cur.execute( INSERT INTO probe_history (device_id, probe_time, online, loss_percent) VALUES ((SELECT id FROM devices WHERE ip?), ?, ?, ?), (ip, time.strftime(%Y-%m-%d %H:%M:%S), online, loss) ) conn.commit() conn.close() if __name__ __main__: run_probe()代码里我特意把result.stderr作为解析对象因为 fping 在-q模式下会把汇总结果输出到 stderrstdout 反而是空的。这个坑我一开始踩过如果你用result.stdout去解析会拿到空字符串半天找不出原因。3.3 拓扑发现脚本的实现思路拓扑发现脚本比在线探测复杂一些核心流程分三步用snmpwalk拉取所有核心交换机的基本信息。拉取 LLDP 邻居表和 MAC 地址表。对两张表做关联匹配生成链路关系。以思科交换机为例拉取 LLDP 邻居表的命令是snmpwalk -v2c -c public 192.168.1.1 1.0.8802.1.1.2.1.4.1.1.7这个 OID 对应的是lldpRemPortId可以拿到邻居的设备 ID 和端口号。如果交换机不支持 LLDP就退到 MAC 表snmpwalk -v2c -c public 192.168.1.1 .1.3.6.1.2.1.17.4.3.1.2拉下来的结果是一个 MAC 地址到交换机端口的映射表。把所有交换机的表收集起来做交叉比对如果设备 A 在交换机 1 的端口 5 上出现同时也在交换机 2 的某个端口上出现那就可以合理推断交换机 1 和交换机 2 之间可能存在链路。实际工程上这一步会有误判我加了“置信度”字段只有当某条链路被至少 3 个不同 MAC 地址的“漂移”行为支持时才把它画到拓扑图上。这一步也是整个项目中最花时间的部分调试 SNMP OID 的过程比较枯燥但做完之后拓扑自动生成的准确率能达到 90% 以上非常值得投入。3.4 可视化展示五分钟出一个能看的页面展示页我用 Flask ECharts 写ECharts 的力引导图graph类型非常适合画拓扑。数据从数据库里读出来拼成 ECharts 需要的 nodes 和 links 格式返回给前端即可。from flask import Flask, render_template, jsonify import sqlite3 app Flask(__name__) app.route(/api/topology) def topology(): conn sqlite3.connect(/etc/fpinger/fpinger.db) cur conn.cursor() devices cur.execute(SELECT id, ip, hostname, device_type, location, last_seen FROM devices).fetchall() links cur.execute(SELECT d1.ip, d2.ip, l.status FROM links l JOIN devices d1 ON l.device_a_idd1.id JOIN devices d2 ON l.device_b_idd2.id).fetchall() conn.close() nodes [{id: d[1], name: d[2] or d[1], device_type: d[3], location: d[4], last_seen: d[5]} for d in devices] edge_list [{source: l[0], target: l[1], status: l[2]} for l in links] return jsonify({nodes: nodes, links: edge_list}) if __name__ __main__: app.run(host0.0.0.0, port8080)前端代码就不全贴了核心就是用一个fetch(/api/topology)拿到数据然后设置 ECharts 的series[0].type graph再把节点状态映射成颜色在线绿色、离线红色、未知灰色。如果你不想写前端也可以直接用现成的开源可视化组件比如 Grafana 的拓扑图插件也能替代这一层。3.5 定时任务与告警真正省心的关键所有脚本都写好之后还需要一个定时任务来驱动。我用了 crontab 做了两套周期* * * * * cd /etc/fpinger python3 probe.py logs/probe.log 21 30 * * * * cd /etc/fpinger python3 topology_discovery.py logs/topo.log 21 0 * * * * cd /etc/fpinger python3 check_offline.py logs/alert.log 21每分钟跑一次在线探测每半小时跑一次拓扑发现实际可以改成每小时每小时检查一次离线设备并发告警。告警我推荐用钉钉或企业微信的 Webhook当检测到某台设备连续 3 个周期离线时就推一条消息到运维群里。这里的关键参数是“连续 3 个周期”因为单个周期的丢包可能是瞬时拥塞或者交换机重启导致的不能一丢包就告警否则半夜告警轰炸会很快把你折腾到“狼来了”状态。我用的告警脚本核心逻辑就一段offline_devices [] for ip in devices: count cur.execute( SELECT COUNT(*) FROM probe_history h JOIN devices d ON h.device_idd.id WHERE d.ip? AND h.online0 AND h.probe_time?, (ip, datetime.now() - timedelta(minutes3)) ).fetchone()[0] if count 3: offline_devices.append(ip)把离线 IP 汇总后通过 Webhook 推给钉钉机器人格式用 markdown内容包含设备 IP、离线时间、最后一次在线时间方便值班同学直接评估影响范围。4. 常见问题与排查技巧实录4.1 fping 探测结果频繁出现短暂离线这个现象我在部署初期遇到很多次设备明明在线但 fping 输出显示丢包 100%。排查下来发现两个原因设备对 ICMP 限速。部分交换机默认对 ICMP 的 CPU 处理做了限制探测包一多直接丢弃。解决方法是把探测源 IP 加到访问控制列表白名单或者调大接口的 ICMP 速率限制值。无线桥接链路丢包。无线设备在信号弱的时候丢包率高fping 的-c 3在丢包 50% 的情况下刚好可能 3 个包全丢产生“离线”误判。解决方案是把探测周期内的包数从 3 个调到 5 个并且在判断离线前增加一个“用 ARP 二次确认”的逻辑如果 ping 不通再用arping探测一次能通就不算离线。4.2 拓扑图上出现重复设备或链路这个问题大多是因为 MAC 表数据没及时过期。交换机 MAC 表默认老化时间一般是 300 秒但如果某些交换机配置了 0表示永久保存MAC 地址会一直留在表里即使设备已经离线。这样拓扑发现脚本就会把已经下线的设备当作仍在某端口下导致拓扑图上出现“占位设备”。解决办法是在拓扑发现脚本里对超过 2 个老化周期没有更新过的 MAC 记录直接过滤掉。另外同一个设备如果同时接入有线和无线也会在两张表上出现不同来源的记录需要按 MAC 地址做去重处理。4.3 探测量大了之后数据库写入变慢刚开始我把每次探测的详细记录全部写入probe_history设备一多这张表的数据量涨得飞快查询拓扑页面时明显变卡。后来做了一次优化只保留最近 7 天的明细数据每天凌晨跑一次清理任务删掉更早的记录另外把probe_history表按天做分区查询时只扫描当天的分区。实测下来页面响应时间从原来的 3 秒降到 0.4 秒左右。清理语句很简单DELETE FROM probe_history WHERE probe_time datetime(now, -7 days);配合索引能让它跑得更快CREATE INDEX idx_probe_time ON probe_history(probe_time);4.4 现场拓扑和实际网络对不上这是每个做拓扑监控的人都会遇到的终极难题。物理上有人把网线从交换机 A 拔下来插到了交换机 B但监控系统还是按旧数据在画图。我目前的做法是拓扑发现每次跑到新数据时跟库里上一次的数据做 diff如果链路变化超过 5 条先不直接更新而是推送一条“拓扑变更”提示让运维确认。确认后再更新数据库这样能避免因为抓取过程中的临时异常导致拓扑大面积错乱。另外建议每年手动巡检一次机柜和跳线记录把实际物理连接和系统拓扑对上。自动发现的拓扑可以作为参考但“最终真相”还是以现场为准这是所有网络监控系统都逃不开的现实。4.5 告警消息太多如何收敛告警泛滥的根因通常不是脚本触发过多而是没做“告警聚合”。比如某台汇聚交换机离线它下面挂着的 30 台接入交换机也会跟着离线如果不做聚合一轮探测就会产生 31 条告警。我的做法是先按设备的device_type做层级排序核心设备告警优先级最高接入设备只在核心设备在线时才单独告警。如果核心设备离线就只发一条“核心设备离线可能影响以下设备”的汇总消息接入设备的单独告警直接静默 30 分钟。这样一来的效果非常明显告警群从每天几十条降到平均每天 3~5 条值班同学的怨气小了很多。5. 一些后续可以扩展的方向项目做到这里已经能稳定跑大半年了后面如果需要继续深挖我觉得有两个方向值得尝试。一个是加“端口流量趋势”功能。现在的系统只做在线状态监控看不到带宽占用情况。通过 SNMP 拉端口的ifInOctets和ifOutOctets可以在拓扑图上用线条粗细表示流量大小一眼看出哪条链路在跑大流量对排查拥塞很有帮助。另一个是接入“配置备份”。网络设备最怕配置被误改后找不到变更记录。可以定期通过 SSH 登录设备执行show running-config把配置保存到本地版本库每次变更都留痕。这样真要出问题的时候能快速 diff 出配置差异回滚也更从容。我在实际使用中最大的体会是网络拓扑监控的核心不是“画出漂亮的图”而是“在故障发生时快速缩小排查范围”。FPinger 这套方案帮我做到了这一点——拓扑图不是摆设而是真的能定位问题的工具。它不需要多复杂但每一个功能点都切中运维的痛点。如果你也在为“设备多了管不过来”发愁不妨照着这个思路搭一套试试踩坑的过程本身也是一次很好的学习。本文还有配套的精品资源点击获取