A data diagnosis method and device, a diagnosis apparatus, and a storage medium

Abstract

The embodiment of the application discloses a data diagnosis method and device, a diagnosis equipment and a storage medium. The method comprises the following steps: receiving a diagnosis request of a target diagnosis type of a target service sent by a diagnosis platform; the diagnosis request comprises a target domain name required to be called when executing the target service and network attribute information of a network used for executing the target service; intermediate data generated when the target service is executed based on the target domain name and the network attribute information is acquired; the intermediate data comprises address data required in the process of executing the target service; diagnosis reference data of the target diagnosis type of the target service is acquired; the intermediate data is diagnosed based on the diagnosis reference data, and a diagnosis result for the target service is obtained; the diagnosis result is used for indicating that a target address indicated by the target domain name can be accessed or cannot be accessed when the target service is executed based on the network attribute information. By using the application, the diagnosis efficiency and diagnosis accuracy for the target service can be improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data diagnostic method, apparatus, diagnostic equipment, and storage medium. Background Technology

[0002] With the rapid development of various businesses (such as cloud services) and the gradual expansion of business scale, customers have increasingly higher requirements for the network quality used to execute these services. However, in real-world scenarios, network anomalies often occur during customer requests to execute services, leading to situations where services cannot be executed normally. Currently, to diagnose network anomalies, most enterprises (those creating the business) typically use manual diagnostic methods, requiring technical personnel to analyze relevant data. This diagnostic method heavily relies on the diagnostic experience of technical personnel, is time-consuming and labor-intensive, and is prone to errors, resulting in low diagnostic efficiency and accuracy. Summary of the Invention

[0003] This application provides a data diagnostic method, apparatus, diagnostic device, and storage medium, which can improve the diagnostic efficiency and accuracy for target services.

[0004] In a first aspect, embodiments of this application provide a data diagnostic method, including:

[0005] Receive a diagnostic request from the diagnostic platform for a specific type of diagnostic service; the diagnostic request includes the target domain name to be invoked to execute the target service, and network attribute information of the network used to execute the target service;

[0006] Obtain intermediate data required to execute the target service based on the target domain name and the network attribute information; the intermediate data includes address data required during the execution of the target service.

[0007] Obtain the diagnostic reference data of the target service under the target diagnostic type;

[0008] Based on the diagnostic reference data, data diagnosis is performed on the intermediate data to obtain a diagnostic result for the target service; the diagnostic result is used to indicate whether the target address can be accessed or cannot be accessed when the target service is executed based on the network attribute information, and the target address refers to the address indicated by the target domain name.

[0009] Secondly, embodiments of this application provide a data diagnostic device, including:

[0010] The receiving unit is configured to receive a diagnostic request sent by the diagnostic platform for a target diagnostic type for a target service; the diagnostic request includes the target domain name to be invoked to execute the target service, and network attribute information of the network used to execute the target service;

[0011] The first acquisition unit is used to acquire intermediate data required to execute the target service based on the target domain name and the network attribute information; the intermediate data includes address data required during the execution of the target service.

[0012] The second acquisition unit is used to acquire diagnostic reference data of the target service under the target diagnostic type;

[0013] A diagnostic unit is used to perform data diagnosis on the intermediate data based on the diagnostic reference data to obtain a diagnostic result for the target service; the diagnostic result is used to indicate whether the target address can be accessed or cannot be accessed when the target service is executed based on the network attribute information, and the target address refers to the address indicated by the target domain name.

[0014] Thirdly, embodiments of this application provide a diagnostic device, the diagnostic device comprising: a processor and a memory, the processor being configured to execute the method described in the first aspect above.

[0015] Fourthly, embodiments of this application also provide a computer-readable storage medium storing program instructions that, when executed, implement the method described in the first aspect above.

[0016] Fifthly, embodiments of this application also provide a computer program product or computer program, which includes program instructions that, when executed by a processor, implement the method described in the first aspect above.

[0017] In this embodiment, a diagnostic request for a target service type sent by a diagnostic platform can be received. This diagnostic request may include the target domain name to be invoked for executing the target service, and network attribute information of the network used to execute the target service. Then, intermediate data generated when executing the target service based on the target domain name and network attribute information can be obtained. This intermediate data may include address data required during the execution of the target service. Diagnostic reference data for the target service under the target diagnostic type can also be obtained. Furthermore, data diagnosis can be performed on the intermediate data based on the diagnostic reference data to obtain a diagnostic result for the target service. This diagnostic result can be used to indicate whether the target address can be accessed or not when executing the target service based on the network attribute information. The target address may refer to the address indicated by the target domain name. By implementing the above method, automated data diagnosis can be achieved, improving diagnostic intelligence. Furthermore, diagnostic reference data can be obtained for data analysis, allowing diagnosis to be performed according to pre-set diagnostic rules, solving the tedious and error-prone manual diagnostic operations, thereby improving diagnostic efficiency and accuracy. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of the architecture of a data diagnostic system provided in an embodiment of this application;

[0020] Figure 2 This is a flowchart illustrating a data diagnostic method provided in an embodiment of this application;

[0021] Figure 3 This is a schematic diagram of a process for obtaining a diagnostic request provided in an embodiment of this application;

[0022] Figure 4 This is a flowchart illustrating another data diagnostic method provided in an embodiment of this application;

[0023] Figure 5a This is a schematic diagram of the first diagnostic interface on a diagnostic platform under a domain name diagnostic type provided in this application embodiment;

[0024] Figure 5b This is a schematic diagram of the diagnostic parameter input area in a first diagnostic interface provided in an embodiment of this application;

[0025] Figure 5cThis is a code diagram illustrating the interface parameters of a diagnostic request under a domain name diagnostic type provided in an embodiment of this application;

[0026] Figure 5d This is a logical diagram illustrating fault diagnosis under a domain name diagnosis type provided in an embodiment of this application;

[0027] Figure 5e This is a schematic diagram of the fault reproduction area in a first diagnostic interface provided in an embodiment of this application;

[0028] Figure 5f This is a schematic diagram of the fault prediction area in a first diagnostic interface provided in an embodiment of this application;

[0029] Figure 5g This is a schematic diagram of the fault creation area in a first diagnostic interface provided in an embodiment of this application;

[0030] Figure 5h This is a flowchart illustrating the creation of a work order under a domain name diagnostic type, as provided in an embodiment of this application.

[0031] Figure 6a This is a code diagram illustrating a fault creation request for creating a work order under a domain name diagnosis type provided in this application embodiment;

[0032] Figure 6b This is a schematic diagram of a network recovery detection process under a domain name diagnosis type provided in an embodiment of this application;

[0033] Figure 6c This is a code diagram illustrating a network recovery detection request under a domain name diagnosis type provided in this application embodiment;

[0034] Figure 6d This is a flowchart illustrating a data diagnosis method under a domain name diagnosis type provided in an embodiment of this application;

[0035] Figure 6e This is a flowchart illustrating another data diagnosis method under a different domain name diagnosis type provided in this application embodiment;

[0036] Figure 7 This is a flowchart illustrating another data diagnostic method provided in an embodiment of this application;

[0037] Figure 8a This is a schematic diagram of the interface of the diagnostic parameter input area on a diagnostic platform under the Ping diagnostic type, provided in an embodiment of this application.

[0038] Figure 8b This is a code diagram illustrating the interface parameters of a diagnostic request under the Ping diagnostic type provided in an embodiment of this application;

[0039] Figure 8c This is a schematic diagram of the interface of the diagnostic parameter input area on a diagnostic platform under a port diagnostic type, provided in an embodiment of this application.

[0040] Figure 8d This is a code diagram illustrating the interface parameters of a diagnostic request under a port diagnostic type provided in an embodiment of this application;

[0041] Figure 8e This is a logical diagram illustrating fault diagnosis under the Ping diagnostic type provided in an embodiment of this application;

[0042] Figure 9a This is a schematic diagram of the interface of a fault reproduction area under the Ping diagnostic type provided in an embodiment of this application;

[0043] Figure 9b This is a schematic diagram of the interface of a fault prediction area under the Ping diagnostic type provided in an embodiment of this application;

[0044] Figure 9c This is a schematic diagram of the interface of the fault creation area under the Ping diagnostic type provided in an embodiment of this application;

[0045] Figure 9d This is a flowchart illustrating the creation of a work order under the Ping diagnostic type, as provided in an embodiment of this application.

[0046] Figure 9e This is a code diagram illustrating a fault creation request for creating a work order under the Ping diagnostic type provided in an embodiment of this application;

[0047] Figure 9f This is a schematic diagram of a network recovery detection process under the Ping diagnostic type provided in an embodiment of this application;

[0048] Figure 9g This is a code diagram illustrating a network recovery detection request under the Ping diagnostic type provided in an embodiment of this application;

[0049] Figure 9h This is a flowchart illustrating a data diagnosis method under Ping diagnosis type and port diagnosis type provided in an embodiment of this application;

[0050] Figure 9i This is a flowchart illustrating another data diagnostic method under a Ping diagnostic type provided in an embodiment of this application;

[0051] Figure 9j This is a flowchart illustrating another data diagnostic method under a different port diagnostic type provided in this application embodiment;

[0052] Figure 10This is a schematic diagram of the structure of a data diagnostic device provided in an embodiment of this application;

[0053] Figure 11 This is a schematic diagram of the structure of a diagnostic device provided in an embodiment of this application. Detailed Implementation

[0054] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0055] Cloud technology refers to a managed technology that unifies a series of resources such as hardware, software, and networks within a wide area network or local area network to achieve data computing, storage, processing, and sharing.

[0056] Cloud technology is a collective term for network technology, information technology, integration technology, management platform technology, and application technology applied to the cloud computing business model. It can form resource pools, providing flexible and convenient on-demand access. Cloud computing technology will become a crucial support. Backend services of technical network systems require substantial computing and storage resources, such as video websites, image websites, and many portal websites. With the rapid development and application of the internet industry, every item may have its own identification mark in the future, requiring transmission to backend systems for logical processing. Data at different levels will be processed separately, and various industry data will all require robust system support, which can only be achieved through cloud computing.

[0057] Cloud computing is a computing model that distributes computing tasks across a resource pool consisting of a large number of computers, enabling various application systems to access computing power, storage space, and information services as needed. The network providing these resources is called the "cloud." From the user's perspective, the resources in the "cloud" are infinitely scalable, readily available, on-demand, expandable, and pay-as-you-go.

[0058] This application can store the data required for data diagnosis in the "cloud" and retrieve and expand the data in the cloud at any time as needed. For example, the diagnostic reference data of the target business under the target diagnostic type can be stored in the "cloud". When performing data diagnosis on the target business under the target diagnostic type, the corresponding diagnostic reference data can be retrieved from the "cloud" for subsequent data diagnosis operations.

[0059] Artificial intelligence (AI) is the theory, methods, technology, and application systems that use digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to achieve optimal results. In other words, AI is a comprehensive technology within computer science that attempts to understand the essence of intelligence and produce a new kind of intelligent machine that can react in a way similar to human intelligence. AI studies the design principles and implementation methods of various intelligent machines, enabling them to possess the functions of perception, reasoning, and decision-making.

[0060] Artificial intelligence (AI) is a comprehensive discipline encompassing a wide range of fields, including both hardware and software technologies. Fundamental AI technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, operating / interactive systems, and mechatronics. AI software technologies primarily include computer vision, speech processing, natural language processing, and machine learning / deep learning.

