一种降低日志文件空间占用的方法、存储介质及终端与流程

1.本发明涉及计算机技术领域，具体而言，涉及一种降低日志文件空间占用的方法、存储介质及终端。


背景技术：

2.日志功能对于服务器、通信基站、工业网关和路由器等需要长时间持续运行的设备来讲是一项必备的基础功能，完善的日志功能可以非常有效地帮助运维人员排查定位设备的问题。然而，由于设备的长时间持续运行，必将会产生大量的日志数据，这些日志文件将造成相当大的空间占用。与此同时，无论是硬盘存储器还是闪存，其价格都与存储容量呈正相关，庞大的日志数据文件给设备的生产和运维带来了巨大的成本负担。
3.容易想到的是，为解决以上提及的问题，我们可以将每一条日志语句映射为一个索引值，在存储日志语句的时候仅需要存储日志语句相对应的索引值和参数即可，也就是通信行业较为常用的打点日志法。其运行逻辑的流程图如图2所示。
4.然而，打点日志法存在两个问题，一个是打点日志必须在每次更新源代码之后，使用独立的索引表生成器将整个工程的源代码扫描一遍，并提取源代码中存在的所有日志语句，为每一条日志语句生成一个全局唯一的索引值，最终形成索引表文件。对于规模较大的软件工程而言，以上的过程是相当耗时的。而且，一旦在源代码更新之后没有立即更新索引表，将造成源代码和索引表的版本不一致，这将会使得最终生成的日志文件无法正常解析和显示。二是打点日志没有写入字符串类型参数的能力，这将严重限制日志功能的扩展性和灵活性。
5.而另一种在互联网领域常用的降低日志文件空间占用的方法是压缩日志法，如图3所示，也就是在写入日志语句到文件之前对日志数据进行压缩，这可以非常有效地降低日志文件空间占用。但是，压缩日志数据的算法较为复杂，对于处理器算力的消耗通常也是比较大的。然而，我们并不希望在降低日志文件空间占用的同时，消耗掉太多的处理器算力，毕竟处理器算力才是整台设备当中最宝贵的资源。


技术实现要素：

