Log processing method, electronic device, and computer-readable storage medium

Abstract

The present application relates to the field of computers, and discloses a log processing method, an electronic device, and a computer-readable storage medium. The method comprises: a target device acquires log records of a target session; in the case where the target session ends abnormally, the target device determines all log records of the target session as target log records; in the case where the target session ends normally, the target device acquires some log records from among all the log records of the target session as the target log records; and the target device stores the target log records.

Description

Log processing method, electronic device, and computer-readable storage medium

[0001] Cross-reference

[0002] The present application claims priority from the Chinese patent application No. 202410839648.1 filed on June 26, 2024, and entitled "Log processing method, electronic device, and computer-readable storage medium", the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0003] The present application belongs to the field of computers, and particularly relates to a log processing method, an electronic device, and a computer-readable storage medium. BACKGROUND

[0004] In the related art, stability abnormalities, service abnormalities, and the like often occur in mobile terminals, servers, and the like. In order to facilitate analysis of the reasons for the abnormalities of the devices, the running information of the devices is usually recorded by logs.

[0005] The conventional log recording method records and stores the running information of the devices without distinction, and the running information of the devices includes communication session information. However, as the devices run, the logs stored by the conventional log recording method often contain a large amount of redundant information. These redundant log information not only occupies a large amount of storage space of the devices, but also has very low effectiveness for subsequent analysis of the reasons for the abnormalities of the devices. SUMMARY

[0006] The present application provides a log processing method, an electronic device, and a computer-readable storage medium.

[0007] In a first aspect, the present application provides a log processing method, including: a target device acquiring log records of a target session; in the case that the target session ends abnormally, the target device determining all log records of the target session as target log records; in the case that the target session ends normally, the target device acquiring part of the log records from all log records of the target session as target log records; and the target device storing the target log records.

[0008] In a second aspect, an embodiment of the present application provides a log processing method, comprising: receiving, by a management device, a target log record of a target session transmitted by a target device, the target log record comprising at least one of a first log record and a second log record, the first log record comprising a partial log record obtained from all log records of the target session in a case where the target session ends normally, and the second log record comprising all log records of the target session in a case where the target session ends abnormally; the type of the target log record comprising a component log record and an application log record; scanning, by the management device, the target log record to obtain a scanning result; in a case where the scanning result indicates that an abnormality exists and the abnormality occurs in the application log record, obtaining, by the management device, a failure flow record in the application log record; and obtaining, by the target device, a root cause of the abnormality based on the failure flow record.

[0009] In a third aspect, an embodiment of the present application provides an electronic device, comprising: a processor and a memory, the memory storing programs or instructions executable on the processor, and the programs or instructions being executed by the processor to implement the steps of the method according to the first aspect or the second aspect.

[0010] In a fourth aspect, an embodiment of the present application provides a readable storage medium, the readable storage medium storing programs or instructions, and the programs or instructions being executed by a processor to implement the steps of the method according to the first aspect or the second aspect.

[0011] In a fifth aspect, an embodiment of the present application provides a computer program product, the computer program product comprising a computer program, and the computer program being executed by a processor to implement the steps of the method according to the first aspect or the second aspect. BRIEF DESCRIPTION OF DRAWINGS

[0012] FIG. 1 is a schematic diagram of an example network deployment environment of a log processing method according to an embodiment of the present application.

[0013] FIG. 2 is a flowchart of a log processing method according to an embodiment of the present application.

[0014] FIG. 3 is a flowchart of a log processing method according to an embodiment of the present application.

[0015] FIG. 4 is a flowchart of a log processing method according to an embodiment of the present application.

[0016] FIG. 5 is a flowchart of a log processing method according to an embodiment of the present application.

[0017] FIG. 6 is a flowchart of a log processing method according to an embodiment of the present application.

[0018] FIG. 7 is a flowchart of another log processing method according to an embodiment of the present application.

[0019] FIG. 8 is a structural block diagram of a log processing apparatus according to an embodiment of the present application.

[0020] FIG. 9 is a structural block diagram of another log processing apparatus according to an embodiment of the present application.

[0021] FIG. 10 is another structural block diagram of a log processing apparatus according to an embodiment of the present application.

[0022] FIG. 11 is a schematic diagram of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0023] The technical solutions in the embodiments of the present application will be clearly described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some, but not all of the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art belong to the scope of protection of the present application.

[0024] The terms "first", "second", and the like in the specification and claims of the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be exchanged under appropriate circumstances, so that the embodiments of the present application can be implemented in an order other than that illustrated or described herein, and the objects distinguished by "first", "second", etc. are generally a category, and do not limit the number of objects, for example, the first object can be one or more. In addition, "and / or" in the specification and claims indicates at least one of the connected objects, and the character " / ", generally indicates that the front and rear associated objects are in an "or" relationship.

[0025] As described in the background section, the running information of a mobile terminal, a server, and the like is usually recorded in a log, so that the cause of an abnormality of the device can be analyzed by the running information recorded in the log. In the related art, the running information of the device is usually recorded and stored without distinction, and the running information can include communication session information. However, as the device runs, the logs stored by the log recording method used in the related art can contain a large amount of redundant information, and these redundant log information not only occupies a large amount of storage space of the device, but also has very low effectiveness for subsequent analysis of the cause of the abnormality of the device.

[0026] In the log processing method provided in the embodiments of the present application, the target device acquires log records of a target session, in the case of abnormal end of the target session, the target device determines all log records of the target session as target log records; in the case of normal end of the target session, the target device acquires part of the log records from all log records of the target session as target log records; and the target device stores the target log records. In this way, the target device determines all log records of the target session with abnormal end as target log records, so that the target log records can be effectively used for subsequent analysis of the reason for abnormality of the target session, and only part of the log records are acquired from all log records of the target session with normal end as target log records, thereby reducing the storage amount of the target log records, so as to solve the problem that the log information stored in the related art occupies a large amount of storage space and is extremely low in effectiveness for subsequent analysis of the reason for abnormality of the device.

[0027] In addition, in the related art, in the process of storing log records by using a disk, frequent write operations are performed on the disk, which affects the performance of the disk. In the embodiments of the present application, two storage elements (i.e., a first storage element and a second storage element) are used, the first storage element is used to store log records of a target session, and the second storage element (such as a disk) is used to store target log records, the target log records being part of the log records of the target session. In this way, since the log records of the target session are first stored in the first storage element, and then the target log records are stored in the second storage element, the target log records being part of the log records of the target session, the number of write operations on the disk can be greatly reduced compared with the related art, and the performance of the disk is improved. At the same time, compared with the related art of using one storage element, the use of two storage elements to store log records can fully utilize the storage space of the first storage element for caching, and part of important log records are selected from the storage space of the first storage element as target log records, so that the log records stored in the second storage element later have higher usability.

[0028] In the embodiments of the present application, the data read-write rate of the first storage element can be greater than the data read-write rate of the second storage element. For example, the first storage element is an internal memory, and the second storage element is an external memory. In this way, the read-write capability of the first storage element can be fully utilized, and the processing efficiency is improved.

[0029] It should be noted that, for non-conversational log recording, the embodiments of the present application can also use the storage mode of two storage elements. The embodiments of the present application use two storage elements (i.e. the first storage element and the second storage element) to store non-conversational log records in the first storage element and target log records in the second storage element (such as a disk), and the target log records are partially selected from the non-conversational log records. In this way, the target log records are partially selected from the non-conversational log records, and the target log records are stored in the second storage element after the non-conversational log records are stored in the first storage element. Therefore, compared with the related art, the number of write operations on the disk can be greatly reduced, and the performance of the disk can be improved. At the same time, compared with the related art using one storage element, the two storage elements can fully utilize the storage space of the first storage element for caching, and a part of important log records in the storage space of the first storage element can be selected as target log records, so that the log records stored in the second storage element have higher availability.

