A method and system for root cause identification of a target port running abnormally of a system

Abstract

The root cause identification method and system provided by the specification can select a plurality of candidate cause data with high correlation to the target event occurring at the target port from the system operation exception data set. A decision tree is generated based on the target event data and the plurality of candidate cause data. The decision tree generated according to the decision rule of the decision tree can reflect the relationship between the plurality of candidate causes corresponding to the plurality of candidate cause data, so that the root cause causing the operation exception at the target port can be quickly and accurately determined through the decision tree, thereby the problem of the operation exception of the target port can be solved in time, and the root cause can be monitored to ensure the normal operation of the target port.

Description

Technical Field

[0001] This specification relates to the field of Internet technology, and in particular to a method and system for identifying the root cause of abnormal operation of a target port in a system. Background Technology

[0002] An app system comprises a user terminal (such as a user's mobile phone) and a backend system (such as the app's remote server). The user terminal and the backend system typically communicate via means such as wireless networks to transmit data and instructions. During the operation of the entire system, any malfunction in any component—server, network, and / or user terminal—can lead to system-wide malfunctions. These malfunctions are recorded in real-time or offline through logs for backend maintenance personnel to troubleshoot system errors. Some malfunctions are explicit and easily perceived by the user. For example, a blank screen may appear when a user opens the app on their phone. Such malfunctions significantly impact the user experience and require rapid troubleshooting. Other malfunctions are implicit; although not directly perceived by the user operating the terminal, their inherent characteristics still necessitate rapid troubleshooting by maintenance personnel. For instance, a damaged cable in the app's data transmission link can cause data transmission obstacles. Similar problems can also occur in other systems outside the app system.

[0003] To resolve issues related to malfunctions at ports (such as user terminals in an app system, cable fault points, etc., the specific location of which can be freely defined by system administrators), it's typically necessary to investigate the cause of the system malfunction based on the data reported by the malfunctioning port. This process allows for timely handling of malfunctioning ports and strengthens monitoring of factors that can easily lead to port malfunctions, reducing the probability of such incidents. There are many reasons why a port might malfunction. For example, an app crashing on a user terminal could be due to container startup failure, insufficient memory, or incorrect parameter values, preventing the execution of a command on the app's display and thus hindering page rendering. Some of these reasons are direct causes of a blank screen, while others are deeper or root causes. Only by identifying and resolving the root cause can the system malfunction be resolved. When all these causes are displayed in the system logs, it can be difficult for administrators to find the root cause of the blank screen problem among numerous possible causes.

[0004] Therefore, there is a need for a more comprehensive and accurate method and system for identifying the root causes of abnormal port operation in a system. Summary of the Invention

[0005] This specification provides a method and system for more comprehensive and accurate root cause identification of abnormal operation of target ports in a system.

[0006] In a first aspect, this specification provides a method for identifying the root cause of port malfunctions in a system, comprising the following steps: obtaining a system malfunction dataset and target event data, wherein the system malfunction dataset includes multiple system malfunction data representing system malfunction events within a first preset time period, the target event data is system data representing the occurrence of a target event, and the target event is a pre-specified event occurring at a target port of the system; selecting multiple candidate cause data corresponding to multiple candidate causes with a correlation higher than a threshold from the system malfunction dataset; and generating the decision tree based on the multiple candidate cause data and the target event data, wherein the decision tree includes multiple cause chains composed of the multiple candidate causes.

[0007] In some embodiments, the system operation anomaly dataset includes all anomaly data during system operation.

[0008] In some embodiments, the target port includes a node pre-designated by the system during operation.

[0009] In some embodiments, the target port includes a user-facing client; and the target event data includes data reported by a user when using the client due to system malfunction.

[0010] In some embodiments, the plurality of candidate reasons includes at least one of container startup failure, insufficient memory, rendering error, parameter undefined, request error, response error, database operation error, computation error, linking error, or pointer error.

[0011] In some embodiments, selecting multiple candidate cause data from the system anomaly dataset that have a correlation with the target event data higher than a threshold includes: selecting multiple candidate anomaly data from the system anomaly dataset that occur more than a first frequency threshold within a preset time slice; and determining that the multiple candidate cause data includes the multiple candidate anomaly data.

[0012] In some embodiments, obtaining the target event data includes: obtaining feedback data of the target port malfunction; and selecting data from the feedback data that occurs more than a second frequency threshold within the preset time slice as the target event data.

[0013] In some embodiments, the first frequency threshold is related to the average value of the system's abnormal data; the second frequency threshold is related to the average value of the feedback data.

[0014] In some embodiments, according to the root cause identification method of claim 8, the first frequency threshold is m times the average value of the system abnormal data; the second frequency threshold is n times the average value of the feedback data, wherein m and n are both real numbers.

[0015] In some embodiments, the average value of the system anomaly data represents the average frequency of the occurrence of the system anomaly data within a second preset time period prior to the preset time slice; the average value of the feedback data represents the average frequency of the occurrence of the feedback data within the second preset time period prior to the preset time slice.

[0016] In some embodiments, multiple historical candidate anomaly data corresponding to the target event are obtained from multiple historical time slices prior to the preset time slice; and the multiple historical candidate anomaly data are used together with the multiple candidate anomaly data as the multiple candidate cause data.

[0017] In some embodiments, generating the decision tree based on the plurality of candidate cause data and the target event data includes: obtaining statistical data on the occurrence of the plurality of candidate cause data and the target event data under multiple time slices from the system anomaly dataset; and generating the decision tree based on the statistical data, using the candidate causes corresponding to the plurality of candidate cause data as the attribute set of the target event, and using the target event as the label.

[0018] In some embodiments, generating the decision tree based on the plurality of candidate cause data and the target event data further includes: constructing an attribute list, the attribute list including a plurality of time slice data, each time slice data including data on whether the target event and the plurality of candidate causes occurred in the corresponding time slice; repeatedly performing decision operations based on the attribute list to determine the selected cause and use the selected cause as a node of the decision tree until only one candidate cause remains in the attribute set, the decision operation including: determining the decision value of each candidate cause in the attribute set relative to the label, determining the candidate cause corresponding to the smallest decision value as the current selected cause, and updating the attribute set, removing the time slice data where the selected cause did not occur from the attribute list; and generating the decision tree based on the selected causes arranged in a determined chronological order.

[0019] In some embodiments, the decision value includes at least one of the Gini index, information gain, or information gain ratio.

[0020] In some embodiments, the method for identifying the root cause of port malfunction in the system further includes the following steps: obtaining a current system malfunction dataset; inputting the current system malfunction dataset into the decision tree, and outputting the root cause that causes the target port to currently malfunction.

[0021] In some embodiments, inputting the current system operation anomaly dataset into the decision tree and outputting the root cause that causes the target port to currently experience operation anomalies includes: selecting the corresponding cause chain in the decision tree based on the current system operation anomaly dataset; and outputting the system operation anomaly event corresponding to the last level node of the cause chain as the root cause.

[0022] Secondly, this specification provides a system for root cause identification of target port malfunctions, comprising: at least one storage medium storing at least one instruction set for identifying the cause of the target port malfunction; and at least one processor communicatively connected to the at least one storage medium, wherein, when the root cause identification system is running, the at least one processor reads the at least one instruction set and executes the root cause identification method described in the first aspect of this specification according to the instructions of the at least one instruction set.

[0023] As can be seen from the above technical solution, the root cause identification method and system for target port malfunction provided in this specification can select multiple candidate cause data with high correlation to the target event occurring at the target port from the system anomaly dataset. A decision tree is generated based on the target event data and multiple candidate cause data. The generated decision tree includes multiple cause chains composed of multiple candidate causes. The decision rules of the decision tree can classify an unordered dataset into an ordered tree structure. The tree structure can reflect the relationships between data in the dataset. Using the above principle, the relationships between multiple candidate causes corresponding to multiple candidate cause data can be obtained from the cause chains of the decision tree. This allows for accurate and rapid identification of the root cause from multiple candidate causes. By inputting the current system malfunction dataset and the current target event data into the generated decision tree, the root cause causing the current malfunction of the target port can be determined, thereby resolving the target port malfunction problem in a timely manner and ensuring the target port operates normally.