6.本发明在于提供一种降低日志文件空间占用的方法、存储介质及终端，其克服了现有的打点日志法和压缩日志法所存在的上述问题，既可以显著降低日志文件空间占用，又非常节约处理器算力。
7.为了解决上述的问题，本发明采取的技术方案如下：第一方面，本发明提供了一种降低日志文件空间占用的方法，包括以下步骤：s1、构建数据查找结构以及索引表；s2、基于数据查找结构和索引表处理日志语句；s3、保存处理后的日志语句；所述步骤s2包括以下步骤：
s21、判断日志语句是否存在字符串，若存在，则继续执行步骤s22，若不存在，则日志语句处理过程结束；s22、提取日志语句中的字符串作为目标字符串；s23、计算目标字符串的crc编码；s24、判断数据查找结构中是否存在目标字符串的crc编码，若存在，则跳转至步骤s27，若不存在，则继续执行步骤s25；s25、将目标字符串的crc编码添加至数据查找结构；s26、将目标字符串添加到索引表；s27、将日志语句中的目标字符串替换为索引表中对应位置的索引值，跳转至步骤s21。
8.本方案在每写一条日志语句时，提取出日志语句中所有的字符串，并将字符串映射为全局唯一的索引值。当把日志语句中的所有字符串都替换为相应的索引值之后，再将日志语句写入日志文件当中，能显著降低日志文件空间占用。对日志语句中的字符串计算crc编码值，相当于是在计算字符串的“数字指纹”。使用crc编码，对于处理器算力的需求相对较小，可以更加快速地计算出字符串的数字指纹。在实际的工程实施过程中，使用md5或hash等计算数字指纹的算法同样也是可以的，但是计算速度稍低。
9.在实际的工程实施当中，数据查找结构可采用红黑树、哈希表、排序树和有序数组等可以实现快速搜索的数据结构。也就是说，本发明使用任何一种可以实现快速搜索的数据结构，均落入本专利的保护范围。
10.在本发明的一较佳实施方式中，若采用32位处理器实现所述方法，则采用crc-32算法计算字符串的crc编码，若采用64位处理器实现所述方法，则采用crc-64算法计算字符串的crc编码。
11.本方案可使crc编码的位宽与处理器寄存器位宽相等，可以尽可能地节约处理器算力，同时也由于crc编码位宽较大，可以最大程度地避免crc编码值冲突问题。
12.在本发明的一较佳实施方式中，所述数据查找结构为红黑树，所述crc编码作为红黑树的键值。
13.本方案使用crc编码值来作为红黑树的键值来创建红黑树，是因为红黑树的时间复杂度和空间复杂度均较低，具有非常高的实用价值。
14.第二方面，本发明提供一种计算机可读存储介质，所述计算机可读存储介质中存储有程序指令，所述程序指令被处理器执行时实现上述的方法。
15.第三方面，本发明提供一种终端，包括处理器及存储器，所述处理器与所述存储器电性连接，所述存储器用于存储指令和数据；所述处理器用于执行上述方法。
16.与现有技术相比，本发明的有益效果是：1）与打点日志法相比，本发明不需要每次更新源代码之后立即同步更新索引表，在节约大量时间成本的同时，还天然保证了日志文件和索引表的版本一致性，可靠性更高；2）打点日志法没有写入字符串类型参数的能力，而本发明具备此能力，扩展性和灵活性更强；3）与压缩日志法相比，本发明方法的时间复杂度和空间复杂度更低，更加节约处理器算力。
17.为使本发明的上述目的、特征和优点能更明显易懂，下文特举本发明实施例，并配合所附附图，作详细说明如下。
附图说明
18.为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
19.图1是本发明所述降低日志文件空间占用的方法流程示意图；图2是现有技术中的打点日志流程图；图3是现有技术中的压缩日志流程图；图4、5、6、7为本发明实施例中的写入字符串时的索引表。
具体实施方式
20.为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。
21.因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
实施例
22.请参照图1，本发明实施例提供了一种降低日志文件空间占用的方法。
23.在本实施例中，所适用的处理器为32位处理器，采用crc-32算法计算字符串的crc编码，所采用的数据查找结构为红黑树。
24.在本实施例中，以通信基站启动时，基站设备用以下语句记录一条日志为例，如下：gnb_log(“gnodeb %s startup at %u s (utc)”, gnb_name, timestamp)对该日志编码处理过程如下：首先提取第一个字符串“gnodeb
ꢀ”
，计算其crc-32编码值为4264837701。此值在红黑树中不存在，所以将其添加红黑树中，将字符串“gnodeb
ꢀ”
添加到索引表中，得到索引表如图4所示。此时将原语句中的字符串“gnodeb
ꢀ”
替换为其索引值0。需要说明的是，crc-32有标准的计算规则，为业界公知常识。甚至存在许多在线计算crc-32的网站，比如crc（循环冗余校验）在线计算_ip33.com。
25.接下来提取第二个字符串，也就是参数gnb_name的值“inno-gence gnb”，计算其crc-32编码值为4115690655。此值在红黑树中不存在，所以将其添加到红黑树中，将字符串“inno-gence gnb”添加到索引表中，得到索引表如图5所示。此时将原语句中的字符串“inno-gence gnb”替换为其索引值1。
26.接下来提取第三个字符串
“ꢀ
startup at
ꢀ”
，计算其crc-32编码值为2112558363。此值在红黑树中不存在，所以将其添加到红黑树中，将字符串
“ꢀ
startup at
ꢀ”
添加到索引表中，得到索引表如图6所示。此时将原语句中的字符串
“ꢀ
startup at
ꢀ”
替换为其索引值2。
27.接下来提取第四个字符串
“ꢀ
s (utc)”，计算其crc-32编码值为3108629292。此值在红黑树中不存在，所以将其添加到红黑树中，将字符串
“ꢀ
s (utc)”添加到索引表中，得到索引表如图7所示。此时将原语句中的字符串
“ꢀ
s (utc)”替换为其索引值3。
28.最终得到经过编码之后的语句为“0 1 2 1634023630 3”，将该语句保存至日志文件即可。
29.可以看到编码之后的日志语句比原语句短小了许多，相应地对于存储空间的占用也得到了明显的降低。
30.编码之后的语句“0 1 2 1634023630 3”的解码过程只需要将索引值替换为相应的字符串即可实现，此处不再赘述。解码之后的输出结果为“gnodebinno-gence gnb startup at 1634023630 s (utc)”。
31.以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。