[0030] In addition, for the stored log records, the related art usually uses a manual retrieval and analysis method for the stored log records for fault analysis of the target device. However, in the case of continuous growth of the stored log records, the workload of the manual retrieval and analysis method for the fault analysis of the target device is extremely large.

[0031] In the log processing method provided by the embodiments of the present application, the target device can scan the target log records (the target log records can include two types of component log records and application log records) to obtain a scanning result. In the case that the scanning result indicates that there is an exception and the exception occurs in the component log records, the target device sends a first target message containing component exception information to the management device. In the case that the scanning result indicates that there is an exception and the exception occurs in the application log records, the target device obtains a failure flow record indicating an exception in the application log records, and the failure flow record indicates an exception. The target device obtains the root cause of the application exception based on the failure flow record. In this way, the component exception information and the root cause of the application exception are determined by the target device, and the manual retrieval and analysis of the fault of the target device are avoided to reduce the workload.

[0032] In a process of obtaining a root cause of causing an application exception based on the failure flow record of the target device, a fault matching model can be utilized, which is used to determine the root cause of causing the exception based on the failure flow record. The fault matching model can be set on the target device itself or on a remote device, such as a management device on the network side. Taking the case that the fault matching model is set on the target device itself as an example, the target device can input the failure flow record into the fault matching model, and then obtain the root cause output by the fault matching model. In this way, the root cause of causing the exception can be efficiently obtained based on the fault matching model, and the efficiency and accuracy of obtaining the root cause of causing the exception are greatly improved.

[0033] The log processing method provided by the embodiments of the present application can be executed by a target device, which can be an electronic device. The electronic device can be, for example, a terminal device such as a computer, a tablet computer, a mobile phone, etc., or a server. In particular, the target device can also be an embedded device with limited storage resources. It should be understood that the management device mentioned in the following can be a device located on the network side, and the management device and the target device can be different devices. For example, the target device can be a terminal device, and the management device can be a server.

[0034] It should be understood that the description of the same term or case in the embodiments of the present application can be referred to. That is, the description of a certain term or case in one embodiment can also be applied to the description of the term or case in other embodiments, as long as it is logically consistent.

[0035] The method provided by the embodiments of the present application will be described in detail below by specific embodiments and application scenarios in combination with the accompanying drawings.

[0036] FIG. 1 is a schematic diagram of an example network deployment environment of a log processing method provided by the embodiments of the present application. As shown in FIG. 1, the log processing method provided by the embodiments of the present application can involve a target device and a management device. The management device can be located in the Internet, and the target device can be in communication connection with the management device. The target device can be used to store log records and process the stored log records. The management device can be used to process log records. The fault matching model (used to determine the root cause of causing an exception) mentioned in the following can be set on the target device or the management device, which is not limited by the present application.

[0037] FIG. 2 is a flowchart of a log processing method provided by the embodiments of the present application. As shown in FIG. 2, the log processing method provided by the embodiments of the present application includes the following steps:

[0038] Step 210: The target device obtains log records of a target session.

[0039] The log processing method provided in the embodiments of the present application can be applied to the case that the target device interacts with the external device, and the target session can be a communication session. The target session is generated in the process that the target device interacts with the external device, and correspondingly, log records are generated for the target session. The log records can reflect various information of the session of the interaction parties, such as network connection information, message transmission information, and the like.

[0040] The log record in the embodiments of the present application can be a log information in a log, for example, a record information of a fault record occurring at a certain time point. A plurality of log records can form the complete content of the log.

[0041] In the embodiments of the present application, the log records of the target session that have not ended can be temporarily buffered in the first storage element of the target device before the target session ends. The log records belonging to the target session can be buffered in the first storage element according to a preset order (for example, according to the order of the record generation time of the log records) through the session mark (for example, the session ID of the target session) of the target session. When the target session ends, the target device can acquire the log records of the target session from the first storage element of the target device.

[0042] In a possible implementation, the target device can acquire the log records of the target session from the first storage element of the target device when the target session ends or when the target device receives a user instruction to perform session log record acquisition. The specific form of the user instruction to perform session log record acquisition is not limited, for example, the user operates a specified icon on the screen of the target device to trigger the generation of an acquisition instruction, and the acquisition instruction is used to instruct to acquire the log records of the target session.

[0043] In the embodiments of the present application, the log records of the target session can be stored in the first storage element of the target device. Further, in step 210, the log records of the target session can be acquired from the first storage element. The first storage element can be a main memory.

[0044] In step 220, when the target session ends abnormally, the target device determines all the log records of the target session as the target log records.

[0045] In the embodiments of the present application, the abnormal end of the target session can be the abnormal end of the target session caused by sudden power failure of the target device, the abnormal end of the target session caused by sudden death of the target device, and the like. The specific form of the abnormal end of the target session is not limited in the embodiments of the present application.

[0046] In the embodiment of the present application, before step 220, it can be judged whether the target session is abnormally ended. The log record of the target session can include the start and end time of the target session, the basic information of the interactive parties such as IP and the like. When it is identified that the field with the meaning of abnormality such as error, fail and the like appears in the log record of the target session, it can be judged that the target session is abnormally ended.

[0047] Step 230: In the case that the target session is normally ended, the target device obtains part of the log records from the whole log records of the target session as the target log records.

[0048] The embodiment of the present application does not limit the specific way in which the target device obtains part of the log records from the whole log records of the target session as the target log records. For example, the log record containing the specified keyword is taken as the target log record, and the log record meeting the certain time condition is taken as the target log record. In the embodiment of the present application, in the case that it is judged that the target session is normally ended, part of the log records from the whole log records of the target session can also be obtained as the target log records by the way selected by the user. That is, the part of the log records obtained from the whole log records of the target session in step 230 can be the log record selected by the user. In the embodiment of the present application, the target device can display the whole log of the target session in the normally ended case to the user through the display screen, and receive the log record selected by the user as the target log record.

[0049] In the embodiment of the present application, the judgment result of whether the target session is abnormally ended can be matched with the preset filtering rule. The filtering rule is specifically that when the judgment result shows that the target session is abnormally ended, the whole log record of the target session is kept, and when the judgment result shows that the target session is normally ended, part of the log records obtained from the whole log records of the target session is taken as the target log record.

[0050] Step 240: The target device stores the target log record.

[0051] In the embodiments of the present application, the determined target log record can be stored in a second storage element of the target device. The second storage element is different from the first storage element. In addition, when a specified condition is met, the target device can transmit a target log record to the management device, the target log record including at least one of a first log record and a second log record, the first log record including partial log records obtained from all log records of the target session when the target session ends normally, and the second log record including all log records of the target session when the target session ends abnormally. Moreover, the type of the target log record can include a component log record and an application log record. In this way, the management device can receive the target log record of the target session transmitted by the target device, scan the target log record to obtain a scanning result, and then perform further analysis and processing.

[0052] It should be understood that, in the embodiments of the present application, the log record of the target session in step 210 can be a log record obtained from a first storage element of the target device, the first storage element being used to store log records of the target session before the target session ends. The first storage element can be an internal memory, such as a random access memory. The target log record in step 240 is stored in a second storage element of the target device. The second storage element can be an external memory, such as a solid state disk, a flash memory, etc. In this way, compared with the related art which uses one storage element, the use of two storage elements to store log records can make full use of the storage space of the first storage element for caching, and select a part of important log records from the storage space of the first storage element as the target log record, so that the log records stored in the second storage element subsequently have higher availability.

