CN112685274A

CN112685274A - Log generation method and device, electronic equipment and storage medium

Info

Publication number: CN112685274A
Application number: CN202011599686.2A
Authority: CN
Inventors: 尹航
Original assignee: Beijing Dajia Internet Information Technology Co Ltd
Current assignee: Beijing Dajia Internet Information Technology Co Ltd
Priority date: 2020-12-29
Filing date: 2020-12-29
Publication date: 2021-04-20

Abstract

The disclosure relates to a log generation method, a log generation device, an electronic device and a storage medium. The method comprises the following steps: receiving a request event containing a type identifier, wherein the type identifier is used for indicating the event type of the request event; sending the request event to a plurality of preset filtering components so that the plurality of filtering components respectively filter the request event according to the type identification, wherein the plurality of filtering components are respectively associated to a plurality of interface components in a log generation framework, and the plurality of interface components respectively correspond to a plurality of log files; and after receiving a target event which is filtered and sent by any one filtering component, generating a target log according to the target event, and storing the target log in a log file corresponding to an interface component associated to any one filtering component. According to the scheme, effective isolation aiming at the system log can be realized according to the request event.

Description

Log generation method and device, electronic equipment and storage medium

Technical Field

The present disclosure relates to the field of software programming, and in particular, to a log generation method and apparatus, an electronic device, and a storage medium.

Background

At present, a business system built depending on the internet usually generates a corresponding system log in the process of operation or maintenance. For example, in the operation process of the service system, a request event corresponding to the method invocation request may generate an operation log such as a user behavior log, a system operation log, and the like. For another example, in the process of performing a stress test on a business system or a certain service, the system or the service is not always taken off line, but an online test is performed during the normal operation of the system or the service, so as to generate a corresponding test request log.

In the related art, logs generated by a service system are generally stored in a pre-designated log file in a time sequence for subsequent log processing. However, as the service functions provided by the service system are more and more abundant, the types and the number of the logs generated by the service system are gradually increased, and the storage mode is difficult to realize efficient log classification and cannot meet the increasingly diverse log management requirements.

Disclosure of Invention

The present disclosure provides a log generation method, apparatus, electronic device, and storage medium to at least solve the technical problems in the related art. The technical scheme of the disclosure is as follows:

according to a first aspect of the embodiments of the present disclosure, a log generation method is provided, including:

receiving a request event containing a type identifier, wherein the type identifier is used for indicating the event type of the request event;

sending the request event to a plurality of preset filtering components so that the plurality of filtering components respectively filter the request event according to the type identification, wherein the plurality of filtering components are respectively associated to a plurality of interface components in a log generation framework, and the plurality of interface components respectively correspond to a plurality of log files;

and after receiving a target event which is filtered and sent by any one filtering component, generating a target log according to the target event, and storing the target log in a log file corresponding to an interface component associated to any one filtering component.

Optionally, the plurality of filtering components correspond to the plurality of interface components one to one, and the plurality of interface components are respectively configured with configuration parameters for specifying different log files.

Optionally, the multiple interface components are further configured with field parameters for specifying different target fields, and the generating a target log according to the target event includes:

and extracting field information from a target field corresponding to the target event, and generating a target log containing the field information.

Optionally, the type of the request event includes a user operation event and a system test event.

Optionally, the plurality of filtering components include a first filtering component for filtering and sending the user operation event and a second filtering component for filtering and sending the system test event, and the plurality of interface components include a first interface component associated to the first filtering component and a second interface component associated to the second filtering component, wherein:

the first interface component is configured with configuration parameters for specifying a running log file for storing a running request log generated by the log generation framework, the running request log being generated according to a service request generated by a service system connected to the log generation framework in a normal operation state;

the second interface component is configured with configuration parameters for specifying a test request log file for storing a test request log generated by the log generation framework according to a test request generated by the service system in a test state.

Optionally, any of the filtering components filters the request event by using the following filtering rules:

if the type identifier of the request event is a preset identifier, sending the request event; if not, then,

and if the type identifier of the request event is other than the preset identifier, not sending the request event.

According to a second aspect of the embodiments of the present disclosure, there is provided a log generation system, including:

the filtering components are respectively used for filtering and sending different types of request events according to type identifiers carried by the request events, wherein the type identifiers are used for indicating the event types of the request events;

the log generation framework comprises a plurality of interface components, the interface components are respectively configured with configuration parameters used for specifying different log files, and the log generation framework is used for generating a target log according to a target event sent after being filtered by any filtering component and storing the target log in a log file specified by the interface component related to the filtering component.

Optionally, the log generation framework is a callback log framework, the filtering component is a filtering component constructed based on the callback log framework, and the interface component is an accessory component constructed based on the callback log framework; the callback log framework is used for generating a target log according to a target event sent after any filtering component filters and storing the target log in a log file designated for the accessory component associated with the any filtering component.

