日志生成方法、装置、电子设备和存储介质

技术领域

本公开涉及软件编程领域，尤其涉及一种日志生成方法、装置、电子设备和存储介质。

背景技术

现阶段，依赖于互联网搭建的业务系统在运行或维护过程中通常会产生相应的系统日志。例如，在业务系统运行过程中，方法调用请求对应的请求事件会产生用户行为日志、系统运行日志等运行日志。又例如，在针对业务系统或其中某一服务进行压力测试的过程中，往往并不会将该系统或服务下线，而是会在系统或服务正常运行过程中进行在线测试，从而产生相应的测试请求日志。

在相关技术中，通常将业务系统产生的日志按照时间顺序统一存放在预先指定的日志文件中，以便后续日志处理。然而，随着业务系统提供的业务功能越来越丰富，业务系统所产生的日志种类和数量也逐渐增多，而上述存放方式难以实现高效的日志分类，无法满足日益多样的日志管理需求。

发明内容

本公开提供了日志生成方法、装置、电子设备和存储介质，以至少解决相关技术中的技术问题。本公开的技术方案如下：

根据本公开实施例的第一方面，提出一种日志生成方法，包括：

接收包含类型标识的请求事件，所述类型标识用于表明所述请求事件的事件类型；

发送所述请求事件到预设的多个过滤组件，以使所述多个过滤组件分别根据所述类型标识对所述请求事件进行过滤，所述多个过滤组件被分别关联至日志生成框架中的多个接口组件，所述多个接口组件分别对应于多个日志文件；

在接收到任一所述过滤组件过滤并发送的目标事件后，根据所述目标事件生成目标日志，并将所述目标日志存储在关联至所述任一过滤组件的接口组件所对应的日志文件中。

可选的，所述多个过滤组件与所述多个接口组件一一对应，所述多个接口组件被分别配置有用于指定不同日志文件的配置参数。

可选的，所述多个接口组件还分别配置有用于指定不同目标字段的字段参数，所述根据所述目标事件生成目标日志，包括：

从所述目标事件所对应的目标字段中提取字段信息，并生成包含所述字段信息的目标日志。

可选的，所述请求事件的类型包括用户操作事件和系统测试事件。

可选的，所述多个过滤组件包括用于过滤并发送所述用户操作事件的第一过滤组件和用于过滤并发送所述系统测试事件的第二过滤组件，所述多个接口组件包括关联至所述第一过滤组件的第一接口组件和关联至所述第二过滤组件的第二接口组件，其中：

所述第一接口组件被配置有用于指定运行日志文件的配置参数，所述运行日志文件用于存储所述日志生成框架生成的运行请求日志，所述运行请求日志被根据连接至所述日志生成框架的业务系统在正常运行状态下产生的业务请求所生成；

所述第二接口组件被配置有用于指定测试请求日志文件的配置参数，所述测试请求日志文件用于存储所述日志生成框架生成的测试请求日志，所述测试请求日志被根据所述业务系统在测试状态下产生的测试请求所生成。

可选的，任一所述过滤组件采用下述过滤规则对所述请求事件进行过滤：

若所述请求事件的类型标识为预设标识，则发送所述请求事件；否则，

若所述请求事件的类型标识为所述预设标识之外的其他标识，则不发送所述请求事件。

根据本公开实施例的第二方面，提出一种日志生成系统，包括：

多个过滤组件，所述多个过滤组件分别用于根据请求事件携带的类型标识过滤并发送不同类型的请求事件，其中，所述类型标识用于表明所述请求事件的事件类型；

日志生成框架，所述日志生成框架包括多个接口组件，所述多个接口组件被分别配置有用于指定不同日志文件的配置参数，所述日志生成框架用于根据任一过滤组件过滤后发送的目标事件生成目标日志，并将所述目标日志存储在为所述任一过滤组件关联的接口组件指定的日志文件中。

可选的，任一所述过滤组件采用下述过滤规则对所述请求事件进行过滤：

若所述请求事件的类型标识为预设标识，则发送所述请求事件；否则，

若所述请求事件的类型标识为所述预设标识之外的其他标识，则不发送所述请求事件。

可选的，所述日志生成框架为回拨日志框架，所述过滤组件为基于所述回拨日志框架构建的过滤组件，所述接口组件为基于所述回拨日志框架构建的附属组件；其中，多个过滤组件被分别关联至多个附属组件，所述多个附属组件被分别配置有用于指定不同日志文件的配置参数，所述回拨日志框架用于根据任一过滤组件过滤后发送的目标事件生成目标日志，并将所述目标日志存储在为所述任一过滤组件关联的附属组件指定的日志文件中。

可选的，所述请求事件的类型包括用户操作事件和系统测试事件。

可选的，所述多个过滤组件包括用于过滤并发送所述用户操作事件的第一过滤组件和用于过滤并发送所述系统测试事件的第二过滤组件，所述多个接口组件包括关联至所述第一过滤组件的第一接口组件和关联至所述第二过滤组件的第二接口组件，其中：

为所述第一接口组件配置的所述配置参数用于指定运行日志文件，所述运行日志文件用于存储所述日志生成框架生成的运行请求日志，所述运行请求日志根据连接至所述日志生成系统的业务系统在正常运行状态下产生的业务请求所生成；

