ascjreddy/Network-Monitoring-Incident-Response-Platform

# 网络监控事件响应平台 针对多设备网络环境的自动化根因分析和故障重构。 ## 为什么开发这个平台 当网络发生故障时，典型的响应方式是手动的：通过 SSH 登录到每台设备，在 syslog 中使用 grep 进行搜索，对比时间戳，并试图找出最先发生故障的节点。在多设备网络中，这个过程通常需要 15–30 分钟——而每过一分钟，如果错误地归责了故障点，或者以错误的顺序修复了正确的故障点，都会导致更多的停机时间。 我想要构建一个能自动完成这种关联分析的系统。只需为其提供网络拓扑，让它持续收集遥测数据，当发生故障时，它应该能在 60 秒内准确地告诉你是什么发生了故障、产生了什么连锁反应，以及应该如何解决。 ## 工作原理 三个 Python 脚本持续运行并协同工作： **`syslog_collector.py`** 在 GNS3 虚拟机上监听 UDP 514 端口。来自每台网络设备的每一条 syslog 消息都会到达这里，经过严重级别和设备身份的解析后，被写入 Windows 主机上的 PostgreSQL 中。 **`snmp_poller.py`** 每 30 秒通过 SNMP 轮询一次设备，检查可达性。结果会被存入同一个 PostgreSQL 数据库中。 **`incident_engine.py`** 在 Windows 上运行，每 30 秒查询一次数据库。它会检查过去 10 分钟的事件，对已知的故障特征应用模式匹配规则，遍历拓扑图以查找下游影响范围，并写入结构化的事件记录——包括根因设备、受影响的设备、时间线以及修复步骤。 Grafana 面板直接从 PostgreSQL 提取数据，并每 30 秒自动刷新一次。当事件触发时，你会立即看到它：活动事件计数器变红，事件日志显示完整的根因分析，并且 syslog 流显示触发该事件的原始事件。 ## 架构 ``` 9 GNS3 network devices (Cisco IOU) | | syslog UDP 514 SNMP every 30s | | syslog_collector.py snmp_poller.py (GNS3 VM) (GNS3 VM) | | +--------+----------+ | PostgreSQL (Windows host) 3 tables: syslog_events snmp_metrics incidents | incident_engine.py (Windows host) | +----------+-----------+ | | Grafana dashboard Incident reports (real-time panels) (root cause + fix) ``` ## 网络拓扑 跨越 4 层的 9 台设备运行 OSPF： ``` Edge-RTR-01 / \ Core-SW-01 Core-SW-02 | | Dist-HQ Dist-Branch / \ | Acc-SW1 Acc-SW2 Acc-SW3 ``` 关联引擎能够识别此拓扑。当 Core-SW-01 上的某个接口断开时，引擎会遍历该树状结构，并识别出 Dist-HQ、Acc-SW1、Acc-SW2 及其下游的所有设备——这些都是症状，而不是原因。 ## 引擎检测的内容 | 事件类型 | 检测逻辑 | |---|---| | 接口断开 | syslog 中包含 `LINEPROTO-5-UPDOWN` + `down` | | OSPF 邻居丢失 | syslog 中包含 `OSPF` + `ADJCHG` + `DOWN` | | 设备不可达 | SNMP 连续 90 秒以上报告 `unreachable` | | 链路震荡 (Link flapping) | 同一设备在 10 分钟内发生 5 次以上的 up/down 事件 | 故障的恢复检测采用相同的反向逻辑。当接口重新启动或 OSPF 邻接关系恢复时，事件将被标记为已解决，仪表板也会变回绿色。 有一个不太明显但值得一提的修复机制：在事件解决后，10 分钟的事件窗口中仍然包含最初的故障 syslog 消息。如果不对此进行处理，引擎将立即重新检测到相同的事件。解决方法是使用一个 `recently_resolved` 字典来跟踪 `(device, incident_type) → resolved_at` 时间戳。在每个引擎周期中，任何早于该时间戳的匹配事件都会被跳过。 ## 事件输出示例 ``` ============================================================ INCIDENT DETECTED -- 2026-06-01 02:57:28 ============================================================ Type: OSPF_NEIGHBOR_LOST Root Cause: Core-SW-01 Event: OSPF adjacency lost at 2026-06-01 02:57:22 Affected: Dist-HQ, Acc-SW1, Acc-SW2 Remediation: Verify OSPF config on both sides. Run: show ip ospf neighbor Check interface status. ------------------------------------------------------------ Timeline: 02:57:22 | Core-SW-01 | %OSPF-5-ADJCHG: Nbr 1.1.1.1 from FULL to DOWN 02:57:24 | Core-SW-01 | %LINEPROTO-5-UPDOWN: Ethernet0/0 changed to down ============================================================ ``` ## 技术栈 | 组件 | 工具 | |---|---| | 网络模拟器 | GNS3 | | 网络设备 | Cisco IOU-L3, Cisco IOU-L2 | | 遥测 | Python syslog 服务器 (UDP 514) + subprocess snmpget | | 数据库 | PostgreSQL 16 | | 面板 | Grafana | | 语言 | Python 3 | ## 运行说明 **前置条件：** 安装了 Cisco IOU 镜像的 GNS3，Python 3.9+，PostgreSQL，Grafana。 ``` git clone https://github.com/ascjreddy/Network-Monitoring-Incident-Response-Platform cd Network-Monitoring-Incident-Response-Platform pip install psycopg2-binary ``` 设置数据库（创建三张表——schema 位于 `architecture.md` 中）。 然后启动这三个脚本： ``` # 在 GNS3 VM 上 — 终端 1 sudo python3 syslog_collector.py # 在 GNS3 VM 上 — 终端 2 sudo python3 snmp_poller.py # 在 Windows 上 — PowerShell python incident_engine.py ``` 从 `grafana-dashboard.json` 导入 Grafana 面板。 在 Core-SW-01 上触发测试故障： ``` conf t interface Ethernet0/0 shutdown end ``` 引擎会在 60 秒内检测到它。使用 `no shutdown` 恢复接口，事件会自动解决。 ## 测试结果 **测试用例 1 — Core-SW-01 接口故障** 通过在 Core-SW-01 上关闭 Ethernet0/0 触发。引擎检测到了 OSPF_NEIGHBOR_LOST，并追踪到了 Dist-HQ 及下游接入层交换机的连锁反应。当接口重新启动时，事件已自动解决。 检测时间：从接口关闭到事件记录写入不到 60 秒。 涵盖汇聚层故障、OSPF 邻接丢失和误报预防的其他测试场景记录在 screenshots 文件夹中。

标签：Docker 部署, Grafana, PostgreSQL, 故障排查, 根因分析, 测试用例, 系统日志, 网络运维