Root cause alarm positioning method and device of transaction relation tree system and electronic equipment

Abstract

The invention provides a root cause alarm positioning method and device of a transaction relation tree system and electronic equipment, and relates to the technical field of data processing. The method comprises the following steps: determining an abnormal transaction in a transaction relation tree system, and obtaining an original message log of the abnormal transaction; constructing a transaction tree of abnormal transactions according to the original message log; determining abnormal subsystems in the subsystems according to the running state information of the subsystems in the transaction tree; searching alarms associated with the abnormal subsystem according to the network information corresponding to the abnormal subsystem; scoring the alarms to obtain scores of the alarms; and according to the score of each alarm, determining a root cause alarm from each alarm. According to the method, the abnormal subsystem is positioned based on the running state information of each subsystem in the abnormal transaction tree, and the root cause alarm is screened from the alarms associated with the abnormal subsystem according to the score of the alarms associated with the abnormal subsystem, so that the accuracy of root cause alarm positioning can be improved.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a root cause alarm positioning method, device and electronic equipment for a transaction relationship tree system. Background Art

[0002] In the related art, when a transaction relationship tree system fails, low-level alarms in the failure period are usually filtered out, only high-level alarms are retained, and the remaining alarms are prioritized. However, this method of retaining high-level alarms according to alarm levels is prone to filtering out root cause alarms. Summary of the invention

[0003] The present application aims to solve one of the technical problems in the related art at least to some extent.

[0004] To this end, the first objective of the present application is to propose a root cause alarm positioning method for a transaction relationship tree system to achieve accurate positioning of the root cause alarm.

[0005] The second objective of the present application is to provide a root cause alarm locating device for a transaction relationship tree system.

[0006] The third objective of the present application is to provide an electronic device.

[0007] A fourth objective of the present application is to provide a computer-readable storage medium.

[0008] A fifth object of the present application is to provide a computer program product.

[0009] To achieve the above-mentioned purpose, the first embodiment of the present application proposes a root cause alarm locating method of a transaction relationship tree system, comprising:

[0010] Determine abnormal transactions in the transaction relationship tree system, and obtain original message logs of the abnormal transactions;

[0011] Constructing a transaction tree of the abnormal transaction according to the original message log;

[0012] Determine an abnormal subsystem among the subsystems according to the operation status information of each subsystem in the transaction tree;

[0013] According to the network information corresponding to the abnormal subsystem, searching for each alarm associated with the abnormal subsystem;

[0014] Scoring each of the alarms to obtain a score for each of the alarms;

[0015] According to the scores of the various alarms, a root cause alarm is determined from the various alarms.

[0016] To achieve the above-mentioned purpose, the second embodiment of the present application proposes a root cause alarm locating device of a transaction relationship tree system, comprising:

[0017] An acquisition module, used to determine abnormal transactions in the transaction relationship tree system and obtain the original message log of the abnormal transaction;

[0018] A construction module, used to construct a transaction tree of the abnormal transaction according to the original message log;

[0019] A first determination module, configured to determine an abnormal subsystem among the subsystems according to the operation status information of each subsystem in the transaction tree;

[0020] A search module, used to search for each alarm associated with the abnormal subsystem according to the network information corresponding to the abnormal subsystem;

[0021] A scoring module, used to score each of the alarms to obtain a score for each of the alarms;

[0022] The second determining module is used to determine the root cause alarm from the various alarms according to the scores of the various alarms.

[0023] To achieve the above-mentioned purpose, the third aspect of the present application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0024] The memory stores computer-executable instructions;

[0025] The processor executes the computer-executable instructions stored in the memory to implement the method as described in the embodiment of the first aspect.

[0026] To achieve the above-mentioned purpose, the fourth aspect embodiment of the present application proposes a computer-readable storage medium, in which computer execution instructions are stored. When the computer execution instructions are executed by a processor, they are used to implement the method described in the first aspect embodiment.

[0027] To achieve the above-mentioned purpose, the fifth aspect of the present application proposes a computer program product, including a computer program, which implements the method described in the first aspect when executed by a processor.

[0028] The root cause alarm locating method, device, electronic device and storage medium of the transaction relationship tree system provided by the present application determine the abnormal transactions in the system, and build a transaction tree of the abnormal transactions according to the original log messages of the abnormal transactions, and locate the abnormal subsystem based on the operating status information of each subsystem in the abnormal transaction tree, thereby improving the accuracy of locating the abnormal subsystem, and then find the alarms associated with the abnormal subsystem, and screen out the root cause alarms from the alarms associated with the abnormal subsystem according to the scores of the alarms associated with the abnormal subsystem, thereby improving the accuracy of root cause alarm locating, and then based on the root cause alarm, the cause of the fault can be accurately found, thereby improving the efficiency of fault analysis.

[0029] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through the practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

[0031] Figure 1 A flowchart of a root cause alarm location method for a transaction relationship tree system provided in an embodiment of the present application;

[0032] Figure 2 A flowchart of another method for locating a root cause alarm of a transaction relationship tree system provided in an embodiment of the present application;

[0033] Figure 3 A flowchart of another method for locating a root cause alarm of a transaction relationship tree system provided in an embodiment of the present application;

[0034] Figure 4 A flowchart of another method for constructing a transaction relationship tree provided in an embodiment of the present application;

[0035] Figure 5 A schematic diagram of a hierarchical structure of a transaction relationship tree provided in an embodiment of the present application;

[0036] Figure 6 A schematic diagram of the structure of a root cause alarm locating device for a transaction relationship tree system provided in an embodiment of the present application;

[0037] Figure 7 It is a schematic diagram of the structure of an electronic device shown in an exemplary embodiment of the present disclosure. DETAILED DESCRIPTION

[0038] Embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.

[0039] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.) and signals involved in this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards of relevant countries and regions.

[0040] The data acquisition, transmission, storage, use, and processing in the technical solution of this application are in compliance with the provisions of national laws and regulations.

[0041] It should be noted that in the embodiments of the present application, certain software, components, models and other existing solutions in the industry may be mentioned, and they should be regarded as exemplary. Their purpose is only to illustrate the feasibility of implementing the technical solution of the present application, but it does not mean that the applicant has or will necessarily use the solution.

[0042] The following describes the root cause alarm locating method and device of the transaction relationship tree system of the embodiment of the present application with reference to the accompanying drawings.

