CN113810231B - 一种日志解析方法、系统、电子设备及存储介质 - Google Patents

Abstract

本申请公开了一种日志解析方法，应用于分布式计算平台，包括：根据Raft协议确定所述分布式计算平台中每一计算节点的节点角色；根据所述计算节点的节点角色对日志解析规则进行一致性同步，以使所有所述计算节点对应的日志解析规则相同；若接收到日志数据，则将所述日志数据分发至所述计算节点；其中，所述计算节点中存储有预编译的日志解析规则；控制所述计算节点利用所述日志解析规则对所述日志数据执行日志解析操作。本申请能够在保证日志解析规则一致性的前提下，降低日志解析操作的性能消耗。本申请还公开了一种日志解析系统、一种电子设备及一种存储介质，具有以上有益效果。

Description

一种日志解析方法、系统、电子设备及存储介质

技术领域

本申请涉及日志审计技术领域，特别涉及一种日志解析方法、系统、电子设备及存储介质。

背景技术

传统单机日志审计设备由于无法进行动态扩展，单机流量处理有性能上限，导致大型流量业务无法有效支撑，经常出现设备宕机、数据丢失等问题，严重影响企业的安全运维和正常生产工作。相关技术中，使用Flink、Spark、MapReduce等基于分布式计算平台实现了分布式的日志审计的方案，但是上述分布式计算平台使用的通用计算框架不适用于日志解析业务，当数据量剧增时处理性能问题都比较明显，并且底层代码复杂，优化也比较困难。

因此，如何在保证日志解析规则一致性的前提下，降低日志解析操作的性能消耗是本领域技术人员目前需要解决的技术问题。

发明内容

本申请的目的是提供一种日志解析方法、系统、电子设备及存储介质，能够在保证日志解析规则一致性的前提下，降低日志解析操作的性能消耗。

为解决上述技术问题，本申请提供一种日志解析方法，应用于分布式计算平台，该日志解析方法包括：

根据Raft协议确定所述分布式计算平台中每一计算节点的节点角色；

根据所述计算节点的节点角色对日志解析规则进行一致性同步，以使所有所述计算节点对应的日志解析规则相同；

若接收到日志数据，则将所述日志数据分发至所述计算节点；其中，所述计算节点中存储有预编译的日志解析规则；

控制所述计算节点利用所述日志解析规则对所述日志数据执行日志解析操作。

可选的，将所述日志数据分发至所述计算节点，包括：

按照日志种类划分规则对所述日志数据进行划分，得到多个种类的子数据；

确定所述计算节点与日志种类的对应关系，并根据所述计算节点与所述日志种类的对应关系将所述子数据分发至对应的计算节点。

可选的，在控制所述计算节点利用所述日志解析规则对所述日志数据执行日志解析操作之前，还包括：

确定每一所述计算节点对应的日志种类，根据日志种类与日志解析规则的对应关系在所述计算节点中预编译对应的日志解析规则，并将预编译结果存储至所述计算节点。

可选的，将所述日志数据分发至所述计算节点之后，还包括：

判断所述计算节点的业务压力是否大于预设压力；

若是，则所述计算节点接收到的日志数据分配给所述计算节点的关联节点；其中，所述关联节点与所述计算节点对应的日志种类相同。

可选的，所述节点角色包括领导节点、从属节点和候选节点；

相应的，根据所述计算节点的节点角色对日志解析规则进行一致性同步，包括：

将所述领导节点的LRU队列中存储的规则标识增量同步至所述从属节点的LRU队列；

其中，规则库中每一日志解析规则均有唯一对应的规则标识，所述计算节点利用所述规则标识从所述规则库中读取日志解析规则。

可选的，根据所述计算节点的节点角色对日志解析规则进行一致性同步，包括：

根据所述计算节点的节点角色通过mmap内存映射的方式对所述日志解析规则进行一致性同步。

可选的，所述计算节点之间通过gRPC协议和Protobuf协议进行通讯；