the configuration parameters configured for the first interface component are used for specifying an operation log file, the operation log file is used for storing an operation request log generated by the log generation framework, and the operation request log is generated according to a service request generated by a service system connected to the log generation system in a normal operation state;

the configuration parameters configured for the second interface component are used for specifying a test log file, the test request log file is used for storing a test request log generated by the log generation framework, and the test request log is generated according to a test request generated by the service system in a test state.

Optionally, the configuration parameters for specifying different log files include multiple file names and/or multiple file storage addresses, where the multiple file names are the file names of multiple different log files, and the multiple file storage addresses store different log files.

According to a third aspect of the embodiments of the present disclosure, there is provided a log generating apparatus, including:

an event receiving unit configured to receive a request event containing a type identifier, wherein the type identifier is used for indicating an event type of the request event;

an event sending unit, configured to send the request event to a plurality of preset filtering components, so that the plurality of filtering components respectively filter the request event according to the type identifier, the plurality of filtering components are respectively associated to a plurality of interface components in a log generation framework, and the plurality of interface components respectively correspond to a plurality of log files;

and the log generation unit is configured to generate a target log according to the target event after receiving the target event filtered and sent by any one of the filter assemblies, and store the target log in a log file corresponding to an interface assembly associated with the any one of the filter assemblies.

Optionally, the plurality of interface components are further respectively configured with field parameters for specifying different target fields, and the log generation unit is further configured to:

According to a fourth aspect of the embodiments of the present disclosure, there is provided an electronic apparatus, including:

a processor;

a memory for storing the processor-executable instructions;

wherein the processor is configured to execute the instructions to implement the log generation method as described in any of the embodiments of the first aspect above.

According to a fifth aspect of the embodiments of the present disclosure, a storage medium is provided, where instructions, when executed by a processor of an electronic device, enable the electronic device to perform the log generation method described in any one of the above first aspects.

According to a sixth aspect of embodiments of the present disclosure, there is provided a computer program product comprising a computer program and/or instructions which, when executed by a processor, implement the log generation method of any of the embodiments of the first aspect described above.

The technical scheme provided by the embodiment of the disclosure at least brings the following beneficial effects:

according to the embodiment of the disclosure, on the basis of the existing log generation framework, the scheme realizes a plurality of filtering components and a plurality of interface components associated with the filtering components, thereby forming a log generation system. And then the log generation system is utilized to realize the filtering of the request event according to the type identification of the request event, and after a corresponding target log is generated according to the target event output after being filtered by a certain filtering component, the target log is stored in a log file corresponding to the structural component related to the filtering component. Because each filtering component in the log generation system is associated with each interface component, and each structure component corresponds to each log file, corresponding system logs can be generated according to different request events obtained by filtering each filtering component respectively through the scheme, and then each system log is stored in the log file corresponding to each filtering component respectively, that is, different types of system logs are stored in different storage spaces, so that effective isolation for the system logs is realized.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the disclosure and are not to be construed as limiting the disclosure.

FIG. 1 is a schematic diagram illustrating a structure of a log generation system according to an embodiment of the present disclosure;

FIG. 2 is a flow diagram illustrating a method of log generation according to an embodiment of the present disclosure;

FIG. 3 is a schematic diagram illustrating a method of configuring a log generation framework, according to an embodiment of the present disclosure;

FIG. 4 is a schematic diagram illustrating a configured log generation system, according to an embodiment of the present disclosure;

FIG. 5 is a flow diagram illustrating another method of log generation according to an embodiment of the present disclosure;

FIG. 6 is a schematic block diagram illustrating a log generation apparatus in accordance with an embodiment of the present disclosure;

fig. 7 is a block diagram illustrating an electronic device in accordance with an embodiment of the present disclosure.

Detailed Description

In order to make the technical solutions of the present disclosure better understood by those of ordinary skill in the art, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings.

It should be noted that the terms "first," "second," and the like in the description and claims of the present disclosure and in the above-described drawings are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the disclosure described herein are capable of operation in sequences other than those illustrated or otherwise described herein. The implementations described in the exemplary embodiments below are not intended to represent all implementations consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present disclosure, as detailed in the appended claims.

Therefore, the present disclosure provides a log generating system, which implements a plurality of filtering components and a plurality of interface components associated therewith based on an existing log generating framework, wherein each interface component corresponds to each different log file, and any log file is used for storing a system log generated based on a request event filtered by the filtering component associated with the corresponding interface component. And further provides a log method based on the log generation system: and after generating a corresponding target log according to the target event output after filtering by a certain filtering component, storing the target log in a log file corresponding to a structural component associated to the filtering component. The log generation system and the log generation method realize effective isolation aiming at the system log.

