Fault locating method, device, equipment and computer readable storage medium

Abstract

The application discloses a fault positioning method, device, equipment and computer readable storage medium. The method comprises the following steps: obtaining an error code of a first service component; analyzing the structure of the error code to obtain a structure code field of the error code; the structure code field at least comprises a code field used for representing a service scene in which the first service component is located; the service scene is determined by the calling relationship among service components; determining the service scene in which the first service component is located according to the code field used for representing the service scene in which the first service component is located; and positioning a fault service component corresponding to the error code according to the service scene. According to the fault positioning method, the service scene in which the first service component is located is determined, and the fault service component corresponding to the error code is positioned according to the service scene, so that the range of the fault service component to be checked can be quickly narrowed down. Therefore, the fault service component can be quickly checked and accurately positioned.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of computers, and particularly relates to a fault positioning method and device, equipment and a computer readable storage medium. BACKGROUND

[0002] In a complex business system, multiple business components often need to call each other to reduce the coupling between components. Since there is a complex calling relationship between components, if an error occurs in the business system, it is difficult to trace back to the source business component that caused the error. Therefore, a business error code needs to be designed to locate the business component that caused the error of the business system.

[0003] At present, the existing business error code design rule can only locate the component where the error occurs. However, it is found in the tracing process that the business component located by the error code is not necessarily the source business component that caused the error, i.e., the fault business component. At this time, the fault business component needs to be located accurately by checking the business component located by the error code.

[0004] In the prior art, the process of locating the fault business component by checking the business component located by the error code is long and slow. SUMMARY

[0005] The embodiments of the present application provide a fault positioning method, device, equipment, computer readable storage medium and computer program product, which can quickly check and accurately locate the fault business component.

[0006] In a first aspect, the embodiments of the present application provide a fault positioning method, which comprises:

[0007] obtaining an error code of a first business component;

[0008] analyzing the structure of the error code to obtain a structure code field constituting the error code; the structure code field at least includes a code field for representing a business scenario in which the first business component is located; the business scenario is determined by a calling relationship between business components;

[0009] determining the business scenario in which the first business component is located according to the code field for representing the business scenario in which the first business component is located;

[0010] locating a fault business component corresponding to the error code according to the business scenario.

[0011] In a possible implementation manner, before the structure of the error code is analyzed to obtain the structure code field constituting the error code, the method further comprises:

[0012] determine a plurality of business scenarios according to a calling relationship between business components;

[0013] configure error codes with different structure coding fields for different business scenarios.

[0014] In a possible implementation, the determining a plurality of business scenarios according to a calling relationship between business components specifically includes:

[0015] determine a first scenario in which a single business component is not called; the first scenario includes the single business component;

[0016] The configuring error codes with different structure coding fields for different business scenarios specifically includes:

[0017] configure the structure coding field of the error code of the first scenario as a combination of an error category coding field, a business component coding field, and an error coding field; the business component coding field is a unique identifier of the single business component.

[0018] In a possible implementation, the determining a plurality of business scenarios according to a calling relationship between business components specifically includes:

[0019] determine a second scenario in which two business components are called; the second scenario includes an initiator business component and a receiver business component; the initiator business component is a business component that initiates a call; the receiver business component is a business component that receives a call;

[0020] The configuring error codes with different structure coding fields for different business scenarios specifically includes:

[0021] configure the structure coding field of the error code of the second scenario as a combination of an error category coding field, an initiator business component coding field, a receiver business component coding field, and an error coding field; the initiator business component coding field is a unique identifier of the initiator business component; the receiver business component coding field is a unique identifier of the receiver business component.

[0022] In a possible implementation, the determining a plurality of business scenarios according to a calling relationship between business components specifically includes:

[0023] determine a third scenario in which a plurality of business components are called; the third scenario includes an intermediate business component, an upstream business component, and a downstream business component; the upstream business component is a business component that initiates a call; the downstream business component is a business component that receives a call; the intermediate business component is used for information transfer between the upstream business component and the downstream business component;

[0024] The error code with different structure coding fields is configured for different service scenarios, and specifically includes the following steps.

[0025] The structure coding field of the error code of the third scenario is configured as a combination of an error category coding field, an intermediate service component coding field, an upstream service component coding field, a downstream service component coding field, and an error coding field; the intermediate service component coding field is a unique identifier of the intermediate service component; the upstream service component coding field is a unique identifier of the upstream service component; and the downstream service component coding field is a unique identifier of the downstream service component.