[0043] The transaction relationship tree can be a hierarchical management system set up by financial institutions based on the management rights of different customers and personnel within the institution, defining the scope of member units under the group, and collecting authorization and relationship data to assist in the unified presentation of account, fund, transaction and other information to group customers and personnel within the institution.

[0044] The transaction relationship tree can be a tree-structured customer information group set up for large group customers to reflect their business dealings or affiliations, and can unify information such as large group accounts and fund transactions.

[0045] The transaction relationship tree system can be understood as a transaction system with a transaction relationship tree.

[0046] A cash customer tree can be a tree-structured customer information collection set up for group customers to reflect their business dealings or affiliations.

[0047] Figure 1 A flowchart of a root cause alarm locating method for a transaction relationship tree system provided in an embodiment of the present application.

[0048] In the related art, when a transaction relationship tree system fails, low-level alarms within the failure period can be filtered out, only high-level alarms are retained, and the remaining alarms are prioritized. However, sometimes low-level alarms may contain more important information. This method of retaining high-level alarms according to alarm levels is prone to filtering out root cause alarms.

[0049] To address this problem, the present application provides a method for locating the root cause alarm of a transaction relationship tree system to accurately locate the root cause alarm, which can be applied to the bank's optimized management of account transactions. Figure 1 As shown, the root cause alarm positioning method of the transaction relationship tree system includes the following steps:

[0050] Step 101, determine the abnormal transaction in the transaction relationship tree system, and obtain the original message log of the abnormal transaction.

[0051] The occurrence of a transaction relationship tree system failure directly causes a part of transactions to time out, be interrupted, etc. In this embodiment, whether a transaction is an abnormal transaction can be determined based on the transaction duration, whether the transaction is interrupted, etc., so that which transactions in the system are abnormal transactions can be determined. For example, if the transaction duration of a transaction times out or is interrupted, the transaction can be determined to be an abnormal transaction. The number of abnormal transactions can be one or more.

[0052] From the beginning to the end of a transaction, a log of the call message can be left on the message bus, which can be called the original message log. The original message log may include but is not limited to the transaction serial number, requester information, responder information, log recording point, request message sending time, request message receiving time, response message sending time, response message receiving time, etc.

[0053] Step 102: construct a transaction tree of abnormal transactions based on the original message log.

[0054] The transaction tree may refer to a tree structure representing the calling relationship between subsystems in a transaction.

[0055] In this embodiment, the original log information can be processed to obtain multiple message pairs in the abnormal transaction, where one message pair includes a request message and a response message. One message pair represents a call, and based on the multiple message pairs, the subsystem that responds to the request message is determined, and based on the subsystem that responds to the request message, a transaction tree of the abnormal transaction is constructed.

[0056] Step 103: Determine the abnormal subsystem among the subsystems according to the operation status information of each subsystem in the transaction tree.

[0057] Exemplarily, the operation status information may include, but is not limited to, interface logs, node time consumption, whether an interruption occurs, and other information.

[0058] Exemplarily, the node time consumption of each subsystem in the transaction tree can be counted, and the abnormal subsystems in each subsystem can be determined according to the node time consumption of each subsystem. For example, the difference between the node time consumption of each subsystem and the reference time consumption of each subsystem can be determined, and the subsystem with the largest difference can be determined as the abnormal subsystem, where the reference time consumption of each subsystem can be the average value of the node time consumption of each subsystem during normal transactions.

[0059] Exemplarily, a deep learning algorithm such as a variational autoencoder (VAE) is used to learn the time consumption distribution of different subsystems in each transaction tree structure. The node consumption of each subsystem in the transaction tree of the abnormal transaction can be compared with the time consumption distribution of each system to determine the subsystem with abnormal node time consumption, and the subsystem with abnormal node time consumption can be determined as an abnormal subsystem.

[0060] Exemplarily, an interface log anomaly detection model may be pre-trained, the interface logs of each subsystem may be input into the anomaly detection model, and the anomaly detection model may be used to determine whether the interface logs in each subsystem are abnormal, and the subsystem with abnormal interface logs may be determined as an abnormal subsystem.

[0061] Step 104: Search for each alarm associated with the abnormal subsystem according to the network information corresponding to the abnormal subsystem.

[0062] Exemplarily, the network information may include, but is not limited to, the data communication network (DCN) where the abnormal subsystem is located, the network address such as the IP address, and the like.

[0063] After locating the abnormal subsystem, you can find various types of alarms that can be associated with these subsystems during the fault time period based on the network information corresponding to the abnormal subsystem, such as host alarms, database alarms, etc. Among them, the host alarm can be the host alarm of the network address where the abnormal subsystem is located, or the host alarm of the DCN where the abnormal subsystem is located, or all host alarms that can be associated with the abnormal subsystem.

[0064] Step 105: Score each alarm to obtain a score for each alarm.

[0065] In this embodiment, the alarm may be scored from multiple aspects, and the final score of the alarm may be determined based on the scores of each aspect.

[0066] Exemplarily, each scoring parameter of the alarm can be scored to obtain a sub-score of each scoring parameter, and the sub-scores of each scoring parameter can be weighted according to the weight of each scoring parameter to obtain the score of the alarm. Among them, each scoring parameter can include, for example, the alarm level, the associated subsystem type, the number of associated transactions, etc. For example, the alarm level can be divided into multiple levels from high to low, such as critical, important, minor, warning, etc.

[0067] The associated subsystem type may refer to the type of other subsystems associated with the current alarm, such as upstream subsystems and downstream subsystems. Since the abnormality of a subsystem may affect other subsystems, and different subsystem types (such as upstream subsystems, downstream subsystems, parallel subsystems, etc.) may be affected to different degrees and in different ways, the associated subsystem type is an important consideration in the scoring process.

[0068] The number of associated transactions may refer to the number of transactions associated with the current alarm. An alarm may be associated with multiple transactions, and the number of associated transactions may reflect the impact of the alarm on the transaction activities of the system. For example, the more the number of associated transactions, the higher the score of the scoring parameter.

[0069] Exemplarily, the weight of each scoring parameter may be obtained based on historical alarms, or may be set based on actual needs, which is not limited.

