Fault analysis method and related apparatus

Abstract

A fault analysis method and a related apparatus, which are applied to the field of microservice architectures. In the present application, first configuration information defined by a requesting end and component configuration information corresponding to related components in the entire data distribution link of a configuration service gateway (e.g., component configuration information of N components) can be acquired, and fault analysis can be performed on the basis of the first configuration information and the component configuration information of the N components. That is, in the present application, a fault in the service gateway can be analyzed on the basis of back-end resources. Alternatively, in the present application, on the basis of an erroneous request and an operation log of a component in the service gateway, a call record corresponding to the erroneous request can be obtained, and then a fault analysis result of the service gateway accessing the request can be obtained on the basis of an error cause in the call record corresponding to the request. In this way, the present application can improve the accuracy of analyzing a fault cause of the service gateway or analyzing a fault cause of a request for accessing the service gateway, does not require a user operation to provide information, and can improve the convenience and timeliness of fault analysis.

Description

A fault analysis method and related apparatus

[0001] This application claims priority to Chinese Patent Application No. 202510220409.2, filed on February 26, 2025, entitled "A Fault Analysis Method and Related Apparatus", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of microservice architecture, and in particular to a fault analysis method and related apparatus. Background Technology

[0003] Microservices architecture (MSA) breaks down a large application into multiple smaller service instances. A service gateway distributes traffic to these instances, and client requests only need to communicate with the gateway, not directly with the individual service instances. In real-world scenarios, the service gateway may fail, causing errors such as 404, 503, and timeouts, rendering the service instances unavailable. Therefore, in a microservices architecture, it's crucial to regularly inspect the service gateway's functionality and analyze the causes of failures to ensure timely resolution and improve system stability.

[0004] Some fault analysis tools can analyze the causes of service gateway failures by using error logs provided by users. This method requires users to manually input a large amount of information, which may lead to user input errors and make it difficult to ensure data consistency. As a result, the accuracy of the fault causes obtained from the analysis is low, and the operation is relatively cumbersome. Summary of the Invention

[0005] This application provides a fault analysis method and related apparatus, which can improve the accuracy of analyzing the causes of faults in service gateways, eliminate the need for user input of information, improve the convenience and timeliness of fault analysis, and enhance the user experience.

[0006] Firstly, this application provides a fault analysis method applied to a fault analysis apparatus. Optionally, the fault analysis apparatus is a standalone device, such as a computing device. Alternatively, the fault analysis apparatus is a module within a computing device, such as a software module and / or a hardware module. It should be understood that the fault analysis apparatus described here is an exemplary execution entity; in specific implementations, the device or module executing the fault analysis method may not be referred to as a fault analysis apparatus. Exemplarily, the method is executed by a fault analysis tool in a service gateway.

[0007] The fault analysis method includes: a fault analysis device acquiring first configuration information from a first service and N component configuration information from N components, where N is an integer and greater than 0. The fault analysis device obtains the fault analysis result of the service gateway based on the first configuration information and the N component configuration information. The N components are associated with the service gateway, each component corresponding to a component configuration information, and the service gateway is used by the requesting end to access the service instance. The first configuration information is defined by the requesting end, and the component configuration information corresponding to each of the N components is obtained from second configuration information provided by the first service, which is based on the first configuration information. The first configuration information and the N component configuration information are used to indicate the configuration of the service gateway. The fault analysis result is used to indicate abnormal components among the N components, where the configuration indicated by the component configuration information of the abnormal component is inconsistent with the configuration indicated by the first configuration information.

[0008] In a microservice architecture, configuration information related to the service gateway needs to be distributed layer by layer from relevant components in the entire data distribution chain (such as the request client, the first service, and N other components) to the service gateway. This enables the service gateway to be configured, and thus allows the request client to access service instances through the service gateway. Throughout the entire data distribution chain, all configuration information related to the service gateway originates from the first configuration information defined by the request client. If, in the entire data distribution chain, the configuration information of a component differs from the configuration information in the first configuration, it may lead to service gateway access failure.

[0009] Therefore, in the above scheme, the fault analysis device can obtain the first configuration information defined by the requesting end and the component configuration information (such as the component configuration information of N components) corresponding to the relevant components in the entire data distribution link of the configuration service gateway. It then performs fault analysis based on the first configuration information and the component configuration information of the N components. That is, the fault analysis device can analyze the service gateway's faults based on backend resources. For example, if the fault analysis device obtains an abnormal component whose configuration indicated by the component configuration information among the N components is inconsistent with the configuration indicated by the first configuration information, this application can consider that the cause of the service gateway's fault is highly likely related to this abnormal component. For example, an error in the configuration indicated by the abnormal component may lead to service gateway access failure. This improves the accuracy of the fault analysis device in analyzing the cause of service gateway faults, eliminates the need for user intervention to provide information, enhances the convenience and timeliness of fault analysis, and improves the user experience.

[0010] In one possible implementation of the first aspect, the fault analysis device obtains the fault analysis result of the service gateway based on first configuration information and N component configuration information, including the following operations: the fault analysis device aligns the data formats of the first configuration information and the N component configuration information to obtain first configuration information and N component configuration information in a first data format. The fault analysis device obtains the fault analysis result of the service gateway based on the first configuration information and the N component configuration information in the first data format.

[0011] Optionally, when the data format of the first configuration information is not the first data format, the fault analysis device adjusts the data format of the first configuration information to the first data format. Further, when the data format of the first component configuration information is not the first data format, the fault analysis device adjusts the data format of the first component configuration information to the first data format, where the first component configuration information is any one of N component configuration information.

[0012] In the above embodiments, the fault analysis device can align the data formats of the first configuration information and the configuration information of N components, so that the fault analysis device can subsequently analyze whether the format-aligned configuration information of the N components is consistent with the first configuration information, thereby obtaining the fault analysis result of the service gateway. Data format alignment facilitates data comparison by the fault analysis device, which can improve the accuracy of the fault analysis device in analyzing the cause of service gateway faults.

[0013] In another possible implementation of the first aspect, the inconsistency between the configuration indicated by the component configuration information corresponding to the abnormal component and the configuration indicated by the first configuration information includes the inconsistency between the component configuration information corresponding to the abnormal component in the first data format and the first configuration information in the first data format, and / or, the component configuration information corresponding to the abnormal component has no data.

[0014] In the above implementation, if the component configuration information corresponding to the abnormal component in the first data format is inconsistent with the first configuration information in the first data format, and / or if the component configuration information corresponding to the abnormal component has no data, the configuration indicated by the abnormal component may be incorrect, thereby causing the service gateway access failure.

[0015] In another possible implementation of the first aspect, the association between the component and the service gateway includes the component belonging to the service gateway.

[0016] Optionally, some components in the entire data delivery chain of the configuration service gateway may be located within the service gateway, such as controller components, messenger components, and proxy components. Alternatively, some components in the entire data delivery chain of the configuration service gateway may not be located within the service gateway but may be connected to it; for example, the application programming interface (API) service component may communicate with the service gateway.

[0017] In another possible implementation of the first aspect, the first configuration information is included in the API request sent by the requesting end to the first service. That is, the API request sent by the requesting end to the first service includes the first configuration information. Optionally, the first configuration information includes routing configuration information, domain name configuration information, and service configuration information.

[0018] In another possible implementation of the first aspect, the N components include an API service component, a controller component, a messenger component, and a proxy component. The first service is further configured to convert the first configuration information into second configuration information and send the second configuration information to the API service component. The API service component is configured to obtain the second configuration information from the first service. The controller component is configured to obtain the second configuration information from the API service component, and the controller component is further configured to convert the data format of the second configuration information into a second data format and send the second configuration information in the second data format to the messenger component. The messenger component is configured to obtain the second configuration information in the second data format from the controller component and send the second configuration information in the second data format to the proxy component. The proxy component is configured to obtain the second configuration information in the second data format from the messenger component.

[0019] The above implementation exemplarily describes the relevant components in the entire data distribution chain of the configuration service gateway, as well as the distribution process of configuration information. When the configuration indicated by the component configuration information corresponding to the relevant component in the data distribution process is inconsistent with the configuration indicated by the first configuration information defined by the requesting end, it may cause the configuration indicated by the abnormal component to be incorrect, thereby leading to service gateway access failure.

[0020] In another possible implementation of the first aspect, the fault analysis method further includes: when the result of the first request from the requesting end is a request error, the fault analysis device sends the fault analysis result of the first request to the requesting end. The first request is used by the requesting end to access a service instance through a service gateway, and the fault analysis result of the first request is related to the fault analysis result of the service gateway.

[0021] When an error occurs in the configuration indicated by an abnormal component, it may cause a service gateway access failure, which in turn may result in an incorrect request from the requesting end. In this case, the fault analysis device can send the fault analysis result of the request to the requesting end. This fault analysis result is related to the fault analysis result of the service gateway. For example, if the result of the first request is a request error, and the fault analysis result of the service gateway indicates that the service gateway failure is related to the abnormal component, the fault analysis result of the first request could be that an error occurred in the configuration of the abnormal component when configuring the service gateway, causing the service gateway to fail, which in turn led to the error in the first request.

[0022] Secondly, this application provides a fault analysis method applied to a fault analysis device. Optionally, the fault analysis device is a standalone device, such as a computing device. Alternatively, the fault analysis device is a module within a computing device, such as a software module and / or a hardware module. It should be understood that the fault analysis device described here is an exemplary execution entity; in specific implementations, the device or module executing the fault analysis method may not be referred to as a fault analysis device. Exemplarily, the method is executed by a fault analysis tool in a service gateway.