[0053] In the embodiments of the present application, the target device obtains a log record of a target session; in the case where the target session ends abnormally, the target device determines all log records of the target session as a target log record; in the case where the target session ends normally, the target device obtains partial log records from all log records of the target session as a target log record; and the target device stores the target log record. In this way, the target device determines all log records of the target session that ends abnormally as a target log record, so that the target log record can be effectively used for subsequent analysis of the cause of the abnormality of the target session. Moreover, only partial log records are obtained from all log records of the target session that ends normally as a target log record, which reduces the storage amount of the target log record, thereby solving the problem that the log information stored in the related art occupies a large amount of storage space and has very low effectiveness for subsequent analysis of the cause of the abnormality of the device.

[0054] Please refer to FIG. 3, which is a flowchart of a log processing method according to an embodiment of the present application. As shown in FIG. 3, the log processing method according to an embodiment of the present application includes the following steps:

[0055] Step 310: The target device acquires log records of the target session.

[0056] Step 320: In the case that the target session ends abnormally, the target device determines all log records of the target session as target log records.

[0057] Step 330: In the case that the target session ends normally, the target device acquires part of the log records of the target session as target log records.

[0058] Step 340: The target device acquires log records of non-session.

[0059] In an embodiment of the present application, the log records of non-session can be temporarily buffered in a first storage element of the target device. In the case that the target device receives a user instruction to acquire log records of non-session, the target device can stop updating the first storage element with log records, and acquire log records of non-session from the first storage element of the target device. That is, the log records of non-session in step 340 can be log records acquired from the first storage element of the target device. The first storage element can be an internal storage, such as a random access memory.

[0060] It should be understood that step 340 is not necessarily performed after step 310. Step 310 can be performed first, and then step 340 can be performed. Alternatively, step 340 can be performed first, and then step 310 can be performed. Alternatively, step 310 and step 340 can be performed simultaneously.

[0061] Step 350: The target device acquires part of the log records of non-session as target log records.

[0062] In an embodiment of the present application, after the target device acquires log records of non-session, part of the log records of non-session can be acquired as target log records by a user-selected manner. That is, the part of the log records of non-session acquired in step 350 are user-selected log records. Specifically, the target device can display all log records of non-session to a user through a display screen, and receive user-selected log records as target log records.

[0063] Step 360: The target device stores the target log records.

[0064] In the embodiment of the present application, the determined target log record can be stored in a second storage element of the target device. The second storage element can be an external storage, such as a solid state disk or a flash.

[0065] In the embodiment of the present application, only part of the non-session log records are obtained as target log records, thereby reducing the storage amount of the target log records, and solving the problem that the log information stored in the related art occupies a large amount of storage space.

[0066] In addition, in the embodiment of the present application, the log records of the target session that has not ended and the non-session log records can be temporarily buffered in a first storage element. The first storage element can be an internal storage, such as a random access memory. After the target log record is determined, the target log record is stored in a second storage element. The second storage element can be an external storage, such as a solid state disk or a flash. The storage rate of the first storage element can be greater than that of the second storage element. In this way, the storage space of the first storage element can be fully utilized for buffering, and part of the important log records in the storage space of the first storage element are selected as target log records, so that the log records stored in the second storage element have higher availability. At the same time, the data read-write rate of the first storage element can be greater than that of the second storage element. For example, the first storage element is an internal storage, and the second storage element is an external storage. In this way, the read-write capability of the first storage element can be fully utilized, and the processing efficiency is improved.

[0067] FIG. 4 is a flowchart of a log processing method provided by an embodiment of the present application. As shown in FIG. 4, the log processing method provided by the embodiment of the present application includes the following steps:

[0068] In step 410, the target device obtains the log record of the target session.

[0069] The log processing method provided by the embodiment of the present application can be applied to the case that the target device interacts with an external device. The target session can be a communication session. During the interaction between the target device and the external device, a session is performed, and accordingly, log records are generated for the session. These log records can reflect various information of the session between the two parties, such as network connection information and message transmission information.

[0070] The log record in the embodiment of the present application can be a piece of log information in a log, such as a piece of record information of a fault record occurring at a time point. A plurality of log records can form the specific content of a log.

[0071] In an embodiment of the present application, the target device can stop updating the log record to the first storage element in the case that the target session ends or the user indicates to perform session log record acquisition, and acquire the log record of the target session from the first storage element of the target device.

[0072] Step 420: determining a failure flow record from the whole log record of the target session in the case that the target session ends abnormally, the failure flow record indicating that the target session ends abnormally.

[0073] In an embodiment of the present application, whether the target session ends abnormally can be determined, and the log record of the target session can include the start and end time of the target session, basic information of the interactive parties such as IP and the like, when the field with the meaning of abnormality such as error, fail and the like is identified in the log record of the target session, it is considered that the target session ends abnormally.

[0074] In an embodiment of the present application, in the case that the target session ends abnormally, the failure flow record can be determined from all the flow records of the whole log record of the target session. For example, the whole log record of the target session includes flow record a, flow record b, flow record c and flow record d, and the flow record c indicates that the target session ends abnormally, then the flow record c is determined as the failure flow record.

[0075] Step 430: marking the failure flow record.

[0076] In an embodiment of the present application, after the failure flow record is determined from all the flow records of the whole log record of the target session, the failure flow record can be marked, for example, a character is marked in the failure flow record to mark the flow record as the failure flow record.

[0077] Step 440: the target device determines the whole log record of the target session which ends abnormally as the target log record.

[0078] Step 450: in the case that the target session ends normally, the target device acquires part of the log record from the whole log record of the target session as the target log record.

[0079] Step 460: the target device stores the target log record.

[0080] In an embodiment of the present application, in the case that the target session ends abnormally, the failure flow record indicating that the target session ends abnormally is determined from the whole log record of the target session and marked as the target log record for storage, so that when the target device fault reason is analyzed based on the target log record subsequently, the target device fault reason can be analyzed conveniently based on the failure flow record indicating that the target session ends abnormally which is marked in the target log record.

[0081] FIG. 5-1 is a flowchart of a log processing method according to an embodiment of the present application. As shown in FIG. 5-1, the log processing method according to an embodiment of the present application includes the following steps:

[0082] Step 510: The target device acquires log records of a target session.

[0083] Step 515: In the case where the target session ends abnormally, the target device determines a failure flow record from all log records of the target session, the failure flow record indicating that the target session ends abnormally.

[0084] In the embodiment of the present application, it can be determined whether the target session ends abnormally. For example, the log records of the target session can include the start and end time of the target session, and basic information of the interactive parties, such as IP and other information. When it is identified that there is a field with the meaning of abnormality, such as error or fail, in the log records of the target session, it is considered that the target session ends abnormally.

[0085] In the embodiment of the present application, in the case where it is determined that the target session ends abnormally, the failure flow record can be determined from all flow records of all log records of the target session. For example, the log records of the target session include flow record a, flow record b, flow record c and flow record d, and the flow record c indicates that the target session ends abnormally. Then, the flow record c is determined as the failure flow record.

[0086] In the embodiment of the present application, the failure flow record can be marked after it is determined from all log records of the target session.

[0087] Step 520: The target device determines all log records of the target session that ends abnormally as target log records.

[0088] Step 525: In the case where the target session ends normally, the target device acquires part of the log records of the target session as target log records from all log records of the target session.