[0024] The root cause identification methods for abnormal operation of the target port of the system provided in this specification, as well as other functions of the system, are partially listed in the following description. The figures and examples described below will be readily apparent to those skilled in the art. The inventive aspects of the recommended methods and systems provided in this specification can be fully understood through practice or use of the methods, apparatus, and combinations described in the detailed examples below. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 A schematic diagram illustrating an application scenario of a root cause identification system provided according to an embodiment of this specification is shown.

[0027] Figure 2 A schematic diagram of the structure of a device provided according to an embodiment of this specification is shown;

[0028] Figure 3 A flowchart of a root cause identification method provided according to an embodiment of this specification is shown;

[0029] Figure 4 A schematic diagram of a decision tree for identifying the root cause of fever, provided according to an embodiment of this specification, is shown.

[0030] Figure 5 A decision tree for identifying the root cause of a target port malfunction in an APP system, according to an embodiment of this specification, is illustrated; and

[0031] Figure 6 This document illustrates another decision tree for identifying the root cause of a target port malfunction in an APP system, according to an embodiment of this specification. Detailed Implementation

[0032] The following description provides specific application scenarios and requirements for this specification, intended to enable those skilled in the art to make and use the contents of this specification. Various partial modifications to the disclosed embodiments will be apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments and applications without departing from the spirit and scope of this specification. Therefore, this specification is not limited to the embodiments shown, but rather to the widest scope consistent with the claims.

[0033] The terminology used herein is for the purpose of describing particular exemplary embodiments only and is not restrictive. For example, unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “the” used herein may also include the plural forms. When used in this specification, the terms “comprising,” “including,” and / or “containing” mean that the associated integers, steps, operations, elements, and / or components are present, but do not exclude the presence of one or more other features, integers, steps, operations, elements, components, and / or groups, or that other features, integers, steps, operations, elements, components, and / or groups may be added to the system / method.

[0034] Considering the following description, these and other features of this specification, as well as the operation and function of the related components of the structure, and the economy of assembly and manufacture of the parts, can be significantly improved. All of these form part of this specification with reference to the accompanying drawings. However, it should be clearly understood that the drawings are for illustrative and descriptive purposes only and are not intended to limit the scope of this specification. It should also be understood that the drawings are not drawn to scale.

[0035] The flowcharts used in this specification illustrate operations implemented according to some embodiments of this specification. It should be clearly understood that the operations in the flowcharts may not be implemented in a sequential order. Instead, the operations may be implemented in reverse order or simultaneously. Furthermore, one or more additional operations may be added to the flowcharts. One or more operations may be removed from the flowcharts.

[0036] Figure 1 The diagram illustrates an application scenario of a root cause identification system provided according to an embodiment of this specification. For example, system 100 could be the previously described app system. The app system could also be a payment system, such as PayPal. TM Examples include the Industrial and Commercial Bank of China's (ICBC) mobile app. Another example is an app system that can be a video system, such as YouTube. TM TikTok TM bilibili TM And so on. For example, an app system can also be a social media system, such as Instagram. TM Weibo TM Facebook TM Etc. System 100 could also be other systems, such as a website system, a management information system, etc.

[0037] System 100 may include server 110, target port 120, network 130, and database 140.

[0038] Network 130 can facilitate the exchange of information and / or data. In some embodiments, network 130 can be any type of wired or wireless network, or a combination thereof. For example, network 130 may include a cable network, wired network, fiber optic network, telecommunications network, intranet, Internet, local area network (LAN), wide area network (WAN), wireless local area network (WLAN), metropolitan area network (MAN), public area network (WAN), public switched telephone network (PSTN), Bluetooth network, ZigBee network, near field communication (NFC) network, or similar network. In some embodiments, network 130 may include one or more network access points. For example, network 130 may include wired or wireless network access points, such as base stations and / or Internet switching points 130-1, 130-2, ... Through this access point, one or more components of target port 120, server 110, database 140 can connect to network 130 to exchange data and / or information. Figure 1 As shown, server 110, target port 120, and database 140 can be connected to network 130 and exchange information and / or data through network 130. For example, target port 120 can obtain services from server 110 through network 130.

[0039] Server 110 may store data or instructions for performing the root cause identification method for abnormal operation of the target port of the system as described in this specification, and may execute or store the data and / or instructions for execution. Server 110 may be a device that provides corresponding services to target port 120. For example, server 110 in an APP system can provide services corresponding to the APP.

[0040] Database 140 may store data and / or instructions. In some embodiments, database 140 may store data and / or instructions for performing the methods for root cause identification described herein. Server 110 and target port 120 may have access to database 140. Server 110 and target port 120 may access the data or instructions stored in database 140 via network 130. In some embodiments, database 140 may be directly connected to server 110 and target port 120. In some embodiments, database 140 may be part of server 200. In some embodiments, database 140 may include mass storage, removable storage, volatile read-write memory, read-only memory (ROM), or similar content, or any combination thereof. Exemplary mass storage may include non-transitory storage media such as disks, optical discs, and solid-state drives. Exemplary removable storage may include flash drives, floppy disks, optical discs, memory cards, zip disks, magnetic tapes, etc. Typical volatile read-write memory may include random access memory (RAM). Example RAMs may include dynamic RAM (DRAM), dual date rate synchronous dynamic RAM (DDR SDRAM), static RAM (SRAM), thyristor RAM (T-RAM), and zero-capacitance RAM (Z-RAM), etc. Exemplary ROMs may include mask ROM (MROM), programmable ROM (PROM), virtual programmable ROM (PEROM), electronically programmable ROM (EEPROM), optical disc (CD-ROM), and digital multifunction disk ROM, etc. In some embodiments, database 140 may be implemented on a cloud platform. For example only, a cloud platform may include a private cloud, public cloud, hybrid cloud, community cloud, distributed cloud, inter-cloud cloud, or similar, or any combination thereof. In some embodiments, database 140 may store data obtained from target port 120. For example, in an APP system, database 140 may store status data of various application software provided by server 110, as well as user 150's evaluations and feedback on the APP.

[0041] Target port 120 can be a node pre-specified during the operation of system 100. Any node in system 100 that requires analysis can be designated as target port 120.

[0042] For example, in the process of signal transmission using cables in System 100, sensors are typically installed in key transmission areas to monitor the transmitted signals. When a sensor detects an anomaly in the transmission signal, it will report the detected anomaly to the system's control center. Authorized maintenance personnel at the control center need to investigate the cause of the signal transmission anomaly at the monitoring point. Many factors can cause signal transmission anomalies, such as mechanical damage or poor shielding of the cable along the route from the signal source to the monitoring point, leading to external electromagnetic contamination of the transmitted signal, or cable aging causing signal loss. In this case, the sensor's monitoring point can serve as the target port 120.

[0043] For example, target port 120 can be a smart device in system 100 carrying application software. The application software can be the aforementioned APP or a website. The APP can include mini-programs. In this case, target port 120 can be a client 122 facing user 150, such as a mobile phone or a wearable device used to detect human physiological data (such as body temperature, blood pressure, heart rate, respiration, etc.). User 150 is the user of client 122. One or more APPs can be installed on the smart device. The APP can provide user 150 with the ability and interface to interact with the outside world through network 130. Client 122 can include hardware devices with data information processing functions and the necessary programs to drive the hardware devices. The data information processing function includes data information collection. Target port 120 can communicate with server 110. When target port 120 is client 122, server 110 can be a device that provides corresponding services to the application software of client 122.

