WO2018045756A1

WO2018045756A1 - Fault localization platform, fault localization method and device

Info

Publication number: WO2018045756A1
Application number: PCT/CN2017/081072
Authority: WO
Inventors: 陈克云
Original assignee: 华为技术有限公司
Priority date: 2016-09-06
Filing date: 2017-04-19
Publication date: 2018-03-15
Also published as: CN106254144A; CN106254144B

Abstract

Disclosed in the present invention are a fault localization platform, a fault localization method and a device, related to the technical field of communications. The method comprises: when executing a service step corresponding to a service request ID, sending a corresponding processing log from a first service system to a log system, the log system determining an abnormal service step according to an execution result of the received processing log, and thereby localizing a faulty service system; the first service system generates a processing log for each service step, making it possible for the log system to determine a specific faulty service system by means of an execution result of a processing log, solving the problem in the prior art of needing to check each service system from top to bottom in sequence so as to determine a faulty service system; when there are relatively many service systems, leading to a problem of lower faulty service system localization efficiency, faulty service system localization can by achieved by means of processing logs corresponding to a service request ID, improving faulty service system localization efficiency.

Description

Fault location platform, fault location method and device

Technical field

The present invention relates to the field of communications technologies, and in particular, to a fault location platform, a fault location method, and a device.

Background technique

In a cloud service environment, in order to provide multiple services, a platform usually has multiple systems in the platform, and multiple services are completed through interaction between multiple systems. Among them, a variety of services may include: file services, object services, and host backup services.

In the prior art, when a certain service is executed by a platform, there are interaction calls between multiple systems in the platform. When the service fails to execute, the system needs to be in the highest order from the top to the bottom. At the beginning, each system that has interactive calls is executed in turn to check the system, and finally the faulty system is located. Referring to FIG. 1 , the cloud platform 100 includes: a cloud management system 210 , a data protection service system 220 , a virtualization system 230 , a production storage system 240 , a cloud backup management system 250 , and a backup storage system 260 . The cloud platform 100 performs a host backup service process as follows: the cloud management system 210 sends a backup request to the data protection service system 220; after receiving the backup request, the data protection service system 220 sends a scheduling backup request to the virtualization system 230; the virtualization system 230, according to the received scheduled backup request, send a backup request to the cloud backup management system 250, and query the backup status every preset time; the cloud backup management system 250 sequentially performs a volume snapshot 251, a volume snapshot comparison 252 according to the execution backup request, Extract data 253, store data 254, and backup complete 255. The volume snapshot comparison refers to comparing the current time data with the previous time data; the cloud backup management system 250 stores the result of the volume snapshot comparison and the extracted difference data into the production storage system 240; The time data is stored in the backup storage system 260.

In the process of implementing the embodiments of the present invention, the inventors have found that the prior art has at least the following problems:

When the host backup fails, it is necessary to start from the uppermost cloud management system 210, and sequentially check whether the data protection service system 220, the virtualization system 230, the production storage system 240, the cloud backup management system 250, and the backup storage system 260 are faulty. Eventually locating a failed system results in less efficient positioning of the failed system.

Summary of the invention

In order to solve the problems in the prior art, the embodiments of the present invention provide a fault location platform, a fault location method, and a device. The technical solution is as follows:

In a first aspect, a fault location platform is provided, where the platform includes: an identity distribution system, a log system, a first service system, and a second service system;

The identifier distribution system is configured to allocate a service request identifier (ID) to the service request, where the service request is sent when the first service system executes a service; a service that is executed by the service system and the second service system; the first service system is configured to generate a process log of each service step corresponding to the service request ID, where the process log is used to record the service The execution result of the step; the respective service steps include: a service step performed by the first service system, and a service step performed by the first service system by the first service system; the log system is used for Receiving the processing log corresponding to the service request ID; determining an abnormal service step according to the execution result in the processing log, and positioning the service system for performing the abnormal service step as a faulty service system.

In the solution shown in the embodiment of the present invention, when the first service system and the first service system call the second service system to perform the service step corresponding to the service request ID, the first service system sends a corresponding processing log to the log system, and the log is generated. The system determines the abnormal service step according to the execution result in the received processing log, and finally locates the faulty service system. The first service system generates a processing log for each service step, so that the log system can perform the execution result according to the processing log. The specific faulty service system is determined, and the prior art needs to check each service system in order from the top and bottom, and finally determine the faulty service system. When the number of service systems is large, the positioning efficiency of the faulty service system is caused. The lower problem is that the faulty service system is located through the processing log corresponding to the service request ID, and the effect on the positioning efficiency of the faulty service system is improved.

In a first possible implementation manner of the first aspect, the first service system is configured to generate a first process corresponding to the internal service step when performing an internal service step corresponding to the service request ID a log, the first processing log is sent to the log system, where the first processing log is used to record an execution result of the step of executing the internal service by the first service system; the first service system is further used to: And generating, by the second service system, an external service step corresponding to the service request ID, generating a second processing log corresponding to the external service step, and sending the second processing log to the log system, where The second processing log is configured to record an execution result of the executed second service system to execute the external service step; the log system is configured to determine, according to the execution result in the first processing log, Whether the internal service step is the abnormal service step, and when the internal service step is the abnormal service step, the first service system is located as the fault a service system, determining, according to the execution result in the second processing log, whether the external service step is the abnormal service step, where the external service step is the abnormal service step, the called The second service system is located as the faulty service system.

In the solution shown in the embodiment of the present invention, the first service system records the execution result of the execution of the internal service step as the first processing log; the execution result of the execution of the external service step is recorded as the second processing log; and the log system according to the first processing log The execution result may determine whether the first service system is a faulty service system; according to the execution result of the second process log, it may be determined whether the second service system is a faulty service system; and the internal service step and the external service step are separately recorded, It is beneficial to improve the positioning efficiency of faulty business systems.

With reference to the first possible implementation of the first aspect, in a second possible implementation, the first service system includes: a first processing module having a first application programming interface (API), The first API has a corresponding first API identifier; the second service system includes: a second processing module having a second API, the second API has a corresponding second API identifier; and the first service system And sending the first processing log to the log system; the first processing log includes: the service request ID, a first service system ID, the first API identifier, and a result code, and the result code The first processing module performs the execution result of the internal service step; the first service system is further configured to send the second processing log to the log system; the second processing log includes: Describe the service request ID, the first service system ID, the first API identifier, the second service system ID, the second API identifier, and a return code, where the return code refers to calling the second processing module The execution result of the external service step is performed; the log system is configured to: when the faulty service system is the first service system, locate an API corresponding to the first API identifier as a fault API; When the faulty service system is the called second service system, the API corresponding to the second API identifier is located as the fault API.

In the solution shown in the embodiment of the present invention, when the faulty service system is the first service system, the log system determines, according to the first API identifier carried in the first processing log, that the API corresponding to the first API identifier is a fault API; When the service system is the second service system, the log system determines, according to the second API identifier carried in the second processing log, that the API corresponding to the second API is a fault API; and the first processing identifier carries the first API identifier and The second processing log carries the second API identifier, so that the log system can locate the fault API according to the API identifier, thereby improving the accuracy of the positioning of the faulty service system.

With reference to the second possible implementation of the first aspect, in a third possible implementation, the log system is configured to obtain a business process model corresponding to the service request ID, where the business process model includes: An execution sequence of each service step corresponding to the service request ID; and sequentially acquiring n first processing logs and m second processing logs corresponding to the respective service steps according to the execution order, where the n and the m are respectively Is a positive integer.

In the solution shown in the embodiment of the present invention, the log system obtains the first processing log and the second processing log corresponding to each service step according to the execution order in the business process model, which is beneficial to sequentially determining abnormal business steps according to the sequence of executing the business steps. It is beneficial to avoid waste of resources and improve the efficiency of positioning the faulty business system.