其中，所述计算节点通过AppendEntries RPC传输心跳信号和日志数据，所述计算节点通过RequestVote RPC选举领导节点。

本申请还提供了一种日志解析系统，该系统包括：

节点角色确定模块，用于根据Raft协议确定分布式计算平台中每一计算节点的节点角色；

规则同步模块，用于根据所述计算节点的节点角色对日志解析规则进行一致性同步，以使所有所述计算节点对应的日志解析规则相同；

日志分发模块，用于若接收到日志数据，则将所述日志数据分发至所述计算节点；其中，所述计算节点中存储有预编译的日志解析规则；

日志解析模块，用于控制所述计算节点利用所述日志解析规则对所述日志数据执行日志解析操作。

本申请还提供了一种存储介质，其上存储有计算机程序，所述计算机程序执行时实现上述日志解析方法执行的步骤。

本申请还提供了一种电子设备，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器调用所述存储器中的计算机程序时实现上述日志解析方法执行的步骤。

本申请提供了一种日志解析方法，应用于分布式计算平台，包括：根据Raft协议确定所述分布式计算平台中每一计算节点的节点角色；根据所述计算节点的节点角色对日志解析规则进行一致性同步，以使所有所述计算节点对应的日志解析规则相同；若接收到日志数据，则将所述日志数据分发至所述计算节点；其中，所述计算节点中存储有预编译的日志解析规则；控制所述计算节点利用所述日志解析规则对所述日志数据执行日志解析操作。

本申请根据Raft协议为分布式计算平台中每一计算节点设置对应的节点角色，基于节点角色对日志解析规则进行一致性同步，使得各个计算节点对日志解析时使用的规则相同。在收到日志数据后，本申请将日志分发至各个计算节点，使得各个计算节点各自处理自身接收到的日志数据，计算节点之间无需进行频繁的信息交互。计算节点中存储有预编译的日志解析规则，无需匹配所有解析规则，避免了性能资源浪费。因此，本申请能够在保证日志解析规则一致性的前提下，降低日志解析操作的性能消耗。本申请同时还提供了一种日志解析系统、一种存储介质和一种电子设备，具有上述有益效果，在此不再赘述。

附图说明

为了更清楚地说明本申请实施例，下面将对实施例中所需要使用的附图做简单的介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例所提供的一种日志解析方法的流程图；

图2为本申请实施例所提供的一种Raft协议的日志复制原则示意图；

图3为本申请实施例所提供的一种Raft协议的分布式日志解析系统的示意图；

图4为本申请实施例所提供的一种计算节点原理示意图；

图5为本申请实施例所提供的一种计算节点的通讯消息处理示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

下面请参见图1，图1为本申请实施例所提供的一种日志解析方法的流程图。

具体步骤可以包括：

S101：根据Raft协议确定所述分布式计算平台中每一计算节点的节点角色；

其中，其中，本实施例可以应用于使用Raft协议的分布式计算平台，该分布式计算平台中包括多个计算节点，在Raft协议中计算节点的节点角色可以包括领导节点、从属节点和候选节点。领导节点用于将自身存储的日志条目传输至从属节点，在领导节点出现异常时从属节点的角色变更为候选节点，接收投票数最多的候选节点成为新的领导节点。

S102：根据所述计算节点的节点角色对日志解析规则进行一致性同步，以使所有所述计算节点对应的日志解析规则相同；

其中，本实施例中计算节点中存储的日志条目具体指日志解析规则的规则标识，每条日志解析规则均存在唯一对应的规则标识，日志解析规则可以存储于规则库中，各个计算节点可以根据自身存储的规则标识从规则库中获取相应的日志解析规则。

具体的，本实施例中可以通过将领导节点的规则标识增量传输至从属节点实现日志解析规则的一致性同步，由于上述方式中结算节点之间传输的是日志解析规则的规则标识而不是日志解析规则，因此能够提高日志解析规则的同步效率。进一步的当所有计算节点中存储的规则标识相同时，所有计算节点对应的日志解析规则也都相同。

