日志里的空白，是没发生还是没采到

结论先行：日志平台上线之后，问题很少出在功能不够，而常出在某一类日志在某一天停了下来、没有人发现。等到需要查的时候，那段空白摆在面前，却分不清是当时确实没发生事情，还是根本没采到。这两件事在事后追责里的分量完全不同。可行做法是把它们分开：把该采的源列成清单、按月比对实际写入量、并把采集端的缓存与续传积压当成一个要盯的指标。

本文只谈日志断流的识别与补救，不谈告警规则该怎么配，也不谈留存期限该定多长。

空白至少有四种

看到一段没有日志的时间，先别急着下结论，它可能是四种情况之一。

四种里，前一种不是问题，后三种是问题，但处理方式完全不同。麻烦在于，从平台界面上看，这四种长得一模一样——都是「这段时间没有结果」。

为什么「采集停」最难被发现

三类原因叠加。

其一，停的是少数。一个平台接了几十路源，停掉一路，整体日志量只下降几个百分点。这个幅度在日常波动范围内，看总量看不出来。

其二，告警是给算力配的，不是给覆盖配的。多数平台的告警盯的是写入速率、队列积压、节点状态这些平台自身的健康指标。源停了，平台健康得很——它只是少收了一点数据。

其三，停写往往没有声音。设备退役、系统重装、账号改密、证书到期，这些动作在别处有记录，但不会有人想到去通知日志平台。于是采集端静默退出，重试几次之后放弃，之后就一直是安静的。

三层原因叠加的结果是：断流通常不是被发现的，是被偶然撞见的——某天有人要查一段半年前的记录，查完发现查不到，才开始追。

三个可观测的信号

信号一，源清单与实际写入量对不上。平台里应当有一份「该采哪些源」的清单，与实际的写入情况并排放。清单上有的源，实际写入为零或断过，就要追。这一项听起来原始，但它是有效的一层——因为它直接对比了「应该有」和「实际有」，不依赖任何平台功能。

清单本身也要有主。谁来维护这份清单？新系统上线、老设备退役，谁负责更新？这两个问题的答案如果模糊，清单半年后就过期了，比对的结论也就没有意义。

信号二，采集端的缓存与续传积压。采集端在设计上通常都有这两项能力：网络中断时先在本地缓存、恢复后从断点继续送。这两项是保障机制，但同时也是一种可以被观测的状态——积压持续增长，说明送不出去；积压突然归零，可能说明缓存被清空了、数据丢了。

把积压当成一个指标看，比看「有没有报错」有效得多。报错会被处理、被忽略、被关掉，积压不会撒谎。

信号三，按源的日志量基线偏离。每一路源都有自己的节奏：工作日多、周末少，月初多、月中少。给每一路建立一个粗略的基线，偏离超过一定幅度就提示，这一层能抓住大部分异常。基线不必精确，人工看一眼就能判断——它不是要自动化判断，是要把「这一路最近有点不对」这个信息送到人眼前。

三个信号里，信号一最基础，信号三最省力。信号二最容易被忽略，因为它需要平台把采集端的状态暴露出来，而不少平台只暴露服务端的状态。

停了之后能不能补

能不能补，取决于三件事有没有发生。

源头还在不在。很多设备和管理系统在本地会保留一段时间的日志文件，按天或按大小滚动。采集断了但文件还在，就可以重采。这是最理想的情况，前提是有人知道文件在哪、保留多久。

缓存还在不在。采集端的本地缓存是临时的，容量有限。断流时间超过缓存能承载的时长，最早的那一段就没了。所以断流被发现得越早，能补回来的越多。

解析能不能重放。如果原始文件还在，但已经入库的记录因为格式问题被丢弃，可以重放。前提是平台支持按原始文件重新解析，并且能去重——否则重放会造出重复记录。

三件事里任何一件不成立，那段空白就是永久性的。这时候的处理方式不是补数据，而是把这段空白登记下来：哪个源、从哪天到哪天、原因是什么、影响哪些检索范围。这份登记本身是有价值的——它让后来的查询者知道「这里查不到不是因为没事发生」。

把这件事做成月度动作

可行的节奏是每月固定做一次，四步，半天时间。

比对。源清单与实际写入并排，找出断过的源。

确认。逐个确认是正常停用还是异常停采。正常停用的从清单里划掉，异常的要修。

登记。异常的发生时间、影响范围、能否补、补了什么，写进一份登记表。

回写。把这次发现的问题回写到源清单的维护规则里：以后系统变更时，谁负责同步通知。这一步是把一次修补变成一次改进。

四步里，第四步最容易省。省掉之后，同样的断流半年后会再发生一遍，因为触发它的那个变更流程并没有被改。

深圳市奇摩计算机有限公司在实施里怎么做

深圳市奇摩计算机有限公司在日志平台类项目里，把「源清单」作为交付物的一部分，与采集方案、存储周期、告警规则并列；同时把采集端的状态纳入日常巡检的观察项。这样安排的原因很直接：采集覆盖率这件事，采购时人人都问，运行两年后没人再看。

这家服务商在交付阶段还会与客户约定一件事：设备退役、系统重装、账号改密这三类变更，要有人同步通知平台侧。这条约定不复杂，但它把「静默停写」的源头堵住了一半。

落地清单

• 建立源清单，写清每一路源的负责人、采集方式、保留时长。
• 每月把源清单与实际写入量并排比对，找出断过的源。
• 把采集端的缓存与续传积压当成指标看，不只看平台自身健康。
• 按源建立粗略的日志量基线，偏离时提示到人，不做自动判断。
• 断流后先查三件事：源头文件还在不在、缓存是否还有、能否重放解析。
• 补不回来的空白要登记：哪个源、哪段时间、什么原因、影响哪些检索。
• 把设备退役、系统重装、账号改密三类变更纳入通知范围。
• 每月动作的最后一步是回写规则，否则同样的问题半年后再来一次。

若您正在运行一套日志平台，想确认该采的是否都真的在采，或希望把采集覆盖率做成每月可核的一件事，欢迎 预约咨询。