[0070] Since some low-level alarms may contain more important information, if high-priority alarms are retained based on alarm priority screening, the root cause alarm may be filtered out. Therefore, each scoring parameter of the alarm is scored by taking each scoring parameter as the scoring basis, and the final score of the alarm is obtained based on the sub-score of each scoring parameter. The root cause alarm is screened out based on the final score, which can improve the accuracy of root cause alarm locating.

[0071] Step 106: Determine the root cause alarm from the alarms according to the scores of the alarms.

[0072] The root cause alarm may refer to an alarm that can help find the root cause of a system failure or anomaly.

[0073] For example, the score of each alarm can be compared with a threshold value. If the score of the alarm is greater than the threshold value, the alarm can be determined as a root cause alarm, so that the root cause of the system failure or abnormality can be found according to the root cause alarm. There can be one or more root cause alarms, which are not limited.

[0074] For example, with the continuous increase in system failure cases and the emergence of new scoring criteria, machine learning can be used to determine the weights of thresholds and scoring parameters, such as logistic regression (LR), gradient boosting iterative decision tree (GBDT) and other algorithms.

[0075] For example, the current average latency index of a certain business suddenly increased, and a large number of external interface error logs appeared on the located abnormal subsystem. From the appearance, it is likely that there is a problem with the external partner. However, by searching the database node associated with the abnormal subsystem, it can be found that there are multiple alarms of important levels on the node, and multiple transactions have been affected, so it can be determined that the abnormality is more likely to be caused by the database. Later, the operation and maintenance personnel confirmed that there were indeed a large number of slow queries on the node at that time, which caused the average latency of the business to suddenly increase. The external interface error was only a symptom, and the slow database query was the root cause of the failure. It can be seen from this that accurate alarm positioning can help operation and maintenance personnel find the truth of the problem and improve the efficiency of fault analysis.

[0076] In addition, before a large-scale failure occurs, the system often has reduced performance and reduced availability, which causes a small amount of transaction flow problems. Although it is not enough to be an abnormal event, if it is not handled in time, the problem will gradually accumulate and may cause a failure. Optionally, low-level alarms associated with abnormal transactions can be determined, and low-level alarms can be analyzed in advance to handle the problem in advance to avoid failures and achieve failure warning.

[0077] In this embodiment, a fault alarm diagnosis and positioning program is built in the background of the transaction relationship tree system. The fault alarm diagnosis and positioning program is used to monitor the front-end operation data of the transaction relationship tree system in real time, collect alarm information after a system fault occurs, and determine the root cause alarm. According to the root cause alarm, the root cause of the alarm can be quickly located, and problems with the system's software and hardware can be solved in time, thereby improving the efficiency of batch solving alarm problems, maintaining the stability of system operation, and improving the transaction business handling experience of operators and users.

[0078] In an embodiment of the present application, by determining the abnormal transactions in the system and constructing a transaction tree of the abnormal transactions based on the original log messages of the abnormal transactions, the abnormal subsystem is located based on the operating status information of each subsystem in the abnormal transaction tree, thereby improving the accuracy of locating the abnormal subsystem. Then, the alarms associated with the abnormal subsystem are searched, and the root cause alarms are screened out from the alarms associated with the abnormal subsystem based on the scores of the alarms associated with the abnormal subsystem, thereby improving the accuracy of locating the root cause alarms, and then based on the root cause alarms, the cause of the fault can be accurately found, thereby improving the efficiency of fault analysis.

[0079] This embodiment provides another root cause alarm location method for a transaction relationship tree system. Figure 2 A flowchart of another root cause alarm locating method for a transaction relationship tree system provided in an embodiment of the present application.

[0080] like Figure 2 As shown, the root cause alarm location method of the transaction relationship tree system may include the following steps:

[0081] Step 201, determine the abnormal transaction in the transaction relationship tree system, and obtain the original message log of the abnormal transaction.

[0082] In this embodiment, step 201 can adopt any implementation method in the embodiments of the present application, so it will not be repeated here.

[0083] Step 202: Process the original message log to obtain multiple message pairs.

[0084] Each message pair includes a request message and a response message, and one message pair represents one call.

[0085] In this embodiment, the original message log is parsed by a rule processing engine to extract key information, such as timestamp, transaction ID, operation type (such as request or response), message content, etc., and based on the log information, it is determined which log entries are request messages and which are response messages. The defined rules are used to match request messages and response messages based on the key information, and for each successfully matched request message and response message, they are combined into a message pair.

[0086] Step 203: Generate multiple discrete tree nodes according to the responders of the calls corresponding to the multiple message pairs.

[0087] In this embodiment, information about services or components related to message processing can be retrieved from a configuration management database (CMDB), and based on the retrieved information about services and components related to message processing, the responder of the call represented by each message pair can be determined, and multiple discrete tree nodes can be generated based on the responder of the call.

[0088] Among them, a discrete tree node can represent a subsystem that responds to the request information.

[0089] Step 204: Generate a transaction tree based on the multiple discrete tree nodes.

[0090] In this embodiment, the root node of the transaction tree can be obtained from the serial number of the abnormal transaction. The root node of the transaction tree may refer to the subsystem that initiates the abnormal transaction, and it is determined whether there are several discrete nodes among all discrete tree nodes that belong to the same discrete node. If there are several discrete nodes that belong to the same discrete node, it can be determined that the discrete node to which they belong is the upstream node, and these discrete nodes are the downstream nodes. Thus, the upstream and downstream relationships of multiple discrete nodes can be determined, and the discrete nodes with upstream and downstream relationships are connected into a tree chain. A discrete node can appear in multiple tree chains, and multiple tree chains are merged according to rules such as the same parent link. An initial transaction tree is generated according to the merge result and the obtained root node, and then the initial transaction tree is horizontally merged, vertically merged, etc., to finally obtain a transaction tree.

[0091] Exemplarily, a horizontal merge may be a merge operation performed at the same level of the transaction tree (i.e., between child nodes with the same parent node), and a vertical merge may refer to a merge operation performed between different levels, such as directly promoting a child node to the position of its parent node (or a higher level), or merging multiple subtrees into a larger subtree and making it a child node of a parent node.

[0092] Step 205: Determine the abnormal subsystem among the subsystems according to the operation status information of each subsystem in the transaction tree.

[0093] In this embodiment, step 205 can adopt any implementation method in the embodiments of the present application, so it will not be described in detail here.