为所述第二接口组件配置的所述配置参数用于指定测试日志文件，所述测试请求日志文件用于存储所述日志生成框架生成的测试请求日志，所述测试请求日志根据所述业务系统在测试状态下产生的测试请求所生成。

可选的，所述用于指定不同日志文件的配置参数包括多个文件名和/或多个文件存储地址，其中，所述多个文件名分别为多个不同的日志文件的文件名，所述多个文件存储地址处分别存储有不同的日志文件。

根据本公开实施例的第三方面，提出一种日志生成装置，包括：

事件接收单元，被配置为接收包含类型标识的请求事件，所述类型标识用于表明所述请求事件的事件类型；

事件发送单元，被配置为发送所述请求事件到预设的多个过滤组件，以使所述多个过滤组件分别根据所述类型标识对所述请求事件进行过滤，所述多个过滤组件被分别关联至日志生成框架中的多个接口组件，所述多个接口组件分别对应于多个日志文件；

日志生成单元，被配置为在接收到任一所述过滤组件过滤并发送的目标事件后，根据所述目标事件生成目标日志，并将所述目标日志存储在关联至所述任一过滤组件的接口组件所对应的日志文件中。

可选的，所述多个过滤组件与所述多个接口组件一一对应，所述多个接口组件被分别配置有用于指定不同日志文件的配置参数。

可选的，所述多个接口组件还分别配置有用于指定不同目标字段的字段参数，所述日志生成单元还被配置为：

从所述目标事件所对应的目标字段中提取字段信息，并生成包含所述字段信息的目标日志。

可选的，所述请求事件的类型包括用户操作事件和系统测试事件。

可选的，所述多个过滤组件包括用于过滤并发送所述用户操作事件的第一过滤组件和用于过滤并发送所述系统测试事件的第二过滤组件，所述多个接口组件包括关联至所述第一过滤组件的第一接口组件和关联至所述第二过滤组件的第二接口组件，其中：

所述第一接口组件被配置有用于指定运行日志文件的配置参数，所述运行日志文件用于存储所述日志生成框架生成的运行请求日志，所述运行请求日志被根据连接至所述日志生成框架的业务系统在正常运行状态下产生的业务请求所生成；

所述第二接口组件被配置有用于指定测试请求日志文件的配置参数，所述测试请求日志文件用于存储所述日志生成框架生成的测试请求日志，所述测试请求日志被根据所述业务系统在测试状态下产生的测试请求所生成。

可选的，任一所述过滤组件采用下述过滤规则对所述请求事件进行过滤：

若所述请求事件的类型标识为预设标识，则发送所述请求事件；否则，

若所述请求事件的类型标识为所述预设标识之外的其他标识，则不发送所述请求事件。

根据本公开实施例的第四方面，提出一种电子设备，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如上述第一方面中任一实施例所述的日志生成方法。

根据本公开实施例的第五方面，提出一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行上述第一方面中任一实施例所述的日志生成方法。

根据本公开实施例的第六方面，提供一种计算机程序产品，包括计算机程序和/或指令，所述计算机程序和/或指令被处理器执行时实现上述第一方面中任一实施例所述的日志生成方法。

本公开的实施例提供的技术方案至少带来以下有益效果：

根据本公开的实施例，本方案以现有的日志生成框架为基础，实现多个过滤组件及与之关联的多个接口组件，从而形成日志生成系统。进而利用该日志生成系统按照请求事件的类型标识实现对请求事件的过滤，并在根据某一过滤组件过滤后输出的目标事件生成相应的目标日志后，将目标日志存储在关联至该过滤组件的结构组件所对应的日志文件中。因为日志生成系统中的各个过滤组件与各个接口组件相关联，且各个结构组件分别对应于多个日志文件，因此通过该方案能够根据各个过滤组件分别过滤得到的不同的请求事件分别生成相应的系统日志，进而将各个系统日志分别保存在各个过滤组件对应的日志文件中，即将不同类型的系统日志存储在不同的存储空间，从而实现针对系统日志的有效隔离。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。

图1是根据本公开的实施例示出的一种日志生成系统的结构示意图；

图2是根据本公开的实施例示出的一种日志生成方法的流程图；

图3是根据本公开的实施例示出的一种日志生成框架的配置方法的示意图；

图4是根据本公开的实施例示出的一种配置后的日志生成系统的示意图；

图5是根据本公开的实施例示出的另一种日志生成方法的流程图；

图6是根据本公开的实施例示出的一种日志生成装置的示意框图；

图7是根据本公开的实施例示出的一种电子设备的结构图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

现阶段，依赖于互联网搭建的业务系统在运行或维护过程中通常会产生相应的系统日志。例如，在业务系统运行过程中，方法调用请求对应的请求事件会产生用户行为日志、系统运行日志等运行日志。又例如，在针对业务系统或其中某一服务进行压力测试的过程中，往往并不会将该系统或服务下线，而是会在系统或服务正常运行过程中进行在线测试，从而产生相应的测试请求日志。