Fig. 1 is a schematic mechanism diagram of a log generation system according to an exemplary embodiment of the present specification. As shown in FIG. 1, the system can include a log generation framework and a plurality of filtering components, wherein:

In the log generating system shown in fig. 1, n filter components, such as filter component 1, filter component 2 … …, filter component n, etc., may be included; the log generation framework comprises n interface components such as an interface component 1, an interface component 2 … … and an interface component n, wherein any filter component is respectively associated to at least one interface component, and any interface component respectively corresponds to at least one log file. And any filter component sends the filtered target event to the log generation framework, and the target event is used for generating a corresponding target log and is stored in a log file corresponding to the interface component associated with the filter component.

In this embodiment, the log processing device may be connected to a service system of the network service, and therefore the request event may be a request event (or referred to as a request) such as a method call request, a component call request, a function call request, and the like generated by the service system. For example, in a scenario where the service system performs a stress test while providing a normal network service for a user, a method invocation request generated in the service system may include a service request (often corresponding to a real user operation) generated by a normal account and a test request generated by a test account, where the purpose of the present solution is to: and respectively generating an operation request log and a test request log for the service request and the test request, and respectively storing the operation request log and the test request log, thereby realizing log isolation so as to effectively analyze the test result. For another example, in a scene where the business system performs gray level update, a first type account uses (before update) old version software and a second type account uses (after update) new version software in all accounts corresponding to the business system, and at this time, the purpose of the scheme is: and generating corresponding old version logs and new version logs for account requests generated by the first type of account and the second type of account respectively, and storing the old version logs and the new version logs respectively, thereby realizing log isolation so as to compare and analyze new version software and version software.

In order to realize the isolation of logs corresponding to different requests, the scheme needs to construct a filtering component aiming at a request event, so that a corresponding filtering rule needs to be determined firstly. The filtering rules may be set manually by background personnel, adopt default settings of the system, or adopt historical filtering rules of the historical filtering component, which is not limited by the embodiments of the present disclosure. In one embodiment, any filtering component may implement filtering the request event according to the type identification of the request event, that is, the following filtering rules are adopted: if the type identifier of the request event is a preset identifier, sending the request event; otherwise, if the type identifier of the request event is other than the preset identifier, the request event is not sent. By the method, the filtering component can determine whether to send the request event only by comparing the type identifier of the request event with the preset identifier, so that the request event is filtered quickly.

In an embodiment, the log generation framework of the scheme may be a callback log framework, the filtering component may be a filter constructed based on the callback log framework, and the interface component may be an accessory component constructed based on the callback log framework; the callback log framework is used for generating a target log according to a target event sent after filtering by any filter and storing the target log in a log file designated for the accessory component associated with any filter. Further, the callback log framework may adopt a logback log framework in the related art, so that each Filter may include a Filter constructed based on the logback log framework, and each accessory component may include an append component constructed based on the logback log framework. Accordingly, the type identifier at this time may include thread variable information (or called ThreadLocal information) of the request event. The filtering component and the interface component are constructed on the basis of a mature and effective logback log frame, so that the log generation efficiency can be improved, the running stability of the configured log generation frame can be ensured, and the log processing efficiency can be ensured finally.

In one embodiment, the event types of the request events to be filtered may include two types: user operation events (corresponding to service requests in a normal operation state of the service system) and system test events (corresponding to test requests in a test state of the service system). Correspondingly, the number of the filter assemblies and the interface assemblies at this time is at least two.

Further, the plurality of filtering components may include a first filtering component for filtering and transmitting user operation events and a second filtering component for filtering and transmitting system test events, and the plurality of interface components may include a first interface component associated to the first filtering component and a second interface component associated to the second filtering component, wherein: the configuration parameters configured for the first interface component are used for specifying an operation log file, the operation log file is used for storing an operation request log generated by a log generation framework, and the operation request log is generated according to a service request generated by a service system connected to the log generation system in a normal operation state; and the configuration parameters configured for the second interface component are used for specifying a test log file, the test log file is used for storing a test request log generated by a log generation framework, and the test request log is generated according to a test request generated by the service system in a test state. At this time, according to the log generation system, a corresponding system log can be generated for the request event of the service system, and is divided into a service request log and a test request log according to the event type of the request event, and then the service request log and the test request log are respectively stored in an operation log file and a test log file, so that effective isolation of the two types of log files is realized, and the test realization of the service system is facilitated.

In an embodiment, the configuration parameters respectively specified for the interface components include a plurality of file names and/or a plurality of file storage addresses, where the plurality of file names are respectively file names of a plurality of different log files, and the plurality of file storage addresses respectively store different log files. Therefore, at least one log file is respectively appointed for any interface component in a file name or file storage address mode, and the correspondence between the log file and the interface component is ensured.

