CN115809222A - 一种日志处理方法、装置、设备以及计算机存储介质 - Google Patents

Abstract

本申请实施例公开了一种日志处理方法、装置、设备以及计算机存储介质，该方法包括：接收待处理的日志数据；按照日志类型对待处理的日志数据进行分类，得到至少一组日志数据，将至少一组日志数据对应存储在预设缓存仓库的至少一个存储目录文件中；其中，预设缓存仓库包括至少一个存储目录文件，且不同的日志类型对应不同的存储目录文件；从预设缓存仓库的至少一个存储目录文件中读取日志数据进行解析，并将解析结果写入目标数据库。这样，通过将待处理的日志数据按照日志类型进行分类后，将其对应存储到预设缓存仓库的若干个存储目录文件中，如此不仅能够实现对日志数据的统一管理以及规范存储，而且还能够提高日志处理的速度。

Description

一种日志处理方法、装置、设备以及计算机存储介质

技术领域

本申请涉及计算机数据处理技术领域，尤其涉及一种日志处理方法、装置、设备以及计算机存储介质。

背景技术

当今社会处于信息化时代，随着计算机技术的高速发展，对信息安全提出了更高的要求。各大厂商的防火墙设备广泛部署在各领域，不可避免的会产生海量的防火墙日志，这些防火墙日志对网络安全审计至关重要，如何接收和存储海量的防火墙日志，是首先需要思考和解决的问题。

目前，各厂商各防火墙设备的日志格式千差万别，SYSLOG作为主要的日志格式，广泛应用于各类网络和安全设备中，且被多数操作系统支持，已成为日志的重要标准。然而，即便是SYSLOG格式的日志，日志的类型和具体内容格式也各不相同，在对日志数据进行接收与存储时，存在日志数据量过大、日志类型不统一等现象，导致难以对日志进行统一管理及规范存储，从而降低了日志处理的速度。

发明内容

本申请提供了一种日志处理方法、装置、设备以及计算机存储介质，能够实现对日志数据的统一管理及规范存储，同时还能够提高日志处理的速度。

本申请的技术方案是这样实现的：

第一方面，本申请实施例提供了一种日志处理方法，该方法包括：

接收待处理的日志数据；

按照日志类型对待处理的日志数据进行分类，得到至少一组日志数据，将至少一组日志数据对应存储在预设缓存仓库的至少一个存储目录文件中；其中，预设缓存仓库包括至少一个存储目录文件，且不同的日志类型对应不同的存储目录文件；

从预设缓存仓库的至少一个存储目录文件中读取日志数据进行解析，并将解析结果写入目标数据库。

第二方面，本申请实施例提供了一种日志处理装置，该日志处理装置包括接收单元、存储单元以及解析单元，其中，

接收单元，配置为接收待处理的日志数据；

存储单元，配置为按照日志类型对待处理的日志数据进行分类，得到至少一组日志数据，将至少一组日志数据对应存储在预设缓存仓库的至少一个存储目录文件中；其中，预设缓存仓库包括至少一个存储目录文件，且不同的日志类型对应不同的存储目录文件；

解析单元，配置为从预设缓存仓库的至少一个存储目录文件中读取日志数据进行解析，并将解析结果写入目标数据库。

第三方面，本申请实施例提供了一种日志处理设备，该日志处理设备包括存储器和处理器，其中，

存储器，用于存储能够在处理器上运行的计算机程序；

处理器，用于在运行计算机程序时，执行如第一方面的日志处理方法。

第四方面，本申请实施例提供了一种计算机存储介质，该计算机存储介质存储有计算机程序，该计算机程序被至少一个处理器执行时实现如第一方面的日志处理方法。

本申请实施例所提供的一种日志处理方法、装置、设备以及计算机存储介质，通过接收待处理的日志数据；按照日志类型对待处理的日志数据进行分类，得到至少一组日志数据，将至少一组日志数据对应存储在预设缓存仓库的至少一个存储目录文件中；其中，预设缓存仓库包括至少一个存储目录文件，且不同的日志类型对应不同的存储目录文件；从预设缓存仓库的至少一个存储目录文件中读取日志数据进行解析，并将解析结果写入目标数据库。这样，在将待处理的日志数据按照日志类型进行分类后，将其对应存储到预设缓存仓库的若干个存储目录文件中，不仅实现了对待处理的日志数据按照其类型进行统一管理，而且还实现了日志数据在存储目录文件中的规范存储；同时还使得在对日志数据进行解析时，可以按照存储目录文件对其中的日志数据进行并行解析，进而还能够提高日志处理的速度。

附图说明

图1为本申请实施例提供的一种日志处理方法的流程示意图；

图2为本申请实施例提供的另一种日志处理方法的流程示意图；

图3为本申请实施例提供的一种日志处理方法的应用框架示意图；

图4为本申请实施例提供的一种日志处理装置的组成结构示意图；

图5为本申请实施例提供的另一种日志处理装置的组成结构示意图；

图6为本申请实施例提供的一种日志处理设备的具体硬件结构示意图；

图7为本申请实施例提供的另一种日志处理设备的组成结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。可以理解的是，此处所描述的具体实施例仅用于解释相关申请，而非对该申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与有关申请相关的部分。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

还需要指出，本申请实施例所涉及的术语“第一\第二\第三”仅是用于区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

在相关技术中，如何接收和存储海量的防火墙日志，是首先需要思考和解决的问题；而不同厂商的不同防火墙设备的日志格式千差万别，如何对各种防火墙日志数据进行统一解析入库也是要解决的重要问题。SYSLOG作为主要的日志类型，广泛应用于各类网络和安全设备中，且被多数操作系统支持，现已成为日志的重要标准，只要防火墙日志满足SYSLOG格式标准，便可统一接收处理。以SYSLOG日志为例，该日志格式如下(具体可以参考RFC3164，其定义了关于SYSLOG格式标准以及在网络中传输的各种规则)所示：

<PRI>HEADER MSG

这里，<PRI>表示优先级(Priority)，由程序模块(Facility)和严重性(Severity)组合而成。具体地，PRI＝Facility×8+Severity值。其中，Severity可分为8种不同的日志级别，分别为：0，Emergency；1，Alert；2，Critical；3，Error；4，Warning；5，Notice；6，Informational；7，Debug。

另外，HEADER可以包含时间戳TIMESTAMP和主机名HOSTNAME。如果主机名为空或者无法识别，那么会显示网际互联协议(Internet Protocol，IP)地址。MSG可以包含产生信息进程的额外信息以及信息的文本部分。其中，MSG部分又可以分为TAG和Content两部分，这里的Content部分即为日志内容部分。

目前，行业内对海量防火墙日志的接收和存储主要集中在软件上的优化，很少涉及到软件和硬件的整体优化，而且相关技术在对日志数据进行接收和存储时，仍存在较多不足之处。例如：(1)相关技术中，一般采用单一线程(或进程)监听用户数据报协议(UserDatagram Protocol，UDP)的514端口，来实现日志接收工作，即接收日志时都是通过单一网卡来完成数据传输的，当日志接收峰值过大时，单一网卡很容易形成日志接收瓶颈。(2)相关技术中，在进行SYSLOG日志的接收时，一般都需要先将日志数据进行归一化处理，然后再存储，这样不利于防火墙日志内容格式的动态新增，不能很好地实现动态添加、即插即用。(3)相关技术中，在进行日志接收时，日志接收模块一般都会将日志数据先写入到本地文件，然后再解析入库，但是将日志写入到本地文件后，缺少对本地日志文件的统一管理，例如日志文件如何分类、日志文件大小控制、日志文件数量控制、日志堆积如何处理等。

