前言

Logan是美团点评集团移动端基础日志组件，这个名称是Log和An的组合，代表个体日志服务。同时Logan也是“金刚狼”大叔的名号，当然我们更希望这个产品能像金刚狼大叔一样犀利。

Logan已经稳定迭代了一年多的时间。目前美团点评绝大多数App已经接入并使用Logan进行日志收集、上传、分析。近日，我们决定开源Logan生态体系中的存储SDK部分（Android/iOS），希望能够帮助更多开发者合理的解决移动端日志存储收集的相关痛点，也欢迎更多社区的开发者和我们一起共建Logan生态。Github的项目地址参见：

https://github.com/Meituan-Dianping/Logan

背景

随着业务的不断扩张，移动端的日志也会不断增多。但业界对移动端日志并没有形成相对成体系的处理方式，在大多数情况下，还是针对不同的日志进行单一化的处理，然后结合这些日志处理的结果再来定位问题。然而，当用户达到一定量级之后，很多“疑难杂症”却无法通过之前的定位问题的方式来进行解决。移动端开发者最头疼的事情就是“为什么我使用和用户一模一样的手机，一模一样的系统版本，仿照用户的操作却复现不出Bug”。特别是对于Android开发者来说，手机型号、系统版本、网络环境等都非常复杂，即使拿到了一模一样的手机也复现不出Bug，这并不奇怪，当然很多时候并不能完全拿到真正完全一模一样的手机。相信很多同学见到下面这一幕都似曾相识：

用(lao)户(ban)：我发现我们App的XX页面打不开了，UI展示不出来，你来跟进一下这个问题。

你：好的。

于是，我们检查了用户反馈的机型和系统版本，然后找了一台同型号同版本的手机，试着复现却发现一切正常。我们又给用户打个电话，问问他到底是怎么操作的，再问问网络环境，继续尝试复现依旧未果。最后，我们查了一下Crash日志，网络日志，再看看埋点日志（发现还没报上来）。

你内心OS：奇怪了，也没产生Crash，网络也是通的，但是为什么UI展示不出来呢？

几个小时后……

用(lao)户(ban)：这问题有结果了吗？

你：我用了各种办法复现不出来……暂时查不到是什么原因导致的这个问题。

用(lao)户(ban)：那怪我咯？

你：……

如果把一次Bug的产生看作是一次“凶案现场”，开发者就是破案的“侦探”。案发之后，侦探需要通过各种手段搜集线索，推理出犯案过程。这就好比开发者需要通过查询各种日志，分析这段时间App在用户手机里都经历了什么。一般来说，传统的日志搜集方法存在以下缺陷：

• 日志上报不及时。由于日志上报需要网络请求，对于移动App来说频繁网络请求会比较耗电，所以日志SDK一般会积累到一定程度或者一定时间后再上报一次。
• 上报的信息有限。由于日志上报网络请求的频次相对较高，为了节省用户流量，日志通常不会太大。尤其是网络日志等这种实时性较高的日志。
• 日志孤岛。不同类型的日志上报到不同的日志系统中，相对孤立。
• 日志不全。日志种类越来越多，有些日志SDK会对上报日志进行采样。

面临挑战

美团点评集团内部，移动端日志种类已经超过20种，而且随着业务的不断扩张，这一数字还在持续增加。特别是上文中提到的三个缺陷，也会被无限地进行放大。

查问题是个苦力活，不一定所有的日志都上报在一个系统里，对于开发者来说，可能需要在多个系统中查看不同种类的日志，这大大增加了开发者定位问题的成本。如果我们每天上班都看着疑难Bug挂着无法解决，确实会很难受。这就像一个侦探遇到了疑难的案件，当他用尽各种手段收集线索，依然一无所获，那种心情可想而知。我们收集日志复现用户Bug的思路和侦探破案的思路非常相似，通过搜集的线索尽可能拼凑出相对完整的犯案场景。如果按照这个思路想下去，目前我们并没有什么更好的方法来处理这些问题。

