1. 基于OTel的移动端全链路 Trace建设思考和实践 高玉龙（元泊） 阿里巴巴-阿里云高级开发工程师

2. 目录 01 1. 背景介绍 02 2. 解决思路 03 3. 方案介绍 04 4. 总结

3.

4. 背景介绍 研发人员 2个人 1000个人 代码行数 5000行 100万 架构规模 10个模块 100+模块 发布频率 一个月 修复时间 1个小时 产品成熟度 一周 5个小时 Ø 研发过程变化大 Ø 问题难以复现和排查

5. 为什么很难复现 01 多端日志不统一 统一数据采集标准 Android、iOS、微服务等多端日志协议 不统一，日志分析难 02 端侧数据采集难 平台、框架无关，统一采集能力 调用链路复杂、模块多，技术框架不同； 代码隔离，模块间状态传递频繁； 解决思路 设备碎片化，网络环境复杂 03 多系统数据关联难 不同框架、系统的数据获取难； 数据上下文自动关联 数据分析缺少上下文信息，数据关联难 04 确定问题难 模块、系统依赖多，复现问题难； 对应域的同学多人排查，人肉运维成本高 领域经验沉淀，自动化经验分析

6. 统一数据采集标准 业务现状 行业方案 解法 n 数据采集没有统一的规范 n 协议/数据类型不统一 Ø 各个端基于OTel协议统一实现 n 跨端/跨系统日志分析难 n 方案之间难以兼容/互通 Ø 基于OTel协议统一存储、处理、 分析 移动端 应用端 SDK 研发框架 Android iOS Middleware Serverless Container PAAS 统一采集 l l l l 跨语言规范 API / SDK Exporters Collectors 统一协议 SLS 存储、处理、分析

7. 端侧数据采集的难点 数据串联难 性能保障难 不丢数据难 l 框架多，模块多，业务差异大 l 40+ 系统版本 l App崩溃、OOM、非优雅退出 l 线程/协程，完全异步调用 l 10000+ 机型 l 全球 150 + 电信运营商 l 可观测数据源多 l 跨洋数据传输，链路质量波动，劫持

8. 端侧数据串联的难点 业务链路 网络质量 研发框架 性能 接口访问 更多数据 u 可观测数据来源多 u 研发框架技术能力对外黑盒 共性问题 可观测数据来源 1. 三方框架数据如何采集、串联？ method XXX 线程B 2. 不同可观测数据如何串联？ method YYY 3. 线程/协程如何自动串联？ 异步 method B 同步 method A async/ await method D 协程 线程C 线程A 同步/异步调用形式 u 端侧业务链路完全异步调用 u 异步调用方式多样化

9. 端侧数据自动串联方案 协程调度器 协程挂起 协程恢复 最终数据 根节点 trace协议 Android 更新上下文 子节点 线程栈 上下文 Parent Span + activeSpan + trace_id + span_id Scope + parent_id 上下文 Child Span + activeSpan + trace_id + span_id + parent_id iOS 1. 协程/线程内自动关联 activity_create 线程 1 activity_scope_enter 线程 n 2. 支持多层级嵌套 线程 m 协程 协程 协程 activity_scope_leave

10. 三方框架数据采集和串联 业内常见做法 效果 1. 拦截过滤器、Hook 2. 其他扩展方式或不支持 扩展库 Fresco Picasso 上下文管理 共性问题 OkHttp3 Ø 上下文自动关联 Ø 埋点完全生效 Ø 业务代码侵入性低 扩展库Api 示例：OkHttp3字节码插桩 1. 埋点不完全 2. 需要侵入业务代码 InsnList inject newCall(Lokhttp3/Request;)Lokhttp3/Call; VarInsn ClassReader FieldInsn MethodInsn ASM + Transform Api 方法名: ClassWriter 方法开始位置插入： LabelNode; VarInsnNode(ALOAD, 1); MethodInsnNode(); VarInsnNode(ASTORE, 1); 字节码插桩 .class Files .dex Files