基于此，本申请实施例提供了一种日志处理方法，该方法的基本思想是：接收待处理的日志数据；按照日志类型对待处理的日志数据进行分类，得到至少一组日志数据，将至少一组日志数据对应存储在预设缓存仓库的至少一个存储目录文件中；其中，预设缓存仓库包括至少一个存储目录文件，且不同的日志类型对应不同的存储目录文件；从预设缓存仓库的至少一个存储目录文件中读取日志数据进行解析，并将解析结果写入目标数据库。这样，将待处理的日志数据按照日志类型进行分类后对应存储到预设缓存仓库的若干个存储目录文件中，不仅实现了对待处理的日志数据按照其类型进行统一管理，而且还实现了日志数据在存储目录文件中的规范存储；同时还使得在对日志数据进行解析时，可以按照存储目录文件对其中的日志数据进行并行解析，进而还能够提高日志处理的速度。

下面将结合附图对本申请各实施例进行详细说明。

本申请的一实施例中，参见图1，其示出了本申请实施例提供的一种日志处理方法的流程示意图。如图1所示，该方法可以包括：

S101、接收待处理的日志数据。

需要说明的是，本申请实施例提供的日志处理方法可以应用于日志处理装置，或者集成有该日志处理装置的日志处理设备。这里，日志处理设备可以是各种网络设备、安全设备、防火墙设备等，诸如可以是计算机、智能手机、平板电脑、笔记本电脑、掌上电脑、个人数字助理(Personal Digital Assistant，PDA)、导航装置、服务器等等，本申请实施例对此不作具体限定。

还需要说明的是，SYSLOG日志作为目前主要的日志类型，虽然只要防火墙日志格式满足SYSLOG格式标准，便可统一接收处理。然而，即使日志格式满足SYSLOG格式标准，但是各日志数据的具体类型以及内容格式也是存在各种差异的，在实际接收、存储以及解析时，仍然存在一些问题。因此，本申请实施例提供一种日志处理方法，仍以SYSLOG日志为例，对日志数据的接收、存储以及解析过程进行改进。

在待处理的日志数据的接收过程中，当日志接收峰值过大时，为了解决单一网卡很容易成为日志接收瓶颈的问题，本申请实施例可以通过多个物理网卡监听不同的UDP端口来实现多进程并发接收待处理的日志数据，以提高日志接收的效率。因此，在一些实施例中，所述接收待处理的日志数据，可以包括：

通过至少两个物理网卡监听至少两个UDP端口；

将从至少两个UDP端口获取到的日志数据确定为待处理的日志数据；其中，每一个物理网卡对应监听一个UDP端口，且从至少两个UDP端口获取日志数据的过程并发执行。

需要说明的是，本申请实施例通过至少两个物理网卡对至少两个UDP端口进行监听，并将从这至少两个UDP端口获取到的日志数据确定为待处理的日志数据。其中，从UDP端口获取到的日志数据可以是防火墙发送的SYSLOG日志。且每一个物理网卡可以对UDP端口进行对应监听，通过多个物理网卡监听多个UDP端口以获取日志数据的过程可以并发执行。

这样，由于采用了多个物理网卡对多个UDP端口进行监听，实现了多进程并发接收待处理的日志数据，即使接收的日志数据的峰值较大，也能够实现顺利接收日志数据，避免形成日志接收瓶颈。

S102、按照日志类型对待处理的日志数据进行分类，得到至少一组日志数据，将至少一组日志数据对应存储在预设缓存仓库的至少一个存储目录文件中。

在本申请实施例中，预设缓存仓库可以包括至少一个存储目录文件，且不同的日志类型对应不同的存储目录文件。

需要说明的是，在接收到待处理的日志数据之后，可以根据待处理的日志数据的日志类型，对待处理的日志数据进行分类，从而能够得到至少一组日志数据，然后将这至少一组日志数据对应存储到预设缓存仓库的至少一个存储目录文件中。这里，每一组日志数据属于一种日志类型，即不同日志类型的一组日志数据是对应存储在一个存储目录文件中。

也就是说，在本申请实施例中，存储目录文件是与日志数据的日志类型相对应的，在预设缓存仓库中，一个存储目录文件对应存储一种日志类型的日志数据。示例性地，假设待处理的日志数据的日志类型为Session日志，那么就将该日志数据存储到预设缓存仓库中与Session日志相对应的存储目录文件中，从而实现对日志数据的规范存储。

还需要说明的是，在实际业务场景中，待处理的日志数据的日志类型有可能与已有的存储目录文件均不对应，即对于已有的存储目录文件而言，出现了新的日志类型，此时，可以新建一个存储目录文件，用于对应存储新的日志类型的日志数据。因此，在一些实施例中，该方法还可以包括：

当待处理的日志数据的日志类型为新的日志类型时，在预设缓存仓库中建立与新的日志类型相对应的存储目录文件。

这样，将待处理的日志数据按照其日志类型在预设缓存仓库的存储目录文件中对应存储，而且还针对新的日志类型建立对应的存储目录文件，从而实现了对日志数据的统一管理，还能够动态更新预设缓存仓库的存储目录文件。

可以理解，由于本申请实施例可以通过多个物理网卡监听多个UDP端口来并发执行接收待处理的日志数据的过程，这样，可能会同时接收到大量日志数据，同时将大量日志数据存储到预设缓存仓库并进行处理可能会造成中央处理器(Central Processing Unit，CPU)负担过重。因此，为了避免同时处理大量任务造成CPU负担过重，或者CPU目前的资源无法支撑同时处理这么多数据，这时候，可以先将待处理的日志数据存储到至少一个预设队列中，然后在CPU较为空闲时再将待处理的日志数据传输到预设缓存仓库，再执行按照日志类型对待处理的日志数据进行分类，并将所得到的至少一组日志数据对应存储在预设缓存仓库的至少一个存储目录文件的步骤。

因此，在一些实施例中，在接收待处理的日志数据之后，该方法还可以包括：

将待处理的日志数据存储到至少一个预设队列；

根据至少一个发送线程从至少一个预设队列中读取日志数据并发送到预设缓存仓库；其中，每一个预设队列对应一个发送线程，且至少一个发送线程并发执行；

相应地，所述按照日志类型对待处理的日志数据进行分类，得到至少一组日志数据，将至少一组日志数据对应存储在预设缓存仓库的至少一个存储目录文件中，可以包括：

在预设缓存仓库接收到待处理的日志数据后，按照日志类型对待处理的日志数据进行分类，得到至少一组日志数据；

将至少一组日志数据对应存储在至少一个存储目录文件中。

需要说明的是，在将待处理的日志数据存储到至少一个预设队列之后，从预设队列中读取日志数据发送给预设缓存仓库时，可以通过发送线程从预设队列中读取日志数据发送到预设缓存仓库中，然后预设缓存仓库在收到待处理的日志数据之后，按照日志类型将其分为至少一组日志数据，并将至少一组日志数据对应存储在至少一个存储目录文件中。

这里，预设队列和发送线程的数量均为至少一个，且至少一个发送线程和至少一个预设队列的数量可以是一致的，在从预设队列中读取日志数据发送到预设缓存仓库中时，至少一个发送线程可以并发执行。例如：若存在2个预设队列，则发送线程的数量也是2个；若存在3个预设队列，则发送线程的数量也是3个。这样，通过并发执行多个发送线程从多个预设队列中将待处理的日志数据取出并发送到预设缓存仓库，能够提高日志传输的效率。