[0089] Step 530: The target device stores the target log records, the type of the target log records including at least one of component log records and application log records.

[0090] In the embodiment of the present application, the target log records include component log records and / or application log records. In the embodiment of the present application, the component can be a functional component used in the running process of the target device, such as a kernel, an operating system, an FTP interface, and the like. In some cases, the component in the embodiment of the present application can be a bottom component relied on in the running process of the computer. The component log records (for example, log records for the operating system) are used to record the information of the component relied on by the application (i.e., application program) in the running process.

[0091] Step 535: The target device scans the target log record to obtain a scanning result.

[0092] Step 540: In a case where the scanning result indicates that there is an exception and the exception occurs in the component log record, the target device sends a first target message containing component exception information to the management device.

[0093] In the embodiment of the present application, the management device is an electronic device different from the target device, for example, the target device is a terminal and the management device is a server. The target device scans the target log record to obtain a scanning result. In a case where the scanning result indicates that there is an exception in the target log record and the exception occurs in the component log record, the target device sends a first target message containing component exception information to the management device. The first target message containing component exception information can include component state exception start and end time points and an exception state overview.

[0094] In the embodiment of the present application, the management device can store the received first target message in a classified manner according to at least one of the IP of the target device, the name of the abnormal component of the target device, and the time sequence of the component exception of the target device, and the storage manner can be circular storage.

[0095] In the embodiment of the present application, before the target device sends the first target message to the management device in step 540, the target device can filter and reorganize the component log record according to component function points; the target device obtains the target component function point corresponding to the log record in which the exception occurs in the component log record. Correspondingly, the component exception information contained in the first target message can include component exception information associated with the target component function point. In this way, the management device can obtain component exception information associated with the target component function point through the first target message, and then analyze or process the component exception information.

[0096] The process of filtering and reorganizing the component log record according to component function points by the target device will be further introduced below taking the component log record of an operating system as an example. In the embodiment of the present application, the operating system component can include the following function points: link state, protocol stack, and memory of the operating system. The target device can filter and reorganize the component log record of the operating system according to the function points such as the link state, protocol stack, and memory of the operating system, and obtain the target component function point corresponding to the log record in which the exception occurs in the component log record, for example, the target component function point in which the exception occurs in the operating system, such as the link state exception. The component exception information sent by the target device to the management device in step 540 can be information associated with the target component function point, for example, information about the link state exception of the operating system.

[0097] Step 545: In the case that the scanning result indicates that there is an exception and the exception occurs in the application log record, the target device acquires a failure flow record in the application log record, the failure flow record indicating that the exception occurs.

[0098] In the embodiments of the present application, in the case that the target session exception ends, a failure flow record indicating that the target session exception occurs is determined from all log records of the target session and is marked and stored. In the case that the target device scans the target log record and the scanning result indicates that there is an exception in the target log record and the exception occurs in the application log record, the target device acquires a failure flow record in the application log record, the failure flow record indicating that the exception occurs.

[0099] Step 550: The target device acquires a root cause causing the exception based on the failure flow record.

[0100] In the embodiments of the present application, step 550 has multiple implementation manners.

[0101] In one embodiment of the present application, in step 550, the target device acquires a root cause causing the exception based on the failure flow record, which can specifically include the following steps: the target device sends a second target packet to the management device, the second target packet containing the failure flow record and being used for the management device to determine the root cause causing the exception by a fault matching model, the fault matching model being used for determining the root cause causing the exception based on the failure flow record. After the management device determines the root cause causing the exception by the fault matching model, the root cause causing the exception is sent to the target device, and the target device receives the root cause causing the exception sent by the management device.

[0102] In another embodiment of the present application, in step 550, the target device acquires a root cause causing the exception based on the failure flow record, which can specifically include the following steps: the target device inputs the failure flow record into a fault matching model, the fault matching model being used for determining the root cause causing the exception based on the failure flow record; and the target device acquires the root cause output by the fault matching model. The fault matching model can be a local fault matching model, so that the target device can quickly acquire the root cause output by the fault matching model.

[0103] After the root cause causing the exception is acquired in step 550, the target device can record the root cause causing the exception in the application log record. In this way, the root cause causing the exception can be directly acquired based on the application log record subsequently, and the efficiency of acquiring the root cause causing the exception is greatly improved.

[0104] In the embodiment of the present application, the target device can scan the stored target log record, and determine the root cause of the abnormality based on the scanning result, thereby avoiding relying on manual retrieval and analysis of the fault of the target device to reduce the workload. Moreover, the type of the target log record includes at least one of a component log record and an application log record. The root cause of the abnormality can be obtained in a differentiated manner for the two types, which takes into account the processing efficiency and accuracy. In particular, for the case where the scanning result indicates that there is an abnormality and the abnormality occurs in the application log record, the accuracy of the obtained root cause can be ensured through the fault matching model.

[0105] In the embodiment of the present application, as shown in FIG. 5-2, the target device can scan the target log record, and determine whether an abnormality occurs in the component log record based on the scanning result. In the case where the scanning result indicates that there is an abnormality and the abnormality occurs in the component log record, the target device sends a first target message containing component abnormality information to the management device, and the management device stores the component abnormality information. Specifically, the component abnormality information can be stored in categories according to at least one of the IP of the target device, the abnormal component name of the target device, and the time sequence of the component abnormality of the target device. In the case where the scanning result indicates that there is an abnormality and the abnormality occurs in the application log record, the target device sends a second target message containing the failure flow record to the management device, and the management device determines the root cause of the abnormality through the fault matching model. Specifically, the failure flow record can be input to the fault matching model, and then the fault matching model determines the root cause of the abnormality based on the received failure flow record. The fault matching model in the embodiment of the present application can store the component abnormality information, and when the fault matching model receives the failure flow record in the application log record, the failure flow record can be matched with the component abnormality information stored in the fault matching model to obtain the information of the abnormal component on which the application running depends, and then the root cause of the abnormality is obtained. The management device can send the root cause of the abnormality to the target device, and the target device stores it.

[0106] FIG. 6 is a flowchart of a log processing method provided by an embodiment of the present application. As shown in FIG. 6, the log processing method provided by the embodiment of the present application includes the following steps:

[0107] Step 610: A target device obtains a log record of a target session.

[0108] In the embodiments of the present application, the log records of the target session that have not been ended are temporarily buffered in the first storage element of the target device before the target session ends. The log records belonging to the target session can be buffered in the first storage element in a preset order (for example, in the order of the recording time of the log records) through the session mark of the target session (for example, the session ID of the target session). When the target session ends, the target device can acquire the log records of the target session from the first storage element of the target device.

[0109] In a possible implementation, the target device can stop updating the log records to the first storage element and acquire the log records of the target session from the first storage element of the target device when the target session ends or the user indicates to acquire the session log records.

[0110] Step 613: In the case where the target session ends abnormally, determine the failure flow record from the entire log records of the target session, and the failure flow record indicates that the target session ends abnormally.

[0111] In the embodiments of the present application, it can be judged whether the target session ends abnormally, for example, the log records of the target session include the start and end time of the target session, the basic information of the interaction parties such as IP and other information. When it is identified that the log records of the target session include the fields with abnormal meanings such as error and fail, it is considered that the target session ends abnormally.

[0112] In the embodiments of the present application, in the case where it is judged that the target session ends abnormally, the failure flow record can be determined from all the flow records of the entire log records of the target session. For example, the entire log records of the target session include flow record a, flow record b, flow record c and flow record d, and the flow record c indicates that the target session ends abnormally, and then the flow record c is determined as the failure flow record.