[0023] The fault analysis method includes: a fault analysis device obtaining a first call record corresponding to the first request based on the path of the first request, the creation time of the first request path, and the operation log of the first component. The fault analysis device then obtains a fault analysis result for the first request based on the first call record corresponding to the first request. Finally, the fault analysis device sends the fault analysis result of the first request to the requesting end. Here, the first component belongs to the service gateway, and the first request is used by the requesting end to access the service instance through the service gateway. The operation log includes at least one first call record, and the first call record corresponding to the first request belongs to at least one first call record. Each first call record includes the request path, the creation time of the request path, the call result corresponding to the request, and the error reason corresponding to the request. The call result corresponding to the first request is a request error, and the fault analysis result includes the error reason of the first request.

[0024] In the above scheme, the operation log of the first component includes call records corresponding to the requests processed by the service gateway, such as the error reasons corresponding to the requests. Therefore, the fault analysis device can obtain the fault analysis results of the request based on the error reasons in the first call record corresponding to the erroneous request. This improves the accuracy of the fault analysis device in analyzing the fault reasons of requests accessing the service gateway. It eliminates the need for user intervention to provide information, thereby improving the convenience and timeliness of fault analysis and enhancing the user experience.

[0025] In another possible implementation of the second aspect, each first call record further includes an identifier ID of the connection corresponding to the request, the connection including the connection between the requesting end and the first component and / or the connection between the first component and the service instance. The fault analysis device obtains the fault analysis result of the first request based on the first call record corresponding to the first request, including the following operations: The fault analysis device obtains the second call record corresponding to the first request based on the ID of the connection corresponding to the first request and the operation log. The fault analysis device obtains the fault analysis result of the first request based on the second call record corresponding to the first request. The operation log includes at least one second call record, and the second call record corresponding to the first request belongs to at least one second call record. Each second call record includes at least one of the following: information related to the creation of the connection corresponding to the request, information related to the creation of the stream corresponding to the request, and information related to the read / write of the socket corresponding to the request.

[0026] In the above embodiments, the fault analysis device can also obtain the second call record corresponding to the first request based on the ID of the connection corresponding to the first request, and then analyze the fault analysis result of the first request based on the second call record corresponding to the first request. Thus, if the first call record corresponding to the first request does not contain an error reason for the first request, or if the error reason for the first request is inaccurate or unusable, the fault analysis device can use the second call record corresponding to the first request to analyze and obtain the fault analysis result of the first request, ensuring the accuracy and effectiveness of the fault analysis result of the first request and improving the convenience and timeliness of fault analysis. Furthermore, if each second call record includes information related to the creation of the connection corresponding to the request, information related to the creation of the stream corresponding to the request, and information related to the reading and writing of the socket corresponding to the request, the second call record includes the call record of the entire call chain of the request with the error. The fault analysis device can analyze the fault cause of the request and check whether there are problems in the calls of the entire call chain based on the call relationship between the backend resources and the components in the entire call chain, and can also improve the accuracy and comprehensiveness of the fault analysis device in analyzing the fault cause of the service gateway access request.

[0027] In another possible implementation of the second aspect, the call result includes a status code, and a request error includes a status code corresponding to the request not meeting a preset condition.

[0028] For example, the preset condition is that the status code does not meet the 2XX status code, such as 404, 503, etc.

[0029] Thirdly, this application provides a fault analysis apparatus, comprising an acquisition unit and a processing unit, wherein: the acquisition unit is used to acquire first configuration information from a first service and N component configuration information from N components. The N components are associated with a service gateway, each component corresponding to a component configuration information, and the service gateway is used by the requesting end to access a service instance. The first configuration information is defined by the requesting end, and the component configuration information corresponding to each of the N components is obtained from second configuration information provided by the first service, the second configuration information being based on the first configuration information. The first configuration information is used to indicate the configuration of the service gateway, and the N component configuration information is used to indicate the configuration of the service gateway, where N is an integer and N is greater than 0. The processing unit is used to obtain a fault analysis result of the service gateway based on the first configuration information and the N component configuration information. The fault analysis result is used to indicate abnormal components among the N components, where the configuration indicated by the component configuration information corresponding to the abnormal component is inconsistent with the configuration indicated by the first configuration information.

[0030] In one possible implementation of the third aspect, the processing unit is further configured to align the data formats of the first configuration information and the N component configuration information to obtain the first configuration information and the N component configuration information in the first data format. The processing unit is further configured to obtain the fault analysis result of the service gateway based on the first configuration information and the N component configuration information in the first data format.

[0031] In another possible implementation of the third aspect, the inconsistency between the configuration indicated by the component configuration information corresponding to the abnormal component and the configuration indicated by the first configuration information includes the inconsistency between the component configuration information corresponding to the abnormal component in the first data format and the first configuration information in the first data format, and / or, the component configuration information corresponding to the abnormal component has no data.

[0032] In another possible implementation of the third aspect, the association between the component and the service gateway includes the component belonging to the service gateway.

[0033] In another possible implementation of the third aspect, the first configuration information is included in the API request sent by the requesting end to the first service.

[0034] In another possible implementation of the third aspect, the N components include an API service component, a controller component, a messenger component, and a proxy component. The first service is further configured to convert the first configuration information into second configuration information and send the second configuration information to the API service component. The API service component is configured to obtain the second configuration information from the first service. The controller component is configured to obtain the second configuration information from the API service component, and the controller component is further configured to convert the data format of the second configuration information into a second data format and send the second configuration information in the second data format to the messenger component. The messenger component is configured to obtain the second configuration information in the second data format from the controller component and send the second configuration information in the second data format to the proxy component. The proxy component is configured to obtain the second configuration information in the second data format from the messenger component.

[0035] In another possible implementation of the third aspect, the acquisition unit is further configured to send the fault analysis result of the first request to the requesting end if the call result of the first request from the requesting end is a request error. The first request is used by the requesting end to access the service instance through the service gateway, and the fault analysis result of the first request is related to the fault analysis result of the service gateway.

[0036] Fourthly, this application provides a fault analysis apparatus, comprising a processing unit and an acquisition unit, wherein: the processing unit is configured to obtain a first call record corresponding to the first request based on the path of the first request, the creation time of the path of the first request, and the operation log of the first component; the first component belongs to a service gateway; the first request is used by the requesting end to access a service instance through the service gateway; the operation log includes at least one first call record; the first call record corresponding to the first request belongs to at least one first call record; each first call record includes the path of the request, the creation time of the path of the request, the call result corresponding to the request, and the error reason corresponding to the request; the call result corresponding to the first request is a request error. The processing unit is further configured to obtain a fault analysis result of the first request based on the first call record corresponding to the first request; the fault analysis result includes the error reason of the first request. The acquisition unit is configured to send the fault analysis result of the first request to the requesting end.

[0037] In another possible implementation of the fourth aspect, each first call record further includes an identifier ID of the connection corresponding to the request, the connection including the connection between the requesting end and the first component and / or the connection between the first component and the service instance. The processing unit is further configured to obtain a second call record corresponding to the first request based on the ID of the connection corresponding to the first request and the runtime log. The processing unit is further configured to obtain a fault analysis result of the first request based on the second call record corresponding to the first request. The runtime log includes at least one second call record, and the second call record corresponding to the first request belongs to at least one second call record. Each second call record includes at least one of the following: information related to the creation of the connection corresponding to the request, information related to the creation of the stream corresponding to the request, and information related to the read / write operations of the socket corresponding to the request.

[0038] In another possible implementation of the fourth aspect, the call result includes a status code, and a request error includes a status code corresponding to the request not meeting a preset condition.

[0039] Fifthly, this application provides a computing device, which includes a processor and a memory. The memory stores a computer program, and the processor is used to call the computer program stored in the memory to implement the method of any one of the first aspects or any one of the second aspects.

[0040] Sixthly, this application provides a service gateway, which includes the fault analysis apparatus of the third aspect, the fault analysis apparatus of the fourth aspect, or the computing device of the fifth aspect.

[0041] In a seventh aspect, this application provides a readable storage medium for storing a computer program that, when executed by a processor, causes a device including a processor to perform the method of either the first aspect or the second aspect.

[0042] Eighthly, this application provides a computer program product that, when executed by a processor, causes a device including a processor to perform the method of either the first aspect or the second aspect.

[0043] The beneficial effects of the technical solutions provided in aspects three to eight of this application can be referred to the beneficial effects of the technical solutions in aspects one and / or two, and will not be repeated here. Attached Figure Description

[0044] The accompanying drawings used in the description of the embodiments will be briefly introduced below.

[0045] Figure 1 is a schematic diagram of the architecture of a fault analysis system provided in this application;

[0046] Figure 2 is a schematic diagram of the architecture of another fault analysis system provided in this application;

[0047] Figure 3 is a flowchart illustrating a fault analysis method provided in an embodiment of this application;

[0048] Figure 4 is a flowchart illustrating another fault analysis method provided in an embodiment of this application;

[0049] Figure 5 is a structural schematic diagram of a fault analysis device provided in an embodiment of this application;

[0050] Figure 6 is a schematic diagram of another fault analysis device provided in an embodiment of this application;

[0051] Figure 7 is a schematic diagram of the structure of a computing device provided in an embodiment of this application. Detailed Implementation

[0052] Before introducing the embodiments of this application, the terminology that may be used in the embodiments of this application will be introduced first.

