第3章：巡检系统架构——分层设计、模块划分与数据流

做系统巡检就像给服务器做体检，没有清晰的架构，体检报告就是一团乱麻。我刚开始带运维团队时，最头疼的就是巡检数据流看不懂——采集点和告警池之间隔着好几层代理，丢数据了都查不出链路上哪个环节断了。后来我们重构了整个巡检系统，把分层和模块固定下来，才算真正把巡检做成了自动化流水线。这一章，我把自己踩过的坑和总结的结构掰开揉碎了讲给你。

3.1 分层设计：三层两线，别乱串

我习惯把巡检系统拆成三层两线。三层是数据采集层、处理分析层、展示调度层；两线是控制流线和数据流线，两条线必须物理隔离，否则调度命令堵塞数据管道，你会看到告警延迟到天荒地老。

层级	核心职责	我踩过的坑
展示调度层	用户交互、任务编排、报表展示、权限控制	曾经把任务调度逻辑写在Web前端，一刷新就重复派发巡检单
处理分析层	指标计算、规则匹配、异常判定、日志清洗	内存溢出最常见的地方——正则匹配没做超时隔离
数据采集层	SSH/SNMP/Agent 采集、日志收割、元数据获取	采集插件全家福式部署，把目标机CPU打满，生产事故一次就学乖了

3.2 模块划分：五个核心模块，缺一不可

分层定了框架，模块才是干活的主力。我把核心模块梳理成下表，你想想看，少了哪一个，巡检系统都会变成跛脚鸭。

模块名称	功能定位	数据流角色
任务调度器	接收用户/定时触发，生成巡检任务，管理队列	控制流起点
采集代理	执行具体采集脚本，支持多协议（SNMP/SSH/HTTP）	数据产生者
数据管道	消息排队、协议转换、去重、限流	数据缓冲与路由
规则引擎	加载告警阈值、异常判定、关联分析	数据消费者+决策者
告警与报表	推送邮件/钉钉/短信，生成PDF/CSV报告	数据输出端

3.3 数据流：从点击到告警，七步走

理解数据流比记住分层更重要。我画了一张图，把核心路径串起来。你看，数据从左上到右下，控制流从右到左，两条线在任务调度器交汇。

数据流的顺序其实很简单：用户或定时器发起任务→调度器派单→采集代理执行→数据进入管道→规则引擎判定→告警/报表输出。但有几个细节容易翻车，我逐个讲。

3.4 数据流里的三个关键点

3.4.1 缓冲层的必要性

采集代理直接写入数据库？千万别。一旦数据库打嗝（锁等待、主从延迟），采集线程全部卡死，后面的任务就阻塞了。我在生产环境用过一次Kafka，数据管道用磁盘队列做二级缓冲，才把峰值吞吐扛到每秒10万条记录。其实说白了，消息队列就是给系统装了个减震器。

3.4.2 降级与熔断

规则引擎如果挂了怎么办？我采用的设计是：降级只出基础告警，不做关联分析。熔断阈值设成CPU 80%或队列积压超过10万条，直接跳过复杂规则，只保留简单的单指标阈值。我跟你说，最怕的不是故障，是故障时规则引擎还在尝试跑复杂SQL把系统拖死。

3.4.3 数据一致性：去重与幂等

网络抖动会导致采集代理重复上报同一条数据。我的做法是在数据管道入口做基于时间戳+源IP+指标名的去重，窗口设成30秒。注意别用全局锁，用Redis + Lua脚本来处理，否则高并发下会变成全剧瓶颈。

3.5 模块划分的部署建议

你问我部署时怎么切？我习惯这样：

• 展示调度层：2台Nginx + 4个Web实例，状态存Redis
• 任务调度器：独立部署，用分布式锁避免重复派单
• 采集代理：每台目标机部署一个轻量Agent，资源占用控制在3% CPU以下
• 数据管道：Kafka集群3台起步，消费端做批量提交
• 规则引擎：无状态水平扩展，告警缓存过期时间设成5分钟
• 告警与报表：单独进程，用异步非阻塞HTTP发送，避免阻塞规则引擎

3.6 为什么架构要这么设计？

一句话：让故障范围可控，让排查路径清晰。分层之后，采集层坏了不影响告警历史查询；规则引擎卡住了，数据管道还在继续接受新数据。我做过一次压测，模拟数据管道断连10分钟，重启后消费积压，但所有记录最终都落库了，没有一条丢失。这就是架构设计的力量。

你想想看，如果从头到尾一条线串通，任何一个环节挂了，整个巡检就停摆，恢复后还得手动补数据——这种架构我接手过，改起来真是让人头秃。