摘要

  • RFC 3164 将整个传统 syslog 数据包限制在 1,024 字节，并要求中继为缺少有效时间戳的消息补入时间戳，还建议补入主机名。
  • 如果补充这些字段后超出上限，中继必须截断数据包；RFC 明确提醒，原始消息末尾可能包含重要信息。

头部也要占用预算

设想一台路由器发出一条接近满长的 syslog 数据包，却没有可用的时间戳。中继收到它，检查 PRI 优先级字段，然后准备转发。按 RFC 3164 第 4.3.2 节，中继必须在 PRI 后插入自己的当前本地时间戳；若能确定主机名，则还应补入主机名。收到的数据其余部分会作为消息的 CONTENT 追加进去。

这个操作并非没有代价。RFC 3164 第 4.1 节限制的是整个数据包，而不只是事件文本：PRI、HEADER 和 MSG 共用 1,024 字节。如果时间戳、主机名和分隔空格使重组后的包超长，第 4.3.2 节要求中继检查总长度，并把数据包截回 1,024 字节。备忘录直接指出后果：原始包末尾的信息可能丢失，而且可能是重要信息。

微妙之处在于，丢失发生的位置。收集器仍可能收到一条看起来格式正确的 syslog 消息。PRI 和新添的头部都很规整；但事件最后几个字节——“因为”之后的原因、命令输出、设备标识符、校验值或诊断中的第二个数值——可能已经不在了。本文把这些作为可能情况，而非声称真实事故已经发生。协议规定：当补充字段使原本较长的输入超过共享上限时，消息末尾就会暴露在这一风险之下。

规范要求不等于实现普查

这是 2001 年 8 月发布的 Informational 备忘录中对 BSD syslog 协议的规定，不是每个中继都遵循它的证据。RFC 第 4.2 节允许设备最初发出的 UDP/514 负载是任意有效的 syslog 消息；它建议发送端预先提供 PRI、HEADER 和 MSG 结构，因为这样更易读，也能避免中继改写。第 6.1 节另行要求接收端不能因收到超过 1,024 字节的消息而故障，并描述了不同的接收端行为。两处都没有统计现实设备发出长消息的频率、哪些中继会截断，或收集器最终保存了什么。

1,024 字节的消息上限也不能与路径 MTU 混为一谈。前者是 RFC 3164 中 syslog 包/消息的约束；后者关乎网络路径上网络层数据包的大小。IP 分片、UDP 数据报处理和应用层截断是不同机制。消息符合协议上限，并不保证路径 MTU 不会造成问题；反过来，超过传统应用上限，也不必然是路径造成的。

补入的值本身也有证据边界。时间戳是中继当前的本地时间，不一定是事件发生时间。主机名是中继所知的设备名；如果无法识别，则使用发送方 IP 地址。RFC 3164 不要求接收方验证该主机名是否与发送者相符。因此，补充字段可以提高可读性，却不能证明原始事件时间或密码学意义上的来源身份。

后来的格式有帮助，但不能证明全网已迁移

RFC 5424 后来取代 RFC 3164，采用更明确的 syslog 头部和结构化数据。RFC 6587 描述 TCP 传输的分帧方式，并指出标准化 syslog 已扩展传统 1,024 八位组消息长度。RFC 3195 采用另一种账目：其 RAW 配置文件把每条事件正文限制在 1,024 字节，但不把 BEEP 分帧开销计入。这些对照很重要，因为“1,024 字节”在不同层次可能指不同对象；但新 RFC 的发布不能证明旧发送端或中继随之消失。

历史教训更窄也更具体：中继试图补足上下文，却可能消耗正文共用的有限预算。重组后的包仍可能成功送达、解析并存储；这些状态都不能证明原始消息完整保留。要证明现实系统中的完整性，需要成对证据——源端字节、每一跳中继的输入和输出、收集器解析结果，以及之后的读回记录——不能只看发送成功或头部格式正确。

来源