还需要说明的是，预设队列的数量可以根据CPU负载状态动态确定和/或根据自定义数值进行设置。具体来说，根据当前的CPU负载状态可以确定当前的CPU资源所能够支撑的预设队列的数量，这里，将当前的CPU资源所能够支撑的预设队列的数量称作第一数量值；自定义数值则是预先写入代码中的一个预设值，可以为日志管理人员结合实际需求、代码状态等信息自定义的一个期望参考值。

在一种示例中，根据CPU负载状态动态确定预设队列的数量，可以是根据CPU的资源使用率来确定，或者也可以根据是CPU核数来确定。具体来说，如果CPU的资源使用率较低或者CPU核数较大，即当前资源充足，那么就可以设置较多数量的预设队列；如果CPU的资源使用率较高或者CPU核数较小，即当前资源不足，那么就可以设置较少数量的预设队列。这里的多或少是相对而言的，具体预设队列的数量是根据CPU所能够提供的资源来确定。

在另一种示例中，根据自定义数值确定预设队列的数量，可以是直接在代码中写入预设的自定义数值，并将该自定义数值确定为预设队列的数量。

除此之外，本申请实施例还存在这样一种情况，当前的CPU资源并不足以支撑自定义数值数量的预设队列，或者虽然当前的CPU资源能够支撑较多数量(大于自定义数值)的预设队列，但是实际并不需要使用这么多数量的预设队列。因此，在又一种示例中，还可以根据CPU负载状态和自定义数值相结合以动态确定预设队列的数量。具体实现方式如下：

将第一数量值与自定义数值进行比较；

若第一数量值小于自定义数值，则将第一数量值确定为预设队列的数量；

若第一数量值大于或者等于自定义数值，则将自定义数值确定为预设队列的数量。

示例性地，假设在代码中预设的自定义数值为5，如果此时CPU资源充足，能够支撑8～10个预设队列，但是预先设置的预设队列的数量的自定义数值为5，那么就只会分配5个预设队列用以缓存待处理的日志数据；如果此时CPU资源不足，最多只能够支撑3个预设队列，而无法支撑5个预设队列，那么虽然自定义数值为5，但是由于CPU资源不足，此时就根据CPU的实际资源状况，分配3个预设队列。也就是说，在这种方式中，自定义数值可以看作对预设队列的数量的指导值，通过CPU负载状态和自定义数值相结合动态确定预设队列的数量，使得在CPU资源足够支撑的同时，满足数据传输效率。

还需要说明的是，由于需要在预设队列中存储大量待处理的日志数据，对于如何将日志数据存储到多个预设队列中，需要设置一定的分配方式。

在一些实施例中，所述将待处理的日志数据存储到至少一个预设队列，可以包括：

将待处理的日志数据按照预设分配方式对应存储到至少一个预设队列；

其中，预设分配方式至少包括下述其中一项：随机分配方式、轮询分配方式和一致性哈希算法分配方式。

需要说明的是，在将大量待处理的日志数据存储到多个预设队列时，可以存在多种分配方式。优选地，本申请实施例可以采用随机分配方式、轮询分配方式或者一致性哈希算法分配方式中的一种或者多种分配方式将待处理的日志数据存储到若干个预设队列中，当然也可以采用其它分配方式，本申请实施例对此不作具体限定。

其中，随机分配可以是将待处理的日志数据随机地分配存储到至少一个预设队列中，或者是结合一定的优先级算法等进行随机分配。轮询分配方式可以是按照请求时间顺序进行分配，即可以按照时间顺序将待处理的日志数据分配存储到至少一个预设队列中，如果一个预设队列满了，则可以将待处理的日志数据分配到另一个预设队列中。一致性哈希算法通过将整个哈希值空间映射成一个虚拟的圆环，哈希空间按顺时针方向组织，能够解决经典的负载均衡问题，在本申请实施例中，通过一致性哈希算法分配方式可以将待处理的日志数据均衡地分配存储到至少一个预设队列中。

S103、从预设缓存仓库的至少一个存储目录文件中读取日志数据进行解析，并将解析结果写入目标数据库。

需要说明的是，本申请实施例还需要对待处理的日志数据进行解析入库，即从存储目录文件中读取日志数据进行解析，在得到解析结果之后，将解析结果写入目标数据库。这里，目标数据库可以是一个数据库，也可以是一个文件系统，或者是任何用户或者操作系统指定的存储位置，可以根据用户需求自定义设置，本申请实施例对此不作具体限定。

在一些实施例中，所述从预设缓存仓库的至少一个存储目录文件中读取日志数据进行解析，可以包括：通过至少一个解析线程从至少一个存储目录文件中分别读取待解析的目标日志数据并对目标日志数据进行解析；其中，每一个解析线程对应一个存储目录文件，且至少一个解析线程并发执行；

当目标日志数据中的字段为公有字段时，通过正则表达式对公有字段进行解析，得到公有字段的解析结果；

当目标日志数据中的字段为私有字段时，通过预设配置规则对私有字段进行解析，得到私有字段的解析结果；

根据公有字段的解析结果和私有字段的解析结果得到目标日志数据的解析结果。

需要说明的是，即便是满足SYSLOG格式标准的日志数据，日志数据的具体类型和内容格式也各不相同，对于日志数据中自定义日志内容等数据，相关技术难以对其做到完整且准确的解析。

这里，对日志数据进行解析时，可以为每个存储目录文件分配一个解析线程。这样，每一个解析线程对应解析一个存储目录文件中的日志数据，将被解析的日志数据称为目标日志数据，可以通过多个解析线程并发执行对存储目录文件中的日志数据进行解析并将解析结果写入目标数据库的过程，有效提高对日志数据进行解析的效率。

具体地，每个解析线程都逐条从存储目录文件中读取目标日志数据并进行解析，目标日志数据中被解析的各字段可以分为公有字段和私有字段。其中，符合SYSLOG格式标准的字段为公有字段，可以利用正则表达式对公有字段进行匹配，从而得到公有字段的解析结果；而不符合SYSLOG格式标准的字段为私有字段，对于私有字段，就需要通过预设配置规则来对其进行解析。

也就是说，日志数据中的内容可以包括公有字段和私有字段，针对公有字段和私有字段分别采用不同的解析方式进行解析，得到各自对应的解析结果，然后根据公有字段的解析结果和私有字段的解析结果得到目标日志数据的解析结果。本申请实施例可以将公有字段和私有字段的解析结果按照字段在日志数据中的顺序进行组合后作为该日志数据的解析结果，或者也可以结合实际需求对公有字段和私有字段的解析结果进行组合或者相关处理，得到日志数据的解析结果。

例如，以前述的SYSLOG格式标准为例，HEADER中的TIMESTAMP和HOSTNAME即为SYSLOG格式标准的公有字段，通过正则表达式可以直接匹配得到目标日志数据的时间戳和主机名。

而对于日志数据中不符合SYSLOG格式标准的私有字段，则需要根据预设配置规则对其进行解析。示例性地，在通过预设配置规则对私有字段进行解析时，可以是通过日志数据中的自定义配置项来对日志内容中的私有字段进行解析，代码可以对自定义配置项的身份标识号(Identity Document，ID)进行识别，该ID信息可以为一个八位的十六进制数，在其之后配置了用于解析日志内容的私有字段的模板信息，也就是说自定义配置项提供了用于解析日志内容的模板信息，根据该模板信息就可以对日志内容进行解析。例如，自定义配置项中可以包括日志类型、日志级别、设备厂商信息、系统模块等配置项。