[0026] In a possible implementation, the downstream service component includes at least one of a service component inside a service system and a service component outside the service system.

[0027] In a second aspect, an embodiment of the present application provides a fault locating device, which includes the following modules.

[0028] An obtaining module is configured to obtain an error code of a first service component.

[0029] An analyzing module is configured to analyze the structure of the error code to obtain a structure coding field constituting the error code; the structure coding field includes at least a coding field used to represent a service scenario in which the first service component is located; and the service scenario is determined by a calling relationship between service components.

[0030] A first determining module is configured to determine the service scenario in which the first service component is located according to the coding field used to represent the service scenario in which the first service component is located.

[0031] A locating module is configured to locate a fault service component corresponding to the error code according to the service scenario.

[0032] In a third aspect, an embodiment of the present application provides an electronic device, which includes a processor and a memory storing computer program instructions.

[0033] The processor implements the method in any possible implementation method of the first aspect when executing the computer program instructions.

[0034] In a fourth aspect, an embodiment of the present application provides a computer readable storage medium, which stores computer program instructions, and the computer program instructions are executed by a processor to implement the method in any possible implementation method of the first aspect.

[0035] In a fifth aspect, an embodiment of the present application provides a computer program product, instructions in the computer program product being executed by a processor of an electronic device to cause the electronic device to perform the method in any possible implementation of the method in the first aspect.

[0036] The fault positioning method, apparatus, device, computer readable storage medium and computer program product provided in the embodiments of the present application can quickly determine the service scenario in which the first service component is located according to the structure coding field of the error code. Since the service scenario is determined according to the calling relationship between the service components, the service scenario refines the calling relationship between the service components. Therefore, the number of service components in each service scenario is relatively small, and the calling relationship between the service components is relatively clear. Therefore, by determining the service scenario in which the first service component is located, and positioning the fault service component corresponding to the error code according to the service scenario, the range of the fault service component to be checked can be quickly narrowed down. Thus, the fault service component can be quickly checked and accurately positioned. BRIEF DESCRIPTION OF DRAWINGS

[0037] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed to be used in the embodiments of the present application will be briefly introduced. For those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.

[0038] Figure 1 is a calling relationship between service components provided by an embodiment of the present application;

[0039] Figure 2 is a flowchart of a fault positioning method provided by an embodiment of the present application;

[0040] Figure 3 is a calling relationship between service components based on different service scenarios provided by an embodiment of the present application;

[0041] Figure 4 is a flowchart of another fault positioning method provided by an embodiment of the present application;

[0042] Figure 5 is a flowchart of a fault positioning apparatus provided by an embodiment of the present application;

[0043] Figure 6 is a flowchart of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0044] The features and exemplary embodiments of the various aspects of the present application will be described in detail below with reference to the figures. To make the present application more clear, the present application is described in further detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are merely intended to explain the present application, but not to limit the present application. The present application can be implemented without some of the specific details by those skilled in the art. The following description of the embodiments is merely intended to provide a better understanding of the present application by showing examples of the present application.

[0045] It should be noted that, in this document, the terms such as first and second are merely used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between these entities or operations. Moreover, the terms "include", "contain" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such a process, method, article or device. Without more limitations, the elements defined by the statement "include" do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0046] In a multi-component business system, an error code is generally composed of three parts: error category, business component code and error code.

[0047] Among them, the error category generally includes: business component program exception, business component business processing exception and outbound third-party service component exception. For convenience of description, the three categories can be named as X, Y, Z three error categories in turn. Among them, X, Y, Z are only three categories, and on the basis of the above three categories, there can be some subdivided small categories. In addition, the above subdivided small categories can be identified by two-digit code. For example, Y type can be subdivided into business logic error (BL), password authentication exception (PW) and the like.

[0048] In addition, in a multi-component business system, in order to facilitate the description of the calling relationship between the business components, the business components can be coded. The calling relationship between the business components can be shown as Figure 1 .

[0049] Further, the error code is to uniformly code all errors in the business component, which is generally represented by 3 or 4 digit codes. For example, the string length overlength can be coded as 1000, and the variable format exception can be coded as 1001 and the like.