[0113] Step 616: Label the failure flow record.

[0114] In the embodiments of the present application, after the failure flow record is determined from all the flow records of the entire log records of the target session, the failure flow record can be labeled, for example, the failure flow record is labeled with a specified character in the failure flow record.

[0115] Step 619: The target device determines the entire log records of the target session that ends abnormally as the target log records.

[0116] Step 622: In the case where the target session ends normally, the target device acquires part of the log records from the entire log records of the target session as the target log records.

[0117] ​​​​​​​​​In the embodiment of the present application, in the case that it is judged that the target session is normally ended, the target log record can be obtained from part of the whole log records of the target session as the target log record by a manner selected by the user.

[0118] In the embodiment of the present application, the judging result of whether the target session is abnormally ended can be matched with the preset filtering rule, and the filtering rule can be that the whole log records of the target session are kept when the judging result shows that the target session is abnormally ended. In the case that the judging result shows that the target session is normally ended, part of the whole log records of the target session is obtained as the target log record.

[0119] Step 625: The target device obtains the non-session log record.

[0120] Step 628: The target device obtains part of the non-session log record as the target log record from the non-session log record.

[0121] In the embodiment of the present application, after the target device obtains the non-session log record, part of the whole non-session log record can be obtained as the target log record by a manner selected by the user.

[0122] Step 631: The target device stores the target log record, and the type of the target log record includes at least one of the component log record and the application log record.

[0123] In the embodiment of the present application, the determined target log record can be stored in the second storage element of the target device.

[0124] In the embodiment of the present application, the target log record includes the component log record and / or the application log record. The component log record (for example, the log record of the operating system) is used to record the information of the component on which the application (application program) depends.

[0125] Step 634: The target device scans the target log record to obtain a scanning result.

[0126] Step 637: In the case that the scanning result indicates that there is an exception and the exception appears in the component log record, the target device sends a first target message to the management device, and the first target message contains the component exception information.

[0127] In one embodiment of the present application, before the target device sends the first target message to the management device in step 637, the target device can filter and reorganize the component log record according to the component function point; the target device obtains the target component function point corresponding to the log record in which the exception appears in the component log record; and the component exception information includes the component exception information associated with the target component function point.

[0128] For example, for component log records of the operating system, the target device can filter and reorganize the component log records of the operating system according to functional points such as link state, protocol stack, and memory of the operating system, and obtain a target component functional point corresponding to a log record that appears abnormally in the component log records, for example, the component log records of the operating system appear abnormally, and the target component functional point that appears abnormally in the operating system is obtained, for example, the link state is abnormal. In step 637, the target device sends the component abnormal information in the first target message to the management device and information associated with the target component functional point, for example, information about the link state abnormality of the operating system.

[0129] In the embodiments of the present application, the management device is an electronic device different from the target device, for example, the target device is a terminal, and the management device is a server on the network side. The target device scans the target log record, and if the scanning result indicates that the target log record is abnormal and the abnormality appears in the component log record, the target device sends a first target message containing component abnormal information to the management device. The first target message containing the component abnormal information can include the start and end time points of the component state abnormality and an abnormality state summary.

[0130] In the embodiments of the present application, the management device can store the received first target message according to the IP of the target device, the abnormal component name of the target device, and the time sequence of the component abnormality of the target device, and the storage mode can be circular storage.

[0131] Step 640: In the case where the scanning result indicates that there is an abnormality and the abnormality appears in the application log record, the target device obtains a failure flow record in the application log record, and the failure flow record indicates that the abnormality appears.

[0132] In the embodiments of the present application, as discussed in step 613, in the case where the target session abnormality ends, the failure flow record indicating that the target session appears abnormally is determined from all the log records of the target session and is stored after being marked. In the case where the target device scans the target log record, if the scanning result indicates that the target log record is abnormal and the abnormality appears in the application log record, the target device obtains a failure flow record in the application log record, and the failure flow record indicates that the abnormality appears.

[0133] Step 643: The target device obtains the root cause of the abnormality based on the failure flow record.

[0134] In an embodiment of the present application, in step 643, the target device obtains the root cause of the abnormality based on the failure flow record, which can include the following steps: the target device sends a second target packet to the management device, the second target packet containing the failure flow record and being used for the management device to determine the root cause of the abnormality by a fault matching model, the fault matching model being used to determine the root cause of the abnormality based on the failure flow record. After the management device determines the root cause of the abnormality by the fault matching model, the root cause of the abnormality is sent to the target device, and the target device receives the root cause sent by the management device.

[0135] In another embodiment of the present application, in step 643, the target device obtains the root cause of the abnormality based on the failure flow record, which can include the following steps: the target device inputs the failure flow record into a fault matching model, the fault matching model being used to determine the root cause of the abnormality based on the failure flow record; and the target device obtains the root cause output by the fault matching model.

[0136] In an embodiment of the present application, after the target device obtains the root cause of the abnormality, the target device can record the root cause in the application log record.

[0137] In an embodiment of the present application, the target device can scan the stored target log record, and determine the root cause of the abnormality based on the scanning result, thereby avoiding relying on manual retrieval and analysis of the fault of the target device, and reducing the workload. Moreover, the type of the target log record includes at least one of a component log record and an application log record. The root cause of the abnormality can be obtained in a differentiated manner for the two types, which takes into account the processing efficiency and accuracy. In particular, for the case where the scanning result indicates that there is an abnormality and the abnormality occurs in the application log record, the fault matching model can ensure the accuracy of the obtained root cause.

[0138] In an embodiment of the present application, the target device obtains the log record of a target session; in the case where the target session ends abnormally, the target device determines all the log records of the target session as the target log record; in the case where the target session ends normally, the target device obtains part of the log records from all the log records of the target session as the target log record; and the target device stores the target log record. In this way, the target device determines all the log records of the target session that ends abnormally as the target log record, so that the target log record can be effectively used for subsequent analysis of the cause of the abnormality of the target session. Moreover, only part of the log records are obtained from all the log records of the target session that ends normally as the target log record, thereby reducing the storage amount of the target log record, and thus solving the problem that the log information stored in the related art occupies a large amount of storage space and is extremely ineffective for subsequent analysis of the cause of the abnormality of the device.

[0139] It should be understood that the explanation of each step in the log processing method provided by the embodiments of the present application can be referred to each other. For example, the explanation of the steps in FIG. 5-1 and FIG. 6 can also be applied to each step in FIG. 2-FIG. 4. Similarly, for example, the explanation of the steps in FIG. 2-FIG. 4 can also be applied to each step in FIG. 5-1 and FIG. 6.

[0140] Please refer to FIG. 7, which is a flow chart of a log processing method provided by an embodiment of the present application. As shown in the figure, the log processing method provided by the embodiments of the present application includes the following steps:

[0141] Step 710: The management device receives the target log record of the target session transmitted by the target device, the target log record including at least one of the first log record and the second log record, and the type of the target log record including the component log record and the application log record.

[0142] In the embodiments of the present application, the target log record includes the first log record and / or the second log record, the first log record including the partial log record obtained from the entire log record of the target session in the case of normal end of the target session, and the second log record including the entire log record of the target session in the case of abnormal end of the target session; and the type of the target log record including the component log record and the application log record.

[0143] The log processing method provided by the embodiments of the present application can be applied to the case that the target device interacts with the external device, and the target session can be a communication session. In the process of the target device interacting with the external device, the session will be carried out, and accordingly, the log record will be generated for the session, which can reflect various information of the session of the interaction parties, such as network connection information, message transmission information, etc.