[0061] Machine Learning (ML) is a multidisciplinary field involving probability theory, statistics, approximation theory, convex analysis, and algorithm complexity theory. It specifically studies how computers can simulate or implement human learning behavior to acquire new knowledge or skills and reorganize existing knowledge structures to continuously improve their performance. Machine learning is the core of artificial intelligence and the fundamental way to endow computers with intelligence; its applications span all areas of artificial intelligence. Machine learning and deep learning typically include techniques such as artificial neural networks, belief networks, reinforcement learning, transfer learning, inductive learning, and instructional learning.

[0062] This solution can be used to obtain intermediate data for the target business under the target diagnostic type, and then input the intermediate data into a deep neural network model to perform anomaly prediction, thereby making network anomaly diagnosis more intelligent and convenient.

[0063] This application proposes a diagnostic platform that can perform data diagnostics on a target service at a target diagnostic type to determine whether there are any anomalies in the network executing the target service, and further identify the faults causing the anomalies. The target diagnostic type can refer to the type of diagnostics performed on the domain name called to execute the target service, such as a domain name diagnostic type or DNS (Domain Name System) diagnostic type. The target diagnostic type can also refer to the type of diagnostics performed on the network executing the target service, which may include network connectivity diagnostic types (or Ping diagnostic types) or port connectivity diagnostic types (or Port diagnostic types). In one embodiment, if a diagnostician has a data diagnostic need for a target service at a target diagnostic type, they can initiate a diagnostic request for that target service through the diagnostic platform. The diagnostician can input the required diagnostic parameters for data diagnostics on the platform, allowing the platform to generate a corresponding diagnostic request. After generating the diagnostic request, the platform can respond to the request to perform data diagnostics and obtain the corresponding diagnostic results, which can indicate whether there are network anomalies or not. Optionally, if the network exhibits anomalies, the diagnostic results may also include the faults causing the network anomalies. Performing data diagnostic tasks through a diagnostic platform makes these tasks more convenient and efficient, improving diagnostic effectiveness and reducing costs associated with manual operations (such as time and labor costs).

[0064] Based on the diagnostic platform provided above, this application proposes a data diagnostic scheme and a corresponding data diagnostic system to achieve data diagnostics of target businesses under target diagnostic types, thereby improving data diagnostic efficiency. Please refer to... Figure 1 This is a schematic diagram of the architecture of a data diagnostic system provided in an embodiment of this application. The data diagnostic system may include a diagnostic platform and a diagnostic device in which the diagnostic platform is located. In one embodiment, if a diagnostician has a data diagnostic need for a target business at a target diagnostic type, they can initiate a diagnostic request for the target business at the target diagnostic type through the diagnostic platform. The diagnostic platform can then send the diagnostic request to the diagnostic device, allowing the diagnostic device to obtain the diagnostic result corresponding to the target business based on the diagnostic request. Optionally, after obtaining the diagnostic result, the diagnostic device can return the diagnostic result to the diagnostic platform so that the diagnostic platform can display the diagnostic result.

[0065] The data diagnostic functions of the diagnostic platform can be integrated into a single client, meaning the diagnostic platform can be understood as a diagnostic client. This client can be a smart device with network connectivity, such as a mobile phone, tablet, laptop, PDA, or Mobile Internet Device (MID). The diagnostic device can be a server. This server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The diagnostic platform and diagnostic device can be directly or indirectly connected via wired or wireless communication; this embodiment does not impose any limitations on this connection.

[0066] In this application embodiment, in order to improve the efficiency of data diagnosis, this application embodiment is based on Figure 1 The data diagnostic system shown provides a data diagnostic scheme. In its specific implementation, this scheme can be executed by a diagnostic device. The principle of the data diagnostic scheme is as follows: First, it can receive a data diagnostic request from a diagnostic platform for a target service within a target diagnostic type. This diagnostic request may contain relevant information for subsequent data diagnostics, such as the target domain name to be invoked for executing the target service and the network attribute information of the network used to execute the target service. Then, it can obtain intermediate data generated when executing the target service based on the target domain name and network attribute information; this intermediate data may include address data required during the execution of the target service. It can also obtain diagnostic reference data for the target service under the target diagnostic type. After obtaining the intermediate data and diagnostic parameter data, it can perform data diagnostics on the intermediate data based on the diagnostic reference data to obtain the diagnostic results for the target service. By implementing the above scheme, automated data diagnostics can be achieved, improving diagnostic intelligence; furthermore, it can obtain diagnostic reference data for data analysis to perform diagnostics according to pre-set diagnostic rules, solving the tedious and error-prone manual diagnostic operations, thereby improving diagnostic efficiency and accuracy.

[0067] Based on the data diagnostic scheme provided above, this application embodiment provides a data diagnostic method, which can be executed by the diagnostic equipment mentioned above. Please refer to... Figure 2 The data diagnostic method includes, but is not limited to, the following steps:

[0068] S201, Receive a diagnostic request from the diagnostic platform for the target diagnostic type of the target business.

[0069] The diagnostic request may include the target domain name to be invoked to execute the target service, and the network attribute information of the network used to execute the target service. The target service can be a webpage opening service, an application opening task, or other services; there are no specific limitations. The network attribute information may include the geographical region to which the network used to execute the target service belongs and the network provider; the network provider can be an operator or other object that can provide the network, such as operators including operator 1, operator 2, operator 3, etc., and the geographical region could be city 1, city 2, city 3, etc. As mentioned above, the target diagnostic type can refer to the type of diagnostic performed on the domain name to be invoked to execute the target service (e.g., domain name diagnostic type), or it can refer to the type of diagnostic performed on the network used to execute the target service (e.g., Ping diagnostic type or port diagnostic type).

[0070] In one implementation, the diagnostic request can be triggered by a diagnostician performing relevant operations on the diagnostic platform. For example, when a diagnostician needs to perform network diagnostics (or data diagnostics) for a target service's target diagnostic type, the diagnostician can perform relevant operations on the diagnostic interface output by the diagnostic platform to send a diagnostic request for the target service's target diagnostic type to the diagnostic platform. See, for example... Figure 3 As shown, the diagnostic platform used by the diagnostic personnel can display a diagnostic interface, which may include a diagnostic parameter input area 301 and a submission control 302. The diagnostic parameter input area 301 may include domain name input items, region input items, and network provider input items. If the diagnostic personnel want to diagnose the network with the domain name www.123.com, the geographic region city 1, and the network provider operator 1, they can enter www.123.com, city 1, and operator 1 in the relevant input items in the diagnostic parameter input area. Then, the diagnostic personnel can perform a trigger operation (such as a click operation, a press operation, etc.) on the submission control 302, thereby triggering the diagnostic platform to obtain the diagnostic parameters (i.e., the data in each input item) in the diagnostic parameter input area and send a diagnostic request to the diagnostic device. This diagnostic request may include the target domain name to be called for executing the target service, and the network attribute information (geographic region and network provider object) of the network used to execute the target service.

[0071] In one implementation, the diagnostic request may be generated by triggering a diagnostic scheduled task. For example, a diagnostic scheduled task can be set up, specifying the triggering conditions for performing a diagnostic on the target service of a target diagnostic type. For instance, the triggering condition could be the current time reaching a preset diagnostic time or other conditions. The diagnostic scheduled task may also specify the target domain name to be invoked to execute the target service, and the network attribute information of the network used to execute the target service.

[0072] S202, Obtain the intermediate data required when executing the target business based on the target domain name and network attribute information.

[0073] The intermediate data may include address data required during the execution of the target service. It should be noted that the address involved in this embodiment can be understood as an IP address.

[0074] The implementation methods for acquiring intermediate data and the specific meaning of the intermediate data differ depending on the target diagnostic type. The following section elaborates on the acquisition of intermediate data for different target diagnostic types.

[0075] (1) When the target diagnostic type refers to the type of diagnostics performed on the domain name to be called for the execution of the target business (i.e., DNS diagnostic type).

[0076] The intermediate data can refer to the resolution address of the target domain name provided by the network. The resolution address corresponding to the target domain name can refer to the IP address corresponding to the target domain name. This resolution address can be called the first resolution address.

[0077] In one embodiment, to obtain the first resolved address, the diagnostic device may first determine the domain name resolution device used by the network provider to resolve the domain name. For ease of subsequent description, this device may be referred to as the first device. After determining the first device, the diagnostic device may call the first device to resolve the target domain name in order to obtain the first resolved address of the network provider for the target domain name.

[0078] (2) When the target diagnostic type refers to the type of diagnosis performed on the network performing the target service (i.e., Ping diagnostic type or port diagnostic type).

[0079] Intermediate data can refer to address data generated during data transmission between the second and third devices. The second device can be the device initiating the target service within a geographical area, and the third device can be the device generating the service data for the target service. For example, if the target service is a webpage opening task, the service data can refer to the webpage data used to generate the webpage, and the third device can be the device used to generate the webpage data. There is at least one relay device between the second and third devices for data transmission. For example, assuming the second device is in city 1 and the third device is in city 2, one or more devices can be routed during data transmission to transfer data from the second device to the third device; the routed devices are the relay devices. Therefore, the address data mentioned above can specifically include: the device address of the second device, the device address of each relay device, and the device address to which the data is transmitted from the device address of the third device. Here, the device address can refer to the IP address of the corresponding device.

[0080] In one embodiment, to obtain the aforementioned address data, the diagnostic device can first identify a second device used to initiate a target service within a geographical area. The second device can then use the network provided by the network provider to send first test data (i.e., the data mentioned above) to the third device, enabling the second device to obtain address data generated during the transmission of the first test data to the third device. After obtaining the address data, the second device can send it to the diagnostic device, allowing the diagnostic device to receive the address data generated during the transmission of the first test data returned by the second device and identify this address data as intermediate data.

[0081] S203, Obtain diagnostic reference data for the target business under the target diagnostic type.

[0082] The diagnostic reference data can be understood as data used to assist in determining the diagnostic result, or it can refer to the diagnostic rules (or diagnostic algorithms, diagnostic logic, etc.) required for data diagnosis of intermediate data. The diagnostic reference data can be pre-set and stored in a storage area so that it can be directly retrieved from that storage area when needed.

[0083] The diagnostic reference data can vary depending on the target diagnostic type. For example, if the target diagnostic type involves diagnosing the domain name called to execute the target service, the diagnostic reference data can include a preset first abnormal address and a second resolved address. The first abnormal address can be an address that would prevent access to the target address when executing the target service based on network attribute information. The second resolved address is the address obtained after the business object to which the target service belongs resolves the target domain name. The business object can be the object that created the target service, such as an individual or an enterprise. Similarly, if the target diagnostic type involves diagnosing the network executing the target service, the diagnostic reference data can include a preset second abnormal address, which could be an address that would prevent access to the target address when executing the target service based on network attribute information.

[0084] S204. Based on the diagnostic reference data, perform data diagnostics on the intermediate data to obtain diagnostic results for the target service. The diagnostic results can be used to indicate whether the target address can be accessed or not when performing the target service based on network attribute information. The target address can refer to the address indicated by the target domain name.

[0085] The implementation of data diagnosis based on diagnostic reference data differs for different target diagnostic types. The following explanation uses two target diagnostic types as examples.

[0086] (1) The target diagnostic type is the type of diagnostic performed on the domain name that needs to be called to execute the target business.

[0087] If the first resolved address is the first abnormal address, then the diagnostic result indicates that the target address cannot be accessed when executing the target service based on network attribute information. Similarly, if the first and second resolved addresses are different, the diagnostic result also indicates that the target address cannot be accessed when executing the target service based on network attribute information. It can be understood that the second resolved address is obtained by resolving the service object corresponding to the target service. Therefore, this second resolved address can be understood as a correct resolved address for the target service, or as a baseline resolved address that can be accessed when executing the target service based on network attribute information. Based on this, it can be known that if the first and second resolved addresses are different, then the first resolved address is an incorrect resolved address. Therefore, if the first resolved address is not a correct resolved address, then the target address cannot be accessed when executing the target service based on network attribute information, because the target address is the correct resolved address corresponding to the target domain name.