[0050] On this basis, if Figure 1If an exception occurs in component 3 in the error code and an error code is thrown, the faulty component can be located from the error code. For example, if the error code thrown is YBLA0031000, it can be seen from the error code that the location of the error code thrown is A003, that is, the user maintaining the A003 component first checks A003. Based on the calling relationship between components, if the user maintaining the A003 component feeds back that the A003 component has no problem, it is possible that the A003 component has a problem, and the user maintaining the A002 component needs to be contacted to check the A002 component. Such a checking process has no problem. However, for a business system with many business components and a complex calling relationship between components, the above checking process can seriously slow down the checking speed. Especially for some important and / or wide-ranging business systems, the faulty business component needs to be quickly located and the problem needs to be solved to ensure the normal operation of the business.

[0051] To solve the problems in the prior art, an embodiment of the present application provides a fault locating method, device, equipment, computer readable storage medium and computer program product.

[0052] First, the fault locating method provided by the embodiment of the present application is introduced.

[0053] Figure 1 A flowchart of a fault locating method provided by the embodiment of the present application is shown. As shown in Figure 1 The fault locating method provided by the embodiment of the present application includes the following steps:

[0054] S210, an error code of a first business component is acquired;

[0055] S220, the structure of the error code is parsed to obtain a structure code field constituting the error code; the structure code field at least includes a code field used for representing a business scenario in which the first business component is located; the business scenario is determined by a calling relationship between business components;

[0056] S230, the business scenario in which the first business component is located is determined according to the code field used for representing the business scenario in which the first business component is located;

[0057] S240, a faulty business component corresponding to the error code is located according to the business scenario.

[0058] The fault positioning method of the embodiment of the application can quickly determine the service scenario in which the first service component is located by encoding the fields according to the structure of the error code. Since the service scenario is determined according to the calling relationship between the service components, the service scenario refines the calling relationship between the service components. Therefore, the number of service components in each service scenario is relatively small, and the calling relationship between the service components is relatively clear. Therefore, by determining the service scenario in which the first service component is located and positioning the fault service component corresponding to the error code according to the service scenario, the range of the fault service component can be quickly narrowed down. Thus, the fault service component can be quickly checked and accurately positioned.

[0059] The specific implementation of each step is described below.

[0060] In some embodiments, in S210, the error code can be composed of an error category, a service component code and an error code. The error category can include service component program exception, service component service processing exception and outbound third-party service component exception, etc. In addition, each error category can also include a subcategory. For example, the service component service processing exception can specifically include service logic error, password authentication exception, etc. On this basis, based on the error category, each error category can be encoded respectively. For example, the service component program exception can be encoded as X, the service component service processing exception can be encoded as Y, the outbound third-party service component exception can be encoded as Z, the service logic error can be encoded as BL, and the password authentication exception can be encoded as PW, etc.

[0061] In addition, based on the uniqueness of the function of each service component, each service component can be uniquely encoded. For example, component 1 can be encoded as A001, component 2 can be encoded as A002, etc.

[0062] Furthermore, the error code can be the unique code of the error occurring in the service component. For example, the string length overlength can be encoded as 1000, and the variable format exception can be encoded as 1001, etc.

[0063] It should be noted that the encoding of the error category, the service component code and the error code can be composed of numbers, letters or a combination of numbers and letters, which is not limited herein. Since the error code can be composed of the error category, the service component code and the error code, the error code can also be composed of numbers and / or letters.

[0064] In this embodiment, the service component code in the error code can be one, two or multiple.

[0065] As an example, a business system may include multiple business components, and complex calling relationships may exist between these components. If an error occurs at a certain business component, that component cannot perform its original task. In this case, the business system has failed and can throw an error code. This error code can be displayed on the monitoring interface of the operations and maintenance personnel. The monitoring interface can be any display interface capable of receiving messages from the business system.

[0066] In some embodiments, in S220, the structure encoding field of the error code may include an error category encoding field, a business component encoding field, and an error encoding field, etc.

[0067] As an example, after the business system throws an error code, the error code can be parsed to obtain the various structured encoding fields that make up the error code, such as the error category encoding field, the business component encoding field, and the error code field.