Based on the log generation system, the following embodiments of the present disclosure also provide a log generation method. Fig. 2 is a flowchart illustrating a method of generating a log according to an exemplary embodiment of the present disclosure. As shown in fig. 2, the method is applied to a log processing device such as a server, and may include the following

steps

202 and 206.

Step 202, receiving a request event containing a type identifier, where the type identifier is used to indicate an event type of the request event.

Step 204, sending the request event to a plurality of preset filtering components, so that the plurality of filtering components respectively filter the request event according to the type identifier, wherein the plurality of filtering components are respectively associated to a plurality of interface components in a log generation framework, and the plurality of interface components respectively correspond to a plurality of log files.

In this embodiment, the log processing device may be connected to a service system of the network service, and thus the request event may be a request event (or referred to as a request) such as a method call request, a component call request, a function call request, and the like generated by the service system. The service system may add a type identifier to any request event when the request event is generated, or the log processing device may call other preset request classification services to classify any received request event and add a type identifier.

The type identifier of any request event may be an account ID generating the request event. For example, in a scenario where the service system performs a stress test while providing a normal network service for a user, a method invocation request generated in the service system may include a service request generated by a normal account (often corresponding to a real user operation) and a test request generated by a test account. At this time, the account ID of any account may be used as the type identifier of the request event generated by the account, so that after receiving the request event, the multiple filtering components in the log processing device may determine the event type of the request event according to the account ID carried by the multiple filtering components: a service request or a test request. Or in a scene of performing gray level update by the service system, the first type account uses (before update) old version software and the second type account uses (after update) new version software in all accounts corresponding to the service system, and at this time, the version number can be used as a type identifier of a corresponding request event, for example, an event identifier of a request event generated by the first type account is "VO", an event identifier of a request event generated by the second type account is "VN", and the like. Alternatively, the type identifier of any request event may also be a preset special identifier, such as a special character "S1", "S2", and the like, which is not limited by the embodiments of the present disclosure.

In one embodiment, in the case that the request event itself carries or is marked with a type identifier, the filtering rule followed by any filtering component may be: if the type identifier of the request event is a preset identifier, sending the request event; otherwise, if the type identifier of the request event is other than the preset identifier, the request event is not sent. Wherein, the above-mentioned "sending request event" can be understood as that the filtering component sends the request event to its associated interface component; moreover, in the case of not sending the request event, the filtering component may choose to discard the request event or record the filtering result of the request event, which is not described in detail. It can be seen that the filtering component constructed according to the rule may only send (or release) the request event corresponding to the preset identifier, thereby facilitating to implement accurate filtering of the request event. In the foregoing embodiment, in the case of constructing two filtering components, the first filtering component may only pass the service request and the second filtering component only passes the test request, or the first filtering component may only pass the service request generated by the first type of account and the second filtering component may only pass the service request generated by the second type of account.

In an embodiment, in addition to constructing a plurality of filter components, the method may construct a plurality of interface components based on the log generation framework and perform corresponding configuration, where configuration parameters corresponding to any interface component may be used to specify a corresponding log file, and interface components corresponding to respective interface components are different. And further, each filtering component can be correspondingly associated to each interface component so as to realize the configuration of the log generation framework. The log file specified by the configuration parameter of any interface component is used for storing the system log corresponding to the target event output by the filtering component associated with the interface component, namely, because different interface components correspond to different log files, the system log generated according to the request event output by different filtering components can be stored in different log files, thereby realizing effective isolation of the system log.

In an embodiment, the specific number of the filter components and the interface components in this embodiment may be consistent with the type of the request event, that is, in a case that the request events to be processed may be classified into n types, the number of the filter components and the interface components that are constructed is n, so that any filter component may filter only one of the request events. Even more, multiple filter components may correspond one-to-one to multiple interface components, which may be configured with configuration parameters for specifying different log files, respectively. Therefore, the system logs corresponding to different types of request events are distributed to different log files through the one-to-one correspondence relationship between the filtering assemblies and the interface assemblies and the configuration parameters respectively configured for the interface assemblies.

In an embodiment, the number of the filter assemblies and the number of the interface assemblies may be two; the event types of the request event at this time may include two types: the log generation system can ensure that any request event is determined as a user operation event or a system test event, further distribute the system logs of the request event to the log files corresponding to the corresponding events, and ensure that the system logs corresponding to the similar request events are distributed to the same log file.