[0088] (2) The target diagnostic type is the type of diagnosis performed on the network that performs the target service.

[0089] If the intermediate data contains a second abnormal address, the diagnostic result indicates that the target address cannot be accessed when performing the target service based on network attribute information. Similarly, if the device address to which the first test data was last transmitted in the intermediate data is not the device address of the third device, the diagnostic result also indicates that the target address cannot be accessed when performing the target service based on network attribute information. It is understood that the third device is the device to which the first test data is to be transmitted. Therefore, if the device address to which the first test data was last transmitted is not the device address of the third device, it can be determined that the first test data was not transmitted to the device, thus confirming that the target address cannot be accessed when performing the target service based on network attribute information.

[0090] In one implementation, after obtaining the diagnostic results for the target service under the domain name diagnostic type, the diagnostic device can also generate a diagnostic analysis report for the target service based on the diagnostic results. This diagnostic analysis report may include the diagnostic results, or it may also include data involved in the data diagnosis (such as diagnostic parameters, intermediate data, etc.) and other data (e.g., if the diagnostic result indicates that the target address cannot be accessed, the diagnostic analysis report may also include solutions for resolving network anomalies). After obtaining the diagnostic analysis report, it can be returned to the diagnostic platform, allowing the platform to output the report. For example, the diagnostic analysis report can be displayed on the diagnostic platform's diagnostic interface, allowing diagnostic personnel to view it and perform network recovery based on the data in the report.

[0091] In this embodiment, a diagnostic request for a target service type sent by a diagnostic platform can be received. This diagnostic request may include the target domain name to be invoked for executing the target service, and network attribute information of the network used to execute the target service. Furthermore, intermediate data generated when executing the target service based on the target domain name and network attribute information can be obtained. Diagnostic reference data for the target service under the target diagnostic type can also be obtained. Therefore, data diagnosis can be performed on the intermediate data based on the diagnostic reference data to obtain a diagnostic result for the target service. Through the above methods, automated data diagnosis can be achieved, improving diagnostic intelligence. Moreover, diagnostic reference data can be obtained for data analysis, allowing diagnosis to be performed according to pre-set diagnostic rules, solving the tedious and error-prone manual diagnostic operations, thereby improving diagnostic efficiency and accuracy.

[0092] Please see Figure 4This is a flowchart illustrating another data diagnostic method provided in this application embodiment. This application embodiment primarily uses a diagnostic device as the execution subject, and the target diagnostic type refers to the type of domain name diagnostic performed on the domain name required to execute the target business (i.e., domain name diagnostic type). Please refer to [link to relevant documentation]. Figure 4 The data diagnostic method includes, but is not limited to, the following steps:

[0093] S401, Receive diagnostic requests from the diagnostic platform for the target diagnostic type of the target business.

[0094] The diagnostic request includes the target domain name to be invoked for executing the target service, and the network attribute information of the network used to execute the target service; for a detailed understanding, please refer to the description in step S201 above, which will not be repeated here.

[0095] In one implementation, the diagnostic platform can display a diagnostic interface. Different diagnostic interfaces can be displayed for different target diagnostic types for the target business. Understandably, if the target diagnostic type here is a domain name diagnostic type, then this diagnostic interface is for the domain name diagnostic type of the target business. This interface can be referred to as the first diagnostic interface. For example, this first diagnostic interface could be as follows: Figure 5a As shown, Figure 5a As shown, the first diagnostic interface may include a selection area 50 for selecting the diagnostic type. Diagnostic personnel can select the diagnostic type for which data diagnosis is needed within this selection area 50. For example, clicking or pressing the "DNS Diagnosis" area will display the first diagnostic interface; similarly, clicking or pressing the "Ping Diagnosis" area will display the diagnostic interface for the Ping diagnostic type. In one embodiment, when a diagnostic personnel needs to perform data diagnosis for a domain name diagnostic type, they can perform relevant operations on the first diagnostic interface of the diagnostic platform to enable the diagnostic platform to obtain a diagnostic request for the domain name diagnostic type specific to the target business. For example, the diagnostic platform can obtain the diagnostic parameters entered by the diagnostic personnel on the first diagnostic interface and generate a diagnostic request for the domain name diagnostic type specific to the target business based on these parameters. After obtaining the diagnostic request, the diagnostic platform can send it to the diagnostic device, which can then receive the diagnostic request sent by the diagnostic platform.

[0096] For example, see as follows Figure 5a As shown, the first diagnostic interface may include a diagnostic parameter input area 51. This diagnostic parameter input area 51 may include multiple input items, which can be used by diagnostic personnel to input relevant diagnostic parameters required for data diagnosis of the domain name diagnostic type for the target business. For example, such as... Figure 5bAs shown, the diagnostic parameter input area 51 may include a domain name input field 501, a network provider input field 502, and a region input field 503; correspondingly, these three input fields can be used by diagnostic personnel to input the target domain name, network provider, and geographical region, respectively. The diagnostic parameter input area 51 may also include a submission control 504, which, when triggered (e.g., pressed or clicked), allows the diagnostic platform to obtain the diagnostic parameters from each input field.

[0097] For example, such as Figure 5b As shown, diagnostic personnel can enter the target domain name "www.123.com" in the domain name input field 501, select the corresponding network provider "Operator 1" in the network provider input field 502, and enter the geographical region "City 1" in the region input field 503; then click or press the submit control 504. When the diagnostic platform detects that the submit control 504 has been triggered, it can obtain the diagnostic parameters from each input field in the diagnostic parameter input area 51 and generate a diagnostic request, which may include the diagnostic parameters entered in the diagnostic parameter input area 51. Optionally, the diagnostic parameter input area 51 may also include a protocol input field 505, which can be used by diagnostic personnel to select the Internet protocol (such as IPv4 or IPv6); the diagnostic parameter input area 51 may also include a one-click clear control 506, which can be used to clear all the diagnostic parameters entered in the diagnostic parameter input area with one click, thereby improving the efficiency of clearing diagnostic parameters on the interface.

[0098] In one implementation, the interface parameters in the diagnostic request for the target diagnostic type of the target business can be seen as follows: Figure 5c As shown, where, as Figure 5cThe data shown represents the interface parameters for a diagnostic request under the "Create Domain Diagnostic Task" category. These parameters can include the request mode, request body requirements, request carrier, and a request example. For instance, the request mode could be a POST request; the request body requirement could be Content-Type: application / json; charset=utf-8, meaning the diagnostic request content is in JSON format and encoded in UTF-8; and the request carrier can be JSON. In the request example, `isp` indicates the network provider (e.g., ISP 3), `ldns` indicates the device address of the domain name resolution device (e.g., 111.11.1.1), `province` indicates the geographical region (e.g., city 1), `domain` indicates the target domain name (e.g., www.123.com), `area` limits the geographical region (e.g., country A), and `record_type` indicates the record type (e.g., type A). This record type can be a parameter used later during domain name resolution, but will not be detailed here. The user is used to indicate the username of the diagnostic personnel (e.g., the username could be admin), the AddressFamily_no is used to indicate the Internet Protocol (e.g., the Internet Protocol could be 4 (i.e., IPv4)), and the CreateTime is used to indicate the time when the diagnostic request was generated (e.g., the generation time could be 2022-07-18 10:35:11).

[0099] S402, Determine the first device for resolving domain names for the network provider object.

[0100] In one implementation, a domain name resolution device (DNS) for resolving domain names can be determined based on the network provider and the geographical region. This device can be referred to as the first device, which can be understood as a DNS resolution device (e.g., a domain name server). Specifically, the device addresses of each network provider and the corresponding DNS resolution devices in the corresponding geographical region can be pre-stored. For example, a mapping relationship between network providers, geographical regions, and device addresses can be pre-configured, as shown in Table 1 below. A network provider and its corresponding geographical region can have one or more device addresses; that is, the first device for resolving domain names can have one or more. It should be noted that in practical scenarios, there are usually two DNS resolution devices for resolving domain names for a network provider. One DNS resolution device can be understood as the primary device, and the other as a backup device. Configuring multiple DNS resolution devices can improve the accuracy of domain name resolution.

[0101] Table 1

[0102] Network Provider Geographical region Device address Operator 1 City 1 Address 1, Address 2 Operator 1 City 2 Address 3 Carrier 2 City 3 Address 4, Address 5 … … …

[0103] Based on this, it can be seen that after obtaining the network provider and geographical region from the diagnostic request, these two pieces of data can be directly used to match the corresponding device address. After determining the device address, the corresponding first device can then be determined based on that device address. The first device is the device corresponding to the device address. For example, assuming the network provider is operator 1 and the geographical region is city 2, then according to Table 1, the device address matching operator 1 and city 2 is address 3, and the first device is the device corresponding to address 3.

[0104] S403, call the first device to resolve the target domain name, obtain the first resolution address of the network provider for the target domain name; and determine the first resolution address as intermediate data.

[0105] In one implementation, the diagnostic device can send a domain name resolution request to the first device. Upon receiving the request, the first device can retrieve the first resolved address of the target domain name from its storage and return the retrieved address to the diagnostic device. It's important to understand that different network providers can configure corresponding domain name resolution devices in various geographical regions, and these devices store a large number of addresses corresponding to domain names. This allows them to retrieve the addresses of the domain names needed for business operations. Typically, under normal circumstances, the addresses of the domain names stored in each domain name resolution device are consistent. Therefore, the first device can pre-store a large number of addresses corresponding to domain names. When the first device has a domain name resolution request for a specific domain name, it can directly retrieve the address corresponding to the domain name from its storage.

[0106] In one implementation, sending the domain name resolution request to the first device can be performed directly by the diagnostic device, or it can be performed by the diagnostic device calling the second device. The second device can refer to a device used to initiate a target service within a geographical area, and this second device can be determined based on the network provider object and the geographical area in the diagnostic request. In one embodiment, the diagnostic personnel can pre-configure multiple devices, each associated with a network provider object and a geographical area; that is, a device can initiate a target service within its associated geographical area and through the network provider object. For example, a mapping relationship between the network provider object, the geographical area, and the device can be pre-configured, as shown in Table 2 below. For example, as shown in Table 2, assuming the network provider object is operator 1 and the geographical area is city 1, the corresponding second device is device 1.

[0107] Table 2

[0108] Network Provider Geographical region equipment Operator 1 City 1 Equipment 1 Operator 1 City 2 Equipment 2 Carrier 2 City 3 Equipment 3 … … …

[0109] In one implementation, step S403 can be achieved by executing a command (or instruction) that has domain name resolution functionality. For example, the command could be the `dig` command or other commands; this embodiment uses the `dig` command as an example. For instance, the format of the `dig` command can be `Dig@{ldns}{domain name}{record type}+retry=5+time={timeout}`; where "ldns" represents the device address of the domain name resolution device (e.g., the device address of the first device), "domain name" represents the target domain name, and "record type" represents the record type the first device needs to obtain when resolving the domain name. The data corresponding to this record type contains the resolution address corresponding to the domain name. For example, this record type can include A records, MX records, NS records, etc. This embodiment mainly uses A records as an example for related explanation. Specifically, the diagnostic device can call the second device to execute the `dig` command to obtain the first resolution address of the network provider for the target domain name. The specific implementation of the dig command by the second device can be understood as follows: The second device can send a domain name resolution request to the first device corresponding to the device address in the dig command. After receiving the domain name resolution request, the first device can retrieve the record data corresponding to the record type (such as an A record) indicated in the dig command from the corresponding storage, and then return the retrieved record data to the second device. After receiving the record data, the second device can forward the record data to the diagnostic device. After receiving the record data, the diagnostic device can also obtain the first resolution address, which is contained in the record data.

