[转]京东mPaaS移动日志建设与应用

引言

移动操作系统为开发者提供了功能丰富的日志组件，比如说Android Studio 中的Logcat窗口会显示系统消息，例如在进行垃圾回收时显示的消息，以及使用Log类添加到应用的消息， 能够辅助开发者进行高效的开发工作。然而在生产环境中，当用户（或者老板）反馈一些问题，又比较冷僻难以复现的时候（不是Crash），常常就会陷入一筹莫展的境地。此时，借助线上异常数据实时上报，我们只能是祈祷用户网络环境通畅，能够及时把异常数据第一时间上报上来，然而这种做法并不能保证我们永远那么幸运。

于是，我们需要研制一款性能较高的移动日志系统来解决我们当下的难题，该系统能具备日志信息完整、性能损耗低、轻量级（体积）、精确回捞的特点。接下来介绍一下移动日志系统的研发历程。

设计方案

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

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都可以发挥其功效

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被设为以下的某个值：

EACCES：访问出错
EAGAIN：文件已被锁定，或者太多的内存已被锁定
EBADF：fd不是有效的文件描述词
EINVAL：一个或者多个参数无效
ENFILE：已达到系统对打开文件的限制
ENODEV：指定文件所在的文件系统不支持内存映射
ENOMEM：内存不足，或者进程已超出最大内存映射数量
EPERM：权能不足，操作不允许
ETXTBSY：已写的方式打开文件，同时指定MAP_DENYWRITE标志
SIGBUS：试着访问不属于进程的内存区

• 参数说明

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();
    }

日志写入的流程

3. 移动日志系统架构介绍

客户端日志SDK为开发者提供日志的打印，主要是将在线上运行期间产生的日志写入文件中，根据开发者的需要捞取指定的日志，为开发者解决线上问题提供助力。我们设计了满足基本功能的系统，架构如下图所示：

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平台整体平均水准。

测试结果

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实现的日志库进行下对比。

实践案例

在app的线上环境我们可能遇到各种问题，我们希望将出现问题当天的日志获取到用于问题的分析，协助解决问题。这样的业务场景几乎覆盖了大部分的业务场景，对于自助收银机这样的设备使用场景，运行时期的日志对于问题的排查尤为重要。

数科自助收银设备主要服务于各大超市卖场的自如结账，缓解多条人工收银通道仍无法抵消的收银压力。当出现问题的时候，我们不可能对使用者进行回访，所以运行时候的日志对于问题排查尤为重要。

在未使用移动日志系统之前，遇到问题后，由于缺少运营工具，对于问题的排查，需要占用较多的研发资源，在接入移动日志系统后，运营就可以独自处理大部分的问题。这样极大的提高了解决问题的效率，减少了研发侧参与排查运营问题的时间。

写到最后

当前的sdk使用场景是定时拉取服务端的策略，根据下发的最新策略进行日志文件的上报，有一定的时间延后性，后期我们将开放主动上报日志的通道以及结合push推送消息，提高日志回捞的及时性以及成功率。

当前的sdk暂时只支持移动端（Android以及IOS），在后续我们将进行多端支持，将在RN，Flutter，小程序以及H5等各种应用场景中统一使用当前日志库进行日志的采集和存储。

转自京东mPaaS移动日志建设与应用