[0068] In some embodiments, in S230, the business scenario can be determined by the calling relationship between business components. The business scenario can be a first scenario, a second scenario, or a third scenario. Additionally, as... Figure 3 As shown, the first scenario can be a business scenario where a single component is not invoked; the second scenario can be a business scenario where two business components are invoked; and the third scenario can be a business scenario where multiple business components are invoked. Among the multiple business components in the third scenario, an intermediate business component may be included. This intermediate business component can be used only for information relay. Furthermore, the multiple business components in the third scenario may include three business components.

[0069] As an example, since the first scenario includes a single business component, the second scenario includes two business components, and the third scenario includes multiple business components, if only one business component code exists in the business component code field of the error code, it can be determined that the business component that caused the error is in the first scenario. If two business component codes exist in the business component code field of the error code, it can be determined that the business component that caused the error is in the second scenario. If multiple business component codes exist in the business component code field of the error code, it can be determined that the business component that caused the error is in the third scenario.

[0070] As another example, the business component program exception X can occur in the first scenario, the business component program exception X and the business component business processing exception Y can occur in the second scenario, and the outbound third-party service component exception Z can occur in the third scenario. Therefore, if the error category X exists in the error category coding field of the error code, it can be determined that the business component where the error occurs is in the first scenario. If the error category Y exists in the error category coding field of the error code, it can be determined that the business component where the error occurs is in the first scenario or the second scenario. If the error category Z exists in the error category coding field of the error code, it can be determined that the business component where the error occurs is in the third scenario.

[0071] In some embodiments, in S240, the business component where the error occurs can be a business component that cannot perform the original task, and the faulty business component can be a business component that causes the error. Due to the complex calling relationship between the business components, the business component where the error occurs is not necessarily the faulty business component.

[0072] As an example, if the business component where the error occurs is in the first scenario, it can be determined that the business component where the error occurs is the faulty business component. If the business component where the error occurs is in the second scenario, since there are only two business components in the second scenario, when the business component where the error occurs is not faulty, it can be determined that the other business component in the second scenario is the faulty business component. If the business component where the error occurs is in the third scenario, since there are multiple business components in the third scenario, when the business component where the error occurs is not faulty, other business components can be investigated. Specifically, there can be three business components in the third scenario, so when the business component where the error occurs is not faulty, only the other two business components need to be investigated, and then it can be determined that one of the other two business components in the third scenario is the faulty business component.

[0073] In order to quickly locate the faulty business component, as another implementation manner of the present application, the present application further provides another implementation manner of the fault locating method, which is described in the following embodiments.

[0074] Please refer to Figure 4 The fault locating method provided by the embodiments of the present application can further include the following steps before S220 shown in the above embodiments.

[0075] S410, determining a plurality of business scenarios according to a calling relationship between the business components;

[0076] S420, configuring error codes with different structure coding fields for different business scenarios.

[0077] The embodiments of the present application can determine a plurality of business scenarios according to the calling relationship between business components, so as to simplify the calling relationship between business components. By configuring error codes with different structure coding fields for different business scenarios, the business scenario in which the business component is located can be quickly located according to the coding field in the error code representing the business scenario when the business system throws an error code, and then the faulty business component can be quickly located.

[0078] The specific implementation of each step is described below.

[0079] In some embodiments, in S410, the calling relationship between components can have a single business component without calling, two business components calling, and a plurality of business components calling in turn, and the like. Among them, any two business components can be in a mutual calling relationship, or in a one-way calling relationship.

[0080] In some embodiments, in S420, the error code can be composed of an error category, a business component code, and an error code. Since the calling relationship and the number of business components are different in different business scenarios, different numbers of business component codes can be configured for different business scenarios. In this embodiment, the error code with different structure coding fields includes but is not limited to different numbers of business component codes.

[0081] In this embodiment, S410 can specifically include:

[0082] The business scenario in which a single business component is not called is determined as a first scenario; the first scenario includes a single business component;

[0083] S420 can specifically include:

[0084] The structure coding field of the error code of the first scenario is configured as a combination of an error category coding field, a business component coding field, and an error coding field; the business component coding field is a unique identifier of a single business component.

[0085] Here, a single business component can independently execute the internal processing logic of the business component. That is, in the first scenario, a single business component can not call other components and independently execute tasks. In other words, the error code configured for the first scenario can reflect the abnormal error in the business component.

[0086] In addition, the error code of the first scenario in this embodiment can be compatible with the general error code in the prior art which is not configured for a business scenario.