[0110] S404, Obtain diagnostic reference data for the target business under the target diagnostic type.

[0111] The diagnostic reference data may include a preset first abnormal address and a second resolved address. The first abnormal address refers to an address that would prevent access to the target address when performing target services based on network attribute information. This first abnormal address can be preset and stored in a designated area, so that it can be directly retrieved from that designated area when data diagnosis is needed using the diagnostic parameter data. For example, the first abnormal address could be 127.0.0.1 or 0.0.0.0, or it could be an address in the anti-fraud center's whitelist, or it could be a specified error code (such as code 0).

[0112] The second resolution address is the address obtained after the business object to which the target business belongs resolves the target domain name. The method for obtaining the second resolution address is similar to that for obtaining the first resolution address. The following provides a detailed explanation of how to obtain the second resolution address. In one implementation, the domain name resolution device used by the business object to resolve the domain name can be determined first. For ease of description later, this domain name resolution device can be referred to as the fourth device. Then, the fourth device can be called to resolve the target domain name, obtaining the resolution address (which can be called the second resolution address) of the business object for the target domain name. The fourth device can refer to a device matching the business object. For any business object, it can be configured with a domain name resolution device for resolving the corresponding domain name. When there is a need for a device for resolving the domain name of a business object, this domain name resolution device can be called to resolve the domain name.

[0113] It should be noted that the specific implementation method for obtaining the second resolved address using the fourth device described above is similar to the specific implementation method for obtaining the first resolved address using the second device described above, and will not be repeated here. The difference between the two lies in the device address corresponding to the device. When obtaining the first resolved address, the device address of the first device is used, while when obtaining the second resolved address, the device address of the fourth device is used. For example, when using the `dig` command to obtain the second resolved address, the device address in the `dig` command is the device address of the fourth device. The device address of the fourth device can also be pre-stored in a storage area, so that when the device address is needed, it can be directly obtained from the storage area.

[0114] S405, perform data diagnosis on intermediate data based on diagnostic reference data to obtain diagnostic results for the target service; the diagnostic results are used to indicate whether the target address can be accessed or not when the target service is executed based on network attribute information, and the target address refers to the address indicated by the target domain name.

[0115] In one implementation, diagnostic reference data can be matched with intermediate data (i.e., the first resolved address) to obtain a diagnostic result for the target service. For example, if the first resolved address is the first abnormal address, the diagnostic result can be determined to indicate that the target address cannot be accessed when performing the target service based on network attribute information. Similarly, if the first resolved address and the second resolved address are different, the diagnostic result can also be determined to indicate that the target address cannot be accessed when performing the target service based on network attribute information.

[0116] In one implementation, when performing data diagnosis on intermediate data based on diagnostic reference data, in addition to determining, as mentioned above, that the diagnostic result indicates the inability to access the target address when executing the target service based on network attribute information, it is also possible to further determine the fault causing the inability to access the target address. That is, the diagnostic result can also include the fault (i.e., the cause) that causes the inability to access the target address. The following is combined with... Figure 5d The diagram illustrates the specific logic (or diagnostic algorithm) for determining faults. Figure 5d In this context, A represents the second resolution address and B represents the first resolution address. Faults may include domain name blocking, anti-fraud center blocking, detector malfunction, domain name hijacking, resolution timeout, resolution anomaly, etc., and may also include other faults. This application embodiment uses the above-mentioned faults as examples for relevant explanation.

[0117] (1) Domain name blocking

[0118] If the first resolved address is 127.0.0.1 or 0.0.0.0 in the first abnormal address, then the failure to access the target address can be determined to be domain name blocking. Domain name blocking refers to the target domain name being blocked and prohibited from use by a certain unit or organization.

[0119] (2) Anti-fraud center blocking

[0120] If the first resolved address exists in the anti-fraud center's whitelist of the first abnormal address, then it can be determined that the failure to access the target address is due to the anti-fraud center blocking.

[0121] (3) Detector malfunction

[0122] If the first resolved address is the specified error code (or exception status code, code 0) in the first abnormal address, then it can be determined that the failure to access the target address is due to a probe malfunction. This is because, in the case of a probe malfunction, the returned data will be the specified error code.

[0123] (4) Domain hijacking

[0124] If the first resolved address differs from the second resolved address, and the first resolved address is not empty, then the inability to access the target address can be attributed to domain hijacking. Domain hijacking can be understood as an internet attack, such as when a domain name resolution device is attacked or forged, potentially causing the target domain name to resolve to an incorrect address.

[0125] (5) Parsing timeout

[0126] If the first resolved address differs from the second resolved address, and the first resolved address is empty, then the failure to access the target address is determined to be due to a timeout in the DNS resolution device of the network provider. The condition that the first resolved address is empty can mean that the diagnostic device fails to obtain the first resolved address within a preset time and a preset number of retries. The preset time and preset number of retries can be preset. For example, if the preset time is 30 seconds and the preset number of retries is 5, then if the diagnostic device still fails to obtain a resolution result after 5 retries within 30 seconds, then the failure to access the target address is determined to be due to a timeout in the DNS resolution device of the network provider.

[0127] (6) Parsing error

[0128] In addition to the five types of faults described above that cause the inability to access the target address, the following faults may also exist. In one embodiment, the domain name resolution device used for domain name resolution (such as the second and fourth devices mentioned above) may also experience resolution anomalies. In this case, both the first and second resolution addresses are empty; that is, if both the first and second resolution addresses are empty, it can be determined that the fault causing the inability to access the target address is a resolution anomaly.

[0129] In one implementation, the first diagnostic interface of the diagnostic platform may further include a fault reproduction area, such as... Figure 5a The area marked with 52; the fault reproduction area can be used to display the data involved when performing data diagnostics for domain name diagnostic types. For example, as... Figure 5a The fault reproduction area 52 shown can display the operator, monitoring point, monitoring point IP, target domain name, resolution time, baseline resolution result, and operator's resolution result. Here, the operator refers to the network provider, the monitoring point refers to a geographical region, the monitoring point IP refers to the device address of the diagnostic equipment, the resolution time refers to the time of performing data diagnostics for the domain name diagnostic type, the baseline resolution result refers to the result of resolving the target domain name using the target service's business object (i.e., the second resolution address), and the operator's resolution result refers to the result of resolving the domain name using the network provider (i.e., the first resolution address). For example, as shown... Figure 5eThe image shows the data displayed in fault reproduction area 52 after completing the data diagnosis for the domain name diagnostic type. As can be seen, displaying data in the fault reproduction area allows for the reproduction of various data involved when a network fault occurs, enabling diagnostic personnel to quickly understand the data involved in this domain name diagnostic. Furthermore, displaying the DNS resolution results in this area allows diagnostic personnel to directly predict faults based on the resolution results.

[0130] In one implementation, the first diagnostic interface of the diagnostic platform may further include a fault prediction area, such as... Figure 5a The area marked with 53; this fault prediction area can be used to display the diagnostic results of data diagnostics performed on the domain name diagnostic type. For example, as shown... Figure 5f The results shown are for the domain name diagnostic type. Figure 5f The message "City 1 - Operator 1: LDNS (219.141.140.10), resolution normal" indicates that domain name resolution using the domain name resolution device (device address 219.141.140.10) corresponding to City 1 and Operator 1 is normal. Therefore, it means that when performing domain name diagnosis for the target domain "www.123.com", the network provider is "Operator 1", and the geographical region is "City 1", the target domain name is without fault. It can be seen that displaying the diagnostic results in the fault prediction area allows diagnostic personnel to quickly understand the diagnostic results of data diagnosis for the target business under the target diagnostic type, thereby improving user experience.

[0131] In one implementation, the first diagnostic interface of the diagnostic platform may further include a fault registration area, such as... Figure 5a The area marked with 54; this fault creation area can be used to display a work order, which includes the data involved in data diagnosis for the domain name diagnosis type. For example, as shown... Figure 5g The image shows a work order displayed in the fault creation area. This work order may include information such as the work order title 507, the work order creation time 508, and the fault description for the domain name diagnosis type 509. The fault description may include the diagnosis results, which may refer to the fault that causes the inability to access the target address, the cause of the fault, the solution to the fault, the comparison of resolution results (first resolution address and second resolution address), etc.

[0132] In one embodiment, the fault creation area may include creation controls (such as...) Figure 5aThe fault order creation area 54 displays the "Click to automatically create work order" control; when the order creation control is triggered, the diagnostic platform can send a work order creation request to the diagnostic device, so that the diagnostic device can respond to the work order creation request and create the corresponding work order. The following is combined with... Figure 5h The process describes the work order creation process. Specifically, after the diagnostic device receives the work order creation request, it can obtain the diagnostic results and process them using preset work order creation rules to generate a work order. Alternatively, it can be understood as formatting the diagnostic results to automatically generate a work order. Result formatting involves processing the diagnostic results using preset work order creation rules to obtain information for generating the work order. This information may include the work order title, a comparison of parsing results, a preliminary diagnosis (such as faults in the diagnostic results), and a handling method. After obtaining this information, the work order can be automatically created (i.e., generated) and archived (i.e., stored). After the diagnostic device successfully creates the work order, it can return it to the diagnostic platform so that the platform can display the work order in the fault work order area. In another embodiment, work order creation can be automatically triggered after the diagnostic results are determined. The created work order can be archived so that it can be directly retrieved from the archive after receiving a work order creation request.

[0133] In one embodiment, the interface parameters in the work order creation request for the target diagnostic type of the target business can be seen as follows: Figure 6a As shown, where, as Figure 6a The data shown represents the relevant interface parameters for the work order creation request when creating a work order. For an understanding of these parameters, please refer to [link / reference needed]. Figure 5c The understanding of the corresponding parameters will not be elaborated here. In the request example, `TicketType` indicates the domain diagnosis type (e.g., the domain diagnosis type description is "domain name resolution failure"). `Title` indicates the ticket title (e.g., the ticket title could be "[www.123.com][Operator 3] City 1 Domain Hijacking"). `FaultDesc` indicates the fault details description, which is used to request the relevant data displayed in the data diagnosis (e.g., resolution results (first and second resolution results), handling methods, etc.). `ExigenceLevel` indicates the ticket level (e.g., level 3), which indicates the urgency of the ticket creation. This ticket level can be entered in the fault creation area, such as... Figure 5aThe fault creation area 54 shown contains a work order level input field, where diagnostic personnel can enter the corresponding work order level. CreateTime indicates the time the work order was created (e.g., 2022-07-18 10:35:11), Origin indicates the source of the work order (e.g., the source could be the name of the diagnostic platform, Xxx), and Creator indicates the username of the person who created the work order (e.g., the username could be admin).

[0134] In one implementation, the first diagnostic interface of the diagnostic platform may further include a recovery detection area, such as... Figure 5a The area marked with 55 is the recovery detection area. This area displays network recovery results (or fault recovery results) in cases where the target address cannot be accessed or a fault exists. Besides directly displaying network recovery status, the recovery detection area can also display data from one or more of the aforementioned fault reproduction, fault prediction, and fault reporting areas, allowing for a detailed understanding of the data involved in the recovery detection process and the specific network recovery status.

[0135] In one embodiment, the recovery detection area may include recovery detection controls (such as...) Figure 5a The recovery detection area 55 displays the "Click to Start Detection" control; when the recovery detection control is triggered, the diagnostic platform can send a recovery detection request to the diagnostic device, enabling the diagnostic device to respond to the recovery detection request and determine the corresponding network recovery result. The following is combined with... Figure 6b The process describes the network recovery detection. Specifically, when the recovery detection control is triggered (i.e., a diagnostic task is generated), the diagnostic platform can obtain the diagnostic parameters in the diagnostic parameter input area during data diagnosis of the target business's domain name diagnostic type. These parameters are then used to perform data re-diagnosis (or network recovery detection) and obtain the corresponding network recovery result. This result indicates whether the network has recovered or not. After the diagnostic device determines the network recovery result, it can return the result to the diagnostic platform, allowing the platform to receive and display it in the recovery detection area. This provides diagnostic personnel with a clear understanding of the network recovery status, improving the user experience.