With reference to the third possible implementation manner of the first aspect, in a fourth possible implementation, the log system is further configured to: determine the internal service step according to an execution result in the i th first processing log Whether it is the abnormal service step, the i is a positive integer less than or equal to n; if the abnormal service step, the API corresponding to the first API identifier included in the i-th first processing log is located as If the abnormal service step is not performed, let i=i+1, and determine, according to the execution result in the i-th first processing log, whether the internal service step is the abnormal service step.

According to the solution shown in the embodiment of the present invention, the log system determines whether the internal service step is an abnormal service step according to the execution result in the first processing log according to the execution order in the business process model, which is beneficial to sequentially determining according to the sequence of executing the business steps. Abnormal business steps are beneficial to avoid waste of resources and improve the efficiency of positioning the faulty business system.

In conjunction with the third possible implementation of the first aspect, in a fifth possible implementation, the log system is further configured to: determine the external service step according to an execution result in the jth second processing log Whether it is the abnormal service step, the j is a positive integer less than or equal to m; if the abnormal service step, the API corresponding to the second API identifier included in the jth second processing log is located as If the abnormal service step is not performed, let j=j+1, and determine, according to the execution result in the jth second processing log, whether the external service step is the abnormal service step.

According to the solution shown in the embodiment of the present invention, the log system determines whether the external service step is an abnormal service step according to the execution result in the second processing log according to the execution order in the business process model, which is beneficial to sequentially determining according to the sequence of executing the business steps. Abnormal business steps are beneficial to avoid waste of resources and improve the efficiency of positioning the faulty business system.

A second aspect provides a fault locating method, the method comprising: receiving a processing log corresponding to a service request identifier ID; the service request is sent when the first service system executes a service, and the service is performed by a presence call relationship And the processing log is used to record the execution result of each service step corresponding to the service request ID, where the respective service steps include: the first service a service step performed by the system, and the first service system invokes a service step performed by the second service system; determining an abnormal service step according to the execution result in the processing log; and is configured to execute the abnormal service The business system of the step is located as a faulty business system.

In the solution shown in the embodiment of the present invention, the log system determines the abnormal service step according to the received execution result in the processing log corresponding to the service request ID, and finally locates the faulty service system; The processing step generates a processing log, so that the log system can determine a specific faulty service system according to the execution result in the processing log, and solves the problem in the prior art that the service systems are sequentially checked from the top to the bottom, and the faulty service is finally determined. When the number of service systems is large, the system has a low efficiency in locating the faulty service system, and the faulty service system is located through the processing log corresponding to the service request ID, thereby improving the positioning efficiency of the faulty service system. effect.

In a first possible implementation manner of the second aspect, the processing log includes: a first processing log and a second processing log; and determining, according to the execution result in the processing log, an abnormal service step, including: Determining, according to the execution result in the first processing log, whether the internal service step is the abnormal service step; the first processing log is used to record that the first service system executes the internal corresponding to the service request ID An execution result of the business step; determining, according to the execution result in the second processing log, whether the external service step is the abnormal service step; the second processing log is used to record the execution of the second service system and the The execution result of the external service step corresponding to the service request ID.

With reference to the first possible implementation of the second aspect, in a second possible implementation manner of the second aspect, the determining, by using the service system for performing the abnormal service step, the faulty service system includes: When the internal service step is the abnormal service step, the first service system is located as the faulty service system; when the external service step is the abnormal service step, the second to be called The business system is located as the faulty business system.

In the solution shown in the embodiment of the present invention, the service system records the execution result of the execution of the internal service step as the first processing log; the execution result of the execution of the external service step is recorded as the second processing log; and the execution of the log processing system according to the first processing log As a result, it can be determined whether the first service system is a faulty service system; according to the execution result of the second process log, it can be determined whether the second service system is a faulty service system; and the internal service step and the external service step are recorded separately, which is beneficial to improve Positioning efficiency for faulty business systems.

With reference to the second possible implementation of the second aspect, in a third possible implementation of the second aspect, the first service system includes: a first processing module having a first application programming interface API, The first API has a corresponding first API identifier; the second service system includes: a second processing module having a second API, the second API has a corresponding second API identifier; the method further includes: When the faulty service system is the first service system, the API corresponding to the first API identifier is located as a fault API according to the first API identifier included in the first processing log; The processing log includes: the service request ID, the first service system ID, the first API identifier, and the result code, where the result code refers to an execution result of the first processing module performing the internal service step; When the faulty service system is the called second service system, the API corresponding to the second API identifier is located as the fault API according to the second API identifier included in the second processing log; The second place The management log includes: the service request ID, the first service system ID, the first API identifier, the second service system ID, the second API identifier, and a return code, where the return code refers to The second processing module executes the execution result of the external service step.

In the solution shown in the embodiment of the present invention, when the faulty service system is the first service system, the log system determines, according to the first API identifier carried in the first processing log, that the API corresponding to the first API identifier is a fault API; When the system is the second service system, the log system determines, according to the second API identifier carried in the second processing log, that the API corresponding to the second API is a fault API; and the first API identifier carries the first API identifier and the first The second processing log carries the second API identifier, so that the log system can locate the fault API according to the API identifier, thereby improving the accuracy of positioning the faulty service system.

With reference to the third possible implementation of the second aspect, in a fourth possible implementation, the method may further include: acquiring a business process model corresponding to the service request ID, where the business process model includes: An execution sequence of each service step corresponding to the service request ID; and sequentially acquiring n first processing logs and m second processing logs corresponding to the respective service steps according to the execution order, where the n and the m are respectively Is a positive integer.

With reference to the fourth possible implementation manner of the foregoing aspect, in a fifth possible implementation, the determining, according to the execution result in the first processing log, whether the internal service step is the abnormal service step includes: Determining, according to the execution result in the ith first processing log, whether the internal service step is the abnormal service step, where i is a positive integer less than or equal to n; and the API corresponding to the first API identifier is located The failure API includes: if the abnormal service step, the API corresponding to the first API identifier included in the i-th first processing log is located as the fault API; if not the abnormal service step, Let i=i+1, and perform the step of determining whether the abnormal service step is based on the execution result in the i-th first processing log.

With reference to the fourth possible implementation of the second aspect, in a sixth possible implementation, the determining, according to the execution result in the second processing log, whether the external service step is the abnormal service step includes: Determining, according to the execution result in the jth second processing log, whether the external service step is the abnormal service step, where j is a positive integer less than or equal to m; and the API corresponding to the second API identifier is located And the faulty API includes: if the abnormal service step, the API corresponding to the second API identifier included in the jth second processing log is located as the fault API; if not the abnormal service step Then, let j=j+1, perform the step of determining whether the external service step is the abnormal service step according to the execution result in the jth second processing log.

In a third aspect, a fault locating device is provided, the fault locating device comprising at least one unit for implementing a fault locating method that may be provided by any of the second aspect or the second aspect described above.

The technical effects obtained by the foregoing third embodiment of the present invention are similar to those obtained by the corresponding technical means in the second aspect, and are not described herein again.

According to a fourth aspect, there is provided a computer readable storage medium having stored therein an executable program for implementing the fault location method provided by any of the possible aspects of the second aspect or the second aspect described above.

In a fifth aspect, a logging system is provided, the logging system comprising a processor and a memory; the processor for storing one or more instructions, the instructions being indicated to be executed by the processor, the processor for A fault location method provided in any of the possible designs of the second aspect or the second aspect described above is implemented.

In summary, the beneficial effects provided by the technical solutions provided by the embodiments of the present invention include:

When the service system performs the service step corresponding to the service request ID, the corresponding processing log is sent to the log system, and the log system determines the abnormal service step according to the execution result in the received processing log, and finally locates the faulty service system; In the prior art, it is necessary to check each service system in order from the top and bottom, and finally determine the faulty service system. When the number of service systems is large, the problem of low positioning efficiency of the faulty service system is achieved, and the fault is improved. The effect of the positioning efficiency of the business system.

