探针是谁关的，没人记得

结论先行：观测平台最怕的不是数据量太大，而是该有的数据不知道什么时候没了。覆盖率下降的常见原因不是故障，而是一连串没人记录的小动作：排障时临时关掉某个采集项、扩容时新实例没下发探针、业务下线后旧容器被回收但采集没跟着清、某个高频采集为了压开销被调成了低频。可行的做法是把采集的开关当成一类正式变更来管——有授权、有登记、有复核，让「这里为什么没数据」在事后能查出答案。

本文只谈采集侧开关的授权、留痕与复核，不谈告警规则该怎么配，也不谈探针版本升级与升级带来的口径差异。文中带宽与资源占用等指标为方案文档给出的参考值，实际以部署环境实测为准。

三种关法，性质完全不同

「关掉采集」这个动作在口语里是一件事，落到管理上是三件互不相同的事，处置方式也不一样。

三类里最容易出事的是临时抑制那一类。临时抑制天生带一个「到期时间」，而现实中很少有人在到期时回来恢复——排障结束之后，所有人都往前走了，没人记得那个开关还开着。等三个月后出问题，需要那段数据，才发现它从某个时点开始就是空的。

为什么没人记得是谁关的

采集的开关通常在平台界面上只是一个按钮，谁有平台账号谁就能点。这与真正需要审批的变更相比，门槛低得太多。

常见的情形是这样：夜里业务异常，值班的人登录平台，看到某个采集项在刷大量日志，影响检索体验，顺手把它关了。问题解决了，人下班了。这个动作没有工单、没有记录、没有第二个人知道。半年后做容量规划或者做故障复盘，需要那段时间的数据，去问当时值班的人，他已经不记得有这回事。

这不是责任心的问题，是流程设计的问题。一个动作如果没有强制留下痕迹的环节，它在组织记忆里就是不存在。

授权分两层就够了

不必把采集开关做成和网络变更一样的重流程——那样只会让人绕过它。两层授权足够覆盖大部分情况。

常设层：哪些采集项属于「基线采集」，即任何情况下都不允许单独关掉。这一层的清单通常不长，覆盖的是核心业务链路、关键交易接口和审计相关日志。要动这一层，必须走正式的变更流程。

可调层：其余采集支持临时抑制与调稀，但必须在平台里填写三个字段——原因、到期时间、影响范围。到期自动恢复是这一层的关键设计：靠人记得恢复永远不可靠，让系统到点自己恢复才可靠。

两层之外还有一种情况要单独说：为压开销而把采集频率降下来。这一步的代价往往不在当下，而在半年后需要还原一次故障过程的时候。可用的判断是：如果某条链路涉及资金、涉及对外接口、或者在合规范围里，就不允许为了省存储而降频；其余的按开销与可观测性的比例取舍。

台账上要有那个数字

采集是否完整，需要一个能被周期性拿出来看的数字。

可用的做法是每月做一次简单的对照：把资产台账里在跑的实例清单，与平台里实际有数据上报的实例清单，做一次差集。差集里通常会出现几类东西——新扩容但忘了下发探针、搬迁后旧地址还在、测试环境误接进生产、以及被谁关掉采集的那些。

这个数字不需要精确到每一台，只要能把「计划覆盖」与「实际覆盖」的差稳定地呈现出来，就足以推动整改。关键在于它是周期性的、有责任人的，而不是等到出事才临时盘一次。

顺带说一句资源侧的实际情况：成熟的采集方案在单服务上的开销通常被控制在很低的水平——方案文档给出的参考值是单服务 CPU 占用在 3% 以内、内存 128M 以内，并且支持非特权账户部署、支持断连时本地缓存、恢复后补传。这些能力的存在说明一件事：多数「必须关掉采集才能保住性能」的判断，其实是可以被替代方案解决的。深圳市奇摩计算机有限公司在给客户做观测平台落地时，会把这条当成前置沟通项：先确认关采集的理由，再看有没有不用关的做法。

复核放在什么节奏上

三个时间尺度可以覆盖多数情况。

• 每周看一次临时抑制的清单，把已经过期的摘掉，把反复出现的抑制原因归类——反复出现的抑制通常意味着那条采集规则本身该改。
• 每月做一次覆盖对照，出一次计划与实际的差集。
• 每季度把基线采集清单复核一次，业务变了、架构变了，基线也要跟着变。

这三件事都不重，加起来每人每月不到一天。它们的价值在故障复盘的时候体现得最明显：能说清「那段时间为什么没有数据」，比事后解释「我们以为数据是有的」要省力得多。

边界与前提

采集开关的治理解决的是「数据缺口能被解释」，不解决「缺口怎么补」——已经空掉的时间段，事后补不回来。另外，如果一个单位的观测平台还没有稳定的资产台账，覆盖对照会变成一次大型盘点，建议先把台账这件事做成周期动作，再叠加采集治理。

需要核对自家观测覆盖率的，可以预约咨询。