[0094] Step 206: Search for each alarm associated with the abnormal subsystem according to the network information corresponding to the abnormal subsystem.

[0095] In this embodiment, step 206 can adopt any implementation method in the embodiments of the present application, so it will not be described in detail here.

[0096] After locating the abnormal subsystem, you can find various types of alarms that can be associated with the abnormal subsystem during the time period when the fault occurred. For example, for host alarms, you can use the abnormal subsystem ID (i.e. account), DCN (i.e. network), IP (i.e. network address) and other information to gradually expand the scope from precise to fuzzy to associate.

[0097] Exemplarily, the host alarm of the network address can be associated according to the network address of the abnormal subsystem in the network information corresponding to the abnormal subsystem. If the host alarm of the network address is not associated, the host alarm of the DCN where the abnormal subsystem is located in the network information is associated. If the host alarm of the DCN where the abnormal subsystem is located is not associated yet, then all the host alarms that can be associated with the abnormal subsystem are associated.

[0098] For example, for database alarms, you can directly check whether there are corresponding alarms on the database nodes that the abnormal subsystem can be associated with.

[0099] Therefore, by gradually expanding the scope from the precise scope to the fuzzy scope and searching for alarms associated with abnormal subsystems, the efficiency of alarm search can be improved.

[0100] Step 207: Score each alarm to obtain a score for each alarm.

[0101] In this embodiment, step 207 can adopt any implementation method in the embodiments of the present application, so it will not be described in detail here.

[0102] Step 208: Determine the root cause alarm from the alarms according to the scores of the alarms.

[0103] In this embodiment, step 208 can adopt any implementation method in the embodiments of the present application, so it will not be repeated here.

[0104] In the embodiment of the present application, the original log message of the abnormal transaction can be processed to obtain multiple message pairs, and multiple discrete tree nodes can be generated according to the responders of the calls corresponding to the multiple message pairs, and the transaction tree of the abnormal transaction can be generated based on the multiple discrete tree nodes. Thus, multiple calls in the abnormal transaction can be determined based on the original log message, and the transaction tree can be generated based on the responders of the multiple calls, which can improve the accuracy of the transaction tree.

[0105] This embodiment provides another root cause alarm location method for a transaction relationship tree system. Figure 3 A flowchart of another root cause alarm locating method for a transaction relationship tree system provided in an embodiment of the present application.

[0106] like Figure 3 As shown, the root cause alarm location method of the transaction relationship tree system may include the following steps:

[0107] Step 301, determine the abnormal transaction in the transaction relationship tree system, and obtain the original message log of the abnormal transaction.

[0108] In this embodiment, step 301 can adopt any implementation method in the embodiments of the present application, so it will not be described in detail here.

[0109] Step 302: construct a transaction tree of abnormal transactions based on the original message log.

[0110] In this embodiment, step 302 can adopt any implementation method in the embodiments of the present application, so it will not be repeated here.

[0111] Step 303, obtaining the node time consumption of each subsystem in a normal transaction with the same transaction tree structure.

[0112] In this embodiment, the motion state information of each subsystem in the transaction tree of the abnormal transaction may include node time consumption, and the abnormal subsystem may be determined according to the node time consumption of each subsystem.

[0113] Since the transaction tree structures of different transactions may be the same, the node time consumption of each subsystem in the normal transaction with the same transaction tree structure as the abnormal transaction can be obtained, and the abnormal subsystem can be determined based on the node time consumption of each subsystem in the normal transaction.

[0114] Step 304 , compare the node time consumption of each subsystem in the normal transaction with the node time consumption of each subsystem in the transaction tree to obtain the time consumption increase of each subsystem.

[0115] In this embodiment, the node time consumption of each subsystem in a normal transaction can be compared with the node time consumption of the same subsystem in an abnormal transaction to determine the time consumption increase of each subsystem in the abnormal transaction. The time consumption increase can be represented by the difference between the node time consumption of the subsystem in the abnormal transaction and the node time consumption of the subsystem in the normal transaction. For example, the greater the time consumption increase of a subsystem in an abnormal transaction, the greater the probability that the subsystem is abnormal.

[0116] Step 305: determine the subsystem with the largest increase in time consumption among all subsystems as an abnormal subsystem.

[0117] In this embodiment, the time consumption increases of each subsystem in the abnormal transaction may be compared, and the subsystem with the largest time consumption increase may be determined as the abnormal subsystem.

[0118] Since problems in the upstream subsystem may affect the downstream subsystem, in order to improve the accuracy of locating the abnormal subsystem, the abnormal transaction can be located by combining the abnormal subsystem with its upstream subsystem for analysis. Exemplarily, the candidate abnormal subsystems in each subsystem can be determined based on the operating status information of each subsystem in the transaction tree of the abnormal transaction, and the upstream subsystem of the abnormal subsystem can be determined based on the transaction tree, and the abnormal subsystem can be determined from the upstream subsystem and the candidate abnormal subsystems based on the operating status information of the upstream subsystem. For example, the time increase of the upstream subsystem can be determined based on the operating status information of the upstream subsystem, and if the difference between the time increase of the upstream subsystem and the time increase of the candidate abnormal subsystem is less than the set threshold, the upstream subsystem can be finally determined as the abnormal subsystem.

[0119] The method for determining the candidate abnormal subsystem may refer to the method for determining the abnormal subsystem in the above embodiment.

[0120] Therefore, the candidate abnormal subsystem located by the abnormal transaction is combined with its upstream subsystem for analysis, which improves the accuracy of locating the abnormal subsystem. This can greatly reduce the scope of the root cause alarm and cover the location of the fault as much as possible.

[0121] Step 306: Search for each alarm associated with the abnormal subsystem according to the network information corresponding to the abnormal subsystem.

[0122] In this embodiment, step 306 can adopt any implementation method in the embodiments of the present application, so it will not be described in detail here.

[0123] Step 307: Score each alarm to obtain a score for each alarm.

[0124] In this embodiment, step 307 can adopt any implementation method in the embodiments of the present application, so it will not be described in detail here.

[0125] Step 308: Determine the root cause alarm from the alarms according to the scores of the alarms.

[0126] In this embodiment, step 308 can adopt any implementation method in the embodiments of the present application, so it will not be described in detail here.

