FDLog App客户端日志系统

背景

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

简述

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

  1. 安全

    • 当我们在代码里面写入一行一行的日志的时候,并不能明文存在我们的手机中,如果有拿到手机 ROOT 权限的人,有意搜索相关有用的信息时,就会发现日志信息并且明文,那么公司的一些业务信息就会暴露等,所以一定要保证安全。

  2. 性能

    • App 属于前端的范畴,性能也是一个 App 能否留住用户的关键,当日志系统性能太差,经常会大比例的占用 CPU 等,影响到渲染的时候,就需要考虑这个日志的设计是否合理了。

  3. 丢失率

    • 日志的丢失率也是我们需要考虑的,当正在执行日志记录的情景下,突然被用户杀掉是否影响之前记录的日志信息,最大程度上的降低丢失率。

日志的上报策略:

  1. 轮询

    • 通过定时任务不断上传 App 日志,这样可以利用的数据就会很多,数据分析团队,会根据前端上报的日志快速报警,在用户没有主动联系我们的时候,我们就可以定位到问题,并且诊断修复它。

  2. 引导用户

    • 如果觉得业务日志信息大批量上报,我们只想要出问题的日志进行排查,也可以在 App 内有一个地方是专门上报日志的触发按钮,当用户觉得 App 出现了问题,他会联系客服,在客服的引导下上报日志,开发查看问题。

  3. 日志回捞

    • 用户将自己身份信息(例如 用户名/ID)告知客服,客服将关键信息给到开发小哥,开发小哥通过日志系统,日志回捞,将目标用户的本地日志上传到服务器进行诊断,其实相比于引导用户来上报,就是降低了用户的操作步骤。

详述

安全:

  1. 日志使用 AES128 进行对称加密 PADDING 模式 PKCS7 CBC模式

  2. 对于 AES 对称加密的 KeyIV,我们使用的是 RSA 非对称加密,保证对称密钥的安全。 本地打散 PriKey 到客户端, 服务器再下发 用 PublicKey 加密的 KeyIV,这样保证客户端的相对安全。

性能:

  1. 使用流式压缩,压缩类型 GZIP ,之所以使用流式压缩是为了避免 CPU 峰值,因为集中去压缩很占 CPU,这里的顺序是先压缩再加密,因为如果先加密压缩比例会降低很多。

  2. 使用 MMAP 方式进行 MMAP 与磁盘的映射,这是为了避免每次写入日志都需要开启关闭文件流,占用资源。

  3. 使用 C 编写核心日志库。 ,是为了统一多端,,C 的性能略高一些。

丢失率:

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

日志的实现大致流程

下面是实现的大致流程

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

缓存文件

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

  2. 缓存文件的格式:

日志文件

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

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

总结

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

最后更新于