腾讯云可观测平台全链路追踪

全链路追踪简介
全链路追踪（Full-Link Tracing）是一种用于监控和分析分布式系统中单个请求从发起到最终响应的完整路径的技术。它就像给系统的每一次请求分配一个“全程物流单号”，无论这个请求在复杂的系统内部经过多少服务“中转站”，您都能清晰看到它的整个行程和每个环节的状态。
全链路追踪的实现主要依赖于以下几个关键技术点：
标识符生成与传递：当请求进入系统时（例如通过网关或 Web 服务器），会立即生成一个唯一的 Trace ID。这个 ID 会像“接力棒”一样，通过 HTTP 请求头或 RPC 框架的上下文，在后续所有相关的服务调用中持续传递下去。
数据记录（Span）：请求每经过一个服务，该服务就会创建一个或多个 Span，详细记录操作的开始时间、耗时、标签（如 HTTP 方法、URL、状态码）以及可能发生的异常事件。这些 Span 通过父子关系组织起来，最终形成一棵完整的“调用树”。
数据收集与可视化：各个服务生成的 Span 数据会被异步上报到一个集中的收集器，然后存储到数据库中。最终，这些数据可以通过可视化界面展示出清晰的调用链图，让您对请求的路径和每个环节的耗时一目了然。
而链路追踪上下文的跨服务、跨协议传递是实现全链路监控的基础。主流追踪系统通过在请求元数据中添加特殊字段（如 traceparent、SW8），实现调用链的关联与追踪。目前主流的跨服务、跨协议传递协议规范有两个，基于 W3C Trace Context 规范的 traceparent，以及 SkyWalking 定义的 SW8。
﻿
W3C Trace Context 简介
W3C Trace Context 是一个由万维网联盟（W3C）制定的标准化规范，用于在分布式系统中传递追踪上下文信息。它定义了标准的 HTTP 头部格式，使得不同的追踪和诊断产品能够相互协作，实现跨服务的请求追踪。
W3C Trace Context 规范主要包含两个 HTTP 头部字段，traceparent 头部和 tracestate 头部。当请求进入系统时，会生成一个唯一的 trace ID，这个 ID 通过 HTTP 头部在后续所有相关服务调用中持续传递。每个服务都会创建 Span 记录操作信息，最终形成完整的调用树。这些数据被收集到集中式存储，并通过可视化界面展示。
traceparent：携带分布式追踪的核心上下文信息（如 trace-id、Span ID、采样标志），协议规范如下。
// 格式
traceparent: <version>-<trace-id>-<parent-id>-<trace-flags>
// 示例
traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
// 字段说明
version：2个字符，表示版本号，当前为00
trace-id：32个字符，全局唯一的追踪 ID（16 字节，通常为 128 位十六进制字符串）
parent-id：16个字符，当前请求的父 Span ID（8 字节，通常为 64 位十六进制字符串）
trace-flags：2个字符，采样标志，01 表示采样，00 表示未采样
tracestate：携带供应商自定义的追踪信息，支持多供应商链路追踪场景。
// 格式
tracestate: <key1>=<value1>,<key2>=<value2>,...
// 示例
tracestate: sw=abc123,ot=xyz456
// 字段说明
tracestate 是可选字段，允许不同厂商在链路追踪上下文中添加自定义信息。多个供应商信息以逗号分隔，顺序有意义（最左侧优先）。
在 HTTP 协议中，通过在 HTTP 请求头中添加 traceparent 和 tracestate 字段，可实现链路追踪上下文的传递。
GET /api HTTP/1.1
Host: example.com
traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
tracestate: sw=abc123
除了 HTTP 协议外，W3C Trace Context 还支持其他通信协议，包括 gRPC 协议、AMQP、MQTT 等，确保在各种分布式系统环境中都能正常工作。以下是在 gRPC 协议中的传递规范，主要是在 metadata 中传递 traceparent 和 tracestate 字段。
md := metadata.Pairs(
  "traceparent", "00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01",
  "tracestate", "sw=abc123"
)
ctx := metadata.NewOutgoingContext(context.Background(), md)
说明：
消息队列（MQ）协议：在消息属性（如 Kafka headers、RocketMQ Message Properties）中传递 traceparent 和 tracestate 字段。
对于其他的协议，只要协议支持自定义元数据（如 header、metadata、属性），都可以传递 traceparent 和 tracestate 两个字段。
SkyWalking 及 SW8简介
SkyWalking 是一款开源的分布式系统应用程序性能监控（APM）工具，专为微服务、云原生架构和基于容器（Docker、Kubernetes、Mesos）的架构而设计。它提供了分布式追踪、性能指标分析、应用服务依赖分析、可视化一体化等解决方案。
SW8协议是 SkyWalking 的跨进程传播协议，用于在分布式系统中传递追踪上下文信息。该协议定义了标准的 HTTP 头部格式，使得不同的追踪和诊断产品能够相互协作。
// 协议
SW8: <traceId>-<segmentId>-<SpanId>-<service>-<serviceInstance>-<endpoint>-<targetAddress>-<sample>
﻿
// 示例
SW8: dHJhY2VJZA==-c2VnbWVudElk-MA==-c2VydmljZQ==-aW5zdGFuY2U=-ZW5kcG9pbnQ=-dGFyZ2V0QWRkcmVzcw==-MQ==
﻿
// 字段说明
traceId：位置1，全局唯一的追踪链路 ID（Base64 编码）
segmentId：位置2，当前服务生成的 segment ID（Base64 编码）
SpanId：位置3，当前 Span 的编号（Base64 编码的整数，通常为 0、1、2...）
service：当前服务名（Base64 编码）
serviceInstance：当前服务实例名（Base64 编码）
endpoint：当前调用的入口（如 HTTP 路径，Base64 编码）
targetAddress：目标地址（如主机:端口，Base64 编码）
sample：采样标志（Base64 编码的字符串，"1" 表示采样，"0" 表示不采样）
RUM Pro 的全链路追踪功能优势
RUM Pro 的全链路追踪能力核心特色在于将链路追踪的起点从后台服务向前延伸至终端用户发起请求的初始时刻，从而构建起一条真正贯穿“客户端→网络→后台服务”的完整可观测链路。
拓展链路起点，覆盖端到端场景
传统的分布式链路追踪技术主要关注服务间的调用关系，其“起点”通常是到达网关或首个后端服务的请求。而 RUM Pro 通过代码插桩或业务动态接入等方式，基于其网络监控能力，在客户端层面拦截所有发出的 HTTP 请求，并自动注入标准的追踪上下文信息（如 traceparent 头部和 SW8 头部）。这种做法将一次请求的完整生命周期追溯到了其在客户端产生的源头，实现了从用户操作开始的全链路追踪。
拥抱开放标准，实现无缝对接
为了实现与异构后台系统的顺畅对接，RUM Pro 选择了拥抱开放标准。它注入的 traceparent 头部遵循 W3C Trace Context 规范，而 SW8 头部则兼容 Apache SkyWalking 的跨进程传播协议。只要后端监控系统（如 Zipkin、Jaeger、SkyWalking 等）支持并解析这些通用标准，就能识别并继续传递由 RUM Pro 在客户端生成的追踪上下文。这使得 RUM Pro 能够与各类遵循规范的后台监控系统无缝集成，共同构建完整的调用链视图。
关联多维数据，精准定位问题
通过将客户端请求与后端链路关联起来，RUM Pro 能够帮助开发者：
精准定位问题边界：当问题发生时，能快速判断是客户端网络异常、特定机型兼容性问题，还是后端服务性能瓶颈或错误所致。
关联分析用户体验：可以将后端的服务响应耗时与前端的页面加载时间、应用启动时间等性能指标关联分析，全面评估优化效果。
RUM Pro 的全链路追踪特色在于“始于客户端，融于后端生态” 的能力。它通过支持开放标准，有效地弥合了前端与后端在可观测性领域的鸿沟，为开发者提供了一个从用户设备到最终服务的、无缝连接的完整链路视角。
接入 RUM Pro 的全链路追踪（仅支持 Android 平台）
RUM Pro 的全链路追踪依赖 RUM Pro 的网络监控能力，在客户端层面拦截所有发出的 HTTP 请求，并自动注入标准的追踪上下文信息。
为了实现监听网络请求和注入追踪上下文信息，RUM Pro 同时支持代码插桩和业务动态接入这两种方式。无论是哪一种方式都需要开启网络监控功能。
RUM Pro 的网络监控功能通过集成 OkHttp 的 EventListener 机制，实现了对 HTTP 请求质量的监控。该功能不仅能够追踪请求总耗时、成功率、上行/下行数据量等核心指标，还能细化分析 DNS 解析、TCP 连接、TLS 握手、请求发送、响应接收等关键阶段的耗时情况。只要您的业务使用的是基于 OkHttp 的网络库（例如 Retrofit、Fuel、RxEasyHttp 等），RUM Pro 的网络监控均可实现无缝兼容 。
除此之外，RUM Pro 通过多种方式支持对 Android 原生网络请求接口的监控。
步骤1：管理台打开网络监控
网络监控默认是关闭的，业务需要通过 应用配置 > SDK 配置，调整 net_quality 的采样率来开启网络监控。在接入验证阶段，推荐全量打开（即 sample_ratio 设置为1）。
sample_ratio：设备采样率，表示允许多少设备开启网络监控。
daily_report_limit：表示网络监控的数据上报，每天最多允许上报多少次。网络监控的数据是合并上报的，具体合并的情况由 max_batch_count, min_batch_count 来决定。
max_batch_count：表示一条网络监控的数据上报中，最多包含多少条 HTTP 请求质量的明细数据，默认是100。
min_batch_count：表示一条网络监控的数据上报中，最少包含多少条 HTTP 请求质量的明细数据，默认是50 。
说明：
在接入验证阶段，推荐将 sample_ratio 设置为1，max_batch_count 和 min_batch_count 调小一些，方便验证上报。验证完成后，需要将这三个配置恢复为默认值，或者根据业务特点设置合适的参数。
﻿
步骤2：业务接入全链路追踪
RUM Pro 目前支持两种方案来接入全链路追踪：代码自动插桩方案 和 业务主动适配接入。
方案一：代码自动插桩方案
在 SDK 接入方面，业务可以选择代码插桩方式来监控网络请求。RUM Pro 发布了一个代码插桩的插件 com.tencent.bugly.perf，业务可以参考以下流程，接入插件。
1. 在项目根目录的 build.gradle 文件的 buildscript 节点，补充 BuglyPerf 的插件信息。
buildscript {
    repositories {
        google()
        mavenCentral()
        maven { url 'https://repo1.maven.org/maven2/' }
        maven { url 'https://oss.sonatype.org/content/repositories/snapshots/' }
        maven { url 'https://mirrors.tencent.com/repository/maven/thirdparty-snapshots' }
    }
﻿
    dependencies {
        classpath 'com.android.tools.build:gradle:7.4.2'
        classpath 'com.tencent.bugly.perf:bugly-perf-plugin:1.0.1-SNAPSHOT'
    }
}
2. 在需要网络监控的子项目的 build.gradle 文件中，引入 com.tencent.bugly.perf 这个 plugin，及 Bugly SDK 依赖。
plugins {
...
    id 'com.tencent.bugly.perf'
...
}
...
// BuglyPerf 代码插桩插件配置
BuglyPerfPlugin {
    debugMode false
    instrumentSomeJar true
    includePackages = ['okhttp3/']
    excludePackages = ['android/support', 'androidx']
    includeJarNames = ['bugly-library', 'okhttp']
}
...
// 依赖 Bugly SDK （要求4.4.7.9及以上版本）
dependencies {
...
implementation "com.tencent.bugly:bugly-library:4.4.7.9-SNAPSHOT"
...
}
3. 重新编译构建应用
./gradlew installDebug 
方案二：业务主动适配接入
如果业务不想通过插桩方案来接入网络监控，可以通过非插桩方案，在业务代码中主动适配。主要的适配点包含 okhttp 的请求适配，以及 Android 原生请求的适配。
okhttp 请求适配核心逻辑是，使用经过 RUM Pro 适配过的 OkHttpClient.Builder 来创建 OkHttpClient。这样 RUM Pro 有机会在 Builder 中插入 Interceptor 以及 EventListener.Factory。业务适配的示例代码如下所示：
// 方案一：ClientBuilder.createClient  
OkHttpClient client = ClientBuilder.createClient(oldClient); 
﻿
// 方案二：ClientBuilder.enhanceBuilder
ClientBuilder.enhanceBuilder(oldBuilder);
OkHttpClient client = builder.build();
除了 okhttp 请求外，业务也有可能直接使用 Android 系统提供的原生 URLConnection 来发起请求。针对这种情况，RUM Pro 提供了两种方式：
方式1：直接通过 ClientBuilder.wrapURLConnection 包装系统返回的 URLConnection，示例代码如下所示。这种方式需要修改每一处使用 URL.openConnection 的地方，比较繁琐。
// 通过 ClientBuilder.wrapURLConnection 包装
HttpURLConnection connection = ClientBuilder.wrapURLConnection(url.openConnection());
直接基于 okhttp 的能力，代理系统原生的 HttpURLConnection。这种方式，只需要在进程创建后，执行一次开启逻辑即可，比较简洁。如果想代理「使用系统原生接口」的 Http 请求，推荐在 Application#onCreate 时尽早开启代理。
// 开启代理：
BuglyURLStreamHandlerFactory.init();
...
// 关闭代理: 开启代理后，也可以动态关闭代理。
BuglyURLStreamHandlerFactory.reset();
步骤3：关联业务系统
将终端性能监控 Pro 的业务系统与 APM 的业务系统进行关联。进入 终端性能监控 Pro > 资源管理 > 业务系统 页面，选择需要关联的业务系统，单击编辑，添加要关联的 APM 业务系统，然后单击确定。
﻿
步骤4：查看全链路数据
1. 前往 网络 监控，可查看指定请求的详情，单击详情中的全链路追踪，可以直接查看链路详情。
﻿
2. 单击全链路追踪的链接，然后单击查看链路详情即可跳转链路追踪页面。
﻿
在链路详情页面即可查看详细信息。
﻿
﻿
全链路追踪

本页目录：

全链路追踪简介

W3C Trace Context 简介

SkyWalking 及 SW8简介

RUM Pro 的全链路追踪功能优势

接入 RUM Pro 的全链路追踪（仅支持 Android 平台）

步骤1：管理台打开网络监控

步骤2：业务接入全链路追踪

方案一：代码自动插桩方案

方案二：业务主动适配接入

步骤3：关联业务系统

步骤4：查看全链路数据