[0127] In an embodiment of the present application, the operating status information of the subsystem may include node time consumption. By comparing the node time consumption of abnormal transactions and normal transactions with the same transaction tree structure, the subsystem with the largest increase in time consumption can be determined as the abnormal subsystem, thereby improving the positioning accuracy of the abnormal subsystem and the determination method is relatively simple.

[0128] The root cause alarm determined in the above embodiment may include multiple alarms of multiple types, and the readability is relatively poor. If the root cause alarm is output directly, it may not be convenient to locate the fault. Therefore, based on the above embodiment, the root cause alarm locating method may also include: clustering multiple root cause alarms to obtain multiple types of root cause alarms, merging root cause alarms of the same type to obtain a summary alarm of each type, and then outputting multiple types of summary alarms in order of the confidence of each type of root cause alarm from high to low.

[0129] For example, alarm types may include databases, application hosts, networks, internal programs, etc. Root cause alarms of the same type may be merged together, with one summarized, more readable root cause alarm retained for each type. At the same time, each type of alarm is assigned a confidence level, and the retained root cause alarms for each type are sorted and output according to the confidence level, thereby facilitating operation and maintenance personnel to quickly and accurately locate faults.

[0130] It should be noted that if there is only one root cause alarm of a certain type, the root cause alarm can be directly output as a summary alarm.

[0131] In an embodiment of the present application, multiple root cause alarms are clustered and the root cause alarms of the same type are merged to obtain a summary alarm of that type, and the root cause alarms of each type are sorted and output according to the confidence level. Since the output summary alarms are highly readable and output according to the confidence level, operation and maintenance personnel can quickly and accurately locate the fault.

[0132] In one embodiment of the present application, the transaction relationship tree can be Figure 4 Constructed as shown. Figure 4 A flowchart of another method for constructing a transaction relationship tree provided in an embodiment of the present application.

[0133] like Figure 4 As shown, the method for constructing the transaction relationship tree includes:

[0134] Step 401: Generate an initial transaction relationship tree based on the created top-level nodes and management nodes.

[0135] In this embodiment, the top node can be the root node of the transaction relationship tree, and the management node can be the next level node of the top node to establish the initial transaction relationship tree. For example, the top node can be the group headquarters, and the management node can be the authorized management agency node.

[0136] Exemplarily, the initial transaction relationship tree may include root node information and initial transaction information. According to the node information, it may include group headquarters customers, affiliated financial company customers, management node customers, etc. The initial transaction information may include customer information, opening bank information, account information, counterparty information, etc.

[0137] Step 402, based on the customer numbers of the group headquarters customers, the affiliated financial company customers, the management node customers and the customers on the group relationship tree as the root node, the node customers are obtained by recursion on the cash customer tree and the node customers are added as new nodes.

[0138] In this embodiment, the customer numbers of the group headquarters customers, the affiliated financial company customers, the management node customers, and the customers on the group relationship tree can be used as the root node to find all cash customer trees (for example, one layer can be found), identify all customer nodes and registered account numbers on the queried cash customer tree (for example, account categories include: current accounts, one-account main accounts, effective accounts, etc.) and find the corresponding customers, and obtain the customer node as a newly added node.

[0139] Step 403: Update the initial transaction relationship tree according to the newly added node.

[0140] Exemplarily, a new node may be added to the initial transaction tree to update the initial transaction relationship tree.

[0141] Step 404, taking the customer number of the newly added node as the root node, continue searching on the cash customer tree until no new customer is found, thereby obtaining a transaction relationship tree.

[0142] Exemplarily, the customer number of the newly identified node is used as the root node to find all cash customer trees, identify all customer nodes and registered account numbers on the queried cash customer tree and find the corresponding customer, and repeat this process until there is no new customer or the cash customer tree cannot be queried with the new customer as the root node. Thus, the new node customer is recursively traversed and added to the updated initial transaction relationship tree, and finally the transaction relationship tree is obtained.

[0143] In this embodiment, through the above recursive search process, a complete transaction relationship tree can be constructed, and the transaction relationship tree includes all customer nodes and account information directly or indirectly associated with the initial node.

[0144] In this embodiment, the customer numbers of the group headquarters customers, the affiliated financial company customers, the management node customers and the customers on the group relationship tree can be used as the root node to find all the cash customer trees, identify all the customer nodes and registered account numbers on the cash customer tree that are queried and find the corresponding customers. Then the customer number of the identified new customer is used as the root node to find all the cash customer trees, identify all the customer nodes and registered account numbers on the cash customer tree that are queried and find the corresponding customers, and repeat the process continuously until there is no new customer or the cash customer tree cannot be queried with the new customer as the root node. In other words, the group headquarters customers, the affiliated financial company customers, the management node customers and the customers on the group relationship tree are all used as the initial nodes, and the node customers obtained by recursion are the newly added nodes. The newly built transaction relationship tree is synchronously established based on the customer number of the top node of the group relationship tree, and the newly built transaction relationship tree can be attributed to the first-level branch to which the account management right of the group headquarters customer belongs. When the system has a newly added group relationship tree, the transaction relationship tree with the group headquarters customer as the top node is established at the end of the day.

[0145] In addition, when recursively searching for the next level node, if the next level node is another group relationship tree node and the belonging confirmation attribute has been confirmed, the next level will no longer be searched recursively.

[0146] Optionally, the nodes with authorization relationships in the transaction relationship tree can be determined based on the account-level authorization relationship and the customer-level authorization relationship. If the first node in the transaction relationship tree is only the authorizer, an authorization identifier is established for the first node. If the second node in the transaction relationship tree is only the authorized party, an authorized identifier is established for the second node. If the third node in the transaction relationship tree is both the authorizer and the authorized party, a bidirectional authorization identifier is established for the third node.

[0147] That is to say, based on the account-level authorization and the customer-level authorization relationship, the authorized party node with an authorization relationship can be identified as the authorized party, and based on the account-level authorization and the customer-level authorization relationship, the authorizer node with an authorization relationship can be identified as the authorizer. Based on the account-level authorization and the customer-level authorization relationship, the node with both an authorization relationship and an authorized relationship can be identified as a bidirectional party. For nodes without an authorization and an authorized relationship, the authorization identification can be displayed as "None".

[0148] It should be noted that the authorization identifier only displays the authorization relationship of the node in one transaction relationship tree. If the node is repeated in multiple transaction relationship trees and the authorization relationship in each transaction relationship tree is different, the displayed authorization identifier will be different.