11. 如何确保性能 内存上限管理 数据结构优化 动态内存管理 协议直接拼装 减少内存开辟 文件连续写 文件上限管 理 Ring File 发送成功 日志发送 pos cp log 减少内存复制 1. 内存受限，频繁GC，易OOM 2. 频繁协议化，系统占用高 3. 数据离线缓存 I/O 负载 4. 端碎片化，多端性能不一致 聚合写 断点保存 缓存清理 文件缓存管理 协议过程优化 性能影响因素 内存空间复用 内存管理 addLog 写入数据 动态字符串 核心收益 吞吐量提升2倍 CPU最高降低60% 内存最高降低50% C内核实现，多平台性能一致

12. 如何确保日志不丢失 应用生命周期不可控 网络延时高，抖动大 l 应用非优雅退出 l 运营商网络环境复杂，网络劫持问题 l 设备掉电，异常重启 l 偏远地区、跨洋数据传输，链路质量波动 WAL(预写日志) 数据落盘 写数据 异常重启 Sender 内存 缓存 缓存 管理 .data 数据 聚合 断点 恢复 断点 管理 .idx lz4压 缩 重试策略 边缘节点 就近接入 SLS 自建网络加速通道 发送 效果 断点更新 lz4 数据包体积下降2.1倍 QPS提升13倍 发送成功率99.3% 网络延时下降50%

13. 多系统数据关联处理 用户访问 崩溃、性能 接口访问 更多数据源 问题 1. 数据量大，多系统数据不好关联 2. 设备ID、App版本等不同维度如何进一步分析 解法 1. 多系统数据统一存储，上下文自动关联处理 2. 拓扑处理，指标预计算 数据源 用户访问 网络质量 span1 崩溃、性能 span2 业务数据 span3 父节点处理 节点规整 空 根节点 子节点Map 映射 父节点 子节点排序 parentId span4 OT 协议 非空 不存在 SLS 统一存储 虚拟节点处 理 节点生成

14. 多系统数据拓扑生成 挑战 解法 Trace数据规模往往比较大， 时效性要求高，怎么做？ 1. 流处理 join 耗时高，把流处理 问题转为批处理问题 2. 中间态最大化价值 数据源 Map阶段 A: span2 span3 span4 分钟级 traceID spanID parentID 相等 相等 A": traceID ... spanID parentID ... 转换 最终产物 Combine阶段 中间产物 确定边信息 span1 系统视角 链路视角 边信息 未匹配 traceID traceID spanID spanID parentID parentID 指标信息 resource 边信息 中间产物 指标信息 ... M 1 M 2 依赖信息 M n 资源信息 SLS 数据合并 计数统计 延时指标 数据合并 百分位 计数统计 延时指标 百分位

15. 自动化问题根因定位探索 业务 1 B C B E service service service service service name name name name name E F V m 聚类分析 根因定位 层次聚类 图算法 由底向上找5 个节点 聚类 latency latency latency latency latency status status status status status 异常Trace 异常Trace 异常Trace V n d b e f 异常Trace 异常Trace 异常Trace d b c 找到异常起始点 异常Trace 异常Trace 异常Trace a a c C D D F 业务 n 实时特征生成 A A e 异常 找典型 特征编码 Trace f 问题 思路 1. 业务模式多，数据量大，不确定性大 Ø 业务链路特征实时生成 2. 业务系统复杂多变，请求链路复杂多变 Ø 模式识别，业务自动聚类 3. 多人参与排查，人肉运维成本高 Ø 图算法，根因自动定位 根因 典型Trace service+name +latency+status d A B C D h E F d A B C G d D D H d D h E d A B C D 可能的根因 F h E F K H G H

16. 案例：多端链路追踪 业务耗时 多端串联 iOS 指标信息 微服务 Android 多层嵌套 拓扑节点

17. 整体架构方案 上层应用 链路分析 拓扑查询 指标查询 日志查询 根因定位 数据处理 指标预计算 Trace链路生成 依赖关系生成 拓扑结构 特征处理中心 统一存储 数据存储 Logging 数据源 SDK Tracing Metrics 用户点击 网络质量 性能 访问日志

18. 总结 04 03 02 01 l 完善插件、注解等方 式采集支持 l 更多三方框架的支持 丰富可观测数据源 l 网络质量采集 l 性能数据采集等 扩展端侧应用场景 l 用户访问监测 l 性能 Profiling 等 能力开源，贡献社区

19. 扫码回复「D2」 获取第十七届 D2 演讲 PDF 材料 后续也将推送 D2 会后技术文章，敬请关注！！

20. 感谢大家观看