[0087] In this way, since there is only one service component in the first scenario, by determining that the service component where the error occurs is in the first scenario, the service component where the error occurs can be immediately determined as the faulty service component, and the faulty service component can be quickly located.

[0088] In this embodiment, S410 can further include:

[0089] The service scenario in which the two service components are invoked is determined as a second scenario; the second scenario includes an initiator service component and a receiver service component; the initiator service component is a service component that initiates invocation; and the receiver service component is a service component that receives invocation.

[0090] S420 can further include:

[0091] The structure of the error code of the second scenario is configured as a combination of an error category encoding field, an initiator service component encoding field, a receiver service component encoding field, and an error encoding field; the initiator service component encoding field is a unique identifier of the initiator service component; and the receiver service component encoding field is a unique identifier of the receiver service component.

[0092] Here, the invocation relationship between the two service components can be bidirectional invocation or unidirectional invocation. In a certain service invocation, if service component A invokes service component B, service component A can be the initiator service component, and service component B can be the receiver service component. On the other hand, in a certain service invocation, if service component B invokes service component A, service component B can be the initiator service component, and service component A can be the receiver service component. Therefore, the two service components in the second scenario can both perform internal processing logic of the service components.

[0093] As an example, if the second scenario includes service component A and service component B, when an error occurs at service component A, the range of the faulty service component can be locked to service component A and service component B.

[0094] As an example, if there are more than two service components that invoke each other, the invocation relationship between the multiple service components can be divided into multiple second scenarios. For example, service component A invokes service component B, and service component B invokes service component C. The service scenario in which service component A invokes service component B can be determined as one second scenario, and the service scenario in which service component B invokes service component C can be determined as another second scenario.

[0095] In this way, since there are only two service components in the second scenario, by determining that the service component where the error occurs is in the second scenario, the range of the faulty service component can be immediately narrowed, and the faulty service component can be quickly located.

[0096] In the embodiment, S410 can further include:

[0097] The service scenario in which the plurality of service components are invoked is determined as a third scenario; the third scenario includes an intermediate service component, an upstream service component, and a downstream service component; the upstream service component is a service component that initiates invocation; the downstream service component is a service component that receives invocation; and the intermediate service component is used for information transfer between the upstream service component and the downstream service component.

[0098] S420 can further include:

[0099] The structure coding field of the error code of the third scenario is configured as a combination of an error category coding field, an intermediate service component coding field, an upstream service component coding field, a downstream service component coding field, and an error coding field; the intermediate service component coding field is a unique identifier of the intermediate service component; the upstream service component coding field is a unique identifier of the upstream service component; and the downstream service component coding field is a unique identifier of the downstream service component.

[0100] Here, the third scenario can include three service components. The upstream service component and the downstream service component can both be used for processing logic within the service components, and the intermediate service component can only be used for information transfer between the upstream service component and the downstream service component, without any logic processing. Of course, the intermediate service component can also be used for processing logic within the service components.

[0101] In addition, the downstream service component can include at least one of a service component within a business system and a service component outside the business system. When the downstream service component is a service component outside the business system, there can be an intermediate service component for accommodating invocation between service components inside and outside the system, because the message structure of the service component outside the system and the message structure of the service component inside the system can be different. Of course, when the downstream service component is a service component outside the business system, there can also be an intermediate service component for information transfer between the upstream service component and the downstream service component. The intermediate service component can be used for processing logic within the service components.

[0102] As an example, if there are more than three service components for invocation, the invocation relationship between the plurality of service components can be divided into a plurality of third scenarios. For example, service component A invokes service component B, service component B invokes service component C, and service component C invokes service component D. Service component A invoking service component B and service component B invoking service component C can be determined as one third scenario, and service component B invoking service component C and service component C invoking service component D can be determined as another third scenario.

[0103] Thus, since there are only three service components in the third scenario, the range of the faulty service component can be narrowed down immediately by determining that the faulty service component is in the third scenario, and the faulty service component can be located quickly.

[0104] In addition, other steps of the method in the embodiments of the present application can be referred to the above Figure 2 The related description of the embodiments is not described in detail here.

[0105] Based on the fault locating method provided in the above embodiments, the present application also provides a specific implementation of the fault locating device. Please refer to the following embodiments.