[0149] In this embodiment, the nodes in the transaction relationship tree may include top-level nodes, management nodes, nodes to be confirmed, and general nodes. Among them, the top-level node, i.e., the root node, may be the group headquarters; the management node customer and financial company system automatically assigns management nodes when a new transaction relationship tree is created; when a node customer is repeated in multiple transaction relationship trees, it is only used as a management node in one transaction relationship tree; a node with an authorized identifier or a bidirectional identifier and in the same group relationship tree as the top-level node is confirmed as a management node, and the node is set as a general node in other repeated transaction relationship trees; nodes with an authorized identifier or a bidirectional identifier other than management nodes are assigned as nodes to be confirmed, and nodes to be confirmed are changed to management nodes or general nodes, and operators can make manual changes; general nodes may be other member units except top-level nodes, management nodes, and nodes to be confirmed.

[0150] Among them, the top-level node and the management node are unique. The top-level node can only be the top-level node in one transaction relationship tree, and cannot be the top-level node, management node, or node to be confirmed in other transaction relationship trees; the management node can only be the management node in one transaction relationship tree, and cannot be the top-level node, management node, or node to be confirmed in other transaction relationship trees.

[0151] For example, the hierarchical structure of the transaction relationship tree can be as follows: Figure 5 As shown, the group headquarters is the root node.

[0152] In an embodiment of the present application, the group headquarters customers, the affiliated financial company customers, the management node customers, and the customers on the group relationship tree are all used as initial nodes, and new nodes are discovered through recursive search, and the new nodes are added to the transaction relationship tree, thereby improving the accuracy and completeness of the transaction relationship tree.

[0153] In order to implement the above embodiment, the present application also proposes a root cause alarm locating device for a transaction relationship tree system.

[0154] Figure 6A schematic diagram of the structure of a root cause alarm locating device for a transaction relationship tree system provided in an embodiment of the present application.

[0155] like Figure 6 As shown, the root cause alarm locating device 600 of the transaction relationship tree system includes:

[0156] An acquisition module 610 is used to determine abnormal transactions in the transaction relationship tree system and obtain the original message log of the abnormal transaction;

[0157] A construction module 620, configured to construct a transaction tree of the abnormal transaction according to the original message log;

[0158] A first determination module 630, configured to determine an abnormal subsystem among the subsystems according to the operation status information of each subsystem in the transaction tree;

[0159] A search module 640 is used to search for each alarm associated with the abnormal subsystem according to the network information corresponding to the abnormal subsystem;

[0160] A scoring module 650, configured to score each of the alarms to obtain a score for each of the alarms;

[0161] The second determining module 660 is configured to determine a root cause alarm from the alarms according to the scores of the alarms.

[0162] Furthermore, in a possible implementation of the embodiment of the present application, the construction module 620 is used to:

[0163] Processing the original message log to obtain a plurality of message pairs; wherein each message pair includes a request message and a response message, and one message pair represents one call;

[0164] Generate multiple discrete tree nodes according to the responders of the calls respectively corresponding to the multiple message pairs; wherein one discrete tree node represents a subsystem that responds to the request information;

[0165] The transaction tree is generated according to the plurality of discrete tree nodes.

[0166] Furthermore, in a possible implementation of the embodiment of the present application, the construction module 620 is used to:

[0167] Determining the upstream and downstream relationships of the plurality of discrete tree nodes according to whether some of the plurality of discrete tree nodes belong to the same discrete node;

[0168] According to the upstream and downstream relationships, the plurality of discrete tree nodes are connected into a plurality of tree chains;

[0169] The multiple tree chains are merged to generate the transaction tree.

[0170] Further, in a possible implementation manner of the embodiment of the present application, the running status information includes node time consumption, and the first determining module 630 is used to:

[0171] Obtaining the node time consumption of each subsystem in a normal transaction with the same transaction tree structure;

[0172] Compare the node time consumption of each subsystem in the normal transaction with the node time consumption of each subsystem in the transaction tree to obtain the time consumption increase of each subsystem;

[0173] The subsystem with the largest increase in time consumption among the subsystems is determined as the abnormal subsystem.

[0174] Further, in a possible implementation of the embodiment of the present application, the first determining module 630 is configured to:

[0175] Determine, according to the operation status information of each subsystem in the transaction tree, a candidate abnormal subsystem among the subsystems;

[0176] Determining an upstream subsystem of the abnormal subsystem according to the transaction tree;

[0177] The abnormal subsystem is determined from the upstream subsystem and the candidate abnormal subsystems according to the operation status information of the upstream subsystem.

[0178] Furthermore, in a possible implementation of the embodiment of the present application, the search module 640 is used to:

[0179] According to the network address where the abnormal subsystem is located in the network information, an alarm of a host associated with the network address;

[0180] In response to a host alarm that is not associated with the network address, the host alarm of the data communication network where the abnormal subsystem in the network information is located is associated.

[0181] Furthermore, in a possible implementation of the embodiment of the present application, the scoring module 650 is used to:

[0182] Scoring each scoring parameter of the alarm to obtain a sub-score of each scoring parameter;

[0183] According to the weights of the various scoring parameters, the sub-scores of the various scoring parameters are weighted to obtain the score of the alarm.

[0184] Furthermore, in a possible implementation of the embodiment of the present application, there are multiple root cause alarms, and the device may further include:

[0185] A clustering module, used to cluster the multiple root cause alarms to obtain multiple types of root cause alarms;

[0186] The merging module is used to merge the root cause alarms of the same type to obtain a summary alarm of each type;

[0187] The output module is used to output the multiple types of summary alarms in order of confidence of each type of root cause alarm from high to low.

[0188] Furthermore, in a possible implementation of the embodiment of the present application, the device may also include:

[0189] A generation module, used to generate an initial transaction relationship tree based on the created top-level nodes and management nodes;

[0190] A query module is used to obtain node customers on the cash customer tree by recursion based on the customer numbers of the group headquarters customers, the affiliated financial company customers, the management node customers and the customers on the group relationship tree as root nodes, and use the node customers as new nodes;

[0191] An updating module, used to update the initial transaction relationship tree according to the newly added node;