[0044] For ease of description, the system and method in this disclosure are described using an APP system as an example, with target port 120 as client 122. Of course, those skilled in the art will understand that the system and method can also be applied to other types of systems, such as website systems, without affecting the core spirit of the invention involved in this disclosure.

[0045] An app is installed on client 122. For example... Figure 1As shown, user 150 can use the services provided by the APP on client 122. Client 122 and / or server 110 can collect status data generated during the use of the APP. The instructions for the root cause identification method for the abnormal operation of the target port of the system, which are built into the memory of server 110 and / or database 140, can output the root cause causing the abnormal operation of the target port. The server 110 that collects data and the server 110 that executes the root cause identification method can be the same device or different devices. It can be a single device or a system composed of multiple devices. The two devices can work synchronously or asynchronously. For example, after one device in server 110 collects data, it uploads it to database 140, and another device in server 110 runs the instructions of the root cause identification method and outputs the root cause.

[0046] Figure 2 A schematic diagram of a device 200 provided according to an embodiment of this specification is shown. The device 200 may be a server 110 or a client 122.

[0047] like Figure 2 As shown, device 200 includes at least one storage medium 230 and at least one processor 220. In some embodiments, device 200 may further include a communication port 250 and an internal communication bus 210. Additionally, device 200 may also include I / O components 260.

[0048] The internal communication bus 210 can connect different system components, including storage medium 230 and processor 220. I / O component 260 supports input / output between device 200 and other components.

[0049] Storage medium 230 may include a data storage device. The data storage device may be a non-transitory storage medium or a temporary storage medium. For example, the data storage device may include one or more of a disk 232, a read-only storage medium (ROM) 234, or a random access storage medium (RAM) 236. Storage medium 230 also includes at least one instruction set stored in the data storage device. The instructions are computer program code, which may include programs, routines, objects, components, data structures, procedures, modules, etc., that execute the root cause identification method for abnormal operation of target ports of the system provided in this specification.

[0050] Communication port 250 is used for data communication between device 200 and the outside world. For example, device 200 can connect to network 130 through communication port 250. At least one processor 220 is connected to at least one storage medium 230 via an internal communication bus 210. At least one processor 220 is used to execute the at least one instruction set mentioned above. When system 100 is running, at least one processor 220 reads the at least one instruction set and executes the root cause identification method 300 for target port operation abnormalities provided in this specification according to the instructions of the at least one instruction set.

[0051] Processor 220 can perform all the steps included in method 300 for root cause identification. Processor 220 can be in the form of one or more processors, and in some embodiments, processor 220 may include one or more hardware processors such as microcontrollers, microprocessors, reduced instruction set computers (RISC), application-specific integrated circuits (ASICs), application-specific instruction set processors (ASIPs), central processing units (CPUs), graphics processing units (GPUs), physical processing units (PPUs), microcontroller units, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), advanced RISC machines (ARMs), programmable logic devices (PLDs), any circuit or processor capable of performing one or more functions, etc., or any combination thereof.

[0052] For illustrative purposes only, only one processor 220 is described in this specification for device 200. However, it should be noted that device 200 may also include multiple processors. Therefore, the operation and / or method steps disclosed in this specification may be executed by one processor as described herein, or they may be executed jointly by multiple processors. For example, if processor 220 of device 200 in this specification executes steps A and B, it should be understood that steps A and B may also be executed jointly or separately by two different processors 220 (e.g., a first processor executes step A, a second processor executes step B, or the first and second processors jointly execute steps A and B).

[0053] Figure 3 A flowchart of a root cause identification method provided according to an embodiment of this specification is shown. Method 300 can be executed by server 110. Further, server 110 may have, for example, Figure 2The structure of device 200 is shown. Specifically, the storage medium in server 110 may store at least one set of instructions for identifying the root cause of a target port malfunction in the system. Processor 220 may be communicatively connected to storage medium 230. Processor 220 may read the instruction set stored in its local storage medium and / or database 140, and then execute method 300 provided herein according to the instructions. Method 300 may include performing the following steps via at least one processor 220:

[0054] S320: Server 110 / Processor 220 obtains system operation anomaly dataset and target event data.

[0055] The system anomaly dataset includes multiple system anomaly data representing system malfunction events within a first preset time period. For example, the first preset time period can be one day or more days. For example, the first preset time period can be seven days. As mentioned above, user 110 can use various services provided by the APP on client 122. If any component of server 110, network 130, database 140, and / or client 122 experiences an operational anomaly, it may lead to an operational anomaly in the entire system 100. In some embodiments, the system anomaly dataset includes all anomaly data during system operation within a certain period (i.e., the full data of the system within that time period) so as not to overlook all possible causes in the subsequent process of finding the root cause of the target event. For example, the anomaly events may include: container startup failure, insufficient memory, rendering anomaly, undefined parameters, request anomaly, response anomaly, database operation anomaly, computation anomaly, link anomaly or pointer anomaly, and / or signal transmission anomaly, etc. For example, when the methods and systems described in this application are applied to disease diagnosis, the target port 120 can be a wearable device for detecting human parameters, and the abnormal event can be abnormal human physiological data, such as fever, high blood pressure, allergies, arrhythmia, high blood sugar, and insufficient blood oxygen. These abnormal events can occur at any stage of the operation of system 100.

[0056] System logs can be configured on server 110 of system 100. The system logs record all data information during the operation of system 100, including system operation anomaly data corresponding to the aforementioned system operation anomaly events. Server 110 / processor 220 or maintenance personnel can obtain system anomaly datasets from the system logs. For example, system anomaly datasets may include data such as container startup failures, insufficient memory, rendering failures, undefined parameters, request anomalies, response anomalies, database operation anomalies, connection or pointer anomalies, signal transmission anomalies, etc.

[0057] The target event data includes data corresponding to the target events occurring on the target port 120. For example, in the case of an APP system, the target port 120 may include a client 122 (such as a mobile phone). In order to understand and resolve abnormal events encountered by user 150 when using client 122, client 122 may include a feedback channel for user 150 to report any abnormal events encountered by client 122. Abnormal events of client 122 may include some functional abnormalities of client 122. For example, in the case of an APP system, these functional abnormalities may include the APP interface failing to open / reporting errors, crashing, black screen, white screen, lag / freezing, interface misalignment, abnormal button clicks, dropped frames, and / or incomplete page loading, etc. Since client 122 directly touches the user, when the abnormal reaction of system 100 occurs on client 122, it may be perceived by user 150, thereby affecting the user's experience. As mentioned earlier, user 150 of client 122 will immediately perceive certain abnormalities, such as the APP interface failing to open / reporting errors, crashing, black screen, white screen, lag / freezing, interface misalignment, and / or abnormal button clicks, etc. These functional abnormalities of client 122 will significantly affect user 150's use of client 122, therefore user 150 will report these functional abnormalities through feedback channels. However, some abnormalities may go unnoticed by user 150 or not affect normal use, therefore user 150 will not report such functional abnormalities. For example, when using a video APP, a brief frame drop occurs in the video frame. This brief frame drop is also caused by an abnormality in the operation of system 100, but this frame drop may not be noticed by the user and will not affect the user's overall viewing experience, therefore user 150 will not report this abnormality. Another example is when user 150 is using a social APP, emoticon images do not load completely during chat. The incomplete loading of emoji images is also caused by an abnormality in the operation of system 100, but this situation will not affect normal communication between users 150, so users 150 will not provide feedback. In this disclosure, the feedback from users 150 can be referred to as public opinion. When many users in system 100 report this abnormal event through client 122, the corresponding number of public opinion events (the number of feedback data) will increase accordingly, and the phenomenon of abnormal public opinion data may occur. When the number of public opinion data (feedback data) about a certain issue suddenly increases, that issue may become the target event. For example, when the APP interface experiences widespread problems such as being unable to open / reporting errors, crashing, black screen, white screen, lag / freezing, interface misalignment, and abnormal button clicks, many users 150 will report to server 110, and these abnormalities will become the target events.For example, when the methods and systems described in this application are applied to disease diagnosis, wearable devices that detect human body parameters can use data such as blood glucose, heart rate, blood oxygen, blood pressure, and cell activity as public opinion. When a patient's vital signs remain abnormal or the data changes too rapidly, the abnormal events corresponding to these vital signs become target events.