除此之外，当待处理的日志数据中存在新的日志格式的情况下，为了解决相关技术不利于防火墙日志格式的动态新增的问题，在一些实施例中，该方法还可以包括：

在接收待处理的日志数据的过程中，若接收到的日志数据为新的日志格式，则设置新的配置项，并将新的配置项增加到预设配置规则中；其中，新的配置项用于实现对新的日志格式的日志数据的正确解析。

需要说明的是，在接收待处理的日志数据的过程中，如果出现了新的日志格式，意味着已有的预设配置规则就无法对新的日志格式进行解析。这时候，可以设置新的配置项，并将新的配置项增加到预设配置规则中，从而对新的日志格式也能够做到正确解析。

其中，新的日志格式的日志数据通常包括私有字段，由于私有字段通常不符合SYSLOG标准，如果出现了新的，那么已有的预设配置规则中的配置项就无法对其正确解析，需要添加新的配置项用于对新的日志格式进行对应解析。例如，新的配置项可以是对应新的日志格式的模板信息，将其加入预设配置规则中，实现了对预设配置规则的更新，这样，不仅本次可以对新的日志格式的日志数据进行正确解析，在之后的日志处理过程中，如果再出现该格式的日志数据，就可以直接通过预设配置规则正确解析。

也就是说，本申请实施例可以通过配置项实现对日志数据的正确解析，在预设配置规则中包括有多种配置项，其当出现新的日志格式时，就可以利用新的配置项更新预设配置规则；而且由于通过新增加配置项，而非是对日志数据进行归一化处理，还有利于实现防火墙日志格式的动态新增。

示例性地，新的配置项可以采用LogID配置项。其中，LogID配置项可以包括以下部分：(1)日志类型(type)，如Session日志、Thread日志、IM日志、URL日志等；(2)日志级别(Severity)，8种级别；(3)设备厂商信息；(4)系统模块(module)。

这样，在出现新的日志格式时，通过增加新的配置项到预设配置规则中，就可以对日志数据正确解析，实现了动态添加，即插即用。

进一步地，在本申请实施例中，还可以对预设缓存仓库的健康状态进行监控，以保证在对日志数据进行处理的过程中，预设缓存仓库不会出现问题。

在一些实施例中，该方法还可以包括：

判断预设缓存仓库是否存在日志堆积；

若预设缓存仓库存在日志堆积，则根据预设清理策略对预设缓存仓库进行日志堆积处理；

其中，预设清理策略至少包括下述其中一项：删除日志级别最低的日志数据、删除最早接收的日志数据、抛弃最新接收的日志数据和删除预设日志类型的日志数据。

需要说明的是，将日志数据存入预设缓存仓库和从预设缓存仓库中读取日志数据并进行解析是一个动态的过程。在这个过程中，有可能由于未及时对预设缓存仓库中的日志数据进行读取解析等原因导致预设缓存仓库产生日志堆积，这时候，就需要对堆积的日志数据进行一定处理。

具体来说，可以为预设缓存仓库建立一个守护进程，该守护进程会对预设缓存仓库的健康状态进行监控和管理。当确定预设缓存仓库中存在日志堆积时，守护进程会根据预设清理策略进行日志堆积处理。这里，预设清理策略可以包括下述中的一项或者多项：删除日志级别最低的日志数据、删除最早接收的日志数据、抛弃最近接收的日志数据和删除预设日志类型的日志数据。当然，守护进程也可以根据其它方式对预设缓存仓库进行日志堆积处理，并不限于此处所列举的，本申请实施例对此不作具体限定。

在一些实施例中，所述判断预设缓存仓库是否存在日志堆积，可以包括：

确定将待处理的日志数据存储到预设缓存仓库的第一速度和从预设缓存仓库中读取日志数据并解析写入目标数据库的第二速度；

若第二速度小于第一速度，则确定预设缓存仓库存在日志堆积；

若第二速度大于或等于第一速度，则确定预设缓存仓库不存在日志堆积。

需要说明的是，第一速度代表将日志数据存储到预设缓存仓库时的日志数据产生速度，第二速度则代表从预设缓存仓库中读取日志数据并解析入库时的入库速度。

如果第二速度小于第一速度，即对于预设缓存仓库而言，从其中读取日志数据并解析的速度小于向其中存储日志数据的速度，相当于预设缓存仓库中的日志数据总量在增加，那么此时就有可能导致预设缓存仓库产生日志堆积。

如果第二速度大于或等于第一速度，即对于预设缓存仓库而言，从其中读取日志数据的速度大于或等于向其中存储日志数据的速度，相当于预设缓存仓库中的日志数据总量在减少或者不变，那么此时预设缓存仓库不会产生日志堆积。

还需要说明的是，本申请实施例还可能存在这种情况，虽然第二速度小于第一速度，但是此时预设缓存仓库的空间使用率还很低。例如，此时仅有10％的预设缓存仓库的空间被占用，那么虽然预设缓存仓库中日志数据的总量在增加，但是由于预设缓存仓库空间仍旧充足，并不一定会导致日志堆积。因此，这时候需要设置一个空间使用率阈值，在一些实施例中，该方法还可以包括：在满足第二速度小于第一速度且预设缓存仓库的空间使用率大于空间使用率阈值的情况下，确定预设缓存仓库存在日志堆积。示例性地，空间使用率阈值可以为70％、80％、90％等数值，本申请实施例对此不作具体限定。

进一步地，在一些实施例中，该方法还可以包括：

当预设缓存仓库存在异常时，生成相应的异常告警信息；其中，异常告警信息包括：空间不足告警信息，和/或，日志堆积告警信息。

需要说明的是，还可以通过前述的守护进程对预设缓存仓库的日志堆积、空间使用状态等进行监控，确定预设缓存仓库是否存在异常，如果存在异常就生成异常告警信息。这里，异常告警信息可以包括空间不足告警信息、日志堆积告警信息等的一个或者多个。

这里，预设缓存仓库存在异常可以包括：预设缓存仓库的空间使用率已超过空间使用率阈值，或者预设缓存仓库中已产生日志堆积等情况。

示例性地，如果空间使用率大于空间使用率阈值，就生成空间不足告警信息，并进行空间不足告警；如果是因为第二速度小于第一速度导致可能会产生日志堆积，就生成日志堆积告警信息，并进行日志堆积告警；如果空间不足且日志堆积，就生成空间不足告警信息和日志堆积告警信息，并进行告警。

这样，通过对预设缓存仓库的健康状态进行监控，从而能够对日志堆积进行及时处理，并在预设缓存仓库存在异常时进行及时告警。

