结论先行：服务网格把流量治理下沉到每个实例旁挂的代理之后，应用只看到"调用发出去了"，中间的转发、重试、加密与连接池等待都发生在代理层，链路里凭空多出一段。要把这段并入调用链，核心是让代理层与应用层共用同一个链路标识，并把代理的出入口耗时单独成段上报；否则服务之间的耗时对不上，超时问题会被误判成应用或数据库慢。
为什么网格环境下链路容易对不上
没有代理时，一次调用大致是"应用 A → 网络 → 应用 B"。引入代理后变成"应用 A → 本地代理 → 网络 → 对端代理 → 应用 B"。多出来的两段各自有转发耗时、重试策略和超时配置，而应用侧的监控通常只记录自己发出请求到收到响应的时间，把中间的全部算进"网络耗时"或"对端耗时"。
结果是三类典型错位：端到端耗时远大于各应用耗时之和；应用报"对端无响应"但对端日志里根本没有这次请求；同一次业务请求在两端各生成一条链路，看上去接了，检索时依然断成两段。
三层数据分别能看什么
| 层次 | 能看到什么 | 看不到什么 |
|---|---|---|
| 应用内跨度 | 方法耗时、数据库语句、异常堆栈、业务字段 | 转发与网络耗时、重试次数 |
| 代理层跨度 | 出入口转发耗时、重试与限流事件、连接池等待 | 业务语义，如订单号、用户标识 |
| 基础设施指标 | 节点资源、网络吞吐、队列深度 | 单次请求的因果关系 |
三层缺任何一层，归因都会偏。只有应用数据，会把代理层的问题算到对端头上；只有代理数据，能说清"慢在哪一跳"，却说不清影响了哪笔业务。
打通的三个前提
- 标识透传。代理必须把上游请求中的链路标识原样向下传递，并在出入口各记录一次。使用非标准协议或自定义报文时，需要显式配置透传字段，不能依赖默认行为。
- 同一时间基准。应用、代理、节点统一接入内部时钟源。时钟偏差会让跨层的时间窗关联错位，表现是"数据都有，就是对不上"。
- 服务名口径统一。网格里的服务标识要与应用注册名、资产台账里的服务名一致。口径不一致会在拓扑上出现两个同名不同实体，统计口径随之分裂。
四类容易算错的地方
- 重试放大。代理自动重试会让调用次数大于业务请求数。吞吐类指标应按业务请求去重，否则容量判断会偏保守。
- 超时配置不一致。应用超时大于代理超时时，应用先抛"对端无响应"，真实原因却是代理层超时更短。两边的超时值应当集中登记并定期核对。
- 连接池等待。耗时集中在代理出口、后端却很健康时，多半是连接池耗尽或上游限流，而不是对端服务慢。
- 加密传输。启用加密后旁路抓不到内容，只能依赖代理侧主动上报。这一段如果没采集，链路里就存在一段空白。
落地清单
- 先确认代理的注入方式与标识透传配置，用一条核心链路做端到端验证，再推广到全量。
- 把代理层耗时设为独立指标，不与业务耗时合并统计。
- 对重试、限流、熔断事件单独打点，作为独立告警项而不是日志文本。
- 核对服务名与实例标识的映射关系，消除拓扑重影。
- 试运行期持续对比"应用耗时之和"与"端到端耗时"的差值，差值长期偏大说明仍有未纳入的段。
链路打通不是一次性的配置动作，而是随服务与代理版本持续校准的过程。奇摩在为金融与制造企业做可观测体系建设时，通常把代理层数据与应用层链路放在同一次试点里验证，避免上线后再回头补采集。