[0058] Of course, target events can also include pre-defined events that, while not public opinion events, are of primary concern to operations and maintenance personnel. For example, in a system that uses cables to transmit signals, when sensors detect abnormal signal transmission at monitoring points, they report this anomaly to the control center. In this case, the abnormal signal transmission at the monitoring point can also be considered a target event. The monitoring information reported by the sensors to the control center can be considered target event data.

[0059] It should be noted that the system operation anomaly dataset can include target event data. The system anomaly dataset obtained by operations and maintenance personnel from the system logs includes all anomaly data during system operation, while the target event data only includes system operation anomaly data corresponding to target events that occur on target ports preset by the operations and maintenance personnel.

[0060] User 150's feedback on public opinion can be transmitted to server 110 or database 140.

[0061] Database 140 or server 110 can be shared across the entire region. Numerous users 150 will encounter various anomalies when using the APP client 122. Therefore, server 110 or database 140 will contain a large amount of user feedback data. For example, within the same time period, user A's client 122 might experience an APP white screen anomaly, while user B's client 122 might experience an APP crash anomaly. Both users can report the anomalies encountered by their client 122 through feedback channels. When multiple users 150 report their anomalies, the number of user feedback events increases, requiring close attention from operations and maintenance personnel. The feedback data from user 150 can reflect the specific anomalies occurring during client 122's operation and can also indirectly reflect anomalies existing in the system 100's operation.

[0062] Server 110 / processor 220 can obtain system exception datasets and target event data from system logs. Of course, server 110 / processor 220 can also obtain target event data from client 122 or database 140.

[0063] System anomalies occur over time, and therefore, the recorded system anomaly data in the logs also fluctuates accordingly. Sometimes, the fluctuations in system anomaly data caused by system anomalies are normal. However, when there is anomaly in public opinion, the system anomaly data related to that anomaly will fluctuate more significantly than normal. Such system anomalies require close attention and rapid handling by operations and maintenance personnel.

[0064] For example, taking day M as an example, with a time slice of 1 hour, then the period from 0:00 to 5:00 on day M includes 5 time slices. Table 1 lists the system anomaly data and feedback data within each time slice from 0:00 to 5:00 on day M.

[0065] Table 1

[0066]

[0067]

[0068] Here, the time slice refers to a preset time length. Generally, the length of the time slice is much shorter than the length of the first preset time period. For example, if the first preset time period is 7 days, the length of the time slice can be set to 1 hour. With a time slice of 1 hour, the blank screen of the APP on the client 122 that occurs between 00:00:00 and 00:59:59 on any day within the preset time period can be used as public opinion. The client 122 can be a hardware device with data processing capabilities to send the feedback data of the user 150 regarding the blank screen of the APP within this time slice as target event data to the log of the server 110 via the network 130 in the form of data packets, or to the log stored in the database 140, and then the server 110 / processor 220 reads it from the database 140.

[0069] In Table 1, the first preset time period is from 0:00 to 5:00 on day M of the cycle, with each time slice being 1 hour. For example, within time slice T4, user 150 encountered an app crash and reported it. In this case, the app crash might have been caused by a calculation error, but the code related to the calculation was not faulty. The error only occurred when referencing calculation data based on user 150's actions. Since the app crash was not widespread, the number of reports (feedback) was not abnormally high (e.g., far less than three times the normal amount). This can be considered a normal fluctuation in system 100's operational data.

[0070] For example, within time slice T4, the number of public comments regarding the app's blank screen anomaly increased significantly compared to other time periods (e.g., more than three times the normal amount), indicating that users 150's client 122 generally experienced the blank screen anomaly and reported it through feedback channels. In this case, the app blank screen can be considered the target event. Due to the large number of users reporting it, the operations and maintenance personnel need to investigate system 100 to resolve the anomaly encountered by user 150.

[0071] Specifically, S320 may include the following steps:

[0072] S322: Server 110 / processor 220 obtains feedback data indicating that the target port is malfunctioning.

[0073] Server 110 / processor 220 can obtain feedback data regarding abnormal operation of the target port. This feedback data may include data (public opinion data) reported by user 150 regarding all abnormal events or functional malfunctions occurring on client 122. This feedback data can be obtained by client 122 and stored in database 140 or server 110.

[0074] S324: Within a preset time slice, server 110 / processor 220 selects data from the feedback data that occurs more than a second frequency threshold and determines them as the target event data.

[0075] Server 110 / processor 220 can select data from the feedback data that occurs more than a second frequency threshold within a preset time slice and define them as the target event data. The second frequency threshold can be related to the average value of the feedback data. For example, the second frequency threshold can be n times the average value of the feedback data, where n is a real number. The average value of the feedback data represents the average frequency of the feedback data occurring within a second preset time period prior to the preset time slice, while the target events represent those abnormally frequent system malfunction events reported within the preset time slice.

[0076] The second preset time period can be one day or more. The second preset time period can be the same as or different from the first preset time period. For example, the second preset time period can be 5 days. Taking Table 1 as an example, assuming the preset time slice is T4 on day M, the average frequency of abnormal events occurring in the 5 days prior to T4 can be used as a standard to judge whether the feedback data for the same abnormal event within T4 fluctuates significantly. For example, if the feedback frequency for a certain abnormal event within T4 is greater than the feedback frequency in the 5 days prior to T4, this abnormal event can be used as the target event for analysis. The second frequency threshold is also different for feedback data of different abnormal events. For example, if the average hourly feedback data regarding APP white screens in the 5 days prior to T4 is 20 times, then the second frequency threshold for APP white screens in the T4 time slice is 20 times; if the feedback data regarding APP crashes is 15 times, then the second frequency threshold for APP crashes in the T4 time slice is 15 times. The second frequency threshold can be set to 3 times the average value of the feedback data. For example, within time slice T4, client 122 received 70 feedback reports regarding the app's blank screen and 20 feedback reports regarding app crashes. It can be observed that the feedback data regarding app crashes does not fluctuate significantly compared to the average data of the previous 5 days, and is less than 3 times the average; therefore, these app crashes can be considered normal fluctuations. However, the feedback data regarding the app's blank screen is 3.5 times the average data of the previous 5 days, exceeding 3 times the average, thus requiring close attention. In this case, the app blank screen, a system malfunction event, can be considered the target event, and the feedback data regarding the app blank screen can be considered the target event data. The selection of n can be based on the staff's past experience in handling anomalies or derived through training using neural networks, among other methods.

[0077] Within the same time period, there may be multiple instances of abnormal fluctuations in feedback data, thus allowing for multiple target events. For example, within a preset time slice, if the feedback data for app white screen and app crashes both exceed the average of the feedback data received in the previous 5 days, both can be considered target events. Multiple target events can be included in the decision tree generation process, therefore, the same decision tree can be used to analyze multiple target events. In some embodiments, different decision trees can be generated for different target events, with each decision tree used to explain a target event and identify the root cause leading to that target event.

[0078] S340: Server 110 / processor 220 selects multiple candidate cause data from the system anomaly dataset that have a correlation degree higher than a threshold with the target event data.

[0079] To investigate the cause of the target event on client 122, it is necessary to filter the acquired system anomaly dataset. From the system anomaly dataset, multiple candidate cause data are selected, corresponding to multiple candidate causes whose correlation with the target event data is higher than a threshold in a preset time slice within the first preset time period and in historical time slices prior to the preset time slice.