[0053] 1. Service Gateway: In a microservice architecture, the service gateway is a crucial component, acting as the unified entry point for external requests (such as clients) to enter the microservice's internal system. For example, the service gateway can route requests; when a request is sent, the service gateway accurately forwards the request to the corresponding service instance based on information such as the target address and request type. For example, the service gateway may include a controller component, a pilot component, and an envoy component. The pilot component monitors events by registering a controller component in Kubernetes, thereby obtaining the relationship between services, Kubernetes resource objects (endpoints), and compute units (pods). The pilot component provides service discovery functionality to the envoy sidecar component, and traffic management functionality for intelligent routing (e.g., A / B testing, canary deployments) and resilience (timeouts, retries, circuit breakers, etc.). Envoy, implemented in C++, is a high-performance network proxy service for service meshes. It runs in parallel with applications, abstracting the network by providing common functionality in a platform-independent manner.

[0054] 2. Routing configuration information, also known as routing rules, is used to define how the service gateway forwards received requests from the requesting end to the backend service instance.

[0055] 3. Domain name configuration information, used to bind domain names to the service gateway, enabling requesting clients to access the service gateway via the domain name, and then the service gateway forwards the requests from the requesting clients to the backend service instances. Optionally, the service gateway can be configured with different routes and policies for different domain names.

[0056] 4. Service configuration information mainly involves how to define and manage backend service instance information in the service gateway, including the service instance address, port, health check, load balancing strategy, etc., to ensure that the service gateway can correctly forward requests from the requesting end to available backend service instances.

[0057] 5.404 is a status code used to indicate that a webpage or resource requested by a requesting party (such as a client) was not found on the server.

[0058] 6.503 is a status code used to indicate that the server is currently unable to process a request from a client, for example, because the server is temporarily overloaded or undergoing maintenance and is unable to provide service to the requesting client.

[0059] 7. The requested path specifies the specific resource on the server to be accessed or the operation to be performed. For example, in an e-commerce system, the requested path for a product list could be / products / list.

[0060] 8. Request-related streams, such as request streams, which are the data streams formed by a series of requests sent by the requesting party to the service instance. Another example is response streams, which are the streams of response data returned by the service instance in response to the requesting party's requests.

[0061] 9. Request the corresponding socket. A socket is a mechanism used in network programming to achieve inter-process communication between different hosts. It is an abstract representation of a network communication endpoint. In the Transmission Control Protocol (TCP) / Internet Protocol (IP) network model, a socket can be seen as a combination of an IP address and a port number. Through sockets, the requesting end (such as a client) and the service instance can establish a connection, send and receive data.

[0062] The terminology explanations provided above may be applied to the embodiments described below.

[0063] In microservice architecture applications, service gateways may fail, causing access errors on the requesting end (such as 404, 503, access timeout, etc.), resulting in service instance unavailability. Therefore, in a microservice architecture, it is necessary to check the functionality of the service gateway and analyze the causes of service gateway failures so that they can be resolved in a timely manner, improving system stability. Some fault analysis tools can analyze the causes of service gateway failures through user-provided error logs. However, this method requires users to manually input a large amount of information, which may lead to user input errors and difficulty in ensuring data consistency, resulting in low accuracy of the analyzed fault causes. Moreover, fault analysis requires users to provide error logs before it can be performed, which lacks timeliness, is cumbersome, inconvenient, and provides a poor user experience.

[0064] In view of this, this application provides a fault analysis method and related apparatus, which can improve the accuracy of analyzing the causes of faults in service gateways, eliminate the need for user input of information, improve the convenience and timeliness of fault analysis, and enhance user experience.

[0065] For ease of understanding, the architecture and business scenarios of the fault analysis system provided in the embodiments of this application are described below. It should be noted that the system architecture and business scenarios described in this application are for the purpose of more clearly illustrating the technical solutions of this application and do not constitute a limitation on the technical solutions provided in this application. It should be understood that as system architectures evolve and new business scenarios emerge, the technical solutions provided in this application are equally applicable to similar technical problems.

[0066] Please refer to Figure 1, which is a schematic diagram of the architecture of a fault analysis system provided in this application. The fault analysis system 10 includes a request terminal 101, a first service 102, a service gateway 104, a service instance 105, and N components (N is an integer and N is greater than 0, for example, the N components include the API service component 103 shown in Figure 1, the controller component 1041, the messenger component 1042, and the proxy component 1043 in the service gateway 104). Figure 1 is illustrated with four components as an example. It should be understood that in actual use, the number of components can be more or less. The following describes the devices included in the fault analysis system 10:

[0067] The requesting client 101 has communication capabilities, such as sending requests to the first service 102 and accessing the service instance 105 through the service gateway 104. For example, the requesting client 101 can be a client application, such as a web application (e.g., a browser-based single-page application), a mobile application (e.g., a Harmony application), etc.

[0068] The first service 102 has communication capabilities. For example, the first service 102 is used to obtain information (such as first configuration information) from the requesting end 101 and send information (such as second configuration information) to the API service component 103. The first and second configuration information are used to indicate the configuration of the service gateway 104. Optionally, the first configuration information includes configuration information such as routing configuration information, domain name configuration information, and service configuration information.

[0069] Furthermore, the first service 102 also has data processing capabilities. For example, the first service 102 is used to obtain an API request from the requesting end 101, the API request including first configuration information, and the first service 102 is used to analyze the obtained API request to obtain the first configuration information. Even more exemplarily, the first service 102 is used to convert the first configuration information into second configuration information. Optionally, the second configuration information can be a Kubernetes custom resource, such as a gateway, destination rule, or virtual service. For example, the first service 102 can be a cloud service, such as Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or Software as a Service (SaaS).

[0070] Service gateway 104 has communication capabilities and is used by requester 101 to access service instance 105. Exemplarily, service gateway 104 is used to obtain information (such as second configuration information) from API service component 103 to configure itself. More exemplaryly, service gateway 104 is used to obtain information (such as a request) from requester 101 and send the information (such as the request) to service instance 105. Service gateway 104 is also used to receive information (such as response information) from service instance 105 and send the information (such as response information) to requester 101.

[0071] Service instance 105 has communication and data processing capabilities. For example, service instance 105 can be a specific running entity of a service. For example, when a service is deployed and started, it exists as one or more instances in a computing environment (such as a server, container, etc.). For instance, a user authentication service can have multiple service instances running simultaneously, each capable of independently handling user authentication requests.

[0072] Optionally, the number of service instances 105 is not limited in this application. Figure 1 is only an example of one service instance. In actual use, the number of service instances 105 can be more, which will not be listed here.

[0073] N components are associated with service gateway 104. These N components are relevant components in the entire data distribution chain. Each of these N components distributes configuration information related to service gateway 104 to proxy component 1043 within service gateway 104 to configure service gateway 104, thereby enabling request client 101 to access service instance 105 through service gateway 104. The following sections describe each of the N components:

[0074] For example, a component being associated with a service gateway includes a component that is not part of the gateway but is connected to it. For instance, some components in the entire data delivery chain of configuring the service gateway may not be located at the service gateway but are connected to it. For example, API service component 103 is not part of service gateway 104 but communicates with it.

[0075] API service component 103 has communication capabilities, such as a Kubernetes API server component. For example, API service component 103 is used to obtain information (such as second configuration information) from a first service 102.

[0076] As another example, the association between a component and a service gateway includes the component belonging to the gateway. For instance, some components in the entire data delivery chain of configuring the service gateway may be located in the service gateway, such as controller component 1041, messenger component 1042, and agent component 1043 belonging to service gateway 104.

[0077] The controller component 1041 (also referred to as the controller component 1041) has communication and data processing capabilities. For example, the controller component 1041 is used to obtain second configuration information from the API service component 103, convert the data format of the second configuration information into a second data format, and send the second configuration information in the second data format to the messenger component 1042. For instance, the controller component 1041 can obtain the second configuration information from the API service component 103 through reconcile, converting the second configuration information into second configuration information in the data format of the proxy component (which may be referred to as the Envoy data format for convenience). As another example, the controller component 1041 can send the second configuration information in the Envoy data format to the messenger component 1042 through some service discovery (x discovery service, xDS) protocol. xDS is a set of protocols for dynamically configuring Envoy agents, including Listener Discovery Service (LDS), Route Discovery Service (RDS), Cluster Discovery Service (CDS), and Endpoint Discovery Service (EDS).

[0078] Messenger component 1042 (also referred to as pilot component 1042) has communication capabilities. Exemplarily, messenger component 1042 is used to obtain second configuration information in a second data format from controller component 1041 and send the second configuration information in the second data format to agent component 1043. For example, the pilot component can receive second configuration information in Envoy data format from controller component 1041 via the xDS protocol and send the second configuration information in Envoy data format to agent component 1043 via the xDS protocol.

[0079] The proxy component 1043 (also referred to as the Envoy component 1043) has communication and data processing capabilities. For example, the proxy component 1043 is used to obtain second configuration information in a second data format from the messenger component 1042, thereby activating the configuration of the service gateway 104. Thus, the requesting client 101 can send a service request to the service gateway 104. The service request received by the service gateway 104, after passing through the proxy component 1043, can be forwarded by the proxy component 1043 according to the activated configuration of the service gateway 104 (such as configuring the routing configuration information of the service gateway 104), for example, forwarding it to the service instance 105, thereby enabling the requesting client 101 to access the service instance 105 through the service gateway 104.

[0080] Optionally, the fault analysis system 10 may also include a database 106 for storing information (such as first configuration information) obtained by the first service 102 from the requesting end 101.

