淘宝客户端诊断体系升级实战

作者：伝逸

淘宝作为一个航母级的应用，每天都有数亿的用户在使用。保证客户端的稳定性是我们的首要目标。为此，我们也提出了5-15-60的目标。即问题告警时，5分钟响应，15分钟定位，60分钟恢复。但是现有的排查体系并不能很好的达到这个目标，分析下来主要原因是：

监控阶段

• 通过Crash堆栈、异常信息进行聚合统计，不够精细准确，不够灵敏；
• 监控到异常后，端侧行为比较单一，只上报异常信息，无法提供更多有用数据；
• 手淘大部分问题都和线上变更有关，但是缺少对变更质量的监控。

排查阶段

• 监控上报的异常信息不足，依赖日志进行问题排查；
• Crash或异常时不会主动上传日志，需要手动捞取， 用户不在线获取不到日志；
• 获取日志之后：

1. 缺少分类，缺乏标准，日志杂乱，看不懂其他模块的日志；
2. 缺少场景信息，无法完整的重现异常时用户的操作场景；
3. 缺少整个生命周期相关的事件信息，无法掌握app的运行情况；
4. 各个模块上下游的日志信息无法有效关联形成完整链路；
5. 现有日志可视化工具功能较弱，无法提高排查效率；

• 问题排查靠人工分析，效率低下，相同问题缺少沉淀；
• 各个系统间的数据缺少关联，需要到多个平台获取数据。

诊断体系升级思路

针对以上现有问题，我们重新设计了整个无线运维排查诊断体系的架构。在新的架构中，我们引入了场景的概念。以往端上发生的异常都是一个个独立的事件，没有办法针对不同的异常做更精细的处理和数据收集。而引入场景概念后，一个场景可能是一个异常和多种条件的组合，针对不同的场景可以做配置，使得异常信息的收集更加丰富，更加精准。

同时我们重新定义了端侧异常数据，主要包括标准的Log日志数据、记录调用链路的Trace全链路数据、运行时相关的Metric指标数据以及发生异常时的现场快照数据。平台侧可以利用异常数据进行监控和告警。也可以对这些数据进行可视化的解析，针对业务的差异，平台提供了插件化的能力来解析数据。利用这些语义化后的信息，平台可以进行初步的问题诊断。

所以接下来要实现的目标是：

• 实现端侧场景化的监控运维；
• 升级日志体系，实现LOG、TRACE、METRIC数据整合， 提供更加丰富和精准的排查信息；
• 完成高可用体系数据整合，提供面向问题排查的标准化接⼝和平台；
• 插件化支撑平台赋能，业务自定义诊断插件，完成诊断体系平台间对接；
• 平台依据诊断信息，给出诊断结果，能做到自动化、智能化；
• 依据诊断结果给出解决方案或提出整改需求，形成从需求->研发->发布->监控->排查->诊断->修复->需求的闭环。

日志体系升级

目前分析运行日志还是端侧排查问题的主要手段，前面也提到我们的日志本身存在一些问题。所以我们第一步是对日志体系进行了升级。（在此之前我们完善了日志自身的基础能力，比如提升写入性能、提升日志压缩率、提升上传成功率、建立日志的数据大盘等等）

为了提高日志的排查效率，我们从日志内容着手，重新制定了端侧的标准日志协议。标准化的日志协议可以为我们在平台侧进行日志可视化建设、自动化日志分析提供帮助。我们从Log、Trace、Metr