Page 481 - 《软件学报》2024年第4期

吴圣垚 等: HiLog: OpenHarmony 的高性能日志系统 2059

因此在上述主流日志系统中, Android 的日志系统 (Android version ≥ 5.0.0) 的技术架构脱颖而出, 可以满足内
核解耦、多进程、实时读写的需求. 但是, 该日志系统仍存在一些关键问题亟待解决.
(1) 吞吐量 (throughput) 问题: Android 日志系统的吞吐量已经不能完全满足当下的丰富软件生态, 负载超过吞
吐量将会导致严重的日志丢包问题. Yang 等人通过与 Google、VMware 工程师的交流, 发现在代码评审环节中,
有相当多的时间被用来讨论保留还是删除日志语句; 并且为了向吞吐量妥协, 剔除了大量有用的调试信息, 导致花
费更多的调试时间 [14] , 形成恶性循环. 事实上, 主流日志系统的吞吐量瓶颈在当下已经切实导致了开发效率的下降.
(2) 资源分配问题: Android 日志系统仅对进入日志缓冲区的日志总流量做出限制, 而未对每个程序的日志流
量进行限制. 从而导致各个程序会对写日志资源进行竞争, 竞争的结果是不确定、不公平的, 一个日志流量正常的
程序很可能因为一个违规高速写日志的程序而失去日志记录. 并且作为单一程序的开发者没有责任和动力去规范
程序的写日志速率, 从而节约日志总流量这项公共资源.
(3) 数据安全问题: 包含敏感数据的日志会流向日志系统, Android 日志系统没有相应的安全能力对数据进行
保护. 通过与华为、润和等公司进行沟通, 发现各种厂家对于自身硬件关键参数的保护需求是十分迫切的. 但是基
于对 Android 和 OpenHarmony 源码的日志语句分析, 在日志中普遍存在常用指针、内存地址、设备参数等关键
信息; 同时也存在用户操作信息、用户名等用户敏感数据. 这些数据为开发者提供了便利, 但也允许任何日志的使
用者都可以轻易获取上述数据, 带来严重的数据安全问题.
(4) 轻量设备兼容问题: Android 日志系统没有特别面向资源受限设备进行兼容设计. Android 日志系统在用户
态维护独立缓冲区, 保存包括 Linux 内核日志在内的所有日志数据, 因此需要消耗大量的内存资源, 导致难以在资
源受限设备上运行.
因此, 为了解决上述吞吐量、资源分配、数据安全和轻量设备兼容 4 个关键问题, 当前亟需为 OpenHarmony
操作系统设计与开发一款日志系统, 构成 OpenHarmony 操作系统软件供应链的重要节点 [22] .
2 HiLog 日志系统模型规范

尽管 HiLog 与 Android 日志系统有相同的基础架构, 但是 OpenHarmony 的面向全设备、面向全场景的独特
性使得 HiLog 必须具备高性能、高设备兼容性等新特性. 为了明确开发目标与技术特点, 本节为 HiLog 设计了相
应的模型规范, 包括性能原则、资源分配原则、设备兼容性原则和数据安全原则. 具体内容如下.
2.1 性能原则
衡量日志系统性能的指标主要是日志吞吐量, 吞吐量代表日志系统在不丢包的情况下日志收发的速率上限,
代表了日志系统在高速日志读写情境下精确捕获日志信息的能力. 随着应用生态的发展, 操作系统中各个应用的
写日志需求逐渐增长, 对日志系统的吞吐量提出了更高的要求. 当操作系统中的写日志需求超过了日志系统的吞
吐量时, 将会出现丢包问题. 丢包的日志无法被日志系统记录, 亦无法向程序开发者、维护人员提供任何有效信
息. 事实上, 当前主流日志系统的吞吐量瓶颈问题已经切实地影响了程序的开发, 开发者们不得不向性能妥协, 减
少日志的写入需求.
在吞吐量的影响因素方面, 一方面硬件平台的性能起到决定性的作用, 另一方面日志系统的合理设计和优化
也可以使其在相同的硬件平台上达到更高的吞吐量. 摩尔定律失效警示软件开发者不能仅通过期待硬件性能的高
速增长来满足软件的性能需求, 因此 HiLog 日志系统应当针对高吞吐量需求进行设计, 从软件层面解决吞吐量瓶
颈问题.
2.2 资源分配原则
系统资源不是无限的, 因此需要考虑分配问题. 从操作系统层面看, 日志系统作为操作系统的信息记录者, 不
应抢占过多的系统资源 (如 CPU 资源), 影响其他程序的正常运作. 从日志系统层面看, 一个程序的日志业务也不
应占用过多的日志系统资源, 影响其他程序的日志业务. 因此, HiLog 应当在设计时考虑资源分配问题. 一方面在
操作系统层面合理分配日志系统和其他程序占用的资源, 另一方面是在日志系统层面合理分配各个程序占用的日