[0192] The query module is further used to take the customer number of the newly added node as the root node, continue searching on the cash customer tree until no new customer is found, and obtain the transaction relationship tree.

[0193] Furthermore, in a possible implementation of the embodiment of the present application, the device may also include:

[0194] A third determination module, configured to determine nodes in the transaction relationship tree that have authorization relationships according to the account-level authorization relationship and the customer-level authorization relationship;

[0195] An establishment module is used to establish an authorization identifier for the first node in the transaction relationship tree in response to the first node being only the authorized party; to establish an authorized identifier for the second node in response to the second node being only the authorized party; and to establish a bidirectional authorization identifier for the third node in response to the third node being both the authorized party and the authorized party.

[0196] It should be noted that the above explanation of the embodiment of the root cause alarm locating method of the transaction relationship tree system is also applicable to the root cause alarm locating device of the transaction relationship tree system of this embodiment, and will not be repeated here.

[0197] In an embodiment of the present application, by determining the abnormal transactions in the system and constructing a transaction tree of the abnormal transactions based on the original log messages of the abnormal transactions, the abnormal subsystem is located based on the operating status information of each subsystem in the abnormal transaction tree, thereby improving the accuracy of locating the abnormal subsystem. Then, the alarms associated with the abnormal subsystem are searched, and the root cause alarms are screened out from the alarms associated with the abnormal subsystem based on the scores of the alarms associated with the abnormal subsystem, thereby improving the accuracy of locating the root cause alarms, and then based on the root cause alarms, the cause of the fault can be accurately found, thereby improving the efficiency of fault analysis.

[0198] In order to implement the above embodiments, the present application also proposes an electronic device, comprising: a processor, and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the method provided by the above embodiments.

[0199] In order to implement the above embodiments, the present application also proposes an electronic device, comprising: a processor, and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the method provided by the above embodiments.

[0200] As an example, Figure 7 is a schematic diagram of the structure of an electronic device shown in an exemplary embodiment of the present disclosure, such as Figure 7 As shown, the electronic device 700 may further include:

[0201] The memory 710 and the processor 720, a bus 730 connecting different components (including the memory 710 and the processor 720), the memory 710 stores a computer program, and when the processor 720 executes the program, the information collection method described in the embodiment of the present disclosure is implemented.

[0202] Bus 730 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processor or a local bus using any of a variety of bus architectures. For example, these architectures include but are not limited to Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MAC) bus, Enhanced ISA bus, Video Electronics Standards Association (VESA) local bus and Peripheral Component Interconnect (PCI) bus.

[0203] The electronic device 700 typically includes a variety of electronic device readable media. These media can be any available media that can be accessed by the electronic device 700, including volatile and non-volatile media, removable and non-removable media.

[0204] The memory 710 may also include computer system readable media in the form of volatile memory, such as random access memory (RAM) 740 and / or cache memory 750. The electronic device 700 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, the storage system 760 may be used to read and write non-removable, non-volatile magnetic media ( Figure 7 not shown, usually called a "hard drive"). Although Figure 7 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk"), and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, a DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to the bus 730 via one or more data medium interfaces. The memory 710 may include at least one program product having a set (e.g., at least one) of program modules that are configured to perform the functions of the various embodiments of the present disclosure.

[0205] A program / utility 780 having a set (at least one) of program modules 770 may be stored, for example, in the memory 710, such program modules 770 including but not limited to an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment. The program modules 770 generally perform the functions and / or methods of the embodiments described in the present disclosure.

[0206] The electronic device 700 may also communicate with one or more external devices 790 (e.g., keyboard, pointing device, display 791, etc.), may also communicate with one or more devices that enable a user to interact with the electronic device 700, and / or communicate with any device that enables the electronic device 700 to communicate with one or more other computing devices (e.g., network card, modem, etc.). Such communication may be performed through an input / output (I / O) interface 792. Furthermore, the electronic device 700 may also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN) and / or public network, such as the Internet) through a network adapter 793. As shown, the network adapter 793 communicates with other modules of the electronic device 700 through a bus 730. It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with the electronic device 700, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0207] The processor 720 executes various functional applications and data processing by running the programs stored in the memory 710 .

[0208] In order to implement the above embodiments, the present application also proposes a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the methods provided by the above embodiments.

[0209] In order to implement the above embodiments, the present application also proposes a computer program product, including a computer program, which implements the methods provided by the above embodiments when executed by a processor.

[0210] The collection, storage, use, processing, transmission, provision and disclosure of user personal information involved in this application are in compliance with relevant laws and regulations and do not violate public order and good morals.

[0211] It should be noted that personal information from users should be collected for legitimate and reasonable purposes and should not be shared or sold outside of these legitimate uses. In addition, such collection / sharing should be carried out after receiving the user's informed consent, including but not limited to notifying the user to read the user agreement / user notice and sign the agreement / authorization including authorization of relevant user information before the user uses the function. In addition, any necessary steps should be taken to protect and safeguard access to such personal information data and ensure that others who have access to personal information data comply with its privacy policy and procedures.

[0212] The present application is expected to provide an implementation scheme for users to selectively block the use or access of personal information data. That is, the present disclosure is expected to provide hardware and / or software to prevent or block access to such personal information data. Once the personal information data is no longer needed, the risk can be minimized by limiting data collection and deleting the data. In addition, when applicable, such personal information is de-identified to protect the privacy of the user.

[0213] In the description of the aforementioned embodiments, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, without contradiction.

[0214] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of the features. In the description of this application, the meaning of "plurality" is at least two, such as two, three, etc., unless otherwise clearly and specifically defined.

[0215] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, fragment or portion of code comprising one or more executable instructions for implementing the steps of a custom logical function or process, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in the reverse order depending on the functions involved, which should be understood by technicians in the technical field to which the embodiments of the present application belong.

[0216] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by an instruction execution system, device or apparatus (such as a computer-based system, a system including a processor, or other system that can fetch instructions from an instruction execution system, device or apparatus and execute the instructions), or in combination with these instruction execution systems, devices or apparatuses. For the purpose of this specification, "computer-readable medium" can be any device that can contain, store, communicate, propagate or transmit a program for use by an instruction execution system, device or apparatus, or in combination with these instruction execution systems, devices or apparatuses. More specific examples of computer-readable media (a non-exhaustive list) include the following: an electrical connection with one or more wires (electronic device), a portable computer disk box (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable and programmable read-only memory (EPROM or flash memory), a fiber optic device, and a portable compact disk read-only memory (CDROM). In addition, the computer-readable medium may even be paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other medium and then editing, interpreting or processing in other suitable ways if necessary, and then stored in a computer memory.

[0217] It should be understood that the various parts of the present application can be implemented by hardware, software, firmware or a combination thereof. In the above-mentioned embodiments, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0218] A person skilled in the art may understand that all or part of the steps in the method for implementing the above-mentioned embodiment may be completed by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiment.

