摘要

  • RFC 5424 的可选 timeQuality 字段记录来源端对时区认知、同步状态和可能偏差的判断，不会在接收端独立检测时钟。
  • syncAccuracy 表示两次同步之间来源端认为的最大偏差；它是否可信，取决于时间源可靠性和运维配置，而非字段格式本身。

时间戳之外，还需要知道谁在作判断

事件响应人员把来自不同机器的 Syslog 记录汇总到一起时，往往先看时间戳：先发生的是哪条日志？如果两条记录只差几毫秒，这种顺序看起来尤其确定。但格式正确的时间值并没有说明来源机器是否知道自己的时区、是否跟随可靠时间源，或者维护人员是否持续监测同步服务。RFC 5424 的 timeQuality 正是用来把这类上下文附在消息上。

RFC 5424 第 6.2.3 节用受限的 RFC 3339 形式定义 TIMESTAMP，并建议在时钟精度和性能允许时包含小数秒。第 7.1 节则允许来源端通过结构化数据描述其对系统时间的认知。这里的“认知”很重要：字段由发送者产生，它和事件一起到达接收端，却不是接收端对该时钟进行的一次独立测量。

第 7.1 节还建议：如果来源端没有正确同步到可靠的外部时间源，或者不知道时区信息是否正确，就应写出 timeQuality。其中各项参数仍然是可选的；规范鼓励披露不确定性，并没有要求每个发送者都填满所有细节。

因此，应该把两件事分开：时间戳以何种格式表达，来源端又能为这次表达提供什么支持。精细到小数秒，只回答前一件事。

三项参数描述三个不同边界

tzKnown 回答来源端是否知道自己所用的时区信息。时区已知与时间戳写成 UTC 并不矛盾；RFC 5424 明确指出，即使时间采用 Z 表示，时区仍可能是已知的。反过来，写成 UTC 也不自动证明本机时区配置可靠。附录 A.7 倾向于保守默认值，并指出管理员配置或核验可以成为声明时区已知的依据。

isSynced 表示来源端是否认为自己的系统时钟已与可靠的外部来源同步，例如 NTP。接收端解析消息时不会因此查询 NTP，也不会从线上报文本身知道上游源的健康状况。它看到的是发送者给出的状态值。

syncAccuracy 是一个以微秒计的整数，表示来源端认为在同步间隔之间，时钟可能偏离的最大幅度。若 isSynced="0"，该参数不得出现。RFC 5424 的示例用了 60,000,000 微秒，也就是一分钟；在 09:00 的时间戳下，示例让读者考虑 08:59 至 09:01 的范围。这不是第三方拿仪器测得的误差，而是来源端声明的预期边界。

规范只建议在来源端实际知道时间源可靠性时写出 syncAccuracy。附录指出，这类认识通常来自运维配置，并警告不要制造精确可靠的假象。接收端还有一个明文解释规则：出现 isSynced="1" 而缺少 syncAccuracy 时，收集器或中继可以假定时间足够准确、可视为正确。这个规则说明了接收方如何理解报文，并没有替来源端证明同步服务正常。

记录进入管道以后，证据也要一起走

IANA 的 Syslog 参数注册表把 timeQuality、tzKnown、isSynced 和 syncAccuracy 都列为可选项。收集系统必须容纳有这些参数和没有这些参数的消息。缺少它们不等于时间错误，但确实减少了接收方可用来判断时间质量的显式信息。

更棘手的情况发生在日志标准化：处理链保存了时间戳，却丢弃了同一结构化数据块。后续分析人员可能看到毫秒精度，却不知道发送端当时附带了怎样的限制。保留字段是必要的，但还不充分；还要能查到来源主机、负责配置的团队，以及相关时期的同步监测记录。

NTP 最佳实践 RFC 8633 建议监测时间源和 NTP 实例，并发现失去同步的服务器。这为来源端声明提供了运维侧的核验方向。它并不证明任何特定 Syslog 部署执行了该建议；现有材料也没有给出实际部署比例或线上误差统计。

timeQuality 提供的是来源声明

这组字段有实用价值：让发送端可以随事件说明自己认为时区和同步状态如何，让接收端保留这份说明，并在重建时间线时避免把所有时间戳看成同等可靠。但它不能认证事件，不能独立证明跨系统的因果顺序，也不能把来源端判断变成外部测量。

Heng Lu 关于“运行代码优先”的文章在此只能作为有限的编辑视角：文档标签不能取代已部署系统实际验证和执行的内容。RFC 定义了声明格式；声明的操作依据仍在来源主机正在运行的时钟配置和监测机制里。收集器可以保存这个边界，却无法事后替来源端补出证据。

来源