Further, the two filtering components at this time may include a first filtering component for filtering and sending a user operation event and a second filtering component for filtering and sending a system test event, and accordingly, the two interface components may be a first interface component associated to the first filtering component and a second interface component associated to the second filtering component, respectively; wherein: the configuration parameters configured for the first interface component are used for specifying an operation log file, the operation log file is used for storing an operation request log generated by a log generation framework, and the operation request log is generated according to a service request generated by a service system connected to the log generation system in a normal operation state; and the configuration parameters configured for the second interface component are used for specifying a test log file, the test log file is used for storing a test request log generated by a log generation framework, and the test request log is generated according to a test request generated by the service system in a test state. On one hand, the operation log file is assigned to the first interface component and the detection log file is assigned to the second interface component, so that the operation request log generated according to the service request (namely, the system log generated by the service system in the normal operation state) can be stored in the operation log file, and meanwhile, the test request log generated according to the system detection event (namely, the request log generated by the service system in the test state) can be stored in the test log file, thereby realizing accurate log isolation. On the other hand, because the operation log file is used for storing the system log generated by the service system in the normal operation state, the system log generated according to the user operation event in the test process and the system log generated according to the user operation event when the test is not performed are stored in the same log file, the effective compatibility of the system log corresponding to the user operation event is realized, namely the compatibility of the log generation in the non-test process is realized, the configuration parameters are changed less when the method is applied, and the operation stability of a log generation frame is favorably ensured.

Step 206, after receiving the target event filtered and sent by any one of the filter assemblies, generating a target log according to the target event, and storing the target log in a log file corresponding to an interface assembly associated with the any one of the filter assemblies.

In an embodiment, the plurality of interface components are further respectively configured with field parameters for specifying different target fields, and at this time, the log processing device may extract field information from the target field corresponding to the target event, and then generate a target log including the field information according to a preset rule. For example, when the request event sequentially includes fields such as "event type, creation time, creation account ID, function name of called function, calling method, validity duration, and verification information (e.g., token)", the field values of "test request, 2020.11.01.08.10.30, AAA, and Regression function (Regression function)" of the four fields "of" event type, creation time, creation account ID, and function name of called function "may be sequentially extracted, and then the four fields are sorted according to a preset order to generate a corresponding system log. The specific process of generating the log may refer to the records in the related art, and is not described herein again.

As described above, the log generation method of the present disclosure may be used to configure a logback log framework, and the configured framework may be used to generate logs and implement log isolation. With reference to fig. 2 to fig. 4, a process of configuring and generating a log generation system based on a logback log framework and generating a target log by using the system is described in detail below by taking a service system stress test scenario as an example.

FIG. 3 is a flow diagram illustrating another method of configuring a log generation framework in accordance with an embodiment of the present disclosure; as shown in fig. 3, the method is applied to a log processing device, and may include the following steps:

in step 302a, the log processing device determines a filter rule.

In an embodiment, a preset identifier for filtering the request event may be preset for the type identifier of the request event, and then the filtering rule is specified according to the preset identifier. Specifically, the request event may be sent (i.e., released) to the corresponding interface component when the type identifier of the request event is the preset identifier; otherwise, the request event is not sent (i.e. not released) when the type identifier of the request event is other than the preset identifier, and the request event may be discarded or the related information of the request event may be recorded. Correspondingly, after any filtering component constructed according to the filtering rule receives any request event, two possibilities exist for the filtering result of the request event: sending the request event to an interface component, wherein the sent request event is a target event of a log to be generated; or not send the request event. It is understood that, the multiple types of identifiers corresponding to the filtering rules may be mutually exclusive, and at this time, any request event may be input into each filtering component, and one or only one filtering component may output the request event as a target event (the filtering component may be referred to as a target filtering component). Or, any request event may also carry multiple types of identifiers (for example, event tags are used as type components for filtering), and then any request event may be simultaneously filtered by multiple filtering components and released, that is, the request event may be simultaneously sent to multiple interface components, and corresponding system logs are respectively generated according to each type identifier and respectively allocated to multiple log files.

In an embodiment, the filtering rule may be set manually by a background person, a default setting of the system is adopted, or a history filtering rule of the history filtering component is adopted, which is not limited by the embodiment of the disclosure.

In step 304a, the log processing device builds a first filter component and a second filter component based on the logback log framework.

As shown in fig. 4, the present embodiment is described by taking the construction of two filter elements as an example. In the scheme of this embodiment, a logback log frame is adopted, so that the first Filter component (e.g., Filter1) and the second Filter component (e.g., Filter2) can be implemented by inheriting ch.qos.

According to the filtering rules, any filtering component can only filter and output the request events meeting the preset identification corresponding to the filtering component. For example, in a scenario where a stress test is performed while providing a normal network service for a user, the request event may include a service request generated by a normal account and a test request generated by a test account, where the first filtering component may only filter and pass the service request, and the second filtering component may only filter and pass the test request. Therefore, after the log generation device sends any received request event to the first filtering component and the second filtering component: if the request event is a service request, the request event is released by the first filtering component; otherwise, if the request event is a test request, it is passed through by the second filter element.