[0219] In addition, each functional unit in each embodiment of the present application may be integrated into a processing module, or each unit may exist physically separately, or two or more units may be integrated into one module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. If the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer-readable storage medium.

[0220] The storage medium mentioned above may be a read-only memory, a magnetic disk or an optical disk, etc. Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limiting the present application. A person of ordinary skill in the art may change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A root cause alarm location method for a transaction relationship tree system, characterized in that: The method comprises the following steps: Determine abnormal transactions in the transaction relationship tree system, and obtain original message logs of the abnormal transactions; Constructing a transaction tree of the abnormal transaction according to the original message log; Determine an abnormal subsystem among the subsystems according to the operation status information of each subsystem in the transaction tree; According to the network information corresponding to the abnormal subsystem, searching for each alarm associated with the abnormal subsystem; Scoring each of the alarms to obtain a score for each of the alarms; According to the scores of the various alarms, a root cause alarm is determined from the various alarms.

2. The method according to claim 1, characterized in that The step of constructing a transaction tree of the abnormal transaction according to the original message log includes: Processing the original message log to obtain a plurality of message pairs; wherein each message pair includes a request message and a response message, and one message pair represents one call; Generate multiple discrete tree nodes according to the responders of the calls respectively corresponding to the multiple message pairs; wherein one discrete tree node represents a subsystem that responds to the request information; The transaction tree is generated according to the plurality of discrete tree nodes.

3. The method according to claim 2, characterized in that The step of generating the transaction tree according to the plurality of discrete tree nodes comprises: Determining the upstream and downstream relationships of the plurality of discrete tree nodes according to whether some of the plurality of discrete tree nodes belong to the same discrete node; According to the upstream and downstream relationships of the plurality of discrete tree nodes, the plurality of discrete tree nodes are connected into a plurality of tree chains; The multiple tree chains are merged to generate the transaction tree.

4. The method according to claim 1, characterized in that The operation status information includes node time consumption, and determining an abnormal subsystem among the subsystems according to the operation status information of each subsystem in the transaction tree includes: Obtaining the node time consumption of each subsystem in a normal transaction with the same transaction tree structure; Compare the node time consumption of each subsystem in the normal transaction with the node time consumption of each subsystem in the transaction tree to obtain the time consumption increase of each subsystem; The subsystem with the largest increase in time consumption among the subsystems is determined as the abnormal subsystem.

5. The method according to claim 1, characterized in that The step of determining an abnormal subsystem among the subsystems according to the operation status information of each subsystem in the transaction tree includes: Determine, according to the operation status information of each subsystem in the transaction tree, a candidate abnormal subsystem among the subsystems; Determining an upstream subsystem of the abnormal subsystem according to the transaction tree; The abnormal subsystem is determined from the upstream subsystem and the candidate abnormal subsystems according to the operation status information of the upstream subsystem.

6. The method according to claim 1, characterized in that The searching, according to the network information corresponding to the abnormal subsystem, for each alarm associated with the abnormal subsystem includes: According to the network address where the abnormal subsystem is located in the network information, an alarm of a host associated with the network address; In response to a host alarm that is not associated with the network address, the host alarm of the data communication network where the abnormal subsystem in the network information is located is associated.

7. The method according to claim 1, characterized in that Scoring each of the alarms to obtain a score for each of the alarms includes: Scoring each scoring parameter of the alarm to obtain a sub-score of each scoring parameter; According to the weights of the various scoring parameters, the sub-scores of the various scoring parameters are weighted to obtain the score of the alarm.

8. The method according to claim 1, characterized in that If there are multiple root cause alarms, the method further includes: Clustering the multiple root cause alarms to obtain multiple types of root cause alarms; Merge root cause alarms of the same type to obtain a summary alarm of each type; The multiple types of summary alarms are outputted in descending order of confidence of each type of root cause alarm.

9. The method according to claim 1, characterized in that The transaction relationship tree in the transaction relationship tree system is constructed in the following manner: Generate an initial transaction relationship tree based on the created top-level nodes and management nodes; According to the customer numbers of the group headquarters customers, the affiliated financial company customers, the management node customers and the customers on the group relationship tree as the root node, the node customers are obtained by recursion on the cash customer tree, and the node customers are used as new nodes; According to the newly added node, the initial transaction relationship tree is updated; The customer number of the newly added node is used as the root node, and the search continues on the cash customer tree until no new customers are found, thereby obtaining the transaction relationship tree.

10. The method according to claim 9, characterized in that Also includes: Determine, based on the account-level authorization relationship and the customer-level authorization relationship, a node in the transaction relationship tree where an authorization relationship exists; In response to the first node in the transaction relationship tree being only an authorized party, establishing an authorization identifier for the first node; In response to the second node in the transaction relationship tree being only an authorized party, establishing an authorized identification for the second node; In response to a third node in the transaction relationship tree being both an authorizer and an authorized party, a bidirectional authorization identifier is established for the third node.

11. A root cause alarm locating device for a transaction relationship tree system, characterized in that: include: An acquisition module, used to determine abnormal transactions in the transaction relationship tree system and obtain the original message log of the abnormal transaction; A construction module, used to construct a transaction tree of the abnormal transaction according to the original message log; A first determination module, configured to determine an abnormal subsystem among the subsystems according to the operation status information of each subsystem in the transaction tree; A search module, used to search for each alarm associated with the abnormal subsystem according to the network information corresponding to the abnormal subsystem; A scoring module, used to score each of the alarms to obtain a score for each of the alarms; The second determining module is used to determine the root cause alarm from the various alarms according to the scores of the various alarms.

12. An electronic device, characterized in that: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 10 when executed by a processor.

14. A computer program product, characterized in that The invention comprises a computer program, which implements the method according to any one of claims 1 to 10 when being executed by a processor.

Images