Page 480 - 《软件学报》2024年第4期
P. 480

2058                                                       软件学报  2024  年第  35  卷第  4  期


                 程序之间会出现资源竞争, 导致日志显示缺失和               CPU  开销提升的问题. 此外, Android    日志系统未提供相应的敏感
                 数据保护功能, 任何读权限日志用户均可阅读全部日志信息, 即使这些信息中存在其他用户的敏感数据信息; 最
                 后, Android  日志系统对于日志的持久化缺乏优化, 导致持久化文件占用空间过大.
                  1.2.2    Fuchsia 日志系统
                    Fuchsia OS  作为  Google 开发的新一代开源操作系统, 其日志系统仍在不断地迭代开发中. 分析其设计思路可
                 知, Fuchsia OS  的日志系统采用    Socket 实现进程间通信, 这一特征与        Android  日志系统的日志系统      (version  ⩾
                 5.0.0) 一致. 两者的不同点在于      Fuchsia OS  日志系统以链表作为缓冲区, 可以有效利用碎片化的内存空间. 目前
                 Fuchsia 的日志系统暂未投入到实际产品中进行大规模应用, 经过对源码的初步分析, 该日志系统存在内存拷贝次
                 数多、用户态内存频繁分配释放的问题.
                  1.2.3    FTrace 日志系统
                    FTrace 作为  Linux  内核日志系统, 用于协助开发人员了解 Linux 内核的运行时行为, 进行故障调试或性能分
                 析. 与前述日志系统“为每个操作系统维护唯一缓冲区”的设计理念不同, FTrace 在架构设计上采用“为每                            CPU  核
                 维护一个缓冲区”的设计方案, 因此日志读/写接口延时较低. 同时, FTrace 采用                  Page 结构组织数据, 单     Page 上记
                 录一个时间戳, Page 仅内日志记录相对时间差, 节约记录时间所需的存储空间. 但是                       FTrace 也存在缺陷, 例如由
                 于  Page 数据存储结构的特性, 导致当前      Page 剩余空间不足仍写入一条日志时, 需要构造新的             Page, 造成内存空间浪费.
                  1.2.4    Log4j2  日志系统
                    Log4j2  是开源组织   Apache 维护的一款基于     Java 的单进程日志框架, 采用单进程维护一个缓冲区的设计方
                 案, Log4j2  采用比较交换   (compare and swap, CAS) 方法实现缓冲区加解锁, 降低日志读写接口的延时            [24] . 与此同
                 时, Log4j2  使用缓存行填充解决伪共享问题, 隔离更新操作, 进一步提升运行效率                    [25] . Log4j2  存在的问题是  CAS
                 方法的   CPU  开销较大, 且存在日志缓冲区修改的          ABA  问题  (ABA problem) [26] .
                  1.2.5    NanoLog  日志系统
                    NanoLog  日志系统由   Stanford  大学  Platform  实验室开发  [14] . 如图  3  所示, 一方面该日志系统采用每线程对应
                 一个缓冲区的设计理念, 另一方面在编译期和运行时分别对日志进行二进制预处理, 使大量数据操作以二进制形
                 式完成. 因此, NanoLog  具备极低的时延和极高的日志吞吐量. NanoLog             读/写日志延时为      Log4j2  的  1/35, 数据吞
                 吐量为   Log4j2  的  40  倍  [14] . NanoLog  的缺陷在于采用空间换时间的策略, 内存消耗大, 同时在打印或持久化阶段需
                 要进行复杂的反序列化、格式化、排序等后处理操作, 实质上是将复杂处理后移.

                                                                    Runtime
                     C++          User sources with  Compile  User C++  Link  User application
                             NanoLog  preprocessor  NanoLog  Generated  User thread  Staging buffer  thread  log
                     user           injected code    object files      User thread  Staging buffer  NanoLog
                    sources                                                            compaction  Compact
                                                                       User thread
                                                                              Staging buffer
                   NanoLog        Metadata  combiner  library code  Compile
                    library                                            Decompressor  Human     Post
                                          Compile-time                             readable log  execution
                                           图 3 NanoLog  日志系统的日志写入流程         [14]

                  1.3   HiLog  日志系统的必要性和重要性
                    OpenHarmony  是面向全设备、全场景的开源操作系统, 日志是              OpenHarmony  不可或缺的基础能力.
                    从技术架构层面分析, 大多数主流日志系统都不适合作为                   OpenHarmony  的日志系统, 原因如下: ① FTrace 日
                 志系统仅适用于内核日志读写, 且使用            FTrace 则意味着操作系统的日志功能与           Linux  内核的强耦合, 不适用于适
                 配多内核的    OpenHarmony  操作系统; ② Log4j2  是单进程的日志框架, 不适用于操作系统这类多进程并发的状况.
                 ③ NanoLog  虽然拥有极高的日志写入速率, 但是日志读取需要复杂的后处理机制, 不能满足操作系统调试所需的
                 实时读日志需求.
   475   476   477   478   479   480   481   482   483   484   485