[0080] As mentioned earlier, the system anomaly dataset includes all anomaly data during system operation within a first preset time period (e.g., the length of 7 days prior to the current time slice). The logs in database 140 or server 110 may include all system anomaly data within the first preset time period. This complete set of system operation anomaly data constitutes the system anomaly dataset. Therefore, it is necessary to first select multiple candidate cause data from the system anomaly dataset to identify the cause of the target event. Multiple candidate cause data correspond to multiple candidate causes. There may be many direct or indirect causes leading to abnormal operation of client 122, such as container startup failure, insufficient memory, rendering anomalies, request anomalies, response anomalies, database operation anomalies, computation anomalies, connection anomalies, or pointer anomalies, etc. These causes may occur at any stage of system 100's operation.

[0081] Specifically, step S340 may include:

[0082] S342: Within a preset time slice, server 110 / processor 220 selects multiple candidate abnormal data from the system abnormal dataset that have occurred more than a first frequency threshold.

[0083] The system anomaly dataset consists of runtime data recorded in the system log from 0:00 to 5:00 on day M, including container startup failures, request exceptions, pointer exceptions, and insufficient memory. Time T4 (3:00 to 4:00) on day M is used as a preset time slice. Assuming an app white screen is selected as the target event, the feedback data of the app white screen within the T4 time slice is the target event data. The first frequency threshold is related to the average value of the system anomaly data. The average value of the system runtime anomaly data represents the average frequency of the system anomaly data occurring within a second preset time period prior to the preset time slice. For example, the second preset time period is 5 days. When analyzing the container startup failure data within the T4 time slice on day M, server 110 / processor 220 can use the frequency of container startup failures from day M-5 to day M as the first frequency threshold to determine whether the container startup failure data is candidate anomaly data causing the app white screen target event. The first frequency threshold is m times the average value of the system anomaly data. Here, m can be any real number, such as an integer or a decimal. The first frequency threshold varies for different system anomaly data. For example, if there are 3 container startup failures in the first 5 days, then the first frequency threshold for container startup failures is 3 times. We choose m=4. Between 3 AM and 4 AM on day M, there are 15 container startup failures, exceeding the first frequency threshold by more than 4 times. During this period, an app white screen event occurred, and the data on system 100 container startup failures also showed abnormal fluctuations. Therefore, we can conclude that there is a correlation between system 100 container startup failures and the app white screen event on client 122. The selection of m can be based on staff's past experience in handling anomalies or by training a neural network, etc. m and n can be the same or different. Similarly, the same processing method can be applied to request anomalies, pointer anomalies, and insufficient memory data in the T4 time slice on day M to determine whether these three system 100 anomalies are related to the app white screen event on client 122. If there is a correlation between system anomaly data and target event data, then the corresponding system anomaly data can be used as candidate anomaly data.

[0084] Step S344: Server 110 / processor 220 determines that the plurality of candidate cause data includes the plurality of candidate anomaly data.

[0085] It's important to note that when analyzing data within a time slice, only system anomaly data within that time slice that occurs more frequently than a first frequency threshold can be selected as candidate anomaly data from the system anomaly dataset. However, data that doesn't exceed the first frequency threshold in a specific time slice may exceed it in other time slices. For example, analyzing data in time slice T4 of day M reveals that data related to container startup failures and pointer anomalies both exceed the set first frequency threshold, while data related to insufficient memory does not. However, in time slice T3 of day M, data related to insufficient memory also exceeds the set first frequency threshold. To comprehensively investigate the root cause of the app's white screen, insufficient memory must also be considered a candidate cause, and data related to insufficient memory must also be considered candidate cause data. Therefore, multiple candidate anomaly data selected within a preset time slice constitute multiple candidate cause data. Multiple candidate cause data includes multiple candidate anomaly data.

[0086] Specifically, step S344 also includes:

[0087] Server 110 / processor 220 acquires multiple historical candidate anomaly data corresponding to the target event from multiple historical time slices prior to the preset time slice. These multiple historical candidate anomaly data, along with the original candidate anomaly data, are used as the multiple candidate cause data.

[0088] When selecting candidate cause data from the system anomaly dataset from 0:00 to 6:00 on day M, with the APP white screen as the target event, server 110 / processor 220 first selects candidate cause data on a time slice basis. For example, if the APP white screen anomaly occurs in time slice T5 of day M and the frequency exceeds the second frequency threshold, candidate causes need to be determined. Server 110 / processor 220 can select system anomaly data from the system anomaly data of time slice T5 that occurs more than the first frequency threshold as candidate anomaly data. The candidate causes corresponding to the candidate anomaly data are the causes related to the target event. Server 110 / processor 220 also needs to analyze system anomaly data within time slices in the system anomaly dataset where the APP white screen anomaly event also occurred. For example, if the APP white screen event occurs in time slice T3 but does not exceed the second frequency threshold, server 110 / processor 220 can consider that the target event - APP white screen - does not exist in time slice T3. Therefore, when analyzing the system anomaly causing the APP white screen, server 110 / processor 220 can exclude system anomaly data exceeding a first frequency threshold within time slice T3 from being considered candidate cause data. For example, if an APP white screen event occurs within time slice T2 and exceeds a second frequency threshold, server 110 / processor 220 considers the target event—APP white screen—to exist within time slice T2. Therefore, when analyzing the system anomaly causing the APP white screen, server 110 / processor 220 uses system anomaly data exceeding the first frequency threshold within time slice T2 as historical candidate anomaly data. Server 110 / processor 220 can use historical candidate anomaly data and candidate anomaly data together as candidate cause data. In some embodiments, server 110 / processor 220 can select multiple candidate anomaly data within a preset time slice, which are multiple candidate cause data. That is, the candidate cause corresponding to historical candidate anomaly data and the candidate cause corresponding to candidate anomaly data are the same. One time slice can identify all candidate causes.

[0089] S360: Server 110 / processor 220 generates a decision tree based on the multiple candidate cause data and the historical target event data.

[0090] Decision tree models are classic algorithm models in the field of machine learning. The decision tree algorithm is a method to approximate discrete function values. A decision tree is a tree structure that represents the classification of samples based on features. The classification process of a decision tree can be summarized as recursively selecting splitting features from a given dataset according to the feature selection criteria, and then dividing the dataset according to the selected splitting features, so that each subset has a reasonable classification process.

[0091] In this step, server 110 / processor 220 selects multiple candidate cause data from the system anomaly dataset, identifying several candidate causes leading to the abnormal operation of target port 120. These candidate causes may have causal or influence relationships. For example, server 110 / processor 220, through the aforementioned steps, determines that the APP white screen may be caused by factors such as rendering anomalies, container startup anomalies, insufficient memory, undefined parameters, and pointer anomalies. Rendering failure may be due to pointer anomalies or container startup failure. Container startup failure may be due to insufficient memory, which in turn may be due to undefined parameters. Therefore, when server 110 / processor 220 uses a decision tree, it can infer that the insufficient memory is caused by undefined parameters, based on the APP white screen being caused by insufficient memory. Thus, maintenance personnel only need to resolve the parameter definition issue to solve the APP white screen problem. By using a decision tree to investigate multiple candidate causes, server 110 / processor 220 can more accurately and quickly locate the root cause of the target event, thereby resolving the target event.

[0092] Specifically, step S360 may include:

[0093] S362: Server 110 / processor 220 obtains statistical data on the occurrence of multiple candidate cause data and target event data under multiple time slices from the system anomaly dataset.

[0094] The statistical regularity includes whether the target event occurs within a time slice and whether the selected candidate causes occur. As mentioned earlier, the target event may not occur in every time slice across multiple time slices. Since candidate causes are selected from the datasets of the preset time slice and historical time slices preceding the preset time slice, candidate causes selected in historical time slices may not appear in the preset time slice. Similarly, candidate causes selected in the preset time slice may not appear in historical time slices. The statistical regularity includes the occurrence of candidate causes in each time slice within the entire first preset time period to be analyzed.