[0144] In the embodiments of the present application, before the end of the target session, the target device can temporarily cache the log record of the target session which has not ended in the first storage element of the target device. The log record belonging to the target session can be cached in the first storage element according to a preset order (for example, according to the order of the recording generation time of the log record) through the session mark of the target session (for example, the session ID of the target session). When the target session ends, the target device can obtain the log record of the target session from the first storage element of the target device.

[0145] In a possible implementation, the target device can stop updating the log record to the first storage element and obtain the log record of the target session from the first storage element of the target device in the case that the target session ends or the user indicates to carry out the session log record acquisition.

[0146] In the embodiment of the present application, before the target device transmits the target log record to the management device, it is determined whether the target session ends abnormally. The log record of the target session can include the start and end time of the target session, basic information of the interactive parties such as IP and other information. When it is identified that the log record of the target session includes a field with abnormal meaning such as error or fail, it is determined that the target session ends abnormally.

[0147] In the embodiment of the present application, when the target device determines that the target session ends abnormally, the failure flow record is determined from all the flow records of the complete log record of the target session. For example, the complete log record of the target session includes flow record a, flow record b, flow record c and flow record d. When the flow record c indicates that the target session ends abnormally, the flow record c is determined as the failure flow record, and the failure flow record is marked.

[0148] In the embodiment of the present application, after the failure flow record is determined from all the flow records of the complete log record of the target session, the failure flow record is marked, for example, a note is added to the failure flow record that the flow record is a failure flow record.

[0149] When the target session ends normally, the target device obtains part of the log record from the complete log record of the target session as the first log record. When it is determined that the target session ends normally, the part of the log record obtained from the complete log record of the target session is obtained as the first log record by a user-selected manner. When the target session ends abnormally, the target device obtains the complete log record of the target session as the second log record. The target device sends the first log record and the second log record to the management device.

[0150] In the embodiment of the present application, the target device can match the determination result of whether the target session ends abnormally with the preset filtering rule. The filtering rule is that when the determination result shows that the target session ends abnormally, the complete log record of the target session is retained, and when the determination result shows that the target session ends normally, part of the log record obtained from the complete log record of the target session is obtained as the target log record.

[0151] In the embodiment of the present application, the management device is an electronic device different from the target device, for example, the target device is a terminal and the management device is a network side server.

[0152] Step 720: The management device scans the target log record to obtain a scanning result.

[0153] In an embodiment of the present application, after the management device scans the target log record in step 720, if the scanning result indicates that there is an exception in the target log record and the exception occurs in the component log record, the management device can filter and reorganize the component log record according to component function points. For example, for the component log record of the operating system, the management device can filter and reorganize the component log record of the operating system according to function points such as the link state, protocol stack and memory of the operating system, and obtain the target component function point corresponding to the log record with the exception in the component log record, for example, the component log record of the operating system has an exception, and the information of the target component function point with the exception in the operating system is obtained, for example, the information of the link state exception. Moreover, the management device can send the information that the component log record has an exception to the target device. The component log record with the exception can include the IP of the target device, the exception component name of the target device and the time when the component exception of the target device occurs. After receiving the information that the component log record has an exception sent by the management device, the target device can store the information in the component log record.

[0154] Step 730: If the scanning result indicates that there is an exception and the exception occurs in the application log record, the management device obtains the failure flow record in the application log record, which indicates the exception.

[0155] In an embodiment of the present application, in the case that the target session exception ends, the failure flow record indicating the exception of the target session is determined from all the log records of the target session, marked and then stored. The management device scans the target log record, and if the scanning result indicates that there is an exception in the target log record and the exception occurs in the application log record, the management device obtains the failure flow record in the application log record, which indicates the exception. In the embodiment of the present application, the failure flow record with the exception in the application log record can be marked (for example, marked with a specified character), so that the management device can obtain the failure flow record in the application log record, which indicates the exception, through the mark.

[0156] Step 740: The management device obtains the root cause causing the exception based on the failure flow record.

[0157] In the embodiment of the present application, after the management device acquires the failure flow record in the application log record in step 730, the management device can input the failure flow record into a fault matching model, which is used to determine the root cause of the abnormality based on the failure flow record. Then, the root cause output by the fault matching model can be acquired by the management device. Specifically, the specific process in which the management device acquires the root cause of the abnormality based on the failure flow record in step 740 can be as follows: the management device inputs the failure flow record into the fault matching model, in which the component abnormality information is stored, and when the fault matching model receives the failure flow record in the application log record, the failure flow record is matched with the component abnormality information stored in the fault matching model to obtain the information of the abnormal component on which the application running depends, and then the root cause of the abnormality is obtained; and the management device acquires the root cause output by the fault matching model.

[0158] After the management device acquires the root cause output by the fault matching model, the management device can send the root cause to the target device, and after the target device acquires the root cause of the abnormality, the target device can record the root cause in the application log record. That is, after the root cause of the abnormality is acquired in step 740, the management device can send the root cause of the abnormality to the target device, so that the target device records the root cause in the application log record.

[0159] In the embodiment of the present application, after the management device scans the target log record, if the scanning result indicates that there is an abnormality and the abnormality occurs in the component log record, the management device can store the component abnormality information according to the IP of the target device, the abnormal component name of the target device, and the time sequence of the component abnormality of the target device, and the like, into the management device. If the scanning result indicates that there is an abnormality and the abnormality occurs in the application log record, the management device can determine the root cause of the abnormality through the fault matching model. Specifically, the failure flow record can be input into the fault matching model, and then the failure flow record received by the fault matching model is used to determine the root cause of the abnormality. The component abnormality information can be stored in the fault matching model, and when the fault matching model receives the failure flow record in the application log record, the failure flow record is matched with the component abnormality information stored in the fault matching model to obtain the information of the abnormal component on which the application running depends, and then the root cause of the abnormality is obtained. The management device can send the root cause of the abnormality to the target device for storage by the target device. In this way, the fault can be conveniently located.

[0160] In the embodiment of the present application, the management device can scan the stored target log record, and determine the root cause of the abnormality based on the scanning result, thereby avoiding relying on manual retrieval and analysis of the target device for failure, so as to reduce the workload. Moreover, the type of the target log record includes at least one of a component log record and an application log record. The differentiated manner can be used to obtain the root cause of the abnormality for the two types, so as to balance the processing efficiency and accuracy. In particular, in the case where the scanning result indicates that there is an abnormality and the abnormality occurs in the application log record, the fault matching model can ensure the accuracy of the obtained root cause.

[0161] FIG. 8 is a structural block diagram of log processing provided by an embodiment of the present application. Referring to FIG. 8, the log processing apparatus 800 provided by the embodiment of the present application includes:

[0162] The obtaining module 810 is configured to obtain log records of a target session.

[0163] The determining module 820 is configured to, in the case where the target session ends abnormally, determine all log records of the target session as target log records.

[0164] The obtaining module 810 is further configured to, in the case where the target session ends normally, obtain part of the log records from all log records of the target session as target log records.

[0165] The storage module 830 is configured to store the target log records.

[0166] In the log processing apparatus provided by the embodiment of the present application, the log records of the target session are obtained; in the case where the target session ends abnormally, the target device determines all log records of the target session as target log records; in the case where the target session ends normally, the target device obtains part of the log records from all log records of the target session as target log records; and the target device stores the target log records. In this way, the target device determines all log records of the target session that ends abnormally as target log records, so that the target log records can be effectively used for subsequent analysis of the cause of the abnormality of the target session. Moreover, only part of the log records are obtained from all log records of the target session that ends normally as target log records, so as to reduce the storage amount of the target log records, thereby solving the problem that the log information stored in the related art occupies a large amount of storage space and is extremely ineffective for subsequent analysis of the cause of the abnormality of the device.

