Syslog协议基础：RFC 5424标准、Facility与Severity、传输方式
好，咱们正式开始聊协议。
做HSM审计日志转发，不懂Syslog协议是行不通的。虽然你日常配置可能只是填几个参数——IP、端口、协议类型，但底层到底怎么回事，关键时刻能救你一命。我见过太多排错现场，就是因为不清楚Facility和Severity的对应关系，日志被丢到错误文件里，找半天找不到。
这一节，我们把RFC 5424、Facility、Severity、传输方式这几个硬骨头啃下来。
RFC 5424标准：Syslog的新规范
早期的Syslog标准是RFC 3164，那是个很随意的规范，格式不统一，字段边界模糊。后来大家觉得这样不行，于是在2009年推出了RFC 5424。现在主流设备和软件基本都支持RFC 5424，特别是HSM这类安全设备。
RFC 5424定义了正式的报文格式。核心结构我列一下：
HEADER [STRUCTURED-DATA] [SP MSG]
HEADER：
PRI VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID
PRI = Facility * 8 + Severity
结构是 PRI VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME ...，我看着都眼花，但说白了就是给每条日志贴个标签：谁发的、什么时候发的、什么程序发的、级别是什么。
这里面有个关键点——PRI值。
PRI = Facility × 8 + Severity。这个公式贯穿整个Syslog。你想想看，接收端收到报文后，第一件事就是解析PRI值，拆出Facility和Severity，然后决定这条日志分配到哪里去。如果你配置时Facility填错了，日志就跑到错误分类里了。
重点理解：RFC 5424是结构化日志的基础。HSM设备如果支持，尽量让它输出RFC 5424格式，后续做日志解析和审计效率会高很多。
Facility与Severity：日志的身份与紧急度
Facility说白了就是日志的生产者——是操作系统内核？是邮件系统？还是安全/授权子系统？
Severity则是这条日志有多严重——是崩溃级还是纯调试信息？
这两个维度组合在一起，就确定了日志的归属和响应方式。我在项目中遇到过有人把所有日志都配成kern或local0，结果日志服务器上一锅粥，根本没法做策略分析。
常用的Facility值如下：
| Facility编号 | 关键字 | 说明 |
|---|---|---|
| 0 | kern | 内核消息 |
| 1 | user | 用户级消息 |
| 2 | 邮件系统 | |
| 3 | daemon | 系统守护进程 |
| 4 | auth | 安全/授权消息 |
| 5 | syslog | syslogd内部生成 |
| 6 | lpr | 行式打印机子系统 |
| 16～23 | local0～local7 | 本地使用，预留自定义 |
HSM日志通常用auth(4)或local0～local7。嗯，这里要注意：按标准化建议，安全审计日志应该用auth，但很多HSM厂商偏好local0，因为方便在接收端单独截取。我的建议是——咨询HSM厂商文档，别自己猜。
Severity级别从0（最紧急）到7（最不紧急）：
| 编号 | 严重级别 | 说明 |
|---|---|---|
| 0 | Emergency | 系统不可用 |
| 1 | Alert | 立即采取行动 |
| 2 | Critical | 临界状态 |
| 3 | Error | 错误情况 |
| 4 | Warning | 警告情况 |
| 5 | Notice | 正常但重要 |
| 6 | Informational | 信息消息 |
| 7 | Debug | 调试信息 |
为什么要有8个级别？说白了就是为了方便过滤。在HSM场景里，你可能只关心Error及以上级别，接收端直接配置一个阈值，err(3)以下的统统忽略。
曾经有个客户把HSM的审计日志级别改成了Debug，日志量立刻暴涨100倍，网络带宽被打满，Syslog服务器CPU直接100%。记得生产环境慎用Debug级别。
如果想在配置时精确筛选，可以这样写：
# 只接收 local0 设施且级别为 err 及以上的日志
local0.err @192.168.1.100:514
这里的local0.err就是Facility + Severity的组合表达式。
个人习惯：我在所有项目中都坚持用local0做HSM日志设施。这样接收端规则可以写得极其干净，不会和其他系统日志混在一起。
传输方式：UDP / TCP / TLS
传日志不能只看「能发出去」，还要考虑可靠性、安全性。三种主要方式各有利弊，我逐一分析。
| 特性 | UDP (RFC 5426) | TCP (RFC 6587) | TLS (RFC 5425) |
|---|---|---|---|
| 传输层 | 无连接 | 面向连接 | 加密连接 |
| 数据可靠性 | 低，可能丢包 | 高，保证按序到达 | 高 |
| 安全加密 | 无 | 无 | TLS加密 |
| 流量控制 | 无 | 有 | 有 |
| 默认端口 | 514 | 601 (或514) | 6514 |
| 适用场景 | 内网、低风险、对丢包不敏感 | 内网、要求可靠交付 | 外网、跨网络、安全审计必需 |
UDP：最简单、最快速，但不可靠。HSM日志如果走UDP，一旦网络拥塞或Syslog服务器繁忙，日志直接丢弃，不会有重传。我在内网测试环境常用，但生产环境不推荐。
TCP：有连接保障，日志不会丢，但增加了握手开销。注意RFC 6587定义了两种帧格式——非透明帧和透明帧，前者靠换行符分割，后者靠八位长度前缀。我建议优先用透明帧，避免日志内容本身包含换行造成混乱。
TLS：加密传输，安全合规的硬性要求。HSM审计日志如果涉及敏感操作记录（如密钥生成、策略变更），必须走TLS，否则审计数据在网络上裸奔，合规审查直接过不了。配置时需要服务端证书、客户端证书（可选双向认证），端口是6514。
你想想看，为什么HSM厂商越来越强推TLS？因为监管机构要求日志传输链路加密，UDP和普通TCP都不满足。
我曾经在银行项目排错时发现，一条重要的密钥生成日志因为UDP丢包没传到SIEM系统，审计人员花了三天才找到原因。从那以后，凡是我负责的HSM审计链路，至少走TCP，最好走TLS。
现在来看一张结构图，直观理解Syslog协议在HSM转发中的层次关系：
这张图把大结构梳理清楚：报文从Facility+Severity组合确定身份，通过RFC 5424结构化头部附带时间、主机名等元信息，最后选择UDP/TCP/TLS传出去。
三种传输方式如何选？我根据自己的实战经验，给你一个决策思路：
- 纯内网调试 → UDP。快速，省资源，丢几条日志无所谓。
- 内网生产环境 → TCP。牺牲一点点延迟，换来可靠交付，绝大多数场景足够。
- 跨网络/合规审计 → TLS。必须的。监管要求日志传输加密，TLS是唯一合规路径。
配置TLS时，你会遇到证书管理的问题。嗯，这个后面章节会详细展开。提一句：记得用强密码套件，不要为了省事选TLS_RSA_WITH_NULL_SHA这类空加密套件——我跟你说，真的有人这么干过。
关于传输方式的最后一个提醒：如果走TCP或TLS，双方都要确保socket保持存活。我曾经排查过一个案例，HSM设备连续发送大量日志，TCP连接积压，发送缓冲区溢出，最终日志开始丢。解决方案有两个：要么调大内核缓冲区，要么在HSM端做限速（rate-limiting）。
我想强调一点：不要盲从。有一个客户因为盲目全上TLS，100台HSM同时连接一台Syslog服务器，TCP+TLS握手开销让服务器直接宕机。后来拆成多台接收节点，问题解决。凡事都有代价，根据实际场景做取舍。
好，Syslog协议基的几个核心块就这些。记住PRI的拆解公式，记住Facility的常用值，记住三种传输方式的适用边界。到这一步，你已经比很多「只是配个IP就完事」的运维人员专业了。后面的章节咱们会把这些基础用在HSM的实战配置上。