Page 91 - 《软件学报》2021年第5期

尤勇 等:一种监控系统的链路跟踪型日志数据的存储设计 1315

这样可以解决上面提到的读写冲突问题,并且在内存块完整写入磁盘以及索引数据更新到文件中后,才能
将对应的内存块数据清空.
(2) 集群机器宕机
当存储集群中的某台机器宕机后,内存中的数据是会丢失的;此外,如果在内存块写入文件时出现宕机,数
据块只写入了一部分,该部分数据就成为了无效的脏数据块.
理论上,监控日志的存储并不要求高可用、不可丢失性,日志存储系统是可以容忍少量的数据丢失的;在牺
牲了一定的数据完整性的前提下,带来更便捷的设计与更高的性能.以 MySQL 为例,它引入了事务、bin log 与
redo log 这 3 种机制,确保在宕机时内存中的页数据也不会出现丢失,但是这种机制在实现上是非常复杂的,对于
日志存储系统并不合适.
(3) LogView 的 id 重复
在一台被监控的服务器机器上,某一个应用在某小时内产生的 LogView 需要赋值 id 标识,此时需要针对 id
标识中的{index}段进行自增.如果此时发生进程中断或者机器宕机,内存中自增的 index 值会丢失,从而该小时
内的 index 值重置为 0,导致大量的 id 重复出现,所以需要周期性地将 index 值持久化到磁盘文件中,存在以下两
个问题.
• 时间周期太长会导致服务重启时重复 id 较多;
• 周期太短会因为存储 index 值的文件频繁 IO 操作影响机器性能.
当前采取每 3s 持久化 index 值到磁盘一次的策略,是多次真实实验后选出的较为合适的时间周期.
当出现 id 重复时,会直接更新之前 id 对应索引块中的地址信息为最新的地址.例如:当前小时内(3 600s)在
第 3 002 秒发生宕机,再次启动时,会读取之前最新的 index 值(第 3 000 秒时的 index 值),重启后生成的 index 值
会与第 3 000 秒~第 3 002 秒之间产生的 id 发生重复.在创建对应索引时,对应的一级索引 Entry 和二级索引 Entry
的空间中都已经存在相应数据了,此时采取直接覆盖的方式,更新为最新的地址,确保存储的信息是最新的.

4 效果评价

本节采集了部分真实环境的运行指标数据来体现本文存储方案的读写性能指标;此外,还随机选取了多组
数据文件与索引文件来说明日志的数据特征与磁盘空间的占用情况.
4.1 性 能
本文存储方案的性能通过集群 TPS、机器的硬件指标等来体现写入性能、通过耗时来说明查询性能.在第
2 节中提到了多种相关的用于日志存储的数据库、存储方案,而它们并不适合于日志的存储,所以此处并没有测
试对比它们的性能.
4.1.1 写入性能
在 LogView 日志写入数据文件时,需要等待内存块满后才能刷新到文件中,所以单条 LogView 写入的耗时
与内存块合适能满有关,即与日志产生的频率有关;此外,内存块写入数据文件实际上仅是将内存块刷新到磁盘
的过程,这主要与机器的配置有关,与存储方案设计的关系很小,所以本节不通过耗时来衡量写入性能.而通过
真实运行环境中的各项机器硬件指标以及 TPS 指标来体现.
此处采集了线上服务与线下测试两个集群中的真实运行数据,线上的后端集群中共存在上百台服务器,各
集群中硬件配置相同,随机选取了两个集群中的单台机器,它们的硬件配置(CPU 核数/内存/磁盘)如下.
• 线上环境机器 A:32 核/128G/5.44T.
• 线下测试环境机器 B:16 核/64G/3.76T.
上述两台机器(A 和 B)于 2020 年 5 月 1 日的 11:00~12:00 的 1 个小时内处理并存储了大量来被监控集群上
报的日志数据,此处同样使用 CAT 系统采集了该小时内两台机器运行时的硬件指标、所处理的日志的各项特
征指标,见表 2~表 4.