[0167] In an embodiment of the present application, the part of the log records obtained from all log records of the target session are user-selected log records.

[0168] The storage module 830 can include a first storage element and a second storage element. In an embodiment of the present application, the log record of the target session is obtained from the first storage element of the storage module 830, and the first storage element is used to store the log record of the target session before the target session ends; and the target log record is stored in the second storage element of the target device.

[0169] In an embodiment of the present application, before the storage module 830 stores the target log record, the obtaining module 810 is further configured to obtain a non-session log record; and part of the log record is obtained from the non-session log record as the target log record.

[0170] In an embodiment of the present application, the part of the log record obtained from the non-session log record is the target log record selected by a user.

[0171] In an embodiment of the present application, the non-session log record is obtained from the first storage element of the storage module 830; and the target log record is stored in the second storage element of the storage module 830.

[0172] In an embodiment of the present application, the first storage element is an internal memory, and the second storage element is an external memory.

[0173] In an embodiment of the present application, the determining module 820 is further configured to determine a failure flow record from the entire log record of the target session in the case that the target session ends abnormally, and the failure flow record indicates that the target session ends abnormally. The log processing apparatus 800 further includes a marking module configured to mark the failure flow record.

[0174] In an embodiment of the present application, during the process of obtaining the log record of the target session, the obtaining module 810 is further configured to specifically obtain the log record of the target session in the case that the target session ends or a user indicates to obtain the log record of the target session.

[0175] In an embodiment of the present application, the type of the target log record includes at least one of a component log record and an application log record, and the component log record is used to record information of a component on which an application depends; and after the target log record is stored, the log processing apparatus 800 further includes a scanning module configured to scan the target log record to obtain a scanning result.

[0176] The sending module is configured to send a first target message to a management device in the case that the scanning result indicates that there is an abnormality and the abnormality occurs in the component log record, and the first target message includes component abnormality information.

[0177] The obtaining module 810 is further configured to, in a case where the scanning result indicates that an exception exists and the exception occurs in the application log record, obtain a failure flow record in the application log record, the failure flow record indicating that the exception occurs; and based on the failure flow record, obtain a root cause of the exception.

[0178] In an embodiment of the present application, after the root cause of the exception is obtained, the log processing apparatus 800 further comprises a recording module configured to record the root cause in the application log record.

[0179] In an embodiment of the present application, in the process of obtaining the root cause of the exception based on the failure flow record, the obtaining module 810 is specifically configured to: send a second target packet to a management device, the second target packet containing the failure flow record and being used for the management device to determine the root cause of the exception by a fault matching model; the fault matching model is used to determine the root cause of the exception based on the failure flow record; and receive the root cause sent by the management device.

[0180] In an embodiment of the present application, in the process of obtaining the root cause of the exception based on the failure flow record, the obtaining module 810 is specifically configured to: input the failure flow record into a fault matching model, the fault matching model being used to determine the root cause of the exception based on the failure flow record; and obtain the root cause output by the fault matching model.

[0181] In an embodiment of the present application, before the first target packet is sent to the management device, the log processing apparatus 800 further comprises a screening and reorganizing module configured to screen and reorganize the component log records according to component function points.

[0182] The obtaining module 810 is further configured to obtain a target component function point corresponding to a log record in which an exception occurs in the component log record; and the component exception information comprises component exception information associated with the target component function point.

[0183] FIG. 9 is a structural block diagram of log processing provided by an embodiment of the present application. Referring to FIG. 9, the log processing apparatus 900 provided by an embodiment of the present application comprises:

[0184] The receiving module 910 is configured to receive target log records of a target session transmitted by a target device, the target log records comprising at least one of first log records and second log records, the first log records comprising partial log records obtained from all log records of the target session in the case where the target session ends normally, and the second log records comprising all log records of the target session in the case where the target session ends abnormally; the target log records comprise component log records and application log records; the scanning module 920 is configured to scan the target log records to obtain a scanning result; and the obtaining module 930 is configured to, in the case where the scanning result indicates that an abnormality exists and the abnormality occurs in the application log records, obtain a failure flow record in the application log records, the failure flow record indicating the abnormality; and the management device obtains a root cause of the abnormality based on the failure flow record.

[0185] In the log processing apparatus provided in the embodiments of the present application, the target log records comprise at least one of the first log records and the second log records, and the second log records comprise all log records of the target session in the case where the target session ends abnormally, so that the target log records can be effectively used for subsequent analysis of the cause of the abnormality of the target session, and the first log records comprise partial log records obtained from all log records of the target session in the case where the target session ends normally, so that the storage amount of the target log records is reduced, thereby solving the problem that the log information stored in the related art occupies a large amount of storage space and is extremely ineffective for subsequent analysis of the cause of the abnormality of the device.

[0186] In one embodiment of the present application, the log processing apparatus 900 further comprises a sending module configured to, after obtaining the root cause of the abnormality, send the root cause to the target device, so that the target device records the root cause in the application log records.

[0187] In one embodiment of the present application, in the process of obtaining the root cause of the abnormality based on the failure flow record, the obtaining module 930 is specifically configured to input the failure flow record into a fault matching model, the fault matching model being configured to determine the root cause of the abnormality based on the failure flow record, and obtain the root cause output by the fault matching model.

[0188] In one embodiment of the present application, the log processing apparatus 900 further comprises a screening and recombining module configured to, in the case where the scanning result indicates that an abnormality exists and the abnormality occurs in the component log records, screen and recombine the component log records by component function points by the target device.

[0189] Fig. 10 is another structural block diagram of a log processing system according to an embodiment of the present application. It should be understood that the structural block diagram shown in Fig. 10 is for more clearly discussing the whole log processing procedure. The log processing system in Fig. 10 comprises a log storage module and a log processing module. As shown in Fig. 10, the log storage module is composed of a log pre-storing unit, a session result judging unit, a data filtering unit, a resetting unit and a log storage unit. The log pre-storing unit buffers log records through the log pre-storing unit (i.e. the first storage element mentioned above); the session result judging unit and the data filtering unit jointly complete the discrimination and screening of the log records in the first storage element; the data filtering unit stores rules for determining target log records, and the filtering result is the target log records; the log storage unit is responsible for storing the determined target log records to the log storage unit (i.e. the second storage element mentioned above); the resetting unit is responsible for resetting the operations of the units of the log storage module after the target log records are stored to the second storage element, so as to prepare to record the next log record pre-storing data. The log storage module is responsible for improving the effectiveness of log records and optimizing the log record storage function. The log processing module is composed of a log monitoring unit, a component monitoring unit, an upper-layer application monitoring unit, a state statistical unit and a fault matching model unit. The operation of storing the target log records to the second storage element will trigger the log monitoring unit to scan the target log records in real time; in the case that the scanning result indicates that there is an exception and the exception appears in the component log records, the component monitoring unit will screen and reorganize the component log information according to the function points, and send a first target message containing the component exception information to the management device, and then clear the corresponding component log records in the second storage element; the upper-layer application monitoring unit is responsible for acquiring the failure flow record indicating the occurrence of an exception in the application log records and sending it to the management device in the case that the scanning result indicates that there is an exception and the exception appears in the application log records; the state statistical unit is responsible for counting the component exception information at each time point scanned, and centrally managing each component exception information according to the fault matching model; the fault matching model unit can store the matching rules of the failure flow record and the root cause of the exception. The log processing module is responsible for monitoring the exception information in the target log records and identifying and diagnosing the root cause of the exception.

