Collector（收集器）

Collector（收集器） 是监控系统架构中的核心数据处理枢纽，它位于 Agent 和后端存储之间，负责接收、处理和转发所有监控数据。可以把它理解为监控体系中的"快递分拣中心"。

---

Collector 的三大核心职责

接收（Receiver）

Collector 提供多种协议的接收端点，可以从各种来源收集数据：

• 接收 Agent 上报的指标、日志、链路追踪数据

• 支持多种协议：OTLP、Prometheus、Jaeger、Zipkin、Kafka、StatsD 等

• 不挑食，什么格式的数据都能接

处理（Processor）

收到原始数据后，Collector 会进行一系列加工：

• 批处理：将零散数据打包，减少网络请求次数

• 过滤：丢弃不需要的噪音数据，节省存储成本

• 采样：对链路追踪数据进行采样，避免数据量爆炸

• 转换：统一数据格式，添加元数据（如主机名、环境标签）

• 限流：防止数据洪峰压垮后端存储

导出（Exporter）

处理完成后，Collector 将数据转发到各种后端系统：

• 指标 → Prometheus、InfluxDB

• 链路追踪 → Jaeger、Tempo

• 日志 → Elasticsearch、Loki

• 甚至可以同时发往多个后端

---

在你的监控平台中的位置

结合你之前的技术栈，Collector 的角色大致如下：

Agent (psutil采集) → [HTTP/WebSocket] → Collector → [处理/聚合] → 后端存储 (MySQL/InfluxDB) → 前端展示 (ECharts)

Collector 的好处是：Agent 不需要关心数据最终存在哪里、用什么格式存。如果以后要换数据库或增加新的监控后端，只需要改 Collector 的配置，Agent 代码完全不用动。

---

常见的 Collector 实现

名称	所属生态	特点
OpenTelemetry Collector	CNCF	最主流，支持指标/日志/链路三合一，插件丰富
SkyWalking Collector	Apache	专注链路追踪，内置存储和查询能力
Prometheus	CNCF	本质也是一个 Collector，通过拉取方式收集指标
Telegraf	InfluxData	轻量级，插件多，适合指标采集
Fluentd/Fluent Bit	CNCF	专注日志收集

---

举个实际例子

假设你有 100 台服务器，每台服务器上的 Agent 每秒上报一次数据：

• 没有 Collector：100 个 Agent 直接连数据库，数据库连接数爆炸，且每个 Agent 都要知道数据库地址、表结构等细节

• 有 Collector：100 个 Agent 只连 Collector，Collector 负责批处理、聚合后统一写入数据库。Agent 完全不知道后端是什么

---

总结

Collector 就是监控架构中的中间层，它解耦了数据采集（Agent）和数据存储（后端），提供了统一的数据接收、加工和分发能力。有了 Collector，整个监控体系才具备灵活性、可扩展性和可维护性。