共计 4824 个字符，预计需要花费 13 分钟才能阅读完成。
前言
Logan 是美团点评集团移动端基础日志组件，这个名称是 Log 和 An 的组合，代表个体日志服务。同时 Logan 也是“金刚狼”大叔的名号，当然我们更希望这个产品能像金刚狼大叔一样犀利。
Logan 已经稳定迭代了一年多的时间。目前美团点评绝大多数 App 已经接入并使用 Logan 进行日志收集、上传、分析。近日，我们决定开源 Logan 生态体系中的存储 SDK 部分（Android/iOS），希望能够帮助更多开发者合理的解决移动端日志存储收集的相关痛点，也欢迎更多社区的开发者和我们一起共建 Logan 生态。Github 的项目地址参见：https://github.com/Meituan-Di…。
背景
随着业务的不断扩张，移动端的日志也会不断增多。但业界对移动端日志并没有形成相对成体系的处理方式，在大多数情况下，还是针对不同的日志进行单一化的处理，然后结合这些日志处理的结果再来定位问题。然而，当用户达到一定量级之后，很多“疑难杂症”却无法通过之前的定位问题的方式来进行解决。移动端开发者最头疼的事情就是“为什么我使用和用户一模一样的手机，一模一样的系统版本，仿照用户的操作却复现不出 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。