[0190] Fig. 11 is a schematic diagram of an electronic device according to an embodiment of the present application. Referring to Fig. 11, the present application further provides an electronic device 1100, which can be various types of computers and the like. The electronic device 1100 comprises a processor 1110 and a memory 1120, wherein the memory 1120 stores programs or instructions, and the programs or instructions are executed by the processor 1110 to implement the steps of any one of the methods described above, such as the steps of the log processing method shown in Figs. 2-7.

[0191] The embodiments of the present application also provide a readable storage medium, which stores programs or instructions, and the programs or instructions are executed by the processor to implement the steps of any one of the above-described methods.

[0192] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage devices, etc.) containing computer-usable program code.

[0193] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of the flows and / or blocks in the flowcharts and / or block diagrams can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing apparatus to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing apparatus generate means for implementing the functions specified in one or more flows in the flowcharts and / or one or more blocks in the block diagrams.

[0194] These computer program instructions can also be stored in a computer-readable memory that can direct the computer or other programmable data processing apparatus to work in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including instruction means, which implements the functions specified in one or more flows in the flowcharts and / or one or more blocks in the block diagrams.

[0195] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus, so that a series of operation steps are performed on the computer or other programmable data processing apparatus to generate a computer-implemented process, so that the instructions executed on the computer or other programmable data processing apparatus provide steps for implementing the functions specified in one or more flows in the flowcharts and / or one or more blocks in the block diagrams.

[0196] In a typical configuration, the computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memories.

[0197] Memory can include non-persistent memory, Random Access Memory (RAM), and / or non-volatile memory such as read-only memory (ROM) or flash memory, etc. in a computer readable medium. Memory is an example of computer readable media.

[0198] Computer readable media includes permanent and non-permanent, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD), or other optical storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to a computing device. According to the definition herein, computer readable media does not include transitory media such as modulated data signals and carrier waves.

[0199] It should also be noted that the terms "comprising", "containing", or any other similar term are intended to encompass non-exclusive inclusions such that a process, method, article, or apparatus that comprises a list of elements does not include those elements solely, but can also include other elements not expressly listed or inherent to such process, method, article, or apparatus.

[0200] Those skilled in the art will understand that embodiments of the present application can be provided as a method, a system or a computer program product. Therefore, the present application can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application can take the form of a computer program product implemented on one or more computer available storage media (including, but not limited to, disk memory, CD-ROM, optical storage, etc.) containing computer usable program code.

[0201] The above description is only an example of the present application and is not intended to limit the present application. Various modifications and changes can be made to the present application by those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the scope of the claims of the present application.

Claims

1. A log processing method, wherein, The method comprises: the target device acquires log records of a target session; in the case where the target session ends abnormally, the target device determines all log records of the target session as target log records; in the case where the target session ends normally, the target device acquires part of the log records from all log records of the target session as target log records; the target device stores the target log records.

2. The method of claim 1, wherein, The part of the log records acquired from all log records of the target session are user-selected log records.

3. The method of claim 1, wherein, The log records of the target session are log records acquired from a first storage element of the target device, the first storage element being used to store log records of the target session before the target session ends; the target log records are stored in a second storage element of the target device.

4. The method of claim 1, wherein, Before the target device stores the target log records, the method further comprises: the target device acquires log records of a non-session; the target device acquires part of the log records from the log records of the non-session as target log records.

5. The method of claim 4, wherein, The part of the log records acquired from the log records of the non-session are user-selected target log records.

6. The method of claim 4, wherein, The log records of the non-session are log records acquired from the first storage element of the target device; the target log records are stored in the second storage element of the target device.

7. The method of claim 3 or 6, wherein, The first storage element is an internal memory, and the second storage element is an external memory.

8. The method of claim 1, wherein, The method further comprises: in the case where the target session ends abnormally, determining a failure flow record from all log records of the target session, the failure flow record indicating that the target session ends abnormally; labeling the failure flow record.

9. The method of claim 1, wherein, The target device acquires log records of a target session, comprising: in the case where the target session ends or a user indicates to acquire log records of a session, the target device acquires log records of the target session.

10. The method according to any one of claims 1-6, wherein, The type of the target log records comprises at least one of component log records and application log records, the component log records being used to record information of components on which an application runs; After the target device stores the target log records, the method further comprises: the target device scans the target log records to obtain a scanning result; in the case where the scanning result indicates that there is an abnormality and the abnormality occurs in the component log records, the target device sends a first target message to a management device, the first target message containing component abnormality information; in the case where the scanning result indicates that there is an abnormality and the abnormality occurs in the application log records, the target device acquires a failure flow record in the application log records, the failure flow record indicating that the abnormality occurs; and the target device acquires a root cause of the abnormality based on the failure flow record.

11. The method of claim 10, wherein, After acquiring the root cause of the abnormality, the method further comprises: the target device records the root cause in the application log records.

12. The method of claim 10, wherein, The target device acquires the root cause of the abnormality based on the failure flow record, comprising: The target device sends a second target message to the management device, the second target message containing the failure process record and being used for the management device to determine the root cause of the abnormality through a fault matching model; The target device receives the root cause sent by the management device.

13. The method of claim 10, wherein, The target device obtains the root cause of the abnormality based on the failure process record, including: The target device inputs the failure process record into a fault matching model, the fault matching model being used for determining the root cause of the abnormality based on the failure process record; The target device obtains the root cause output by the fault matching model.

14. The method of claim 10, wherein, Before the target device sends the first target message to the management device, the method further includes: The target device filters and reorganizes the component log records by component function points; The target device obtains a target component function point corresponding to the log record with the abnormality in the component log records; The component abnormality information includes component abnormality information associated with the target component function point.

15. A log processing method, wherein, The method further includes: The management device receives target log records of a target session transmitted by a target device, the target log records including at least one of first log records and second log records, the first log records including partial log records obtained from all log records of the target session in the case of normal termination of the target session, and the second log records including all log records of the target session in the case of abnormal termination of the target session; the target log records including component log records and application log records; The management device scans the target log records to obtain a scanning result; In the case where the scanning result indicates that there is an abnormality and the abnormality occurs in the application log records, the management device obtains a failure process record in the application log records, the failure process record indicating the occurrence of the abnormality; The management device obtains a root cause of the abnormality based on the failure process record.

16. The method of claim 15, wherein, After obtaining the root cause of the abnormality, the method further includes: The management device sends the root cause to the target device, so that the target device records the root cause in the application log records.

17. The method of claim 15 or 16, wherein, The management device obtains the root cause of the abnormality based on the failure process record, including: The management device inputs the failure process record into a fault matching model, the fault matching model being used for determining the root cause of the abnormality based on the failure process record; The management device obtains the root cause output by the fault matching model.

18. The method of claim 15, wherein, The method further includes: In the case where the scanning result indicates that there is an abnormality and the abnormality occurs in the component log records, the management device filters and reorganizes the component log records by component function points.

19. An electronic device, comprising: A computer program product comprising a computer readable medium having stored thereon a computer program or instructions that, when executed by a processor, implement the steps of the method of any of claims 1-18.

20. A computer readable storage medium, wherein, A medium having stored thereon a program or instructions that, when executed, implement the steps of the method of any of claims 1-18.

21. A computer program product, wherein, A computer program that, when executed by a processor, implements the steps of the method of any of claims 1-18.

Images