在相关技术中，通常将业务系统产生的日志按照时间顺序统一存放在预先指定的日志文件中，以便后续日志处理。然而，随着业务系统提供的业务功能越来越丰富，业务系统所产生的日志种类和数量也逐渐增多，而上述存放方式难以实现高效的日志分类，无法满足日益多样的日志管理需求。

为此，本公开提出一种日志生成系统，以现有的日志生成框架为基础，实现多个过滤组件及与之关联的多个接口组件，其中各个接口组件分别对应于各个不同的日志文件，任一日志文件用于保存基于其对应的接口组件所关联的过滤组件过滤得到的请求事件生成的系统日志。进而基于该日志生成系统提出一种日志方法：利用该日志生成系统按照请求事件的类型标识实现对请求事件的过滤，并在根据某一过滤组件过滤后输出的目标事件生成相应的目标日志后，将目标日志存储在关联至该过滤组件的结构组件所对应的日志文件中。通过上述日志生成系统和日志生成方法实现针对系统日志的有效隔离。

图1是本说明书一示例性实施例示出的一种日志生成系统的机构示意图。如图1所示，该系统可以包括日志生成框架和多个过滤组件，其中：

所述多个过滤组件分别用于根据请求事件携带的类型标识过滤并发送不同类型的请求事件，其中，所述类型标识用于表明所述请求事件的事件类型；

所述日志生成框架包括多个接口组件，所述多个接口组件被分别配置有用于指定不同日志文件的配置参数，所述日志生成框架用于根据任一过滤组件过滤后发送的目标事件生成目标日志，并将所述目标日志存储在为所述任一过滤组件关联的接口组件指定的日志文件中。

如图1所示的日志生成系统中，可以包括过滤组件1、过滤组件2……过滤组件n等共n个过滤组件；而日志生成框架中包含接口组件1、接口组件2……接口组件n等共n个接口组件，而任一过滤组件分别被关联至至少一个接口组件，任一接口组件分别对应于至少一个日志文件。任一过滤组件过滤后发送至日志生成框架的目标事件，被用于生成相应的目标日志，并保存至该过滤组件关联的接口组件所对应的日志文件中。

在本实施例中，日志处理设备可以连接至网络业务的业务系统，因此上述请求事件可以为业务系统产生的方法调用请求、组件调用请求、函数调用请求等请求事件(或称为请求)。例如，在业务系统在为用户提供正常网络服务的同时进行压力测试的场景下，业务系统中产生的方法调用请求可能包括正常账号产生的业务请求(往往对应于真正的用户操作)和测试账号产生的测试请求，此时本方案的目的为：分别为业务请求和测试请求生成运行请求日志和测试请求日志，并将运行请求日志和测试请求日志分别进行存储，从而实现日志隔离以便于为对测试结果进行有效分析。又例如，在业务系统进行灰度更新的场景下，业务系统所对应全部账号中的第一类账号使用(更新前的)旧版本软件、第二类账号使用(更新后的)新版本软件，此时方案的目的为：分别为第一类账号和第二类账号产生的账号请求生成相应的旧版本日志和新版本日志，并将旧版本日志和新版本日志分别进行存储，从而实现日志隔离以便于为对新版本软件和版本软件进行比较分析。

为实现对不同请求所对应日志的隔离，本方案需要构建针对请求事件的过滤组件，因此需要先确定相应的过滤规则。过滤规则可以由后台人员手动设置、采用系统的默认设置或者采用历史过滤组件的历史过滤规则，本公开实施例并不对此进行限制。在一实施例中，任一过滤组件可以根据请求事件的类型标识实现过滤请求事件，即采用下述过滤规则：若请求事件的类型标识为预设标识，则发送该请求事件；否则，若请求事件的类型标识为预设标识之外的其他标识，则不发送该请求事件。通过该方式，过滤组件只需要对请求事件的类型标识与预设标识进行比较，即可确定是否发送该请求事件，从而快速完成对请求事件的过滤。

在一实施例中，本方案的日志生成框架可以为回拨日志框架，过滤组件可以为基于回拨日志框架构建的过滤器，接口组件可以为基于回拨日志框架构建的附属组件；其中，多个过滤器被分别关联至多个附属组件，多个附属组件被分别配置有用于指定不同日志文件的配置参数，该回拨日志框架用于根据任一过滤器过滤后发送的目标事件生成目标日志，并将目标日志存储在为任一过滤器关联的附属组件指定的日志文件中。进一步的，上述回拨日志框架可以采用相关技术中的logback日志框架，从而上述各个过滤器可以包括基于logback日志框架构建的Filter，上述各个附属组件可以包括基于logback日志框架构建的appender组件。相应的，此时的类型标识可以包括请求事件的线程变量信息(或称ThreadLocal信息)。在成熟有效的logback日志框架的基础上构建上述过滤组件和接口组件，不仅能够提高日志生成效率，而且能够保证配置后的日志生成框架的运行稳定性，最终有助于保证日志处理效率。

在一实施例中，待过滤的请求事件的事件类型可以包括两种：用户操作事件(对应于业务系统正常运行状态下的业务请求)和系统测试事件(对应于业务系统测试状态下的测试请求)。相应的，此时的过滤组件和接口组件的个数至少为两个。