本实施例提供了一种日志处理方法，通过接收待处理的日志数据；按照日志类型对待处理的日志数据进行分类，得到至少一组日志数据，将至少一组日志数据对应存储在预设缓存仓库的至少一个存储目录文件中；其中，预设缓存仓库包括至少一个存储目录文件，且不同的日志类型对应不同的存储目录文件；对至少一个存储目录文件中的日志数据进行解析，并将解析结果写入目标数据库。这样，在将待处理的日志数据按照日志类型进行分类后，将其对应存储到预设缓存仓库的若干个存储目录文件中，不仅实现了对待处理的日志数据按照其类型进行统一管理，而且还实现了日志数据在存储目录文件中的规范存储；同时还使得在对日志数据进行解析时，可以按照存储目录文件对其中的日志数据进行并行解析，进而还能够提高日志处理的速度；另外，在接收日志数据时，通过多网卡监听多端口实现多进程接收待处理的日志数据，提高了日志数据的接收效率；在将日志数据从若干个预设队列传输到预设缓存仓库时，每个预设队列对应一个发送线程，通过若干个发送线程并发从预设队列中读取日志数据再发送给预设缓存仓库，提高了日志数据的传输效率；在对日志数据进行解析时，每个存储目录文件对应一个解析线程，通过若干个解析线程并发执行日志数据的解析，同时可以通过预设配置规则对日志内容进行准确解析，即使出现了新的日志格式，也只需要在配置文件中新增一条配置项即可对日志内容进行准确解析，提高了日志数据的解析效率并实现了日志格式的动态新增；同时，还对预设缓存仓库的健康状态进行监控，及时对日志堆积进行有效处理，并在存在异常时进行相应告警，避免了由于异常导致日志数据丢失、出错等问题。

本申请的另一实施例中，参见图2，其示出了本申请实施例提供的另一种日志处理方法的流程示意图。如图2所示，该方法可以包括：

S201、并发运行多个日志接收进程，将接收到的SYSLOG日志缓存到至少一个预设队列。

需要说明的是，本申请实施例仍以SYSLOG日志为例，即本申请实施例所涉及到的日志数据等均可以指SYSLOG日志。这里，并发运行多个日志接收进程，通过多个物理网卡分别监听不同的UDP端口来接收防火墙发送的SYSLOG日志，并将接收的SYSLOG日志缓存到至少一个预设队列(也称为缓存队列)。优选地，预设队列的数量可以为多个。

具体地，通过多个物理网卡监听不同的UDP端口时，由于数据包中带有网际互联协议(Internet Protocol，IP)信息，通过IP信息，就可以知道接收的数据来源于哪个设备以及对应的端口。这样，一个物理网卡就可以对应监听某一端口以接收对应设备SYSLOG日志，只要端口未被其它节点占用，就可以通过物理网卡对其进行监听，例如UDP的514、515以及更多端口，实现了多进程并发接收SYSLOG日志。

在接收SYSLOG日志之后，需要将SYSLOG日志先存储到至少一个预设队列中，预设队列个数的设定可以根据CPU核数动态确定或者自定义数值进行设置。

具体来说，对于每一个监听UDP端口获取SYSLOG日志的进程，都可以控制其线程的数量，线程数量与预设队列的数量一致。在本申请实施例中，自定义数值是一个写入代码中的值，相当于一个期望参考值，可以是日志管理人员根据实际需求或者设备配置设置的一个具体值，自定义数值对执行SYSLOG日志的接收与存储过程中分配的预设队列的实际数量具有一定的指导作用。在接收与存储SYSLOG日志的过程中，可以实时地获取当前的CPU负载状态并结合自定义数值对预设队列的个数进行动态确定，具体来说，如果当前的CPU负载过高或者CPU核数本身就很小，即当前CPU资源不足，不足以支撑较多数量的预设队列(CPU当前能够支撑的预设队列的数量小于自定义数值)，那么就根据当前的CPU状态确定预设队列的数量；如果当前CPU负载较低或者CPU核数较多，即当前CPU资源充足，能够支撑的预设队列的数量大于或者等于自定义数值，那么就确定预设队列的数量为自定义数值。

还需要说明的是，在将SYSLOG日志存储到预设队列中时，可以采用随机分配方式、轮询分配方式或一致性哈希算法分配方式等将日志数据分配到不同的预设队列中，本申请实施例对此不作具体限定。

S202、并发运行至少一个发送线程，将SYSLOG日志从至少一个预设队列传输到预设缓存仓库。

需要说明的是，在本申请实施例中，预设队列相当于对SYSLOG日志进行临时存储的区域，将SYSLOG日志存储到预设队列之后，如果CPU需要执行的任务过多，则只会在CPU空闲时才将SYSLOG日志从预设队列中取出。这样，通过预设队列保障SYSLOG日志不会丢失，且可以在CPU空闲时再从预设队列中将SYSLOG日志进行取出，保证了CPU的工作效率。

在将SYSLOG日志从预设队列中取出然后发送到预设缓存仓库(也可以称为日志文件缓存仓库)中时，每一个预设队列都对应有一个发送线程(也可以称为日志发送线程)，每一个发送线程从对应的预设队列中取出SYSLOG日志后发送到预设缓存仓库，并且多个发送线程可以并发运行。

S203、在预设缓存仓库中，对SYSLOG日志按照日志类型进行分类，对应存储到至少一个存储目录文件中。

预设缓存仓库在接收SYSLOG日志时，会按照日志类型将SYSLOG日志进行分类，然后分别存储到不同的存储目录文件中。每种日志类型都对应有一个存储目录文件(也可以称为存储目录)，当有新的日志类型时，就新建一个存储目录文件用来存储新的日志类型的SYSLOG日志。

这里，日志类型可以是预设配置规则中配置的日志类型(type)，例如，日志类型可以为Session日志、Thread日志、IM日志或者URL日志等，对于每种日志类型，都对应有一个存储目录文件。

S204、并发运行至少一个日志解析入库线程，将解析结果写入目标数据库。

需要说明的是，可以通过日志解析入库线程(即前述实施例中的解析线程)监听预设缓存仓库中是否有日志文件，当预设缓存仓库中存在日志文件时，就会对预设缓存仓库中的日志文件进行解析并写入目标数据库，即“日志解析入库”，这里的“库”即目标数据库，目标数据库可以是一个文件系统或者数据库等等，在实际中需要结合用户的需求，将解析结果写入对应的目标数据库，本申请实施例对此不作具体限定。

在进行日志解析并将解析结果写入目标数据库时时，对于每种日志类型即每个存储目录文件都分配一个解析线程(也可以称为日志解析入库线程)，同时多个解析线程可以对多个存储目录文件中的SYSLOG日志并发进行解析入库。

具体地，每个解析线程从对应的存储目录文件中逐条读取SYSLOG日志进行处理，对于公有字段的解析，可使用正则表达式进行匹配；而对于私有字段的解析，则根据预设配置规则中的配置项对私有字段进行解析，在本申请实施例中，配置项可以采用LogID配置项，其可以提供日志内容模板对私有字段进行解析。这里，公有字段可以是在SYSLOG格式标准的范围之内的字段，而私有字段则是在SYSLOG格式标准的范围之外的需要通过LogID配置项进行解析的字段。

示例性地，以下为一个带有LogID配置项的SYSLOG日志的示例：

<PRI>TIMESTAMP HOSTNAME LOGID:CONTENT

其中，PRI表示优先级；TIMESTAMP表示时间戳；HOSTNAME表示主机名；LogID为具体方案中的预设配置规则中自定义的配置项，本申请实施例通过LogID配置项来解析日志内容；Content为日志内容。

在本申请实施例中，通过预设配置规则中的配置项例如LogID配置项来区分不同的防火墙日志，不同的防火墙日志内容格式对应不同的LogID配置项，其ID为8位16进制数。

示例性地，LogID配置项可以包括以下部分：(1)日志类型(type)，如Session日志、Thread日志、IM日志、URL日志等；(2)日志级别(Severity)，8种级别；(3)设备厂商信息；(4)系统模块(module)。

LogID配置项的示例如下(其中，module未示出)：