Step 302b, the log processing device builds a first interface component and a second interface component based on the logback log framework.

In this embodiment, the log processing device may further build an interface component based on the logback log framework. The first interface component (e.g., the applier 1) and the second interface component (e.g., the applier 2) may be implemented by inheriting ch.qos.logback.core.applier.applier under a JAVA environment, and a specific implementation process may refer to records in the related art, which is not described herein again.

Step 304b, the log processing device configures the first interface component and the second interface component.

Further, the log processing device may configure the first interface component and the second interface component, for example, may configure parameters such as a log format, a log content field, and a file name of a log file stored in the log, which correspond to the system log respectively. The configured log format and content field is used for specifying the format and content of the generated system log, and the configured file name is used for specifying the storage location of the generated system log (in which file the generated system log is to be distributed and stored). The specific process of configuring the configuration parameters of the interface component can be referred to in the related art, and is not described herein again.

In this embodiment, as an exemplary implementation, steps 302a to 304a may be performed to construct the filter component, and then steps 302b to 304b may be performed to construct and configure the interface component; alternatively, as another exemplary embodiment, steps 302b-304b may be performed to build and configure the interface component before steps 302a-304a are performed to build the filter component. In other words, there is no necessary sequence between the "constructing and filtering component" and the "constructing and configuring interface component", and the sequence can be adjusted according to the actual situation. Of course, both can be performed simultaneously, and the embodiment of the disclosure does not limit this.

In step 306, the log processing device associates the interface component to the filter component.

In an embodiment, after the filter component is built and the interface component is built and configured, the log processing device may associate the first interface component to the first filter component and associate the second interface component to the second filter component. In order to ensure that the system logs generated according to the request events sent after being filtered by the filtering components are distributed to different log files, different file names of the log files can be configured for the first interface component and the second interface component. For example, a file name "application _ log" may be configured for the first interface component, and a file name "application _ test.log" may be configured for the second interface component, so as to indicate, by the file name, that the log file corresponding to the first interface component is used for storing the operation request log, and the log file corresponding to the second interface component is used for storing the test request log.

For example, the above-described configuration for the first interface component and the second interface component may be implemented by interface component configuration code. Taking a JAVA language environment as an example, in the environment, the file name "application log" of the log file corresponding to the first interface component inherited from the first filter component can be specified by an inherited type statement, so that the log file is specified for the first interface component to be used for saving the operation request log; similarly, the file name "application log" of the log file corresponding to the second interface component inherited from the second filter component can be specified by the statement of the inheritance type, so that the log file is specified for the first interface component to be used for saving the test request log.

In addition, the interface component configuration code for the first interface component may specify a corresponding filtering rule for the first filtering component with which it is associated, such as filtering and sending only the service request; similarly, the interface component configuration code for a second interface component may specify corresponding filter rules for its associated second filter component, such as filtering and sending test requests only. Of course, other filtering rules may be configured for the two filtering components, and are not described in detail.

Fig. 4 shows a schematic structural diagram of a log generation system formed by the configured filter component, interface component, and logback log framework. It can be seen that the input end of the log generation system is connected to the service system, and the logback log framework includes a first interface component and a second interface component, which are configured by a unified log configuration file (of course, different log configuration files may also be used to configure the first interface component and the second interface component respectively), and the log configuration file may include the configuration code. The input ends of the first interface component and the second interface component are respectively connected with the first filtering component and the second filtering component, and the output ends of the first interface component and the second interface component are respectively connected with a user log file application.

At this time, request events such as a method call request, a component call request, a function call request, and the like generated by the service system are simultaneously input to the first filtering component and the second filtering component of the log generation system, and the request events are respectively filtered by the first filtering component and the second filtering component. And the request event output after being filtered by any one filtering component enters a corresponding interface component, and then the logback log framework generates a system log (an operation request log is generated corresponding to the first interface component, and a test request log is generated corresponding to the second interface component) according to the configuration file corresponding to the interface component, and the system log is distributed to a corresponding log file for storage.

Fig. 5 is a flow chart illustrating another log generation method according to an embodiment of the present disclosure. Taking the request event as an example of repeatedly invoking the request, as can be seen from fig. 5, the specific process of generating the request log and implementing log isolation by using the log generation system shown in fig. 4 may include the following

steps

502 and 508.

In step 502, the log processing device receives a request event generated by a service system.

In the operation process of the business system, a method calling request (hereinafter referred to as a request event) is generated according to the account behavior so as to call a corresponding method module to respond to the account behavior. The request event may be caused by a user operation of a normal account (hereinafter referred to as a user account) or caused by a test instruction of a test account, so that the request event generated by the service system may be a service request or a test request.