进一步的，上述多个过滤组件可以包括用于过滤并发送用户操作事件的第一过滤组件和用于过滤并发送系统测试事件的第二过滤组件，上述多个接口组件可以包括关联至第一过滤组件的第一接口组件和关联至第二过滤组件的第二接口组件，其中：为第一接口组件配置的配置参数用于指定运行日志文件，该运行日志文件用于存储日志生成框架生成的运行请求日志，该运行请求日志被根据连接至日志生成系统的业务系统在正常运行状态下产生的业务请求所生成；而为第二接口组件配置的配置参数用于指定测试日志文件，该测试日志文件用于存储日志生成框架生成的测试请求日志，该测试请求日志被根据业务系统在测试状态下产生的测试请求所生成。此时，根据上述日志生成系统，能够对业务系统的请求事件生成相应的系统日志，并将其按照请求事件的事件类型分为业务请求日志和测试请求日志，然后将二者分别保存在运行日志文件和测试日志文件中，实现两类日志文件的有效隔离，有助于业务系统的测试实现。

在一实施例中，为各个接口组件分别指定的配置参数包括多个文件名和/或多个文件存储地址，其中，上述多个文件名分别为多个不同的日志文件的文件名，上述多个文件存储地址处分别存储有不同的日志文件。从而通过文件名或文件存储地址的方式，为任一接口组件分别指定至少一个日志文件，保证日志文件与接口组件的对应。

基于上述日志生成系统，本公开的下述实施例还提出一种日志生成方法。图2是本公开一示例性实施例示出的一种日志生成方法的流程图。如图2所示，该方法应用于服务器等日志处理设备，可以包括下述步骤202-206。

步骤202，接收包含类型标识的请求事件，所述类型标识用于表明所述请求事件的事件类型。

步骤204，发送所述请求事件到预设的多个过滤组件，以使所述多个过滤组件分别根据所述类型标识对所述请求事件进行过滤，所述多个过滤组件被分别关联至日志生成框架中的多个接口组件，所述多个接口组件分别对应于多个日志文件。

在本实施例中，日志处理设备可以连接至网络业务的业务系统，因此请求事件可以为业务系统产生的方法调用请求、组件调用请求、函数调用请求等请求事件(或称为请求)。业务系统可以在生成任一请求事件时即为该请求事件添加类型标识，或者日志处理设备也可以调用其他预设的请求分类服务对接收到的任一请求事件进行分类并添加类型标识。

其中，任一请求事件的类型标识可以为产生该请求事件的账号ID。例如在业务系统在为用户提供正常网络服务的同时进行压力测试的场景下，业务系统中产生的方法调用请求可能包括正常账号产生的业务请求(往往对应于真正的用户操作)和测试账号产生的测试请求。此时可以将任一账号的账号ID作为该账号所产生请求事件的类型标识，从而日志处理设备中的多个过滤组件在接收到该请求事件后可以根据其携带的账号ID判断该请求事件的事件类型：业务请求或测试请求。再或者在业务系统进行灰度更新的场景下，业务系统所对应全部账号中的第一类账号使用(更新前的)旧版本软件、第二类账号使用(更新后的)新版本软件，此时可以将版本号作为相应请求事件的类型标识，如第一类账号所产生请求事件的事件标识为“VO”、第二类账号所产生请求事件的事件标识为“VN”等。又或者，任一请求事件的类型标识也可以为预设的特殊标识，如特殊字符“S1”、“S2”等，本公开实施例并不对此进行限制。

在一实施例中，在请求事件自身携带或者被标记有类型标识的情况下，任一过滤组件所遵循的过滤规则可以为：若请求事件的类型标识为预设标识，则发送该请求事件；否则，若请求事件的类型标识为预设标识之外的其他标识，则不发送该请求事件。其中，上述“发送请求事件”可以理解为由过滤组件将请求事件发送至其所关联的接口组件；而且，在在不发送请求事件的情况下，过滤组件可以选择丢弃该请求事件或者记录该请求事件的过滤结果，不再赘述。可见，根据该规则构建的过滤组件可以仅发送(或称放行)预设标识对应的请求事件，从而有助于实现对请求事件的准确过滤。承接于前述实施例，在构建两个过滤组件的情况下，可以使第一过滤组件仅通过业务请求而第二过滤组件仅通过测试请求，或者使第一过滤组件仅通过第一类账号产生的业务请求而第二过滤组件仅通过第二类账号产生的业务请求。

在一实施例中，除构建多个过滤组件之外，该可以基于日志生成框架构建多个接口组件并进行相应的配置，其中任一接口组件对应的配置参数可以用于指定相应的日志文件，而各个接口组件对应的接口组件并不相同。进而可以将各个过滤组件相应的关联至各个接口组件，以实现对日志生成框架的配置。其中，任一接口组件的配置参数所指定的日志文件，用于存储该接口组件所关联过滤组件输出的目标事件对应的系统日志——因为不同接口组件对应于不同的日志文件，所以根据不同过滤组件输出的请求事件生成的系统日志能够被存储在不同的日志文件中，从而实现对系统日志的有效隔离。

