日志采集基础：日志格式、采集方式归纳总结

做日志采集这几年，我先从一个问题开始聊——你连日志长什么样都不清楚，怎么知道该用什么工具去抓？

我刚开始接手第一个日志项目时，领导丢给我一堆 `.log` 文件，让我“把数据弄到平台上”。我打开一看，每行格式都不一样，有空格分隔的、有用 `|` 分隔的、还有纯 JSON 的。当时我就意识到，不懂日志格式，采集就是盲人摸象。

日志格式：先摸清楚“原料”长什么样

日志格式说白了就是文本的排列规则。我把它归成三类，大多数场景都跑不出这个圈。

你想想看，如果日志是 JSON 结构，你用简单的正则硬拆，不仅累还容易丢字段。反过来，如果日志是纯文本乱序，你强行用 JSON 解析器去读，程序直接报错。

采集方式：从“读文件”到“收网络包”

日志格式定下来，下一步就是怎么把数据搞到手。我常用的方式有四种，具体用哪种，得看日志的产生方。

1. 直接读取文件 —— 最老派但最稳。用 tail -F 或 Filebeat / Fluent Bit 这类 Agent 监听文件变化。适合应用写到本地磁盘的日志。
2. 标准输出捕获 —— 容器化时代的标配。Docker / Kubernetes 默认把容器的 stdout/stderr 重定向到宿主机，然后用采集 Agent 捞走。我在公司上 K8s 时踩过一次坑：有的应用日志走 stdout，有的走文件，两种采集方式都要配。
3. 网络日志接收 —— 比如 Syslog 服务器监听 UDP 514 端口，或者 HTTP 上报。适合网络设备、集中式日志源。我记得有一次客户的防火墙日志就是 Syslog 格式，我用 rsyslog 转发到 Kafka，省了一台采集 Agent。
4. Agent 主动拉取 —— 比如使用 Prometheus 的 exporter 模式，或者脚本定期从数据库导出日志表。不是实时，但适合批处理场景。

避坑指南：我曾经吃过这些亏

• 千万不要忽略日志滚动 —— logrotate 或轮转策略会把当前日志重命名，如果你的采集 Agent 还在读旧 inode，就会漏数据。我用的解决方法是“按文件 inode + 文件名”双重追踪。
• 编码陷阱 —— 有的 Windows 应用输出 GBK，Linux 采集端默认 UTF-8，解析直接乱码。一定要在采集 Agent 的配置中显式指定编码。
• 时间戳时区不统一 —— 同一个集群里，有的日志用 UTC，有的用 CST。我后来强制要求所有日志必须带时区偏移，或者在采集阶段统一转化为 UTC+0。

核心流程图：日志从产生到落地的全链路

这张图把上面讲的格式和采集方式串起来了。你可以把它当作模板，每接到一个新日志源就往里填。

这张图我把它叫做“日志采集三明治”——上面是原料层（日志源），中间是加工层（格式 + 采集），下面是下锅层（中间件和存储）。每次接入新项目，我都会先对照这幅图走一遍，基本不会漏。

小结：记住两个“先”

• 先看格式，再选工具。 别上来就装个 Logstash 瞎配一通。
• 先评估来源，再定采集方式。 文件、网络、容器各有各的最佳实践。