Abnormality positioning method and related equipment
Patent Information
- Application Number
- CN202411716936.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-27
- Publication Date
- 2025-03-18
AI Technical Summary
In complex distributed business scenarios, the calls of each business subsystem in the business system are frequent and complex, so that when an exception occurs in one business scenario, abnormal performance data reflected in multiple business subsystems occur, resulting in difficulty in positioning abnormalities.
By receiving performance log messages sent by each service subsystem on the monitoring platform, establishing a transaction model, using the call link in the transaction model to determine the abnormal service subsystem, and quickly locate the service subsystem that causes abnormal transaction codes.
It improves the ability and efficiency of abnormal positioning, and can quickly identify the business subsystem that causes abnormal transaction codes, reducing the difficulty of abnormal positioning.
Smart Images
Figure CN119645763A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of computer technology, and in particular to an abnormality locating method, device, electronic device, computer-readable storage medium, and computer program product. Background Art
[0002] In financial scenarios, more and more service providers are using distributed architecture to build their own business systems, providing different business functions according to product definitions, thereby combining various business scenarios and providing a variety of transaction services. By monitoring the performance data of the business system, the stability and observability of the business system can be improved, and abnormalities in the business system can be discovered in a timely manner.
[0003] However, in increasingly complex business scenarios, the calls to various business subsystems in the business system are more frequent and complex. When an abnormality occurs in a business scenario (i.e., a transaction business of a certain transaction type), it is often reflected in the performance data of multiple business subsystems. Abnormalities make it extremely difficult to locate the abnormality. Summary of the invention
[0004] The present application provides an abnormality location method, which can quickly locate the business subsystem that causes the transaction code abnormality, improving the abnormality location capability and efficiency. The present application also provides a device, electronic device, computer-readable storage medium and computer program product corresponding to the above method.
[0005] In a first aspect, the present application provides an abnormality location method. Applied to a monitoring platform, the monitoring platform is used to monitor multiple distributed business systems, each of the distributed business systems includes multiple business subsystems deployed in a distributed manner, and each of the distributed business systems is used to perform transaction business of a corresponding transaction type, the method comprising:
[0006] Receiving a plurality of performance log messages sent by each business subsystem in the plurality of distributed business systems; wherein the performance log message includes: a log number for identifying a transaction, a transaction code for identifying a transaction type, a service code for identifying a business subsystem, a call code for identifying a caller, and performance data;
[0007] Determine multiple transaction models corresponding to the multiple transactions according to the multiple performance log messages; wherein the nodes of the transaction model are multiple business subsystems that complete the transaction, and the call links between the nodes of the transaction model are determined by the call codes used to identify the callers in the performance log messages of the multiple business subsystems that complete the transaction;
[0008] In response to the first transaction code generating an exception, at least one business subsystem causing the first transaction code to generate an exception is determined according to the multiple transaction models.
[0009] In some possible implementations, in response to the first transaction code generating an exception, determining, according to the multiple transaction models, at least one business subsystem causing the first transaction code to generate an exception includes:
[0010] In response to a first transaction code generating an abnormality, determining an abnormal transaction model involving the first transaction code from the plurality of transaction models;
[0011] Determine the candidate business subsystem corresponding to each node in the abnormal transaction model;
[0012] At least one business subsystem causing the first transaction code to be abnormal is determined based on the performance data in the performance log message of the candidate business subsystem.
[0013] In some possible implementations, determining at least one business subsystem causing the first transaction code to be abnormal according to the performance data in the performance log message of the candidate business subsystem includes:
[0014] In response to an abnormality in performance data in a performance log message of a first business subsystem in the candidate business subsystem, it is determined that the first business subsystem causes the first transaction code to be abnormal.
[0015] In some possible implementations, the method further includes:
[0016] In response to the first service code generating an exception, at least one transaction causing the exception due to the first business subsystem identified by the first service code is determined according to the multiple transaction models.
[0017] In some possible implementations, in response to the first service code generating an exception, determining, according to the multiple transaction models, at least one transaction in which the first business subsystem identified by the first service code causes the exception includes:
[0018] In response to the first service code generating an exception, determining a candidate transaction model involving the first service code from the plurality of transaction models;
[0019] According to the performance data in the performance log messages of the business subsystems corresponding to each node in the candidate transaction model, in response to the presence of an abnormality in the performance data in the performance log messages of the business subsystems corresponding to each node in the first transaction model in the candidate transaction model, it is determined that the transaction corresponding to the first transaction model is caused by the first business subsystem identified by the first service code.
[0020] In some possible implementations, the calling code for identifying the caller is a transaction code or a service code.
[0021] In a second aspect, the present application provides an abnormality location device. Deployed on a monitoring platform, the monitoring platform is used to monitor multiple distributed business systems, each of the distributed business systems includes multiple business subsystems deployed in a distributed manner, and each of the distributed business systems is used to perform transaction services of a corresponding transaction type, and the device includes:
[0022] A communication module, used to receive a plurality of performance log messages sent by each business subsystem in the plurality of distributed business systems; wherein the performance log message includes: a log number for identifying a transaction, a transaction code for identifying a transaction type, a service code for identifying a business subsystem, a call code for identifying a caller, and performance data;
[0023] A first determination module is used to determine multiple transaction models corresponding to multiple transactions according to the multiple performance log messages; wherein the nodes of the transaction model are multiple business subsystems that complete the transaction, and the call links between the nodes of the transaction model are determined by the call code used to identify the caller in the performance log messages of the multiple business subsystems that complete the transaction;
[0024] The second determination module is used to determine, in response to the first transaction code generating an exception, at least one business subsystem causing the first transaction code to generate an exception according to the multiple transaction models.
[0025] In some possible implementations, the second determining module is specifically configured to:
[0026] In response to a first transaction code generating an abnormality, determining an abnormal transaction model involving the first transaction code from the plurality of transaction models;
[0027] Determine the candidate business subsystem corresponding to each node in the abnormal transaction model;
[0028] At least one business subsystem causing the first transaction code to be abnormal is determined based on the performance data in the performance log message of the candidate business subsystem.
[0029] In some possible implementations, the second determining module is specifically configured to:
[0030] In response to an abnormality in performance data in a performance log message of a first business subsystem in the candidate business subsystem, it is determined that the first business subsystem causes the first transaction code to be abnormal.
[0031] In some possible implementations, the second determining module is further configured to:
[0032] In response to the first service code generating an exception, at least one transaction causing the exception due to the first business subsystem identified by the first service code is determined according to the multiple transaction models.
[0033] In some possible implementations, the second determining module is specifically configured to:
[0034] In response to the first service code generating an exception, determining a candidate transaction model involving the first service code from the plurality of transaction models;
[0035] According to the performance data in the performance log messages of the business subsystems corresponding to each node in the candidate transaction model, in response to the presence of an abnormality in the performance data in the performance log messages of the business subsystems corresponding to each node in the first transaction model in the candidate transaction model, it is determined that the transaction corresponding to the first transaction model is caused by the first business subsystem identified by the first service code.
[0036] In some possible implementations, the calling code for identifying the caller is a transaction code or a service code.
[0037] In a third aspect, the present application provides an electronic device, wherein the electronic device comprises a processor and a memory, wherein the memory stores instructions, and the processor executes the instructions so that the electronic device platform executes the method as described in the first aspect of the present application or any implementation of the first aspect.
[0038] In a fourth aspect, the present application provides a computer-readable storage medium. The computer-readable storage medium stores instructions, which, when executed on an electronic device, enable the electronic device to execute the method described in the first aspect or any one of the implementations of the first aspect.
[0039] In a fifth aspect, the present application provides a computer program product. The computer program product includes computer-readable instructions, and when the computer program product is executed on an electronic device, the electronic device executes the method described in the first aspect or any one of the implementations of the first aspect.
[0040] Based on the implementations provided in the above aspects, this application can also be further combined to provide more implementations.
[0041] Based on the above description, it can be seen that the technical solution of this application has the following beneficial effects:
[0042] Specifically, the method is applied to a monitoring platform, which is used to monitor multiple distributed business systems, each distributed business system includes multiple business subsystems deployed in a distributed manner, and each distributed business system is used to perform transaction business of corresponding transaction types. The method first receives multiple performance log messages sent by each business subsystem in the multiple distributed business systems, wherein the performance log message includes: a log number for identifying the transaction, a transaction code for identifying the transaction type, a service code for identifying the business subsystem, a call code for identifying the caller, and performance data. Then, based on the multiple performance log messages, multiple transaction models corresponding to the multiple transactions are determined, wherein the nodes of the transaction model are the multiple business subsystems that complete the transaction, and the call links between the nodes of the transaction model are determined by the call code for identifying the caller in the performance log messages of the multiple business subsystems that complete the transaction. In response to an exception in the first transaction code, at least one business subsystem that causes the first transaction code to generate the exception is determined based on the multiple transaction models.
[0043] In this method, by configuring a call code for identifying the caller in the performance log message of each business subsystem, when the business subsystem reports the performance log message to the monitoring platform, the monitoring platform can establish a transaction model for each business. In this way, when a certain transaction code (i.e., a certain type of transaction business) is abnormal, the transaction model is screened, and the business subsystem that caused the transaction code abnormality can be quickly located, thereby improving the abnormality location capability and efficiency. BRIEF DESCRIPTION OF THE DRAWINGS
[0044] The above and other features, advantages and aspects of the embodiments of the present application will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the accompanying drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and the originals and elements are not necessarily drawn to scale.
[0045] Figure 1 A schematic diagram of a flow chart of an abnormality location method provided in an embodiment of the present application;
[0046] Figure 2 A schematic diagram of a distributed business system provided in an embodiment of the present application;
[0047] Figure 3 A schematic diagram of the structure of an abnormality locating device provided in an embodiment of the present application;
[0048] Figure 4 A schematic diagram of the structure of an electronic device for realizing abnormality positioning provided in an embodiment of the present application. DETAILED DESCRIPTION
[0049] The embodiments of the present application will be described in more detail below with reference to the accompanying drawings. Although certain embodiments of the present application are shown in the accompanying drawings, it should be understood that the present application can be implemented in various forms and should not be construed as being limited to the embodiments described herein. Instead, these embodiments are provided to provide a more thorough and complete understanding of the present application. It should be understood that the drawings and embodiments of the present application are only for exemplary purposes and are not intended to limit the scope of protection of the present application.
[0050] The term "including" and its variations used herein are open inclusions, i.e., "including but not limited to". The term "based on" means "based at least in part on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". The relevant definitions of other terms will be given in the following description.
[0051] It should be noted that the concepts such as "first" and "second" mentioned in this application are only used to distinguish different devices, modules or units, and are not used to limit the order or interdependence of the functions performed by these devices, modules or units.
[0052] It should be noted that the modifications of "one" and "plurality" mentioned in the present application are illustrative rather than restrictive, and those skilled in the art should understand that unless otherwise clearly indicated in the context, it should be understood as "one or more".
[0053] In order to facilitate understanding of the technical solution of the present application, the specific technical terms and application scenarios in the present application are explained below.
[0054] Performance monitoring: Performance monitoring refers to the detection and recording of performance indicators of software, hardware or systems during operation so that they can be analyzed to detect potential performance problems. By collecting and analyzing performance data, system bottlenecks can be identified, resource allocation can be optimized, and system reliability and stability can be improved.
[0055] Performance data: Performance data usually includes monitoring data of business systems, such as transaction volume, response time, success rate, etc.
[0056] Performance log: Performance log is a form of performance monitoring implementation. The business system prints the attributes of each transaction into a log file according to the agreed format, and pushes the log file to the monitoring platform for analysis.
[0057] Distributed business system: A distributed business system is a set of computer programs distributed across multiple computing nodes. Each node is an independent physical device or software process, but they all work to achieve a common goal. In a distributed business system, a single business transaction is broken down, and each part is handled by a business subsystem.
[0058] Transaction channel: the source of the transaction, such as access through web channels, mobile channels, etc.
[0059] Transaction control: used to judge transactions sent through various channels and forward them to different business subsystems for processing based on transaction types.
[0060] Business subsystem: A system that processes business logic distributed by the transaction control system. It is divided into product system and basic system. The product system is used to process specific business logic, and the basic system is used to provide the required data (such as account information) and other information when the product system processes business.
[0061] Transaction code: A code agreed upon for each business scenario (i.e., transaction type) to distinguish different business scenarios and for transaction master control to forward and record.
[0062] Service code: In a distributed business system, each business subsystem provides calling services to other systems through service codes to provide its own different business processing functions.
[0063] In financial scenarios, more and more service providers are using distributed architecture to build their own business systems, providing different business functions according to product definitions, thereby combining various business scenarios and providing a variety of transaction services. By monitoring the performance data of the business system, the stability and observability of the business system can be improved, and abnormalities in the business system can be discovered in a timely manner.
[0064] However, in increasingly complex business scenarios, the calls to various business subsystems in the business system are more frequent and complex. When an abnormality occurs in a business scenario (i.e., a transaction business of a certain transaction type), it is often reflected in the performance data of multiple business subsystems. Abnormalities make it extremely difficult to locate the abnormality.
[0065] In view of this, the present application provides an abnormality positioning method. The method is applied to a monitoring platform, and the monitoring platform is used to monitor multiple distributed business systems, each distributed business system includes multiple business subsystems deployed in a distributed manner, and each distributed business system is used to perform transaction business of corresponding transaction types. The method first receives multiple performance log messages sent by each business subsystem in the multiple distributed business systems, wherein the performance log message includes: a log number for identifying a transaction, a transaction code for identifying a transaction type, a service code for identifying a business subsystem, a call code for identifying a caller, and performance data. Then, according to the multiple performance log messages, multiple transaction models corresponding to the multiple transactions are determined, wherein the nodes of the transaction model are multiple business subsystems that complete the transaction, and the call links between the nodes of the transaction model are determined by the call code for identifying the caller in the performance log messages of the multiple business subsystems that complete the transaction. In response to the first transaction code generating an abnormality, at least one business subsystem that causes the first transaction code to generate an abnormality is determined according to the multiple transaction models.
[0066] In this method, by configuring a call code for identifying the caller in the performance log message of each business subsystem, when the business subsystem reports the performance log message to the monitoring platform, the monitoring platform can establish a transaction model for each business. In this way, when a certain transaction code (i.e., a certain type of transaction business) is abnormal, the transaction model is screened, and the business subsystem that caused the transaction code abnormality can be quickly located, thereby improving the abnormality location capability and efficiency.
[0067] Next, the abnormality location method provided by the present application is described in detail with reference to the accompanying drawings. Figure 1 A flow chart of an abnormality location method is shown, the method is applied to a monitoring platform, the monitoring platform is used to monitor multiple distributed business systems, each distributed business system includes multiple business subsystems deployed in a distributed manner, each distributed business system is used to perform transaction business of a corresponding transaction type, and specifically includes the following steps:
[0068] S101: receiving a plurality of performance log messages sent by respective business subsystems in a plurality of distributed business systems.
[0069] The performance log message includes: a log number for identifying a transaction, a transaction code for identifying a transaction type, a service code for identifying a business subsystem, a call code for identifying a caller, and performance data.
[0070] In other words, the transaction code can be understood as a mark used to determine the transaction type or transaction scenario, the log number can be understood as a mark used to determine whether it belongs to the same transaction, and the call code can be understood as a mark used to establish a calling relationship between multiple business subsystems in a distributed business system.
[0071] In some possible implementations, the calling code used to identify the caller is a transaction code or a service code. In other words, the transaction code or the service code indicates the calling relationship between multiple business subsystems in the transaction business.
[0072] Furthermore, the performance log message may also include the business subsystem name, transaction channel, time consumption, error code and return code, etc., which is not limited in the embodiment of the present application.
[0073] by Figure 2 The distributed business system shown is used as an example for explanation. In this distributed business system, it includes several business subsystems including a channel system, a general control system, a product system A, a product system B, a basic system a and a basic system b. The distributed business system is used for dynamic account transaction business.
[0074] Specifically, the account movement transaction is sent from a channel system to the master control system. The master control system receives the transaction code (trans) and forwards it to the corresponding product system A according to the type. Product system A receives the transaction code and calls the service code (service1) of product system B to query the account balance. Product system B calls the service code (service2) of basic system a to obtain transaction contract information. Product system B then calls the service code (service3) of basic system b to obtain customer information and complete the function of querying the balance. Product system B returns the account balance, product system A processes the transfer, and the transfer result is returned to the transaction channel, and the transaction is completed.
[0075] Taking product system B as an example, since product system A calls product system B, the calling code of product system B is the service code, and the performance log message of product system B can be:
[0076] {
[0077] "logNo":"2571460893483484", / / Log number
[0078] "sys":"Product System B", / / Business subsystem name
[0079] "transCode":"trans", / / Transaction code
[0080] "channel":"Channel system", / / Transaction channel
[0081] "svc":"service1", / / Service code
[0082] "svcFrom":"trans", / / calling code
[0083] "cost":"1000ms", / / Time consumption
[0084] "errCode":"", / / Error code
[0085] "returnCode":"S" / / Return code
[0086] ........ / / Performance data
[0087] }
[0088] Taking product system A as an example, since product system A is called by the master control system, the calling code of product system A is the transaction code, and the performance log message of product system A can be:
[0089] {
[0090] "logNo":"2571460893483484", / / Log number
[0091] "sys":"Product System A", / / Business subsystem name
[0092] "transCode":"trans", / / Transaction code
[0093] "channel":"Channel system", / / Transaction channel
[0094] "svc":"trans", / / service code
[0095] "svcFrom":"trans", / / calling code
[0096] "cost":"2000ms", / / Time consumption
[0097] "errCode":"", / / Error code
[0098] "returnCode":"S" / / Return code
[0099] ........ / / Other performance data
[0100] }
[0101] It can be seen from the performance log messages of product system A and product system B that the two performance log messages of product system A and product system B belong to one transaction through the consistency of log numbers, the transaction type is determined through the consistency of transaction codes, the transaction sending channel is determined through the consistency of channels, the service provided by this business subsystem is determined through the service code, and the business subsystem that calls this business subsystem is determined through the calling code.
[0102] S102: Determine multiple transaction models corresponding to multiple transactions according to multiple performance log messages.
[0103] Among them, the nodes of the transaction model are multiple business subsystems that complete the transaction, and the call links between the nodes of the transaction model are determined by the call code used to identify the caller in the performance log messages of the multiple business subsystems that complete the transaction.
[0104] That is to say, since a call code for identifying the caller is added to the performance log message in the embodiment of the present application, a transaction model in the transaction business process can be established through the performance log message.
[0105] Continue as Figure 2 The distributed business system shown is used as an example for explanation. Since the channel system does not directly participate in business transaction processing and has been reflected in the performance log message, the transaction model in the embodiment of the present application can ignore the channel system. Figure 2 The transaction model of the distributed business system shown has five nodes: product system A, product system B, basic system a, basic system b and master control system. There are four call links, namely: master control system → product system A, product system A → product system B, product system A → basic system a, product system B → basic system b.
[0106] In specific implementation, the monitoring receipt can determine the transaction model under a certain transaction type (i.e., a certain business scenario) through the transaction code. Furthermore, the corresponding relationship between the transaction code and the transaction model is 1:N, that is, the same transaction code can correspond to multiple transaction models.
[0107] It should be noted that in some embodiments, abnormal transactions may not complete the entire transaction model. The return code and error code in the performance log message are used to determine whether the transaction is successful. In this way, incomplete transactions are eliminated and the complete transaction model is retained.
[0108] S103: In response to the first transaction code generating an exception, determine at least one business subsystem causing the first transaction code to generate an exception according to a plurality of transaction models.
[0109] The first transaction code may be any transaction code in a plurality of transaction models.
[0110] In a specific implementation, in response to an exception generated by the first transaction code, an abnormal transaction model involving the first transaction code is determined from multiple transaction models, and candidate business subsystems corresponding to each node in the abnormal transaction model are determined; based on performance data in performance log messages of the candidate business subsystems, at least one business subsystem that caused the exception in the first transaction code is determined.
[0111] That is, when the first transaction code is abnormal, the transaction model with the first transaction code, that is, the transaction type of the first transaction code, is determined as an abnormal transaction model that may be abnormal through the transaction codes of each node in the transaction model.
[0112] Furthermore, by analyzing the performance data of the candidate business subsystems corresponding to each node in the abnormal transaction model, in response to the presence of an abnormality in the performance data in the performance log message of the first business subsystem in the candidate business subsystem, such as a decrease in success rate or an increase in response time, it is determined that the first business subsystem caused the abnormality in the first transaction code.
[0113] That is to say, by analyzing the performance data of the candidate business subsystem, it is determined whether the candidate business subsystem is abnormal, and then the business subsystem that caused the abnormality of the first transaction code can be obtained to achieve abnormal location. In addition, the factors causing the abnormality of the business subsystem that caused the abnormality of the first transaction code can be assisted in troubleshooting according to the information such as the channel system and error code in the performance log message.
[0114] In some embodiments, in response to the first service code generating an exception, at least one transaction in which the first business subsystem identified by the first service code causes the exception is determined based on multiple transaction models.
[0115] The first service code may be a service code of any service subsystem in the plurality of distributed service systems.
[0116] Further, in response to the first service code generating an exception, a candidate transaction model involving the first service code is determined from a plurality of transaction models.
[0117] That is to say, when an abnormality occurs in the first business subsystem identified by the first service code, the service code of each node in the transaction model is used to determine the transaction model with the first service code, that is, the transaction model including the first business subsystem in the transaction model, as a candidate transaction model that may be affected by the first business subsystem.
[0118] Next, based on the performance data in the performance log messages of the business subsystems corresponding to each node in the candidate transaction model, in response to the presence of an abnormality in the performance log messages of the business subsystems corresponding to each node in the first transaction model in the candidate transaction model, it is determined that the transaction corresponding to the first transaction model is caused by the first business subsystem identified by the first service code.
[0119] That is to say, by analyzing the performance data of each node in the candidate transaction model, it is determined whether there are abnormal nodes in the candidate transaction model, and then the first transaction model affected by the first business subsystem and causing the abnormality can be determined, and the transaction scope affected by the first service code can be determined.
[0120] In this method, by configuring a call code for identifying the caller in the performance log message of each business subsystem, when the business subsystem reports the performance log message to the monitoring platform, the monitoring platform can establish a transaction model for each business. In this way, when a certain transaction code (i.e., a certain type of transaction business) is abnormal, the transaction model is screened, and the business subsystem that caused the transaction code abnormality can be quickly located, thereby improving the abnormality location capability and efficiency.
[0121] Based on the above method provided in the embodiment of the present application, the embodiment of the present application also provides an abnormality locating device corresponding to the above method. The units / modules involved in the embodiments of the present application described in the embodiment of the present application can be implemented by software or by hardware. Among them, the name of the unit / module does not constitute a limitation on the unit / module itself under certain circumstances.
[0122] See also Figure 3 The structural diagram of the abnormality locating device shown is deployed on a monitoring platform, and the monitoring platform is used to monitor multiple distributed business systems, each of which includes multiple business subsystems deployed in a distributed manner, and each of which is used to perform transaction business of a corresponding transaction type. The device 300 includes:
[0123] The communication module 301 is used to receive a plurality of performance log messages sent by each business subsystem in the plurality of distributed business systems; wherein the performance log message includes: a log number for identifying a transaction, a transaction code for identifying a transaction type, a service code for identifying a business subsystem, a call code for identifying a caller, and performance data;
[0124] A first determination module 302 is used to determine multiple transaction models corresponding to multiple transactions according to the multiple performance log messages; wherein the nodes of the transaction model are multiple business subsystems that complete the transaction, and the call links between the nodes of the transaction model are determined by the call code used to identify the caller in the performance log messages of the multiple business subsystems that complete the transaction;
[0125] The second determination module 303 is configured to determine, in response to the first transaction code generating an exception, at least one business subsystem causing the first transaction code to generate an exception according to the multiple transaction models.
[0126] In some possible implementations, the second determining module 303 is specifically configured to:
[0127] In response to a first transaction code generating an abnormality, determining an abnormal transaction model involving the first transaction code from the plurality of transaction models;
[0128] Determine the candidate business subsystem corresponding to each node in the abnormal transaction model;
[0129] At least one business subsystem causing the first transaction code to be abnormal is determined based on the performance data in the performance log message of the candidate business subsystem.
[0130] In some possible implementations, the second determining module 303 is specifically configured to:
[0131] In response to an abnormality in performance data in a performance log message of a first business subsystem in the candidate business subsystem, it is determined that the first business subsystem causes the first transaction code to be abnormal.
[0132] In some possible implementations, the second determining module 303 is further configured to:
[0133] In response to the first service code generating an exception, at least one transaction causing the exception due to the first business subsystem identified by the first service code is determined according to the multiple transaction models.
[0134] In some possible implementations, the second determining module 303 is specifically configured to:
[0135] In response to the first service code generating an exception, determining a candidate transaction model involving the first service code from the plurality of transaction models;
[0136] According to the performance data in the performance log messages of the business subsystems corresponding to each node in the candidate transaction model, in response to the presence of an abnormality in the performance data in the performance log messages of the business subsystems corresponding to each node in the first transaction model in the candidate transaction model, it is determined that the transaction corresponding to the first transaction model is caused by the first business subsystem identified by the first service code.
[0137] In some possible implementations, the calling code for identifying the caller is a transaction code or a service code.
[0138] The abnormality locating device 300 according to the embodiment of the present application may correspond to executing the method described in the embodiment of the present application, and the above and other operations and / or functions of each module / unit of the abnormality locating device 300 are respectively to realize Figure 1 For the sake of brevity, the corresponding processes of each method in the illustrated embodiment are not described in detail here.
[0139] The functions described above in this document may be performed at least in part by one or more hardware logic components. Figure 4 The structural diagram of the electronic device 400 for realizing abnormality positioning shown in FIG. 1 is as follows: Figure 4The electronic device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.
[0140] like Figure 4 As shown, the electronic device 400 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 401, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 402 or a program loaded from a storage device 408 into a random access memory (RAM) 403. In the RAM 403, various programs and data required for the operation of the electronic device 400 are also stored. The processing device 401, the ROM 402, and the RAM 403 are connected to each other via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.
[0141] Typically, the following devices may be connected to the I / O interface 405: an input device 406 including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 407 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 408 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 409. The communication device 409 may allow the electronic device 400 to communicate with other devices wirelessly or by wire to exchange data. Although Figure 4 The electronic device 400 is shown with various devices, but it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed instead.
[0142] The present application also provides a computer-readable storage medium, also referred to as a machine-readable medium. In the context of the present application, a machine-readable medium may be a tangible medium that may contain or store a program for use by an instruction execution system, device or equipment or used in combination with an instruction execution system, device or equipment. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
[0143] It should be noted that the computer-readable medium mentioned above in the present application may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The computer readable signal medium may also be any computer readable medium other than a computer readable storage medium, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer readable medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.
[0144] The computer-readable medium carries one or more programs. When the one or more programs are executed by the electronic device, the electronic device: receives multiple performance log messages sent by each business subsystem in the multiple distributed business systems; wherein the performance log message includes: a log number for identifying a transaction, a transaction code for identifying a transaction type, a service code for identifying a business subsystem, a call code for identifying a caller, and performance data; determines multiple transaction models corresponding to multiple transactions based on the multiple performance log messages; wherein the nodes of the transaction model are multiple business subsystems that complete the transaction, and the call links between the nodes of the transaction model are determined by the call code for identifying the caller in the performance log messages of the multiple business subsystems that complete the transaction; in response to an exception in a first transaction code, determines at least one business subsystem that causes the first transaction code to generate an exception based on the multiple transaction models.
[0145] In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a non-transitory computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device. When the computer program is executed by a processing device, the above-mentioned functions defined in the method of the embodiment of the present application are executed.
[0146] Although the subject matter has been described in language specific to structural features and / or methodological logical actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. On the contrary, the specific features and actions described above are merely example forms of implementing the claims.
[0147] Although several specific implementation details are included in the above discussion, these should not be interpreted as limiting the scope of the present application. Certain features described in the context of a separate embodiment can also be implemented in a single embodiment in combination. On the contrary, the various features described in the context of a single embodiment can also be implemented in multiple embodiments individually or in any suitable sub-combination.
[0148] The above description is only a preferred embodiment of the present application and an explanation of the technical principles used. Those skilled in the art should understand that the scope of disclosure involved in the present application is not limited to the technical solution formed by a specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above disclosed concept. For example, the above features are replaced with the technical features with similar functions disclosed in this application (but not limited to) by each other to form a technical solution.
Claims
1. A method for locating an abnormality, characterized in that: Applied to a monitoring platform, the monitoring platform is used to monitor multiple distributed business systems, each of the distributed business systems includes multiple business subsystems deployed in a distributed manner, and each of the distributed business systems is used to perform transaction business of a corresponding transaction type, the method includes: Receiving a plurality of performance log messages sent by each business subsystem in the plurality of distributed business systems; wherein the performance log message includes: a log number for identifying a transaction, a transaction code for identifying a transaction type, a service code for identifying a business subsystem, a call code for identifying a caller, and performance data; Determine multiple transaction models corresponding to the multiple transactions according to the multiple performance log messages; wherein the nodes of the transaction model are multiple business subsystems that complete the transaction, and the call links between the nodes of the transaction model are determined by the call codes used to identify the callers in the performance log messages of the multiple business subsystems that complete the transaction; In response to the first transaction code generating an exception, at least one business subsystem causing the first transaction code to generate an exception is determined according to the multiple transaction models.
2. The method according to claim 1, characterized in that In response to the first transaction code generating an exception, determining at least one business subsystem causing the first transaction code to generate an exception according to the multiple transaction models includes: In response to a first transaction code generating an abnormality, determining an abnormal transaction model involving the first transaction code from the plurality of transaction models; Determine the candidate business subsystem corresponding to each node in the abnormal transaction model; At least one business subsystem causing the first transaction code to be abnormal is determined based on the performance data in the performance log message of the candidate business subsystem.
3. The method according to claim 2, characterized in that The determining, based on the performance data in the performance log message of the candidate business subsystem, at least one business subsystem causing the first transaction code to be abnormal includes: In response to an abnormality in performance data in a performance log message of a first business subsystem in the candidate business subsystem, it is determined that the first business subsystem causes the first transaction code to be abnormal.
4. The method according to claim 1, characterized in that The method further comprises: In response to the first service code generating an exception, at least one transaction causing the exception due to the first business subsystem identified by the first service code is determined according to the multiple transaction models.
5. The method according to claim 4, characterized in that In response to the first service code generating an exception, determining, according to the multiple transaction models, at least one transaction caused by the first business subsystem identified by the first service code causing the exception, comprises: In response to the first service code generating an exception, determining a candidate transaction model involving the first service code from the plurality of transaction models; According to the performance data in the performance log messages of the business subsystems corresponding to each node in the candidate transaction model, in response to the presence of an abnormality in the performance data in the performance log messages of the business subsystems corresponding to each node in the first transaction model in the candidate transaction model, it is determined that the transaction corresponding to the first transaction model is caused by the first business subsystem identified by the first service code.
6. The method according to any one of claims 1 to 5, characterized in that: The calling code used to identify the caller is a transaction code or a service code.
7. An abnormality locating device, characterized in that: Deployed on a monitoring platform, the monitoring platform is used to monitor multiple distributed business systems, each of the distributed business systems includes multiple business subsystems deployed in a distributed manner, and each of the distributed business systems is used to perform transaction business of a corresponding transaction type. The device includes: A communication module, used to receive a plurality of performance log messages sent by each business subsystem in the plurality of distributed business systems; wherein the performance log message includes: a log number for identifying a transaction, a transaction code for identifying a transaction type, a service code for identifying a business subsystem, a call code for identifying a caller, and performance data; A first determination module is used to determine multiple transaction models corresponding to multiple transactions according to the multiple performance log messages; wherein the nodes of the transaction model are multiple business subsystems that complete the transaction, and the call links between the nodes of the transaction model are determined by the call code used to identify the caller in the performance log messages of the multiple business subsystems that complete the transaction; The second determination module is used to determine, in response to the first transaction code generating an exception, at least one business subsystem causing the first transaction code to generate an exception according to the multiple transaction models.
8. An electronic device, characterized in that: The electronic device comprises a processor and a memory, wherein instructions are stored in the memory, and the processor executes the instructions so that the electronic device executes the method according to any one of claims 1 to 6.
9. A computer-readable storage medium, characterized in that: The method comprises computer-readable instructions, and when the computer-readable instructions are executed on an electronic device, the electronic device executes the method according to any one of claims 1 to 6.
10. A computer program product, characterized in that The computer program product comprises computer-readable instructions, and when the computer program product is run on an electronic device, the electronic device executes the method according to any one of claims 1 to 6.