在一实施例中，本实施例中过滤组件和接口组件的具体个数可以与请求事件的类型保持一致，即在待处理的请求事件可分为n类的情况下，所构建过滤组件和接口组件的个数都为n个，从而任一过滤组件可以仅过滤其中一种请求事件。甚至，多个过滤组件可以与多个接口组件一一对应，此时多个接口组件可以被分别配置有用于指定不同日志文件的配置参数。从而通过过滤组件与接口组件的一一对应关系以及分别为各个接口组件分别配置的配置参数，保证不同类型的请求事件对应的系统日志被分配至不同的日志文件。

在一实施例中，上述过滤组件和接口组件的个数可以分别为两个；此时请求事件的事件类型可以包括两种：用户操作事件和系统测试事件，而通过上述日志生成系统，能够保证将任一请求事件确定为用户操作事件或者系统测试事件，并进而将请求事件的系统日志分配至相应事件对应的日志文件中，保证同类请求事件对应的系统日志被分配至同一日志文件中。

进一步的，此时的两个过滤组件可以包括用于过滤并发送用户操作事件的第一过滤组件和用于过滤并发送系统测试事件的第二过滤组件，相应的，两个接口组件可以分别为关联至第一过滤组件的第一接口组件和关联至第二过滤组件的第二接口组件；其中：为第一接口组件配置的配置参数用于指定运行日志文件，该运行日志文件用于存储日志生成框架生成的运行请求日志，该运行请求日志被根据连接至日志生成系统的业务系统在正常运行状态下产生的业务请求所生成；而为第二接口组件配置的配置参数用于指定测试日志文件，该测试日志文件用于存储日志生成框架生成的测试请求日志，该测试请求日志被根据业务系统在测试状态下产生的测试请求所生成。一方面，为第一接口组件指定运行日志文件并为第二接口组件指定检测日志文件，保证了根据业务请求生成的运行请求日志(即业务系统在正常运行状态下产生的系统日志)能够被存储在运行日志文件中，同时，根据系统检测事件生成的测试请求日志(即业务系统在测试状态下产生的请求日志)能够被存储在测试日志文件中，从而实现准确的日志隔离。另一方面，因为运行日志文件用于保存业务系统在正常运行状态下产生的系统日志，从而将测试过程中根据用户操作事件生成的系统日志与不进行测试时根据用户操作事件生成的系统日志保存在同一日志文件中，实现了用户操作事件所对应系统日志的有效兼容，即实现对非测试时的日志生成的兼容，使得该方法应用时的配置参数改动较少，有助于保证日志生成框架的运行稳定性。

步骤206，在接收到任一所述过滤组件过滤并发送的目标事件后，根据所述目标事件生成目标日志，并将所述目标日志存储在关联至所述任一过滤组件的接口组件所对应的日志文件中。

在一实施例中，多个接口组件还分别配置有用于指定不同目标字段的字段参数，此时日志处理设备可以从目标事件所对应的目标字段中提取字段信息，然后按照预设规则生成包含该字段信息的目标日志。例如，在请求事件中依次包含“事件类型、创建时间、创建账号ID、被调用函数的函数名、调用方式、有效时长、验证信息(如token)”等字段的情况下，可以依次提取“事件类型、创建时间、创建账号ID、被调用函数的函数名”四个字段的字段取值“测试请求、2020.11.01.08.10.30、AAA、Regression function(回归函数)”，然后按照预设顺序对这四个字段进行排序后生成相应的系统日志。其中，生成日志的具体过程可以参见相关技术中的记载，此处不再赘述。

根据本公开的实施例，本方案以现有的日志生成框架为基础，实现多个过滤组件及与之关联的多个接口组件，从而形成日志生成系统。进而利用该日志生成系统按照请求事件的类型标识实现对请求事件的过滤，并在根据某一过滤组件过滤后输出的目标事件生成相应的目标日志后，将目标日志存储在关联至该过滤组件的结构组件所对应的日志文件中。因为日志生成系统中的各个过滤组件与各个接口组件相关联，且各个结构组件分别对应于多个日志文件，因此通过该方案能够根据各个过滤组件分别过滤得到的不同的请求事件分别生成相应的系统日志，进而将各个系统日志分别保存在各个过滤组件对应的日志文件中，即将不同类型的系统日志存储在不同的存储空间，从而实现针对系统日志的有效隔离。

如前所述，本公开的日志生成方法可以用于配置logback日志框架，使用配置后的该框架可以生成日志并实现日志隔离。下面结合图2-图4，以业务系统压力测试场景为例，对以logback日志框架为基础配置生成日志生成系统，并利用该系统生成目标日志的过程进行详细说明。

图3是根据本公开的实施例示出的另一种日志生成框架的配置方法的流程图；如图3所示，该方法应用于日志处理设备，该方法可以包括下述步骤：

步骤302a，日志处理设备确定过滤规则。

