📚 课程目录第3章数据采集层设计

3、数据采集层设计：采集器架构模式、主动采集 vs 被动采集、数据标准化接口设计、采集器注册与发现机制

数据采集层是整个失效预警系统的「眼睛」和「耳朵」。没有它，后面的分析、判断、告警全是空谈。我见过不少团队，一上来就搞复杂的算法模型，结果数据质量一塌糊涂，模型再牛也白搭。

说白了，采集层决定了系统的下限。你采集的数据有多准、多快、多全，预警系统就有多靠谱。今天咱们就聊聊怎么设计这一层。

采集器架构模式：单体 vs 插件化

先说说采集器的架构。我刚开始做监控系统时，习惯把所有采集逻辑写在一个大模块里。CPU、内存、磁盘、网络……全塞一起。结果呢？改一个采集项就得重新部署整个服务，风险大，还容易互相影响。

后来我换成了插件化架构。每个采集器是一个独立插件，通过统一接口注册到主进程中。主进程负责调度、生命周期管理、数据上报，插件只关心「怎么采」。

核心思路：主控 + 插件，各司其职。

主控（Collector Manager）：负责插件加载、配置下发、心跳检测、数据汇聚。
插件（Collector Plugin）：实现具体采集逻辑，比如读取 /proc/stat、调用 API、解析日志。

这样做的好处很明显：

热插拔：新增采集项不用重启主进程，动态加载插件就行。
隔离性：一个插件挂了不影响其他插件，主控可以自动重启它。
复用性：同样的插件可以部署到不同机器，配置不同参数即可。

我画了一张架构图，帮你理解这个模式：

主动采集 vs 被动采集

这是采集层设计里绕不开的选择题。两种模式各有适用场景，选错了后面全是坑。

对比维度	主动采集（Pull）	被动采集（Push）
触发方式	采集中心定时拉取	被监控端主动上报
控制权	在采集中心手里	在被监控端手里
适用场景	内网、可控环境	边缘节点、不可控网络
扩展性	采集中心容易成为瓶颈	天然分布式，扩展性好
实时性	取决于轮询间隔	事件驱动，实时性高
典型代表	Prometheus	Telegraf → InfluxDB

我在实际项目中是怎么选的？

数据中心内部：用主动采集。所有机器都在同一个内网，采集中心可以控制节奏，避免被监控端把网络打满。
边缘节点或云上实例：用被动采集。这些节点可能随时启停，IP 会变，主动去拉容易扑空。让它们主动上报更靠谱。

我的经验：不要死磕一种模式。很多成熟系统都是混合模式——核心服务用 Pull，边缘节点用 Push。你可以在采集中心统一收口，上层不用关心数据是怎么来的。

数据标准化接口设计

采集器五花八门，但上报的数据格式必须统一。否则下游的存储、分析、告警模块得适配 N 种格式，维护成本直接爆炸。

我习惯定义一个标准数据模型，所有采集器都按这个模型输出：

{
  "metric": "cpu_usage_percent",
  "tags": {
    "host": "web-01",
    "region": "cn-beijing",
    "service": "nginx"
  },
  "fields": {
    "value": 78.5,
    "max": 100,
    "min": 0
  },
  "timestamp": 1700000000,
  "collector": "cpu_plugin_v2",
  "interval": 15
}

这个模型包含几个关键部分：

metric：指标名称，全局唯一。命名规范我建议用 层级_对象_指标，比如 system_cpu_usage。
tags：标签，用于区分不同维度。注意标签值不要太多，否则会引发高基数问题。
fields：实际数值。可以包含多个字段，比如 value、max、min、count。
timestamp：采集时间戳，统一用 Unix 时间戳（秒或毫秒）。
collector：采集器标识，方便排查问题。
interval：采集间隔，下游可以用来做数据补全或异常检测。

注意：时间戳一定要在采集端生成，不要在传输过程中重新打。我遇到过因为网络延迟导致时间戳漂移的问题，排查了好久才发现是中间件改了时间。

采集器注册与发现机制

当采集器数量从几十个涨到几千个时，手动管理就彻底行不通了。你需要一套自动注册与发现机制。

我常用的方案是这样的：

采集器启动时，向注册中心发送注册请求，带上自己的元信息（IP、端口、采集类型、版本号）。
注册中心（比如 Consul、Etcd、Zookeeper）记录这些信息，并维持心跳。
采集中心从注册中心拉取活跃采集器列表，动态分配采集任务。
采集器下线或失联，注册中心自动摘除，采集中心不再调度它。

这里有个关键点：心跳超时。我一般设 3 个心跳周期没收到就标记为下线。太短容易误判，太长又影响故障发现速度。

注册信息示例：

{
  "collector_id": "cpu_plugin_web-01",
  "type": "cpu",
  "version": "2.1.0",
  "host": "192.168.1.10",
  "port": 9100,
  "endpoint": "/metrics",
  "tags": {"region": "cn-beijing", "env": "prod"},
  "heartbeat_interval": 10,
  "last_seen": 1700000000
}

有了这套机制，新增采集器只需要部署并启动，剩下的自动完成。我曾经在半小时内上线了 500 台机器的采集任务，全靠这套自动发现。

小结

数据采集层设计，说白了就是三件事：

架构：用插件化模式，主控管调度，插件管采集。
模式：Pull 还是 Push，看场景选，别死板。
标准化：统一数据模型，统一注册发现，让系统能自动运转。

这些基础打好了，后面的存储、分析、告警才能站得稳。下一层咱们聊聊数据怎么存，怎么查——那是另一个有意思的话题。