FDLog App 客户端日志系统

Question

背景

背景概述： App 端经常会遇到线上业务出问题的情况，想分析具体是哪块的问题，但是如果没有日志系统的支持，就很难定位客户 App 的实际情况，很难找到实际的原因，所以在这个背景下，我们必须要有一套，好用并且性能较好的系统来帮助我们。

简述

App 端日志实现的基本要素：

1. 安全
   • 当我们在代码里面写入一行一行的日志的时候，并不能明文存在我们的手机中，如果有拿到手机 ROOT 权限的人，有意搜索相关有用的信息时，就会发现日志信息并且明文，那么公司的一些业务信息就会暴露等，所以一定要保证安全。
2. 性能
   • App 属于前端的范畴，性能也是一个 App 能否留住用户的关键，当日志系统性能太差，经常会大比例的占用 CPU 等，影响到渲染的时候，就需要考虑这个日志的设计是否合理了。
3. 丢失率
   • 日志的丢失率也是我们需要考虑的，当正在执行日志记录的情景下，突然被用户杀掉是否影响之前记录的日志信息，最大程度上的降低丢失率。

日志的上报策略：

1. 轮询
   • 通过定时任务不断上传 App 日志，这样可以利用的数据就会很多，数据分析团队，会根据前端上报的日志快速报警，在用户没有主动联系我们的时候，我们就可以定位到问题，并且诊断修复它。
2. 引导用户
   • 如果觉得业务日志信息大批量上报，我们只想要出问题的日志进行排查，也可以在 App 内有一个地方是专门上报日志的触发按钮，当用户觉得 App 出现了问题，他会联系客服，在客服的引导下上报日志，开发查看问题。
3. 日志回捞
   • 用户将自己身份信息（例如 用户名/ID）告知客服，客服将关键信息给到开发小哥，开发小哥通过日志系统，日志回捞，将目标用户的本地日志上传到服务器进行诊断，其实相比于引导用户来上报，就是降低了用户的操作步骤。

详述

安全：

1. 日志使用 AES128 进行对称加密 PADDING 模式 PKCS7 CBC 模式 。
2. 对于 AES 对称加密的 Key 和 IV ，我们使用的是 RSA 非对称加密，保证对称密钥的安全。 本地打散 PriKey 到客户端， 服务器再下发 用 PublicKey 加密的 Key 和 IV ，这样保证客户端的相对安全。

性能：

1. 使用流式压缩，压缩类型 GZIP ，之所以使用流式压缩是为了避免 CPU 峰值，因为集中去压缩很占 CPU，这里的顺序是先压缩再加密，因为如果先加密压缩比例会降低很多。
2. 使用 MMAP 方式进行 MMAP 与磁盘的映射，这是为了避免每次写入日志都需要开启关闭文件流，占用资源。
3. 使用 C 编写核心日志库。 一 ,是为了统一多端， 二 ,C 的性能略高一些。

丢失率：

1. 制定日志格式，每一条日志，都会为一个日志单元，当其中有一个日志单元损坏，不完整，再下次写入的时候会自动修复这个日志单元（删除掉这个但单元），这样的好处是，即使一个单元的损坏了，也不影响整个日志文件的解析，当然坏处，就是压缩率变低了，因为待压缩的文本量少了。 但是相对于压缩率我们更需要的是低的丢失率，我们日志的主要职责就是帮助开发找到问题，所以丢失率一定要少。

日志的实现大致流程

下面是实现的大致流程

日志的整体流程： 用户写入 ---> 压缩 ---> 加密 ---> MMAP 映射到 缓存文件 ---> 当缓存文件大小满足写入日志文件 ---> 写入日志 ---> 生成 日志文件

缓存文件

缓存文件用于 MMAP 做内存映射，也就是操作内存，直接会写入缓存文件当中。

缓存文件的格式：

日志文件

日志文件也拥有日志文件的协议格式，日志文件从缓存文件中来，当缓存文件大小到达预设置的值时就会将日志信息存入日志文件。

需要上传到服务器的日志文件。

总结

整个日志是一个从前端到后端的一个完整系统，这个系统可以帮助我们很好的解决一些线上的实际问题，在这里要非常感谢美团 Logan 日志团队开源的源代码给予参考。 从前端 App 日志记录，压缩加密，到服务端的日志存储，日志上报策略，最后到数据团队的日志分析，整个的一条线贯穿了日志系统的整体架构。