不过，虽然侦探破案和开发者查日志解决问题的思路很像，但实质并不一样。我们处理的是Bug，不是真实的案件。换句话说，因为我们的“死者”是可见的，那么就可以从它身上获取更多信息，甚至和它进行一次“灵魂的交流”。换个思路想，以往的操作都是通过各种各样的日志拼凑出用户出现Bug的场景，那可不可以先获取到用户在发生Bug的这段时间产生的所有日志（不采样，内容更详细），然后聚合这些日志分析出（筛除无关项）用户出现Bug的场景呢？

个案分析

新的思路重心从“日志”变为“用户”，我们称之为“个案分析”。简单来说，传统的思路是通过搜集散落在各系统的日志，然后拼凑出问题出现的场景，而新的思路是从用户产生的所有日志中聚合分析，寻找出现问题的场景。为此，我们进行了技术层面的尝试，而新的方案需要在功能上满足以下条件：

• 支持多种日志收集，统一底层日志协议，抹平日志种类带来的差异。
• 日志本地记录，在需要时上报，尽可能保证日志不丢失。
• 日志内容要尽可能详细，不采样。
• 日志类型可扩展，可由上层自定义。

我们还需要在技术上满足以下条件：

• 轻量级，包体尽量小
• API易用
• 没有侵入性
• 高性能

横空出世

在这种背景下，Logan横空出世，其核心体系由四大模块构成：

• 日志输入
• 日志存储
• 后端系统
• 前端系统

最佳实践

日志输入

常见的日志类型有：代码级日志、网络日志、用户行为日志、崩溃日志、H5日志等。这些都是Logan的输入层，在不影响原日志体系功能的情况下，可将内容往Logan中存储一份。Logan的优势在于：日志内容可以更加丰富，写入时可以携带更多信息，也没有日志采样，只会等待合适的时机进行统一上报，能够节省用户的流量和电量。

以网络日志为例，正常情况下网络日志只记录端到端延时、发包大小、回包大小字段等等，同时存在采样。而在Logan中网络日志不会被采样，除了上述内容还可以记录请求Headers、回包Headers、原始Url等信息。

日志存储

Logan存储SDK是这个开源项目的重点，它解决了业界内大多数移动端日志库存在的几个缺陷：

• 卡顿，影响性能
• 日志丢失
• 安全性
• 日志分散

Logan自研的日志协议解决了日志本地聚合存储的问题，采用“先压缩再加密”的顺序，使用流式的加密和压缩，避免了CPU峰值，同时减少了CPU使用。跨平台C库提供了日志协议数据的格式化处理，针对大日志的分片处理，引入了MMAP机制解决了日志丢失问题，使用AES进行日志加密确保日志安全性。Logan核心逻辑都在C层完成，提供了跨平台支持的能力，在解决痛点问题的同时，也大大提升了性能。

为了节约用户手机空间大小，日志文件只保留最近7天的日志，过期会自动删除。在Android设备上Logan将日志保存在沙盒中，保证了日志文件的安全性。

详情请参考：美团点评移动端基础日志库——Logan

后端系统

后端是接收和处理数据中心，相当于Logan的大脑。主要有四个功能：

• 接收日志
• 日志解析归档
• 日志分析
• 数据平台

接收日志

客户端有两种日志上报的形式：主动上报和回捞上报。主动上报可以通过客服引导用户上报，也可以进行预埋，在特定行为发生时进行上报（例如用户投诉）。回捞上报是由后端向客户端发起回捞指令，这里不再赘述。所有日志上报都由Logan后端进行接收。

日志解析归档

客户端上报的日志经过加密和压缩处理，后端需要对数据解密、解压还原，继而对数据结构化归档存储。

日志分析

不同类型日志由不同的字段组合而成，携带着各自特有信息。网络日志有请求接口名称、端到端延时、发包大小、请求Headers等信息，用户行为日志有打开页面、点击事件等信息。对所有的各类型日志进行分析，把得到的信息串连起来，最终汇集形成一个完整的个人日志。

数据平台

数据平台是前端系统及第三方平台的数据来源，因为个人日志属于机密数据，所以数据获取有着严格的权限审核流程。同时数据平台会收集过往的Case，抽取其问题特征记录解决方案，为新Case提供建议。

前端系统

