EMAS远程日志 - 移动端问题排查利器

本文涉及的产品
移动研发平台 EMAS,开发者版免费套餐
简介: 远程日志是什么?具体做了哪些事情?内部是怎么实现的?本文将从 功能、架构、体验优化三个方面来介绍一下远程日志发展过程及展望。

阿里云 云原生应用研发平台EMAS 张月(此间)

前言

当 App 发布到用户手里之后,开发者对 App 运行状态的感知就只能通过各类业务和稳定性监控了。这些监控平台会把线上问题(如崩溃堆栈、异常网络请求等)及业务数据采集到服务端,然后给用户提供聚合 Metrics 等 BI 数据。但这个过程很容易丢失细节,不能直观反映问题发生原因,导致线上问题很难排查分析。

可能聪明的你会想,我把所有的日志都上报到后端不就行了?但是这样会给 App 带来很多无意义的网络消耗,也会造成比较大的网络和存储的压力。阿里云远程日志( https://www.aliyun.com/product/emascrash/tlog )在这个场景下应运而生,通过将日志存放 App 本地,需要时拉取的方式,在牺牲了一点实时性的情况下,解决了上报日志费流量存储,不上报日志没办法查问题的困境。

远程日志具体在里面做了哪些事情?内部又是怎么实现的?接下来我就会从 功能、架构、体验优化 三个方面来介绍一下远程日志发展过程,最后再聊聊我们的展望。

功能

如前言介绍的一样,我们会把日志先存在 App 本地,当需要的时候再拉取上来做分析查看。整个过程可以简单拆解成如下几步:
image.png

移动端特性

  • C层面实现:性能提升,一份代码多端支持
  • 加密存储:使用非对称加密方式,日志存储上报更安全
  • 日志轮转:最长支持7天日志存储,每天最大存储 10M
  • MMAP机制:避免缓存日志丢失,提升性能 (注:MMAP 机制是将文件直接映射成内存的操作,避免页缓存到文件的拷贝,详情可移步:https://www.cnblogs.com/huxiao-tee/p/4660352.html )

后端特性

远程日志的定位是异步拉取,把问题日志从移动设备端拉回来分析。结合不同使用场景,用户对设备精准度、拉取及时性、拉取成功率等不同侧重的特点,我们在拉取模式和产品联动上做了不同的实践。

拉取模式

精准拉取:指定设备列表

举个例子,一个风和日丽的上午,你刚到公司,发现老板满脸不爽的告诉你昨天晚上他 App 崩溃了。那摆在眼前就是两条路,要么搞定这个问题,要么“提桶跑路”。这个时候远程日志出场了,你可以熟练的输入老板的设备Id,做一次日志拉取,查查老板 App 的日志定位原因,解决问题。
image.png

这个模式下,用户使用面临了两个体验问题:

  • 拉取速度慢。下发拉取任务后,需要终端用户重新打开App才能完成日志上传,但这个时间很不可控。
  • 拉取成功率低。下发拉取任务会有部分设备inactive,导致没办法接受拉取指令,导致日志无法上传。

针对这个问题,我们在拉取上做了相关的优化,实现了智能筛选的功能。

智能筛选:指定筛选条件

用户不需要指定目标设备列表,而是关心某个或几个维度下的设备详细日志。那用户可以设定拉取的设备组合条件,系统自动帮用户选取设备。

为了加快设备拉取速度以及拉取成功率,远程日志在选取设备增加了如下策略:

  • 自动筛选最近启动的设备拉取。
  • 自动调整筛选出的设备池,扩大拉取规模,最多扩大到原始规模的8倍等。
    image.png

联动崩溃数据

在端上问题发生的场景中,大多数是因为崩溃或者异常行为。为了给与对这种场景支撑,我们提供了崩溃分析数据联动的支持,打破了「崩溃分析」 和「远程日志」两个产品之间的数据孤岛,提供了问题排查的更多的可能性。

数据联动:崩溃设备列表

通过崩溃分析提供崩溃设备列表,可以帮远程日志直接划定待拉取设备范围,用户更加省力,通过 EMAS 「崩溃分析」中的列表页一键跳转拉取。
image.png

这个方式极大简化了用户在排查崩溃相关问题时选定设备列表的工作,但对于每个崩溃问题还是需要创建拉取日志任务。这个拉取过程还是存在一个时间上的迟滞感,这不仅会打断工程师的排查思路,也会消磨排查问题的积极性。我们能否免除拉取动作,直接把崩溃问题对应的设备日志准备好呢?「智能拉取」就是为了解决这个场景的问题。

智能拉取:提前拉取

我们加深了前面的数据联动,对于首现和 Top 崩溃问题,每天7点定时创建任务,开发同学上班的时候基本上都已经拉取成功了,极大的提升了开发同学的问题排查效率。
image.png

架构

image.png

体验优化

除了在内功上打磨,产品的使用体验上我们也做了相当多的优化,也和大家分享一下。

  • 任务消息通知,让你能够第一时间感知日志上报
  • 整合任务详情与日志详情页面,查看任务日志更方便
  • 完善任务、设备、日志查询筛选
  • 任务时间线透出,感知任务生命周期
  • 顶部菜单栏变侧边栏,控制台与EMAS风格统一
  • 拉取任务持久化,容错性更好。
    image.png

image.png

到此,远程日志的现有的功能、架构和体验介绍就此结束了,接下来说说我们对未来的规划。

展望

增加上报形式

目前都是通过服务端下发任务,端上接受任务上报这种「被动上报」的模式,有一定的局限性,我们接下来希望对客户端在某些情况下「主动上报」日志,比如连续Crash,或者用户在App内反馈问题时上报做相应的支持。

丰富采集数据

现在我们的日志打印仅限于用户日志,还需要支持更多的无痕埋点,记录用户操作路径和网络IO等操作,让日志数据更丰富,能够通过日志复现用户操作流水,机器状态的变化。

更多产品联动

「崩溃分析」是我们产品联动的第一站,除了崩溃和异常,对品质有追求的App开发者也越发重视性能问题,毕竟「功能决定现在,性能决定未来」,后续我们也会思考和如何将「性能分析」产品和远程日志打通,更好的服务我们的用户。

移动研发平台 EMAS

阿里巴巴应用研发平台 EMAS 是国内领先的云原生应用研发平台(移动App、H5应用、小程序、Web应用等),基于广泛的云原生技术(Backend as a Service、Serverless、DevOps、低代码等),致力于为企业、开发者提供一站式的应用研发管理服务,涵盖开发、测试、运维、运营等应用全生命周期。
欢迎大家移步使用:https://cn.aliyun.com/product/emas

相关文章
|
7月前
|
开发工具 开发者
应用研发平台EMAS在接入崩溃分析、性能分析和远程日志的时候
【2月更文挑战第28天】应用研发平台EMAS在接入崩溃分析、性能分析和远程日志的时候
54 6
|
7月前
|
运维 监控 数据挖掘
应用研发平台EMAS产品常见问题之将阿里后台的日志落到我们后台失败如何解决
应用研发平台EMAS(Enterprise Mobile Application Service)是阿里云提供的一个全栈移动应用开发平台,集成了应用开发、测试、部署、监控和运营服务;本合集旨在总结EMAS产品在应用开发和运维过程中的常见问题及解决方案,助力开发者和企业高效解决技术难题,加速移动应用的上线和稳定运行。
|
Dubbo Java 应用服务中间件
项目中引进这玩意,排查日志又快又准
随着微服务盛行,很多公司都把系统按照业务边界拆成了很多微服务,在排错查日志的时候,因为业务链路贯穿着很多微服务节点,导致定位某个请求的日志以及上下游业务的日志会变得有些困难。
|
运维 监控 安全
应急实战 | 记一次日志缺失的挖矿排查
应急实战 | 记一次日志缺失的挖矿排查
197 0
|
2月前
|
Java Shell
「sh脚步模版自取」测试线排查的三个脚本:启动、停止、重启、日志保存
「sh脚步模版自取」测试线排查的三个脚本:启动、停止、重启、日志保存
40 1
|
2月前
|
Java 程序员 应用服务中间件
「测试线排查的一些经验-中篇」&& 调试日志实战
「测试线排查的一些经验-中篇」&& 调试日志实战
23 1
「测试线排查的一些经验-中篇」&& 调试日志实战
|
5月前
|
SQL Java Serverless
实时计算 Flink版操作报错合集之在写入SLS(Serverless Log Service)时出现报错,该如何排查
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
|
7月前
|
SQL Oracle 关系型数据库
oracle11g SAP测试机归档日志暴增排查(二)
oracle11g SAP测试机归档日志暴增排查(二)
332 1
|
7月前
|
Oracle 关系型数据库 Shell
oracle11g SAP测试机归档日志暴增排查(一)
oracle11g SAP测试机归档日志暴增排查(一)
81 1
|
3月前
|
Java
日志框架log4j打印异常堆栈信息携带traceId,方便接口异常排查
日常项目运行日志,异常栈打印是不带traceId,导致排查问题查找异常栈很麻烦。

相关产品

  • 移动研发平台