日志源升级之后，报表是怎么悄悄错的

结论先行：日志平台最常出问题的地方不是接不进来，而是接进来之后悄悄变了样。上游系统打个补丁、换个版本、改个字段名，日志照样在写，采集照样在收，但解析规则已经对不上了。这时候看板上不会报错，只会安静地少掉一部分数据，或者把字段填错位置。发现它不能靠人盯，要靠三个可观测信号和一份变更联动清单。

本文只谈已经接进来的日志源在上游改动之后怎么失真、怎么发现，不谈首次接入怎么选采集方式，也不谈解析规则本身怎么写。

三种失真，都发生在「什么都没变」的表象下

接入阶段做完字段标准化、时间戳统一、无效日志过滤，平台看起来是稳定的。问题出在这套规则假设了上游不会变，而上游一定会变。

其一，位置型解析遇到格式微调就整体偏移。用分隔符或固定位置切分的解析方式，对字段顺序有隐含依赖。上游在前头加了一个新字段、或者某个字段从可选变成必填，后面所有字段的位置就整体挪一格。日志照样入库，只是「操作人」那一列装的是「目标资产」的内容。这种错不会报错，只会让检索结果看起来莫名其妙。

其二，时间口径变了，先后顺序就乱了。上游把时间戳的精度从秒改成毫秒、把本地时间改成带时区的时间、或者干脆换了时间字段的来源，跨系统关联就断了。排查一个横跨三个系统的动作时，平台上看到的先后顺序可能和真实顺序相反。这类问题在有跨时区分支机构的场景里更常见，因为时区差异会被两边的采集口径放大。

其三，源悄悄停写了。最隐蔽的一种。服务器还在、采集端还在跑、心跳正常，但这个源已经好几天没写新内容了——上游把日志级别调高了、把某个模块的日志关掉了、或者把日志文件路径改到了采集端没覆盖的位置。平台侧看到的是「这个源有数据」，只是那份数据停在两周前。

监控体系天然擅长发现「没有」，不擅长发现「不一样」。采集端掉线会触发告警，磁盘满了会触发告警，但「字段内容错位」和「某类日志少了一半」这两件事，在大多数平台的默认配置里都不是告警项。

更麻烦的是第二个原因：失真往往和业务变化同时发生。上游改版那几天，业务量本来就在波动，报表上的数字有变化显得很正常。等到有人发现某个指标一直归零、或者某个查询一直查不到结果，通常已经过去几周。

还有第三个原因，是人的因素。接入阶段是谁做的，通常就是谁最清楚那套解析规则。项目交付之后人一换，规则成了黑盒，出问题的时候连「本来应该长什么样」都说不清。

三个里面，抽样比对最笨也最有效。它不需要预先知道哪里会坏，只需要随机取一段原始文件，和平台上同一时间段的结果摆在一起看。这件事做一次的成本不高，难的是把它变成有节奏的动作，而不是出事后才想起来补。

前三个信号是发现手段，要真正减少这类问题，得让上游的改动传过来。可行的做法不复杂，三件事。

一份源清单，写清谁负责。每个日志源对应一个上游系统、一个负责人、一个变更通知渠道。清单不必很细，但「这条日志来自哪个系统、出问题找谁」必须能一眼看到。很多单位有源清单，缺的是负责人这一列——而缺的往往就是最关键的这一列。

上游变更单里加一行。业务系统做版本升级、改配置、调日志级别的时候，在变更单上勾一项「是否影响日志输出」。勾了就走日志侧的确认，没勾也要留个记录。这一行的成本是一分钟，省下的是几周的静默失真。

改完先双跑一轮。解析规则不得不调整时，新旧规则并行跑一段时间，用同一批原始日志分别解析，比对结果差异。确认差异都在预期之内再切。这一步在替换解析引擎或者大规模改字段的时候尤其值得做。

三点说明。其一，字段空值率与日均量的阈值没有通用值，须按各源的历史分布定，直接套用别处的比例往往误报。其二，抽样比对抽查的是样本，不能证明全量正确，它的作用是把「不知道有没有问题」变成「这段确认过」。其三，把上游变更纳入联动需要跨部门约定，落地节奏取决于现有变更管理流程的成熟度，不宜一次铺开。

深圳市奇摩计算机有限公司是一家 IT 解决方案服务商，在日志平台交付中，习惯把日志源清单、字段字典与解析规则一起作为交接文档，并在交付后陪着做一轮抽样比对，避免平台建好之后没人说得清它本来该是什么样。预约咨询，可以拿现有的日志源清单，先把负责人那一列补齐。