DRAWINGS

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings to be used in the description of the embodiments will be briefly described below.

1 is a flowchart of a method for a host backup service provided in the prior art;

2 is a schematic structural diagram of a fault location platform according to an embodiment of the present invention;

3 is a schematic structural diagram of a fault location platform according to another embodiment of the present invention;

4 is a schematic structural diagram of fault location of a host backup service according to an embodiment of the present invention;

FIG. 5 is a schematic structural diagram of a log system according to an embodiment of the present invention; FIG.

FIG. 6 is a flowchart of a method for fault location method according to an embodiment of the present invention; FIG.

FIG. 7 is a flowchart of a method for fault location according to another embodiment of the present invention; FIG.

FIG. 8 is a flowchart of a method for fault location method according to still another embodiment of the present invention; FIG.

9 is a schematic structural diagram of a fault location system according to an embodiment of the present invention;

FIG. 10 is a flowchart of a method for fault location method according to an embodiment of the present invention; FIG.

FIG. 11 is a structural block diagram of a fault locating device according to an embodiment of the present invention.

detailed description

The technical solutions in the embodiments of the present invention will be clearly and completely described in the following with reference to the accompanying drawings.

Please refer to FIG. 2 , which is a schematic structural diagram of a fault location platform according to an embodiment of the present invention. As shown in FIG. 2, the platform may include an identity distribution system 120, a log system 140, a first service system 161, and a second service system 162.

The identity assignment system 120 has the ability to assign a service request ID to a service request. The service request is sent by the first service system 161 when the service is executed, and the service is performed by the first service system 161 and the second service system 162 in which the call relationship exists.

Optionally, in the embodiment of the present invention, only the service system that performs the service, including the first service system 161 and the second service system 162, is taken as an example, but the service system for performing the service is not specifically limited, for example, the service is performed. The service system further includes: a third service system (not shown); wherein the service is the first service system 161 and the second service system 162 in which the call relationship exists, and the first service system 161 and the first presence call relationship The business of three business systems collaboratively executed.

Optionally, the identity distribution system 120 also has the ability to assign a service ID to the service. One service ID corresponds to one service request ID, or one service ID corresponds to several service request IDs.

Optionally, when the service is triggered at different time points when the same service is executed, the identifier distribution system 120 generates different service request IDs for the service requests triggered at different time points. That is to say, each business step in the execution of the business generates a service request, and the identity distribution system 120 also assigns a service request ID.

Optionally, the identifier distribution system 120 records a service ID, a service request ID, and a correspondence between the service ID and the service request ID.

Optionally, the identity distribution system 120 synchronizes the recorded service ID, the service request ID, and the correspondence between the service ID and the service request ID to the log system 140.

The first service system 161 and the second service system 162 have the ability to perform services while the first service system 161 also has the ability to invoke the second service system to perform business steps. Each service step corresponding to the service request ID includes: a service step performed by the first service system 161 and a service step performed by the first service system 162 by the first service system 162; when performing each service step corresponding to the service request ID, A service system 161 generates a processing log of each service step corresponding to the service request ID. Optionally, the service request ID corresponds to a service step, or the service request ID corresponds to a plurality of service steps; the service step corresponds to the service step The presence of at least one service step is a step performed by the first service system 161 to invoke the second service system 162; each service step corresponds to a processing log.

Optionally, the processing log is used to record the execution result of the business step; optionally, the execution result includes: the execution succeeds or the execution fails.

Optionally, the first service system 161 sends the generated processing log corresponding to the service request ID to the log system 140. The first service system 161 sends the processing log corresponding to the service request ID to the log system 140 by means of asynchronous transmission, or the first service system 161 reports the generated processing log corresponding to the service request ID to the log system 140. .

Logging system 140 has the ability to analyze processing logs. The log system 140 receives the processing log corresponding to the service request ID sent by the first service system 161, determines an abnormal service step according to the execution result in the processing log, and locates the service system 140 that executes the abnormal service step as the faulty service system.

Optionally, the abnormal service step includes an execution failure. When the log system 140 detects that the execution result in the processing log is an execution failure, the log system 140 determines that the service system 140 that performs the service step is a faulty service system.

In summary, the fault location platform provided in this embodiment sends a corresponding service system to the log system when the first service system and the first service system call the second service system to perform the service step corresponding to the service request ID. The processing log, the log system determines the abnormal service step according to the execution result in the received processing log, and finally locates the faulty service system; since the first service system generates a processing log for each service step, the log system processes the log according to the processing log. The execution result in the system can determine a specific faulty service system, and solves the problem in the prior art that the faulty service system is determined by sequentially checking each service system from above and below, and when the number of service systems is large, the fault is caused. The problem of low positioning efficiency of the service system achieves the effect of locating the faulty service system through the processing log corresponding to the service request ID, thereby improving the positioning efficiency of the faulty service system.

In the fault location platform shown in FIG. 2, the processing log reported by the first service system 161 includes: a first processing log and a second processing log, as shown in FIG. 3 .

The first service system 161 can independently execute the internal service step corresponding to the service request ID by itself, and generate the first process log corresponding to the internal service step when the internal service step is executed. The first processing log records the execution results of the first business system 161 performing the internal business steps.

Optionally, the first service system 161 includes a first processing module having a first API, where the first API has a corresponding first API identifier, and the first service system 161 performs an internal service corresponding to the service request ID by using the first processing module. The first processing log includes: a service request ID, a first service system ID, a first API identifier, and a result code, where the result code is an execution result of the first processing module executing the internal service step.

Optionally, when the service step fails to be executed, the first processing log carries an incorrect result code, or, The processing log does not carry the result code, or the first processing log does not carry the result code, and carries the network connection abnormality or no response.

Optionally, the first service system 161 sends the generated first processing log to the log system 140.

The second service system 162 is a service system that is invoked when the first service system 161 executes an external service step corresponding to the service request ID.

Optionally, the first service system 161 generates a second processing log corresponding to the external service step when the second service system 162 is invoked to execute the external service step corresponding to the service request ID. The second processing log records the execution result of the second business system 162 executing the external business step.

Optionally, the second service system 162 includes a second processing module having a second API, where the second API has a corresponding second API identifier, and the first service system 161 invokes the second processing module to execute the service request by using the first processing module. The external processing step corresponding to the ID; the second processing log includes: a service request ID, a first service system ID, a first API identifier, a second service system ID, and a second API identifier and a return code, where the return code is a second processing module Execute the execution result of the external business step.

Optionally, the first service system 161 sends the generated second processing log to the log system 140.

It should be noted that, in this embodiment, only the service request sent by the first service system 161 when the service is executed is taken as an example, but is not specifically limited. For example, when the second service system 162 performs the service, For example, in the process of executing the service, the second service system 162 can also independently execute the internal service step corresponding to the service request ID, and generate a corresponding first processing log, and send it to the log system 140, or the second service. The system calls the other service system to execute the external service step corresponding to the service request ID, and generates a corresponding second processing log, which is sent to the log system 140.

The log system 140 determines whether the internal service step is an abnormal service step according to the execution result in the first processing log. When the internal service step is an abnormal service step, the first service system 161 is positioned as a faulty service system; the log system 140 is further configured according to the The execution result in the second processing log determines whether the external service step is an abnormal service step. When the external service step is an abnormal service step, the called second service system 162 is positioned as the faulty service system.

Optionally, after the first service system 161 is configured as the faulty service system, the log system 140 determines, according to the first API identifier carried in the first processing log, that the API corresponding to the first API identifier is a fault API; the log system is still After the second service system 162 is located as the faulty service system, the API corresponding to the second API identifier is determined to be a fault API according to the second API identifier carried in the second processing log.

Optionally, the log system 140 also obtains a business process model corresponding to the service request ID. The business process model includes: an execution sequence of each business step corresponding to the service request ID.

