1. 背景介绍

首先，我们了解一下移动端全链路Trace 的背景：

从移动端的视角来看，一个App产品从概念产生，到最终的成熟稳定，产品研发过程中涉及到的研发人员、工程中的代码行数、工程架构规模、产品发布频率、线上业务问题修复时间等等都会发生比较大的变化。这些变化，给我们在排查问题方面带来不小的困难和挑战，业务问题会往往难以复现和排查定位。比如，在产品初期的时候，工程规模往往比较小，业务流程也比较简单，线上问题往往能很快定位。而等到工程规模比较大的时候，业务流程往往涉及到的模块会比较多，这个时候有些线上问题就会比较难以复现和定位排查。

本文是笔者在 2022 D2 终端技术大会上的分享，希望能给大家带来一些思考和启发。

2. 端侧问题为什么很难复现和定位？

线上业务问题为什么很难复现和排查定位？经过我们的分析，主要是由4个原因导致：

• 移动端 & 服务端日志采集不统一，没有统一的标准规范来约束数据的采集和处理。

• 端侧往往涉及的模块非常多，研发框架也各不相同，代码相互隔离，设备碎片化，网络环境复杂，会导致端侧数据采集比较难。

• 从端视角出发，不同框架、系统之间的数据在分析问题时往往获取比较难，而且数据之间缺少上下文关联信息，数据关联分析不容易。

• 业务链路涉及到的业务域往往也会比较多，从端的视角去复现和排查问题，往往需要对应域的同学参与排查，人肉运维成本比较高。

这些问题如何来解决？我们的思路是四步走：

• 建立统一标准，使用 标准协议 来约束数据的采集和处理。

• 针对不同的平台和框架，统一数据采集能力。

• 对多系统、多模块产生的数据进行自动上下文关联分析和处理。

• 我们也基于机器学习，在自动化经验分析方面做了一些探索。

3. 统一数据采集标准

如何统一标准？目前行业内也有各种各样的解决方案，但存在的问题也很明显：

• 不同方案之间，协议/数据类型不统一；

• 不同方案之间，也比较难以兼容/互通。

标准这里，我们选择了 OTel，OTel 是 OpenTelemetry 的简称，主要原因有两点：

• OTel 是由云原生计算基金会（CNCF）主导，它是由 OpenTracing 和 OpenCensus 合并而来，是目前可观测性领域的准标准协议；

• OTel 对不同语言和数据模型进行了统一，可以同时兼容 OpenTracing 和OpenCensus，它还提供了一个厂商无关的Collectors，用于接收、处理和导出可观测数据。

在我们的解决方案中，所有端的数据采集规范都基于OTel，数据存储、处理、分析是基于SLS提供的LogHub能力进行构建。

4. 端侧数据采集的难点

只统一数据协议还不够，还要解决端侧在数据采集方面存在的一些问题。总的来说，端侧采集当前面临3个主要的难点：

• 数据串联难

• 性能保障难

• 不丢数据难

端侧研发过程中涉及到的框架、模块往往比较多，业务也有一定的复杂性，存在线程、协程多种异步调用API，在数据采集过程中，如何解决数据之间的自动串联问题？移动端设备碎片化严重，系统版本分布比较散，机型众多，如何保障多端一致的采集性能？App使用场景的不确定性也比较大，如何确保采集到的数据不会丢失？

4.1 端侧数据串联的难点

我们先来分析一下端侧数据自动串联所面临的主要问题。

1. 在端侧数据采集过程中，不仅会采集业务链路数据，还会采集各种性能&稳定性监控数据，可观测数据源比较多。

2. 如果用到其他的研发框架，如OkHttp、Fresco等，可能还会采集三方框架的关键数据用于网络请求，图片加载等问题的分析和定位。对于业务研发同学来说，我们往往不会过多的关注这类三方框架技术能力，涉及到这类框架问题的排查时，过程往往比较困难。

3. 除此之外，端侧几乎完全异步调用，而且异步调用API比较多，如线程、协程等，链路打通也存在一定的挑战。

这里会有几个共性问题：

• 三方框架的数据如何采集？如何串联？

• 不同可观测数据源之间如何串联？

• 分布在不同线程、协程之间的数据如何自动串联？

4.2 端侧数据自动串联方案

我们先看下端侧数据自动串联的方案。

在 OTel 协议标准中，是通过 trace 协议来约束不同数据之间的串联关系。OTel 定义了trace数据链路中每条数据必须要包含的必要字段，我们需要确保同一条链路中数据的一致性。比如，同一条trace链路中，trace_id需要相同；其次，如果数据之间有父子关系，子数据的 parent_id 也需要与父数据的 span_id 相同。

