3、数据采集架构：Agent架构、数据采集策略、数据压缩与传输、数据存储方案
聊到EDR的数据采集，我脑子里第一个蹦出来的词就是「地基」。你想想看，后面所有的检测、分析、溯源，全得靠这层数据撑着。地基没打好，上面盖的楼再漂亮也是危房。这一章，我就把我在实际项目中踩过的坑和积累的经验，掰开了跟你聊聊。
3.1 Agent架构：轻量还是重量，这是个问题
Agent是EDR的「眼睛」和「耳朵」。它部署在终端上，负责把系统里发生的事记录下来。我个人习惯把Agent架构分成两大类：内核态和用户态。
- 内核态Agent：直接跑在操作系统内核里。优点是权限高，能看到进程创建、文件操作、网络连接这些底层行为。缺点是开发难度大，一个蓝屏就能让你半夜被叫起来。
- 用户态Agent：以普通进程方式运行。优点是稳定，挂了不影响系统。缺点是有些敏感事件它根本看不到，比如某些内核级Rootkit的行为。
我的建议是： 对于Windows环境，尽量采用「内核驱动 + 用户态服务」的混合架构。内核驱动负责采集关键事件，用户态服务负责数据处理和上报。这样既保证了数据完整性，又降低了系统崩溃的风险。
我在项目中遇到过一家客户，他们全用用户态Agent，结果被一个内核级木马绕过了所有监控。嗯，那场面，挺尴尬的。
3.2 数据采集策略：不是所有数据都值得采
很多新手容易犯一个错误——恨不得把终端上每个字节都记录下来。结果呢？磁盘爆了，网络堵了，业务部门投诉电话打爆了。
数据采集的核心原则就一句话：在正确的时间，采集正确的事件，以正确的频率。
我一般把采集策略分为三个层级：
| 层级 | 采集内容 | 采集频率 | 典型场景 |
|---|---|---|---|
| L1（基础） | 进程创建、网络连接、文件变更 | 实时 | 日常监控 |
| L2（增强） | 注册表操作、DLL加载、计划任务 | 实时或近实时 | 威胁狩猎 |
| L3（深度） | 内存扫描、API调用链、网络包内容 | 按需触发 | 事件响应 |
为什么会这样设计？说白了，L3的数据量太大了。如果全天候采集，一个终端一天就能产生几十GB的数据。所以，我通常只在检测到可疑行为时，才触发L3级别的采集。
避坑指南： 我曾经在一个金融客户那里，把L3级别的API调用链采集默认开启了。结果三天后，他们的运维找我哭诉——所有终端的硬盘都满了。从那以后，我学乖了，默认只开L1，L2和L3全部做成动态策略。
3.3 数据压缩与传输：省带宽就是省钱
数据采完了，怎么传回服务器？这里有两个关键点：压缩和传输协议。
先说压缩。 我常用的压缩算法是LZ4和Zstandard。LZ4压缩速度极快，适合CPU资源紧张的终端；Zstandard压缩率更高，适合带宽有限的环境。
// 伪代码示例：数据压缩策略
if (cpu_usage < 50%) {
use_compression("zstd", level=3); // 高压缩率
} else {
use_compression("lz4", level=1); // 低CPU开销
}再说传输。 我个人强烈推荐使用gRPC双向流。为什么？因为它支持断点续传、TLS加密、而且协议效率高。我曾经见过有人用HTTP轮询，结果终端一多，服务器直接被连接数打爆了。
注意： 传输过程中一定要做数据完整性校验。我遇到过网络抖动导致数据包损坏的情况，如果没有校验，分析出来的结果全是错的。我的做法是每个数据包都带一个CRC32校验码，服务端收到后重新计算比对。
3.4 数据存储方案：写得好不如查得快
数据到了服务端，存哪里？这是个老生常谈的问题。我见过不少团队把数据一股脑全塞进Elasticsearch，结果查询慢得像蜗牛。
我的存储方案是分层设计：
- 热数据（最近7天）：放在SSD上，用Elasticsearch或ClickHouse。查询要快，毫秒级响应。
- 温数据（7-30天）：放在普通SATA盘上，同样用ClickHouse。查询可以慢一点，秒级响应。
- 冷数据（30天以上）：压缩后存到对象存储（比如MinIO或S3）。查询需要解压，分钟级响应。
你可能会问，为什么不用Elasticsearch存所有数据？嗯，我试过。当数据量超过10TB时，Elasticsearch的查询性能会急剧下降，而且索引重建能把CPU跑满。后来我换成了ClickHouse，查询速度快了不止一个数量级。
核心经验： 数据存储方案一定要考虑「查询模式」。如果你的分析师经常做时间范围查询，那就按时间分区；如果经常按进程名查询，那就建好倒排索引。别等数据存进去了再想怎么查，那时候就晚了。
好了，数据采集架构这块就聊这么多。记住，好的架构不是功能最全的，而是最合适的。根据你的业务场景、终端数量、网络带宽来选型，别盲目追求高大上。