阿里巴巴应用研发平台EMAS官方账号
分类： 项目管理
2020-12-16 19:30:43
当 App 发布到用户手里之后，开发者对 App 运行状态的感知就只能通过各类业务和稳定性监控了。这些监控平台会把线上问题（如崩溃堆栈、异常网络请求等）及业务数据采集到服务端，然后给用户提供聚合 Metrics 等 BI 数据。但这个过程很容易丢失细节，不能直观反映问题发生原因，导致线上问题很难排查分析。
可能聪明的你会想，我把所有的日志都上报到后端不就行了？但是这样会给 App 带来很多无意义的网络消耗，也会造成比较大的网络和存储的压力。阿里云远程日志（ ）在这个场景下应运而生，通过将日志存放 App 本地，需要时拉取的方式，在牺牲了一点实时性的情况下，解决了上报日志费流量存储，不上报日志没办法查问题的困境。
远程日志具体在里面做了哪些事情？内部又是怎么实现的？接下来我就会从 功能、架构、体验优化 三个方面来介绍一下远程日志发展过程，最后再聊聊我们的展望。
如前言介绍的一样，我们会把日志先存在 App 本地，当需要的时候再拉取上来做分析查看。整个过程可以简单拆解成如下几步：
远程日志的定位是异步拉取，把问题日志从移动设备端拉回来分析。结合不同使用场景，用户对设备精准度、拉取及时性、拉取成功率等不同侧重的特点，我们在拉取模式和产品联动上做了不同的实践。
举个例子，一个风和日丽的上午，你刚到公司，发现老板满脸不爽的告诉你昨天晚上他 App 崩溃了。那摆在眼前就是两条路，要么搞定这个问题，要么“提桶跑路”。这个时候远程日志出场了，你可以熟练的输入老板的设备Id，做一次日志拉取，查查老板 App 的日志定位原因，解决问题。
这个模式下，用户使用面临了两个体验问题：
针对这个问题，我们在拉取上做了相关的优化，实现了智能筛选的功能。
用户不需要指定目标设备列表，而是关心某个或几个维度下的设备详细日志。那用户可以设定拉取的设备组合条件，系统自动帮用户选取设备。
为了加快设备拉取速度以及拉取成功率，远程日志在选取设备增加了如下策略：
在端上问题发生的场景中，大多数是因为崩溃或者异常行为。为了给与对这种场景支撑，我们提供了崩溃分析数据联动的支持，打破了「崩溃分析」 和「远程日志」两个产品之间的数据孤岛，提供了问题排查的更多的可能性。
通过崩溃分析提供崩溃设备列表，可以帮远程日志直接划定待拉取设备范围，用户更加省力，通过 EMAS 「崩溃分析」中的列表页一键跳转拉取。
这个方式极大简化了用户在排查崩溃相关问题时选定设备列表的工作，但对于每个崩溃问题还是需要创建拉取日志任务。这个拉取过程还是存在一个时间上的迟滞感，这不仅会打断工程师的排查思路，也会消磨排查问题的积极性。我们能否免除拉取动作，直接把崩溃问题对应的设备日志准备好呢？「智能拉取」就是为了解决这个场景的问题。
我们加深了前面的数据联动，对于首现和 Top 崩溃问题，每天7点定时创建任务，开发同学上班的时候基本上都已经拉取成功了，极大的提升了开发同学的问题排查效率。
除了在内功上打磨，产品的使用体验上我们也做了相当多的优化，也和大家分享一下。
到此，远程日志的现有的功能、架构和体验介绍就此结束了，接下来说说我们对未来的规划。
目前都是通过服务端下发任务，端上接受任务上报这种「被动上报」的模式，有一定的局限性，我们接下来希望对客户端在某些情况下「主动上报」日志，比如连续Crash，或者用户在App内反馈问题时上报做相应的支持。
现在我们的日志打印仅限于用户日志，还需要支持更多的无痕埋点，记录用户操作路径和网络IO等操作，让日志数据更丰富，能够通过日志复现用户操作流水，机器状态的变化。
「崩溃分析」是我们产品联动的第一站，除了崩溃和异常，对品质有追求的App开发者也越发重视性能问题，毕竟「功能决定现在，性能决定未来」，后续我们也会思考和如何将「性能分析」产品和远程日志打通，更好的服务我们的用户。
阿里巴巴应用研发平台 EMAS 是国内领先的云原生应用研发平台（移动App、H5应用、小程序、Web应用等），基于广泛的云原生技术（Backend as a Service、Serverless、DevOps、低代码等），致力于为企业、开发者提供一站式的应用研发管理服务，涵盖开发、测试、运维、运营等应用全生命周期。
欢迎大家移步使用：
