不是所有系统都值得接全链路，先分四类

结论先行：全链路监测的覆盖面常被当成一个越高越好的指标，实际上它的成本随服务数量增长，而绝大多数故障落在少数几条主路径上。四类系统可以先不接：没有用户直接访问的内部批处理、调用量极低且不影响主流程的边缘服务、已经明确要下线的系统、以及第三方提供的不可观测接口。把这四类排除之后，剩下的服务数量通常会少掉一半以上，而排障能力的损失远小于这个比例。

本文只谈接入范围该怎么做取舍、哪些系统先不接，不谈采集覆盖够不够全、也不谈某个具体系统该用什么方式埋点。覆盖率是另一个问题，两者的口径不一样。

先说清一个容易被跳过的账

链路数据的量级不是按服务数线性来的，是按「服务数 × 调用次数 × 采样率」来的。一个每天被调用百万次的服务，与一个每天被调用十次的内部任务，在数据量上差五个数量级，但它们在接入清单上占同样的两行。

这就带来一个常见的错配：接入工作量按「个系统」算，存储成本按「条数据」算，两边的计价单位不一样。评估阶段拿「接了多少个系统」汇报进度，容量阶段才发现真正吃存储的是其中少数几个高频服务。

动态采样是缓解这件事的一个手段：日常低采样降低存储开销，检测到报错或超时时自动切换全量采集。它解决的是「同一个服务在不同时段该采多少」，解决不了「这个服务该不该接」。后一个问题只能在范围层面回答。

四类可以先不接

内部批处理这一类最容易被误判。批处理不是「慢一点的服务」，它是另一类形态：没有用户等着，没有入口耗时，问题的表现通常是「跑完了但结果不对」或者「没跑完」，用链路的方式追不到根因，需要的是任务编排与数据比对。

第四类的取舍要说透。第三方接口在链路上确实是一个耗时环节，问题在于它内部不可见。接进来的结果是链路图上有这个节点、有时间、但没有下钻，排障时能做到的只是「确认这三十毫秒花在外部」。这件事用调用方的边界埋点就能做到，不需要把整条链路延长过去。

「不接」不等于「不看」

这是排除项能不能落地的关键。如果排除之后这些系统变成了监测盲区，那排除就是错的。

正确的做法是给每一类配一种替代手段，让它仍然在视野内，只是换了个视角。批处理看结果与耗时分布；边缘服务看可用性与错误率；即将下线的系统保持现状不投入；第三方看边界指标与对账口径。这四类手段都不需要链路数据，成本也低得多。

换个说法：全链路监测解决的是「一次请求在系统内部怎么走」这个问题，不是所有问题都是这个问题。把不是这个问题的东西硬塞进来，结果是数据变多、判断变慢。

顺序怎么排

范围定完之后，接入顺序本身也影响成败。一个可行的排法是按「用户能感知到的路径」由外向内。

先接用户入口这一段：页面、小程序、网关。这一段的价值是它对应着真实的用户投诉，接上之后「用户说慢」这句话就有了一手的加载数据。再接应用层，把一次请求跨服务的路径串起来。再接中间件与数据库，让链路末端能落到具体语句。基础设施放最后，因为它与链路是两种数据，关联价值高但对链路的完整性没有贡献。

按这个顺序，每一批上线之后都有一段可用的能力，而不是「全接完了才能用」。反过来按资产清单顺序接，很容易出现接了六十个系统却仍然答不出「刚才那笔交易慢在哪」的场面。

评估阶段就要把范围写清

接入范围这件事，最怕的是没有写下来。项目做到一半，业务方按部门提需求，每提一个就加一个系统，范围只增不减，容量规划永远滞后。

可行的做法是在方案阶段就把三份清单列出来：接入清单、暂不接入清单、以及每一类的替代手段。暂不接入清单同样要写解锁条件——比如「调用量上升后重新评估」「第三方提供可观测能力后接入」。

这三份清单放进验收材料里，后面每次扩容都有依据。如果只在方案里写「全覆盖」，验收时无法核对，扩容时也没有边界。

边界与前提

三点说明。其一，本文讨论的是接入范围的取舍逻辑，不涉及具体系统的判断；同一个系统在不同单位的位置可能完全不同，取决于它在业务流程里的作用。其二，四类「暂不接入」都附带解锁条件，条件成立时应当重新评估，不宜当成长期结论。其三，链路数据的存储与检索成本受采样策略影响很大，范围与采样两件事要一起定，只调其中一项效果有限。

深圳市奇摩计算机有限公司在这类可观测项目的实施中，通常先把「不接什么」谈清楚再谈「怎么接」，因为这个顺序定下来之后，容量与工期才有可算的基础。预约咨询，可以按你现有的服务清单与调用量分布，一起把范围划出来。