我们知道，不管是Android平台，还是iOS平台，线程都是操作系统能够调度的最小单元。也就是说，我们所有的代码，最终都会在线程中被执行。在代码被执行过程中，如果我们能把上下文信息和当前线程进行关联，在代码执行时，就能自动获取当前上下文信息，这样就可以解决同一个线程内的trace数据自动关联问题。

在 Android 中，可以基于线程变量 ThreadLocal 来存储当前线程栈的上下文信息，这样可以确保在同一线程中采集到的业务数据进行自动关联。如果是在协程中使用，基于线程变量的方案就会存在问题。因为在协程中，协程真实运行的线程是不确定的，可能会在协程执行的生命周期内进行线程切换，我们需要利用协程调度器和协程Context来保持当前上下文的正确性。在协程恢复时，让关联的上下文信息在当前线程生效，在协程挂起时，再让上下文信息在当前线程失效。

在iOS中，主要基于 activity tracing 机制来保持上下文信息的有效性。通过 activity tracing 机制，在一个业务链路开始时，会自动创建一个activity，我们把上下文信息与activity进行关联。在当前 activity 作用域范围内，所有产生的数据都会与当前上下文自动关联。

基于这两种方案，在产生Trace数据时，SDK会按照 OTel 协议的标准，自动把上下文信息关联到当前数据中。最终产生的数据，会以一棵树的形式进行逻辑关联，树的根节点就是Trace链路的起点。这种方式，不仅支持协程/线程内的数据自动关联，还支持多层级嵌套。

4.3 三方框架的数据采集和串联

针对三方框架的数据采集，我们先看看业内通行的做法，目前主要有两类：

1. 如果三方库支持拦截器或代理的配置，一般会通过在对应拦截器增加埋点代码的方式来实现；

2. 如果三方库对外暴露的接口比较少，一般会通过Hook或其他方式增加埋点代码，或者不支持对应框架的埋点。

这种做法会存在两个主要的问题：

1. 埋点不完全，拿OkHttp来举例说明，三方SDK内部也可能存在对OkHttp的依赖，通过拦截器的方式，可能只支持当前业务代码的埋点采集，三方SDK的网络请求信息无法被采集到，会导致埋点信息不完全。

2. 可能需要侵入业务代码，为了实现对应框架的埋点，需要有一个切入时机，这个切入时机往往需要在对应框架初始化时增加代码配置项来实现。

如何解这两个问题？

我们使用的方案是实现一个 Gradle Plugin，在 Plugin 中对字节码进行插桩处理。

我们知道，Android App 在打包的过程中，有个流程会把 .class 文件转为 .dex 文件，在这个过程中，可以通过 transform api 对 class 文件进行处理。我们是借助 ASM 的方式来实现 class 文件的插桩处理。在对字节码处理的过程中，需要先找到合适的插桩点，然后注入合适的指令。

这里拿OkHttp的字节插桩进行举例：插桩的目标是在 OkHttpClient 调用 newCall 方法时，把当前线程的上下文信息关联到 OkHttp 的 Request 中。在 Transform 过程中，我们先根据 OkHttpClient 的类名过滤出目标 class 文件，然后再根据 newCall 这个方法名过滤要插桩的方法。接下来，需要在 newCall 方法开始的地方把上下文信息插入到 request 的 tags 对象中。经过我们的分析，需要在 newCall 方法调用开始的时候，插入目标代码。为了方便实现和调试，我们在扩展库中实现了一个 OkHttp 的辅助工具，在目标位置插入调用这个工具的字节码，传入 request 对象就可以了。

插入后的字节码会和扩展库进行关联。这样就能解决三方框架数据采集和上下文自动关联的问题。

相对于传统做法，使用字节码插桩的方案，业务代码侵入性会更低，埋点对业务代码和三方框架都能生效，同时结合扩展库也能完成上下文的自动关联。

4.4 如何确保性能

在可观测数据采集过程中，会有大量的数据产生，对内存、CPU占用、I/O负载都有一定的性能要求。

我们基于C对核心部分进行实现，确保多平台的性能一致性，并从三个方面对性能做了优化：

首先，是对协议化处理过程进行优化。数据协议方面选择使用Protocal Buffer协议，Protocal Buffer相对JSON来说，不仅速度更快，而且更省内存空间。在协议的序列化上，我们采用了手动封装协议的实现，在序列化的过程中，避免了很多临时内存空间的开辟、复制以及无关函数的调用。

其次，在内存管理方面，我们直接对SDK的最大使用内存做了可配置的大小限制。内存的使用，可以根据业务情况按需配置，避免SDK内存占用过大对 App 的稳定性造成影响；其次，还引入了动态内存管理机制，内存空间的使用按需增加，不会一直占用App的内存空间，避免内存空间的浪费。同时还提升了字符串的处理性能。在字符的处理上，引入了动态字符串机制，它可以记录字符串自身的长度，获取字符长度时，操作复杂度低，而且可以避免缓冲区溢出，同时也可以减少修改字符串时带来的内存重分配次数。