[0136] The specific implementation method for using these diagnostic parameters to re-diagnose data and obtain the corresponding network recovery result, as mentioned above, can be as follows: First, the diagnostic platform can generate a recovery detection request based on the diagnostic parameters. This recovery detection request may also include the same parameters as the diagnostic request (i.e., target domain name, network provider, and geographical region). Then, the diagnostic platform can send the recovery detection request to the diagnostic device, so that the diagnostic device can determine the network recovery result for the target service under the target diagnostic type based on the recovery detection request. The implementation method of the diagnostic device determining the network recovery result for the target service under the domain name diagnostic type based on the recovery detection request is similar to the method of the diagnostic device determining the diagnostic result for the target service under the domain name diagnostic type based on the diagnostic request. For example, the diagnostic result for the data re-diagnosis can be determined based on the resolution results of the service object, the resolution results of the network provider, and the diagnostic reference data obtained during the data re-diagnosis process. The difference is that the network recovery result here is determined based on the diagnostic results. If the diagnostic result indicates that the target address can be accessed when executing the target service based on the network attribute information, the network recovery result is "recovered"; if the diagnostic result indicates that the target address cannot be accessed when executing the target service based on the network attribute information, the network recovery result is "not recovered".

[0137] In one embodiment, the interface parameters in the recovery detection request for the target diagnostic type of the target business can be seen as follows: Figure 6c As shown, where, as Figure 6c The data shown represents the relevant interface parameters for the recovery detection request during fault recovery detection. For an understanding of these parameters, please refer to [link to relevant documentation / reference]. Figure 5c The understanding of the corresponding parameters will not be elaborated here. In the request example, TicketType indicates the domain diagnosis type (e.g., the domain diagnosis type is described as domain name resolution anomaly), TaskId indicates the ID number of the recovery detection task (e.g., the ID number can be 21), TicketId indicates the number of the recovery detection task (e.g., the number can be 202207180000004), CreateTime indicates the time when the fault recovery detection was generated (e.g., the generation time can be 2022-07-18 10:35:11), Origin indicates the source of the fault recovery detection (e.g., the source can be the name of the diagnostic platform), and Creator indicates the username of the person performing the fault recovery detection (e.g., the username can be admin).

[0138] It's important to understand that after technicians restore network functionality, the customer still needs to confirm whether the recovery was successful. Traditionally, this confirmation process is slow, requiring the customer to re-execute the target service and repeatedly interact with the service provider to verify the results, typically taking hours (e.g., 4 hours). However, by performing fault recovery testing directly on the diagnostic platform, customer confirmation time can be reduced to minutes. After reproducing the network anomaly and obtaining the corresponding diagnostic results, technicians can resolve the fault. After resolving the fault, the diagnostic personnel can then perform another test on the diagnostic platform (e.g., initiating a recovery test request) to determine if the fault has been successfully recovered, eliminating the need for customer intervention and thus reducing confirmation time.

[0139] To better understand the data diagnostic process for the domain name diagnostic type (DNS diagnostic type) for the target business provided in the embodiments of this application, the following is combined with Figure 6d This section further elaborates on data diagnostics for domain name diagnostic types targeting specific business needs. For example... Figure 6d As shown, for domain name diagnostics, the `dig` command can be executed to obtain the resolution results under two different scenarios (i.e., the first and second resolved addresses). The `dig` commands corresponding to these two scenarios are: the `dig` command for the business object and the `dig` command for the network provider object, respectively. After obtaining the two resolution results (e.g., by comparing the two resolution results), the fault corresponding to the inability to access the target address can be determined. This fault can include any one of the following: domain name blocking, anti-fraud center blocking, domain name hijacking, resolution anomaly, resolution timeout, and probe machine anomaly. The method for determining the fault can be referred to the above description and will not be repeated here.

[0140] In one implementation, it can also be combined with Figure 6e This section further elaborates on data diagnostics for domain name diagnostic types targeting specific business needs. For example... Figure 6eAs shown, after the diagnostic device receives a diagnostic request for the domain name diagnostic type targeting the target business, it can filter devices based on the network provider object (e.g., an operator) and geographical region (e.g., a province) included in the diagnostic request. The filtered devices are the second devices described above, which can be used to execute specific commands to obtain intermediate data. After filtering devices, commands (instructions) can be assembled, which are the `dig` commands. The parameters involved in the `dig` command can be referred to the above description and will not be repeated here. The `dig` command here includes two different commands: one related to the business object and the other related to the network provider object. The device address in the `dig` command related to the business object is the address of the domain name resolution device that can be used for domain name resolution within the target business object. The device address in the `dig` command related to the network provider object is the address of the domain name resolution device that can be used for domain name resolution within the geographical region and within the network provider object. In other words, it is necessary to use the domain name resolution device corresponding to the business object and the domain name resolution device corresponding to the network provider object to obtain two resolution results (the first resolution result and the second resolution result).

[0141] After the aforementioned equipment selection and assembly command operations, the second device and its corresponding `dig` command are obtained. Further, the diagnostic device can invoke the agent corresponding to the second device to execute the `dig` command and obtain the corresponding parsing results. After obtaining the parsing results, the second device can transmit the results to the diagnostic platform's data storage center via a JSON interface for data storage. A message queue (such as Kafka) can be used for transmitting the parsing results. The data in the data storage center can be used for displaying relevant data on the diagnostic platform, such as the data displayed in the aforementioned fault reproduction area and fault order creation area.

[0142] In this embodiment, a diagnostic platform can be used to perform data diagnosis under the domain name diagnostic type, thereby achieving automated data diagnosis and improving diagnostic intelligence. Furthermore, diagnostic reference data can be obtained for data analysis, allowing diagnosis to proceed according to pre-set diagnostic rules, thus eliminating tedious and error-prone manual diagnostic operations and improving diagnostic efficiency and accuracy. Practical experience shows that the efficiency of fault diagnosis through the diagnostic platform can be reduced from hours (manual diagnostic operations) to minutes.

[0143] Please see Figure 7This is a flowchart illustrating another data diagnostic method provided in this application embodiment. This application embodiment primarily uses a diagnostic device as the execution subject, and the target diagnostic type refers to the type of network diagnostic performed on the target service (such as Ping diagnostic type or port diagnostic type) as an example; please refer to... Figure 7 The data diagnostic method includes, but is not limited to, the following steps:

[0144] S701 receives a diagnostic request from the diagnostic platform for the target diagnostic type of the target business.

[0145] The diagnostic request includes the target domain name to be invoked to execute the target service, and the network attribute information of the network used to execute the target service. The network attribute information may include the geographical region to which the network used to execute the target service belongs and the network provider.

[0146] It is understood that the target diagnostic type here refers to the type of diagnosis performed on the network executing the target service. The types of network diagnostics can include Ping diagnostics and port diagnostics. For ease of description, the diagnostic interface corresponding to the Ping diagnostic type can be referred to as the second diagnostic interface, and the diagnostic interface corresponding to the port diagnostic type can be referred to as the third diagnostic interface. The second and third diagnostic interfaces are similar to the first diagnostic interface, and both can include input areas for diagnostic parameters, fault reproduction areas, fault prediction areas, fault case creation areas, and recovery detection areas. The specific content displayed in each area of ​​the diagnostic interface may differ for different target diagnostic types. The following sections will elaborate on obtaining diagnostic requests under the Ping diagnostic type and the port diagnostic type.

[0147] (1) In the case of Ping diagnostic type

[0148] In one implementation, when a diagnostician needs to perform data diagnostics on a Ping diagnostic type, the diagnostician can perform relevant operations in the diagnostic parameter input area of ​​the second diagnostic interface for the Ping diagnostic type on the diagnostic platform. This allows the diagnostic platform to obtain a diagnostic request for the Ping diagnostic type specific to the target business. For example, the diagnostic platform can obtain the diagnostic parameters entered by the diagnostician in the diagnostic parameter input area of ​​the second diagnostic interface and can generate a diagnostic request for the Ping diagnostic type specific to the target business based on these parameters. After obtaining the diagnostic request, the diagnostic platform can send it to the diagnostic device. For example, the diagnostic parameter input area in the second diagnostic interface can be seen as follows: Figure 8a As shown, this diagnostic parameter input area can be connected to the diagnostic parameter input area in the first diagnostic interface (e.g., ...). Figure 5bSimilarly, the relevant understanding can be found in the above description. For example, diagnostic personnel can input business assurance information in this area, such as entering a target domain name (or target address), selecting an operator, and then selecting a region or city. After that, they can trigger the "Click Submit" control so that the diagnostic platform can obtain the diagnostic parameters entered by the diagnostic personnel.

[0149] In one embodiment, the interface parameters in a Ping diagnostic request for a target service can be seen as follows: Figure 8b As shown, where, as Figure 8b The data shown represents the relevant interface parameters for the diagnostic request under the Ping diagnostic type (which can also be understood as creating a Ping diagnostic task). For an understanding of these parameters, please refer to [link to relevant documentation]. Figure 5c The understanding of the corresponding parameters will not be elaborated here.

[0150] (2) In the case of port diagnostic type

[0151] In one implementation, when a diagnostician needs to perform data diagnostics on a port diagnostic type, the diagnostician can perform relevant operations in the diagnostic parameter input area of ​​the third diagnostic interface for that port diagnostic type within the diagnostic platform. This allows the diagnostic platform to obtain a diagnostic request for the port diagnostic type specific to the target service. For example, the diagnostic platform can obtain the diagnostic parameters entered by the diagnostician in the diagnostic parameter input area of ​​the third diagnostic interface and generate a diagnostic request for the port diagnostic type specific to the target service based on these parameters. After obtaining the diagnostic request, the diagnostic platform can send it to the diagnostic device. For example, the diagnostic parameter input area of ​​the third diagnostic interface can be seen as follows: Figure 8c As shown. Compared to the diagnostic parameter input areas for ping or domain name diagnostic types, the diagnostic parameter input area for port diagnostic types can also contain input items for inputting the port, such as... Figure 8c The "80" in the text indicates that the port is 80. Based on this, it can be seen that in the case of port diagnostics, network attribute information can also include the port to which the network performing the target service belongs.

[0152] In one embodiment, the interface parameters in the diagnostic request for the port diagnostic type targeting the service can be seen as follows: Figure 8d As shown. For an understanding of the relevant parameters here, please refer to... Figure 5c The understanding of the corresponding parameters will not be elaborated here.

[0153] S702, Identify a second device for initiating a target service within a geographic area.

[0154] The specific implementation of this step can be found in the description of step S403 for determining the second device, and will not be repeated here.

[0155] S703, the second device is invoked to send the first test data to the third device using the network provided by the network object, so that the second device can obtain the address data generated during the transmission of the first test data to the third device.

[0156] The third device refers to a device that can be used to generate business data for the target service. The first test data is data used to test whether the network between the second and third devices is normal. The first test data can refer to data packets, and the number of data packets is not limited. There can be at least one relay device between the second and third devices for transmitting the first test data. The address data generated during the transmission of the first test data can include: the device address of the second device, the device address of each relay device, and the device address to which the first test data is transmitted from the device address of the third device.