在一实施例中，可以针对请求事件的类型标识预先设置用于过滤请求事件的预设标识，进而根据该预设标识指定过滤规则。具体的，可以在请求事件的类型标识为预设标向相应的接口组件发送(即放行)该请求事件；否则，在请求事件的类型标识为预设标识之外的其他标识时不发送(即不放行)该请求事件，此时可以丢弃该请求事件或记录请求事件的相关信息。相应的，根据上述过滤规则构建的任一过滤组件在接收到任一请求事件后，对该请求事件的过滤结果有两种可能：将该请求事件发送至接口组件，此时发送的该请求事件即为待生成日志的目标事件；或者不发送该请求事件。可以理解的是，上述过滤规则对应的多种类型标识之间可以互斥，此时任一请求事件会被输入各个过滤组件，其中有且仅有一个过滤组件能够将该请求事件作为目标事件输出(可以将该过滤组件记为目标过滤组件)。或者，任一请求事件也可以携带多种类型标识(如将事件标签作为类型组件进行过滤)，则任一请求事件可能同时被多个过滤组件过滤后放行，即该请求事件可能被同时发送至多个接口组件，并按照各个类型标识分别生成相应的系统日志，并分别分配至多个日志文件中。

在一实施例中，上述过滤规则可以由后台人员手动设置、采用系统的默认设置或者采用历史过滤组件的历史过滤规则，本公开实施例并不对此进行限制。

步骤304a，日志处理设备基于logback日志框架构建第一过滤组件和第二过滤组件。

如图4所示，本实施例以构建两个过滤组件为例进行说明。本实施例方案采用logback日志框架，所以第一过滤组件(如Filter1)和第二过滤组件(如Filter2)可以通过在JAVA环境下继承ch.qos.logback.core.filter.Filter的方式实现，具体实现过程可以参见相关技术中的记载，此处不再赘述。

由前述过滤规则可知，任一过滤组件仅能够过滤并输出符合自身所对应预设标识的请求事件。例如，在为用户提供正常网络服务的同时进行压力测试的场景下，请求事件可以包括正常账号产生的业务请求和测试账号产生的测试请求，此时第一过滤组件可以仅过滤并放行业务请求、第二过滤组件可以仅过滤并放行测试请求。从而，日志生成设备在将接收到的任一请求事件发送至第一过滤组件和第二过滤组件后：若该请求事件为业务请求，则其会被第一过滤组件放行；否则，若该请求事件为测试请求，则其会被第二过滤组件放行。

步骤302b，日志处理设备基于logback日志框架构建第一接口组件和第二接口组件。

在本实施例中，日志处理设备还可以基于logback日志框架构建接口组件。第一接口组件(如appender1)和第二接口组件(appender2)可以通过在JAVA环境下继承ch.qos.logback.core.appender.Appender的方式实现，具体实现过程可以参见相关技术中的记载，此处不再赘述。

步骤304b，日志处理设备配置第一接口组件和第二接口组件。

进一步的，日志处理设备可以对第一接口组件和第二接口组件进行配置，例如可以配置二者分别对应系统日志的日志格式、日志内容字段以及日志保存的日志文件的文件名等参数。其中，配置的日志格式及内容字段用于指定所生成系统日志的格式和内容，配置的文件名用以指定所生成系统日志的存储位置(即将生成的系统日志分配并保存在哪个文件中)。配置接口组件的配置参数的具体过程可以参见相关技术中的记载，此处不再赘述。

本实施例中，作为一示例性实施方式，可以先执行步骤302a-304a以构建过滤组件，再执行步骤302b-304b以构建并配置接口组件；或者，作为另一示例性实施方式，可以先执行步骤302b-304b以构建并配置接口组件，再执行步骤302a-304a以构建过滤组件。换言之，“构建过滤组件”与“构建并配置接口组件”之间并不存在必然的先后顺序，可以根据实际情况进行调整。当然，二者也可以同时进行，本公开实施例并不对此进行限制。

步骤306，日志处理设备将接口组件关联至过滤组件。

在一实施例中，在构建过滤组件以及构建并配置接口组件完成后，日志处理设备可以将第一接口组件关联至第一过滤组件，并将第二接口组件关联至第二过滤组件。其中，为保证根据各个过滤组件过滤后发送的请求事件生成的系统日志被分配至不同的日志文件中，可以为第一接口组件和第二接口组件配置不同的日志文件的文件名。例如，可以为第一接口组件配置文件名“application.log”、并为第二接口组件配置文件名“application_test.log”，以通过文件名表明第一接口组件对应的日志文件用于存放运行请求日志，而第二接口组件对应的日志文件用于存放测试请求日志。

例如，可以通过接口组件配置代码实现针对第一接口组件和第二接口组件的上述配置。以JAVA语言环境为例，在该环境下，可以通过继承类型的语句指定继承自第一过滤组件的第一接口组件所对应日志文件的文件名“application.log”，从而为第一接口组件指定该日志文件用于保存运行请求日志；类似的，可以通过继承类型的语句指定继承自第二过滤组件的第二接口组件所对应日志文件的文件名“application.log”，从而为第一接口组件指定该日志文件用于保存测试请求日志。

另外，可以在针对第一接口组件的接口组件配置代码中，为其所关联的第一过滤组件指定相应的过滤规则，如仅过滤并发送业务请求；类似的，可以在针对第二接口组件的接口组件配置代码中，为其所关联的第二过滤组件指定相应的过滤规则，如仅过滤并发送测试请求。当然，还可以为两过滤组件配置其他的过滤规则，不再赘述。

