SLS:基于 OTel 的移动端全链路 Trace 建设思考和实践

语言: CN / TW / HK

作者:高玉龙(元泊)

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

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

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

端侧问题为什么很难复现和定位?

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

  • 移动端 & 服务端日志采集不统一,没有统一的标准规范来约束数据的采集和处理。
  • 端侧往往涉及的模块非常多,研发框架也各不相同,代码相互隔离,设备碎片化,网络环境复杂,会导致端侧数据采集比较难。
  • 从端视角出发,不同框架、系统之间的数据在分析问题时往往获取比较难,而且数据之间缺少上下文关联信息,数据关联分析不容易。
  • 业务链路涉及到的业务域往往也会比较多,从端的视角去复现和排查问题,往往需要对应域的同学参与排查,人肉运维成本比较高。

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

  • 建立统一标准,使用 标准协议 来约束数据的采集和处理。
  • 针对不同的平台和框架,统一数据采集能力。
  • 对多系统、多模块产生的数据进行自动上下文关联分析和处理。
  • 我们也基于机器学习,在自动化经验分析方面做了一些探索。

统一数据采集标准

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

  • 不同方案之间,协议/数据类型不统一;
  • 不同方案之间,也比较难以兼容/互通。

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

  • OTel 是由云原生计算基金会(CNCF)主导,它是由 OpenTracing 和 OpenCensus 合并而来,是目前可观测性领域的准标准协议;
  • OTel 对不同语言和数据模型进行了统一,可以同时兼容 OpenTracing 和 OpenCensus,它还提供了一个厂商无关的 Collectors,用于接收、处理和导出可观测数据。

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

端侧数据采集的难点

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

  • 数据串联难
  • 性能保障难
  • 不丢数据难

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

端侧数据串联的难点

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

  1. 在端侧数据采集过程中,不仅会采集业务链路数据,还会采集各种性能&稳定性监控数据,可观测数据源比较多;
  2. 如果用到其他的研发框架,如 OkHttp、Fresco 等,可能还会采集三方框架的关键数据用于网络请求,图片加载等问题的分析和定位。对于业务研发同学来说,我们往往不会过多的关注这类三方框架技术能力,涉及到这类框架问题的排查时,过程往往比较困难;
  3. 除此之外,端侧几乎完全异步调用,而且异步调用 API 比较多,如线程、协程等,链路打通也存在一定的挑战。

这里会有几个共性问题:

  • 三方框架的数据如何采集?如何串联?
  • 不同可观测数据源之间如何串联?
  • 分布在不同线程、协程之间的数据如何自动串联?

端侧数据自动串联方案

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

在 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 链路的起点。这种方式,不仅支持协程/线程内的数据自动关联,还支持多层级嵌套。

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

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

  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 对象就可以了。

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

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

如何确保性能

在可观测数据采集过程中,会有大量的数据产生,对内存、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+条数据的采集。

如何确保日志不丢失?

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

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

  1. 引入预写日志机制的目的是确保写入到 SDK 的数据,在发送到服务器之前,不会因为异常原因而丢失。这个过程的核心是,在数据成功发送到服务器之前,先把数据缓存在移动设备的磁盘上,数据发送成功之后,再移除磁盘上的缓存数据。如果因为 App 异常原因,或者设备重启导致数据发送失败,因为缓存的数据还在,SDK 会根据记录的断点信息对数据发送进度进行恢复。同时预写日志机制可以确保数据的写入和发送并发执行,不会互相阻塞;
  2. 在数据发送之前,还会对多条数据做聚合处理,并通过 lz4 算法进行压缩处理,这种做法可以降低数据发送时的请求次数和网络传输流量的消耗。如果数据发送失败,还会有重试策略,确保数据至少能成功发送一次;
  3. 在数据发送时,SDK 支持就近接入加速边缘节点,并通过边缘节点与 SLS 之间的内部网络加速通道传输数据。

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

多系统数据关联处理

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

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

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

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

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

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

多系统数据拓扑生成

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

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

  • 包含两个节点关系的聚合数据,我们把这种类型的数据,叫做边信息
  • 以及未匹配到的原始数据

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

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

  • 边信息,可以体现调用关系。
  • 依赖信息,可以体现服务依赖关系。
  • 还有指标信息,以及其他资源信息等。其中,业务属性相关的数据会体现在资源信息中。

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

自动化问题根因定位探索

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

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

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

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

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

案例:多端链路追踪

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

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

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

整体架构

接下来,我们来看下整套解决方案的架构:

  1. 最底层是数据源,遵循 OTel 协议,各个端对应的 SDK 按照协议规范统一实现;
  2. 数据存储层,是直接依托于 SLS LogHub,所有系统采集到的数据统一存储;
  3. 再往上是数据处理层,对关键指标、Trace 链路、依赖关系、拓扑结构、还有特征等进行了预处理。

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

后续规划

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

  1. 在采集层,会继续完善插件、注解等方式的支持,降低业务代码的侵入性,提升接入效率
  2. 在数据侧,会丰富可观测数据源,后续会支持网络质量、性能等相关数据的采集
  3. 在应用侧,会提供用户访问监测、性能分析等能力

最后,我们会把核心技术能力开源,共享社区。