2. Syslog 协议概述与标准（RFC 5424）
我第一次接触 Syslog，是在一次金融交易日志审计的项目里。那时设备遍地开花，但日志格式五花八门。说实话，那会儿的 Syslog 简直就是「各说各话」——有带时间戳的，有不带的，有把严重级别写在开头的，也有藏在中间的。看得我头皮发麻。
后来 RFC 5424 出来了。它把这一切规范了起来。说白了，它定义了 Syslog 消息长什么样，每个字段放在哪，必须有什么，可选有什么。今天咱们就来聊聊这个标准的核心要点。
2.1 为什么需要 RFC 5424
旧版的 Syslog（RFC 3164）其实没规定消息格式必须严格遵从。你想想看，一个日志系统连格式都不统一，那解析起来简直就是一场噩梦。
我在上一个项目里，就遇到过两台不同厂商的防火墙，发的日志格式差异特别大。一台把时间戳放在最前面，另一台却把主机名放在最前面。解析程序愣是得写两套配置。嗯，这就是没有统一规范的代价。
RFC 5424 的出现，像是给这群散兵游勇立了个规矩。它明确了消息结构、字符编码、时间格式、甚至结构化数据的标准。从混乱走向秩序，这就是它的核心价值。
2.2 RFC 5424 消息结构
一条标准的 RFC 5424 消息，实际上是由三个部分组成的。我把它们拆开来讲：
- 头部（HEADER）：包含优先级、版本、时间戳、主机名、应用名、进程 ID、消息 ID。
- 结构化数据（STRUCTURED-DATA）：一个可选的、键值对形式的容器。用于扩展元数据。
- 消息体（MSG）：真正的日志内容。UTF-8编码是标准做法。
你可以把它想象成一个快递包裹。头部是快递单，结构化数据是附带的票据，消息体是里面的货物。
<34>1 2024-01-15T10:30:00.123Z myserver.example.com myapp 1234 ID001 [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"] 用户登录成功我们来拆解一下上面这个例子：
| 字段 | 示例值 | 说明 |
|---|---|---|
| <34> | 34 | 优先级（PRI），由设施代码和严重级别计算得出 |
| 1 | 1 | 版本号，RFC 5424 固定为 1 |
| 2024-01-15T10:30:00.123Z | 时间戳 | ISO 8601 格式，必须带时区 |
| myserver.example.com | 主机名 | 完整的域名或主机名 |
| myapp | 应用名 | 产生日志的程序名 |
| 1234 | 进程 ID | 产生日志的进程编号 |
| ID001 | 消息 ID | 用于标识消息类型 |
要注意，优先级字段是最容易被忽视的。它由设施代码乘以 8，再加严重级别得到。比如 kern 设施代码是 0，严重级别 error 是 3，那 PRI 就是 3。不过这个计算咱们顺手就记住了，不复杂。
2.3 结构化数据（SD-ELEMENT）
这是 RFC 5424 最亮眼的设计。相比旧版只能放一段文本，结构化数据可以自定义键值对。比如你可以放个 "transactionID" 或者 "userRole"。
为什么要这么设计？你想想看，在 HSM 日志场景里，一条「签名失败」的日志，如果能附带"serialNumber=0x1234"和"keyLabel=signing_key_01"，那排查问题的效率就完全不一样了。
我曾在一个 HSM 项目中，利用结构化数据追踪密钥生命周期，把审计效率提升了三倍。以前要 grep 好几遍，现在一个结构化字段就能锁定。
[exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"]这个格式很有意思：SD-ID（如 exampleSDID@32473）必须包含一个 @ 符号，用来保证唯一性。后面跟着由空格分隔的键值对，值用引号括起来。这就是一个标准的 SD-ELEMENT。
2.4 传输方式
Syslog 的传输层其实有好几种选择。我按经验把它们排了个序：
- UDP（传统方式）：简单、性能好，但不保证送达。适合内部网络，适合非关键日志。
- TCP（可靠方式）：确保消息到达，但需要维持连接。适合对完整性有要求的场景。
- TLS（加密方式）：在 TCP 之上加了一层 TLS。适合公网传输，或者合规需求高的场景。
搞 HSM 日志传输时，我强烈建议使用 TCP+TLS。原因？HSM 的日志是审计追溯的关键证据，不能丢，也不能被篡改。UDP 不可靠，明文传输又太危险。
我曾经遇到过一个客户，他们把 HSM 日志通过 UDP 跨机房传输。结果网络抖动时，连着丢了几百条签名操作的日志。审计人员找上门，他们才后悔莫及。
2.5 核心概念图解
下面这张图，帮我把 RFC 5424 的整个消息结构和传输关系串起来。顺着看，你就能明白一条日志从哪来的，怎么传的。
2.6 版本与兼容性
你可能已经发现了，RFC 5424 消息里有个版本号字段。这玩意儿其实就是为了向下兼容。版本为 1 的表示新格式，没有版本号的（或者版本为 0 的）就是旧格式。
我在配置 rsyslog 时，通常会打开 $ActionFileDefaultTemplate RSYSLOG_SyslogProtocol23Format，它会强制输出 RFC 5424 格式。这样做的好处是，你的所有日志接收端都能按同一套解析规则来处理。
| 版本 | 对应标准 | 特征 |
|---|---|---|
| 0 或无 | RFC 3164（旧版） | 无结构化数据，格式松散 |
| 1 | RFC 5424（新版） | 结构严谨，支持 SD 和 UTF-8 |
Syslog 协议走到今天，RFC 5424 已经成为主流。无论你是写日志发送端，还是做日志接收端，理解这个标准都是基本功。它不仅让机器好解析，也让人的排查思路更清晰。