In this embodiment, it is assumed that the thread variable information of the request event holds an account ID that generates the request event, and the account ID is used as its own type identifier. It can be understood that account characteristics of corresponding accounts can be recorded in the first filtering component and the second filtering component, for example, account characteristics of a user account can be recorded in the first filtering component, account characteristics of a test account can be recorded in the second filtering component, the account characteristics may be an account registration time period, an account number segment interval, and the like, which is not limited in the embodiment of the present disclosure.

In step 504, the filter component filters the request events.

After receiving any request event, the log generation system sends the request event to the first filtering component and the second filtering component at the same time, and the first filtering component and the second filtering component respectively filter the request event according to the type identification of the request event. If the request event is a service request, the service request is released by the first filtering component and discarded by the second filtering component; if the request event is a test request, the test request is passed through the second filter element and discarded by the first filter element.

Step 506, the logback log framework generates a request log according to the configuration parameters of the interface component.

If the request event is a service request, the service request released by the first filtering component is sent to the first interface component, and then the logback log frame can generate a system log (i.e. an operation request log) according to the configuration parameters corresponding to the first interface component; correspondingly, if the request event is a test request, the test request released by the second filtering component is sent to the second interface component, and then the logback log framework can generate a system log (i.e., a test request log) according to the configuration parameters corresponding to the second interface component. Specifically, for any request event, the logback log framework may obtain specified field information from the request event, and generate a request log according to the obtained field information and a log generation rule specified in the configuration parameters, which is not described herein again in the specific process.

In step 508, the log processing device stores the system log in a corresponding log file.

Because the configuration parameter corresponding to the first interface component already designates the operation log file as application log, and the configuration parameter corresponding to the second interface component already designates the test log file as application _ test log, if the request event is a service request, the log processing device can store the operation request log generated by the logback log frame in the operation log file application log, and if the request event is a test request, the log processing device can store the test request log generated by the logback log frame in the test log file application _ test log, thereby realizing effective isolation of the system logs corresponding to the service request and the test request respectively.

Correspondingly to the embodiment of the log generation method, the disclosure also provides a log generation device and an embodiment of the log generation device.

Fig. 6 is a schematic block diagram illustrating a log generation apparatus according to an embodiment of the present disclosure. The log generating device shown in this embodiment may be applied to log processing devices such as a server, where the server may be a physical server including an independent host, a virtual server borne by a host cluster, a cloud server, and the like; of course, the log generating apparatus may also be applied to a terminal, where the terminal includes but is not limited to a mobile phone, a tablet computer, a wearable device, a personal computer, and other electronic devices, and the embodiments of the present disclosure do not limit this.

As shown in fig. 6, the log generating means may include:

an event receiving unit 601 configured to receive a request event containing a type identifier, where the type identifier is used to indicate an event type of the request event;

an event sending unit 602, configured to send the request event to a plurality of preset filtering components, so that the plurality of filtering components respectively filter the request event according to the type identifier, where the plurality of filtering components are respectively associated to a plurality of interface components in a log generation framework, and the plurality of interface components respectively correspond to a plurality of log files;

the log generating unit 603 is configured to, after receiving a target event filtered and sent by any one of the filter components, generate a target log according to the target event, and store the target log in a log file corresponding to an interface component associated with the any one of the filter components.

Optionally, the plurality of interface components are further configured with field parameters for specifying different target fields, respectively, and the log generating unit 603 is further configured to:

Fig. 7 is a schematic block diagram illustrating an electronic device in accordance with an embodiment of the present disclosure. For example, the electronic device 700 may be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, an exercise device, a personal digital assistant, and the like.

Referring to fig. 7, electronic device 700 may include one or more of the following components: processing component 702, memory 704, power component 706, multimedia component 708, audio component 710, input/output (I/O) interface 712, sensor component 714, and communication component 718.

The processing component 702 generally controls overall operation of the electronic device 700, such as operations associated with display, telephone calls, data communications, camera operations, and recording operations. The processing component 702 may include one or more processors 720 to execute instructions to perform the log generation method or all or part of the steps of the log generation method described above. Further, the processing component 702 may include one or more modules that facilitate interaction between the processing component 702 and other components. For example, the processing component 702 may include a multimedia module to facilitate interaction between the multimedia component 708 and the processing component 702.

The memory 704 is configured to store various types of data to support operations at the electronic device 700. Examples of such data include instructions for any application or method operating on the electronic device 700, contact data, phonebook data, messages, pictures, videos, and so forth. The memory 704 may be implemented by any type or combination of volatile or non-volatile memory devices such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disks.

The power supply component 706 provides power to the various components of the electronic device 700. The power components 706 may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power for the electronic device 700.

