日志采集架构：Agent采集模式、无侵入采集模式、边缘采集与集中采集对比
日志采集是整个日志系统的入口，也是第一道关卡。我见过太多团队，日志采集没做好，后面分析、复盘全白搭。说白了，采集架构选错了，后面再怎么优化也是事倍功半。
今天咱们就聊聊四种主流的采集模式：Agent采集、无侵入采集、边缘采集、集中采集。每种模式都有它的脾气，选对了事半功倍，选错了……嗯，我踩过坑，后面会讲。
一、Agent采集模式：最常用的方案
Agent采集，说白了就是在每台机器上装一个采集程序。它负责读日志文件、解析、发送。这是目前最成熟的方案。
核心思路：部署轻量级Agent到每台服务器，主动采集日志。
我个人的习惯是，只要条件允许，优先用Agent模式。为什么？因为它可控。你想想看，Agent就在机器上，能拿到最原始的数据，处理逻辑也灵活。
常见的Agent有：
- Filebeat：轻量，适合文件采集
- Fluentd：插件丰富，适合复杂场景
- Logstash：功能强，但吃资源
- 自研Agent：定制化高，但维护成本大
举个例子，我之前在电商公司做日志系统，用的就是Filebeat + Kafka的架构。每台应用服务器上部署Filebeat，采集Nginx和业务日志，直接推送到Kafka。简单、稳定、高效。
# Filebeat 配置示例
filebeat.inputs:
- type: log
enabled: true
paths:
- /var/log/nginx/access.log
- /var/log/app/*.log
output.kafka:
hosts: ["kafka1:9092", "kafka2:9092"]
topic: "app-logs"
partition.round_robin:
reachable_only: true小技巧：Agent采集时，建议加一个本地缓存。万一网络抖动，日志不会丢。Filebeat的registry文件就是干这个的。
二、无侵入采集模式：不动业务代码
有些场景下，你没法在机器上装Agent。比如容器环境、Kubernetes集群，或者业务方不让动服务器。这时候，无侵入采集就派上用场了。
无侵入采集，说白了就是不改业务代码，不装Agent，通过其他方式拿到日志。常见的有：
- Sidecar模式：在Pod里挂一个日志采集容器
- 标准输出采集：采集Docker容器的stdout/stderr
- 网络抓包：通过tcpdump抓网络流量还原日志
- 系统调用劫持：用eBPF技术拦截write系统调用
我记得有一次，一个老项目要接入日志系统，但业务方死活不让装Agent，说会影响性能。最后我用了Sidecar模式，在K8s里每个Pod挂一个Fluent Bit容器，采集业务容器的日志文件。业务方没话说，因为确实没动他们的代码。
注意：无侵入采集虽然方便，但性能损耗不可忽视。尤其是eBPF和网络抓包，CPU开销不小。我曾经在生产环境用过eBPF采集，结果CPU飙升了15%，吓得我赶紧切回Agent模式。
三、边缘采集模式：在源头做预处理
边缘采集，就是在数据产生的源头附近做预处理。不是一股脑全发到中心，而是在边缘节点先过滤、聚合、压缩。
这种模式特别适合：
- IoT场景：设备多、网络差，不能全量传输
- 边缘计算：在边缘节点做实时分析
- 跨地域部署：多个机房，先本地处理再汇总
我做过一个项目，全国有50多个机房，每个机房每天产生几十TB的日志。如果全量传到中心，带宽根本扛不住。后来我们在每个机房部署了边缘采集节点，先做日志清洗、去重、聚合，只把关键数据传到中心。带宽直接降了80%。
# 边缘采集节点配置示例
input:
- type: file
path: /data/logs/*.log
filter:
- type: grep
match: "ERROR|WARN|FATAL" # 只保留错误和警告日志
- type: aggregate
window: 60s
key: "service_name"
fields:
- count
- avg_response_time
output:
- type: kafka
topic: "edge-logs"
compression: snappy # 压缩传输核心优势：边缘采集能大幅降低网络带宽和中心存储压力。说白了，就是「数据在源头就处理好了，别给中心添乱」。
四、集中采集模式：统一收口
集中采集，就是所有日志都发到一个中心节点。这个中心节点可能是Kafka、Elasticsearch、或者自研的日志平台。
这种模式的好处是：
- 统一管理：所有日志在一个地方，好查好分析
- 全局视图：跨服务的链路追踪、全链路分析
- 简化运维：不用管每个节点的采集配置
但缺点也很明显：
- 单点瓶颈：中心节点扛不住，整个系统就崩了
- 网络依赖：网络一断，日志就丢了
- 成本高：存储、带宽、计算资源都集中在中心
我建议，集中采集适合中小规模系统。如果日均日志量超过10TB，最好考虑边缘采集+集中采集的混合模式。
五、四种模式对比
咱们直接看表格，一目了然：
| 对比维度 | Agent采集 | 无侵入采集 | 边缘采集 | 集中采集 |
|---|---|---|---|---|
| 部署复杂度 | 中 | 低 | 高 | 低 |
| 性能影响 | 低 | 中 | 低 | 高（中心节点） |
| 数据实时性 | 高 | 中 | 中 | 高 |
| 网络带宽 | 高 | 高 | 低 | 高 |
| 适用场景 | 通用 | 容器/受限环境 | 大规模/跨地域 | 中小规模 |
| 维护成本 | 中 | 低 | 高 | 中 |
六、架构选型建议
说了这么多，到底怎么选？我个人的经验是：
- 优先Agent模式：除非有特殊限制，否则Agent模式最稳
- 容器环境用Sidecar：K8s里用Sidecar采集，别用DaemonSet，避免资源竞争
- 大规模用边缘采集：日均TB级日志，必须做边缘预处理
- 混合模式最灵活：边缘采集做预处理，集中采集做统一收口
避坑指南：我曾经在一个项目里，所有日志都走集中采集，结果Kafka集群扛不住，频繁OOM。后来加了边缘采集节点做限流和聚合，问题才解决。记住，集中采集不是万能的，一定要考虑流量洪峰。
七、整体架构图
下面这张图展示了四种采集模式的整体架构关系：
从图上可以看出来，不同的数据源适合不同的采集模式。没有银弹，只有最适合你场景的方案。