[0081] The service gateway 104 also includes a fault analysis device 1044, which has communication and data processing capabilities, such as a fault analysis tool or fault diagnosis tool within the service gateway 104. Exemplarily, the fault analysis device 1044 is used to obtain first configuration information from the first service 102 and N component configuration information from N components. Each component corresponds to one component configuration information. The component configuration information corresponding to each of the N components is obtained from second configuration information provided by the first service (e.g., the component configuration information of the messenger component 1042 is second configuration information in a second data format, obtained based on the second configuration information), and the second configuration information is obtained based on the first configuration information (e.g., the first service 102 can convert the first configuration information into second configuration information). The first configuration information is used to indicate the configuration of the service gateway 104, and the N component configuration information is used to indicate the configuration of the service gateway 104, where N is an integer and N is greater than 0. As one possible implementation, the fault analysis device 1044 can be a software module, such as a Huawei Cloud Microservice Engine (CSE) virtual machine, software, program code, or container.

[0082] For example, the N components include an API service component 103, a controller component 1041, a messenger component 1042, and a proxy component 1043. The fault analysis device 1044 is interconnected with each of the N components, and can obtain component configuration information from each component through the connection with each component. As another example, the fault analysis device 1044 is used to obtain a fault analysis result for the service gateway 104 based on the first configuration information and the configuration information of the N components. The fault analysis result is used to indicate abnormal components among the N components, where the configuration indicated by the component configuration information of the abnormal component is inconsistent with the configuration indicated by the first configuration information.

[0083] In the fault analysis system shown in Figure 1, relevant components in the entire data distribution chain (such as requester 101, first service 102, API service component 103, controller component 1041, and messenger component 1042) are used to distribute configuration information related to service gateway 104 to proxy component 1043 in service gateway 104 to configure service gateway 104, thereby enabling requester 101 to access service instance 105 through service gateway 104. During this data distribution process, if the configuration of service gateway 104 indicated by a component is inconsistent with the configuration of service gateway 104 defined by the requester, it may lead to service gateway 104 access failure. In this application, the fault analysis device 1044 obtains the first configuration information defined by requester 101 and the component configuration information (such as the component configuration information of N components) corresponding to the relevant components in the entire data distribution chain configuring service gateway 104, and performs fault analysis based on the first configuration information and the component configuration information of the N components, that is, it analyzes the fault of service gateway based on backend resources. This improves the accuracy of fault analysis devices in identifying the causes of faults in service gateways, eliminates the need for user intervention to provide information, enhances the convenience and timeliness of fault analysis, and improves the user experience.

[0084] Of course, the above description is based on the example of the fault analysis device 1044 being located in the service gateway 104. In some solutions, the fault analysis device 1044 can be a physical device located outside the service gateway 104, such as a server, cloud, or host, and the physical device located outside the vehicle communicates and transmits information with the service gateway.

[0085] Please refer to Figure 2, which is a schematic diagram of the architecture of another fault analysis system provided in this application. The fault analysis system 20 includes a request terminal 201, a service gateway 202, and a service instance 203. The devices included in the fault analysis system 20 are described below:

[0086] The requesting client 201 has communication capabilities, such as sending requests (e.g., Hypertext Transfer Protocol (HTTP) requests) to the service gateway 202 to access the service instance 203. For example, the requesting client 201 can be a client application, such as a web application (e.g., a browser-based single-page application), a mobile application (e.g., a Harmony application), etc.

[0087] Service gateway 202 has communication capabilities and is used by requester 201 to access service instance 203. For example, service gateway 202 is used to obtain a request (such as an HTTP request) from requester 201, and send the request (such as an HTTP request) to service instance 203 specified by the configuration information corresponding to the request, thereby enabling requester 201 to access service instance 203. Further exemplarily, service gateway 202 is also used to receive information (such as response information) from service instance 203 and send information (such as response information) to requester 201.

[0088] The service gateway 202 includes a first component 2021 and a fault analysis device 2022. The devices included in the service gateway are described below:

[0089] The first component 2021 has communication and data processing capabilities, such as an Envoy component. For example, the first component 2021 is used to obtain service requests from the requesting end 201. After the service gateway 202 receives the service request, it can be forwarded by the first component 2021 according to the configuration of the service gateway 104 corresponding to the requesting end 201, for example, forwarded to the service instance 203, thereby enabling the requesting end 201 to access the service instance 203 through the service gateway 202.

[0090] The fault analysis device 2022 has communication and data processing capabilities. For example, the fault analysis device 2022 is used to obtain a first call record corresponding to the first request based on the path of the first request, the creation time of the first request path, and the operation log of the first component 2021. The first request is used by the requesting end 201 to access the service instance 203 through the service gateway 202. The operation log includes at least one first call record, and the first call record corresponding to the first request belongs to at least one first call record. Each first call record includes the request path, the creation time of the request path, the call result corresponding to the request, and the error reason corresponding to the request. Further exemplarily, the fault analysis device 2022 is also used to obtain a fault analysis result of the first request based on the first call record corresponding to the first request, and send the fault analysis result of the first request to the requesting end 201. The call result corresponding to the first request is a request error, and the fault analysis result includes the error reason of the first request.

[0091] In the fault analysis system shown in Figure 2, when the requesting end 201 sends a first request to the service gateway 202 to access the service instance 203 through the service gateway 202, the first component 2021 in the service gateway 202 records the first call record corresponding to the first request. If the call result of the first request is a request error, it is necessary to analyze the cause of the first request's failure (error reason) so that the failure can be resolved in a timely manner, improving system stability. In this application, the fault analysis device 2022 can obtain the first call record corresponding to the erroneous request based on the erroneous request and the operation log of the first component 2021, and then obtain the fault analysis result of the request based on the error reason in the first call record corresponding to the request. This improves the accuracy of the fault analysis device in analyzing the fault reasons of requests to access the service gateway, eliminates the need for user input, enhances the convenience and timeliness of fault analysis, and improves user experience.

[0092] Of course, the above description is based on the example of the fault analysis device 2022 being located at the service gateway 202. In some solutions, the fault analysis device 2022 can be a physical device located outside the service gateway 202, such as a server, cloud, or host, and the physical device located outside the vehicle communicates and transmits information with the service gateway.

[0093] The architecture of the fault analysis system of this application has been introduced above. The fault analysis method provided by this application will be introduced below.

[0094] Please refer to Figure 3, which is a flowchart illustrating a fault analysis method provided in an embodiment of this application. Optionally, this method can be applied to a fault analysis system, such as the fault analysis system 10 shown in Figure 1, for example, implemented by the fault analysis device 1044 shown in Figure 1. For ease of understanding, the following description uses a fault analysis device as the executing entity.

[0095] The fault analysis method shown in Figure 3 may include steps S301 to S302. Steps S301 to S302 are detailed below:

[0096] Step S301: The fault analysis device obtains the first configuration information from the first service and the N component configuration information from the N components.

[0097] The fault analysis device has communication and data processing capabilities and can be located in the service gateway, such as the fault analysis device 1044 shown in Figure 1. Optionally, the fault analysis device can be a fault analysis tool or a fault diagnosis tool in the service gateway.

[0098] The first service has communication capabilities, and the first service is, for example, the first service 102 shown in Figure 1. Optionally, the first service may be a cloud service, such as Platform as a Service (PaaS) or Software as a Service (SaaS). For example, the first service is connected to a fault analysis device.

[0099] The first configuration information is used to indicate the configuration of the service gateway. In one possible implementation, the first configuration information is defined by the requesting end. For example, the first service may obtain an API request from the requesting end, the API request including the first configuration information, and the first service may analyze the obtained API request to obtain the first configuration information. Optionally, the first configuration information includes configuration information such as routing configuration information, domain name configuration information, and service configuration information.

[0100] A service gateway is used by requesting clients to access service instances. For example, a service gateway can receive requests from requesting clients and send them to service instances, thereby enabling requesting clients to access service instances. A service gateway can also receive response information from service instances and send response information to the requesting clients.

[0101] N components are associated with the service gateway, where N is an integer and greater than 0. For example, an association between a component and the service gateway includes the component belonging to the gateway. For instance, some components in the entire data delivery chain configuring the service gateway may be located within the service gateway, such as the controller component, messenger component, and proxy component. As another example, an association between a component and the service gateway includes the component not belonging to the gateway but being connected to it. For instance, some components in the entire data delivery chain configuring the service gateway may not be located within the service gateway but are connected to it, such as the API service component not belonging to the service gateway but communicating with it.

[0102] Each component corresponds to a component configuration information, and the N component configuration information is used to indicate the configuration of the service gateway. For example, the N components include API service components (such as Kubernetes API server components), controller components, messenger components (pilot components), and proxy components (envoy components). The N component configuration information includes the component configuration information corresponding to the API service component, the controller component, the messenger component, and the proxy component.

[0103] In one possible implementation, the component configuration information corresponding to each of the N components is obtained from the second configuration information provided by the first service. For example, the N components include an API service component, a controller component, a messenger component, and a proxy component. Exemplarily, the first service sends the second configuration information to the API service component, and the API service component receives the second configuration information from the first service; that is, the component configuration information corresponding to the API service component is the second configuration information.

[0104] For another example, the controller component obtains the second configuration information from the API service component; that is, the component configuration information corresponding to the controller component is the second configuration information. For another example, the controller component converts the data format of the second configuration information into a second data format and sends the second configuration information in the second data format to the messenger component; that is, the component configuration information corresponding to the controller component is the second configuration information in the second data format. Optionally, the second data format can be a proxy component data format, such as the Envoy data format. For example, the controller component is a controller component. The controller component can obtain the second configuration information from the API service component through reconcile, convert the second configuration information into the Envoy data format, and send the Envoy data format second configuration information to the messenger component via the xDS protocol.

[0105] As another example, the messenger component receives second configuration information in a second data format from the controller component and sends the second configuration information in a second data format to the agent component. That is, the component configuration information corresponding to the messenger component is the second configuration information in the second data format. For example, the messenger component is a pilot component, and the pilot component can send the second configuration information in Envoy data format to the agent component via the xDS protocol.