The log system 140 sequentially acquires n first processing logs and m second processing logs corresponding to the respective service steps according to the execution order in the business process model, where n and m are positive integers, respectively.

Optionally, the log system 140 determines, according to the execution result in the i th first processing log, whether the internal service step is an abnormal service step, where i is a positive integer less than or equal to n; when the internal service step is an abnormal service step, the log system 140 The API corresponding to the first API identifier carried in the ith first processing log is determined as a fault API; if the internal service step is not an abnormal service step, the log system 140 causes i=i+1 to continue according to the ith first The execution result in the processing log determines whether the internal business step is an abnormal business step until an abnormal business step is determined.

Optionally, the log system 140 determines, according to the execution result in the jth second processing log, whether the external service step is an abnormal service step, where j is a positive integer equal to or equal to m; when the external service step is an abnormal service step, the log system 140 Determining, by the API corresponding to the second API identifier carried in the jth second processing log, a fault API; If the external service step is not an abnormal service step, the log system 140 makes j=j+1, and continues to determine whether the external service step is abnormal according to the execution result in the jth second processing log until an abnormal service step is determined.

Optionally, the log system 140 includes: an analysis component 141, a modeling component 142, an ID processing component 143, and a log component 144;

An ID processing component 143, configured to store a service request ID;

a log component 144, configured to store a processing log corresponding to the service request ID;

a modeling component 142, configured to store a business process model corresponding to the service request ID;

The analysis component 141 is configured to determine an abnormal service step according to the execution result in the business process model and the processing log, and locate the business system for performing the abnormal business step as the faulty service system.

In an exemplary example, as shown in FIG. 4, taking the host backup service shown in FIG. 1 as an example, the service system for executing the service includes: the cloud management system 11, the data protection service system 12, the virtualization system 13, and the cloud. The backup management system 14, the production storage system 15 and the backup storage system 16; when the host backup service is completed, the cloud management system 11 invokes the data protection service system 12 to perform a backup request, and the identification distribution system allocates a service request ID for the backup request, and requests the service The ID is fed back to the cloud management system 11, and is also synchronized to the ID processing component 143 in the log system 140. When the data protection service system 12 is invoked to execute the backup request, the cloud management system 11 generates a corresponding second processing log, and generates the generated The second processing log is sent to the log component 144 in the log system 140; when the data protection service system 12 invokes the virtualization system 13 to execute the scheduled backup request; the data protection service system 12 generates a corresponding second processing log, and generates the second The processing log is sent to the log component 144 in the log system 140; the virtualization system 13 calls the cloud backup management system 14 in turn. When the volume snapshot, volume snapshot comparison, data extraction, data storage, and backup are completed, the virtualization system 13 generates a corresponding second processing log, and sends the generated second processing log to the log component in the log system 140. 144; the cloud backup management system 14 generates a corresponding first processing log according to each step in the five steps of independently performing volume snapshot, volume snapshot comparison, extracting data, storing data, and backing up, and generating the first five processings. The log is sent to the log component 144 in the log system 140; when the cloud backup management system 14 calls the production storage system 15 to store the result of the volume snapshot comparison and the difference data obtained after the extraction, the cloud backup management system 14 generates a corresponding second processing log. And generating the second processing log to the log component 144 in the log system 140; when the cloud backup management system 14 calls the backup storage system 16 to store the current time data, the cloud backup management system 14 generates a corresponding second processing log. And generating the generated second processing log to the log component 144 in the log system 140; in the log system 140 The business process model corresponding to the host backup request ID is pre-stored in the modeling component 142; when the host backup service fails, the analysis component 141 in the log system 140 executes according to the business process model and the processing log stored in the log component 144. As a result, an abnormal business step is determined, and the business system for performing the abnormal business step is positioned as a faulty business system. For example, if the service step is determined to be an abnormal service step according to the execution result in the second processing log reported by the virtualization system 13, the analysis component 141 determines that the cloud backup management system 14 is a faulty service system.

Please refer to FIG. 5 , which is a schematic structural diagram of a log system 140 according to an embodiment of the present invention. The log system 140 may include a processor 511 , a communication bus 512 , a memory 513 , and a communication interface 514 .

The processor 511 may include one or more central processing units (English: Central Processing Unit, abbreviated: CPU). The processor 511 executes various functional applications and business data processing by running software programs and modules.

Communication interface 514 may include a wireless network interface, such as an Ethernet interface, or a wired network interface. The communication interface 514 is configured to receive a processing log sent by the service system and a service request ID sent by the identity distribution system.

Memory 513 and communication interface 514 are coupled to processor 511 via communication bus 512, respectively.

The memory 513 can be used to store software programs and modules that are executed by the processor 511. In addition, various types of service data and user data can also be stored in the memory 513.

In an embodiment of the invention, the memory 513 can store the operating system 51 and program instructions 52 required for at least one function. The program instructions 52 may include a receiving module 521, a determining module 522 and a positioning module 523, an obtaining module 524, and the like.

The receiving module 521 is configured to receive a processing log corresponding to the service request identifier ID.

The determining module 522 is configured to determine an abnormal service step according to the execution result in the processing log.

The positioning module 523 is configured to locate a service system for performing an abnormal service step as a faulty service system.

The obtaining module 524 is configured to obtain a business process model corresponding to the service request ID.

The memory 513 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), dynamic random access memory (DRAM). ), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (programmable read) -only memory, PROM), read-only memory (ROM), magnetic memory, flash memory, disk or optical disk.

It will be understood by those skilled in the art that the structure of the log system 140 shown in FIG. 5 does not constitute a limitation to the log system 140. The log system 140 in the present invention may include more or fewer components or Combine some components, or different component arrangements.

Please refer to FIG. 6, which is a flowchart of a method for providing a fault location method according to an embodiment of the present invention. This embodiment is exemplified by applying the fault location method to the log system 140 shown in FIG. 2. The fault location method includes the following steps:

Step 601: The log system receives a processing log corresponding to the service request ID.

The service request is sent when the first service system executes the service, and the service is performed by the first service system and the second service system in which the call relationship exists, and the processing log is used to record the execution of each service step corresponding to the service request ID. As a result, each service step includes: a service step performed by the first service system, and a service step performed by the first service system to invoke the second service system.

Optionally, in the embodiment of the present invention, only the service system that performs the service, including the first service system and the second service system, is taken as an example, but the service system for executing the service is not specifically limited, for example, the service system for executing the service. The method further includes: a third service system; wherein the service is a service executed by the first service system and the second service system in which the call relationship exists, and the first service system 161 and the third service system in which the call relationship exists. Correspondingly, the service steps corresponding to the service request ID are only exemplified by the service steps performed by the first service system and the service steps performed by the first service system. Specifically, for example, each service step may further include: the first service system invokes a service step performed by the third service system.

The first service system generates a processing log of each service step corresponding to the service request ID. The first service system executes the service step corresponding to the service request ID, and the first service system invokes the second service system execution and service request When the service step corresponding to the ID is performed, the first service system generates a processing log corresponding to each service step. Optionally, each service step corresponds to one processing log.

For example, the service system A needs to complete the service step 1, the service step 2, and the service step 3 when performing the service step corresponding to the service request B, and the service step 1 needs to invoke the service system C to execute; when the service step 1 is executed, the service system A generates the processing log 1 corresponding to the service step 1; when the service step 2 is executed, the service system A generates the processing log 2 corresponding to the service step 2; when the service step 3 is executed, the service system A generates the corresponding corresponding to the service step 3. Process log 3.

