审计日志采集与存储：Agent采集、ELK与存储策略
说实话，做审计日志异常检测这么多年，我最大的体会是——**采集和存储才是地基**。告警算法再漂亮，如果日志丢了、格式乱了、查起来慢得像蜗牛，一切都是白搭。我自己就踩过坑，今天把这部分核心内容摊开了聊。
3.1 Agent采集：第一公里的质量
Agent是采集的起点。你想想看，如果源头数据不靠谱，后面所有分析都是垃圾进垃圾出。我项目中常用的采集Agent有Filebeat、Logstash、Fluentd、rsyslog，各自侧重不同。
| Agent | 适用场景 | 特点 |
|---|---|---|
| Filebeat | 轻量日志文件采集 | 资源占用极低，内置背压机制 |
| Logstash | 复杂过滤和转换 | 功能强，但吃内存，慎用在高并发 |
| Fluentd | 统一日志层 | 插件丰富，Ruby生态，适合多源 |
| rsyslog | 系统日志采集 | 原生速度，但结构化能力弱 |
推荐组合：小规模用Filebeat→直接送Elasticsearch；大规模在中间加Kafka缓冲，再用Logstash消费。
multiline.pattern就能搞定，但很多人忽略。
Agent还要注意**采集频率**和**断线重连**。如果日志生成是突发的（比如秒杀活动），高频轮询会炸CPU。我习惯用tail-based采集（如Filebeat的backoff参数），压力小很多。
3.2 集中式日志系统：ELK实战
ELK（Elasticsearch, Logstash, Kibana）是目前最主流的集中式日志方案，没有之一。先看各自分工：
| 组件 | 职责 | 我常踩的坑 |
|---|---|---|
| Elasticsearch | 存储+检索 | 索引设计不合理会导致写入瓶颈，我曾在未设置分片数时被IO打满 |
| Logstash | 数据处理管道 | filter里滥用grok正则，CPU飙升到100% |
| Kibana | 可视化 | 别把大量原始日志做成仪表盘，ES会哭 |
传输管线我一般这样搭：
源（应用/系统）
→ Filebeat（采集+压缩）
→ Kafka（消息队列，削峰填谷）
→ Logstash（过滤+格式化）
→ Elasticsearch（存储）
→ Kibana（查询+告警）索引设计原则：按时间命名（如audit-2025-04-07），分片数控制在节点数的1~3倍，副本数设1做容灾。我见过有人为图省事用默认5分片1副本，结果集群在流量高峰直接熔断。
3.3 存储策略：分层与压缩
日志存储是烧钱大户。你想想看，审计日志按合规要求可能要存一年甚至更久。全上SSD？成本吃不消。全上冷存储？查询慢到怀疑人生。所以分层是必然选择。
| 层级 | 存储介质 | 保留周期 | 典型查询场景 |
|---|---|---|---|
| 热数据 | SSD（NVMe） | 7~30天 | 实时告警、紧急排查 |
| 温数据 | HDD | 1~6个月 | 周报、趋势分析 |
| 冷数据 | 对象存储（S3/OSS） | 6个月~永久 | 合规审计、历史回溯 |
压缩也很关键。我遇到过团队把所有字段都原封不动索引进去，磁盘空间一周就爆了。建议：
- 只对需要检索的字段建索引（如IP、user_id），其他存为
ignored或text不索引 - 开启
_source的includes/excludes，只保留必要原始字段 - 开启ES的
best_compression（默认LZ4，可换为ZSTD压缩比更高）
3.4 核心流程梳理
下面这张图把整个采集→存储的链路串起来了。我自己每次做架构设计都会先画一遍这个图，确保每个环节都有冗余和监控。
概括一下，核心就三条：Agent稳、管道顺、分层合理。我每次做新项目都会把这三条写进架构检查清单，几乎每次都能提前发现隐患。