最后，在文件缓存管理方面，我们也限制了文件大小的上限，避免对端设备存储空间的浪费。在缓存文件的落盘处理上，我们引入了Ring File机制，把缓存数据存储在多个文件上面，以日志文件组的形式对多个文件进行组装。整个日志文件组以环形数组的形式，从头开始写，写到末尾再回到头重新循环写。通过这种方式写数据，可以减少写文件时的随机Seek，而且Ring File的机制，可以确保单个日志文件不会过大，从而尽可能的降低系统 I/O 的负载。除了Ring File的机制外，还把断点保存、缓存清理的逻辑放到了一起聚合执行，减少随机Seek。checkpoint的文件大小也做了限制，在超出指定大小后会对checkpoint文件进行清理，避免checkpoint文件过大影响文件读写效率。

经过上面的这些优化措施之后，最终SDK采集数据的吞吐量提升了2倍，内存和CPU占用都有明显的降低。每秒钟最高可支持400+条数据的采集。

4.5 如何确保日志不丢失？

性能满足要求还不够，还需要确保采集到的数据不能丢失。在App的使用过程中，app经常可能会出现异常崩溃，手机设备异常重启，以及网络质量差，网络延时、抖动大的情况。在这类异常场景下，如何确保采集到数据不会丢失？

在采集数据时，我们使用了预写日志（WAL）机制，并结合自建网络加速通道来优化这个问题。

1. 引入预写日志机制的目的是确保写入到SDK的数据，在发送到服务器之前，不会因为异常原因而丢失。这个过程的核心是，在数据成功发送到服务器之前，先把数据缓存在移动设备的磁盘上，数据发送成功之后，再移除磁盘上的缓存数据。如果因为App异常原因，或者设备重启导致数据发送失败，因为缓存的数据还在，SDK会根据记录的断点信息对数据发送进度进行恢复。同时预写日志机制可以确保数据的写入和发送并发执行，不会互相阻塞。

2. 在数据发送之前，还会对多条数据做聚合处理，并通过 lz4 算法进行压缩处理，这种做法可以降低数据发送时的请求次数和网络传输流量的消耗。如果数据发送失败，还会有重试策略，确保数据至少能成功发送一次。

3. 在数据发送时，SDK支持就近接入加速边缘节点，并通过边缘节点与SLS之间的内部网络加速通道传输数据。

经过这三种主要的方式优化之后，数据包的平均大小降低了2.1倍，整体的QPS平均提升13倍，数据整体的发送成功率达到了99.3%，网络延时平均下降了50%。

5. 多系统数据关联处理

解决了端侧数据的串联和采集性能问题之后，还需要处理多系统之间的数据存储和关联分析问题。

数据存储方面，我们直接基于 SLS LogHub 能力，把相关的数据统一存储，基于SLS，日均可以承载PB级别的流量，这个吞吐量可以支持移动端可观测数据的全量采集。

解决了数据的统一存储问题之后，还需要处理两个主要的问题：

第一个问题，不同系统可观测数据之间的上下文关联如何处理？

根据OTel协议的约束，我们可以基于 parent_id 和 span_id 来处理根节点、父节点、子节点之间的映射关系。首先，在查询Trace数据链路时，会先从SLS拉取一定时间段内的所有Trace数据。然后按照OTel协议的约束，对每条数据进行节点类型的判定。由于多系统的数据可能存在延时，在查询Trace数据链路时，有些数据可能还没有到达。我们还需要对暂时不存在的父节点进行虚拟化处理，确保Trace链路的准确性。接下来，还需要对节点进行规整处理，把属于同一个parent_id的节点进行聚合，然后再按照每个节点的开始时间进行排序，最终就可以得到一条trace链路信息，基于这个链路信息，我们可以还原出系统的调用链路。

第二个问题，在进行Trace分析时，我们往往还需要从系统视角出发，对不同维度的数据进一步分析。比如，如果想从设备ID、App版本、服务调用等不同维度，对Trace数据进一步分析，该怎么做？我们来看一下怎么解决这个问题。

6. 多系统数据拓扑生成

当我们从系统整体视角对问题进行分析时，所需要的Trace数据规模往往会比较大，每分钟可能有数千万条数据，而且对数据的时效性要求也比较高。传统的流处理方式在这种场景下很容易遇到性能瓶颈问题。我们采用的方案是，把流处理问题转换为批处理问题，把传统的链路处理视角转换为系统处理视角。经过视角转化之后，从系统视角来看，解决这个问题最主要的核心，就是如何确定两个节点之间的关系。