[0106] For another example, the proxy component receives second configuration information in a second data format from the messenger component, thereby activating the service gateway's configuration; that is, the component configuration information corresponding to the proxy component is the second configuration information in the second data format. For example, the requesting end can send a service request to the service gateway. The service request received by the service gateway, after passing through the proxy component, can be forwarded by the proxy component according to the activated service gateway's configuration, for example, forwarded to a service instance.

[0107] In one possible implementation, the second configuration information is obtained based on the first configuration information. For example, the first service can transform the first configuration information into the second configuration information. For instance, the second configuration information is a Kubernetes custom resource, such as Gateway, DestinationRule, VirtualService, etc.

[0108] In one possible implementation, the fault analysis device is connected to a first service, and the fault analysis device can obtain first configuration information from the first service through the connection between the fault analysis device and the first service.

[0109] In another possible implementation, the fault analysis device is connected to a database (e.g., a communication connection). The database is used to store information obtained from the requesting end by the first service, such as first configuration information. That is, the database stores the first configuration information, and the fault analysis device can obtain the first configuration information from the first service through the connection between the fault analysis device and the database.

[0110] In one possible implementation, the fault analysis device is interconnected with each of the N components, and the fault analysis device can obtain the configuration information of the N components from the N components through the connection between the fault analysis device and each of the N components.

[0111] For example, the N components include an API service component. The fault analysis device is connected to the API service component (e.g., through a communication connection). The fault analysis device can obtain component configuration information of the API service component from the API service component through the connection between the fault analysis device and the API service component. For example, the component configuration information of the API service component is second configuration information (e.g., a Kubernetes custom resource), and the fault analysis device can obtain this second configuration information.

[0112] As another example, the N components include a controller component (such as a controller component). The fault analysis device is connected to the controller component, and the fault analysis device can obtain the component configuration information of the controller component from the controller component through the connection between the fault analysis device and the controller component. For example, the fault analysis device can call an operation and maintenance interface (such as the configuration configz interface) to obtain the component configuration information of the controller component (such as second configuration information or second configuration information in Envoy data format).

[0113] As another example, the N components include a messenger component (such as a pilot component), and the fault analysis device is connected to the messenger component. The fault analysis device can obtain the component configuration information of the messenger component from the messenger component through the connection between the fault analysis device and the messenger component. For example, the fault analysis device can call an operation and maintenance interface (such as the configz interface) to obtain the component configuration information of the messenger component (such as the second configuration information in Envoy data format).

[0114] For another example, the N components include a proxy component (such as an Envoy component). The fault analysis device is connected to the proxy component, and the fault analysis device can obtain the component configuration information of the proxy component from the proxy component through the connection between the fault analysis device and the proxy component. For example, the fault analysis device can call the operation and maintenance interface (such as the configuration config_dump interface) to obtain the component configuration information of the proxy component (such as the second configuration information in Envoy data format).

[0115] Step S302: The fault analysis device obtains the fault analysis results of the service gateway based on the first configuration information and the configuration information of N components.

[0116] The fault analysis results of the service gateway are used to indicate abnormal components among N components. The configuration information of the abnormal component is inconsistent with the configuration information of the first configuration information.

[0117] In this application, relevant components in the entire data distribution chain (such as the requesting end, the first service, and N components (such as the API service component, the controller component, and the messenger component)) are used to distribute configuration information related to the service gateway to the service gateway (such as the proxy component in the service gateway) layer by layer to implement the service gateway configuration, thereby enabling the requesting end to access the service instance through the service gateway. During this data distribution process, all configuration information related to the service gateway originates from the first configuration information defined by the requesting end. If the service gateway configuration indicated by the component configuration information of a component is inconsistent with the service gateway configuration defined by the requesting end, it may lead to service gateway access failure. Therefore, this application considers analyzing the cause of service gateway failure based on the backend configuration resources to obtain failure analysis results.

[0118] The fault analysis device may obtain the fault analysis results of the service gateway in several possible ways. Two possible implementations are described below:

[0119] Implementation 1: The configuration indicated by the component configuration information corresponding to the abnormal component is inconsistent with the configuration indicated by the first configuration information, including the component configuration information corresponding to the abnormal component in the first data format being inconsistent with the first configuration information in the first data format.

[0120] For example, the fault analysis device can align the data formats of the first configuration information and the configuration information of N components to obtain the first configuration information and the N component configuration information in the first data format. For instance, if the data format of the first configuration information is not the first data format, the fault analysis device adjusts the data format of the first configuration information to the first data format. If the data format of the first component configuration information is not the first data format, the fault analysis device adjusts the data format of the first component configuration information to the first data format, where the first component configuration information is any one of the N component configuration information. The first data format is the data format corresponding to a specific component among the N components (such as the Envoy data format, the data format corresponding to a Kubernetes custom resource, etc.). Taking the Envoy data format as an example, if the data format of the first configuration information is not the Envoy data format, the fault analysis device adjusts the data format of the first configuration information to the Envoy data format to obtain the first configuration information in the Envoy data format. For example, N components include an API service component. The component configuration information of the API service component is the second configuration information (such as a Kubernetes custom resource). The data format of the second configuration information is not the Envoy data format. The fault analysis device adjusts the data format of the second configuration information to the Envoy data format to obtain the second configuration information in the Envoy data format.

[0121] Further, the fault analysis device obtains the fault analysis result of the service gateway based on the first configuration information of the first data format and the configuration information of N components of the first data format. For example, the fault analysis device can obtain abnormal components based on the first configuration information of the first data format and the configuration information of N components of the first data format, and then obtain the fault analysis result of the service gateway. For instance, the fault analysis device determines, based on the first configuration information of the first data format, whether there is any component configuration information of the first data format that is inconsistent with the first configuration information of the first data format. The fault analysis device records the component corresponding to the inconsistent component configuration information of the first data format as an abnormal component, that is, the component configuration information corresponding to the abnormal component is inconsistent with the first configuration information of the first data format. As another example, the fault analysis device obtains the fault analysis result of the service gateway based on the abnormal component, for example, the fault analysis result of the service gateway is "The service gateway access failure is caused by an error in the configuration of the service gateway indicated by component A during the configuration of the service gateway." Optionally, the fault analysis result of the service gateway also includes repair suggestions, which include suggestions for resolving the service gateway failure problem. For example, if the service gateway's fault analysis result is "The service gateway access failure is caused by an error in the configuration of the service gateway indicated by component A during the configuration of the service gateway", the service gateway's repair suggestion could be "It is recommended that the requesting party redefine the service gateway's configuration information".

[0122] Implementation 2: The configuration indicated by the component configuration information corresponding to the abnormal component is inconsistent with the configuration indicated by the first configuration information, including the absence of data in the component configuration information corresponding to the abnormal component.

[0123] For example, the fault analysis device can obtain abnormal components based on the first configuration information and the configuration information of N components, and then obtain the fault analysis result of the service gateway. For instance, the fault analysis device determines, based on the first configuration information and the configuration information of N components, whether there are component configuration information without data among the N component configuration information, that is, whether there are components among the N components that have not received configuration information. If there are component configuration information without data among the N component configuration information, the fault analysis device records the component corresponding to the component configuration information without data as an abnormal component, that is, the component configuration information corresponding to the abnormal component has no data. Further, the fault analysis device obtains the fault analysis result of the service gateway based on the abnormal components, for example, the fault analysis result of the service gateway is "The service gateway access failure is caused by an abnormal component that did not receive the configuration information for configuring the service gateway during configuration". Optionally, the fault analysis result of the service gateway also includes repair suggestions, which include suggestions for resolving the service gateway failure problem. For example, if the fault analysis result of the service gateway is "The service gateway access failure is caused by an abnormal component that did not receive the configuration information for configuring the service gateway during configuration", the repair suggestion for the service gateway may be "It is recommended that the requesting end redefine the configuration information of the service gateway".

[0124] In the above possible implementations, the fault analysis device can assume that the cause of the service gateway failure is highly likely to be related to abnormal components. For example, if the abnormal component indicates an error in the configuration or fails to receive the configuration information for configuring the service gateway, it may cause the service gateway access failure. By performing fault analysis through the above possible implementations, the fault analysis device can improve the accuracy of analyzing the cause of the service gateway failure. It does not require user operation to provide information, which can improve the convenience and timeliness of fault analysis and enhance the user experience.

[0125] In one possible implementation, the requesting client can send a first request to the service gateway. Upon receiving the first request, the service gateway forwards it to the service instance corresponding to the first request, enabling the requesting client to access the service instance through the service gateway. If the result of the first request from the requesting client is a request error, the fault analysis device can send a fault analysis result of the first request to the requesting client. This fault analysis result includes the cause of the first request's failure (or the reason for the error), and is related to the fault analysis result of the service gateway. For example, the fault analysis result of the first request might be "The service gateway access failure is caused by an abnormal component in the requesting client's service gateway configuration, resulting in a request error." Optionally, the fault analysis result of the first request may also include repair suggestions, which include recommendations to resolve the error issue in the first request. For example, if the fault analysis result of the first request is "The service gateway access failure is caused by an abnormal component in the requesting client's service gateway configuration, resulting in a request error," the corresponding repair suggestion might be "It is recommended that the requesting client redefine the service gateway's configuration information."

