摘要

  • 事故后没有查到某条日志，既可能是事件没有发生，也可能是它从未进入该输出，或已在传输、轮转与收集端保存环节消失。RFC 9742 不能把这些解释合并成一个结论。
  • 配置按控制台、文件和远端目的地分别选择消息；严重级别、正则表达式和结构化数据开关，会改变以后能够检验的解释。
  • 共同模型使差异可以被描述，并不证明所有实现具有相同功能，更不保证某段事故历史仍然存在。改变这些设置的人掌握着一部分未来追责与复盘的条件。

“没有记录”需要先说明查过哪一份历史

一份事故复盘可能同时写着“认证失败已被记录”和“无法确定此前是否进行过合法变更”。两句话未必矛盾。假设远端输出只接收较高紧急程度的消息，而能够区分变更性质的上下文消息级别较低，那么故障症状会留下，解释症状的线索却可能在设备正常运行时就被排除。这是用于说明机制的假设，并非本篇发现的真实事故。

因此，事故后的搜索结果需要附带一个前提：搜索对象究竟是哪一种经过选择的历史？只说“设备开启了日志”，没有回答哪些消息进了哪个目的地，也没有回答目的地后来留下了什么。

2025 年 4 月发布的 RFC 9742 属于 IETF 标准轨道，定义 ietf-syslog YANG 配置模型。它把控制台、本地文件、远端 relay 或 collector 等输出放入共同表达方式，使管理系统有机会比较策略。标准发布不等于某个厂商已经部署，也不等于设备能够完整记录事故。

模型描述的是配置。应用是否生成了有关事件、当前设置是否真的生效、消息是否到达、到达后是否被持久保存，都仍是各自需要证据的问题。把一个有效配置当成完整事故记录，会把尚未建立的前提藏起来。

每一个输出都可能是不同的选择结果

RFC 9742 的 selector 分别用于控制台、具名日志文件与具名远端目的地。一个文件保留了某类消息，不代表另一个远端输出也保留了它。两份记录出现差异，可能恰好说明各自遵循了不同设置，而不是其中一份损坏。

严重级别的默认规则也值得读准：选择设定的级别及更高紧急程度的消息。syslog 的数字方向相反，越紧急的级别数字越小。因此，error 不表示“仅等于 error”；它通常也选中更紧急的级别，却仍可能排除紧急程度较低的上下文。消息产生时的紧急程度，不等于它在事后所有调查中的证据价值。

模型还提供显式的 all 与 none。如果实现支持可选功能 select-adv-compare，比较方式可以是 equals 或 equals-or-higher，动作可以是 log、block 或停止该消息进一步处理的 stop。这个高级容器内部的默认值分别是 equals-or-higher 与 log。一句“采用 error 级日志”可能遮蔽相等比较、阈值比较或阻断动作的差别。

正则选择属于另一项可选功能 select-match。规范中的模块把 pattern-match 描述为针对整个 SYSLOG-MSG 的 POSIX 正则匹配，不能把它缩写为只匹配末尾的 MSG 文本。如果同时设置 facility 选择和正则，两者必须都匹配。看似宽松的 facility 条件，可能被另一项匹配条件收窄。

这使消息措辞或格式变化也成为观察对象：事件的运维意义没有改变，输出是否选中它却可能改变。具体匹配器和规则组合仍需在对应实现上验证；本篇没有测量任何厂商设备，也没有给整个规则列表虚构一种统一执行顺序。正确问题不是笼统地问“噪声是否减少”，而是问减少后还剩下哪些能够区分原因的消息。

文件保存参数不是一张时间担保

文件轮转决定已被选中的信息还能活多久，但 RFC 并未规定一个必须满足的证据保存天数。file-limit-size 控制文件数量和大小限制是否可配置；数量字段默认值为一，最大文件大小以兆字节表示。file-limit-duration 控制 rollover 与 retention 是否可配置，两者单位均为分钟。