S103：若接收到日志数据，则将所述日志数据分发至所述计算节点；

其中，在接收到日志数据后，可以将日志数据划分为多部分的子数据，将每一子数据分发至对应的计算节点。具体的，本实施例可以预先设置各个计算节点需要处理的日志种类，并将相应日志种类的子数据分发至相应的计算节点，以使每一计算节点仅处理特定1种或多种类型的日志。

本实施例中的计算节点内可以存储有预编译后的日志解析规则，以便直接使用编译后的日志解析规则对接收到的子数据进行处理，从而提高处理效率。作为一种可行的实施方式，本实施例可以在计算节点中存储预编译的全部日志解析规则，也可以在计算节点中存储预编译的部分日志解析规则。进一步的，在为每一计算节点设置需要处理的日志种类、且根据计算节点设置需要处理的日志种类分发子数据的前提下，可以确定解析每一日志种类时所需要使用的部分日志解析规则，以便在计算节点中存储与自身对应的日志种类相匹配的预编译的部分日志解析规则。

举例说明上述过程，例如计算节点A用于处理网络安全日志，计算节点B用于处理系统崩溃日志，可以从所有的日志解析规则中确定所有与网络安全日志相关的网络安全日志解析规则、以及所有与系统崩溃日志相关的系统崩溃日志解析规则，进而在计算节点A中存储预编译后的网络安全日志解析规则，在计算节点B中存储预编译后的崩溃日志解析规则。

S104：控制所述计算节点利用所述日志解析规则对所述日志数据执行日志解析操作。

其中，在将日志数据分发至各个计算节点之后，可以控制各个计算节点利用所述日志解析规则对所述日志数据执行日志解析操作。在得到日志解析结果之后，可以存储日志解析结果或对日志解析结果进行转发。

本实施例根据Raft协议为分布式计算平台中每一计算节点设置对应的节点角色，基于节点角色对日志解析规则进行一致性同步，使得各个计算节点对日志解析时使用的规则相同。在收到日志数据后，本实施例将日志分发至各个计算节点，使得各个计算节点各自处理自身接收到的日志数据，计算节点之间无需进行频繁的信息交互。计算节点中存储有预编译的日志解析规则，无需匹配所有解析规则，避免了性能资源浪费。因此，本实施例能够在保证日志解析规则一致性的前提下，降低日志解析操作的性能消耗。

Raft是一种共识算法，Raft提供了一种在计算系统集群中分布状态机的通用方法，确保集群中的每个节点都同意一系列相同的状态转换。Raft协议为每个节点定义了三个状态：领导节点Leader、候选节点Candidate、从属节点Follower，将时间定义为Term，每个Term有一个ID。Term类似逻辑时钟，在每个Term都会有Leader被选举出来。

领导节点Leader负责处理所有的写请求、发起日志复制、定时心跳，每个Term期间最多只能有一个领导节点Leader，可能会存在选举失败的场景，那么这个Term内是没有领导节点Leader。从属节点Follower处于被动状态，负责处理Leader发过来的RPC请求，并且做出回应。候选节点Candidate是用来选举一个新的Leader，当从属节点Follower超时，就会进入候选节点Candidate状态。

初始状态，所有的节点都处于Follower状态，节点超时后递增current Term进入候选节点Candidate，该节点发送广播消息RequestVote RPC给其他从属节点Follower请求投票。当收到多数节点的投票后，该节点从候选节点Candidate进入Leader。从属节点Follower在收到投票请求后，会首先比较Term，然后再比较日志index，如果都满足则更新本地Current Term然后回应RequestVote RPC为其投票。每个Term期间，从属节点Follower只能投一次票。

