第 2 章：RFC 3164 vs RFC 5424——Syslog 协议的新旧交锋
聊 Syslog，绕不开两个标准：RFC 3164 和 RFC 5424。前者像是老前辈，我从刚入行就在用它；后者是后来者，我在生产环境里也折腾过不少次。说白了，它们俩定义了 syslog 消息长什么样、字段放哪、切分规则是什么。今天我就把这两个标准掰开揉碎，说说消息格式的差异，也聊聊哪些坑我踩过。
2.1 为什么要先聊格式？
很多人一开始觉得 syslog 就是一串“日期 + 主机名 + 信息”，拿过来用正则切就行。但实际运维时，一旦跨设备、跨版本、跨厂商，解析就会崩。我记得有一次审计平台突然报错，查了半天发现一台 Cisco 交换机发了 RFC 5424 的消息，其他设备全是 3164，解析器根本没处理那个新格式的头部。所以，搞明白格式差异，是避免“日志丢一半”的基础。
2.2 RFC 3164：传统格式
RFC 3164 是 2001 年发布的，描述的是 BSD syslog 协议。它的消息结构很简单，大致长这样：
<PRI>TIMESTAMP HOSTNAME MSG我习惯叫它“左对齐三件套”。优先级、时间戳、主机名，后面跟消息正文。注意，这里没有明确的“结构体”概念，很多字段靠空格或特定字符推断。举个例子：
<34>Oct 11 22:14:15 mymachine su: 'su root' failed for lonvick on /dev/pts/8你看，时间戳用的月份缩写+日期+时间，没有年份，没有时区。主机名就是第一个空格后的单词。消息正文从第二个空格后开始，里面还带个冒号分隔进程名和消息内容。这种“自由格式”在实际中带来一个典型问题：解析器必须做大量启发式猜测。我在项目中遇到过一台旧版 AIX 机器，它的时间戳变成了 "Oct 11 22:14:15.123"，多了一个微秒，结果老解析器直接跳过了整条日志。嗯，这就是 3164 的硬伤——规范太模糊。
Tip：如果你还在用 RFC 3164 格式的日志源，建议在接收端做两层解析：第一层按标准切，第二层用正则做容错。我曾经用这个方法搞定了一堆古董路由器。
2.3 RFC 5424：现代化格式
RFC 5424 是 2009 年推出的，彻底重写了消息结构。它的格式更像一个可扩展的“信封”：
<PRI>VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID [STRUCTURED-DATA] MSG为什么要加这么多字段？说白了就是为了让机器好解析。每个字段都用空格分隔，时间戳强制使用 ISO 8601 格式（带时区和精度），主机名不允许有歧义。最关键的改进是 结构化数据，用方括号包裹的键值对：
<165>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47 [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"] BOM'su root' failed for lonvick on /dev/pts/8你看，版本号 "1" 紧跟优先级，时间戳多了 "T" 分隔、时区 "Z"、微秒 ".003"。主机名后面紧跟 "su"（应用名）、"-"（进程名，这里为空）、"ID47"（消息 ID）。结构化数据段 [exampleSDID@32473 ...] 可以携带任意自定义字段。消息正文前面还有个 "BOM" 表示 UTF-8 字节顺序标记。这对于跨语言、跨时区的审计场景非常友好。
注意：RFC 5424 虽然强大，但不是所有设备都支持。我见过一些网络设备宣称支持“syslog”，但实际上只发了 3164 格式。如果你混合接收两种格式，接收端必须能自动识别版本（看优先级后面的数字是否是 "1"）。
2.4 关键差异对比表
下面我把两个协议的核心差异整理成一张表，方便你快速对照——这个表我在给团队讲课时经常用。
| 对比维度 | RFC 3164 | RFC 5424 |
|---|---|---|
| 发布年份 | 2001 | 2009 |
| 消息版本 | 无版本字段（隐含版本0） | 显式版本号（第2字段） |
| 时间戳格式 | Mmm dd hh:mm:ss （无年、无时区） | ISO 8601 （YYYY-MM-DDTHH:MM:SS.mmmZ） |
| 主机名 | 没有规范，可能为空、FQDN或IP | 强制要求，推荐FQDN |
| 进程标识 | 混在MSG中，靠空格猜测 | 独立字段（APP-NAME, PROCID） |
| 结构化数据 | 不支持 | 支持，用键值对扩展 |
| 字符编码 | 未定义（常出现乱码） | UTF-8 强制，支持BOM |
| 消息长度 | 通常 ≤1024 字节 | 可扩展，支持更长的消息 |
| 设备兼容性 | 极广（几乎所有旧设备） | 现代设备逐渐支持 |
核心要点：解析 syslog 时，先看第二个字段是否为数字，如果是 "1" 就走 5424 解析器，否则按 3164 处理。这个探测逻辑我写在了所有接收器的第一行，省了无数个调试夜。
2.5 协议格式选择指南
这两种格式今天仍然共存。那么什么时候该用哪个？我个人经验如下：
- 纯内部网络、设备老旧：3164 足够简单，接收端写点魔法正则也能对付。但要做好“丢字段”的心理准备。
- 需要做安全审计、合规归档：必须上 5424。结构化数据能让你把事件ID、用户、源IP、执行权限等字段原原本本带上，审计员查起来舒服很多。
- 混合场景：接收端统一转成 5424 内部格式。我之前在日志集中器里写了个转换层，把 3164 消息里的信息抽出来，构造一个最小化的 5424 消息，再扔给后端 Kafka。这样下游分析程序只要认一种格式。
避坑指南：我曾经在迁移项目中折腾了一周，只因为一台防火墙的 5424 消息里 HOSTNAME 字段居然是个 IPv6 地址，而下游解析器把它当成非法主机名直接丢弃。所以，拿到 5424 消息后，一定要对每个字段做容错校验，别假设它一定符合标准。
2.6 一眼看懂：协议结构对比
下面这张 SVG 图把两种格式的结构放在一起，方便你从视觉上感受差异——我画给团队新人看的，他们都说“哦，原来区别在这里”。
2.7 最后讲点实用建议
不管你现在在用哪种格式，记住一个原则：接收端永远要做好格式自适应。我推荐在日志集中器或 syslog server 上做两件事：
- 自动嗅探版本：检查优先级数字后面的第一个字段，如果它包含冒号 ":" 则按 3164 时间戳处理；如果它是数字 "1" 则按 5424 处理。
- 标准化输出：收到任何格式后，统一转换成 5424 内部表示（或你定义的 JSON schema），后续所有审计、告警、存储都基于这个标准化结构。
我曾经在帮某金融客户做审计改造时，就是靠这个“统一转换层”，把 3000 多台设备的不同 syslog 格式全部归一化，最终通过了合规审查。嗯，格式差异本身不是灾难，灾难是你没有意识到这种差异的存在。先把 RFC 3164 和 5424 的区别刻在脑子里，以后看到一串乱糟糟的日志就知道该往哪个方向下手了。