[0095] S364: Server 110 / processor 220 uses the candidate causes corresponding to the multiple candidate cause data as the attribute set of the target event, uses the target event as a label, and generates the decision tree based on the statistical data.

[0096] Specifically, step S364 may include:

[0097] S364-1: Server 110 / processor 220 constructs an attribute list, the attribute list including multiple time slice data, each event slice data including data on whether the target event and the multiple candidate causes have occurred in the corresponding time slice.

[0098] For ease of description, this application will use the data in Table 1 as an example to illustrate the decision tree generation process. App crashes in Table 1 cannot be considered target events because the number of feedbacks does not exceed the second frequency threshold. App white screen feedbacks exceed the second frequency threshold and can be considered target events. Therefore, the data on app crashes is removed from Table 1. It should be noted that the data provided in this specification is only for explaining the decision tree generation process; when using the method provided in this specification for root cause identification, the same or different data types can be used. For ease of explanation, the data content in Table 1 has been replaced with "yes" or "no," and data within the T6-T10 time slices has been added. Table 2 lists the statistical patterns across the 10 time slices.

[0099] Table 2

[0100]

[0101]

[0102] For example, in time slice T4, the app on client 122 experienced a white screen. At this time, system 100 encountered container startup failure and a pointer exception, but no memory shortage occurred. Similarly, in time slice T5, the app on client 122 did not experience a white screen, and system 100 did not experience container startup failure, pointer exception, or memory shortage. Table 2 is the attribute list. The attribute set includes container startup failure, pointer exception, memory shortage, etc.

[0103] S364-3: Server 110 / processor 220 repeatedly performs decision-making operations based on the attribute list, determines the selected cause and uses the selected cause as a node of the decision tree model, until only one candidate cause remains in the attribute set.

[0104] Specifically, step S364-3 may include:

[0105] S364-3-1: Server 110 / processor 220 determines the decision value of each of the candidate causes in the attribute set relative to the label.

[0106] In some embodiments, information gain can be used as the decision value. In some embodiments, information gain ratio can be used as the decision value. In some embodiments, the Gini index can be used as the decision value.

[0107] First, let's explain what the Gini coefficient and Gini index are. The Gini coefficient is used to measure the purity of a dataset. The Gini coefficient Gini(D) of dataset D reflects the probability that two samples randomly drawn from dataset D will have inconsistent class labels. Therefore, the smaller the Gini(D), the higher the purity of dataset D.

[0108] The formula for calculating the Gini coefficient is:

[0109]

[0110] P k Let represent the probability that the selected sample belongs to class k. Then the probability that this sample is misclassified is (1-P). k The Gini index represents the probability that a randomly selected sample in a set will be misclassified. The smaller the Gini index, the lower the probability that the selected sample in the set will be misclassified, meaning the higher the purity of the set; conversely, the larger the Gini index, the less pure the set.

[0111] The formula for calculating the Gini index is:

[0112]

[0113] D represents the total number of samples, and the Dth sample... v This represents the number of samples in class V. In the APP system, the Gini coefficient can be used as the decision value to classify candidate causes.

[0114] Calculate the Gini index using the data in Table 2.

[0115] For container startup failures, 5 out of the 10 time slices in Table 2 show instances where container startup failure occurred (marked as "Yes" in the table), and 5 time slices show instances where no container startup failure occurred (marked as "No" in the table). Of the 5 time slices where container startup failure occurred, 2 showed the target event and 3 did not; of the 5 time slices where no container startup failure occurred, 4 showed the target event and 1 did not. The Gini coefficient for container startup failures is... The Gini coefficient for which no container startup failure occurred is G12 = 1.

[0116] The weighted Gini index for container startup failures is:

[0117] Regarding pointer anomalies, 4 out of the 10 time slices in Table 2 experienced pointer anomalies (marked "Yes" in the table), while 6 time slices did not experience pointer anomalies (marked "No" in the table). Of the 4 time slices where pointer anomalies occurred, 3 experienced the target event, and 1 did not. Of the 6 time slices where container startup failure did not occur, 3 experienced the target event, and 3 did not. The Gini coefficient for pointer anomalies is [missing value]. The Gini coefficient for which no pointer anomaly occurred is The weighted Gini index for pointer anomalies is:

[0118] Similarly, the Gini index G3 for insufficient memory can be obtained as follows:

[0119] S364-3-3: The server 110 / processor 220 determines the candidate cause corresponding to the decision value with the smallest value as the current selected cause.

[0120] As mentioned earlier, the Gini coefficient represents the probability that a sample in a set will be misclassified; the smaller the probability, the lower the probability of the sample being misclassified. For example, the method and system described in this application are applied to disease diagnosis (where the target terminal can be a wearable device that detects human parameters, and the target event and / or public opinion can be abnormal human physiological data, such as fever, high blood pressure, abnormal heartbeat, etc.). Taking the decision tree of the cause of a patient's fever as an example, the principle of finding the root cause through the decision tree is explained. Figure 4This diagram illustrates a decision tree for identifying the root causes of fever, according to an embodiment of this specification. A patient's fever may be caused by various factors, such as infectious and non-infectious fever. Infectious fever may be caused by viral infections, bacterial infections, etc. Non-infectious fever may be caused by metabolic disorders, reduced heat dissipation, etc. Metabolic disorders may be caused by endocrine imbalances. Therefore, if the cause of the patient's fever is found, such as an endocrine imbalance, the endocrine system should be regulated. Directly regulating the endocrine system is the correct way to treat or alleviate the patient's fever symptoms. If a patient has a fever due to an endocrine imbalance, but is given medication for viral infections, it may cause harm to the patient's body or delay treatment. Since a small Gini coefficient indicates a low probability of misclassification of samples in the set, it also indicates that in a causal chain, the lower-level node has a higher correlation with the higher-level node, and the lower-level node is more likely to coexist with the higher-level node. For example, in the case of fever, the decision tree can categorize causes leading to infectious fever under the "Infectious Fever" node, and causes leading to non-infectious fever under the "Non-Infectious Fever" node. Furthermore, causes leading to metabolic disorders can be categorized under the "Metabolic Disorder" node. The generated decision tree includes different causal chains (e.g., fever -> non-infectious fever -> metabolic disorder -> endocrine imbalance; fever -> infectious fever -> viral infection; etc.). Attributes with smaller Gini coefficients are closer to the root node (the location of "fever" in the diagram), while attributes with larger Gini coefficients are further away from the root node. The diagram also shows that attributes with smaller Gini coefficients provide a broader explanation for the occurrence of the root node; attributes with larger Gini coefficients provide a more precise explanation for the occurrence of the root node, and are located further away from the root node.

[0121] In an app system, the smaller the Gini coefficient, the broader the explanation of the candidate causes corresponding to the Gini coefficient for the abnormal operation of the system's target port; the larger the Gini coefficient, the more precise the explanation of the candidate causes corresponding to the Gini coefficient for the abnormal operation of the system's target port.

[0122] Comparing the Gini coefficients for container startup failure, pointer exceptions, and insufficient memory, we can see that container startup failure has the lowest Gini coefficient. Because the Gini coefficient for container startup failure is the lowest, its interpretation of the target event is relatively broad. That is, while container startup failure may be the cause of the app's white screen, other reasons could also have caused the container startup failure, leading to the white screen. Therefore, we should prioritize container startup failure as the first identified cause.

[0123] S364-3-5: Server 110 / processor 220 updates the attribute set, and time slice data for which the selected reason did not occur is removed from the attribute list.

[0124] After identifying container startup failure as the primary cause, Table 2 shows that among the five time slices where container startup failure did not occur, four time slices had the target event, and one time slice did not. To uncover the deeper cause of the app's white screen, the data for the time slices in Table 2 that did not have the target event was deleted, and the attribute set was updated. Table 3 is obtained by deleting the data rows corresponding to time slices T2, T3, T6, T8, and T9 in Table 2. Table 3 shows the updated attribute list. The updated attribute set includes pointer exceptions and parameter exceptions.