配置完成得到的过滤组件、接口组件和logback日志框架构成的日志生成系统的结构示意图如图4所示。可见，该日志生成系统的输入端连接业务系统，logback日志框架包括第一接口组件和第二接口组件，二者由统一的日志配置文件进行配置(当然，也可以使用不同的日志配置文件分别进行配置)，该日志配置文件中可以包含上述配置代码。第一接口组件和第二接口组件的输入端分别连接第一过滤组件和第二过滤组件、输出端分别连接用户日志文件application.log和测试请求日志文件application_test.log。

此时，业务系统产生的方法调用请求、组件调用请求、函数调用请求等请求事件同时输入到日志生成系统的第一过滤组件和第二过滤组件，并由二者分别对请求事件进行过滤。任一过滤组件过滤后输出的请求事件进入相应的接口组件，进而logback日志框架根据该接口组件对应的配置文件生成系统日志(对应于第一接口组件生成运行请求日志，对应于第二接口组件生成测试请求日志)，并将上述系统日志分配至相应的日志文件中保存。

图5是根据本公开的实施例示出的另一种日志生成方法的流程图。以请求事件为反复调用请求为例，由图5可见，使用图4所示的日志生成系统生成请求日志并实现日志隔离的具体过程可以包括下述步骤502-508。

步骤502，日志处理设备接收业务系统产生的请求事件。

在业务系统运行过程中，会根据账号行为产生方法调用请求(下称请求事件)，以调用相应的方法模块对账号行为做出响应。其中，上述请求事件可能由正常账号(下称用户账号)的用户操作引起或者由测试账号的测试指令引起，所以业务系统产生的请求事件可能为业务请求或者测试请求，本方案的目的即为生成根据请求事件的类型生成相应的系统日志，并对上述两种请求事件分别对应的系统日志进行隔离(即分别保存在不同的日志文件中)。

在本实施例中，假设请求事件的线程变量信息中保存有产生该请求事件的账号ID，并将该账号ID作为自身的类型标识。可以理解的是，第一过滤组件和第二过滤组件中可以分别记录相应账号的账号特征，例如第一过滤组件中可以记录用户账号的账号特征，第二过滤组件中可以记录测试账号的账号特征，上述账号特征可以为账号注册时间段、账号号段区间等，本公开实施例并不对此进行限制。

步骤504，过滤组件过滤请求事件。

日志生成系统接收到任一请求事件后，会将该请求事件同时发送至第一过滤组件和第二过滤组件，并由二者根据请求事件的类型标识分别对其进行过滤。若该请求事件为业务请求，则该业务请求会被第一过滤组件放行而被第二过滤组件丢弃；若该请求事件为测试请求，该测试请求会被第二过滤组件放行而被第一过滤组件丢弃。

步骤506，logback日志框架根据接口组件的配置参数生成请求日志。

若该请求事件为业务请求，则第一过滤组件放行的该业务请求会被发送至第一接口组件，进而logback日志框架可以按照第一接口组件对应的配置参数生成系统日志(即运行请求日志)；相应的，若该请求事件为测试请求，则第二过滤组件放行的该测试请求会被发送至第二接口组件，进而logback日志框架可以按照第二接口组件对应的配置参数生成系统日志(即测试请求日志)。具体的，对于任一请求事件，logback日志框架可以从该请求事件中获取指定的字段信息，并根据获取到的字段信息和配置参数中指定的日志生成规则生成请求日志，具体过程此处不再赘述。

步骤508，日志处理设备将系统日志存储在相应的日志文件中。

因为第一接口组件对应的配置参数已经指定运行日志文件为application.log、第二接口组件对应的配置参数已经指定测试日志文件为application_test.log，所以若该请求事件为业务请求，则日志处理设备可以将logback日志框架生成的运行请求日志保存在运行日志文件application.log中，若该请求事件为测试请求，则日志处理设备可以将logback日志框架生成的测试请求日志保存在测试日志文件application_test.log中，从而实现对业务请求和测试请求分别对应的系统日志的有效隔离。

与前述日志生成方法的实施例相对应地，本公开还提出了日志生成装置以及日志生成装置的实施例。

图6是根据本公开的实施例示出的一种日志生成装置的示意框图。本实施例所示的日志生成装置可以适用于服务器等日志处理设备，所述服务器可以为包含一独立主机的物理服务器、主机集群承载的虚拟服务器、云服务器等；当然，上述日志生成装置还可以适用于终端，所述终端包括但不限于手机、平板电脑、可穿戴设备、个人计算机等电子设备，本公开实施例并不对此进行限制。

如图6所示，所述日志生成装置可以包括：

事件接收单元601，被配置为接收包含类型标识的请求事件，所述类型标识用于表明所述请求事件的事件类型；

事件发送单元602，被配置为发送所述请求事件到预设的多个过滤组件，以使所述多个过滤组件分别根据所述类型标识对所述请求事件进行过滤，所述多个过滤组件被分别关联至日志生成框架中的多个接口组件，所述多个接口组件分别对应于多个日志文件；

