📚 课程目录第3章日志采集架构

3. 日志采集架构：Agent采集、集中式采集、边缘采集方案对比

日志采集是整个审计追溯体系的「第一公里」。

我见过太多项目，后端分析平台建得花里胡哨，结果日志没采上来，或者采上来的数据缺胳膊少腿。说白了，采集架构选错了，后面全是白搭。

这一节，咱们把三种主流方案掰开揉碎聊清楚。Agent采集、集中式采集、边缘采集，各自适合什么场景，坑在哪，我踩过的雷也一并交代。

Agent采集，就是在每台设备或工控机上装一个小程序。它负责盯着日志文件、系统事件或设备输出，抓到新数据就往服务器推。

我最早做的一个汽车零部件产线项目，用的就是Agent。每台PLC旁边挂一台工控机，Agent跑在工控机上，采集PLC的报警日志和运行状态。

核心特点：

但有个问题——Agent多了，管理就是噩梦。我记得有个项目部署了300多个Agent，版本升级一次，挨个远程登录，折腾了两天。后来我学乖了，必须用带集中管理面板的Agent方案。

我的建议：如果设备数量少于500台，且网络环境稳定，Agent采集是最省心的方案。选型时优先看是否支持远程配置推送和版本批量升级。

集中式采集，就是所有日志通过共享网络路径或统一接口，汇聚到一台中央服务器上采集。

举个例子：产线上所有设备的日志都写到同一个NAS共享文件夹，或者通过syslog统一发到一台日志服务器。

这种方案的好处是——不用装Agent，运维简单。但坏处也很明显：

我曾经在一个电子组装厂试过集中式采集。刚开始50台设备，跑得挺顺。后来扩到200台，中央服务器的磁盘I/O直接打满，日志写入延迟从秒级变成了分钟级。最后不得不拆成多台服务器，其实已经变成了变相的边缘采集。

避坑指南：集中式采集只适合设备数量少（建议100台以内）、日志量小（每天不超过50GB）的场景。别想着后期再扩容，架构一开始就得想清楚。

边缘采集，就是在靠近设备的地方（车间级或产线级）部署一台边缘网关或边缘服务器。它先在本地区域完成日志的采集、清洗、格式化，然后再批量上传到中心平台。

我目前参与的一个半导体产线项目，用的就是边缘采集。每个车间部署一台边缘服务器，负责采集该车间内所有设备的日志。边缘服务器上跑着数据预处理脚本，把不同厂商、不同协议的日志统一成JSON格式，再压缩上传。

边缘采集的核心优势：

你想想看，一个车间200台设备，每台每秒产生10条日志。如果全量上传到中心，带宽和存储都扛不住。但在边缘节点上，我可以只保留「报警级别为ERROR或WARN」的日志，INFO级别的日志只保留统计摘要。这样上传量能减少80%以上。

对比维度	Agent采集	集中式采集	边缘采集
部署复杂度	中等（每台设备装Agent）	低（无需客户端）	较高（需部署边缘节点）
资源占用	低（Agent轻量）	低（设备无负担）	中等（边缘节点需一定算力）
网络依赖	中等（支持断网续传）	高（断网即丢数据）	低（本地缓存能力强）
扩展性	好（加设备加Agent即可）	差（中央服务器易成瓶颈）	好（加车间加边缘节点）
数据预处理	弱（Agent通常只采集）	无（原始数据直接上传）	强（边缘侧可清洗、聚合）
适用规模	中小规模（500台以内）	小规模（100台以内）	中大规模（1000台以上）
典型场景	离散制造、设备分散	实验室、小产线	半导体、汽车、连续流程

说了这么多，到底怎么选？我一般按这个流程走：

一个小技巧：实际项目中，三种方案往往混合使用。比如核心设备用Agent采集，非核心设备用集中式采集，车间级再用边缘节点做统一汇聚。别被「非此即彼」的思路限制住。

下面这张图，把三种架构的拓扑关系画清楚了。你可以直观看到数据流的走向和每个环节的职责。

如果你现在要搭一套产线审计日志采集系统，我的建议是：