作者:伝逸
淘宝作为一个航母级的应用,每天都有数亿的用户在使用。保证客户端的稳定性是我们的首要目标。为此,我们也提出了5-15-60的目标。即问题告警时,5分钟响应,15分钟定位,60分钟恢复。但是现有的排查体系并不能很好的达到这个目标,分析下来主要原因是:
监控阶段
- 通过Crash堆栈、异常信息进行聚合统计,不够精细准确,不够灵敏;
- 监控到异常后,端侧行为比较单一,只上报异常信息,无法提供更多有用数据;
- 手淘大部分问题都和线上变更有关,但是缺少对变更质量的监控。
排查阶段
- 监控上报的异常信息不足,依赖日志进行问题排查;
- Crash或异常时不会主动上传日志,需要手动捞取, 用户不在线获取不到日志;
- 获取日志之后:
- 缺少分类,缺乏标准,日志杂乱,看不懂其他模块的日志;
- 缺少场景信息,无法完整的重现异常时用户的操作场景;
- 缺少整个生命周期相关的事件信息,无法掌握app的运行情况;
- 各个模块上下游的日志信息无法有效关联形成完整链路;
- 现有日志可视化工具功能较弱,无法提高排查效率;
- 问题排查靠人工分析,效率低下,相同问题缺少沉淀;
- 各个系统间的数据缺少关联,需要到多个平台获取数据。
诊断体系升级思路
针对以上现有问题,我们重新设计了整个无线运维排查诊断体系的架构。在新的架构中,我们引入了场景的概念。以往端上发生的异常都是一个个独立的事件,没有办法针对不同的异常做更精细的处理和数据收集。而引入场景概念后,一个场景可能是一个异常和多种条件的组合,针对不同的场景可以做配置,使得异常信息的收集更加丰富,更加精准。
同时我们重新定义了端侧异常数据,主要包括标准的Log日志数据、记录调用链路的Trace全链路数据、运行时相关的Metric指标数据以及发生异常时的现场快照数据。平台侧可以利用异常数据进行监控和告警。也可以对这些数据进行可视化的解析,针对业务的差异,平台提供了插件化的能力来解析数据。利用这些语义化后的信息,平台可以进行初步的问题诊断。
所以接下来要实现的目标是:
- 实现端侧场景化的监控运维;
- 升级日志体系,实现LOG、TRACE、METRIC数据整合, 提供更加丰富和精准的排查信息;
- 完成高可用体系数据整合,提供面向问题排查的标准化接⼝和平台;
- 插件化支撑平台赋能,业务自定义诊断插件,完成诊断体系平台间对接;
- 平台依据诊断信息,给出诊断结果,能做到自动化、智能化;
- 依据诊断结果给出解决方案或提出整改需求,形成从需求->研发->发布->监控->排查->诊断->修复->需求的闭环。
日志体系升级
目前分析运行日志还是端侧排查问题的主要手段,前面也提到我们的日志本身存在一些问题。所以我们第一步是对日志体系进行了升级。(在此之前我们完善了日志自身的基础能力,比如提升写入性能、提升日志压缩率、提升上传成功率、建立日志的数据大盘等等)
为了提高日志的排查效率,我们从日志内容着手,重新制定了