[0125] Table 3

[0126] T1 yes no no …… no T4 yes yes no …… yes T5 yes no yes …… yes T7 yes no no …… no T10 yes no yes …… yes

[0127] Re-execute the decision operation on Table 3 and recalculate the Gini coefficients for pointer anomalies and insufficient memory. The calculation method is as described above. The calculated Gini index for pointer anomalies is: The Gini index for insufficient memory is Among these, insufficient memory has a smaller Gini index. Insufficient memory is output as the second selected reason. At this point, only pointer exceptions remain in the attribute set, and the decision-making process stops.

[0128] S364-3-7: Server 110 / processor 220 generates the decision tree based on the selected reasons arranged in the determined order.

[0129] Figure 5 A decision tree for identifying the root cause of a target port malfunction in an APP system is shown according to an embodiment of this specification.

[0130] The above calculation only uses three candidate reasons: pointer exception, container startup failure, and insufficient memory. In reality, there are many reasons why an app might display a blank screen, and the relationships are much more complex. However, the principle and method of generating the decision tree remain the same. Let's assume that in addition to the three candidate reasons (pointer exception, container startup failure, and insufficient memory), the causes of an app's blank screen also include exception events A, B, C, D, and E. The decision tree generated after ranking the candidate reasons by calculating the Gini index is as follows: Figure 5 As shown.

[0131] The chain of events—app white screen -> container startup failure -> insufficient memory -> pointer exception—indicates that if the app white screen is caused by container startup failure, and the container startup failure is caused by insufficient memory, then the insufficient memory is most likely caused by a pointer exception. This is because operations personnel need to resolve pointer exception issues. Through a decision tree, operations personnel can move from the broad issue of container startup failure to insufficient memory, and finally pinpoint the root cause of the target port's malfunction as a pointer exception. Only by resolving the pointer exception issue can the app white screen problem reported by user 150 be truly resolved.

[0132] In the decision tree generated from the system anomaly dataset and target event data, the target events causing system malfunctions, besides the app white screen, can also include app interface misalignment and abnormal app button clicks. The cause chain for an app crash can include app interface misalignment -> abnormal event F -> abnormal event G. The cause chain for abnormal app button clicks can include abnormal app button clicks -> abnormal event H -> abnormal event I. Figure 6 This document illustrates another decision tree for identifying the root cause of an abnormal operation of the target port 120 of an APP system, according to an embodiment of this specification. Figure 6 The types include target events such as APP interface misalignment and abnormal APP button clicks, as well as the corresponding cause chains.

[0133] Based on the decision tree obtained earlier, the cause of the current malfunction in target port 120 can be investigated. Because a decision tree can contain multiple target events, the root cause of the malfunction in the target port can be found through the decision tree for different target events.

[0134] The root cause identification method may further include:

[0135] S380: Server 110 / Processor 220 acquires the current system operation exception dataset and the current target event data.

[0136] The current system operation anomaly dataset includes all data related to system operation anomalies in the current time slice. Operational anomaly events occurring in System 100 may include: container startup failure, insufficient memory, rendering anomalies, undefined parameters, request anomalies, response anomalies, database operation anomalies, computation anomalies, link or pointer anomalies, signal transmission anomalies, etc. The current system operation anomaly data may include the occurrence status of each candidate cause (anomaly event) in the decision tree. For example, whether a container startup failure occurred, whether a link anomaly occurred, etc. The current target event data includes data corresponding to the target event currently occurring on target port 120. For example, in the APP system example, target port 120 may include client 122 (such as a mobile phone). Operations personnel can obtain the current system operation anomaly dataset in real time from the system logs. The current system operation anomaly dataset may include current target event data.

[0137] It's important to understand that system 100 can include multiple servers 110. The server 110 used to generate the decision tree based on the system operation anomaly dataset and target event data can be the same device or a different device used to analyze the root cause of the current system operation anomaly. It can be a single device or a system composed of multiple devices. After the operations and maintenance personnel obtain system data and complete the decision tree generation operation on server 110, they can immediately perform the identification of the root cause of the current system operation anomaly; alternatively, they can store the generated decision tree in database 140 and use it for root cause identification when there is a need to analyze the root cause of the system operation anomaly.

[0138] S360: Server 110 / processor 220 inputs the current system operation anomaly dataset and the current target data into the decision tree, and outputs the root cause that caused the operation anomaly at the target port 120.

[0139] When an abnormal number of public opinion events occurs at a given moment, data from the current system operation anomaly dataset can be input into a decision tree for root cause identification. For example, when the target event is an app interface misalignment, the generated decision tree can be used to analyze the current system operation anomaly dataset to determine the cause of the app interface misalignment at that moment. Table 4 shows the occurrence of various candidate causes (abnormal events) in the decision tree with the app white screen as the target event.

[0140] Table 4

[0141]

[0142] Specifically, S360 may include:

[0143] Based on the current system operation anomaly dataset, select the corresponding cause path in the decision tree.

[0144] Input the data from Table 4 into the generated decision tree. Since the decision tree is generated from the system operation anomaly dataset, which includes all anomaly data representing system operation, all data in the current system operation anomaly dataset can be decided by the decision tree. From the decision tree, it can be seen that anomaly events F and G do not appear in the decision tree; therefore, it can be determined that anomaly events E and F are not the cause of the app's white screen. Then, make decisions along the causal chain of the decision tree using the other data from Table 4. Based on whether the anomaly events occurred, the causal chain leading to the current app white screen event is: App White Screen -> Anomaly Event B -> Anomaly Event D -> Anomaly Event E.

[0145] Server 110 / processor 220 outputs the system anomaly event corresponding to the last node of the cause chain as the root cause. Through the above analysis of the hierarchical relationship of the decision tree, it can be seen that the causes of this APP white screen include anomaly event B, anomaly event E, and anomaly event D. Among them, the root cause of the APP white screen is anomaly event D. Anomaly event D can be one of the anomalies mentioned above.

[0146] To ensure the timeliness of the causal chain provided by the decision tree, the decision tree can be updated promptly. The methods for updating the decision tree can also be those provided in this manual.

[0147] In summary, the root cause identification method 300 and system 100 for the abnormal operation of the target port 120 provided in this specification identify the root cause of the abnormal operation of the target port 120 by constructing a decision tree. The root cause identification method 300 can select multiple candidate cause data with high correlation to the target event occurring at the target port 120 from the system anomaly dataset. A decision tree is generated based on the target event data and multiple candidate cause data. The generated decision tree includes multiple cause chains composed of multiple candidate causes. Because the decision rules of the decision tree can classify an unordered dataset into an ordered tree structure, and the tree structure can reflect the relationships between data in the dataset, the relationships between multiple candidate causes corresponding to multiple candidate cause data can be obtained from the cause chains of the decision tree. This allows for accurate and rapid identification of the root cause from multiple candidate causes. By inputting the current system anomaly dataset into the generated decision tree, the root cause causing the current abnormal operation of the target port 120 can be quickly and accurately determined, thereby resolving the problem of the current abnormal operation of the target port 120 in a timely manner and ensuring the normal operation of the target port 120.

[0148] This specification, in another aspect, provides a non-transitory storage medium storing at least one set of executable instructions for root cause identification. When the executable instructions are executed by a processor, they instruct the processor to perform the steps of the root cause identification method 300 described in this specification. In some possible embodiments, various aspects of this specification can also be implemented as a program product comprising program code. The program product for implementing the above method may employ a portable compact disc read-only memory (CD-ROM) containing program code and may run on device 200. However, the program product of this specification is not limited thereto. In this specification, a readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system (e.g., processor 220). The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. The computer-readable storage medium may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium that can send, propagate, or transmit programs for use by or in connection with an instruction execution system, apparatus, or device. Program code contained on a readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof. Program code for performing the operations described herein can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on device 200, partially on device 200, as a standalone software package, partially on device 200 and partially on remote device 200, or entirely on remote device 200.

