京东零售云mPaaS移动端日志回捞探索实践

2021-08-23

1.1. 引言

移动操作系统为开发者提供了功能丰富的日志组件，比如说Android Studio 中的Logcat窗口会显示系统消息，例如在进行垃圾回收时显示的消息，以及使用Log类添加到应用的消息，能够辅助开发者进行高效的开发工作。然而在生产环境中，当用户（或者老板）反馈一些问题，又比较冷僻难以复现的时候（不是Crash），常常就会陷入一筹莫展的境地。此时，借助线上异常数据实时上报，我们只能是祈祷用户网络环境通畅，能够及时把异常数据第一时间上报上来，然而这种做法并不能保证我们永远那么幸运。
于是，我们需要研制一款性能较高的移动日志系统来解决我们当下的难题，该系统能具备日志信息完整、性能损耗低、轻量级（体积）、精确回捞的特点。接下来介绍一下移动日志系统的研发历程。

1.2. 设计方案

移动日志系统使用了Linux系统中提供的mmap作为日志文件的载体，目前业内流行的XLOG日志组件、MMKV、美团Logan均采用了此方案，其最大的优势就是高效I/O、低损耗、跨进程等优势，接下来引入下mmap的基本介绍。

1.2.1. 什么是mmap？
操作系统分为内核态和用户态两种运行模式：
内核态（Kernel MODE）能够运行操作系统程序用户态（User MODE）能够运行用户程序
用户态（即应用程序）是不能直接对物理设备进行操作的（Ps:对物理设备进行操作，即对设备的物理地址写数据）。如果想读取硬盘上的某一段数据通常都需要经过硬盘->内核->用户，即数据需要经历两次拷贝，效率十分低下。为了解决这样的问题，内存映射的概念出现了：内核映射即mmap,mmap将设备的物理地址映射到进程的虚拟地址，则用户操作虚拟内存时就相当于对物理设备进行操作了，减少了内核到用户的一次数据拷贝，从而提高数据的吞吐率。
在LINUX中可以使用mmap用来在进程虚拟内存地址空间中分配地址空间，创建和物理内存的映射关系：

当使用mmap映射文件到进程后，就可以直接操作这段虚拟地址进行文件的读写等操作，不必再调用read，write等系统调用。但需注意，直接对该段内存写时不会写入超过当前文件大小的内容。
总之，mmap区别于以往的文件读写，具备以下几个优点：
• 减少了数据的拷贝次数，用内存读写取代I/O读写，提高了文件读取效率
• 实现了用户空间和内核空间的高效交互方式。两空间的各自修改操作可以直接反映在映射的区域内，从而被对方空间及时捕捉
• 提供进程间共享内存及相互通信的方式。不管是父子进程还是无亲缘关系的进程，都可以将自身用户空间映射到同一个文件或匿名映射到同一片区域。从而通过各自对映射区域的改动，达到进程间通信和进程间共享的目的
• 同时，如果进程A和进程B都映射了区域C，当A第一次读取C时通过缺页从磁盘复制文件页到内存中；但当B再读C的相同页面时，虽然也会产生缺页异常，但是不再需要从磁盘中复制文件过来，而可直接使用已经保存在内存中的文件数据
• 可用于实现高效的大规模数据传输。内存空间不足，是制约大数据操作的一个方面，解决方案往往是借助硬盘空间协助操作，补充内存的不足。但是进一步会造成大量的文件I/O操作，极大影响效率。这个问题可以通过mmap映射很好的解决。换句话说，但凡是需要用磁盘空间代替内存的时候，mmap都可以发挥其功效
1.2.2. mmap的使用
对于移动端日志采集SDK来说，主要进行的工作就是将用户写入的数据保存到文件中，在这个过程中涉及到在native层调用mmap函数实现在进程虚拟内存地址空间中分配地址空间，创建和物理内存的映射关系。
接下来介绍一下Linux系统中mmap机制的使用流程：
mmap函数
• 函数声明
void mmap(void addr, size_t size, int prot, int flags, int fd, off_t offset);
• 返回值说明
成功执行时，mmap()返回被映射区的指针。失败时，mmap()返回MAP_FAILED[其值为(void )-1],error被设为以下的某个值：
1 EACCES：访问出错
2 EAGAIN：文件已被锁定，或者太多的内存已被锁定
3 EBADF：fd不是有效的文件描述词
4 EINVAL：一个或者多个参数无效
5 ENFILE：已达到系统对打开文件的限制
6 ENODEV：指定文件所在的文件系统不支持内存映射
7 ENOMEM：内存不足，或者进程已超出最大内存映射数量
8 EPERM：权能不足，操作不允许
9 ETXTBSY：已写的方式打开文件，同时指定MAP_DENYWRITE标志
10 SIGSEGV：试着向只读区写入
11 SIGBUS：试着访问不属于进程的内存区
• 参数说明
参数含义
addr 映射区的开始地址，设置为0时表示由系统决定映射区的起始地址 size 映射区的长度。//长度单位是以字节为单位，不足一内存页按一内存页处理
prot 期望的内存保护标志，不能与文件的打开模式冲突。是以下的某个值，可以通过or运算合理地组合在一起 flags 指定映射对象的类型，映射选项和映射页是否可以共享。它的值可以是一个或者多个以下位的组合体
fd 有效的文件描述词。一般是由open()函数返回，其值也可以设置为-1，此时需要指定flags参数中的MAP_ANON,表明进行的是匿名映射 offset 被映射对象内容的起点
mmap在移动端代码中的使用
//用于写入文件的缓存Buffer
static unsigned char _buffer = NULL;
// mmap缓存文件的大小
static int mmap_cache_file = 100*1024;