The first service system sends the generated processing log to the log system. Optionally, the first service system sends the processing log to the log system by means of asynchronous sending. Alternatively, the first service system sends the generated processing log to the log system. The log system; for example, the first service system sends the processing log 1 to the log system when the processing log 1 is generated; the processing log 2 is sent to the log system when the processing log 2 is generated; and the processing log 3 is sent when the processing log 3 is generated. To the log system; or, after the first service system generates the processing log 1, the processing log 2, and the processing log 3, the processing log 1, the processing log 2, and the processing log 3 are sent to the log system together.

Correspondingly, the log system receives a processing log corresponding to the service request ID sent by the first service system.

This step can be implemented by the processor 511 in the log system 140 shown in FIG. 5 executing the receiving module 521.

Step 602: The log system determines an abnormal service step according to the execution result in the processing log.

After receiving the processing log, the log system determines the abnormal service step according to the execution result in the processing log.

Optionally, the execution result in the processing log includes: the execution succeeds or the execution fails; the abnormal business step is the business step corresponding to the execution failure being the execution failure. When the execution result in the processing log is an execution failure, the log system determines that the service step corresponding to the processing log is an abnormal service step.

For example, if the execution result in the processing log 2 in the processing log 1, the processing log 2, and the processing log 3 is an execution failure, the log system determines that the service step 2 is an abnormal service step according to the execution result in the processing log 2.

This step can be implemented by the processor 511 in the log system 140 shown in FIG. 5 executing the determination module 522.

Step 603: Position the service system for performing the abnormal service step as a faulty service system.

After the log system determines the abnormal service step, the service system for performing the abnormal service step is located as the faulty service system. For example, if the log system determines that the service step 2 is an abnormal service step, the log system determines the service system A that performs the service step 2 as the faulty service system.

This step can be implemented by the processor 511 in the log system 140 shown in FIG. 5 executing the positioning module 523.

In summary, the fault location method provided in this embodiment, when the first service system and the first service system invoke the second service system to perform the service step corresponding to the service request ID, the first service system sends a corresponding response to the log system. The processing log, the log system determines the abnormal service step according to the execution result in the received processing log, and finally locates the faulty service system; since the first service system generates a processing log for each service step, the log system processes the log according to the processing log. The execution result in the system can determine a specific faulty service system, and solves the problem in the prior art that the faulty service system is determined by sequentially checking each service system from above and below, and when the number of service systems is large, the fault is caused. The problem of low positioning efficiency of the service system achieves the effect of locating the faulty service system through the processing log corresponding to the service request ID, thereby improving the positioning efficiency of the faulty service system.

In the embodiment shown in FIG. 6 , optionally, the first service system may independently perform an internal service step corresponding to the service request ID; the processing log is a first processing log, and the first processing log is used to record the first service system. Execute the execution result of the internal business step corresponding to the service request ID. As a possible implementation, step 602 Step 603 can be replaced by the following steps 701 to 705, as shown in FIG. 7:

Step 701: The log system acquires a business process model corresponding to the service request ID, where the business process model includes: an execution sequence of each service step corresponding to the service request ID.

When the service request fails to execute, the log system acquires a business process model corresponding to the service request ID.

When the first service system independently executes the internal service step corresponding to the service request ID, the internal service step corresponding to the entire service request ID needs to be executed according to a predetermined execution order. For example, when the service system A executes the service request 71, a total of 4 needs to be executed. The service steps are respectively the service step 1, the service step 2, the service step 3, and the service step 4. The service step 1 and the service step 2 are performed through the B module; and the service step 3 and the service step 4 are performed through the C module. Exemplarily, the business process model corresponding to the business system A executing the business request 71 is as shown in the following Table 1:

业务请求IDBusiness request ID	业务系统business system	业务系统的模块Business system module	执行顺序Execution order
业务请求71Business request 71	业务系统ABusiness System A	B模块B module	11
业务请求71Business request 71	业务系统ABusiness System A	C模块C module	22

Table I

This step can be implemented by the processor 511 in the log system 140 shown in FIG. 5 executing the acquisition module 524.

Step 702: The log system sequentially acquires n first processing logs corresponding to the respective service steps according to the execution order, where n is a positive integer.

After obtaining the business process model, the log system obtains n first processing logs corresponding to the respective service steps from the received processing logs according to the execution order in the business process model.

Optionally, the first processing log is an execution result corresponding to the first service system independently executing an internal service step corresponding to the service request ID.

Step 703: The log system determines, according to the execution result in the first processing log, whether the internal service step is an abnormal service step.

Optionally, the execution result in the first processing log includes: the execution succeeds or the execution fails; the abnormal business step is a business step corresponding to the execution result being the execution failure. When the execution result in the first processing log is an execution failure, the log system determines that the internal service step corresponding to the first processing log is an abnormal service step.

For example, the execution result in the first processing log 2, the first processing log 2, and the first processing log 3 in the first processing log 2 is an execution failure, and the log system determines the internal service step according to the execution result in the first processing log 2. 2 is an abnormal business step.

Optionally, this step can be implemented by the following possible implementation manners:

The first step is to determine whether the internal service step is an abnormal service step according to the execution result in the i-th first processing log, where i is a positive integer less than or equal to n.

Optionally, the initial value of i is 1. The log system starts from the first first processing log, and determines whether the corresponding internal service step is an abnormal service step according to the execution result of the first first processing log.

In the second step, if it is not an abnormal service step, let i=i+1, and continue to determine whether the corresponding internal service step is an abnormal service step according to the execution result in the i-th first processing log.

Through the loop of the above two steps, until the abnormal business step is determined, otherwise the execution results in the n first processing logs are sequentially determined.

Step 704: When the internal service step is an abnormal service step, the log system locates the first service system as a faulty service system.

When the log system determines that the corresponding internal service step in the i-th first processing log is an abnormal service step, the log system locates the first service system that performs the internal service step as the faulty service system. For example, the log system determines that the corresponding internal service step 2 in the second first processing log is an abnormal service step, and the log system determines that the first service system A in the internal service step 2 is determined as the faulty service system.

Optionally, the first service system includes: a first processing module having a first API, where the first API has a corresponding first API identifier; and the first processing log includes: a service request ID, a first service system ID, and a first API. The identification and result code, the result code refers to the execution result of the internal processing step performed by the first processing module.

Step 705: When the faulty service system is the first service system, the log system locates the API corresponding to the first API identifier as a fault API according to the first API identifier included in the first processing log.

The log system determines, according to the result code carried in the first processing log, that the first service system is a faulty service system, and determines an API corresponding to the first API identifier included in the first processing log as a fault API.

For example, the first service system B includes a first processing module a and a first processing module b; the first API identifier of the first processing module a is API11, and the first API identifier of the first processing module b is API12; the first service system When B performs the service request 72, a total of two internal service steps are required, which are the internal service step 1 and the internal service step 2; the internal processing step 1 is performed first through the first processing module a; and the internal processing is performed through the first processing module b. The service step 2: when the log system determines that the first service system B is the faulty service system according to the result code in the first processing log, the API corresponding to the API 12 is determined to be the fault API according to the API 12 carried in the first processing log. Optionally, the first processing module b corresponding to the fault API is a fault processing module.

In summary, the fault location method provided in this embodiment, when the first service system and the second service system perform the service step corresponding to the service request ID, the first service system sends a corresponding processing log to the log system, and the log is generated. The system determines the abnormal service step according to the execution result in the received processing log, and finally locates the faulty service system. The first service system generates a processing log for each service step, so that the log system can perform the execution result according to the processing log. The specific faulty service system is determined, and the prior art needs to check each service system in order from the top and bottom, and finally determine the faulty service system. When the number of service systems is large, the positioning efficiency of the faulty service system is caused. The lower problem is that the faulty service system is located through the processing log corresponding to the service request ID, and the effect on the positioning efficiency of the faulty service system is improved.

In addition, the log system determines whether the internal service step is an abnormal service step according to the execution result in the first processing log according to the execution order in the business process model, which is beneficial to sequentially determining abnormal business steps according to the sequence of executing the business steps, which is beneficial to avoid Waste of resources and improve the efficiency of positioning the faulty business system.