这样，通过LogID配置项就可以对日志内容进行准确解析。如果有新的日志格式(也称为日志内容格式，即日志的具体内容格式)的SYSLOG日志出现，只需要在预设配置规则中新增一条LogID配置项来更新日志格式，即可以对SYSLOG日志的内容进行正确解析。

在对日志文件进行解析之后，就可以将解析得到的数据写入目标数据库，完成对SYSLOG日志的接收存储以及解析入库。

S204、建立守护进程，监视预设缓存仓库的健康状态。

需要说明的是，本申请实施例还为预设缓存仓库建立了守护进程(也称为缓存仓库守护进程)，用以监视预设缓存仓库的健康状态，在预设缓存仓库健康状态异常时，进行相应的处理或告警。

具体地，当对SYSLOG日志进行解析并将解析结果写入目标数据库的速度小于预设缓存仓库接收SYSLOG日志的速度时，可能会导致预设缓存仓库中的日志堆积，此时需要进行日志堆积处理。示例性地，日志堆积处理可以为：删除日志级别最低的SYSLOG日志、删除最早接收的SYSLOG日志、抛弃最新接收的SYSLOG日志、删除某种日志类型的SYSLOG日志等处理策略。

同时，当预设缓存仓库异常时，需要产生相应的告警。例如：空间不足告警(如磁盘空间不足告警)、日志堆积告警等。需要注意的是，虽然空间不足可能是由于日志堆积导致的，但是空间不足告警与日志堆积告警并不相同。

示例性地，假设磁盘空间使用达到80％以上时，视为磁盘空间不足，此时会进行磁盘空间不足告警；但是，如果此时虽然磁盘空间不足，但是由于此时并没有新的SYSLOG日志被发送到预设缓存仓库中，那么预设缓存仓库中原本堆积的日志文件会随着SYSLOG日志被读取解析而慢慢减少，或者此时对SYSLOG日志进行解析并写入目标数据库的速度是大于预设缓存仓库接收SYSLOG日志的速度的，那么此时并不会产生日志堆积；而如果对SYSLOG日志进行解析并写入目标数据库的速度小于预设缓存仓库接收SYSLOG日志的速度，且这种清理持续未缓解，那么此时已经产生了日志堆积，就需要进行相应的日志堆积告警。

基于上述的日志处理方法，参见图3，其示出了本申请实施例提供的一种日志处理方法的应用框架示意图。如图3所示，该应用框架可以包括以下部分：日志接收部分301；预设队列处理部分302；缓存仓库处理部分303；日志解析入库部分304；缓存仓库守护部分305。各部分的功能如下：

日志接收部分301用于实现日志接收过程，可以包括多个日志接收进程，具体可以为：通过多个物理网卡监听不同的UDP端口来接收防火墙发送的日志数据并将接收的日志数据存储到多个不同的预设队列中。预设队列个数的设定，可以根据CPU核数动态确定或自定义数值进行设置。可以采用随机分配、轮询分配或一致性哈希算法分配等分配策略将日志数据分配到不同的预设队列。

预设队列处理部分302用于实现将日志数据从预设队列发送到预设缓存仓库，可以包括多个发送线程，即每个预设队列对应一个发送线程，该发送线程从预设队列中取出日志数据并发送到预设缓存仓库，多个发送线程并发执行。

缓存仓库处理部分303用于实现接收预设队列发送的日志数据并按日志类型存储到不同的存储目录文件中，即预设缓存仓库负责接收预设队列发送的日志数据，并将日志数据按照日志类型分类，分别存储到不同的存储目录文件中，每种日志类型对应一个存储目录文件。

日志解析入库部分304用于实现对日志数据进行解析并写入目标数据库，可以包括一个日志解析入库进程，其中，一个日志解析入库进程可以包括至少一个解析线程。具体可以为：通过日志解析入库进程监听预设缓存仓库是否有日志文件，如果监听到预设缓存仓库中有日志文件，则进行日志解析入库；可以为每种日志类型对应分配一个解析线程，并对多个存储目录文件进行并发解析入库。具体可以为：从预设缓存仓库的存储目录文件中逐条读取日志数据并进行处理；对于日志数据中公有字段的解析，可使用正则表达式进行匹配，对于日志数据中私有字段的解析，则需要根据LogID提供的日志内容模板进行解析。

缓存仓库守护部分305用于实现对预设缓存仓库健康状态的监视，可以为预设缓存仓库建立缓存仓库守护进程，负责监视缓存仓库的健康状态，并进行必要的日志堆积处理、告警处理等。具体可以为：当对日志数据进行解析并写入目标数据库的速度小于将日志数据存入预设缓存仓库的速度而导致日志堆积时，需要做日志堆积处理，有多种不同的策略可供选择，如删除日志级别最低的日志数据、删除最早接收的日志数据、抛弃最新接收的日志数据、删除某种日志类型的日志数据等；当缓存仓库有异常时，需要产生相应的告警，如磁盘空间不足告警、日志堆积告警等。

也就是说，本申请实施例提供了一种日志处理方法，通过多个物理网卡监听不同的UDP端口，并发运行多个日志接收进程，来解决日志接收峰值过大时单一网卡的性能瓶颈，进而加快日志接收速率；同时，当有新的日志格式时，只需在配置文件中新增一条LogID配置项来设置新日志内容格式，日志数据便可正确解析，做到了动态添加、即插即用；并将接收的日志数据首先存入到预设缓存仓库，该预设缓存仓库有一个专门的守护进程，负责预设缓存仓库的健康管理，会提供日志堆积处理、磁盘阈值分析、日志告警等功能。

另外，本申请实施例提供的一种日志处理方法的应用框架包括日志接收部分、日志传输部分、日志解析入库部分和缓存仓库守护部分。各部分互相配合，通过多个物理网卡监听不同的UDP端口，并发运行多个日志接收进程，并通过预设队列将接收的日志数据首先存入预设缓存仓库；日志解析入库进程监听预设缓存仓库是否有日志文件，如果有则进行日志解析入库；缓存仓库守护进程负责监视预设缓存仓库的健康状态，并进行必要的日志堆积处理、告警处理等。

与相关技术相比，本申请实施例提供的日志处理方法至少具有以下优势：

(1)多网卡并发接收日志数据。

相关技术中，一般采用单一线程(或进程)监听UDP的514端口，来实现日志接收工作，日志接收时都是通过单一网卡来完成数据传输，当日志接收峰值过大时，单一网卡很容易成为日志接收瓶颈。本申请实施例中，可通过新增多个物理网卡，监听不同的UDP端口，并发运行多个日志接收进程，来解决日志接收峰值过大时单一网卡的性能瓶颈，进而加快日志接收速率。

(2)采用LogID配置项，实现动态新增防火墙日志内容格式。

相关技术中，在进行SYSLOG日志接收时，一般都需要先将日志数据归一化处理，然后再存储，不利于防火墙日志格式的动态新增。本申请实施例中，当有新的防火墙日志格式，只需在配置文件中新增一条LogID配置项来设置新日志内容格式，防火墙日志数据便可正确解析，做到了动态添加、即插即用。

(3)缓存文件统一管理。

相关技术中，日志接收模块一般都会将日志数据先写入到本地文件，然后再分析，但是将日志写入到本地文件后，缺少对本地日志文件的统一管理，如日志文件如何分类、日志文件大小控制、日志文件数量控制、日志堆积如何处理等。本申请实施例中，会将接收的日志数据首先存入到预设缓存仓库，该预设缓存仓库有一个专门的守护进程，负责预设缓存仓库的健康管理，会提供日志堆积处理、磁盘阈值分析、日志告警等功能。