[0106] As Figure 5 The fault locating device 500 provided in the embodiments of the present application includes the following modules:

[0107] The acquisition module 510 is configured to acquire the error code of the first service component.

[0108] The analysis module 520 is configured to analyze the structure of the error code to obtain a structure code field constituting the error code. The structure code field at least includes a code field for representing the service scenario in which the first service component is located. The service scenario is determined by the calling relationship between the service components.

[0109] The first determination module 530 is configured to determine the service scenario in which the first service component is located according to the code field for representing the service scenario in which the first service component is located.

[0110] The locating module 540 is configured to locate the faulty service component corresponding to the error code according to the service scenario.

[0111] As an implementation of the present application, as described above, the device can further include:

[0112] The second determination module is configured to determine a plurality of service scenarios according to the calling relationship between the service components.

[0113] The configuration module is configured to configure error codes with different structure code fields for different service scenarios.

[0114] As an implementation of the present application, as described above, the second determination module can specifically include:

[0115] The first determination sub-module is configured to determine a single-service-component-no-call service scenario as a first scenario. The first scenario includes a single service component.

[0116] Based on this, the configuration module can specifically include:

[0117] The first configuration submodule is configured to configure the structure coding field of the error code of the first scenario as a combination of an error category coding field, a service component coding field and an error coding field; and the service component coding field is a unique identifier of a single service component.

[0118] As an implementation form of the present application, the second determination module can further include:

[0119] The second determination submodule is configured to determine a service scenario in which two service components are invoked as a second scenario; the second scenario includes an initiator service component and a receiver service component; the initiator service component is a service component that initiates invocation; and the receiver service component is a service component that receives invocation.

[0120] Based on this, the configuration module can further include:

[0121] The second configuration submodule is configured to configure the structure coding field of the error code of the second scenario as a combination of an error category coding field, an initiator service component coding field, a receiver service component coding field and an error coding field; the initiator service component coding field is a unique identifier of the initiator service component; and the receiver service component coding field is a unique identifier of the receiver service component.

[0122] As an implementation form of the present application, the second determination module can further include:

[0123] The third determination submodule is configured to determine a service scenario in which multiple service components are invoked as a third scenario; the third scenario includes an intermediate service component, an upstream service component and a downstream service component; the upstream service component is a service component that initiates invocation; the downstream service component is a service component that receives invocation; and the intermediate service component is used for information relay between the upstream service component and the downstream service component.

[0124] Based on this, the configuration module can further include:

[0125] The third configuration submodule is configured to configure the structure coding field of the error code of the third scenario as a combination of an error category coding field, an intermediate service component coding field, an upstream service component coding field, a downstream service component coding field and an error coding field; the intermediate service component coding field is a unique identifier of the intermediate service component; the upstream service component coding field is a unique identifier of the upstream service component; and the downstream service component coding field is a unique identifier of the downstream service component.

[0126] As an implementation form of the present application, the downstream service component includes at least one of a service component inside a service system and a service component outside the service system.

[0127] The fault positioning device provided in the embodiments of the present application can quickly determine the service scenario in which the first service component is located by the structure coding field of the error code. Since the service scenario is determined according to the calling relationship between the service components, the service scenario refines the calling relationship between the service components. Therefore, the number of service components in each service scenario is relatively small, and the calling relationship between the service components is relatively clear. Therefore, by determining the service scenario in which the first service component is located, and positioning the fault service component corresponding to the error code according to the service scenario, the range of the fault service component can be quickly narrowed down. Thus, the fault service component can be quickly checked and accurately positioned.

[0128] Based on the fault positioning method provided in the above embodiments, the present application further provides a specific implementation of an electronic device. Figure 6 A schematic diagram of an electronic device 600 provided by the embodiments of the present application is shown.

[0129] The electronic device 600 can include a processor 610 and a memory 620 storing computer program instructions.

[0130] Specifically, the processor 610 described above can include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or can be configured as one or more integrated circuits implementing the embodiments of the present application.

[0131] The memory 620 can include a mass storage for data or instructions. By way of example and not limitation, the memory 620 can include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive or a combination of two or more of these. Where appropriate, the memory 620 can include removable or non-removable (or fixed) media. Where appropriate, the memory 620 can be internal or external to the integrated gateway disaster recovery device. In certain embodiments, the memory 620 is non-volatile solid-state memory.