At the same time, when the faulty service system is the first service system, the log system determines, according to the first API identifier carried in the first processing log, that the API corresponding to the first API identifier is a fault API, and carries the first in the first processing log. An API identifier, so that the log system can locate the fault API according to the API identifier, thereby improving the accuracy of positioning the faulty service system.

Based on the embodiment shown in FIG. 6, optionally, the first service system invokes the second service system to perform and service. The external service step corresponding to the ID is obtained; the processing log is the second processing log, and the second processing log is used to record the execution result of the external service step corresponding to the service request ID by the first service system in the second service system. As another possible implementation manner, the steps 602 to 603 can be replaced by the following steps 801 to 805, as shown in FIG. 8 :

Step 801: The log system acquires a business process model corresponding to the service request ID, where the business process model includes: an execution sequence of each service step corresponding to the service request ID.

When the first service system calls the second service system to execute the external service step corresponding to the service request ID, the external service step corresponding to the entire service request ID needs to be executed according to the predetermined execution order, for example, as shown in FIG. At 81 o'clock, a total of six service systems are required to be completed as a service system 91, a service system 92, a service system 93, a service system 94, a service system 95, and a service system 96; a total of seven service steps are required, which are respectively service steps 1 Service Step 2, Service Step 3, Service Step 4, Service Step 5, Service Step 6 and Service Step 7; the service system 91 first executes the service step 1, the service step 2, and the service step 3 through the x module; Business step 4, business step 5, and business step 6; finally, business step 7 is performed through the z module. The service system 91 needs to invoke the service system 92 through the 2-1 API when the service step 1 is executed by the x module; the service step 92 needs to be invoked by the 2-2 API to invoke the service system 93 when the service step 1 is executed by the w module; the service system 91 is required to complete the service step 2 by calling the service system 93 through the 3-1 API; when the service system 91 executes the service step 4 through the y module, the system completes the service system 94 through the 4-1 API; the service system 91 executes the service through the y module. In step 5, the system is completed by calling the service system 95 through the 5-1 API; when the service system 91 executes the service step 6 through the y module, the system is completed by calling the service system 96 through the 6-1 API. Exemplarily, the business process model corresponding to the execution service request 81 is as shown in Table 1 below:

Table II

Step 802: The log system sequentially acquires m second processing logs corresponding to the respective service steps according to the execution order, where m is a positive integer.

After the log system obtains the business process model, it receives from the received order according to the execution order in the business process model. In the management log, obtain m second processing logs corresponding to each service step.

Optionally, the second processing log is an execution result corresponding to when the called second service system executes an external service step corresponding to the service request ID.

Step 803: The log system determines, according to the execution result in the second processing log, whether the external service step is an abnormal service step.

Optionally, the execution result in the second processing log includes: the execution succeeds or the execution fails; the abnormal business step is the business step corresponding to the execution result being the execution failure. When the execution result in the second processing log is an execution failure, the log system determines that the external service step corresponding to the second processing log is an abnormal service step.

For example, the execution result in the second processing log 2, the second processing log 2, and the second processing log 3 in the second processing log 2 is an execution failure, and the log system determines the external service step according to the execution result in the second processing log 2. 2 is an abnormal business step.

In the first step, it is determined whether the external service step is an abnormal service step according to the execution result in the jth second processing log, and j is a positive integer equal to or smaller than m.

Optionally, the initial value of j is 1. The log system starts from the first second processing log, and determines whether the corresponding external service step is an abnormal service step according to the execution result of the first second processing log.

In the second step, if it is not an abnormal service step, let j=j+1, and continue to determine whether the corresponding external service step is an abnormal service step according to the execution result in the jth second processing log.

Through the loop of the above two steps, until the abnormal business step is determined, otherwise the execution results in the m second processing logs are sequentially determined.

Step 804: When the external service step is an abnormal service step, the log system locates the called second service system as a faulty service system.

When the log system determines that the corresponding external service step in the jth second processing log is an abnormal service step, the log system locates the second service system that performs the external service step as the faulty service system. For example, the log system determines that the corresponding external service step 2 in the second second processing log is an abnormal service step, and the log system is determined to be the faulty service system by the second service system A1 that is called to execute the external service step 2.

Optionally, the first service system includes: a first processing module having a first API, the first API has a corresponding first API identifier, and the second service system includes: a second processing module having a second API, and a second API Having a corresponding second API identifier; the second processing log includes: a service request ID, a first service system ID, a first API identifier, a second service system ID, a second API identifier, and a return code, and the result code is in the call The second processing module executes the execution result of the external business step.

Step 805: When the faulty service system is the second service system, the log system locates the API corresponding to the second API identifier as the fault API according to the second API identifier included in the second processing log.

The log system determines, according to the return code carried in the second processing log, that the called second service system is the faulty service system, and determines the API corresponding to the second API identifier included in the second processing log as the fault API.

For example, the second service system B1 includes the second processing module a1 and the second processing module b1; the second API identifier of the second processing module a1 is the API 21, and the second API identifier of the second processing module b is the API 22; System When B1 executes the service request 82, a total of two external service steps are required, which are external service step 1 and external service step 2; first, external service step 1 is performed through the second processing module a1; and external processing is performed through the second processing module b1. The service step 2: when the log system determines that the second service system B1 is the faulty service system according to the return code in the second process log, the API corresponding to the API 22 is determined to be the fault API according to the API 22 carried in the second process log. Optionally, the second processing module b1 corresponding to the fault API is a fault processing module.

In addition, the log system determines whether the external service step is an abnormal service step according to the execution result in the second processing log according to the execution order in the business process model, which is beneficial to sequentially determining abnormal business steps according to the sequence of executing the business steps, thereby facilitating avoidance. Waste of resources and improve the efficiency of positioning the faulty business system.

At the same time, when the faulty service system is the second service system, the log system determines, according to the second API identifier carried in the second processing log, that the API corresponding to the second API identifier is a fault API, and carries the first in the second processing log. The second API identifier is provided, so that the log system can locate the fault API according to the API identifier, thereby improving the accuracy of positioning the faulty service system.

Please refer to FIG. 10, which is a flowchart of a method for locating a fault according to another embodiment of the present invention. This embodiment is exemplified by applying the fault location method to the fault location system shown in FIG. 3. Optionally, the log system includes: an analysis component, a modeling component, an ID processing component, and a log component; the fault location method includes the following steps:

In step 1001, the analysis component receives the service request ID to be analyzed.

When the service request fails to execute, the analysis component receives the input service request ID to be analyzed.

In step 1002, the analysis component obtains the business process model ID corresponding to the service request ID through the ID processing component.

The analysis component sends a process ID request carrying the service request ID to the ID processing component. The process ID request is used to request a business process model ID corresponding to the service request ID from the ID processing component.

After receiving the process ID request, the ID processing component queries the business process model ID corresponding to the service request ID according to the service request ID carried in the process ID request, and feeds the queryed business process model ID to the analysis component.

Step 1003: The analysis component acquires a business process model corresponding to the service request ID by using the modeling component.

The analysis component sends a model request carrying the business process model ID to the modeling component. The model request is used to request feedback from the modeling component to the business process model corresponding to the business process model ID.

After receiving the model request, the modeling component queries the business process model corresponding to the business process model ID according to the business process model ID carried in the model request, and feeds back the queryed business process model to the analysis component.

For a detailed description of the business process model, please refer to step 701 shown in FIG. 7 and step 801 shown in the figure, and details are not described herein again.

In step 1004, the analysis component obtains a processing log corresponding to the service request ID through the log component.

After obtaining the business process model, the analysis component sends a log acquisition request to the log component, where the log acquisition request is used to request the log component to feed back the processing log corresponding to the service request ID; optionally, the processing log includes: the first processing log and The second processing log.