[0126] In the embodiment shown in Figure 3, the fault analysis device can obtain the first configuration information defined by the requesting end and the component configuration information (such as the component configuration information of N components) corresponding to the relevant components in the entire data distribution link of the configuration service gateway. It then performs fault analysis based on the first configuration information and the component configuration information of the N components. That is, the fault analysis device can analyze the service gateway's faults based on backend resources. For example, if the fault analysis device obtains an abnormal component whose configuration indicated by the component configuration information among the N components is inconsistent with the configuration indicated by the first configuration information, this application can consider that the cause of the service gateway's fault is highly likely related to this abnormal component. For example, an error in the configuration indicated by the abnormal component may lead to service gateway access failure. This improves the accuracy of the fault analysis device in analyzing the cause of service gateway faults, eliminates the need for user intervention to provide information, enhances the convenience and timeliness of fault analysis, and improves the user experience.

[0127] Please refer to Figure 4, which is a flowchart illustrating another fault analysis method provided in an embodiment of this application. Optionally, this method can be applied to a fault analysis system, such as the fault analysis system 20 shown in Figure 2, for example, implemented by the fault analysis device 2022 shown in Figure 2. For ease of understanding, the following description uses the fault analysis device as the executing entity.

[0128] The fault analysis method shown in Figure 4 may include steps S401 to S403. Steps S401 to S403 are detailed below:

[0129] Step S401: The fault analysis device obtains the first call record corresponding to the first request based on the path of the first request, the creation time of the path of the first request, and the operation log of the first component.

[0130] The fault analysis device has communication and data processing capabilities and can be located in the service gateway, such as the fault analysis device 2022 shown in Figure 2. Optionally, the fault analysis device can be a fault analysis tool or a fault diagnosis tool in the service gateway.

[0131] A service gateway is used by requesting clients to access service instances. For example, a requesting client can establish a connection with the service gateway (referred to as a downstream connection for ease of description), and send a request (such as an HTTP request) to the service gateway through this downstream connection. The service gateway can receive the request from the requesting client and, based on the configuration information corresponding to the request, establish a connection between the service gateway and the service instance specified in the configuration information (referred to as an upstream connection for ease of description), and send the request to the service instance through this upstream connection, thereby enabling the requesting client to access the service instance. The service gateway can also receive response information from the service instance and send response information to the requesting client.

[0132] The first component belongs to the service gateway and has communication and data processing capabilities, such as a proxy component (Envoy component) in the service gateway. For example, the first component is used to obtain service requests from the requesting end. After the service gateway receives the service request, it passes through the first component and can be forwarded by the first component according to the configuration of the service gateway corresponding to the requesting end, such as forwarding it to the service instance, thereby enabling the requesting end to access the service instance through the service gateway.

[0133] The first request is used by the requesting end to access the service instance through the service gateway. For example, the first request is an HTTP request.

[0134] The runtime log of the first component includes call records corresponding to requests processed by the service gateway. For example, the runtime log includes at least one first call record, and the first call record corresponding to the first request belongs to at least one first call record. Each first call record includes the request path, the creation time of the request path, the call result corresponding to the request, and the error reason corresponding to the request. For example, the runtime log can be the runtime log of the Envoy component, which can be called envoy.log.

[0135] The result of the first request is a request error (or request failure). In one possible implementation, the result includes a status code, and a request error includes a status code that does not meet a preset condition. For example, the preset condition is that the status code does not meet the 2XX status code, such as 404, 503, etc.

[0136] For example, the fault analysis device can obtain the first call record corresponding to the first request based on the path of the first request, the creation time of the path of the first request, and the operation log of the first component. That is, the fault analysis device can obtain the first call record corresponding to the request whose call result is an error based on the path of the request whose call result is an error, the creation time of the path of the request whose call result is an error, and the operation log of the first component.

[0137] To facilitate understanding, the following table 1 provides an example of the first call record corresponding to a request in the runtime log.

[0138] Table 1

[0139] According to Table 1, the status code for request 1 is 503, meaning the result of the call for request 1 is an error; the status code for request 2 is 404, meaning the result of the call for request 2 is an error; the status code for request 3 is 404, meaning the result of the call for request 3 is an error; and the status code for request 4 is 200, meaning the result of the call for request 4 is normal (or successful).

[0140] If the call result corresponding to the first request is a request error, then according to Table 1, the first request includes request 1, request 2, and request 3. Taking request 1 as the first request as an example, the fault analysis device obtains the first call record corresponding to request 1 based on the path of request 1 (i.e., Path1), the creation time of the path of request 1 (i.e., Time1), and the operation log of the first component, including Path1, Time1, status code 503, and error reason 1.

[0141] In one possible implementation, the fault analysis device can obtain the access record of the first request based on the access log of the first component. The access log includes at least one access record, and the access record corresponding to the first request belongs to at least one access record. Each access record includes the requested path, the creation time of the requested path, and the call result corresponding to the request. Thus, the fault analysis device can obtain the path of the first request and the creation time of the first request path based on the access log of the first component. For example, the access log can be the access log of the Envoy component, and can be called access.log.

[0142] To facilitate understanding, the following table 2 provides examples of some access records corresponding to requests in the access logs.

[0143] Table 2

[0144] If the call result corresponding to the first request is a request error, then according to Table 2, the first request includes request 1, request 2 and request 3. Taking request 1 as the first request, the fault analysis device can obtain the access record of request 1 according to the access log of the first component, including the path of request 1 (i.e., Path1), the creation time of the path of request 1 (i.e., Time1), and the status code 503 of request 1. Then the fault analysis device can obtain the path of request 1 (i.e., Path1) and the creation time of the path of request 1 (i.e., Time1).

[0145] Step S402: The fault analysis device obtains the fault analysis result of the first request based on the first call record corresponding to the first request.

[0146] The fault analysis results include the cause of the error in the first request.

[0147] Referring to Table 1, taking request 1 as an example, the first call record corresponding to request 1 includes Path 1, Time 1, status code 503, and error reason 1. Based on the first call record corresponding to request 1, the fault analysis device can obtain the error reason of request 1, i.e., error reason 1, and thus obtain the fault analysis result of request 1. For example, the fault analysis result of request 1 includes error reason 1.

[0148] In one possible implementation, the error reason corresponding to the first request is not found in the first call record corresponding to the first request, or the error reason corresponding to the first request in the first call record corresponding to the first request is inaccurate or unusable. In this case, the fault analysis device needs to obtain the fault analysis result of the first request based on other information.

[0149] For example, each first call record also includes an identifier ID of the connection corresponding to the request. The connection includes the connection between the requesting end and the first component (or service gateway) (i.e., the downstream connection) and / or the connection between the first component (service gateway) and the service instance (i.e., the upstream connection). The fault analysis device can obtain the second call record corresponding to the first request based on the ID of the connection corresponding to the first request and the operation log. The operation log includes at least one second call record, and the second call record corresponding to the first request belongs to at least one second call record. Each second call record includes at least one of the following: information related to the creation of the connection corresponding to the request, information related to the creation of the stream corresponding to the request, and information related to the read / write operations of the socket corresponding to the request.

[0150] To facilitate understanding, the following examples, in conjunction with Table 3, illustrate some of the first and second call records corresponding to requests in the runtime logs.

[0151] Table 3

[0152] The call result corresponding to the first request is a request error. Referring to Table 3, the first request includes request 1, request 2, and request 3. Table 3 does not contain the error reason for request 3. The fault analysis device can obtain the second call record corresponding to request 3 based on the connection ID (i.e., connection ID 3) and the operation log of the first component. This record includes information related to the creation of the connection corresponding to request 3, information related to the creation of the stream corresponding to request 3, and information related to the read / write operations of the socket corresponding to request 3.

[0153] Furthermore, the fault analysis device obtains the fault analysis result of the first request based on the second call record corresponding to the first request. For example, referring to Table 3, the fault analysis device can obtain the fault analysis result of request 3 based on the second call record corresponding to request 3, namely, the information related to the creation of the connection corresponding to request 3, the information related to the creation of the stream corresponding to request 3, and the information related to the reading and writing of the socket corresponding to request 3.

[0154] For example, the fault analysis device can analyze the second call record corresponding to the first request and find that the buffer of the connection corresponding to the first request is full, causing the first request to report an error. The fault analysis result of the first request could be "The first request reported an error because the buffer of the connection corresponding to the first request is full." As another example, the fault analysis device can analyze the second call record corresponding to the first request and find that the connection response time of the first request exceeds a preset time threshold, causing a socket timeout, which in turn causes the first request to report an error. The fault analysis result of the first request could be "The first request reported an error because the connection response time of the first request exceeds a preset time threshold, causing a socket timeout. It is recommended to resolve the slow response of the service instance of the upstream connection to the service gateway." Thus, if the error reason for the first request is not found in the first call record, or if the error reason is inaccurate or unusable, the fault analysis device can use the second call record corresponding to the first request to obtain the fault analysis result of the first request, ensuring the accuracy and effectiveness of the fault analysis result and improving the convenience and timeliness of fault analysis.

[0155] Optionally, the second call record may also include the ID of the thread to which the connection corresponds and / or the ID of the stream to which the request corresponds (such as stream id), in order to facilitate the analysis of the relevant call information of the thread to which the connection corresponds and the relevant information of the stream to which the request corresponds.

[0156] Optionally, if each second call record includes information related to the creation of the connection corresponding to the request, information related to the creation of the stream corresponding to the request, and information related to the read / write of the socket corresponding to the request, the second call record includes the call record of the entire call chain of the request that reported an error. In this way, the fault analysis device can analyze the cause of the request failure and investigate whether there are problems with the entire call chain based on the call relationship between backend resources and components in the entire call chain. This also improves the accuracy and comprehensiveness of the fault analysis device in analyzing the cause of failures in service gateway access requests.

[0157] Step S403: The fault analysis device sends the fault analysis result of the first request to the requesting end.