[0132] The memory can include read-only memory (ROM), random-access memory (RAM), magnetic disk storage mediums, optical storage mediums, flash memory devices, electrical, optical, or other physical / tangible memory storage devices. Thus, in general, the memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., a memory device) encoded with software that, when executed (by one or more processors), is operable to perform operations described with reference to the methods according to an aspect of the present application.

[0133] The processor 610 implements the fault locating method in any of the above embodiments by reading and executing computer program instructions stored in the memory 620.

[0134] In one example, the electronic device 600 can further include a communication interface 630 and a bus 640. As shown, the processor 610, the memory 620, and the communication interface 630 are connected through the bus 640 and complete communication therebetween. Figure 6

[0135] The communication interface 630 is mainly used to realize communication between modules, devices, units and / or equipment in the embodiments of the present application.

[0136] The bus 640 includes hardware, software or both to couple components of the electronic device to each other. By way of example, and not limitation, the bus can include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an InfiniBand interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or another suitable bus or combination of two or more of these. Where appropriate, the bus 640 can include one or more buses. Although the present application describes and illustrates a particular bus, the present application contemplates any suitable bus or interconnect.

[0137] The electronic device can perform the fault locating method in the embodiments of the present application based on the error code of the first service component that has been acquired at present, thereby realizing the fault locating method and device described in combination Figures 1 to 5 with the above embodiments.

[0138] In addition, in combination with the fault locating method in the above embodiments, the embodiments of the present application can provide a computer storage medium to realize. The computer storage medium has computer program instructions stored thereon; the computer program instructions are executed by a processor to implement any of the fault locating methods in the above embodiments.

[0139] It should be noted that the present application is not limited to the specific configurations and processes described above and shown in the drawings. For the sake of brevity, detailed descriptions of well-known methods are omitted herein. In the above embodiments, several specific steps are described and shown as examples. However, the method processes of the present application are not limited to the specific steps described and shown, and those skilled in the art can make various changes, modifications and additions, or change the order of the steps, after understanding the spirit of the present application.​

[0140] The functions noted in the block diagrams of the above-described structures can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application specific integrated circuits (ASICs), appropriate firmware, plug-ins, functional cards, and the like. When implemented in software, the elements of the present application are program or code segments used to perform the required tasks. The program or code segments can be stored in a machine-readable medium or transmitted through a data signal carried in a carrier wave over a transmission medium or communication link. The "machine-readable medium" can include any medium that can store or transfer information. Examples of the machine-readable medium include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, optical fiber media, radio frequency (RF) links, and the like. The code segments can be downloaded via a computer network such as the Internet, an intranet, and the like.

[0141] It is also noted that the exemplary embodiments mentioned in the present application describe some methods or systems based on a series of steps or devices. However, the present application is not limited to the order of the above steps, that is, the steps can be performed in the order mentioned in the embodiments, or in an order different from the embodiments, or several steps can be performed simultaneously.

[0142] The above-described aspects of the present application can be described with reference to flow charts and / or block diagrams illustrating the architecture, functionality, and operation of implementations of methods, apparatus (systems) and computer program products according to the present application. It will be understood that each block of the flow chart and / or block diagrams, and combinations of blocks in the flow chart and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / acts specified in the flow chart and / or block diagram block or blocks. Such processors can be, but not limited to, general purpose processors, special purpose processors, special purpose application specific processors, or field programmable logic arrays (FPLAs). It should also be understood that each block of the flow chart and / or block diagrams and combinations of blocks in the flow chart and / or block diagrams can be implemented by special purpose hardware-based computer systems which perform some or all of the steps depending on implementation. The embodiments described herein can be implemented in hardware, software, firmware, or any combination thereof.

[0143] The above merely describes a specific implementation of the present application. Those skilled in the art can clearly understand the specific working processes of the system, modules and units described above for the convenience and brevity of description, and can refer to the corresponding processes in the foregoing method embodiments, which will not be described herein again. It should be understood that the protection scope of the present application is not limited to this, and any person skilled in the art can easily think of various equivalent modifications or replacements within the technical range disclosed by the present application, and these modifications or replacements should be covered within the protection scope of the present application.

Claims

