一、日志采集概述：从“黑匣子”到“数字足迹”
1.1 日志到底是什么？
先聊聊最基础的问题——日志。说白了，日志就是系统运行过程中产生的“日记”。每一条记录，都记录了一个事件的发生时间、来源、状态和结果。
我个人习惯把日志分成三类：
- 系统日志：操作系统、内核、硬件驱动产生的记录。比如服务器宕机前留下的最后一条消息。
- 应用日志：业务代码里打印的记录。比如用户登录失败、订单支付超时。
- 安全日志：防火墙、入侵检测、认证系统的记录。比如谁在凌晨三点尝试暴力破解 SSH。
还记得我第一次接手线上事故排查时，系统已经崩溃了半小时。翻遍所有服务器，发现日志格式五花八门——有的用竖线分隔，有的用逗号，还有的直接把异常堆栈和正常日志混在一起。那感觉，就像在垃圾堆里找一张发票。
所以，日志的价值其实就一句话：它是系统运行状态的“黑匣子”。没有它，出问题了你连从哪查起都不知道。
1.2 为什么非要搞标准化？
好，现在你知道日志很重要了。但问题来了——日志格式不统一会怎样？
从那以后，我接手任何项目的第一件事，就是定日志格式规范。
标准化带来的好处其实很直接：
| 维度 | 非标准化 | 标准化 |
|---|---|---|
| 采集效率 | 每接入一种新日志，就要写一个解析器 | 一次配置，所有系统通用 |
| 排查速度 | 人工翻看、肉眼匹配字段 | 工具一键检索、聚合、分析 |
| 告警准确度 | 规则难以统一，误报率高 | 统一字段名，规则清晰可靠 |
| 团队协作 | 开发、运维、安全各看各的 | 一个平台，所有人说同一种语言 |
说白了，标准化就是为组织里的所有人约定一套通用的“话语体系”。你不需要学三种方言才能读懂日志。
1.3 常见日志格式：六种主流“方言”
业界折腾了这么多年，沉淀出了几种公认的日志格式。我按实际使用频率排个序：
我个人的建议是——新项目优先用 JSON 或 GELF；老系统兼容改造，优先考虑 Syslog 或 CEF。
1. JSON（JavaScript Object Notation）
现在最流行的格式，没有之一。所有字段以键值对形式组织，解析简单、扩展性好。
{
"timestamp": "2025-01-15T10:30:00.123Z",
"level": "ERROR",
"logger": "com.example.order.service",
"message": "订单支付超时",
"order_id": "ORD-20250115-0001",
"amount": 299.00,
"duration_ms": 3500
}
优点很明显：人类可读、机器易解析、支持嵌套结构。
缺点就是——体积偏大。大量重复的键名会占用带宽和存储。
2. Syslog（系统日志协议）
老牌选手了。RFC 5424 定义的标准，几乎所有网络设备、Linux 系统都原生支持。
<14>1 2025-01-15T10:30:00.123Z myhost.example.com sshd 1234 - [timeQuality tzKnown="1" isSynced="1"] Failed password for root from 192.168.1.100 port 22 ssh2
嗯，这里要注意：Syslog 的字段位置是固定的，扩展性一般。如果你想加自定义字段，就得用它的结构化数据（SD-ELEMENT）部分，写法比较绕。
3. CEF（Common Event Format）
ArcSight 定义的格式，在安全领域非常常见。它是一种“标题+扩展字段”的结构。
CEF:0|Security|ThreatManager|1.0|100|检测到恶意流量|10|src=192.168.1.100 dst=10.0.0.1 requestMethod=GET
你看，前面用竖线分隔的 7 个字段是定死的，后面是“key=value”的可扩展部分。做安全运营的同学应该很熟悉它。
4. LEEF（Log Event Extended Format）
IBM 家的格式，和 CEF 类似，也是个“定长头+键值对”的结构。
LEEF:1.0|IBM|QRadar|1.0|100|事件描述|devTime=2025-01-15T10:30:00Z srcIP=192.168.1.100 dstIP=10.0.0.1
它和 CEF 的区别啊——说白了就是头部字段的排序和命名不一样。实际选型时，往往取决于你上游用的是哪个厂的 SIEM 系统。
5. CSV（逗号分隔值）
最原始的表格化数据格式。你可以在 Excel 里直接打开它。
2025-01-15 10:30:00.123,ERROR,订单支付超时,ORD-20250115-0001,299.00,3500
好处？简单，极其简单。坏处？字段顺序一旦约定好就不能变，扩展字段必须追加在后面。我见过太多人改了一个字段后就导致解析全线崩盘的情况。
6. GELF（Graylog Extended Log Format）
Graylog 搞出来的格式，专门为日志采集优化的 JSON 变体。它严格要求 version、host、short_message、timestamp 这四个字段必须存在。
{
"version": "1.1",
"host": "myhost.example.com",
"short_message": "订单支付超时",
"timestamp": 1736929800.123,
"level": 3,
"_order_id": "ORD-20250115-0001",
"_amount": 299.00
}
自定义字段前面加下划线，这是 GELF 的约定。它在日志采集的场景下非常顺手，因为接收端（Graylog）不需要额外配置就能自动解析。
1.4 这张图帮你理清思路
下面这张图，是我做课程时归纳的知识结构。你可以把它当成“日志格式选型指南”来用：
1.5 几个必懂的避坑点
- 时间戳格式不统一：有的用 Unix 时间戳（毫秒），有的用 ISO 8601。建议全系统统一使用 UTC + ISO 8601。
- 字段名冲突：比如 A 系统把“用户ID”叫
user_id，B 系统叫uid。标准化后，必须约定唯一的字段名。 - 嵌套层级过深：JSON 好是好，嵌套 5 层以上，解析性能明显下降。我一般建议最多 3 层。
- 特殊字符处理：日志内容里出现换行符、引号、反斜杠，不做转义就直接破坏格式。这是最容易被忽略的问题。