📚 课程目录第4章采集代理与管道部署

4. 采集代理与管道部署

遥测数据要进入分析平台，第一步不是写检测规则，而是把数据从产生点可靠地搬到管道里。这一节讨论五类主流采集方式的工程实现差异，以及它们在同一套部署拓扑中如何分工、如何保证不丢数据。

五类采集方式的适用边界

主机 Agent 部署在终端或服务器上，以进程或系统服务形式常驻，直接读取本地日志文件、系统调用、进程事件。它的优势是能拿到文件级上下文（路径、inode、用户、权限），可以做本地过滤和富化，减少上行带宽。代价是需要逐台安装、升级、配置下发，且在被攻击者拿到 root 后可能被卸载或篡改。

Syslog 是网络设备、安全设备、老式 Unix 系统的通用出口。设备主动把事件推给采集端，采集端只需监听 UDP/TCP 514 或 6514（TLS）。它的优势是零侵入、覆盖广；劣势是格式碎片化严重——同一厂商不同型号的字段顺序都可能不同，且 UDP 模式下丢包无感知。工程上通常用 TCP 或 TLS 承载，并在采集端做解析归一化。

API 拉取 适用于云平台、SaaS、EDR 控制台这类不提供主动推送的数据源。采集器按固定周期调用 REST 接口，用游标或时间戳做增量。关键点是限流与游标持久化：接口通常有 QPS 限制，游标必须落盘，否则重启后会重复拉取或漏拉。

eBPF 在内核态挂载探针，采集网络连接、文件访问、进程执行等事件，无需修改应用代码，开销可控。它适合容器和云原生环境，能拿到传统 Agent 看不到的内核级行为。限制是依赖较新内核（一般 4.18+ 且需 BTF 支持），且需要处理高基数标签带来的内存压力。

流式采集 指从 Kafka、Pulsar、Kinesis 等消息队列消费，或从网络流量镜像中解析。它面向的是已经汇聚过的数据，吞吐高、延迟低，适合做跨源关联的入口。

部署拓扑的三种形态

小规模环境可以直接让 Agent 把数据推到中心 Kafka，链路短、运维简单。但当终端数量上千、跨地域分布时，直连会带来两个问题：一是跨公网传输不稳定，二是中心入口成为单点。此时应引入区域汇聚节点：每个区域部署一台汇聚机，接收本区域 Agent 和 Syslog 数据，做初步过滤和压缩，再通过专线或 TLS 隧道转发到中心。汇聚节点本身要配置本地磁盘队列，断网时先落盘，恢复后按序补发。

容器环境则更适合DaemonSet 模式：每个节点跑一个采集 Pod，通过 hostPath 读取节点日志目录，通过 eBPF 采集内核事件，再统一发往集群内的 Kafka。这种模式下采集器与业务 Pod 解耦，业务扩容不需要改采集配置。

可靠性设计的四个关键点

第一，至少一次投递与幂等消费。 采集端在收到下游 ACK 后才删除本地队列中的记录，网络抖动时可能重复发送。因此下游必须用 event_id 或 (source, timestamp, hash) 做去重，去重窗口一般设为 5～15 分钟，覆盖重传延迟。

第二，背压与限流。 当处理层消费能力下降时，队列积压会向上游传导。采集端要设置内存队列上限，超过阈值时优先丢弃低优先级日志（如 debug 级别），而不是无限制占用内存导致 Agent 崩溃。

第三，时间同步。 跨源关联依赖事件时间。所有采集节点必须运行 NTP 或 chrony，偏差控制在 100ms 以内。Syslog 设备若时间不准，应在采集端记录接收时间作为补充字段，关联时以事件时间为主、接收时间为辅。

第四，可观测性。 采集链路自身也要被监控：每个采集器的发送速率、队列深度、丢弃计数、解析失败率都应上报。当某台 Agent 的发送速率突然归零，往往意味着它被停止或网络被切断，这本身就是一条安全告警。

部署顺序建议：先打通一条最小链路（单台 Agent → 本地队列 → 中心 Kafka → 消费验证），确认端到端延迟和字段完整后，再批量铺开。不要一次性全量上线，否则故障定位会非常困难。

一个可参考的采集配置片段

# 示例：主机 Agent 输出段（参数为教学示例，非实测值）
output:
  kafka:
    hosts: ["kafka-01.corp:9092", "kafka-02.corp:9092"]
    topic: "raw.host.events"
    compression: gzip
    required_acks: 1          # 至少一个副本确认
    max_retries: 5
    backoff: 2s
    bulk_max_size: 2048       # 单批事件数上限
  disk_queue:
    path: /var/lib/agent/queue
    max_size: 2GB             # 断网时可缓冲约数小时
    write_ahead: true

这段配置的核心是 disk_queue 与 required_acks 的组合：前者保证断网不丢，后者保证消息至少落到一个 broker 副本。两者配合，才能在节点重启、网络闪断、broker 切换等常见故障下维持数据完整性。

采集层是整个遥测体系的地基。地基不稳，后面的关联规则再精细也会因为数据缺失而失效。工程上宁可多花时间在缓冲、去重、时间同步这三件事上，也不要急于堆检测规则。