3. CollectionEvent基础：数据结构、采集方式与传输协议
CollectionEvent（采集事件）是监控系统中最原始的数据载体，它记录了从被监控对象（主机、容器、中间件、网络设备）上采集到的一次快照。与AlarmEvent（告警事件）不同，CollectionEvent不携带阈值、严重级别或触发规则，它只回答“在什么时间、从哪个对象、采集到了什么值”。
核心认知： CollectionEvent是“事实”，AlarmEvent是“判断”。没有准确、完整的CollectionEvent，任何告警规则都是空中楼阁。
3.1 CollectionEvent的数据结构
一个标准的CollectionEvent通常包含五元组核心字段，外加若干扩展属性。下表列出了生产环境中最常见的字段定义：
| 字段 | 类型 | 说明 | 示例 |
|---|---|---|---|
| eventId | string | 全局唯一标识，用于去重和追踪 | col-20250321-001a2b3c |
| timestamp | int64 | 采集发生时的Unix毫秒时间戳 | 1742572800000 |
| source | string | 被采集对象的唯一标识（如IP+端口、主机名、Pod UID） | 10.0.1.5:9100 |
| metric | string | 指标名称，遵循命名规范 | cpu_usage_percent |
| value | float64 | 采集到的数值 | 78.32 |
| tags | map[string]string | 维度标签，用于多维度聚合 | {"region":"cn-north","env":"prod"} |
| unit | string | 单位（可选） | %、MB、req/s |
数据结构设计原则：
- 扁平化：避免嵌套JSON，降低序列化/反序列化开销。
- 时间精度统一：全链路使用毫秒时间戳，避免时区与精度混乱。
- 标签白名单：tags字段应限制key数量（通常≤20），防止高基数爆炸。
3.1.1 数据结构关系图
下图展示了CollectionEvent在内存中的逻辑结构，以及各字段之间的从属关系：
3.2 采集方式
根据被采集对象的类型和环境，CollectionEvent的采集方式分为三大类。每种方式在延迟、资源消耗、覆盖范围上各有优劣。
3.2.1 采集方式对比
| 采集方式 | 典型协议/工具 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|---|
| Agent主动采集 | Prometheus Exporter、Telegraf、Datadog Agent | 主机、容器、数据库、中间件 | 标准化、可编程、支持自定义指标 | Agent本身消耗资源，需管理生命周期 |
| 日志/事件驱动采集 | Fluentd、Logstash、Filebeat | 应用日志、业务事件、审计日志 | 无侵入、覆盖业务语义 | 延迟较高，解析规则复杂 |
| API/轮询采集 | SNMP、JMX、REST API | 网络设备、Java应用、云服务 | 无需安装Agent，兼容遗留系统 | 轮询频率受限，可能漏采峰值 |
3.2.2 Agent主动采集流程
以Prometheus生态为例，Agent主动采集的典型流程如下：
- Exporter暴露端点：被监控对象运行Exporter进程，在指定端口（如
:9100）提供/metricsHTTP端点。 - Agent拉取：Prometheus Server或Telegraf按配置的间隔（如15s）向端点发起HTTP GET请求。
- 数据解析：Agent解析返回的文本格式（Prometheus exposition format）或protobuf，提取metric name、value、labels。
- 封装为CollectionEvent：将解析结果填充到CollectionEvent结构体中，添加source、timestamp等元信息。
- 写入管道：将事件推送到内存队列或消息中间件，等待后续处理。
常见陷阱： Agent采集间隔与Exporter数据刷新频率不匹配时，会出现重复值或空洞。建议Exporter的指标刷新间隔 ≤ Agent采集间隔的1/2。
3.2.3 采集方式架构图
下图展示了三种采集方式在监控系统中的部署位置与数据流向：
3.3 传输协议
CollectionEvent从采集端传输到后端处理系统时，需要选择合适的传输协议。协议的选择直接影响吞吐量、可靠性、延迟和资源开销。
3.3.1 主流传输协议对比
| 协议 | 传输方式 | 可靠性 | 适用场景 | 典型实现 |
|---|---|---|---|---|
| HTTP/HTTPS | 请求-响应 | 高（基于TCP） | Agent→Server直连，低频采集 | Prometheus Remote Write |
| gRPC | 双向流 | 高（基于HTTP/2） | 高频采集，微服务间传输 | OpenTelemetry Collector |
| Kafka | 发布-订阅 | 极高（持久化+副本） | 大规模集群，异步解耦 | Kafka Connect, Logstash |
| UDP | 无连接 | 低（可能丢包） | 实时性要求高，可容忍少量丢包 | StatsD, collectd |
| MQTT | 发布-订阅 | 中（QoS可配置） | IoT设备，边缘节点 | EMQX, Mosquitto |
3.3.2 传输协议选型决策树
在实际架构设计中，可以按照以下决策树选择传输协议：
- 数据量 < 10万事件/秒 → 优先使用HTTP/HTTPS，简单易维护。
- 数据量 10万~100万事件/秒 → 使用gRPC，利用流式传输降低连接开销。
- 数据量 > 100万事件/秒 → 引入Kafka作为缓冲层，削峰填谷。
- 边缘节点/弱网环境 → 使用MQTT，支持离线缓存和QoS。
- 实时仪表盘/告警 → 可混合使用UDP（低延迟）+ Kafka（可靠持久化）。
生产建议： 不要将所有CollectionEvent都通过同一条链路传输。建议按指标重要性分级：
- P0（核心业务指标）：gRPC + Kafka 双链路保障。
- P1（基础设施指标）：HTTP/HTTPS 单链路。
- P2（调试/临时指标）：UDP 尽力传输，允许丢包。
3.3.3 传输协议数据流图
下图展示了CollectionEvent从采集端到存储端的完整传输路径，以及各协议在链路中的位置：
3.4 小结
CollectionEvent是监控系统的数据基石。掌握其数据结构（五元组+标签）、采集方式（Agent/日志/API）和传输协议（HTTP/gRPC/Kafka/UDP/MQTT），是后续进行AlarmEvent联合诊断的前提。在实际运维中，数据结构标准化和传输协议分级是保障大规模监控系统稳定运行的关键手段。