日志数据收集与存储基础归纳总结

日志收集与存储，是整个异常检测体系的「地基」。我见过不少团队，模型调得挺准，结果数据源有断层，最后线上跑起来全是坑。说白了，如果地基不牢，上层算法再花哨也白搭。

这一章，我就把日志从「产生」到「落地」的关键环节拆开聊聊。你想想看，日志到底从哪里来？怎么才能不漏不掉地收上来？存在哪里才方便后续分析？这三个问题想明白了，后面建模才踏实。

1. 日志数据的来源与分类

日志的本质，是系统运行时留下的「文字脚印」。脚印的种类很多，我习惯按来源分成下面几类：

我在项目中遇到过一种情况：某次线上故障，应用日志里全是「Connection refused」，但系统日志被归档了，查不到当时的内存和磁盘状态。最后定位是堆外内存泄漏——如果两类日志能关联上，排查时间至少缩短一半。

2. 日志采集方式：选对工具比调参数更重要

日志怎么收？无外乎推和拉两种模式。推模式是日志源主动发，拉模式是采集端定期去轮询。我个人更倾向「推 + 缓冲」的组合，原因看完你就懂了。

2.1 常见采集方式对比

讲个小故事。以前做过一个项目，运维图省事，直接在 Java 应用里用 log4j 写远程 Socket，结果日志量一上来，应用线程被阻塞，拖垮了业务接口。后来换成 Filebeat 从本地文件读取，加上 Kafka 缓冲，问题就消失了。所以啊，采集层一定要和业务层解耦。

3. 存储方案：选型要看「读」和「写」的平衡

日志存哪里？选项很多，但得先想清楚你后续想怎么查。是做实时告警？还是做离线研判？还是两者都要？

我目前做日志异常检测，最常用的组合是：Fluentd → Kafka → ClickHouse。ClickHouse 的列式存储对分析类查询特别友好，用 SQL 就能搞定聚合和滑动窗口，比 Elasticsearch 省了至少一半的机器。当然，如果你团队对 Elastic Stack 很熟，ES 依然是入门首选。

4. 数据收集与存储的整体流程

下面这张图梳理了从日志产生到入库的完整链路。我把它叫做「四段式」：生成 → 采集 → 传输 → 存储。

5. 实践中的避坑清单

嗯，最后列几个我反复提醒团队检查的点。这些细节不注意，后面模型训练时你会一头雾水。

• 时间戳统一 —— 日志里有用 UTC 的，有用本地时间的，甚至还混着无时区的时间。我建议所有日志在采集时就转成 UTC 毫秒时间戳，否则聚合窗口会错位。
• 日志日志轮转（rotation） —— Linux logrotate 默认可能按天切文件，但如果日活量巨大，一天一个文件会膨胀到几个 GB。配置 size 100M 配合 rotate 7 更合理，采集器也要能跟上文件切换。
• 字段裁剪 —— 不是日志里所有字段都对异常检测有用。比如 HTTP 请求的完整 body 可能包含敏感信息，又占存储。我通常在采集端做一层 filter，只保留关键字段：时间戳、级别、模块、错误码、耗时等。
• 采样 vs 全量 —— 对于高基数的 trace ID 或者 session ID，如果全量存储成本太高，可以考虑对正常日志按 1:1000 采样，异常日志全量保留。前提是你有办法识别「可能异常」。我在做流量日志时，就用过两层过滤：第一层基于规则标记可疑，第二层全量存储被标记的日志。