我们看一下具体的处理过程：

在批处理上，我们使用了 MapReduce 框架。首先，在数据源处理阶段，我们基于 SLS 的定时分析（ScheduledSQL）能力，对数据进行聚合处理，按照分钟级从 Trace 数据源中捞取数据。在 Map 阶段，先按照traceID进行分组，对分组之后的数据再按照 spanID、parentID 维度对数据进行聚合。然后计算出相关的统计数据，如成功率、失败率、延时指标等基础统计数据。在实际的业务使用中，往往还会采集一些和具体业务属性相关的数据，这部分数据往往会根据业务的不同，有比较大的差异。针对这部分类型的数据，在聚合处理的过程中，支持按照其他维度对结果进行分组。此时会得到两种中间产物：

• 包含两个节点关系的聚合数据，我们把这种类型的数据，叫做边信息

• 以及未匹配到的原始数据

这两种中间产物，在Combine阶段还会再进行聚合处理，最终会得到包含基础统计指标，以及其他维度的结果数据。

最终产物会包含几个主要的信息：

• 边信息，可以体现调用关系。

• 依赖信息，可以体现服务依赖关系。

• 还有指标信息，以及其他资源信息等。其中，业务属性相关的数据会体现在资源信息中。

基于这些产物，我们可以通过对资源、服务等信息的多个维度筛选，来统计出对应维度的问题分布和影响链路。

7. 自动化问题根因定位探索

接下来向大家介绍下，我们在自动化问题根因定位方向的一些探索。

我们知道，随着App版本的迭代，每次App的发版可能会涉及到多个业务的代码变更。这些变更，有的经过充分测试，也有的未经过充分测试，或者常规测试方法没有覆盖到，对线上业务可能会产生一定的潜在影响，导致部分业务不可用。App规模越大，业务模式越多，对应的业务数据量，请求链路，不确定性就越大。出了问题之后，往往需要多人跨域参与排查，人肉运维成本比较高。

如何在端侧问题排查定位方向，通过技术手段进行研发效能的提速？我们基于机器学习技术做了一些探索。

我们目前的方法是，先对Trace源数据进行特征处理；然后再对特征进行聚类分析，去找到异常Trace；最后再基于图算法等，对异常Trace进行分析，找到异常的起始点。

首先，实时特征处理阶段会读取Trace源数据，对每个Trace链路按照由底向上找5个节点的方式生成一个特征，并对特征进行编码。然后对编码之后的特征通过HDBSCAN算法进行层次聚类分析，此时相似的异常会分到同一个组里面，接下来再从每组异常Trace中找出一条典型的异常Trace。最后，通过图算法找到这条异常Trace的起点，从而确定当前异常Trace可能存在的问题根因。通过这种方式，只要是遵循OTel标准协议的数据源都能够进行处理。

8. 案例：多端链路追踪

经过对数据处理之后，我们来看下最终的效果。

这里有一个模拟 Android、iOS、服务端，端到端链路追踪的场景。

我们使用iOS App来作为指令的发送端，Android App 来作为指令的响应端，用来模拟远程打开汽车空调的操作。我们从图上可以看到，iOS端“打开车机空调”这个操作触发后，依次经过了“用户权限校验”、“发送指令”、“调用网络请求”等环节。Android 端收到指令后，依次执行“远程启动空调”、“状态检查”等环节。从这个调用图可以看得到，Android、iOS、服务端，多端链路被串联到了一起。我们可以从Android、iOS、服务端的任何一个视角，对调用链路进行分析。每个操作的耗时，对应服务的请求数，错误率，以及服务依赖都能体现出来。

9. 整体架构

接下来，我们来看下整套解决方案的架构：

1. 最底层是数据源，遵循OTel协议，各个端对应的SDK按照协议规范统一实现。

2. 数据存储层，是直接依托于 SLS LogHub，所有系统采集到的数据统一存储。

3. 再往上是数据处理层，对关键指标、Trace链路、依赖关系、拓扑结构、还有特征等进行了预处理。

4. 最后是上层应用，提供链路分析、拓扑查询、指标查询、原始日志查询，以及根因定位等能力。

10. 后续规划

最后总结下我们后续的规划：

1. 在采集层，会继续完善插件、注解等方式的支持，降低业务代码的侵入性，提升接入效率

2. 在数据侧，会丰富可观测数据源，后续会支持网络质量、性能等相关数据的采集

3. 在应用侧，会提供用户访问监测、性能分析等能力

最后，我们将计划把核心技术能力开源，共享社区，欢迎持续关注。

附：

1. 阿里云 SLS 服务介绍

2. 阿里云 SLS Trace服务介绍

3. 联系阿里云 SLS