请参见图2，图2为本申请实施例所提供的一种Raft协议的日志复制原则示意图，当领导节点掌权之后，从属节点日志可能有以下情况：一个格子表示一个日志条目；格子中的数字是它的任期。一个从属节点可能会丢失一些条目(a,b)；可能多出来一些未提交的条目(c,d)；或者两种情况都有(e,f)。例如，场景f在如下情况下就会发生：如果一台服务器在任期2时是领导节点往它的日志中添加了一些条目，然后在将它们提交之前就宕机了，之后它很快重启了，成为了任期3的领导节点，又往它的日志中添加了一些条目，然后在任期2和任期3中的条目提交之前它又宕机了并且几个任期内都一直处于宕机状态。

领导节点通过强制从属节点们复制它的日志来处理日志的不一致。这就意味着，在从属节点上的冲突日志会被领导者的日志覆盖。为了使得从属节点的日志同自己的一致，领导节点需要找到从属节点同它的日志一致的地方，然后删除从属节点在该位置之后的条目，然后将自己在该位置之后的条目发送给从属节点。这些操作都在AppendEntriesRPC进行一致性检查时完成。领导者永远不会覆盖自己已经存在的日志条目并且日志的流向为：从领导者到从属节点。

作为对于图1对应实施例的进一步介绍，本实施例可以通过以下方式将所述日志数据分发至所述计算节点：按照日志种类划分规则对所述日志数据进行划分，得到多个种类的子数据；确定所述计算节点与日志种类的对应关系，并根据所述计算节点与所述日志种类的对应关系将所述子数据分发至对应的计算节点。本实施例中可以为每一计算节点设置对应的日志种类，即确定每一计算节点需要处理的日志的种类，进而根据日志种类和计算节点的对应关系将相应日志种类的子数据发送至对应的计算节点。例如计算节点A用于处理网络安全日志，可以将日志数据中的网络安全日志发送至计算节点A。

进一步的，在将所述日志数据分发至对应的计算节点之后，还可以判断所述计算节点的业务压力是否大于预设压力；若是，则所述计算节点接收到的日志数据分配给所述计算节点的关联节点；其中，所述关联节点与所述计算节点对应的日志种类相同。

进一步的，在控制所述计算节点利用所述日志解析规则对所述日志数据执行日志解析操作之前，还可以确定每一所述计算节点对应的日志种类，根据日志种类与日志解析规则的对应关系在所述计算节点中预编译对应的日志解析规则，并将预编译结果存储至所述计算节点。通过存储预编译结果能够提高计算节点解析日志数据的效率。

作为对于图1对应实施例的进一步介绍，Raft协议中确定的节点角色包括领导节点、从属节点和候选节点。相应的，可以通过以下方式对日志解析规则进行一致性同步：将所述领导节点的LRU队列中存储的规则标识增量同步至所述从属节点的LRU队列；其中，规则库中每一日志解析规则均有唯一对应的规则标识，所述计算节点利用所述规则标识从所述规则库中读取日志解析规则。LRU是Least Recently Used的缩写，即最近最少使用，是一种常用的页面置换算法，选择最近最久未使用的页面予以淘汰。该算法赋予每个页面一个访问字段，用来记录一个页面自上次被访问以来所经历的时间t，当须淘汰一个页面时，选择现有页面中其t值最大的，即最近最少使用的页面予以淘汰。

传统的日志审计设备，因为单机能力的限制，在海量数据的采集、存储、索引和运算方面，都存在比较大的瓶颈，特别是在日志解析方面，由于解析比较占用CPU资源，导致大流量场景下，因为数据处理来不及，日审设备会丢失大量的数据。部分厂商发明了设备级联的方式，但是设备级联不能保证解析规则的一致性，各个节点都有自己的规则，并且数据都是自下往上输送，节点间相互独立，可能导致部分数据存在未解析的情况。市面上部分厂商基于分布式计算平台，比如Flink、Spark、MapReduce等实现了分布式的日志审计设备，但是由此带来的问题也非常明显，为了实现分布式日志解析能力，引入了厚重的计算框架，框架不必要的特性占用了一部分计算资源，并且功能的不确定性，在设备运行过程中埋藏了很多故障隐患。并且受制于框架API，只能按照要求实现业务逻辑，无法实现复杂的特性，由于他们都是通用的计算框架，并不适用于日志解析业务，当数据量剧增时，处理性能问题都比较明显，并且底层代码复杂，优化也比较困难。由此可见，以上的分布式日审方案，产品的硬件成本和运营成本相较于传统设备都比较高。