[0157] In one implementation, the diagnostic device can invoke a second device to send at least one second test data to a third device using the network provided by a network object. This allows the second device to obtain the packet loss rate for the at least one second test data. The second test data is used to test whether the network between the second and third devices is functioning correctly; one second test data item can refer to a single data packet. After receiving the packet loss rate, the second device can return it to the diagnostic device, meaning the diagnostic device receives the packet loss rate returned by the second device. If the packet loss rate is greater than or equal to a packet loss rate threshold, it can be determined that there is an anomaly in the network between the second and third devices. For example, if the target diagnostic type is a Ping diagnostic type, the anomaly could indicate a network outage; if the target diagnostic type is a port diagnostic type, the anomaly could indicate a port outage. The packet loss rate threshold can be 100%. After the diagnostic device determines that there is an anomaly in the network between the second and third devices, it can further invoke the second device to send first test data to the third device using the network provided by a network object. This allows the diagnostic device to obtain the address data generated during the transmission of the first test data from the second device to the third device and perform subsequent data diagnostics based on this address data. If the packet loss rate is less than the packet loss rate threshold, it can be determined that the network between the second and third devices is normal. In this case, there is no need to call the process of the second device sending the first test data, and the data diagnosis process can be terminated.

[0158] In one implementation, step S703 can be achieved by executing a command. For example, the command could be the `mtr` command. For instance, if the target diagnostic type is Ping diagnostic, the format of the `mtr` command could be `mtr-nr{target address}`; if the target diagnostic type is port diagnostic, the format of the `mtr` command could be `mtr-nr{target address}-P{target port}`. Here, the target port is the data entered in the port input field of the diagnostic parameter input area. Specifically, the diagnostic device can call a second device to execute the `mtr` command to obtain the address data generated during the transmission of the first test data to the third device. The specific implementation of the second device executing the `mtr` command can be understood as follows: the second device can transmit the first test data to the third device at the target address indicated in the `mtr` command. During the transmission, the first test data can pass through at least one relay device, and the following address data can be generated during the transmission of the first test data: the device address of the second device, the device address of each relay device, and the device address to which the first test data is transmitted from the device address of the third device. This address data is also known as intermediate data. After obtaining the intermediate data, the second device can forward the intermediate data to the diagnostic device, which can then acquire the intermediate data.

[0159] In one implementation, as described above, before invoking the second device to transmit the first test data, the diagnostic device can invoke the second device to transmit the second test data to determine if there are any network anomalies. The specific implementation process of invoking the second device to transmit the second test data to determine if there are network anomalies can also be executed using a single command. That is, before executing the `mtr` command, the second device can first be invoked to execute a command for diagnosing whether the network is abnormal; for example, if the target diagnostic type is Ping diagnostic, the command can be the `ping` command; if the target diagnostic type is port diagnostic, the command can be the `tcpping` command. For example, the format of the `ping` command can be `ping -c{number of packets} -i{interval} -s{packet size}{target address}`; where the number of packets refers to the number of second test data (or the number of data packets), the interval refers to the interval between sending data packets, and the packet size refers to the size of a single data packet. For example, the format of the `tcpping` command can be `tcpping{target address}{target port}`.

[0160] In practice, the diagnostic device can invoke a second device to execute the ping command to obtain the packet loss rate. Specifically, the second device executing the ping command can be understood as follows: the diagnostic device can invoke the second device to send at least one second test data point to the third device using the network provided by the network object, thereby obtaining the packet loss rate for that at least one second test data point. After obtaining the packet loss rate, the second device can return it to the diagnostic device, allowing the diagnostic device to receive the returned packet loss rate. Upon receiving the packet loss rate, the diagnostic device can determine whether to execute the mtr command based on this rate. For example, if the packet loss rate is greater than or equal to a packet loss rate threshold, it can be determined that there is an anomaly in the network between the second and third devices, and the second device can be invoked to execute the mtr command. If the packet loss rate is less than the packet loss rate threshold, it can be determined that the network between the second and third devices is normal, and the second device does not need to be invoked to execute the mtr command.

[0161] S704, receive the address data generated during the transmission of the first test data returned by the second device, and determine the address data generated during the transmission of the first test data as intermediate data.

[0162] S705, Obtain diagnostic reference data for the target business under the target diagnostic type.

[0163] It should be noted that the diagnostic reference data under the Ping diagnostic type and the port diagnostic type is the same.

[0164] The diagnostic reference data may include a preset second abnormal address, which can be an address that would prevent access to the target address when performing the target service based on network attribute information. For example, the second abnormal address could be 202.97.0.0, 219.158.0.0, or 221.183.0.0.

[0165] S706 performs data diagnosis on intermediate data based on diagnostic reference data to obtain diagnostic results for the target service; the diagnostic results are used to indicate whether the target address can be accessed or not when the target service is executed based on network attribute information, and the target address refers to the address indicated by the target domain name.

[0166] In one implementation, if the intermediate data contains a second abnormal address, the diagnostic result can be determined to be a result indicating that the target address cannot be accessed when performing the target service based on network attribute information; if the device address to which the first test data in the intermediate data was last transmitted is not the device address of the third device, the diagnostic result can be determined to be a result indicating that the target address cannot be accessed when performing the target service based on network attribute information.

[0167] In one implementation, when performing data diagnosis on intermediate data based on diagnostic reference data, in addition to determining that the diagnostic result indicates the inability to access the target address when executing the target service based on network attribute information, as mentioned above, the fault causing the inability to access the target address can be further identified. The fault may include backbone network anomalies of the network provider (e.g., operators), network anomalies of the service object, IDC (Internet Data Center) anomalies, provincial backbone network anomalies of the network provider (e.g., operators), and other faults. This application uses the above-mentioned faults as examples for relevant description. It should be noted that the provincial backbone network anomaly of the network provider here can refer to the provincial backbone network anomaly of the network provider in the geographical area where the target address is located. For example, assuming the geographical area is in a certain city, the provincial backbone network anomaly of the network provider can refer to the provincial backbone network anomaly of the network provider in that city. Alternatively, this fault can be simply referred to as the destination provincial backbone network anomaly.

[0168] It's important to understand that when the first data transmission moves from the second device to the third device, it typically utilizes both the network providing the data and the network of the service object. For example, assuming the second device is in city 1 and the third device is in city 2, the networks traversed to transmit the first data from the second device in city 1 to the third device in city 2 could sequentially include the IDC network, the provincial backbone network of the operator in city 1, the operator's backbone network, the provincial backbone network of the operator in city 2, the IDC network, and the network of the service object. Correspondingly, the device addresses included in the intermediate data can include the device addresses of devices within these networks.

[0169] (1) Abnormalities in the backbone network of the network provider (such as the operator).

[0170] If a second abnormal address is found in the intermediate data, the failure causing the inability to access the target address can be identified as a backbone network failure of the network provider (such as an operator). The second abnormal address used to determine the backbone network failure varies depending on the network provider. For example, taking an operator as the network provider, if the intermediate data contains the second abnormal address 202.97.0.0, the failure is identified as a backbone network failure of operator 1; if it contains the second abnormal address 219.158.0.0, the failure is identified as a backbone network failure of operator 2; and if it contains the second abnormal address 221.183.0.0, the failure is identified as a backbone network failure of operator 3.

[0171] (2) Network anomaly of the business object

[0172] If the last device address in the intermediate data is the device address of a device under the business object, then the failure to access the target address is likely due to a network anomaly of the business object. Based on the above description of the network involved in the transmission of the first data, it can be understood that the first data should be able to be transmitted to the third device under normal network conditions. However, in this case, the last device address is the address of the device to which the first data is transmitted, and this device and the third device both belong to the same business object. Therefore, a network anomaly has occurred between this device and the third device, meaning a network anomaly has occurred within the business object.

[0173] (3) The provincial backbone network of the network provider is abnormal (the destination provincial backbone network is abnormal).

[0174] If the last device address in the intermediate data is not the device address of a device under the service object, but the device address of a device in the backbone network of the network provider object, then the fault that prevents access to the target address may be due to an anomaly in the provincial backbone network of the network provider object (such as the operator). It can be understood that if the last device address is not the device address of a device under the service object, then the fault is not due to a network anomaly of the service object. If the last device address is the device address of a device in the backbone network of the network provider object, then there is an anomaly between the backbone network of the network provider object and the target provincial backbone network. If the anomaly in the backbone network of the network provider object is as described in (1), then it can be determined that there is an anomaly in the target provincial backbone network.

[0175] (4) IDC anomaly

[0176] If the last device address in the intermediate data is not the device address of a device under the business object, and the intermediate data does not contain the device address of a device in the backbone network of the network provider object, then the failure to access the target address is likely due to an IDC anomaly. It is understandable that if the last device address is not the device address of a device under the business object, then the failure is not a network anomaly of the business object. Furthermore, if the intermediate data does not contain the device address of a device in the backbone network of the network provider object, then the first transmission data is only transmitted to the network between the backbone networks of the network provider object, thus the failure is likely due to an IDC anomaly.

[0177] Alternatively, if the last device address in the intermediate data is not the device address of a device under the business object, and the intermediate data contains the device address of a device in the backbone network of the network provider object, but the last device address is not the device address of a device in the provincial backbone network of the network provider object, then the fault causing the inability to access the target address is likely due to an IDC anomaly. It can be understood that if the last device address is not the device address of a device under the business object, then the fault is not a network anomaly of the business object. If the intermediate data contains the device address of a device in the backbone network of the network provider object, then the first transmitted data has been transmitted to the network after the backbone network of the network provider object. And if the last device address is not the device address of a device in the provincial backbone network of the network provider object, then the first transmitted data has passed through the destination provincial backbone network, meaning the destination provincial backbone network is not abnormal. Therefore, the fault is likely due to an IDC anomaly.

[0178] (5) Unknown anomalies

[0179] If the intermediate data does not meet the conditions of (1)-(4) above, it can be determined that the fault that causes the inability to access the target address is an unknown anomaly. In this case, the fault can be further determined by manually judging the mtr results or traceroute results.

[0180] The following combination Figure 8e The fault diagnosis logic is explained in detail. Figure 8e The mtr results contain intermediate data; such as Figure 8e The list of IPs (IP1, IP2, ..., IPn) in the MTR results for a specific city can be understood as intermediate data; the last echoed IP can refer to the device address of the device to which the first transmitted data was finally sent. For example... Figure 8e As shown, the fault diagnosis logic can include the following 6 steps:

[0181] 1. Diagnostic equipment can obtain the IP list from the MTR results;

[0182] 2. The diagnostic equipment determines whether 202.97.0.0, 219.158.0.0, or 221.183.0.0 belongs to the IP list. If 202.97.0.0 is determined to belong to the IP list, the fault is identified as a backbone network anomaly of Operator 1. If 219.158.0.0 is determined to belong to the IP list, the fault is identified as a backbone network anomaly of Operator 2. If 221.183.0.0 is determined to belong to the IP list, the fault is identified as a backbone network anomaly of Operator 3. If none of the above conditions are met, proceed to step 3.

[0183] 3. The diagnostic device determines whether the last echoed IP in the IP list is the IP of the service object device (i.e., the device address of the device under the service object). If it is, the fault can be determined to be a network anomaly of the service object. If not, continue to step 4 or 5.