本实施例提供了一种日志处理方法，从中可以看出，本申请实施例提供的日志处理方法可以适用于包括日志接收部分、预设队列处理部分、缓存仓库处理部分、日志解析入库部分和缓存仓库守护部分等的应用框架。通过多个物理网卡监听不同的UDP端口，并发运行多个日志接收进程，并将接收的日志数据首先存入到预设缓存仓库，其将日志数据按照日志类型分类，分别存储到不同的存储目录文件中，每种日志类型对应一个存储目录文件，还可以按照日志类型对日志数据进行多线程解析；并采用LogID配置项，实现动态新增防火墙日志内容格式。通过缓存仓库守护进程监视预设缓存仓库的健康状态，并进行必要的日志堆积处理、告警处理等。这样，能够对日志数据进行统一管理和规范存储，并且提高了日志的接收存储以及解析入库的效率。

本申请的又一实施例中，参见图4，其示出了本申请实施例提供的一种日志处理装置40的组成结构示意图。如图4所示，该日志处理装置包括接收单元401、存储单元402以及解析单元403，其中，

接收单元401，配置为接收待处理的日志数据；

存储单元402，配置为按照日志类型对待处理的日志数据进行分类，得到至少一组日志数据，将至少一组日志数据对应存储在预设缓存仓库的至少一个存储目录文件中；其中，预设缓存仓库包括至少一个存储目录文件，且不同的日志类型对应不同的存储目录文件；

解析单元403，配置为从预设缓存仓库的至少一个存储目录文件中读取日志数据进行解析，并将解析结果写入目标数据库。

在一些实施例中，接收单元401具体配置为通过至少两个物理网卡监听至少两个用户数据包协议UDP端口；以及将从至少两个UDP端口获取到的日志数据确定为待处理的日志数据；其中，每一个物理网卡对应监听一个UDP端口，且从至少两个UDP端口获取日志数据的过程并发执行。

在一些实施例中，存储单元402具体配置为将待处理的日志数据存储到至少一个预设队列；以及根据至少一个发送线程从至少一个预设队列中读取日志数据并发送到预设缓存仓库；其中，每一个预设队列对应一个发送线程，且至少一个发送线程并发执行；以及在预设缓存仓库接收到待处理的日志数据后，按照日志类型对待处理的日志数据进行分类，得到至少一组日志数据；以及将至少一组日志数据对应存储在至少一个存储目录文件中。

在一些实施例中，存储单元402具体配置为将待处理的日志数据按照预设分配方式对应存储到至少一个预设队列；其中，预设分配方式至少包括下述其中一项：随机分配方式、轮询分配方式和一致性哈希算法分配方式。

在一些实施例中，解析单元403具体配置为通过至少一个解析线程从至少一个存储目录文件中分别读取待解析的目标日志数据；其中，每一个解析线程对应一个存储目录文件，且至少一个解析线程并发执行；以及当目标日志数据中的字段为公有字段时，通过正则表达式对公有字段进行解析，得到公有字段的解析结果；以及当目标日志数据中的字段为私有字段时，通过预设配置规则对私有字段进行解析，得到私有字段的解析结果；以及根据公有字段的解析结果和私有字段的解析结果得到目标日志数据的解析结果。

在一些实施例中，参见图5，其示出了本申请实施例提供的另一种日志处理装置的组成结构示意图。如图5所示，该日志处理装置40还可以包括设置单元404，配置为在接收待处理的日志数据的过程中，若接收到的日志数据为新的日志格式，则设置新的配置项，并将新的配置项增加到预设配置规则中；其中，新的配置项用于实现对新的日志格式的日志数据的正确解析。

在一些实施例中，如图5所示，该日志处理装置40还可以包括监控单元405，配置为判断预设缓存仓库是否存在日志堆积；若预设缓存仓库存在日志堆积，则根据预设清理策略对预设缓存仓库进行日志堆积处理；其中，预设清理策略至少包括下述其中一项：删除日志级别最低的日志数据、删除最早接收的日志数据、抛弃最新接收的日志数据和删除预设日志类型的日志数据。

在一些实施例中，监控单元405，具体配置为确定将待处理的日志数据存储到预设缓存仓库的第一速度和从预设缓存仓库中读取待处理的日志数据后并解析写入目标数据库的第二速度；以及若第二速度小于第一速度，则确定预设缓存仓库存在日志堆积；以及若第二速度大于或等于第一速度，则确定预设缓存仓库不存在日志堆积。

在一些实施例中，监控单元405，还配置为当预设缓存仓库存在异常时，生成异常告警信息；其中，异常告警信息包括：空间不足告警信息，和/或，日志堆积告警信息。

可以理解地，在本实施例中，“单元”可以是部分电路、部分处理器、部分程序或软件等等，当然也可以是模块，还可以是非模块化的。而且在本实施例中的各组成部分可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

所述集成的单元如果以软件功能模块的形式实现并非作为独立的产品进行销售或使用时，可以存储在一个计算机可读取存储介质中，基于这样的理解，本实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或processor(处理器)执行本实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

因此，本实施例提供了一种计算机存储介质，该计算机存储介质存储有计算机程序，该计算机程序被至少一个处理器执行时实现前述实施例中任一项所述方法的步骤。

基于上述的一种日志处理装置40的组成以及计算机存储介质，参见图6，其示出了本申请实施例提供的一种日志处理设备50的具体硬件结构示意图。如图6所示，日志处理设备50可以包括：通信接口501、存储器502和处理器503；各个组件通过总线系统504耦合在一起。可理解，总线系统504用于实现这些组件之间的连接通信。总线系统504除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图6中将各种总线都标为总线系统504。其中，通信接口501，用于在与其他外部网元之间进行收发信息过程中，信号的接收和发送；

存储器502，用于存储能够在处理器503上运行的计算机程序；

处理器503，用于在运行计算机程序时，执行：

接收待处理的日志数据；

按照日志类型对待处理的日志数据进行分类，得到至少一组日志数据，将至少一组日志数据对应存储在预设缓存仓库的至少一个存储目录文件中；其中，预设缓存仓库包括至少一个存储目录文件，且不同的日志类型对应不同的存储目录文件；

从预设缓存仓库的至少一个存储目录文件中读取日志数据进行解析，并将解析结果写入目标数据库。