下面通过在实际应用中的基于Raft协议的分布式日志解析方案以解决上述生产环境中出现的性能和成本问题，具体包括以下步骤：

步骤1：建立Raft协议中的各个计算节点角色。

具体的，上述建立计算节点角色的过程包括：系统初始化时计算节点RaftAgent按照Raft协议进行投票选举，明确领导节点Leader、从属节点Follower和候选节点Candidate节点的角色。各个计算节点按照消息类型根据通信消息处理机制(gRPC+Protobuffer)进行消息处理，如果是投票消息，则进行投票反馈操作，如果是解析规则同步消息，则按照要求从领导节点Leader进行数据增量同步。本实施例在程序初始化后，自动进行主从选举，节点宕机后触发二次选举，解析规则按照经过生产环境论证的Raft协议保证实时分布式一致性，确保数据处理的准确性，保障企业生产安全，提高企业生产力。

步骤2：通信节点按照角色设定进行解析规则的一致性同步。

在步骤1后可以得到一个领导节点Leader和多个从属节点Follower的，在领导节点Leader的任期内，用户只能操作集群中领导节点Leader的解析规则，操作从属节点Follower的解析规则也会将请求转发到领导节点Leader，数据流向只有一个，从领导节点Leader节点到从属节点Follower。

从属节点Follower可以定期在AppendEntries阶段完成一致性校验，如果数据落后，将从领导节点Leader同步增量数据，如果数据不一致，则同步领导节点Leader数据并覆盖本地数据，从而保证数据分布式一致性。

步骤3：分流引擎提取各个计算节点的解析规则特征并缓存。

其中，分布式计算平台的分流引擎提取各个计算节点的解析规则特征并缓存包括：分流引擎向Leader节点获取Follower计算节点数据，遍历计算节点进行解析规则特征提取，使用Java Regex及Aviator进行预编译并进行缓存。

上述遍历计算节点进行解析规则特征提取可以得到主规则和子规则，主规则指按照日志种类划分的日志解析规则，子规则指按照日志种类划分的日志解析规则中每一条规则。

步骤4：系统对流入的日志流量按照集群部署方式进行高效解析。

具体的，分布式计算平台的采集终端以HTTP/TCP/UDP等协议向集群发送数据，分流引擎对日志进行主规则和子规则的特征匹配，特征匹配完毕后按照特征来源的计算节点进行数据分发，计算节点根据解析规则的LRU队列进行日志数据的有序解析，日志数据解析完成后进行入库或者进行转发，至此日志解析完毕。

本实施例将解析规则单元化，采用分布式LRU队列和主规则前置的两种方式提升解析规则的匹配效率。主规则的分流引擎将日志进行分流，从而保证计算资源的弹性分配，不会导致某一个计算节点频繁宕机。分流引擎基于日志特征，将日志进行提前分类，日志处理不会像Flink和Spark分布式计算平台那样，日志会在各个计算节点间频繁的相互交换，影响了系统整体的吞吐量。系统设计非常轻量级，各个计算节点各司其职，保证数据的分布式一致性。

请参见图3，图3为本申请实施例所提供的一种Raft协议的分布式日志解析系统的示意图。在接收到日志流后，可以使用主规则对日志数据进行提前匹配，得到多个主规则对应的日志数据，进而将每一类日志数据分发至对应的计算节点。上述主规则(如Windows规则、Linux规则、中间件规则)指每一日志种类对应的日志解析规则。本实施例中每个计算节点基于Raft协议实时同步节点间的解析规则，并且各自维护了一个LRU队列，最频繁触发的规则自动前置，保证日志解析效率，每个计算节点当数据处理来不及时会触发背压机制，由分流引擎将日志进行分流，从而保证计算资源的弹性分配，不会导致某一个计算节点频繁宕机。分流引擎基于日志特征，将日志进行提前分类，日志处理不会像Flink和Spark分布式计算平台那样，日志会在各个计算节点间频繁的相互交换，影响了系统整体的吞吐量。本系统系统设计非常轻量级，各个计算节点各司其职，计算规则由RaftAgent保证数据的分布式一致性。