The multimedia component 708 includes a screen that provides an output interface between the electronic device 700 and a user. In some embodiments, the screen may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive an input signal from a user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundary of a touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 708 includes a front facing camera and/or a rear facing camera. The front camera and/or the rear camera may receive external multimedia data when the electronic device 700 is in an operation mode, such as a photographing mode or a video mode. Each front camera and rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.

The audio component 710 is configured to output and/or input audio signals. For example, the audio component 710 includes a Microphone (MIC) configured to receive external audio signals when the electronic device 700 is in an operational mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signals may further be stored in the memory 704 or transmitted via the communication component 718. In some embodiments, audio component 710 also includes a speaker for outputting audio signals.

The I/O interface 712 provides an interface between the processing component 702 and peripheral interface modules, which may be keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to: a home button, a volume button, a start button, and a lock button.

The sensor assembly 714 includes one or more sensors for providing various aspects of status assessment for the electronic device 700. For example, the sensor assembly 714 may detect an open/closed state of the electronic device 700, the relative positioning of components, such as a display and keypad of the electronic device 700, the sensor assembly 714 may also detect a change in the position of the electronic device 700 or a component of the electronic device 700, the presence or absence of user contact with the electronic device 700, orientation or acceleration/deceleration of the electronic device 700, and a change in the temperature of the electronic device 700. The sensor assembly 714 may include a proximity sensor configured to detect the presence of a nearby object without any physical contact. The sensor assembly 714 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 714 may also include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

The image capture component 716 can be configured to capture image data of a subject to form an image of the subject and can perform necessary processing on the image. The Image capture assembly 716 may include a camera module, in which an Image Sensor (Sensor) senses light from a subject through a lens, and provides the obtained light sensing data to an Image Signal Processor (ISP), which generates an Image corresponding to the subject according to the light sensing data. The image sensor may be a CMOS sensor or a CCD sensor, and may also be an infrared sensor, a depth sensor, or the like; the camera module may be built in the electronic device 700, or may be an external module of the electronic device 700; the ISP may be built in the camera module or may be externally hung on the electronic device (not in the camera module).

The communication component 718 is configured to facilitate wired or wireless communication between the electronic device 700 and other devices. The electronic device 700 may access a wireless network based on a communication standard, such as WiFi, a carrier network (such as 2G, 3G, 4G, or 5G), or a combination thereof. In an exemplary embodiment, the communication component 718 receives a broadcast signal or broadcast related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 718 further includes a Near Field Communication (NFC) module to facilitate short-range communications. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID) technology, infrared data association (IrDA) technology, Ultra Wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

In an embodiment of the present disclosure, the electronic device 700 may be implemented by one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), controllers, micro-controllers, microprocessors or other electronic elements for performing the log generation method or the log generation method described above.

In an embodiment of the present disclosure, there is also provided a non-transitory computer-readable storage medium, such as the memory 704 comprising instructions executable by the processor 720 of the electronic device 700 to perform the log generation method or log generation method described above. For example, the non-transitory computer readable storage medium may be a ROM, a Random Access Memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

It will be understood that the present disclosure is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

It is noted that, in the present disclosure, relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.

The method and apparatus provided by the embodiments of the present disclosure are described in detail above, and the principles and embodiments of the present disclosure are explained herein by applying specific examples, and the above description of the embodiments is only used to help understanding the method and core ideas of the present disclosure; meanwhile, for a person skilled in the art, based on the idea of the present disclosure, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present disclosure should not be construed as a limitation to the present disclosure.

Claims

1. A method of log generation, comprising:

2. The method of claim 1, wherein the plurality of filter components correspond one-to-one to the plurality of interface components, and wherein the plurality of interface components are each configured with configuration parameters for specifying different log files.

3. The method of claim 2, wherein the plurality of interface components are further configured with field parameters for specifying different target fields, respectively, and wherein generating a target log from the target event comprises:

4. The method of claim 1, wherein the types of request events include user operation events and system test events.

5. The method of claim 4, wherein the plurality of filtering components includes a first filtering component for filtering and sending the user-operated events and a second filtering component for filtering and sending the system-testing events, and wherein the plurality of interface components includes a first interface component associated with the first filtering component and a second interface component associated with the second filtering component, wherein:

6. A log generation system, comprising:

7. A log generating apparatus, comprising:

8. An electronic device, comprising:

a processor;

a memory for storing the processor-executable instructions;

wherein the processor is configured to execute the instructions to implement the log generation method of any of claims 1 to 5.

9. A computer-readable storage medium, wherein instructions in the storage medium, when executed by a processor of an electronic device, enable the electronic device to perform the log generation method of any of claims 1 to 5.

10. A computer program product comprising computer programs/instructions, characterized in that the computer programs/instructions, when executed by a processor, implement the log generation method of any of claims 1 to 5.