可以理解，本申请实施例中的存储器502可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(Read-Only Memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(Random Access Memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(Static RAM，SRAM)、动态随机存取存储器(Dynamic RAM，DRAM)、同步动态随机存取存储器(Synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(Double Data RateSDRAM，DDRSDRAM)、增强型同步动态随机存取存储器(Enhanced SDRAM，ESDRAM)、同步链动态随机存取存储器(Synchronous link DRAM，SLDRAM)和直接内存总线随机存取存储器(Direct Rambus RAM，DRRAM)。本文描述的系统和方法的存储器502旨在包括但不限于这些和任意其它适合类型的存储器。

而处理器503可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器503中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器503可以是通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器502，处理器503读取存储器502中的信息，结合其硬件完成上述方法的步骤。

可以理解的是，本文描述的这些实施例可以用硬件、软件、固件、中间件、微码或其组合来实现。对于硬件实现，处理单元可以实现在一个或多个专用集成电路(ApplicationSpecific Integrated Circuits，ASIC)、数字信号处理器(Digital Signal Processing，DSP)、数字信号处理设备(DSP Device，DSPD)、可编程逻辑设备(Programmable LogicDevice，PLD)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)、通用处理器、控制器、微控制器、微处理器、用于执行本申请所述功能的其它电子单元或其组合中。

对于软件实现，可通过执行本文所述功能的模块(例如过程、函数等)来实现本文所述的技术。软件代码可存储在存储器中并通过处理器执行。存储器可以在处理器中或在处理器外部实现。

可选地，作为另一个实施例，处理器503还配置为在运行所述计算机程序时，执行前述实施例中任一项所述的方法的步骤。

在本申请的再一实施例中，基于上述日志处理装置40的组成示意图，参见图7，其示出了本申请实施例提供的另一种日志处理设备50的组成结构示意图。如图7所示，该日志处理设备50至少包括前述实施例中任一项所述的日志处理装置40。

对于日志处理设备50而言，由于在接收日志数据时，可以通过多网卡监听多端口实现多进程接收待处理的日志数据，从而提高了日志数据的接收效率；在将日志数据从多个预设队列传输到预设缓存仓库时，每个预设队列对应一个发送线程，通过多个发送线程并发从预设队列中读取日志数据并发送给预设缓存仓库，从而提高了日志数据的传输效率；在对日志数据进行解析时，每个存储目录文件对应一个解析线程，通过多个解析线程并发执行日志数据的解析，同时可以通过预设配置规则对日志内容进行准确解析，即使出现了新的日志格式，也只需要在配置文件中新增一条配置项即可对日志内容进行准确解析，从而提高了日志数据的解析效率并实现了日志格式的动态更新；同时，还对预设缓存仓库的健康状态进行监控，及时对日志堆积进行有效处理，并在存在异常时进行相应告警，从而避免了由于异常导致日志数据丢失、出错等问题。

以上所述，仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。

需要说明的是，在本申请中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

本申请所提供的几个方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。

本申请所提供的几个产品实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的产品实施例。

本申请所提供的几个方法或设备实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的方法实施例或设备实施例。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (12)

1.一种日志处理方法，其特征在于，所述方法包括：

接收待处理的日志数据；

按照日志类型对所述待处理的日志数据进行分类，得到至少一组日志数据，将所述至少一组日志数据对应存储在预设缓存仓库的至少一个存储目录文件中；其中，所述预设缓存仓库包括至少一个存储目录文件，且不同的日志类型对应不同的存储目录文件；

从所述预设缓存仓库的至少一个存储目录文件中读取日志数据进行解析，并将解析结果写入目标数据库。

2.根据权利要求1所述的方法，其特征在于，所述接收待处理的日志数据，包括：

通过至少两个物理网卡监听至少两个用户数据报协议UDP端口；

将从所述至少两个UDP端口获取到的日志数据确定为所述待处理的日志数据；其中，每一个物理网卡对应监听一个UDP端口，且从所述至少两个UDP端口获取日志数据的过程并发执行。

3.根据权利要求1所述的方法，其特征在于，在所述接收待处理的日志数据之后，所述方法还包括：

将所述待处理的日志数据存储到至少一个预设队列；

根据至少一个发送线程从所述至少一个预设队列中读取日志数据并发送到所述预设缓存仓库；其中，每一个预设队列对应一个发送线程，且所述至少一个发送线程并发执行；

相应地，所述按照日志类型对所述待处理的日志数据进行分类，得到至少一组日志数据，将所述至少一组日志数据对应存储在预设缓存仓库的至少一个存储目录文件中，包括：

在所述预设缓存仓库接收到所述待处理的日志数据后，按照日志类型对所述待处理的日志数据进行分类，得到所述至少一组日志数据；

将所述至少一组日志数据对应存储在所述至少一个存储目录文件中。

4.根据权利要求3所述的方法，其特征在于，所述将所述待处理的日志数据存储到至少一个预设队列，包括：

将所述待处理的日志数据按照预设分配方式对应存储到所述至少一个预设队列；

其中，所述预设分配方式至少包括下述其中一项：随机分配方式、轮询分配方式和一致性哈希算法分配方式。

5.根据权利要求1所述的方法，其特征在于，所述从所述预设缓存仓库的至少一个存储目录文件读取日志数据进行解析，包括：

通过至少一个解析线程从所述至少一个存储目录文件中分别读取待解析的目标日志数据；其中，每一个解析线程对应一个存储目录文件，且所述至少一个解析线程并发执行；

当所述目标日志数据中的字段为公有字段时，通过正则表达式对所述公有字段进行解析，得到所述公有字段的解析结果；

当所述目标日志数据中的字段为私有字段时，通过预设配置规则对所述私有字段进行解析，得到所述私有字段的解析结果；

根据所述公有字段的解析结果和所述私有字段的解析结果得到所述目标日志数据的解析结果。

6.根据权利要求5所述的方法，其特征在于，所述方法还包括：

在接收所述待处理的日志数据的过程中，若接收到的日志数据为新的日志格式，则设置新的配置项，并将所述新的配置项增加到所述预设配置规则中；其中，所述新的配置项用于实现对所述新的日志格式的日志数据的正确解析。

7.根据权利要求1至6任一项所述的方法，其特征在于，所述方法还包括：

判断所述预设缓存仓库是否存在日志堆积；

若所述预设缓存仓库存在日志堆积，则根据预设清理策略对所述预设缓存仓库进行日志堆积处理；

其中，所述预设清理策略至少包括下述其中一项：删除日志级别最低的日志数据、删除最早接收的日志数据、抛弃最新接收的日志数据和删除预设日志类型的日志数据。

8.根据权利要求7所述的方法，其特征在于，所述判断所述预设缓存仓库是否存在日志堆积，包括：

确定将所述待处理的日志数据存储到所述预设缓存仓库的第一速度，以及从所述预设缓存仓库中读取日志数据并解析写入目标数据库的第二速度；

若所述第二速度小于所述第一速度，则确定所述预设缓存仓库存在日志堆积；

若所述第二速度大于或等于所述第一速度，则确定所述预设缓存仓库不存在日志堆积。

9.根据权利要求7所述的方法，其特征在于，所述方法还包括：

当所述预设缓存仓库存在异常时，生成相应的异常告警信息；其中，所述异常告警信息包括：空间不足告警信息，和/或，日志堆积告警信息。

10.一种日志处理装置，其特征在于，所述日志处理装置包括接收单元、存储单元以及解析单元，其中，

所述接收单元，配置为接收待处理的日志数据；

所述存储单元，配置为按照日志类型对所述待处理的日志数据进行分类，得到至少一组日志数据，将所述至少一组日志数据对应存储在预设缓存仓库的至少一个存储目录文件中；其中，所述预设缓存仓库包括至少一个存储目录文件，且不同的日志类型对应不同的存储目录文件；

所述解析单元，配置为从所述预设缓存仓库的至少一个存储目录文件中读取日志数据进行解析，并将解析结果写入目标数据库。

11.一种日志处理设备，其特征在于，所述日志处理设备包括存储器和处理器，其中，

所述存储器，用于存储能够在所述处理器上运行的计算机程序；

所述处理器，用于在运行所述计算机程序时，执行如权利要求1至9任一项所述的日志处理方法。

12.一种计算机存储介质，其特征在于，所述计算机存储介质存储有计算机程序，所述计算机程序被至少一个处理器执行时实现如权利要求1至9任一项所述的日志处理方法。

Images