开发者学堂课程【基于EMAS应用开发实战： EMAS 远程日志-端上问题排查利器】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/770/detail/13487
EMAS 远程日志-端上问题排查利器
内容介绍：
一． 远程日志是什么
二． SDK 接入
三． 新建任务
四． 智能筛选任务
五． 崩溃分析联动
六． 智能拉取
七． 未来展望
一． 远程日志是什么
1. 远程日志
远程日志将端上日志以文件的形式存储在 App 的本地，通过控制台去创建相应的任务，App 接受到相应任务后上报日志，后在 web 控制台展现相应日志，提供搜索和一些报表能力，协助问题的排查。
2.支持平台
安卓和 iOS
3.解决什么问题
移动端设备一经发布，没办法获取到日志
4.适用场景
适合查看单台设备的日志流水来排查定位问题，提升我们 App 的质量。
5. 步骤拆解
客户端在日常运行的过程中，做相应的日志打印，远程 SDK 会将日志以加密文件的形式存储在本地，App 的开发者，可以在控制台创建现在的任务，选取设备去创建任务。端上，指定条件的设备，接受到相应的任务后，把这个日志上传到远程日志的控制台，控制台做相应的解析，在微博端提供给我们相应的日志展现和搜索以及相应的报表，排查问题时，步骤就是这样拆解的。
举例说明：电商，或者本地服务类的 app，经常会遇到支付失败。
常规办法：遇到这类问题我们常规的办法只能靠猜。是不是页面逻辑写错，是不是后端的问题，是不是登录状态过期，或者是网络错误，只能逐一的去排查。
远程日志提供了移动端问题排查的新思路和新方法。
二． SDK 接入
以 iOS 接入为例
① Pod 依赖。
② 做相应的这个 SDK 的集成：在我们的项目里面的去做头文件的依赖和相应的 SDK 初始化。
③ 在我们需要打印日志的地方写入我们打印日志的逻辑，整个接入就已经完成。
除了 Pod 接入，还支持这个 SDK 直接导入的接入。这个是以 iOS 接入为例，安卓接入同样简单。
SDK 接入以后，我们就可以在控制台创建相应的任务。
三．新建任务
1.远程日志控制台组成结构。
顶部是远程日志的 APP，在 EMS 平台创建的 App。左侧是任务列表，在任务列表里面，可以创建任务。
然后是设备日志，就你所创建任务以后选取那些设备，会以两个视角，任务视角和设备视角去查看日志。还有一些相关的拉取设置以及计费和帮助相关的一些帮助项。
任务列表里有任务的名称，拉取的模式，创建的时间和这个任务进度；同时你还可以去追加现在的设备或结束现在这个项目的任务，这是任务列表的页面。
我们也可以看到左上角有一个新建任务，这就是我们的目的。我们刚刚碰到的那个支付失败的问题，我们就可以通过新建任务来解决。
2.用户拉取的模式。
用户拉取模式，是我们去选取特定的这个 ID 做拉取，刚刚我们支付失败的问题，用户可能会通过反馈渠道来反馈，让我们知道用户的 ID，在拉取设备列表里面去做相应的这个筛选。
拉选设备里面我们展现设备 ID 和名称信息。名称其实就是可以去在端上绑定业务侧的名称，比如说给这个设备绑定一个用户昵称或者用户 ID。
同时还提供应用版本、系统版本、地域、品牌、机型的筛选，和在线时间的筛选。筛选这些问题设备，我们就可以创建相应的任务。任务创建成功之后，如何知道是否拉取成功，何时有日志，同时也提供相应的通知设置。
通知的设置的分为两个阶段。第一个阶段是有一台设备上报成功，这时候可以查看相应的日志，提供一个通知的开关。如果选取设备全部拉取成功，也会提供一个开关去做相应的通知，通知使用短信和邮件。选取了设备，添加了通知的配置，就可以去创建相应的任务，创建相应的任务以后，端上接受到任务后，会把相应的日志上传到后端做相应的分析。
拉取成功了，在任务详情里面，可通过任务列表进入任务详情去查看我们刚刚拉取的移动端设备的日志。
我们来到任务详情页面。
这个页面展现了我们主要的工作界面，告诉我们任务信息，设备的信息，以及我们拉取到的日志。任务拉取成功或者任务在过程中都可以进入页面去查看相应的志。
对这个界面能去逐一的介绍。
区域 1 是刚创建任务的时的任务相关的信息。
区域 2 是这个设备相关信息，比如说设备在这个任务里面的状态是怎么样的，是开始拉取了，还在上传，是已经拉取成功还是失败，我们都会把相应的状态归类并展示到这个区案里面。
刚刚支付失败那台设备，已经拉取成功了，我们就会在左侧区案里优先展示。
在区域 3 里可以做筛选。我们想看指定时间的日志，不同级别的日志，或者用特定的关键词做搜索，就可以在这里去做相应的筛选。对于想本地分析云端研发同学来说，我们还提供下载日志的这一个按钮，可以把日志下载下来，自己去做相应的分析。
在区域 4 提供了筛选条件选取以后或者默认的这个筛选条件，移动端 APP 日志链的走势，就是我们最重要的模块。
区域 5 是日志模块。我们把日志时间、级别、模块，和日志本身都展示出来了。可以看到我们刚刚的排查问题是支付失败，我们看到就明确告诉我们这次失败的原因，返回错误为 403，其实他就告诉了你，其实钱不够，这个问题我们就排查解决了。
像这种情况，可能我们在端上加一些逻辑提示，明确的提示他们。这样的话就可以避免一些用户反馈，解决这个端上的一些问题。
除了手动拉取以外，我们还支持选取不同的条件去拉取相应的日志。
我们先说设备问题，我们可以通过任务维度，也可以通过日志维度。刚刚我们筛选相应的设备进入到任务详里面也是可以的。
四．智能筛选任务
除了就刚刚说到的选取大概设备，我们还可以做智能筛选做拉取任务。
比如某一天某个应用版本，在某个地域发生的问题，这覆盖面是比较广的，前面我们手动拉取，可能会有两个问题：选取的那些设备很有可能长时间没上线，导致任务失败，即使任务失败，可能也会隔一段时间再上线上传这个日志，这样的话就会等待很长的时间，这个体验感不是很好。
我们刚刚那种场景，在某个应用版本的，某个地域里面经常会出现支付失败，在智能筛选里面也可以直接去选取相应的条件，然后再去填写一个拉取的设备链。设备链和条件就可以创建新的任务，我们会在后台帮你筛选最快上线的那些设备，把这个日志尽快的拉取到远程日志控制台，提供更好的体验。这就是我们智能筛选任的形式。
同时如果我们筛选的的设备没有很快的上线的话，我们还会去做相应的设备扩容。比如说填的是 3，比如过一段时间就有两个设备上来，那我把三个设备，三个备选设备是扩成 6 个,就有更多的设备命中条件，6-2 的这 4 台设备里面有一个上报了，那我们就把相应的项目任务结束了，因为有三台已经上报了。我们可能有几倍的备选的设备值，当达到选取的设备链以后，我们就把任务结束掉，其实就达到要求，我们就会这个任务视为成功。
能够更快的完成设备拉取，更方便去排查问题。
五．崩溃分析联动
一般的这个情况下，我们反馈渠道除了用户反馈以外，还有一个问题就是用户崩溃了，可能没有反馈，继续打开用。那这样的情况和我们 EMS 另一个产品崩溃分析去做了相关的联动。
崩溃分析中，崩溃，卡顿异常的列表里面，我们做了一些更便捷的操作，我们在一个崩溃分析列表里面可以拉取相应日志。
崩溃，可能涉及了几百台设备，会把这一个设备传入到远程日志里面，在这个远程日志里面，选取相应的设备链去做拉取，我们就把这个崩溃分析跟远程日志做了打通，在崩溃分析去感知问题，通过远程日志拉取就可以定位问题，可以解决问题。这样就更方便感知问题和定位问题。
六．智能拉取
崩溃分析还有一个问题，就是当发生崩溃以后，感知到崩溃以后，再去拉取。从拉取到拉取成功，还是会有一个时间。拉取后这个时间就只能等待，可能几个小时，也可能会失败，其实还是会打断问题的排查思路。
智能拉取就是为了解决这样的问题。所以你在远程控制台排查问题的时候，日志就已经在那，我们就提供一个智能拉取的功能。
就是在前面崩溃分析跟远程控制数据联动的情况下，做了更加深的一步：我们次日七点前，会对前一天的 top 10 的问题，或者是第一次出现的问做自动的拉取，自动拉取后会自动去创建任务。自动7点创建任务，那可能 8.9 点上班的时候，这些日志就已经在那，极大的便捷了排查问题的路径，就不需要再去拉取日志。
上线以后通过分析，直接可以去查看日志，这样就能够更快地去定位、解决问题。
七．未来展望
1.增加上报形式
我们现在只提供在某些条件下去创建任务，端上接收到到任务再去上报。这种情况下做上报其实有局限性，在某些情况下我们希望提供有主动上报功能。比如说端上自主决策什么时候上报。比如移动端开发者可能写相应的逻辑，捕捉到连续的 crash 就会把日志主动上报，因为这些问题比较严重。或者说，用户在 App 内反馈问题，通过反馈这个按钮，点击反馈的时候我们就把相应日志上传，排查问题的时候日志就直接在那里。
2.丰富采集数据
我们现在的数据并不丰富，我们现在的这个数据只支持用户自己的埋点，还需要更多的无痕埋点，解放用户。更完善的做一些监控，去打印日志。远程 SDK 可以帮助用户记录 App 的操作路径，比如点击某个按钮打开某个页面、APP 的内存报警、或者一些网络安慰的操作，都会给用户无痕的记录下来，丰富日志数据数据，更能够通过这个过程去完整的复现用户的操作流水，机器状态的变化，更精确的定位问题。
3.更多产品联动
我们还想做更多的产品联动，重视性能问题，功能决定现在，性能决定未来。后续我们会思考如何把性能日志和远程日志打通，更好地服务移动端的开发者。