[0184] 4. The diagnostic device determines whether the last echoed IP in the IP list is a backbone IP of the operator (i.e., the device address of the device in the operator's backbone network). If it is, the fault is determined to be an anomaly in the destination provincial backbone network. If not, the fault is determined to be an unknown anomaly.

[0185] 5. The diagnostic equipment checks if the carrier's backbone IPs exist in the IP list. If not, the fault is identified as an IDC anomaly. If they exist, proceed to step 6.

[0186] 6. Diagnose the device to determine if the last echoed IP in the IP list is a provincial backbone IP (i.e., the device address of the device in the destination provincial backbone network). If not, the fault can be determined to be an IDC anomaly. If it is, the fault can be determined to be an unknown anomaly.

[0187] It should be noted that the method of determining the diagnostic results and the logic of judging the fault are the same under the Ping diagnostic type and the port diagnostic type (i.e., the situations described above (1)-(5)).

[0188] It should be noted that the various areas in the second and third diagnostic interfaces display relevant data in a similar manner, so the following description will mainly focus on the various areas in the second diagnostic interface.

[0189] In one implementation, the second diagnostic interface of the diagnostic platform may further include a fault reproduction area, for example, the fault reproduction area may be as follows: Figure 9a As shown, Figure 9a This demonstrates the data display of the fault reproduction area after completing a data diagnosis for the Ping diagnostic type. The fault reproduction area can include a first partition 901 and a second partition 902. The first partition 901 can display the geographical area corresponding to the network fault on a map (which can be simply referred to as the fault area). For example, the fault area and non-fault areas on the map can be distinguished by different colors or other methods. The second partition 902 can display relevant data related to the fault area, such as monitoring points, monitoring point IPs, ISPs, target addresses, packet loss rate, and diagnostic results.

[0190] Optionally, the fault reproduction area can also display the MTR results corresponding to the MTR command (including intermediate data) and a data transmission diagram (topology diagram) of the first test data between the second and third devices. This data transmission diagram shows the various devices through which the first test data passes, allowing diagnostic personnel to clearly understand the routing of data between devices during transmission and to identify the specific cause of the fault based on this data. For example, when diagnostic personnel need to view the MTR results and data transmission diagram, they can click or press a specified area to trigger the display of this data; for example, if the diagnostic personnel clicks on... Figure 9a Position 903 in the diagram will also display data 904 in the fault reproduction area. Data 904 contains the mtr results and data transmission graph. The mtr results can include eight columns of data. The first column (Host) displays the IP address or hostname, which is the intermediate data; the second column (Loss%) represents the packet loss rate of this node; the third column (Snt) represents the number of packets sent; the fourth column (Last) represents the most recent latency in milliseconds (ms); the fifth column (Avg) represents the average latency in milliseconds (ms); the sixth column (Best) represents the minimum latency in milliseconds (ms); the seventh column (Wrst) represents the maximum latency in milliseconds (ms); and the eighth column (StDev) represents the standard deviation.

[0191] In one implementation, the second diagnostic interface of the diagnostic platform may further include a fault prediction area, for example, the fault prediction area may be as follows: Figure 9b As shown, Figure 9b This displays the data in the fault prediction area after completing data diagnosis for the Ping diagnostic type. This fault prediction area can be used to display the diagnostic results for the Ping diagnostic type, for example... Figure 9b The message “City 1 - Operator 1: IDC anomaly” indicates that when performing the target service based on City 1 and using the network of Operator 1, the target address cannot be accessed, and the corresponding fault is IDC anomaly.

[0192] In one implementation, the second diagnostic interface of the diagnostic platform may further include a fault creation area, which can be used to display a work order containing data related to data diagnosis for the Ping diagnostic type. For example, the fault creation area can be as follows: Figure 9c As shown, Figure 9c This demonstrates the work order display in the fault creation area after completing a data diagnosis for the Ping diagnostic type. The data types included in this work order are the same as those displayed in the fault creation area of ​​the first diagnostic interface (e.g., ...). Figure 5g The data types are similar, such as the work order title, the work order creation time, the diagnostic results for the domain name diagnostic type, etc.

[0193] In one embodiment, the specific implementation process of creating a test order under the Ping diagnostic type is similar to the specific implementation process of creating a test order under the domain name diagnostic type mentioned above, and will not be repeated here; for example, the specific implementation process of creating a test order under the Ping diagnostic type can be as follows: Figure 9d As shown.

[0194] In one embodiment, the interface parameters in the Ping diagnostic type work order creation request for the target business can be seen as follows: Figure 9e As shown, where, as Figure 9e The data shown represents the relevant interface parameters for the work order creation request when creating a work order. For an understanding of these parameters, please refer to [link / reference needed]. Figure 5c The understanding of the corresponding parameters will not be elaborated here.

[0195] In one implementation, the second diagnostic interface of the diagnostic platform may further include a recovery detection area. This recovery detection area can be used to display network recovery results in cases where the target address cannot be accessed or a fault exists. In addition to directly displaying the network recovery status, the recovery detection area can also display data from one or more of the fault reproduction area, fault prediction area, and fault registration area mentioned above in the second diagnostic interface, allowing for a detailed understanding of the data involved in the recovery detection process and the specific network recovery status.

[0196] In one embodiment, the recovery detection area may include a recovery detection control; when the recovery detection control is triggered, the diagnostic platform may send a recovery detection request to the diagnostic device, enabling the diagnostic device to respond to the recovery detection request and determine the corresponding network recovery result. For example, the specific implementation process of the diagnostic device performing network recovery detection under the Ping diagnostic type can be as follows: Figure 9f As shown in the diagram. In the specific implementation, when the recovery detection control is triggered, the diagnostic platform can obtain the diagnostic parameters in the diagnostic parameter input area when performing data diagnosis of the Ping diagnostic type for the target service. It can then use these diagnostic parameters to re-diagnose the data and obtain the corresponding network recovery result. The implementation method of the diagnostic device determining the network recovery result for the target service under the Ping diagnostic type based on the recovery detection request is similar to the method of the diagnostic device determining the diagnostic result for the target service under the Ping diagnostic type based on the diagnostic request, and will not be elaborated further.

[0197] In one embodiment, the interface parameters in a Ping diagnostic type recovery detection request for the target service can be found as follows: Figure 9g As shown, where, as Figure 9g The data shown represents the relevant interface parameters for the recovery detection request during network recovery detection. For an understanding of these parameters, please refer to [link to relevant documentation / reference]. Figure 5c The understanding of the corresponding parameters will not be elaborated here.

[0198] To better understand the data diagnostics provided in this application's embodiments for the Ping diagnostic type and port diagnostic type targeting the target service, the following is combined with... Figure 9h The paper further elaborates on data diagnostics for Ping diagnostic types and port diagnostic types targeting specific services. In one embodiment, for data diagnostics of the Ping diagnostic type, such as… Figure 9h As shown, intermediate data can be obtained by executing the ping and mtr commands. After obtaining the intermediate data, it can be used as a basis, with the backbone network anomaly of the network provider as the dividing line, to determine the fault corresponding to the inability to access the target address (e.g., Figure 8e The fault may include Figure 9h Any of the ones shown. In one embodiment, such as Figure 9h The implementation process for data diagnosis of port diagnosis type is similar to that for data diagnosis of Ping diagnosis type, except that intermediate data can be obtained using the tcpping and mtr commands.

[0199] In one implementation, it can also be combined with Figure 9i This section further elaborates on data diagnostics of the Ping diagnostic type targeting specific business needs. For example... Figure 9iAs shown, after the diagnostic device receives a Ping diagnostic request for the target service, it can filter devices based on the network provider (e.g., a carrier) and geographical region (e.g., a city) included in the diagnostic request. The filtered devices are the second devices described above. After filtering devices, a command can be assembled, which is the ping command. Then, the diagnostic device can call the agent corresponding to the second device to execute the ping command to obtain the corresponding probe results, i.e., the results obtained after executing the ping command, which include the packet loss rate. Further, probe results with a packet loss rate greater than or equal to a preset packet loss rate can be filtered out. For example, probe results with a packet loss rate of 100% can be filtered out. After filtering out such probe results, the device corresponding to the probe result can be determined, i.e., the device that executed the ping command (e.g., the second device). Next, an mtr command can be assembled to call the agent corresponding to the second device to execute the mtr command, thereby obtaining the mtr result (or intermediate data). The second device can transmit the parsed results to the data storage center of the diagnostic platform via Kafka through a JSON interface for data storage.

[0200] In one implementation, such as Figure 9j The diagram shows the data diagnostic process for the port diagnostic type of the target service. This process performs data diagnostics similar to the Ping diagnostic type described above. Figure 9i The process shown is similar, so the process of data diagnosis for port diagnosis types will not be described in detail here.

[0201] In this embodiment, a diagnostic platform can be used to perform data diagnostics under Ping and port diagnostic types, thereby achieving automated data diagnostics and improving diagnostic intelligence. Furthermore, diagnostic reference data can be obtained for data processing, allowing diagnostics to be performed according to pre-set diagnostic rules, thus eliminating tedious and error-prone manual diagnostic operations and improving diagnostic efficiency and accuracy. Practical experience shows that the efficiency of fault diagnosis through the diagnostic platform can be improved from hours (manual diagnostic operations) to minutes.

[0202] Please see Figure 10 This is a schematic diagram of a data diagnostic device provided in an embodiment of this application. The data diagnostic device described in this embodiment includes:

[0203] The receiving unit 1001 is used to receive a diagnostic request sent by the diagnostic platform for a target diagnostic type for a target service; the diagnostic request includes the target domain name to be called to execute the target service, and the network attribute information of the network used to execute the target service;

[0204] The first acquisition unit 1002 is used to acquire intermediate data that needs to be generated when executing the target service based on the target domain name and network attribute information; the intermediate data includes address data required in the process of executing the target service.

[0205] The second acquisition unit 1003 is used to acquire diagnostic reference data of the target business under the target diagnostic type;

[0206] The diagnostic unit 1004 is used to perform data diagnosis on intermediate data based on diagnostic reference data to obtain diagnostic results for the target service. The diagnostic results are used to indicate whether the target address can be accessed or cannot be accessed when the target service is executed based on network attribute information. The target address refers to the address indicated by the target domain name.

[0207] In one implementation, the target diagnostic type refers to the type of diagnostic performed on the domain name required to execute the target service; the network attribute information includes the network provider object to which the network used to execute the target service belongs; the first acquisition unit 1002 is specifically used for:

[0208] Identify the first device used by the network provider to resolve domain names;

[0209] The first device is invoked to resolve the target domain name, obtaining the first resolution address of the network provider object for the target domain name;

[0210] The first resolved address is determined as intermediate data.

[0211] In one implementation, the diagnostic reference data includes a preset first abnormal address and a second resolution address, wherein the second resolution address is the address obtained by the business object to which the target business belongs after resolving the target domain name; the diagnostic unit 1004 is specifically used for:

[0212] If the first resolved address is the first abnormal address, then the diagnostic result is determined to be the result of insufficient access to the target address when performing the target service based on network attribute information;

[0213] If the first resolved address and the second resolved address are different, then the diagnostic result is determined to be a result indicating that the target address cannot be accessed when performing the target service based on network attribute information.

[0214] In one implementation, the target diagnostic type refers to the type of diagnosis performed on the network executing the target service. The network attribute information includes the geographical region to which the network executing the target service belongs and the network providing the service. The first acquisition unit 1002 is specifically used for:

[0215] Identify a second device for initiating the target service within a geographic area;

[0216] The second device is invoked to send the first test data to the third device using the network provided by the network object, so that the second device can obtain the address data generated during the transmission of the first test data to the third device; the third device refers to the device used to generate the service data of the target service.

[0217] Receive the address data generated during the transmission of the first test data from the second device, and determine the address data generated during the transmission of the first test data as intermediate data.

[0218] In one implementation, the first acquisition unit 1002 is specifically used for:

[0219] The second device is invoked to send at least one second test data to the third device using the network provided by the network object, so that the second device can obtain the packet loss rate for at least one second test data.

[0220] Receive the packet loss rate returned by the second device;

[0221] If the packet loss rate is greater than or equal to the packet loss rate threshold, it is determined that there is an anomaly in the network between the second device and the third device, and the second device is instructed to use the network provided by the network object to send the first test data to the third device.

[0222] In one implementation, at least one relay device exists between the second device and the third device for transmitting the first test data;

[0223] The address data generated during the transmission of the first test data includes: the device address of the second device, the device address of each relay device, and the device address to which the first test data is transmitted from the device address of the third device.

[0224] In one implementation, the diagnostic reference data includes a preset second anomaly address, and the target service is the service of a service object; the diagnostic unit 1004 is specifically used for:

[0225] If the intermediate data contains a second abnormal address, the diagnostic result is determined to be a result indicating that the target address cannot be accessed when performing the target service based on network attribute information;

[0226] If the device address to which the first test data in the intermediate data is finally transmitted is not the device address of the third device, then the diagnostic result is determined to be a result indicating that the target address cannot be accessed when performing the target service based on network attribute information.

[0227] In one implementation, the diagnostic unit 1004 is further configured to:

[0228] Generate a diagnostic analysis report tailored to the target business based on the diagnostic results;

[0229] The diagnostic analysis report is returned to the diagnostic platform, which then outputs a diagnostic analysis report.

[0230] It is understood that the division of units in this embodiment is illustrative and merely a logical functional division; in actual implementation, there may be other division methods. The functional units in this embodiment can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units can be implemented in hardware or as software functional units.

[0231] Please see Figure 11 This is a schematic diagram of the structure of a diagnostic device provided in an embodiment of this application. The diagnostic device described in this embodiment includes: a processor 1101, a memory 1102, and a network interface 1103. The processor 1101, the memory 1102, and the network interface 1103 can exchange data.

[0232] The processor 1101 mentioned above can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0233] The aforementioned memory 1102 may include read-only memory and random access memory, and provides program instructions and data to the processor 1101. A portion of the memory 1102 may also include non-volatile random access memory. The processor 1101 executes the program instructions when it calls them:

[0234] Receive diagnostic requests from the diagnostic platform for the target business and the target diagnostic type; the diagnostic request includes the target domain name to be invoked to execute the target business, and the network attribute information of the network used to execute the target business;

[0235] Acquire intermediate data required when executing target services based on target domain name and network attribute information; intermediate data includes address data required during the execution of target services.

[0236] Obtain diagnostic reference data for the target business under the target diagnostic type;

[0237] Data diagnostics are performed on intermediate data based on diagnostic reference data to obtain diagnostic results for the target service. The diagnostic results are used to indicate whether the target address can be accessed or not when the target service is executed based on network attribute information. The target address refers to the address indicated by the target domain name.

[0238] In one implementation, the target diagnostic type refers to the type of diagnostic performed on the domain name required to execute the target service; the network attribute information includes the network provider object to which the network used to execute the target service belongs; processor 1101 is specifically used for:

[0239] Identify the first device used by the network provider to resolve domain names;

[0240] The first device is invoked to resolve the target domain name, obtaining the first resolution address of the network provider object for the target domain name;

[0241] The first resolved address is determined as intermediate data.

[0242] In one implementation, the diagnostic reference data includes a preset first anomaly address and a second resolution address, wherein the second resolution address is the address obtained by the business object to which the target business belongs after resolving the target domain name; the processor 1101 is specifically used for:

[0243] If the first resolved address is the first abnormal address, then the diagnostic result is determined to be the result of insufficient access to the target address when performing the target service based on network attribute information;

[0244] If the first resolved address and the second resolved address are different, then the diagnostic result is determined to be a result indicating that the target address cannot be accessed when performing the target service based on network attribute information.

[0245] In one implementation, the target diagnostic type refers to the type of diagnosis performed on the network executing the target service. The network attribute information includes the geographical region to which the network executing the target service belongs and the network providing the target service; the processor 1101 is specifically used for:

[0246] Identify a second device for initiating the target service within a geographic area;

[0247] The second device is invoked to send the first test data to the third device using the network provided by the network object, so that the second device can obtain the address data generated during the transmission of the first test data to the third device; the third device refers to the device used to generate the service data of the target service.

[0248] Receive the address data generated during the transmission of the first test data from the second device, and determine the address data generated during the transmission of the first test data as intermediate data.

[0249] In one implementation, processor 1101 is specifically used for:

[0250] The second device is invoked to send at least one second test data to the third device using the network provided by the network object, so that the second device can obtain the packet loss rate for at least one second test data.

[0251] Receive the packet loss rate returned by the second device;

[0252] If the packet loss rate is greater than or equal to the packet loss rate threshold, it is determined that there is an anomaly in the network between the second device and the third device, and the second device is instructed to use the network provided by the network object to send the first test data to the third device.

[0253] In one implementation, at least one relay device exists between the second device and the third device for transmitting the first test data;

[0254] The address data generated during the transmission of the first test data includes: the device address of the second device, the device address of each relay device, and the device address to which the first test data is transmitted from the device address of the third device.

[0255] In one implementation, the diagnostic reference data includes a preset second exception address, and the target service is the service of a service object; the processor 1101 is specifically used for:

[0256] If the intermediate data contains a second abnormal address, the diagnostic result is determined to be a result indicating that the target address cannot be accessed when performing the target service based on network attribute information;

[0257] If the device address to which the first test data in the intermediate data is finally transmitted is not the device address of the third device, then the diagnostic result is determined to be a result indicating that the target address cannot be accessed when performing the target service based on network attribute information.

[0258] In one implementation, processor 1101 is specifically used for:

[0259] Generate a diagnostic analysis report tailored to the target business based on the diagnostic results;

[0260] The diagnostic analysis report is returned to the diagnostic platform, which then outputs a diagnostic analysis report.

[0261] This application also provides a computer storage medium storing program instructions, which, when executed, may include, for example... Figure 2 or Figure 4 or Figure 7 Some or all of the steps of the data diagnostic method in the corresponding embodiments.

[0262] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0263] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0264] This application also provides a computer program product or computer program that includes program instructions stored in a computer-readable storage medium. A processor of a diagnostic device reads the program instructions from the computer-readable storage medium and executes the program instructions, causing the diagnostic device to perform the steps described in the embodiments of the above methods.

[0265] The above provides a detailed description of a data diagnostic method, apparatus, diagnostic device, and storage medium provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A data diagnostic method, characterized in that, The method includes: Receive a diagnostic request from the diagnostic platform for a specific type of diagnostic service; the diagnostic request includes the target domain name to be invoked to execute the target service, and network attribute information of the network used to execute the target service; Obtain intermediate data required to execute the target service based on the target domain name and the network attribute information; the intermediate data includes address data required during the execution of the target service. Obtain the diagnostic reference data of the target service under the target diagnostic type; Based on the diagnostic reference data, data diagnosis is performed on the intermediate data to obtain a diagnostic result for the target service; the diagnostic result is used to indicate whether the target address can be accessed or cannot be accessed when the target service is executed based on the network attribute information, and the target address refers to the address indicated by the target domain name; The target diagnostic types include: types that diagnose the network executing the target service, wherein the network attribute information includes the geographical region to which the network executing the target service belongs and the network provider; the step of obtaining the intermediate data required to execute the target service based on the target domain name and the network attribute information includes: Determine a second device for initiating the target service within the geographical area; The second device is invoked to send first test data to the third device using the network provided by the network object, so that the second device obtains the address data generated during the transmission of the first test data to the third device; the third device refers to a device used to generate the service data of the target service. The device receives address data generated during the transmission of the first test data from the second device, and determines the address data generated during the transmission of the first test data as the intermediate data.

2. The method according to claim 1, characterized in that, The target diagnostic type refers to the type of diagnostic performed on the domain name that needs to be invoked to execute the target service, and the network attribute information includes the network provider object to which the network used to execute the target service belongs; The intermediate data required to execute the target service based on the target domain name and the network attribute information includes: Identify a first device for resolving domain names from the network provider object; The first device is invoked to resolve the target domain name, thereby obtaining the first resolution address of the network provider object for the target domain name; The first resolved address is determined as the intermediate data.

3. The method according to claim 2, characterized in that, The diagnostic reference data includes a preset first abnormal address and a second resolution address, wherein the second resolution address is the address obtained by the business object to which the target business belongs after resolving the target domain name; The step of performing data diagnosis on the intermediate data based on the diagnostic reference data to obtain diagnostic results for the target business includes: If the first resolved address is the first abnormal address, then the diagnostic result is determined to be a result indicating that the target address cannot be accessed when the target service is executed based on the network attribute information; If the first resolved address and the second resolved address are different, then the diagnostic result is determined to be a result indicating that the target address cannot be accessed when the target service is executed based on the network attribute information.

4. The method according to claim 1, characterized in that, The step of invoking the second device to send the first test data to the third device using the network provided by the network object includes: The second device is invoked to send at least one second test data to the third device using the network provided by the network object, so that the second device obtains the packet loss rate for the at least one second test data; Receive the packet loss rate returned by the second device; If the packet loss rate is greater than or equal to the packet loss rate threshold, it is determined that there is an anomaly in the network between the second device and the third device, and the second device is invoked to send the first test data to the third device using the network provided by the network object.

5. The method according to claim 1, characterized in that, At least one relay device exists between the second device and the third device for transmitting the first test data; The address data generated during the transmission of the first test data includes: the device address of the second device, the device address of each relay device, and the device address to which the first test data is transmitted from the device address of the third device.

6. The method according to claim 1, characterized in that, The diagnostic reference data includes a preset second abnormal address, and the target service is the service of a service object; the step of performing data diagnosis on the intermediate data based on the diagnostic reference data to obtain a diagnostic result for the target service includes: If the intermediate data contains the second abnormal address, then the diagnostic result is determined to be a result indicating that the target address cannot be accessed when the target service is executed based on the network attribute information; If the device address to which the first test data in the intermediate data was last transmitted is not the device address of the third device, then the diagnostic result is determined to be a result indicating that the target address cannot be accessed when the target service is executed based on the network attribute information.

7. The method according to claim 1, characterized in that, The method further includes: A diagnostic analysis report for the target business is generated based on the diagnostic results; The diagnostic analysis report is returned to the diagnostic platform, which then outputs the diagnostic analysis report.

8. A data diagnostic device, characterized in that, include: The receiving unit is used to receive diagnostic requests sent by the diagnostic platform for the target diagnostic type of the target business. The diagnostic request includes the target domain name to be invoked to execute the target service, and the network attribute information of the network used to execute the target service; The first acquisition unit is used to acquire intermediate data required to execute the target service based on the target domain name and the network attribute information; the intermediate data includes address data required during the execution of the target service. The second acquisition unit is used to acquire diagnostic reference data of the target service under the target diagnostic type; A diagnostic unit is configured to perform data diagnostics on the intermediate data based on the diagnostic reference data to obtain a diagnostic result for the target service; the diagnostic result is used to indicate whether the target address can be accessed or cannot be accessed when the target service is executed based on the network attribute information, wherein the target address refers to the address indicated by the target domain name; The target diagnostic types include: diagnostic types for networks executing target services, wherein the network attribute information includes the geographical region to which the network executing the target service belongs and the network provider; the first acquisition unit is used to determine a second device for initiating the target service within the geographical region; instructs the second device to send first test data to a third device using the network of the network provider, so that the second device acquires address data generated during the transmission of the first test data to the third device; the third device refers to a device used to generate service data for the target service; receives the address data generated during the transmission of the first test data returned by the second device, and determines the address data generated during the transmission of the first test data as the intermediate data.

9. A diagnostic device, characterized in that, The system includes a processor and a memory, wherein the memory is used to store a computer program, the computer program including program instructions, and the processor is configured to invoke the program instructions to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores program instructions that, when executed, implement the method as described in any one of claims 1-7.

11. A computer program product comprising program instructions that, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

Images