日志生成单元603，被配置为在接收到任一所述过滤组件过滤并发送的目标事件后，根据所述目标事件生成目标日志，并将所述目标日志存储在关联至所述任一过滤组件的接口组件所对应的日志文件中。

可选的，所述多个过滤组件与所述多个接口组件一一对应，所述多个接口组件被分别配置有用于指定不同日志文件的配置参数。

可选的，所述多个接口组件还分别配置有用于指定不同目标字段的字段参数，所述日志生成单元603还被配置为：

从所述目标事件所对应的目标字段中提取字段信息，并生成包含所述字段信息的目标日志。

可选的，所述请求事件的类型包括用户操作事件和系统测试事件。

可选的，所述多个过滤组件包括用于过滤并发送所述用户操作事件的第一过滤组件和用于过滤并发送所述系统测试事件的第二过滤组件，所述多个接口组件包括关联至所述第一过滤组件的第一接口组件和关联至所述第二过滤组件的第二接口组件，其中：

所述第一接口组件被配置有用于指定运行日志文件的配置参数，所述运行日志文件用于存储所述日志生成框架生成的运行请求日志，所述运行请求日志被根据连接至所述日志生成框架的业务系统在正常运行状态下产生的业务请求所生成；

所述第二接口组件被配置有用于指定测试请求日志文件的配置参数，所述测试请求日志文件用于存储所述日志生成框架生成的测试请求日志，所述测试请求日志被根据所述业务系统在测试状态下产生的测试请求所生成。

可选的，任一所述过滤组件采用下述过滤规则对所述请求事件进行过滤：

若所述请求事件的类型标识为预设标识，则发送所述请求事件；否则，

若所述请求事件的类型标识为所述预设标识之外的其他标识，则不发送所述请求事件。

图7是根据本公开的实施例示出的一种电子设备的示意框图。例如，电子设备700可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理等。

参照图7，电子设备700可以包括以下一个或多个组件：处理组件702，存储器704，电源组件706，多媒体组件708，音频组件710，输入/输出(I/O)的接口712，传感器组件714，以及通信组件718。

处理组件702通常控制电子设备700的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件702可以包括一个或多个处理器720来执行指令，以完成上述日志生成方法或者日志生成方法的全部或部分步骤。此外，处理组件702可以包括一个或多个模块，便于处理组件702和其他组件之间的交互。例如，处理组件702可以包括多媒体模块，以方便多媒体组件708和处理组件702之间的交互。

存储器704被配置为存储各种类型的数据以支持在电子设备700的操作。这些数据的示例包括用于在电子设备700上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器704可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件706为电子设备700的各种组件提供电力。电源组件706可以包括电源管理系统，一个或多个电源，及其他与为电子设备700生成、管理和分配电力相关联的组件。

多媒体组件708包括在电子设备700和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件708包括一个前置摄像头和/或后置摄像头。当电子设备700处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件710被配置为输出和/或输入音频信号。例如，音频组件710包括一个麦克风(MIC)，当电子设备700处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器704或经由通信组件718发送。在一些实施例中，音频组件710还包括一个扬声器，用于输出音频信号。

I/O接口712为处理组件702和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件714包括一个或多个传感器，用于为电子设备700提供各个方面的状态评估。例如，传感器组件714可以检测到电子设备700的打开/关闭状态，组件的相对定位，例如所述组件为电子设备700的显示器和小键盘，传感器组件714还可以检测电子设备700或电子设备700一个组件的位置改变，用户与电子设备700接触的存在或不存在，电子设备700方位或加速/减速和电子设备700的温度变化。传感器组件714可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件714还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件714还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

图像采集组件716可以用于采集被摄对象的图像数据，以形成关于被摄对象的图像，并可以对该图像进行必要的处理。该图像采集组件716可以包括相机模组，相机模组中的图像传感器(Sensor)通过镜头感应来自被摄对象的光线，将得到的感光数据提供给图像信号处理器(ISP，Image Signal Processing)，由后者根据感光数据生成对应于被摄对象的图像。其中，上述图像传感器可以为CMOS传感器或CCD传感器，当然，也可以为红外传感器、深度传感器等；相机模组可以内置在电子设备700中，也可以为电子设备700的外接模组；上述ISP可以内置在相机模组中，也可以外挂在上述电子设备中(不在相机模组内)。

通信组件718被配置为便于电子设备700和其他设备之间有线或无线方式的通信。电子设备700可以接入基于通信标准的无线网络，如WiFi，运营商网络(如2G、3G、4G或5G)，或它们的组合。在一个示例性实施例中，通信组件718经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件718还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在本公开一实施例中，电子设备700可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述日志生成方法或者日志生成方法。

在本公开一实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器704，上述指令可由电子设备700的处理器720执行以完成上述日志生成方法或者日志生成方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本领域技术人员在考虑说明书及实践这里公开的公开后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

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

以上对本公开实施例所提供的方法和装置进行了详细介绍，本文中应用了具体个例对本公开的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本公开的方法及其核心思想；同时，对于本领域的一般技术人员，依据本公开的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本公开的限制。