rollover 描述超过间隔后有消息到达时关闭当前文件并开始新文件。retention 描述已经完成或关闭的文件，在移除前应保存多长时间。这些参数不能直接转述为“每一条事件自发生起都保证可查这么久”。如果没有提供归档限制，采用的是实现自行定义的限制。

附录 B.3 关于归档命名、重命名及删除的说明是信息性实现指引，不是一套强制轮转算法，也没有替操作者证明多项限制同时存在时的完整优先次序。由文件数和文件大小相乘得到容量，再把容量说成固定历史时长，会跳过压缩、事件大小、归档计数及其他限制的影响。

在容量受限的情况下，事故带来的消息暴增可能更快挤掉旧历史。这是可以解释的机制，不是本篇测得的保存公式。配置没有变化，也不意味着最早可检索的事件时间没有向后移动。恰恰在最需要前因的时候，更多症状可能压缩已有记录的历史覆盖。

本地文件还有故障依赖的问题。如果设备和记录介质共同受到同一次损坏，记录存在于本地就不等于独立保存。远端目的地可以改变这一依赖，却会增加传输路径和收集端保存政策；设备端轮转参数不能回答收集端是否真正保留了副本。

加密的连接仍不是收集端的入库证明

每个具名远端目的地必须在 UDP 与 TLS 两种传输中选择一种，其内部可以列出地址；默认端口分别为 514 和 6514。这个 choice 的范围是该目的地条目，不应扩大解释为所有分别命名的目的地必须采用同一种传输。

RFC 5426 说明 UDP 交付并不可靠，数据报可以无通知丢失，接收顺序也不能直接当成权威事件顺序。TLS 在适当认证与授权下保护传输这一跳的机密性与完整性，却不能弥补发送前被过滤掉的信息。

RFC 5425 第 3 节 明确指出，认证的传输发送方身份不一定对应消息内部的 HOSTNAME。接受一个可信 relay 的连接，不等于证实它转发的每个原始身份主张。第 6.3 节 又说明，这种 syslog 传输没有应用层确认；连接断开时，发送方不能总是知道哪些消息已交给对端应用。应用接收之后是否持久保存、是否删除，以及内容本身是否正确，仍是后续问题。

结构化数据同样不能凭开关获得过度保证。文件和远端动作中的 structured-data 是可选功能，布尔值默认 false：false 写入 NILVALUE，true 写入一个或多个结构化数据元素。RFC 5424 将这个可解析字段与可选消息文本分开定义。打开开关不会创造原来不存在的事实，也不会验证应用赋予字段的意义；关闭它则可能丢掉下游消费者原本依赖的结构化上下文。

共同名字之后，还要看功能和实际值

一个设备声明 ietf-syslog，不足以推断它提供正则选择或基于时间的留存控制。RFC 8525 的 YANG Library 用模块修订、支持的 features、deviations 和各 datastore 的 schema 描述这些差异；RFC 7950 的 if-feature 让节点是否被实现取决于相应功能支持。共同模型的价值，是让差异可被检查，而不是让差异消失。

厂商扩展也有边界。RFC 9742 附录 B.1 提醒，扩展 facility 可能不能用于 RFC 5424 协议，而是用于本地类似 syslog 的记录功能。本地分类因此未必能够原样成为远端分类。模型的 facility-override 还允许替换发送到远端的 facility；可选 source-interface 则指定出接口，而不是认证某个组织身份。

另一个差别存在于计划和执行之间。RFC 8342 将经过转换、系统试图应用的 intended 配置，与 operational 中实际使用的配置及系统状态区分开来，同时保留实现和报告能力的限制。比较两种视图可以发现当下差异，但修复完成后的快照，不能单独证明事故当时使用的设置。

RFC 9742 没有给出证据保管链、自动审计或完整事故历史。它提供了一个更具体的起点：先确定哪个动作选择了什么，什么在实际运行，什么到达了收集端，以及什么还没有被移除。只有这些边界建立后，记录中的沉默才有较明确的解释。否则，“没查到”首先是所查档案的性质，而非事件未发生的证明。