结论先行：采集覆盖不能用一句「已全覆盖」交差。真正可核的做法是按系统层级拆开，从用户入口一直到基础设施逐层对，每一层给出「能看到什么、怎么算核到了」的判据。设备清单只能证明装了多少台，证明不了故障发生时能不能拿到需要的那段证据。
为什么按层核，而不是按设备核
按设备核的结果是一份数量清单：服务器多少台、容器多少个、探针装了多少套。这份清单回答的是部署进度，不是观测能力。一次真实的故障定位往往跨层——用户说慢，先看入口耗时分给了谁，再看接入层有没有排队，再看应用层哪一跳变长，最后落到数据库或中间件。任何一层缺数据，链条就在那里断掉，前面的数据也白采。
六层覆盖与各自的判据
| 层面 | 该看到的对象 | 怎么算核到了 |
|---|---|---|
| 用户层 | 网页、移动端、小程序、第三方渠道入口 | 能拿到一次真实访问的加载耗时与请求明细，而不只是服务端返回时间 |
| 接入层 | 反向代理、接口网关、负载均衡 | 网关侧的错误码与耗时，能与后端服务记录对应上同一次请求 |
| 应用层 | 微服务、单体应用、定时任务、外部接口调用 | 一次请求跨服务的调用链能完整串起来，中间不出现断点 |
| 中间件 | 缓存、消息队列、搜索 | 队列堆积与缓存命中情况，能反映到对应请求的耗时变化上 |
| 数据层 | 关系库、缓存库、文件存储 | 慢查询能落到具体语句与调用方服务，而不是只有库的整体负载 |
| 基础设施 | 物理机、虚拟机、容器、网络、存储 | 资源曲线能与业务请求量放在同一时间轴上对比 |
三层最常缺
- 接入层。网关与负载均衡的日志常被当成网络设备日志，归到网络组去采，结果是接口网关这一层在观测平台上没有对应数据。而排队与超时恰恰最容易发生在这一层。
- 中间件。常见情况是只采了生产侧，没采消费侧。于是队列里堆了多少消息看得见，消费延迟多长看不见，故障时就分不清是生产太快还是消费卡住。
- 数据层。只采了库的连接数、处理器、磁盘这些整体指标，没落到具体语句。整体指标正常但业务慢的情况，在这一层就查不下去了。
核的三个动作
- 拿一条真实业务请求走全程。从用户端点的动作开始，逐层确认每一层都留下了记录，并且相邻两层的记录能对上同一次请求。对不上就说明层与层之间没有关联标识。
- 定时任务与批处理单独跑一次。这类任务不走用户入口，只核用户入口的项目会把它们整体漏掉，而它们恰恰是异步链路上最常见的问题点。
- 第三方接口调用单独核。它不出现在内部调用链的常规路径上，出问题时要靠它来做对账与申诉，事后补采是补不回来的。
把覆盖写进验收表
建议用三档标注，而不是打勾：标「覆盖」的写判据，标「部分覆盖」的写清缺什么，标「不覆盖」的写替代手段。三档写在合同附件或验收单上，比口头确认可靠得多——半年后换人接手，这张表就是交接材料。
本文只谈按系统层级核对采集覆盖、以及验收表怎么填；不谈同一套采集端在不同开发语言上的采集深度差异，不谈采集端以什么身份运行，也不谈接入前要准备哪些变更材料。
深圳市奇摩计算机有限公司在做这类验收时，会把这条真实请求的逐层记录、定时任务的补充采集、第三方接口的对账记录一并附在验收单后，作为覆盖范围的凭据。预约咨询