For a detailed description of the first processing log, refer to step 702 shown in FIG. 7. For a detailed description of the second processing log, refer to step 802 shown in FIG. 8, and details are not described herein again.

After receiving the log obtaining request, the log component obtains the service request ID carried in the log obtaining request, and queries the first processing log and the second processing log corresponding to the service request ID according to the service request ID; and the queried service request ID The corresponding n first processing logs and m second processing logs are fed back to the analysis component.

Step 1005: The analysis component determines, according to the execution result in the i-th first processing log, whether the internal service step is an abnormal service step.

Optionally, the analysis component determines, according to the execution result in the i-th first processing log, whether the internal service step is an abnormal service step according to an execution order in the business process model, where i is a positive integer less than or equal to n.

In step 1006, if it is not an abnormal service step, the analysis component makes i=i+1, and continues to determine whether the corresponding internal service step is an abnormal service step according to the execution result in the i-th first processing log.

Through the loop of step 1005 and step 1006, until the abnormal service step is determined, otherwise the execution results in the n first processing logs are sequentially determined.

In step 1007, if it is an abnormal service step, the analysis component obtains t second processing logs corresponding to the first processing module that executes the abnormal service step from the m second processing logs.

If the internal service step is an abnormal service step, the analysis component determines that the first processing module that executes the internal service step is a faulty module. Because the first processing module has the possibility of invoking other service systems to complete the business step, the analysis component acquires The t second processing logs corresponding to the first processing module.

Step 1008: The analysis component determines, according to the execution result in the jth second processing log, whether the external service step is an abnormal service step.

Optionally, the analyzing component determines, according to the execution result in the jth second processing log, whether the external service step is an abnormal service step according to the execution order in the business process model, where j is a positive integer less than or equal to t.

In step 1009, if it is not an abnormal service step, the analysis component makes j=j+1, and continues to determine whether the external service step is an abnormal service step according to the execution result in the jth second processing log.

Through the loop of step 1008 and step 1009, until the abnormal business step is determined, otherwise the execution results in the t second processing logs are sequentially determined.

Step 1010: If it is an abnormal service step, the second API label in the second service system to which the analysis component is to be called is The corresponding API is located as a fault API.

If the external service step is an abnormal service step, the analysis component locates the API corresponding to the second API identifier corresponding to the second processing module of the external service step as the fault API.

For details of this step, refer to step 805 shown in Figure 8, and details are not described herein.

This step can be implemented by the processor 511 in the log system 140 shown in FIG. 5 executing the positioning module 524.

Step 1011: If there is no second processing log corresponding to the first processing module, the analysis component locates the API corresponding to the first API identifier of the first processing module as a fault API.

When the execution result of the analysis component in the i-th first processing log determines that the internal service step is an abnormal service step, the analysis component determines that the first processing module that executes the internal service step is a fault module, and if the m second processing logs are not When there is a second processing log corresponding to the first processing module, the analysis component locates the API corresponding to the first API identifier in the first processing module as a fault API; or, the analysis component determines the t corresponding to the first processing module. When the external service step in the execution result in the second processing log is not an abnormal service step, the analysis component locates the API corresponding to the first API identifier in the first processing module as the fault API.

It should be noted that, in this embodiment, whether the internal service step is abnormal according to the execution result in the first processing log, and then the external service step is determined to be abnormal according to the execution result in the second processing log. The service steps are described as an example. The order of the first processing log and the second processing log is not specifically limited. Optionally, after determining whether the external service step is an abnormal service step according to the execution result in the second processing log, determining whether the internal service step is an abnormal service step according to the execution result in the first processing log.

The following is an embodiment of the apparatus of the present invention, which can be used to carry out the method embodiments of the present invention. For details not disclosed in the embodiment of the device of the present invention, please refer to the method embodiment of the present invention.

Please refer to FIG. 11 , which is a structural block diagram of a fault locating device according to an embodiment of the present invention. The fault locating device can be implemented as a log system 140 shown in FIG. 2 or FIG. 3 by software, hardware, or a combination of both. All or part of it. The fault location device can include:

The receiving unit 1120 has the same or similar functions as the receiving module 521, and other implicit functions included by the receiving module 521.

The determining unit 1140 has the same or similar functionality as the determining module 522, as well as other implicit functions included by the determining module 522.

The positioning unit 1160 has the same or similar functionality as the positioning module 523, as well as other implicit functions contained by the positioning module 523.

The obtaining unit 1180 has the same or similar function as the obtaining module 524, and is included by the obtaining module 524 Other hidden features.

It is to be understood that the singular forms "a", "the", "the" It should also be understood that "and/or" as used herein is meant to include any and all possible combinations of one or more of the associated listed items.

The serial numbers of the embodiments of the present invention are merely for the description, and do not represent the advantages and disadvantages of the embodiments.

A person skilled in the art may understand that all or part of the steps of implementing the above embodiments may be completed by hardware, or may be instructed by a program to execute related hardware, and the program may be stored in a computer readable storage medium. The storage medium mentioned may be a read only memory, a magnetic disk or an optical disk or the like.

The above are only the preferred embodiments of the present invention, and are not intended to limit the present invention. Any modifications, equivalents, improvements, etc., which are within the spirit and scope of the present invention, should be included in the protection of the present invention. Within the scope.

Claims

A fault location platform, the platform includes: an identifier distribution system, a log system, a first service system, and a second service system;

The identifier distribution system is configured to allocate a service request identifier ID to the service request, where the service request is sent when the first service system performs a service; the service is the first service system in which the call relationship exists The service that the second service system cooperates to perform;

The first service system is configured to generate a processing log of each service step corresponding to the service request ID, where the processing log is used to record an execution result of the service step; the each service step includes: a business step performed by a service system, and the first service system invokes a service step performed by the second service system;

The log system is configured to receive the processing log corresponding to the service request ID, determine an abnormal service step according to the execution result in the processing log, and locate a service system for performing the abnormal service step For faulty business systems.
The platform of claim 1 wherein:

The first service system is configured to: when executing an internal service step corresponding to the service request ID, generate a first processing log corresponding to the internal service step, and send the first processing log to the log system The first processing log is used to record an execution result of the first service system performing the internal service step;

The first service system is further configured to: when the second service system is invoked to perform an external service step corresponding to the service request ID, generate a second processing log corresponding to the external service step, to the log The system sends the second processing log, where the second processing log is used to record an execution result of the second service system that is invoked to execute the external service step;

The log system is configured to determine, according to the execution result in the first processing log, whether the internal service step is the abnormal service step, and when the internal service step is the abnormal service step, Determining, by the first service system, the faulty service system; determining, according to the execution result in the second processing log, whether the external service step is the abnormal service step, where the external service step is the abnormality In the business step, the second service system to be called is located as the faulty service system.
The platform according to claim 2, wherein the first service system comprises: a first processing module having a first application programming interface API, the first API having a corresponding first API identifier; The second service system includes: a second processing module having a second API, the second API having a corresponding second API identifier;

The first service system is configured to send the first processing log to the log system; the first processing log includes: the service request ID, a first service system ID, the first API identifier, and a result a code, the result code is an execution result of the first processing module performing the internal service step;

The first service system is further configured to send the second processing log to the log system; the second processing log includes: the service request ID, the first service system ID, and the first API An identifier, a second service system ID, the second API identifier, and a return code, where the return code refers to an execution result of invoking the second processing module to execute the external service step;

The logging system is configured to: when the faulty service system is the first service system, locate an API corresponding to the first API identifier as a fault API; where the faulty service system is the called In the second service system, the API corresponding to the second API identifier is located as the fault API.
A platform according to claim 3, wherein

The log system is configured to acquire a business process model corresponding to the service request ID, where the business process model includes: an execution sequence of each service step corresponding to the service request ID; and sequentially acquiring and executing according to the execution sequence n first processing logs and m second processing logs corresponding to each service step, where n and the m are positive integers, respectively.
The platform according to claim 4, wherein the log system is further configured to:

Determining, according to an execution result in the i th first processing log, whether the internal service step is the abnormal service step, where i is a positive integer less than or equal to n;

If the abnormal service step is performed, the API corresponding to the first API identifier included in the i-th first processing log is located as the fault API;

If it is not the abnormal service step, let i=i+1, and determine, according to the execution result in the i-th first processing log, whether the internal service step is the abnormal service step.
The platform according to claim 4, wherein the log system is further configured to:

Determining, according to an execution result in the jth second processing log, whether the external service step is the abnormal service step, where j is a positive integer equal to or smaller than m;

If the abnormal service step is performed, the API corresponding to the second API identifier included in the jth second processing log is located as the fault API;

If it is not the abnormal service step, let j=j+1, and determine, according to the execution result in the jth second processing log, whether the external service step is the abnormal service step.
A fault location method, characterized in that the method comprises:

Receiving a processing log corresponding to the service request identifier ID; the service request is sent by the first service system when the first service system performs the service, and the service is performed by the first service system and the second service system in which the call relationship exists. The processing log is used to record the execution result of each service step corresponding to the service request ID, where the respective service steps include: a service step performed by the first service system, and the first service system calls the Business steps performed by the second business system;

Determining an abnormal service step according to the execution result in the processing log;

The business system for performing the abnormal business step is positioned as a faulty business system.
The method according to claim 7, wherein the processing log comprises: a first processing log and a second processing log;

Determining an abnormal service step according to the execution result in the processing log, including:

Determining, according to the execution result in the first processing log, whether the internal service step is the abnormal service step; the first processing log is used to record that the first service system executes the internal corresponding to the service request ID The result of the execution of the business steps;

Determining, according to the execution result in the second processing log, whether the external service step is the abnormal service step; the second processing log is configured to record, in the calling the second service system, the location corresponding to the service request ID The result of the execution of the external business steps.
The method according to claim 8, wherein the positioning the service system for performing the abnormal service step as a faulty service system comprises:

And when the internal service step is the abnormal service step, positioning the first service system as the faulty service system;

When the external service step is the abnormal service step, the called second service system is located as the faulty service system.
The method according to claim 9, wherein the first service system comprises: a first processing module having a first application programming interface API, the first API having a corresponding first API identifier; The second service system includes: a second processing module having a second API, where the second API has a corresponding second API identifier; the method further includes:

When the faulty service system is the first service system, the API corresponding to the first API identifier is located as a fault API according to the first API identifier included in the first processing log; The processing log includes: the service request ID, the first service system ID, the first API identifier, and the result code, where the result code refers to an execution result of the first processing module executing the internal service step;

When the faulty service system is the called second service system, the API corresponding to the second API identifier is located as the fault according to the second API identifier included in the second processing log. The second processing log includes: the service request ID, the first service system ID, the first API identifier, the second service system ID, the second API identifier, and a return code, and the return The code refers to the execution result of the execution of the external service step by calling the second processing module.
The method of claim 10, wherein the method further comprises:

Obtaining a business process model corresponding to the service request ID, where the business process model includes: an execution sequence of each service step corresponding to the service request ID;

Obtaining n first processing logs and m second processing logs corresponding to the respective service steps in sequence according to the execution sequence, where n and the m are positive integers, respectively.
The method according to claim 11, wherein the determining, according to the execution result in the first processing log, whether the internal service step is the abnormal service step comprises:

Determining, according to an execution result in the i th first processing log, whether the internal service step is the abnormal service step, where i is a positive integer less than or equal to n;

The positioning the API corresponding to the first API identifier as a fault API includes:

If the abnormal service step is performed, the API corresponding to the first API identifier included in the i-th first processing log is located as the fault API;

If it is not the abnormal service step, let i=i+1, and perform the step of determining whether the abnormal service step is the step according to the execution result in the i-th first processing log.
The method of claim 11 wherein said performing in said second processing log The result of the line determines whether the external business step is the abnormal business step, including:

Determining, according to an execution result in the jth second processing log, whether the external service step is the abnormal service step, where j is a positive integer equal to or smaller than m;

The positioning of the API corresponding to the second API identifier as the fault API includes:

If the abnormal service step is performed, the API corresponding to the second API identifier included in the jth second processing log is located as the fault API;

If it is not the abnormal service step, let j=j+1, and perform the step of determining whether the external service step is the abnormal service step according to the execution result in the jth second processing log.
A fault locating device, characterized in that the device comprises:

a receiving unit, configured to receive a processing log corresponding to the service request identifier ID; the service request is sent when the first service system executes the service, where the service is coordinated by the first service system and the second service system where the calling relationship exists Executing a service, the processing log is used to record an execution result of each service step corresponding to the service request ID, where each service step includes: a service step performed by the first service system, and the first The business system invokes a business step performed by the second service system;

a determining unit, configured to determine an abnormal service step according to the execution result in the processing log;

And a positioning unit, configured to locate a service system for performing the abnormal service step as a faulty service system.
The device according to claim 14, wherein the processing log comprises: a first processing log and a second processing log; and the determining unit is further configured to:

Determining, according to the execution result in the first processing log, whether the internal service step is the abnormal service step; the first processing log is used to record that the first service system executes the internal corresponding to the service request ID The result of the execution of the business steps;

Determining, according to the execution result in the second processing log, whether the external service step is the abnormal service step; the second processing log is configured to record, in the calling the second service system, the location corresponding to the service request ID The result of the execution of the external business steps.
The device according to claim 15, wherein the positioning unit is further configured to:

And when the internal service step is the abnormal service step, positioning the first service system as the faulty service system;

When the external service step is the abnormal service step, the called second service system is located as the faulty service system.
The apparatus according to claim 16, wherein the first service system comprises: a first processing module having a first application programming interface API, the first API having a corresponding first API identifier; The second service system includes: a second processing module having a second API, the second API having a corresponding second API identifier; the positioning unit is further configured to:

When the faulty service system is the first service system, the API corresponding to the first API identifier is located as a fault API according to the first API identifier included in the first processing log; A processing log includes: the service request ID, a first service system ID, the first API identifier, and a result code, where the result code refers to The first processing module executes an execution result of the internal service step;

When the faulty service system is the called second service system, the API corresponding to the second API identifier is located as the fault according to the second API identifier included in the second processing log. The second processing log includes: the service request ID, the first service system ID, the first API identifier, the second service system ID, the second API identifier, and a return code, and the return The code refers to the execution result of the execution of the external service step by calling the second processing module.
The device according to claim 17, wherein the device further comprises:

An obtaining unit, configured to acquire a business process model corresponding to the service request ID, where the business process model includes: an execution sequence of each service step corresponding to the service request ID;

The acquiring unit is further configured to sequentially acquire n first processing logs and m second processing logs corresponding to the respective service steps according to the execution order, where the n and the m are positive integers, respectively.
The apparatus according to claim 18, wherein the determining unit is further configured to determine, according to an execution result in the i th first processing log, whether the internal service step is the abnormal service step, where the i Is a positive integer less than or equal to n;

The positioning unit is further configured to:

If the abnormal service step is performed, the API corresponding to the first API identifier included in the i-th first processing log is located as the fault API;

If it is not the abnormal service step, let i=i+1, and perform the step of determining whether the abnormal service step is the step according to the execution result in the i-th first processing log.
The apparatus according to claim 18, wherein the determining unit is further configured to determine, according to an execution result in the jth second processing log, whether the external service step is the abnormal service step, the j Is a positive integer less than or equal to m;

The positioning unit is further configured to:

If the abnormal service step is performed, the API corresponding to the second API identifier included in the jth second processing log is located as the fault API;

If it is not the abnormal service step, let j=j+1, and perform the step of determining whether the external service step is the abnormal service step according to the execution result in the jth second processing log.