[0158] Accordingly, the requesting end can obtain the fault analysis results of the first request from the fault analysis device, thereby obtaining the error reason of the first request.

[0159] Optionally, the fault analysis results for the first request may also include remediation suggestions, which may include recommendations for resolving the request error issue. For example, if the error cause for the first request is "the socket timeout caused by the connection response time exceeding the preset duration threshold, resulting in a request error," the corresponding remediation suggestion could be "it is recommended to resolve the issue of slow response from the service instance of the upstream connection to the service gateway." As another example, if the error cause for the first request is "the socket timeout caused by the connection response time exceeding the preset duration threshold, resulting in a request error," the corresponding remediation suggestion could also be "it is recommended to resolve the issue of slow response from the service instance of the upstream connection to the service gateway."

[0160] In the embodiment shown in Figure 4, the fault analysis device can obtain the call record corresponding to the erroneous request based on the erroneous request and the operation log of the components in the service gateway. Then, it can obtain the fault analysis result of the request based on the error cause in the first call record corresponding to the request. This improves the accuracy of the fault analysis device in analyzing the fault cause of requests accessing the service gateway, eliminates the need for user intervention to provide information, enhances the convenience and timeliness of fault analysis, and improves the user experience.

[0161] The method embodiments of this application have been described above. The apparatus of the embodiments of this application will be described below.

[0162] It should be understood that the division of units in the apparatus provided in the embodiments of this application is only a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Whether a certain function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this application.

[0163] For example, the units in the device can be implemented by a processor calling software. For example, the device includes a processor connected to a memory that stores instructions. The processor calls the instructions stored in the memory to implement any of the above methods or to implement the functions of the units in the device. The processor is, for example, a general-purpose processor, such as a central processing unit (CPU) or a microprocessor, and the memory is either internal or external to the device.

[0164] Alternatively, the units in the device can be implemented as hardware circuits. The functionality of some or all of the units can be achieved through the design of these hardware circuits, which can be understood as one or more processors. For example, in one implementation, the hardware circuit is an application-specific integrated circuit (ASIC). The functionality of some or all of the above units is achieved through the design of the logical relationships between the components within the circuit. In another implementation, the hardware circuit can be implemented using a programmable logic device (PLD). Taking a field-programmable gate array (FPGA) as an example, it can include a large number of logic gates. The connection relationships between the logic gates are configured through a configuration file, thereby achieving the functionality of some or all of the above units.

[0165] In some solutions, the functional modules of the device can be divided according to the aforementioned methods. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one module. The integrated modules can be implemented in hardware or as software functional modules. It should be noted that the module division in this embodiment is illustrative and represents only one logical functional division; in actual implementation, other division methods may be used.

[0166] Several possible devices are listed below.

[0167] Please refer to Figure 5, which is a schematic diagram of a fault analysis device provided in an embodiment of this application. The fault analysis device 50 can be a standalone device or a module within a standalone device. The fault analysis device 50 includes an acquisition unit 501 and a processing unit 502. The acquisition unit 501 is used to perform one or more operations such as acquisition, reception, listening, transmission, and sending, while the processing unit 502 is used to perform one or more operations such as processing, calculation, determination, generation, and updating.

[0168] In some possible designs, the acquisition unit 501 is used to acquire first configuration information from the first service and N component configuration information from N components. The N components are associated with a service gateway, each component corresponding to a component configuration information, and the service gateway is used by the requesting end to access the service instance. The first configuration information is defined by the requesting end, and the component configuration information corresponding to each of the N components is obtained from second configuration information provided by the first service, which is based on the first configuration information. The first configuration information and the N component configuration information are used to indicate the configuration of the service gateway, where N is an integer and greater than 0. The processing unit 502 is used to obtain a fault analysis result of the service gateway based on the first configuration information and the N component configuration information. The fault analysis result is used to indicate abnormal components among the N components, where the configuration indicated by the component configuration information of the abnormal component is inconsistent with the configuration indicated by the first configuration information.

[0169] In some other possible designs, the processing unit 502 is further configured to align the data formats of the first configuration information and the N component configuration information to obtain the first configuration information and the N component configuration information in the first data format. The processing unit 502 is also configured to obtain the fault analysis results of the service gateway based on the first configuration information and the N component configuration information in the first data format.

[0170] In some other possible designs, the configuration indicated by the component configuration information corresponding to the abnormal component is inconsistent with the configuration indicated by the first configuration information, including the component configuration information corresponding to the abnormal component in the first data format being inconsistent with the first configuration information in the first data format, and / or, the component configuration information corresponding to the abnormal component having no data.

[0171] In some other possible designs, components are associated with the service gateway, including components that belong to the service gateway.

[0172] In some other possible designs, the first configuration information is included in the API request sent by the requesting end to the first service.

[0173] In some possible designs, the N components include an API service component, a controller component, a messenger component, and a proxy component. The first service further transforms the first configuration information into second configuration information and sends the second configuration information to the API service component. The API service component retrieves the second configuration information from the first service. The controller component retrieves the second configuration information from the API service component, transforms the data format of the second configuration information into a second data format, and sends the second configuration information in the second data format to the messenger component. The messenger component retrieves the second configuration information in the second data format from the controller component and sends it to the proxy component. The proxy component retrieves the second configuration information in the second data format from the messenger component.

[0174] In some other possible designs, the acquisition unit 501 is also used to send the fault analysis result of the first request to the requesting end if the result of the first request from the requesting end is a request error. The first request is used by the requesting end to access the service instance through the service gateway, and the fault analysis result of the first request is related to the fault analysis result of the service gateway.

[0175] For details of the aforementioned possible implementations, please refer to the description of the fault analysis system 10 and the method embodiment shown in Figure 3 above.

[0176] Please refer to Figure 6, which is a schematic diagram of another fault analysis device provided in an embodiment of this application. The fault analysis device 60 can be a standalone device or a module within a standalone device. The fault analysis device 60 includes a processing unit 601 and an acquisition unit 602. The processing unit 601 is used to perform one or more operations such as processing, calculation, determination, generation, and updating, while the acquisition unit 602 is used to perform one or more operations such as acquisition, reception, listening, transmission, and sending.

[0177] In some possible designs, processing unit 601 is used to obtain the first call record corresponding to the first request based on the path of the first request, the creation time of the path of the first request, and the runtime log of the first component. The first component belongs to the service gateway, and the first request is used by the requesting end to access the service instance through the service gateway. The runtime log includes at least one first call record, and the first call record corresponding to the first request belongs to at least one first call record. Each first call record includes the request path, the creation time of the request path, the call result corresponding to the request, and the error reason corresponding to the request. The call result corresponding to the first request is a request error. Processing unit 601 is also used to obtain the fault analysis result of the first request based on the first call record corresponding to the first request. The fault analysis result includes the error reason of the first request. Acquisition unit 602 is used to send the fault analysis result of the first request to the requesting end.

[0178] In some possible designs, each first call record also includes an identifier ID of the connection corresponding to the request, where the connection includes the connection between the requesting end and the first component and / or the connection between the first component and the service instance. Processing unit 601 is further configured to obtain a second call record corresponding to the first request based on the ID of the connection corresponding to the first request and the runtime log. Processing unit 601 is also configured to obtain a fault analysis result of the first request based on the second call record corresponding to the first request. The runtime log includes at least one second call record, and the second call record corresponding to the first request belongs to at least one second call record. Each second call record includes at least one of the following: information related to the creation of the connection corresponding to the request, information related to the creation of the stream corresponding to the request, and information related to the read / write operations of the socket corresponding to the request.

[0179] In some other possible designs, the call result includes a status code, and a request error includes a status code that does not meet the preset conditions.

[0180] For details of the aforementioned possible implementations, please refer to the description of the fault analysis system 20 and the method embodiment shown in Figure 4 above.

[0181] This application also provides a computing device. This computing device is a device with processing capabilities. Figure 7 is a schematic structural diagram of a computing device provided in an embodiment of this application. As shown in Figure 7, the computing device 70 includes a connection line 701, a processor 702, a memory 703, and a communication interface 704, wherein the processor 702, the memory 703, and the communication interface 704 communicate with each other via the connection line 701. It should be understood that this application does not limit the number of processors 702 and memory 703 in the computing device 70.

[0182] Connection line 701 is used to connect various modules in the device to enable data transmission between different modules. Exemplarily, connection line 701 includes a bus, such as a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. In some cases, connection lines can be categorized as address connection lines, data connection lines, control connection lines, etc. For ease of illustration, only one line is used in Figure 7, but this does not mean that the computing device 70 has only one connection line or only one type of connection line. Connection line 701 can include pathways for transmitting information between various components of the computing device 70 (e.g., processor 702, memory 703, and communication interface 704).

[0183] Processor 702 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0184] The memory 703 may include volatile memory, such as random access memory (RAM). The memory 703 may also include non-volatile memory, such as flash memory, read-only memory (ROM), hard disk drive (HDD), or solid state drive (SSD).

[0185] The memory 703 stores executable code. The processor 702 executes the code stored in the memory 703 to implement the fault analysis method described above, or the processor 702 is used to implement the functions of the fault analysis device 50 or the fault analysis device 60 described above. That is to say, the memory 703 stores instructions for executing the fault analysis method described above.

[0186] The communication interface 704 uses transceiver modules such as, but not limited to, network interface cards and transceivers to enable communication between the computing device 70 and other devices or communication networks. For example, the computing device 70 communicates with a user equipment through the communication interface 704.

[0187] This application also provides a service gateway, which includes the aforementioned fault analysis device 50, fault analysis device 60 or computing device 70, enabling the service gateway to execute the fault analysis method described above.