void init() {
//第一步: 根据设置的缓存位置生成用于映射的文件
makedir_mmapfile(cache_path);
//第二步：打开缓存文件
int fd = open(cache_path, O_RDWR | O_CREAT, S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP);
//mmap映射的文件的判断
if(fd != -1) {
……
//第三步：mmap映射文件到buffer内存中
_buffer = (unsigned char *) mmap(0, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
}
//第四步：关闭文件句柄
close(fd);
}

//第五步：操作mmap内存读写
void write(….) {
// 将要写入的数据封装，压缩和加密
data_zlib_compress();

//将mmap的缓存写入到文件中
fwrite(_buffer, sizeof(char), _buffer.length, dest_file);
fflush(dest_file);

// 文件大小变化等相关操作
update();
}
日志写入的流程

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 Android 9系统版本手机，分别测试了已有的Java日志库、当前日志库、美团Logan、腾讯XLog日志库的写入性能。通过写入速度、GC频率、CPU占用率几个维度来衡量日志库的写入性能，测试的结果只限于衡量当前测试环境，并不代表Android平台整体平均水准。
测试数据量：
写入数据量/条写入间隔/ms 每条日志数据量
20000 3 224字节数据
测试结果

内存的GC测试结果
java日志库:

native日志库:

从上边的内存性能图片中可以看到，java日志库在大量写日志的时候回造成频繁的GC，虽然native日志库不会出现这样频繁的GC，从图中可以看到java日志库的GC频率大约是1s/次，native日志库的GC频率大约是7.5s/次。

CPU使用率测试结果
java日志库:

native日志库:

从上边cpu性能图片中可以看到，java日志库在频繁写入日志的时候cpu的平均使用率大约为13%，native日志库在频繁写入日志的时候cpu的平均使用率大约为5%。
从上述内存以及cpu占用率的对比中，我们可以看出native日志库相较于java日志库来说，性能上有了很大的提示，对于内存的占用较小，在频繁的I/O操作以及加密压缩操作的情况下cpu的使用率仍保持在较低值。

日志库性能的对比
上边我们与java日志进行了对比，接下来我们将于其他使用mmap实现的日志库进行下对比
写入速度（ms/条） GC频率（s/ci） CPU使用率
java日志库 0.3692 1 13%
当前日志库 0.0533 7.5 5%
美团Logan 0.037 12 5%
腾讯Xlog 0.067 10 3%

1.3. 实践案例

在app的线上环境我们可能遇到各种问题，我们希望将出现问题当天的日志获取到用于问题的分析，协助解决问题。这样的业务场景几乎覆盖了大部分的业务场景，对于自助收银机这样的设备使用场景，运行时期的日志对于问题的排查尤为重要。
数科自助收银设备主要服务于各大超市卖场的自如结账，缓解多条人工收银通道仍无法抵消的收银压力。当出现问题的时候，我们不可能对使用者进行回访，所以运行时候的日志对于问题排查尤为重要。
在未使用移动日志系统之前，遇到问题后，由于缺少运营工具，对于问题的排查，需要占用较多的研发资源，在接入移动日志系统后，运营就可以独自处理大部分的问题。这样极大的提高了解决问题的效率，减少了研发侧参与排查运营问题的时间。

1.4. 写到最后

当前的sdk使用场景是定时拉取服务端的策略，根据下发的最新策略进行日志文件的上报，有一定的时间延后性，后期我们将开放主动上报日志的通道以及结合push推送消息，提高日志回捞的及时性以及成功率。
当前的sdk暂时只支持移动端（Android以及IOS），在后续我们将进行多端支持，将在RN，Flutter，小程序以及H5等各种应用场景中统一使用当前日志库进行日志的采集和存储。