一个优秀的前端分析系统可以快速定位问题，提高效率。研发人员通过Logan前端系统搜索日志，进入日志详情页查看具体内容，从而定位问题，解决问题。

目前集团内部的Logan前端日志详情页已经具备以下功能：

• 日志可视化。所有的日志都经过结构化处理后，按照时间顺序展示。
• 时间轴。数据可视化，利用图形方式进行语义分析。
• 日志搜索。快速定位到相关日志内容。
• 日志筛选。支持多类型日志，可选择需要分析的日志。
• 日志分享。分享单条日志后，点开分享链接自动定位到分享的日志位置。

Logan对日志进行数据可视化时，尝试利用图形方式进行语义分析简称为时间轴。

每行代表着一种日志类型。同一日志类型有着多种图形、颜色，他们标识着不同的语义。

例如时间轴中对代码级日志进行了日志类别的区分：

利用颜色差异，可以轻松区分出错误的日志，点击红点即可直接跳转至错误日志详情。

个案分析流程

• 用户遇到问题联系客服反馈问题。

• 客服收到用户反馈。记录Case，整理问题，同时引导用户上报Logan日志。

• 研发同学收到Case，查找Logan日志，利用Logan系统完成日志筛选、时间定位、时间轴等功能，分析日志，进而还原Case“现场”。

• 最后，结合代码定位问题，修复问题，解决Case。

定位问题

结合用户信息，通过Logan前端系统查找用户的日志。打开日志详情，首先使用时间定位功能，快速跳转到出问题时的日志，结合该日志上下文，可得到当时App运行情况，大致推断问题发生的原因。接着利用日志筛选功能，查找关键Log对可能出问题的地方逐一进行排查。最后结合代码，定位问题。

当然，在实际上排查中问题比这复杂多，我们要反复查看日志、查看代码。这时还可能要借助一下Logan高级功能，如时间轴，通过时间轴可快速找出现异常的日志，点击时间轴上的图标可跳转到日志详情。通过网络日志中的Trace信息，还可以查看该请求在后台服务详细的响应栈情况和后台响应值。

未来规划

• 机器学习分析。首先收集过往的Case及解决方案，提取分析Case特征，将Case结构化后入库，然后通过机器学习快速分析上报的日志，指出日志中可能存在的问题，并给出解决方案建议；
• 数据开放平台。业务方可以通过数据开放平台获取数据，再结合自身业务的特性研发出适合自己业务的工具、产品。

平台支持

Platform	iOS	Android	Web	Mini Programs
Support	√	√	√	√

目前Logan SDK已经支持以上四个平台，本次开源iOS和Android平台，其他平台未来将会陆续进行开源，敬请期待。

测试覆盖率

由于Travis、Circle对Android NDK环境支持不够友好，Logan为了兼容较低版本的Android设备，目前对NDK的版本要求是16.1.4479499，所以我们并没有在Github仓库中配置CI。开发者可以本地运行测试用例，测试覆盖率可达到80%或者更高。

开源计划

在集团内部已经形成了以Logan为中心的个案分析生态系统。本次开源的内容有iOS、Android客户端模块、数据解析简易版，小程序版本、Web版本已经在开源的路上，后台系统，前端系统也在我们开源计划之中。

未来我们会提供基于Logan大数据的数据平台，包含机器学习、疑难日志解决方案、大数据特征分析等高级功能。

最后，我们希望提供更加完整的一体化个案分析生态系统，也欢迎大家给我们提出建议，共建社区。

Module	Open Source	Processing	Planning
iOS	√
Android	√
Web		√
Mini Programs		√
Back End			√
Front End			√

团队介绍

周辉，项目发起人，美团点评资深移动架构师。

姜腾，项目核心开发者。

立成，项目核心开发者。

白帆，项目核心开发者。

招聘

点评平台移动研发中心，Base上海，为美团点评集团大多数移动端提供底层基础设施服务，包含网络通信、移动监控、推送触达、动态化引擎、移动研发工具等。同时团队还承载流量分发、UGC、内容生态、整合中心等业务研发，长年虚位以待有志于专注移动端研发的各路英雄。欢迎投递简历：hui.zhou#dianping.com。