[0149] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0150] In summary, after reading this detailed disclosure, those skilled in the art will understand that the foregoing detailed disclosure is presented by way of example only and is not restrictive. Although not explicitly stated herein, those skilled in the art will understand that this specification requires various reasonable changes, improvements, and modifications to the embodiments. These changes, improvements, and modifications are intended to be made by this specification and are within the spirit and scope of the exemplary embodiments described herein.

[0151] Furthermore, certain terms in this specification have been used to describe embodiments of this specification. For example, "an embodiment," "an embodiment," and / or "some embodiments" mean that a particular feature, structure, or characteristic described in connection with that embodiment may be included in at least one embodiment of this specification. Therefore, it is to be emphasized and understood that two or more references to "an embodiment" or "an embodiment" or "alternative embodiment" in various parts of this specification do not necessarily refer to the same embodiment. Moreover, specific features, structures, or characteristics may be suitably combined in one or more embodiments of this specification.

[0152] It should be understood that in the foregoing description of the embodiments in this specification, various features are combined in a single embodiment, drawing, or description for the purpose of simplifying the description and aiding in the understanding of a feature. However, this does not mean that the combination of these features is necessary, and those skilled in the art may readily identify some of the devices as separate embodiments when reading this specification. That is, the embodiments in this specification can also be understood as an integration of multiple secondary embodiments. It is also valid when each secondary embodiment contains fewer than all the features of a single foregoing disclosed embodiment.

[0153] Each patent, patent application, publication of the patent application, and other materials such as articles, books, specifications, publications, documents, articles, etc., cited herein may be incorporated by reference. All contents used for all purposes, except for any history of prosecution documents relating to it, that may be inconsistent with or conflict with this document, or any such history of prosecution documents that may have a limiting effect on the widest extent of the claims, are now or hereafter associated with this document. For example, in the event of any inconsistency or conflict between the description, definition, and / or use of terms associated with any of the included materials and the terms, description, definition, and / or used in connection with this document, the terms used herein shall prevail.

[0154] Finally, it should be understood that the embodiments disclosed herein are illustrative of the principles of the embodiments described in this specification. Other modified embodiments are also within the scope of this specification. Therefore, the embodiments disclosed in this specification are merely examples and not limitations. Those skilled in the art can implement the applications described in this specification using alternative configurations based on the embodiments in this specification. Therefore, the embodiments in this specification are not limited to the embodiments precisely described in the applications.

Claims

1. A method for identifying the root cause of a system's target port malfunction, comprising: Obtain the system operation anomaly dataset and target event data of the system. The system anomaly dataset includes multiple system anomaly data representing system operation anomaly events within a first preset time period. The target event data is system data representing the occurrence of a target event. The target event is a pre-specified event that occurs at a target port of the system. From the system anomaly dataset, select multiple candidate cause data corresponding to multiple candidate causes whose correlation with the target event data is higher than a threshold. The multiple candidate causes include at least one of the following: container startup failure, insufficient memory, rendering anomaly, parameter undefined, request anomaly, response anomaly, database operation anomaly, computation anomaly, link anomaly, or pointer anomaly. as well as Based on the multiple candidate cause data and the target event data, a decision tree is generated. The decision tree includes multiple cause chains that lead to the target event, composed of the multiple candidate causes. There is a causal relationship between the candidate causes corresponding to the nodes at different levels in the cause chain. The step of generating a decision tree based on the multiple candidate cause data and the target event data includes: obtaining statistical data on the occurrence of the multiple candidate cause data and the target event data under multiple time slices from the system anomaly dataset; and using the candidate causes corresponding to the multiple candidate cause data as the attribute set of the target event, using the target event as the label, and generating the decision tree based on the statistical data.

2. The root cause identification method according to claim 1, wherein, The system operation anomaly dataset includes all abnormal data during the operation of the system within the first preset time period.

3. The root cause identification method according to claim 1, wherein, The target port includes a node of the system that is pre-designated during system operation.

4. The root cause identification method according to claim 3, wherein, The target port includes a user-facing client; and The target event data includes data reported by users when they are affected by system malfunctions while using the client.

5. The root cause identification method according to claim 1, wherein, The selection of multiple candidate cause data from the system anomaly dataset that have a correlation higher than a threshold with the target event data includes: Within a preset time slice, multiple candidate anomaly data points are selected from the system anomaly dataset, each occurring more than a first frequency threshold; and The multiple candidate cause data are determined to include the multiple candidate anomaly data.

6. The root cause identification method according to claim 5, wherein, The acquisition of the target event data includes: Obtain feedback data regarding the abnormal operation of the target port; and Within the preset time slice, data that occurs more than a second frequency threshold are selected from the feedback data and identified as the target event data.

7. The root cause identification method according to claim 6, wherein, The first frequency threshold is related to the average value of the system's abnormal data; and The second frequency threshold is related to the average value of the feedback data.

8. The root cause identification method according to claim 7, wherein, The first frequency threshold is m times the average value of the system's abnormal data; and The second frequency threshold is n times the average value of the feedback data, where m and n are both real numbers.

9. The root cause identification method according to claim 7, wherein, The average value of the system anomaly data represents the average frequency of the system anomaly data occurrences within a second preset time period prior to the preset time slice; and The average value of the feedback data represents the average frequency of the feedback data occurring within the second preset time period prior to the preset time slice.

10. The root cause identification method according to claim 5, further comprising: Obtain multiple historical candidate anomaly data corresponding to the target event from multiple historical time slices prior to the preset time slice; as well as The multiple historical candidate anomaly data are used together with the multiple candidate anomaly data as the multiple candidate cause data.

11. The root cause identification method according to claim 1, wherein, The statistical data includes the multiple candidate cause data in the multiple time slices and the data on the number of times and / or whether the target event data occurs.

12. The root cause identification method according to claim 11, wherein, The generation of the decision tree based on the multiple candidate cause data and the target event data further includes: Construct an attribute list, which includes multiple time slice data, and each time slice data includes data on whether the target event and the multiple candidate causes have occurred in the corresponding time slice; Based on the attribute list, decision-making operations are repeatedly performed to determine the selected reasons and use these selected reasons as nodes in the decision tree, until only one candidate reason remains in the attribute set. The decision-making operations include: Determine the decision value for each candidate cause in the attribute set relative to the label. The candidate cause corresponding to the decision value with the smallest determination value is the currently selected cause, and Update the attribute set, removing time slice data for which the selected reason did not occur from the attribute list; The decision tree is generated based on the selected reasons arranged in the determined order.

13. The root cause identification method according to claim 12, wherein, The decision value includes at least one of the Gini index, information gain, or information gain ratio.

14. The root cause identification method according to claim 1, wherein, Also includes: Obtain the current system runtime exception dataset and the current target event data; as well as The decision tree is input with the current system operation anomaly dataset and the current target event data, and the root cause causing the current operation anomaly of the target port is output.

15. The root cause identification method according to claim 14, wherein, The step of inputting the current system operation anomaly dataset into the decision tree and outputting the root cause that caused the current operation anomaly of the target port includes: Based on the current system operation anomaly dataset and the current target event data, the corresponding causal link in the decision tree is selected; and The system malfunction event corresponding to the last node of the cause chain is output as the root cause.

16. A system for root cause identification of abnormal operation of a target port, comprising: At least one storage medium storing at least one instruction set for identifying the root cause of abnormal operation of a target port of the system; as well as At least one processor is communicatively connected to the at least one storage medium. When the root cause identification system is running, the at least one processor reads the at least one instruction set and executes the root cause identification method according to any one of claims 1-15 according to the instructions of the at least one instruction set.

Images