图3中各个计算节点的规则是全量存储的，系统设计了分流引擎进行提前分流后，计算节点只处理总体流量的其中一部分数据，自然只激活了其中一部分解析规则，无需匹配所有解析规则导致性能资源浪费，从而提升系统整体的吞吐量。

本实施例解决了传统日审设备在单机或者级联情况下无法处理海量数据和解析规则不一致的问题，并且未使用繁重的计算框架，整个系统运行非常的轻量级，可以按照用户的业务数据量，弹性的增加计算节点，在满足用户需求的情况下，减少了产品的硬件成本和用户的运营成本。

请参见图4和图5，图4为本申请实施例所提供的一种计算节点原理示意图，图5为本申请实施例所提供的一种计算节点的通讯消息处理示意图。本实施例中计算节点之间通过gRPC协议和Protobuf协议进行通讯；其中，所述计算节点通过AppendEntries RPC传输心跳信号和日志数据，所述计算节点通过RequestVote RPC选举领导节点。计算节点的通讯部分即Raft Agent，在系统初始化时都为候选节点Candidate状态，发起选举后将产生领导节点Leader和从属节点Follower状态，Raft Agent采用gRPC+Protobuf来实现，其中AppendEntries RPC负责心跳、日志传输,RequestVote RPC负责选举，心跳和日志传输的时候将gRPC设置为简单式，Log副本传输设置为流式以保证传输性能，其中简单式为HTTP请求，流式为TCP请求。领导节点和从属节点利用通信端口transport进行交互。

如图5所示的心跳部分系统设计举例，本系统由Java研发，gRPC服务端通过将响应消息封装成WriteQueue.AbstractQueuedCommand，异步写入WriteQueue(Acceptor)，然后调用WriteQueue的scheduleFlush操作，将响应消息发送命令放到NioEventLoop中执行，NioEventLoop调用channel.write方法将其发送到ChannelPipeline(Reactor)，由gRPC的NettyServerHandler拦截write方法，按照命令的分类进行处理，最后调用NettyHttp2ConnectionEncoder的write方法完成响应消息的发送。副本信息Log为解析规则的操作记录，当节点的解析规则与Leader的不一致，Leader将按照版本号判断是否更新自己的当前状态，更新完成后Leader将通知所有Follower节点同步最新的状态数据，从而保证分布式解析规则的一致性。此外还可以使用上述通信消息处理方式处理选举事件、心跳事件、版本同步事件等。Handler用于异步消息的处理。

本实施例可以根据所述计算节点的节点角色通过mmap内存映射的方式对所述日志解析规则进行一致性同步。分布式节点的性能瓶颈在解析规则的操作记录日志同步，RaftAgent采用mmap内存映射技术，用户对这段内存区域的修改可以直接反映到内核空间，同样，内核空间对这段区域的修改也直接反映用户空间。那么对于内核空间和用户空间两者之间需要大量数据传输等操作的话效率是非常高的，RaftAgent利用mmap实现分布式情况下节点数据传输的高效率,保证在大流量的日志流入时，保证较高的计算吞吐性能。

本实施例具有低延迟、高性能的日志数据解析能力，解决传统单机设备性能不足无法扩展的问题。本实施例未使用基于raft开发的三方分布式一致性服务(如etcd)，也未使用基于paxos开发的zookeeper。本实施例基于raft自研了分布式共识框架，和日志解析程序融合在一起，有别与etcd等使用golang语言研发的基于raft协议的分布式共识框架，本文采用java语言，大量使用nio和ractor线程模型，提高分布式通信的性能和吞吐量，保证分布式解析系统的实时性和一致性。