1. A fault location method characterized by, The method comprises: obtaining an error code of a first service component; parsing a structure of the error code to obtain a structure code field constituting the error code; the structure code field at least includes an encoding field for representing a service scenario in which the first service component is located; the service scenario is determined by a calling relationship between service components; determining the service scenario in which the first service component is located according to the encoding field for representing the service scenario in which the first service component is located; locating a faulty service component corresponding to the error code according to the service scenario; wherein the service scenario includes a first scenario, a second scenario and a third scenario; the first scenario is a service scenario without calling of a single service component, the first scenario includes a single service component, and in the first scenario, the service component that has occurred an error is the faulty service component; the second scenario is a service scenario with calling of two service components, the second scenario includes an initiator service component and a receiver service component, and in the second scenario, when the service component that has occurred an error is not faulty, the other service component is the faulty service component; the third scenario is a service scenario with calling of multiple service components, the third scenario includes an intermediate service component, an upstream service component and a downstream service component, and in the third scenario, when the service component that has occurred an error is not faulty, one of the other two service components is the faulty service component.

2. The fault locating method of claim 1, wherein, Before the parsing of the structure of the error code to obtain the structure code field constituting the error code, the method further comprises: determining multiple service scenarios according to a calling relationship between service components; configuring error codes with different structure code fields for different service scenarios.

3. The fault locating method of claim 2, wherein, The configuration of error codes with different structure code fields for different service scenarios specifically comprises: configuring the structure code field of the error code of the first scenario as a combination of an error category encoding field, a service component encoding field and an error encoding field; the service component encoding field is a unique identifier of the single service component.

4. The fault locating method of claim 2, wherein, The initiator service component is a service component that initiates calling; the receiver service component is a service component that receives calling; The configuration of error codes with different structure code fields for different service scenarios specifically comprises: configuring the structure code field of the error code of the second scenario as a combination of an error category encoding field, an initiator service component encoding field, a receiver service component encoding field and an error encoding field; the initiator service component encoding field is a unique identifier of the initiator service component; the receiver service component encoding field is a unique identifier of the receiver service component.

5. The fault locating method of claim 2, wherein, The upstream service component is a service component that initiates calling; the downstream service component is a service component that receives calling; the intermediate service component is used for information relay between the upstream service component and the downstream service component; The configuration of error codes with different structure code fields for different service scenarios specifically comprises: The structure coding field of the error code of the third scenario is configured as a combination of an error category coding field, an intermediate service component coding field, an upstream service component coding field, a downstream service component coding field and an error coding field; the intermediate service component coding field is a unique identifier of the intermediate service component; the upstream service component coding field is a unique identifier of the upstream service component; and the downstream service component coding field is a unique identifier of the downstream service component.

6. The fault locating method of claim 5, wherein, The downstream service component includes at least one of a service component inside a service system and a service component outside the service system.

7. A fault location device characterized by, The apparatus includes: an obtaining module configured to obtain an error code of a first service component; a parsing module configured to parse a structure of the error code to obtain a structure coding field of the error code; the structure coding field includes at least a coding field used to represent a service scenario in which the first service component is located; the service scenario is determined by a calling relationship between service components; a first determining module configured to determine the service scenario in which the first service component is located according to the coding field used to represent the service scenario in which the first service component is located; a positioning module configured to locate a faulty service component corresponding to the error code according to the service scenario; wherein the service scenario includes a first scenario, a second scenario and a third scenario; the first scenario is a service scenario without calling of a single service component; the first scenario includes a single service component; in the first scenario, a service component in which an error occurs is the faulty service component; the second scenario is a service scenario with calling of two service components; the second scenario includes an initiator service component and a receiver service component; in the second scenario, when a service component in which an error occurs is not faulty, another service component is the faulty service component; and the third scenario is a service scenario with calling of multiple service components; the third scenario includes an intermediate service component, an upstream service component and a downstream service component; in the third scenario, when a service component in which an error occurs is not faulty, one of the other two service components is the faulty service component.

8. An electronic device, comprising: The device includes a processor and a memory storing computer program instructions; The processor executes the computer program instructions to implement the fault locating method of any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer program instructions; the computer program instructions are executed by a processor to implement the fault locating method of any one of claims 1-6.

10. A computer program product, characterised in that, The instructions in the computer program product are executed by a processor of an electronic device to cause the electronic device to perform the fault locating method of any one of claims 1-6.

Images