京东批发云mPaaS移动端日志回捞探求通常

1.1. 引言

移动操作系统为开发者提供了性能丰盛的日志组件，比如说Android Studio中的Logcat窗口会显示系统信息，例如在启动渣滓回收时显示的信息，以及经常使用Log类增加到运行的信息，能够辅佐开发者启动高效的开发上班。但是在消费环境中，当用户(或许老板)反应一些疑问，又比拟冷僻难以复现的时刻(不是Crash)，经常就会堕入大刀阔斧的境地。此时，借助线上意外数据实时上报，咱们只能是祈祷用户网络环境通顺，能够及时把意外数据第一时期上报过去，但是这种做法并不能保障咱们永远那么幸运。

于是，咱们须要研制一款性能较高的移动日志系统来处置咱们当下的难题，该系统能具有日志信息完整、性能损耗低、轻量级(体积)、准确回捞的特点。接上去引见一下移动日志系统的研发历程。

1.2. 设计打算

移动日志系统经常使用了Linux系统中提供的mmap作为日志文件的载体，目前业内盛行的XLOG日志组件、MMKV、美团Logan均驳回了此打算，其最大的好处就是高效I/O、低损耗、跨进程等好处，接上去引入下mmap的基本引见。

1.2.1. 什么是mmap?

操作系统分为内核态和用户态两种运转形式：

在Linux中可以经常使用mmap用来在进程虚构内存地址空间中调配地址空间，创立和物理内存的映射相关 ：

当经常使用mmap映射文件到进程后，就可以间接操作这段虚构地址启动文件的读写等操作，不用再调用read，write等系统调用。但需留意，间接对该段内存写时不会写入超越文件大小的内容。

总之，mmap区别于以往的文件读写，具有以下几个好处：

1.2.2. mmap的经常使用

关于移动端日志采集SDK来说，关键启动的上班就是将用户写入的数据保留到文件中，在这个环节中触及到在native层调用mmap函数实如今进程虚构内存地址空间中调配地址空间，创立和物理内存的映射相关。

接上去引见一下Linux系统中mmap机制的经常使用流程：

mmap函数

成功口头时，mmap()前往被映射区的指针。失败时，mmap()前往MAP_FAILED[其值为(void*)-1],error被设为以下的某个值：

mmap在移动端代码中的经常使用

//第一步:依据设置的缓存位置生成用于映射的文件//第三步：mmap映射文件到buffer内存中//将要写入的数据封装，紧缩和加密//将mmap的缓存写入到文件中//文件大小变动等相关操作

日志写入的流程

1.2.3. 移动日志系统架构引见

客户端日志SDK为开发者提供日志的打印，关键是将在线上运转时期发生的日志写入文件中，依据开发者的须要捞取指定的日志，为开发者处置线上疑问提供助力。咱们设计了满足基本色能的系统，架构如下图所示：

1.2.4. 客户端日志SDK引见

日志SDK的架构如图展现，可以分为如下三层，每一层处置了不同的业务场景。

日志SDK在底层经常使用了流式紧缩加密操作，在接纳到写入的日志数据，先将数据启动紧缩操作，而后再启动加密操作，整个环节中都是流式操作，防止了CPU峰值，缩小对CPU性能累赘。在详细的成功中引入了MMAP机制处置了日志失落疑问，经常使用AES启动日志加密确保日志安保性。

日志SDK经过服务端下发的战略启动本地日志的灵活上报，这里咱们可以经过定时的拉取最新的战略，或许经过push通道更新本地的战略，再或许提供上报接口，在用户的反应中，让用户将日志数据上报过去。在下发的战略中咱们启动了少量的自定义，对文件的大小，缓存时长，日志的写入等级等相关的设置启动下发操作，成功运行初始化后，挑选过滤，只将咱们须要的日志写入到文件中，为开发者经常使用。

日志SDK依据战略将指定的日志文件上行到指定的主机上，这个主机将对上行的日志启动解压和解码操作，将日志文件恢复成原始的输入数据，详细的流程可以参考上方的业务流程。

日志SDK业务流程

日志SDK在的业务流程如下图所示，依据服务端性能的战略，采集指定的日志并启动数据的紧缩加密等操作，而后被动将本地日志文件上行到中转服务，将上行结果等相关信息同步到信息展现的服务端。

日志SDK性能

上述设计中以及经常使用中，为了缩小对CPU以及内存的消耗，咱们经过经常使用mmap技术，将流式紧缩加密缓存等操作转移到native层，那么这样做相关于Java层的日志库咱们关于内存以及CPU的经常使用率降落了多少，接上去咱们将经常使用一个Java层的日志库与经常使用mmap成功的native库启动对比。

测试条件

性能测试中驳回了在同一台小米Note3 Android9系统版本手机，区分测试了已有的Java日志库、日志库、美团Logan、腾讯XLog日志库的写入性能。经过写入速度、GC频率、CPU占用率几个维度来权衡日志库的写入性能，测试的结果只限于权衡测试环境，并不代表Android平台全体平均水准。

测试数据量：

测试结果

1. 内存的GC测试结果

Java日志库:

native日志库:

从上边的内存性能图片中可以看到，Java日志库在少量写日志的时刻回形成频繁的GC，只管native日志库不会发生这样频繁的GC，从图中可以看到Java日志库的GC频率大概是1s/次，native日志库的GC频率大概是7.5s/次。

2. CPU经常使用率测试结果

Java日志库:

native日志库:

从上边CPU性能图片中可以看到，Java日志库在频繁写入日志的时刻CPU的平均经常使用率大概为13%，native日志库在频繁写入日志的时刻CPU的平均经常使用率大概为5%。

从上述内存以及CPU占用率的对比中，咱们可以看出native日志库相较于Java日志库来说，性能上有了很大的揭示，关于内存的占用较小，在频繁的I/O操作以及加密紧缩操作的状况下cpu的经常使用率仍坚持在较低值。

日志库性能的对比

上边咱们与Java日志启动了对比，接上去咱们将于其余经常使用mmap成功的日志库启动下对比：

1.3. 通常案例

在app的线上环境咱们或许遇到各种疑问，咱们宿愿将发生疑问今日的日志失掉到用于疑问的剖析，协助处置疑问。这样的业务场景简直笼罩了大局部的业务场景，关于自助收银机这样的设施经常使用场景，运转时期的日志关于疑问的排查尤为关键。

数科自助收银设施关键服务于各大超市卖场的自若结账，缓解多条人工收银通道仍无法对消的收银压力。当发生疑问的时刻，咱们无法能对经常使用者启动回访，所以运转时刻的日志关于疑问排查尤为关键。

在未经常使用移动日志系统之前，遇到疑问后，由于缺少运营工具，关于疑问的排查，须要占用较多的研发资源，在接入移动日志系统后，运营就可以独自处置大局部的疑问。这样极大的提高了处置疑问的效率，缩小了研发侧介入排查运营疑问的时期。

1.4. 写到最后

的sdk经常使用场景是定时拉取服务端的战略，依据下发的最新战略启动日志文件的上报，有必定的时期延后性，前期咱们将放开被动上报日志的通道以及联合push推送信息，提高日志回捞的及时性以及成功率。

的sdk临时只支持移动端(Android以及iOS)，在后续咱们将启动多端支持，将在RN，Flutter，小程序以及H5等各种运行场景中一致经常使用日志库启动日志的采集和存储。