本申请实施例还提供的一种日志解析系统，该系统可以包括：

节点角色确定模块，用于根据Raft协议确定分布式计算平台中每一计算节点的节点角色；

规则同步模块，用于根据所述计算节点的节点角色对日志解析规则进行一致性同步，以使所有所述计算节点对应的日志解析规则相同；

日志分发模块，用于若接收到日志数据，则将所述日志数据分发至所述计算节点；其中，所述计算节点中存储有预编译的日志解析规则；

日志解析模块，用于控制所述计算节点利用所述日志解析规则对所述日志数据执行日志解析操作。

本实施例根据Raft协议为分布式计算平台中每一计算节点设置对应的节点角色，基于节点角色对日志解析规则进行一致性同步，使得各个计算节点对日志解析时使用的规则相同。在收到日志数据后，本实施例将日志分发至各个计算节点，使得各个计算节点各自处理自身接收到的日志数据，计算节点之间无需进行频繁的信息交互。计算节点中存储有预编译的日志解析规则，无需匹配所有解析规则，避免了性能资源浪费。因此，本实施例能够在保证日志解析规则一致性的前提下，降低日志解析操作的性能消耗。

进一步的，日志分发模块用于按照日志种类划分规则对所述日志数据进行划分，得到多个种类的子数据；还用于确定所述计算节点与日志种类的对应关系，并根据所述计算节点与所述日志种类的对应关系将所述子数据分发至对应的计算节点。

进一步的，还包括：

预编译模块，用于在控制所述计算节点利用所述日志解析规则对所述日志数据执行日志解析操作之前，确定每一所述计算节点对应的日志种类，根据日志种类与日志解析规则的对应关系在所述计算节点中预编译对应的日志解析规则，并将预编译结果存储至所述计算节点。

进一步的，还包括：

数据转发模块，用于将所述日志数据分发至所述计算节点之后，判断所述计算节点的业务压力是否大于预设压力；若是，则所述计算节点接收到的日志数据分配给所述计算节点的关联节点；其中，所述关联节点与所述计算节点对应的日志种类相同。

进一步的，所述节点角色包括领导节点、从属节点和候选节点；

相应的，规则同步模块用于将所述领导节点的LRU队列中存储的规则标识增量同步至所述从属节点的LRU队列；其中，规则库中每一日志解析规则均有唯一对应的规则标识，所述计算节点利用所述规则标识从所述规则库中读取日志解析规则。

进一步的，规则同步模块用于根据所述计算节点的节点角色通过mmap内存映射的方式对所述日志解析规则进行一致性同步。

进一步的，所述计算节点之间通过gRPC协议和Protobuf协议进行通讯；其中，所述计算节点通过AppendEntries RPC传输心跳信号和日志数据，所述计算节点通过RequestVote RPC选举领导节点。

由于系统部分的实施例与方法部分的实施例相互对应，因此系统部分的实施例请参见方法部分的实施例的描述，这里暂不赘述。

本申请还提供了一种存储介质，其上存有计算机程序，该计算机程序被执行时可以实现上述实施例所提供的步骤。该存储介质可以包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

本申请还提供了一种电子设备，可以包括存储器和处理器，所述存储器中存有计算机程序，所述处理器调用所述存储器中的计算机程序时，可以实现上述实施例所提供的步骤。当然所述电子设备还可以包括各种网络接口，电源等组件。

说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的系统而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。

还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的状况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims (7)

1.一种日志解析方法，其特征在于，应用于分布式计算平台，包括：

根据Raft协议确定所述分布式计算平台中每一计算节点的节点角色；

根据所述计算节点的节点角色对日志解析规则进行一致性同步，以使所有所述计算节点对应的日志解析规则相同；