[0188] This application also provides a computer program product containing instructions. This computer program product may be a software or program product containing instructions that can run on a computing device or be stored on any available medium. When the computer program product is run on a computing device, it causes the computing device to perform the fault analysis method described above.

[0189] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium capable of being stored by a computing device, or a data storage device such as a data center containing one or more available media. The aforementioned available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives). The computer-readable storage medium includes instructions that instruct the computing device to perform the fault analysis method described above.

[0190] In addition, a few additional points need to be made regarding this application:

[0191] I. The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of this application.

[0192] 2. Unless otherwise stated, “multiple” means two or more.

[0193] 3. Unless otherwise specified or in case of logical conflict, the terms and / or descriptions in different embodiments of this application are consistent and can be referenced by each other. The technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationship.

[0194] IV. The various numerical designations used in this application are merely for descriptive convenience and are not intended to limit the scope of protection of this application. The magnitude of the serial numbers used in this application does not imply a sequential order of execution; the execution order of each process should be determined by its function and internal logic. For example, the terms "first," "second," "third," "fourth," and other various terminology (if present) in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. Such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein.

[0195] Furthermore, any embodiment or design described in this application as "exemplary" or "for example" should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner for ease of understanding.

[0196] V. The terms “comprising” and “having” and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device that includes a series of steps or modules is not necessarily limited to those steps or modules that are expressly listed, but may include other steps or modules that are not expressly listed or that are inherent to such process, method, product or device.

[0197] VI. In this application, "for indicating" can be understood as "enabling". "Enabling" can include direct enabling and indirect enabling. When describing information for enabling A, it can include whether the information directly enables A or indirectly enables A, but does not necessarily mean that the information carries A.

[0198] The information that enables the information is called the information to be enabled. In the specific implementation process, there are many ways to enable the information to be enabled, such as, but not limited to, directly enabling the information to be enabled, such as the information to be enabled itself or its index. It can also be indirectly enabled by enabling other information, where there is a relationship between the other information and the information to be enabled. It can also enable only a part of the information to be enabled, while the other parts are known or pre-agreed upon. For example, enabling specific information can be achieved by using a pre-agreed (e.g., protocol-defined) arrangement of various pieces of information, thereby reducing enabling overhead to some extent. Simultaneously, common parts of various pieces of information can be identified and enabled uniformly to reduce the enabling overhead caused by individually enabling the same information.

[0199] VII. In this application, "predefined" may include preconfiguration. For example, predefining certain information means that the information is calculated or received in advance before performing an action that uses the information. The "predefined" can be implemented by pre-storing corresponding codes, tables, or other means that can be used to indicate relevant information in the device (e.g., controller or vehicle). This application does not limit the specific implementation method.

[0200] 8. The term "storage" or "preservation" in this application can refer to storage in one or more memory devices. These memory devices can be separately configured or integrated into an encoder, decoder, processor, or communication device. Alternatively, some memory devices can be separately configured, while others can be integrated into a decoder, processor, or communication device. The type of memory can be any form of storage medium, and this is not limited.

[0201] 9. The arrows or boxes indicated by dashed lines in the schematic diagrams in the accompanying drawings of this application represent optional steps or optional modules.

Claims

1. A fault analysis method, characterized in that, The method includes: Obtain first configuration information from a first service and N component configuration information from N components, where N is an integer and N is greater than 0. The N components are associated with a service gateway, and each component corresponds to a component configuration information. The service gateway is used by the requesting end to access the service instance. The first configuration information is defined by the requesting end. The component configuration information corresponding to the N components is obtained from the second configuration information provided by the first service. The second configuration information is based on the first configuration information. The first configuration information is used to indicate the configuration of the service gateway, and the N component configuration information is used to indicate the configuration of the service gateway. Based on the first configuration information and the configuration information of the N components, the fault analysis result of the service gateway is obtained. The fault analysis result is used to indicate the abnormal component among the N components. The configuration indicated by the component configuration information corresponding to the abnormal component is inconsistent with the configuration indicated by the first configuration information.

2. The method according to claim 1, characterized in that, The step of obtaining the fault analysis result of the service gateway based on the first configuration information and the configuration information of the N components includes: Align the first configuration information and the N component configuration information according to their data formats to obtain the first configuration information and the N component configuration information in the first data format. Based on the first configuration information of the first data format and the N component configuration information of the first data format, the fault analysis result of the service gateway is obtained.

3. The method according to claim 2, characterized in that, The inconsistency between the configuration information indicated by the component corresponding to the abnormal component and the configuration indicated by the first configuration information includes: The component configuration information corresponding to the abnormal component in the first data format is inconsistent with the first configuration information of the first data format; And / or, the component configuration information corresponding to the abnormal component has no data.

4. The method according to any one of claims 1-3, characterized in that, The association between a component and the service gateway includes the component belonging to the service gateway.

5. The method according to any one of claims 1-4, characterized in that, The first configuration information is included in the application programming interface (API) request sent by the requesting end to the first service.

6. The method according to any one of claims 1-5, characterized in that, The N components include API service components, controller components, messenger components, and proxy components; The first service is further configured to convert the first configuration information into the second configuration information and send the second configuration information to the API service component; The API service component is used to obtain the second configuration information from the first service; The controller component is used to obtain the second configuration information from the API service component. The controller component is also used to convert the data format of the second configuration information into a second data format and send the second configuration information in the second data format to the messenger component. The messenger component is used to obtain second configuration information in the second data format from the controller component, and send the second configuration information in the second data format to the agent component; The proxy component is used to obtain second configuration information in the second data format from the messenger component.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: If the result of the first request from the requesting end is a request error, the fault analysis result of the first request is sent to the requesting end. The first request is used by the requesting end to access the service instance through the service gateway, and the fault analysis result of the first request is related to the fault analysis result of the service gateway.

8. A fault analysis method, characterized in that, The method includes: Based on the path of the first request, the creation time of the path of the first request, and the running log of the first component, a first call record corresponding to the first request is obtained. The first component belongs to the service gateway. The first request is used by the requesting end to access the service instance through the service gateway. The running log includes at least one first call record. The first call record corresponding to the first request belongs to the at least one first call record. Each first call record includes the path of the request, the creation time of the path of the request, the call result corresponding to the request, and the error reason corresponding to the request. The call result corresponding to the first request is a request error. Based on the first call record corresponding to the first request, the fault analysis result of the first request is obtained, and the fault analysis result includes the error reason of the first request; Send the fault analysis results of the first request to the requesting end.

9. The method according to claim 8, characterized in that, Each first call record also includes an identifier ID of the connection corresponding to the request, wherein the connection includes the connection between the requesting end and the first component and / or the connection between the first component and the service instance. Obtaining the fault analysis result of the first request based on the first call record corresponding to the first request includes: Based on the ID of the connection corresponding to the first request and the running log, a second call record corresponding to the first request is obtained. The running log includes at least one second call record. The second call record corresponding to the first request belongs to the at least one second call record. Each second call record includes at least one of the following: information related to the creation of the connection corresponding to the request, information related to the creation of the stream corresponding to the request, and information related to the reading and writing of the socket corresponding to the request. Based on the second call record corresponding to the first request, the fault analysis result of the first request is obtained.

10. The method according to claim 8 or 9, characterized in that, The call result includes a status code, and the request error includes a status code corresponding to the request not meeting a preset condition.

11. A fault analysis device, characterized in that, The fault analysis device includes an acquisition unit and a processing unit, wherein: The acquisition unit is used to acquire first configuration information from the first service and N component configuration information from N components, where N is an integer and N is greater than 0. The N components are associated with the service gateway, and each component corresponds to one component configuration information. The service gateway is used by the requesting end to access the service instance. The first configuration information is defined by the requesting end. The component configuration information corresponding to the N components is obtained from the second configuration information provided by the first service. The second configuration information is based on the first configuration information. The first configuration information is used to indicate the configuration of the service gateway, and the N component configuration information is used to indicate the configuration of the service gateway. The processing unit is used to obtain the fault analysis result of the service gateway based on the first configuration information and the configuration information of the N components. The fault analysis result is used to indicate the abnormal component among the N components. The configuration indicated by the component configuration information corresponding to the abnormal component is inconsistent with the configuration indicated by the first configuration information.

12. A fault analysis device, characterized in that, The fault analysis device includes a processing unit and an acquisition unit, wherein: The processing unit is used to obtain a first call record corresponding to the first request based on the path of the first request, the creation time of the path of the first request, and the operation log of the first component. The first component belongs to the service gateway. The first request is used by the requesting end to access the service instance through the service gateway. The operation log includes at least one first call record. The first call record corresponding to the first request belongs to the at least one first call record. Each first call record includes the path of the request, the creation time of the path of the request, the call result corresponding to the request, and the error reason corresponding to the request. The call result corresponding to the first request is a request error. The processing unit is further configured to obtain the fault analysis result of the first request based on the first call record corresponding to the first request, wherein the fault analysis result includes the error reason of the first request; The acquisition unit is used to send the fault analysis results of the first request to the requesting end.

13. A computing device, characterized in that, The computing device includes a processor and a memory, the memory storing a computer program, and the processor being used to invoke the computer program stored in the memory to implement the method according to any one of claims 1-10.

14. A service gateway, characterized in that, The service gateway includes the fault analysis device as described in claim 11, the fault analysis device as described in claim 12, or the computing device as described in claim 13.

15. A readable storage medium, characterized in that, The readable storage medium is used to store a computer program that, when executed by a processor, causes a device including the processor to perform the method according to any one of claims 1-10.

16. A computer program product, characterized in that, When the computer program product is executed by a processor, the apparatus including the processor performs the method according to any one of claims 1-10.

Images