若接收到日志数据，则将所述日志数据分发至所述计算节点；其中，所述计算节点中存储有预编译的日志解析规则；

控制所述计算节点利用所述日志解析规则对所述日志数据执行日志解析操作；

其中，所述节点角色包括领导节点、从属节点和候选节点；

相应的，根据所述计算节点的节点角色对日志解析规则进行一致性同步，包括：

将所述领导节点的LRU队列中存储的规则标识增量同步至所述从属节点的LRU队列；所述日志解析规则存储于规则库中，所述规则库中每一日志解析规则均有唯一对应的规则标识，所述计算节点利用所述规则标识从所述规则库中读取日志解析规则；

其中，将所述日志数据分发至所述计算节点，包括：

按照日志种类划分规则对所述日志数据进行划分，得到多个种类的子数据；

确定所述计算节点与日志种类的对应关系，并根据所述计算节点与所述日志种类的对应关系将所述子数据分发至对应的计算节点；

在控制所述计算节点利用所述日志解析规则对所述日志数据执行日志解析操作之前，还包括：

确定每一所述计算节点对应的日志种类，根据日志种类与日志解析规则的对应关系在所述计算节点中预编译对应的日志解析规则，并将预编译结果存储至所述计算节点。

2.根据权利要求1所述日志解析方法，其特征在于，将所述日志数据分发至所述计算节点之后，还包括：

判断所述计算节点的业务压力是否大于预设压力；

若是，则所述计算节点接收到的日志数据分配给所述计算节点的关联节点；其中，所述关联节点与所述计算节点对应的日志种类相同。

3.根据权利要求1所述日志解析方法，其特征在于，根据所述计算节点的节点角色对日志解析规则进行一致性同步，包括：

根据所述计算节点的节点角色通过mmap内存映射的方式对所述日志解析规则进行一致性同步。

4.根据权利要求1至3任一项所述日志解析方法，其特征在于，所述计算节点之间通过gRPC协议和Protobuf协议进行通讯；

其中，所述计算节点通过AppendEntries RPC传输心跳信号和日志数据，所述计算节点通过RequestVote RPC选举领导节点。

5.一种日志解析系统，其特征在于，包括：

节点角色确定模块，用于根据Raft协议确定分布式计算平台中每一计算节点的节点角色；

规则同步模块，用于根据所述计算节点的节点角色对日志解析规则进行一致性同步，以使所有所述计算节点对应的日志解析规则相同；所述节点角色包括领导节点、从属节点和候选节点；

日志分发模块，用于若接收到日志数据，则将所述日志数据分发至所述计算节点；其中，所述计算节点中存储有预编译的日志解析规则；

日志解析模块，用于控制所述计算节点利用所述日志解析规则对所述日志数据执行日志解析操作；

相应的，所述规则同步模块，用于将所述领导节点的LRU队列中存储的规则标识增量同步至所述从属节点的LRU队列；所述日志解析规则存储于规则库中，所述规则库中每一日志解析规则均有唯一对应的规则标识，所述计算节点利用所述规则标识从所述规则库中读取日志解析规则；

所述日志分发模块，用于按照日志种类划分规则对所述日志数据进行划分，得到多个种类的子数据；还用于确定所述计算节点与日志种类的对应关系，并根据所述计算节点与所述日志种类的对应关系将所述子数据分发至对应的计算节点；

预编译模块，用于在控制所述计算节点利用所述日志解析规则对所述日志数据执行日志解析操作之前，确定每一所述计算节点对应的日志种类，根据日志种类与日志解析规则的对应关系在所述计算节点中预编译对应的日志解析规则，并将预编译结果存储至所述计算节点。

6.一种电子设备，其特征在于，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器调用所述存储器中的计算机程序时实现如权利要求1至4任一项所述日志解析方法的步骤。

7.一种存储介质，其特征在于，所述存储介质中存储有计算机可执行指令，所述计算机可执行指令被处理器加载并执行时，实现如权利要求1至4任一项所述日志解析方法的步骤。

Images