Fault diagnosis method and device for data acquisition and electronic equipment

Abstract

The invention discloses a fault diagnosis method and device for data acquisition and electronic equipment. The method comprises the following steps: acquiring a multi-source heterogeneous log corresponding to a network element under the condition that network element data acquisition fails; the multi-source heterogeneous log is analyzed through the fault analysis model, fault root cause classification results are obtained, and the fault root cause classification results comprise at least one of scheduler execution exception, network element exception and analysis code exception; when the fault root cause classification result is that the analysis code is abnormal, obtaining the analysis code corresponding to the network element, and generating a prompt word according to the analysis code, a historical repair case and a preset repair requirement; and taking the prompt word as the input of the fault analysis model, and guiding the fault analysis model to generate a code repair result. The technical problems that under the condition that the network element data collection failure rate is high, a log monitoring system in the related technology cannot accurately position a fault source, and analysis codes are repaired mostly depending on artificial experience are solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of data processing and fault diagnosis, in particular, to a data collection fault diagnosis method and device and electronic equipment. BACKGROUND

[0002] In the field of communication network management, network element data collection as a basic operation and maintenance link is generally implemented by batch collection through a pre-configured parsing code executed by a timing task (such as XXL-JOB). However, in a large-scale network, the failure rate of network element data collection is high, which seriously affects the integrity of data and the accuracy of analysis, and interferes with network management decisions. There are mainly three types of faults in the process of network element data collection: scheduling executor error (such as task not normally scheduled triggering), network element exception (such as password error, network interruption, execution instruction failure), and parsing code error (such as unable to correctly parse the original instruction returned by the device). Among them, the parsing code error is particularly tricky, which is rooted in the large number of network element device models and the large difference in returned data formats, network software upgrade may cause the change of returned data structure, and developers are difficult to cover all scenarios of testing. The traditional troubleshooting method of network element data collection failure is inefficient, which depends on manual experience to check and verify one by one through logs, and it is difficult to quickly locate the root cause of complex faults, and cannot adapt to the operation and maintenance needs in large-scale and high-complexity network environment.

[0003] For the above phenomenon, the related technology adopts a hierarchical solution: first, real-time collection of relevant logs through a log monitoring system (such as ELK stack or Prometheus); then, triggering an alarm based on preset rules (such as the keyword "ERROR" or exception type), but this method can only mark abnormal phenomena (such as "NullPointerException" or "Connectiontimeout"), and it is difficult to deeply analyze the root cause of the exception. Secondly, for parsing errors, manual processing procedures are often used, which requires manually logging into the faulty network element, re-executing the data collection instruction to obtain the original output, then debugging the parsing code in the local development environment, and then performing targeted testing and verification after repair, which not only increases the labor cost, but also often cannot guarantee the comprehensiveness and timeliness of the test, especially in the face of rapidly changing network environment and data formats, which is not up to the task.

[0004] In addition, the repeated occurrence and repair of parsing errors are highly repetitive, and there is a lack of a mechanism to effectively deposit these experiences and lessons to form reusable knowledge assets. This leads to the fact that even if the same type of fault occurs again later, the operation and maintenance team still needs to spend a lot of time and effort to solve the problem from scratch, and there is a lack of an automated closed-loop system to cope with the growing challenges in network operation and maintenance.

[0005] At present, no effective solution has been proposed for the above problems. SUMMARY

[0006] Embodiments of the present application provide a data collection fault diagnosis method and device and electronic equipment to at least solve the technical problem that log monitoring systems in the related art cannot accurately locate the root cause of failure when the network element data collection failure rate is high, and are dependent on manual experience to repair and analyze the code.

[0007] According to an aspect of an embodiment of the present application, a data collection fault diagnosis method is provided, comprising: in the case of network element data collection failure, obtaining multi-source heterogeneous logs corresponding to the network element; analyzing the multi-source heterogeneous logs by a fault analysis model to obtain a fault root cause classification result, wherein the fault root cause classification result includes at least one of the following: scheduler execution anomaly, network element anomaly, and analysis code anomaly; in the case that the fault root cause classification result is analysis code anomaly, obtaining the analysis code corresponding to the network element, and generating a prompt word according to the analysis code, historical repair cases, and a preset repair requirement; taking the prompt word as the input of the fault analysis model to guide the fault analysis model to generate a code repair result corresponding to the network element.

[0008] Optionally, in the case of network element data collection failure, obtaining the multi-source heterogeneous logs corresponding to the network element comprises: detecting the network element data collection state after the execution of a timing task, wherein the timing task is a network element data collection task containing a preset collection interval; in the case of abnormal collection state, obtaining the multi-source heterogeneous logs corresponding to the network element with data collection failure, and recording the identification information of the network element, wherein the multi-source heterogeneous logs at least include the scheduling logs, network element logs, and analysis code logs corresponding to the network element.

[0009] Optionally, the method further comprises: in the case that the fault root cause classification result is scheduler execution anomaly, obtaining thread information related to the scheduler by a thread monitoring module, wherein the thread information includes at least one of the following: thread quantity, thread state, and thread resource occupation situation; analyzing the thread information by the fault analysis model to obtain a scheduler execution repair result corresponding to the network element.

[0010] Optionally, the method further comprises: in the case that the fault root cause classification result is network element anomaly, sending a connection request and authentication information to the network element according to a collection network protocol, wherein the collection network protocol is a network protocol used by the network element in the data collection process; obtaining response information processed by the network element to the connection request and authentication information, and determining a connectivity verification result of the network element according to the response information; analyzing the connectivity verification result by the fault analysis model to obtain a network element repair result corresponding to the network element.

[0011] Optionally, the prompt word is generated according to the parsing code, the historical repair case and the preset repair requirement, and the method comprises the following steps: obtaining original instruction output of the network element and abnormal stack information of the parsing code corresponding to the network element in a running process; obtaining the historical repair case corresponding to the parsing code through a retrieval enhancement algorithm according to the original instruction output, the parsing code and the abnormal stack information; and generating the prompt word according to the original instruction output, the parsing code, the abnormal stack information, the historical repair case and the preset repair requirement.

[0012] Optionally, the historical repair case corresponding to the parsing code is obtained through the retrieval enhancement algorithm according to the original instruction output, the parsing code and the abnormal stack information, and the method comprises the following steps: obtaining identification information of the network element; obtaining structural features in the original instruction output, format features in the abnormal stack information and function module labels of the parsing code; and retrieving a plurality of historical repair cases with a similarity higher than a preset threshold to the parsing code from a historical repair knowledge base through the retrieval enhancement algorithm according to the identification information, the structural features, the format features and the function module labels.

[0013] Optionally, after the code repair result corresponding to the network element is obtained, the method further comprises the following steps: determining data collected and parsed successfully by the network element for the last time before data collection fails as historical baseline data; updating the parsing code of the network element according to the code repair result, and re-parsing the original instruction output of the network element according to the updated parsing code to obtain a first parsing result; determining a first verification result according to the first parsing result and the historical baseline data, and in the case that the first verification result indicates that the parsing result is consistent with the historical baseline data, parsing original instruction output of other network elements collected and parsed successfully in the same batch according to the code repair result to obtain a second parsing result; determining a second verification result according to the second parsing result, and in the case that the second verification result indicates that the code repair result can parse other network elements, determining that the code repair result is correct.

[0014] Optionally, the method further comprises the following steps: generating a triple according to the parsing code, the code repair result and the corresponding verification result; and storing the triple to a historical repair knowledge base.

[0015] According to another aspect of the embodiments of the present application, a fault diagnosis device for data collection is also provided, comprising: an acquisition module configured to acquire multi-source heterogeneous logs corresponding to a network element in the case of network element data collection failure; an analysis module configured to analyze the multi-source heterogeneous logs by a fault analysis model to obtain a fault root cause classification result, wherein the fault root cause classification result comprises at least one of the following: scheduler execution abnormality, network element abnormality, and parsing code abnormality; a first generation module configured to, in the case of the fault root cause classification result being the parsing code abnormality, acquire parsing code corresponding to the network element, and generate a prompt word according to the parsing code, historical repair cases, and a preset repair requirement; and a second generation module configured to input the prompt word as an input of the fault analysis model to guide the fault analysis model to generate a code repair result corresponding to the network element.

[0016] According to still another aspect of the embodiments of the present application, an electronic device is also provided, comprising: a memory and a processor, wherein the memory is configured to store program instructions; and the processor is connected with the memory and configured to execute the above-mentioned fault diagnosis method for data collection.

[0017] According to yet another aspect of the embodiments of the present application, a non-volatile storage medium is also provided, comprising a stored computer program, wherein a device in which the non-volatile storage medium is located executes the above-mentioned fault diagnosis method for data collection by running the computer program.

[0018] According to still another aspect of the embodiments of the present application, a computer program product is also provided, comprising computer instructions which, when executed by a processor, implement the above-mentioned fault diagnosis method for data collection.

[0019] In the embodiments of the present application, in the case of network element data collection failure, multi-source heterogeneous logs corresponding to the network element are acquired; the multi-source heterogeneous logs are analyzed by a fault analysis model to obtain a fault root cause classification result, wherein the fault root cause classification result comprises at least one of the following: scheduler execution abnormality, network element abnormality, and parsing code abnormality; in the case of the fault root cause classification result being the parsing code abnormality, parsing code corresponding to the network element is acquired, and a prompt word is generated according to the parsing code, historical repair cases, and a preset repair requirement; the prompt word is input as an input of the fault analysis model to guide the fault analysis model to generate a code repair result corresponding to the network element, achieving the purpose of accurately locating the reason for network element data collection failure and automatically repairing the parsing code, thereby realizing the technical effects of significantly improving operation and maintenance efficiency, optimizing collection success rate, and promoting knowledge reuse, and further solving the technical problems in the related art that, in the case of high network element data collection failure rate, a log monitoring system cannot accurately locate the fault root cause and is dependent on manual experience to repair the parsing code. BRIEF DESCRIPTION OF DRAWINGS

[0020] The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiments of the application and together with the description serve to explain the application. In the drawings:

[0021] Figure 1 Fig. 1 is a hardware structure diagram of a computer terminal for implementing a fault diagnosis method for data collection according to an embodiment of the application;

[0022] Figure 2 Fig. 2 is a flowchart of a fault diagnosis method for data collection according to an embodiment of the application;

[0023] Figure 3 Fig. 3 is a structure diagram of a fault diagnosis device for data collection according to an embodiment of the application. DETAILED DESCRIPTION

[0024] In order to enable persons skilled in the art to better understand the scheme of the present application, the technical scheme in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by persons skilled in the art without creative labor should fall within the scope of protection of the present application.

[0025] It should be noted that the terms "first", "second", and the like in the specification of the present application, the claims, and the above-described drawings are used to distinguish similar objects, and do not have to be used to describe a specific order or sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product, or device that includes a series of steps or units does not have to be limited to only those steps or units clearly listed, but can include other steps or units that are not clearly listed or inherent to the process, method, product, or device.

[0026] First, some nouns or terms that appear in the process of explaining the embodiments of the present application are applicable to the following explanations:

[0027] NE (Network Element, network element): a physical or logical device with independent management function in a communication network, including but not limited to routers, switches, base station controllers, etc., which can communicate with other management systems or devices through standard protocols.

[0028] Scheduling Platform: A distributed system (such as XXL-JOB) used to manage scheduled tasks, responsible for task distribution, execution monitoring, and state tracking.

[0029] Executor: A software module that directly connects to network elements to execute collection instructions and run parsing scripts, providing API interfaces for obtaining runtime context (original instruction output / parsing script output).

[0030] Parsing Script: A program code used to process network element raw output, written in multiple programming languages such as Python and Groovy. The main function of the script is to extract, convert, and parse structured data from the raw response of the network element, facilitating subsequent analysis and storage.

[0031] Original Instruction Output: The unprocessed data returned by the network element device after executing a specific collection command (such as the showinterface command to display interface status), usually in text form.

[0032] LLM (Large Language Model): A highly complex machine learning model that can understand and generate human language by training massive amounts of text data, including but not limited to natural language processing, text generation, and code understanding. In this context, large models are used for intelligent classification of network element data collection faults and automatic repair of parsing code.

[0033] RAG (Retrieve-Augmented Generation): A method combining retrieval and language generation techniques, allowing the model to access and utilize external knowledge bases when generating text or code. In this application, RAG technology is used to find similar historical repair cases for the current parsing code error to construct more effective prompts, guiding the automatic repair process of parsing code.

[0034] To solve the problem of low efficiency in identifying the failure reason of data collection in related technologies, the present application provides a data collection fault diagnosis method, which can be run in Figure 1 The computer terminal is described as follows.

[0035] The data collection fault diagnosis method provided by the present application can be executed in a mobile terminal, a computer terminal, or a similar computing device. Figure 1 A hardware structure block diagram of a computer terminal for implementing the data collection fault diagnosis method is shown. As Figure 1As shown, the computer terminal 10 can include one or more processors (which can include, but are not limited to, processing devices such as microprocessors (MCU) or programmable logic devices (FPGA)), a memory 104 for storing data, and a transmission module 106 for communication functions connected through wired and / or wireless networks. In addition, it can also include a display, a keyboard, a cursor control device, an input / output interface (I / O interface), a universal serial bus (USB) port (which can be included as one of the ports of the I / O interface), a network interface, a BUS bus. Those skilled in the art can understand that Figure 1 The structure shown is only a schematic and does not limit the structure of the above-mentioned electronic device. For example, the computer terminal 10 can include more or fewer components than those shown in the figure, or have a different configuration than that shown in the figure. Figure 1 Figure 1

[0036] It should be noted that the one or more processors and / or other data processing circuits described above can be referred to herein as "data processing circuits" in general. The data processing circuit can be embodied in whole or in part as software, hardware, firmware, or any combination thereof. In addition, the data processing circuit can be a single independent processing module, or all or part of any one of the other elements incorporated into the computer terminal 10. As referred to in the embodiments of the present application, the data processing circuit serves as a processor to control, for example, the selection of the variable resistance terminal path connected to the interface.

[0037] The memory 104 can be used to store software programs and modules of application software, such as program instructions / data storage devices corresponding to the fault diagnosis method of data acquisition in the embodiments of the present application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 104, i.e. implements the above-mentioned fault diagnosis method of data acquisition. The memory 104 can include a high-speed random access memory, and can also include a non-volatile memory such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 can further include a memory remotely disposed with respect to the processor, which can be connected to the computer terminal 10 through a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0038] ​​The transmission module 106 is configured to receive or send data via a network. The network can include, for example, a wireless network provided by a communication provider of the computer terminal 10. In one example, the transmission module 106 includes a network interface controller (NIC) that can connect to other network devices through a base station to communicate with the Internet. In one example, the transmission module 106 can be a radio frequency (RF) module that is configured to communicate with the Internet wirelessly.

[0039] The display can be, for example, a touch screen liquid crystal display (LCD) that enables a user to interact with a user interface of the computer terminal 10.

[0040] It is noted that, in some alternative embodiments, the above-mentioned Figure 1 The computer terminal can include hardware elements (including circuitry), software elements (including computer code stored on a computer readable medium), or a combination of both hardware and software elements. It should be noted that Figure 1 is merely one example of a particular implementation and is intended to illustrate the types of components that can be present in the above-described computer terminal.

[0041] In the above-described operating environment, embodiments of the present disclosure provide a fault diagnosis method for data collection. It is noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described herein can be executed in an order different from that shown herein.

[0042] Figure 2 is a flowchart of a fault diagnosis method for data collection according to an embodiment of the present disclosure, as shown in Figure 2 The method includes the following steps:

[0043] In step S202, in the case of a failure in data collection of a network element, a plurality of source heterogeneous logs corresponding to the network element are obtained.

[0044] In step S204, the plurality of source heterogeneous logs are analyzed by a fault analysis model to obtain a fault root cause classification result, wherein the fault root cause classification result includes at least one of the following: an abnormal execution of a scheduler, an abnormal network element, and an abnormal parsing code.

[0045] In step S206, in the case that the fault root cause classification result is an abnormal parsing code, a parsing code corresponding to the network element is obtained, and a prompt word is generated according to the parsing code, a historical repair case, and a preset repair requirement.

[0046] Step S208, the prompt word is taken as the input of the fault analysis model, and the fault analysis model is guided to generate a code repair result corresponding to the network element.

[0047] Through the steps S202 to S208, the purpose of accurately positioning the network element data collection failure reason and automatically repairing the parsing code is achieved, thereby realizing the technical effects of significantly improving the operation and maintenance efficiency, optimizing the collection success rate and promoting the knowledge reuse, and further solving the technical problems in the related art that the log monitoring system cannot accurately locate the fault root cause in the case of high network element data collection failure rate, and is dependent on manual experience to repair the parsing code. Details are described below.

[0048] In the above step S202, when it is detected that there is a failure in the network element data collection task, a fault diagnosis process is automatically started, and heterogeneous log information corresponding to the failed network element is collected from multiple sources.

[0049] Optionally, in the case of network element data collection failure, the multi-source heterogeneous log corresponding to the network element is obtained, including: detecting the network element data collection state after the execution of a timing task, wherein the timing task is a network element data collection task containing a preset collection interval; in the case of abnormal collection state, obtaining the multi-source heterogeneous log corresponding to the network element with data collection failure, and recording the identification information of the network element, wherein the multi-source heterogeneous log at least includes the scheduling log, the network element log and the parsing code log corresponding to the network element.

[0050] Specifically, the periodic execution of the data collection task is an important part of ensuring the health and performance monitoring of the communication network. These tasks are usually initiated by a timing scheduling platform (such as XXL-JOB), executed according to a preset time interval (collection frequency), and involve data grabbing and parsing of various devices (i.e. network elements) in the network. However, due to various unpredictable factors, such as temporary failure of devices, network fluctuations or code defects of parsing scripts, data collection tasks may fail, resulting in failure to successfully obtain data of some network elements.

[0051] In the embodiments of the present application, in order to effectively deal with this problem, an improved fault diagnosis method is proposed, the core of which is to take action to collect comprehensive fault information from the early stage of collection failure, providing detailed context for subsequent analysis and positioning of faults. Specifically, it is necessary to detect the network element data collection state after the execution of a timing task. Once it is found that the data collection state of a network element is abnormal, i.e. data collection failure, the acquisition process of multi-source heterogeneous log is started immediately to ensure that the moment of failure and the related background can be captured. The acquired multi-source heterogeneous log includes but is not limited to:

[0052] 1) Scheduling log: from the scheduling platform, records the scheduling time, scheduling frequency, scheduler status and any resource conditions that may affect task execution of the timed task. By analyzing the scheduling log, it can exclude or confirm the task scheduling level failure, such as whether the task is triggered on time, whether there is resource competition leading to task execution delay or failure.

[0053] 2) Network element log: directly from the network element device that fails to collect data, including the network element's connection log, authentication information, and real-time reaction and error prompt information when executing the collection instruction. Network element log is crucial for diagnosing whether the collection failure is caused by device itself problems (such as authentication failure, unstable network connection, etc.).

[0054] 3) Parsing code log: records the execution status and any abnormal information of the parsing script in the entire data processing process, such as runtime error, data type mismatch warning, etc. Parsing code log is the key evidence for diagnosing script exceptions, which can reveal the problems in code logic.

[0055] In addition to the above log information, the system also synchronously records the identification information of the network element that fails to collect data, including but not limited to network element ID, device model, manufacturer, software version, etc., so as to consider device characteristics and software environment when classifying faults later, thereby improving the pertinence of fault analysis.

[0056] By comprehensively and timely obtaining multi-source heterogeneous logs related to faults, a more comprehensive fault view is constructed, providing a solid information foundation for subsequent intelligent fault classification and parsing code self-recovery. This approach overcomes the shortcomings of information fragmentation and delayed response in traditional fault troubleshooting methods, enabling faster and more accurate problem identification, providing sufficient basis for automatic repair and manual intervention.

[0057] In the above step S204, the aggregated multi-source heterogeneous logs are classified into three levels of root causes (including scheduler-executor class, network element class and parsing code class) by a fault analysis model (such as LLM), and the diagnostic results with confidence and repair suggestions are output, such as "authentication failure: suggest checking ACL policy, confidence 92%". The following describes the three abnormal categories in detail.

[0058] First, in the case of scheduler execution exception in the fault root cause classification result, the thread information related to the scheduler is obtained through the thread monitoring module, wherein the thread information includes at least one of the following: thread number, thread state and thread resource occupation; the thread information is analyzed by the fault analysis model to obtain the scheduler execution repair result corresponding to the network element.

[0059] In the embodiments of the present application, when it is determined that the reason for the failure of the network element data collection is the abnormality of the scheduler executor, thread information related to the scheduler can be captured by the system built-in thread monitoring module, including but not limited to:

[0060] 1) Thread number: reflecting the total number of threads currently running or waiting for execution, which helps to determine whether there is a thread number overload problem.

[0061] 2) Thread state: for example, running, waiting, blocking or deadlock state, which helps to identify abnormal situations existing in thread management.

[0062] 3) Thread resource occupation: such as CPU usage, memory occupation, etc., used to analyze whether the resource allocation is reasonable and whether there is an execution obstacle caused by resource contention.

[0063] After summarizing the above thread information, it is input to the large model again for deep analysis to identify and locate specific error points that may cause task failure, such as thread deadlock, unreasonable resource scheduling, etc., and generate corresponding solutions to obtain the scheduler execution repair result. For example, if the analysis result shows that there is a thread deadlock, it can be suggested to optimize the thread synchronization mechanism of the scheduler to avoid mutual waiting for resources among multiple threads; if the problem is resource shortage, it can be recommended to increase the resource limit of the scheduler or optimize the resource allocation strategy to ensure the smooth execution of the task. Finally, according to the obtained scheduler execution repair result, the corresponding repair operation is automatically performed, and after the repair operation is completed, the data collection task is re-initiated to verify whether the previous scheduler error has been successfully solved by these measures, so as to ensure that the data collection task can run normally.

[0064] Secondly, in the case that the fault root cause classification result is network element abnormality, connection request and authentication information are sent to the network element according to the collection network protocol, wherein the collection network protocol is a network protocol used by the network element in the data collection process; response information processed by the network element to the connection request and authentication information is obtained, and the connectivity verification result of the network element is determined according to the response information; the connectivity verification result is analyzed by the fault analysis model to obtain the network element repair result corresponding to the network element.

[0065] In the embodiments of the present application, when it is determined that the reason for the failure of the network element data collection is the abnormality of the network element, especially the abnormality in the connection failure or the authentication process, the network element abnormality processing stage is entered, the connectivity and authentication state of the faulty network element can be verified in depth by simulating the normal collection connection process to accurately locate the problem and automatically generate a repair strategy.

[0066] Specifically, first, connectivity verification is triggered, and according to the network protocol used in the network element data collection process (such as SNMP, Telnet, or NETCONF, etc.), a connection request and authentication information are automatically sent to the failed network element to simulate the network interaction process in the actual data collection task. Subsequently, the response information of the network element to the connection request and authentication information is recorded, including but not limited to connection timeout, authentication rejection or other types of network errors, and the connectivity verification result is obtained. Next, based on the collected response information, deep analysis is performed through the fault analysis model to determine the specific type of network element exception, such as network reachability problem, authentication policy conflict, etc., and the corresponding repair strategy is generated, and the network element repair result is obtained, including but not limited to checking the connectivity of the network link, updating the authentication information, optimizing the ACL (Access Control List) policy, etc., to solve the network element exception problem that leads to collection failure. Finally, according to the network element repair result output by the fault analysis model, the corresponding network configuration or authentication information update is automatically executed to attempt to repair the potential problem points that cause the exception, and after the repair operation is completed, the system reinitiates the connection request to the target network element and executes the data collection task to verify whether the problem has been effectively solved.

[0067] Thirdly, as shown in step S206, when the fault analysis model determines that the reason for data collection failure is parsing code exception, the parsing code self-healing process is entered, which mainly generates specific prompt words for the code repair engine to guide the repair work.

[0068] Optionally, the prompt words are generated according to the parsing code, historical repair cases and preset repair requirements, including: obtaining the original instruction output of the network element and the abnormal stack information of the parsing code corresponding to the network element during the running process; obtaining the historical repair cases corresponding to the parsing code through the retrieval enhancement algorithm according to the original instruction output, the parsing code and the abnormal stack information; and generating the prompt words according to the original instruction output, the parsing code, the abnormal stack information, the historical repair cases and the preset repair requirements.

[0069] In the embodiments of the present application, the parsing code self-healing mechanism aims to solve the problem of network element data collection failure caused by parsing script errors. The key of this mechanism is to generate accurate prompt words according to the parsing code, historical repair cases and preset repair requirements, and then automatically generate repair codes through intelligent analysis of large models to realize automatic processing of faults. The specific process analysis is as follows:

[0070] I. Dynamic context capture

[0071] Original instruction output acquisition: When a parsing type fault occurs, the system directly obtains the original command line output (CLI echo) from the faulty network element through the API interface, such as the response data of the show interface command, to ensure that the direct basis for fault handling comes from the production environment;

[0072] Parsing code snippet extraction: Obtain the parsing code snippet being executed, such as scripts written in programming languages including Python, Java, Groovy, etc., to facilitate direct positioning to possible logical defects or data processing abnormalities in the code;

[0073] Exception stack information collection: Capture exception stack information occurring during runtime of the parsing script, such as Traceback of Python script, to provide detailed error location and type information for subsequent fault analysis and repair.

[0074] II. Constructing a prompt word

[0075] Optionally, the prompt word is generated according to the parsing code, historical repair cases, and preset repair requirements (such as maintaining the accuracy of the parsing logic and compatibility with historical data formats), including: obtaining the original instruction output of the network element, and the exception stack information occurring during the running process of the parsing code corresponding to the network element; obtaining the historical repair cases corresponding to the parsing code through a retrieval enhancement algorithm according to the original instruction output, the parsing code, and the exception stack information; and generating the prompt word according to the original instruction output, the parsing code, the exception stack information, the historical repair cases, and the preset repair requirements.

[0076] Among them, obtaining the historical repair cases corresponding to the parsing code through a retrieval enhancement algorithm according to the original instruction output, the parsing code, and the exception stack information includes: obtaining the identification information of the network element; obtaining the structural features in the original instruction output, the format features in the exception stack information, and the functional module labels of the parsing code; and retrieving multiple historical repair cases with a similarity to the parsing code higher than a preset threshold from a historical repair knowledge base through a retrieval enhancement algorithm according to the identification information, the structural features, the format features, and the functional module labels. The specific steps are analyzed as follows:

[0077] 1. Retrieval initiation and parameter determination

[0078] When it is determined that the network element collection failure is caused by parsing code exception, the RAG retrieval process is automatically triggered when entering the prompt word construction stage. At this time, the system will extract key retrieval parameters, including but not limited to the core identification information of the failed network element (such as manufacturer name, device model, software version, etc.), key features in the exception stack information (such as “field undefined”, “format conversion exception”, null pointer exception, etc. Error keywords), structural features in the original instruction output (such as data message format, field arrangement rule, etc.), and functional module labels of the parsing code (such as “interface data parsing”, “performance indicator extraction”, etc.).

[0079] 2. Knowledge base retrieval and case selection

[0080] Based on the above search parameters, the historical repair knowledge base is searched by the RAG search module in multiple dimensions. Specifically, first, the identification information of the failed network element can be used for preliminary filtering to screen out repair cases of the same manufacturer, same series, or similar model devices; then, combined with the error type keywords, repair cases with the same or similar error characteristics are matched; finally, according to the data structure characteristics and code function tags, the search range is further narrowed. After the search is completed, the repair cases obtained by the search are sorted according to the similarity of the current parsed code (such as device matching degree, error type coincidence degree, data feature consistency, etc.), and the top N (such as top 3) high-similarity historical repair cases are selected as reference cases.

[0081] 3. Case information extraction and structured processing

[0082] For the selected reference cases, core information is automatically extracted and structured. The core information includes but is not limited to: error description in the case (corresponding to the current abnormal stack information), defect points of the original parsing code (such as lack of field parsing logic, regular expression mismatch, etc.), core ideas of the repair case (such as adding field mapping rules, optimizing data format conversion functions, etc.), key code fragments after repair (with modification position and logic marked), and matters needing attention in the verification process (such as special scene adaptation requirements, compatibility test focus, etc.). After extraction, these core information is further organized into a standardized format (such as key-value pair, structured table, etc.) for subsequent integration.

[0083] 4. Multi-source information integration and prompt word generation

[0084] The structured RAG search case information is integrated with the basic information of the current code (complete content of the error stack, original instruction output, complete fragment of the parsing code to be repaired), and the preset repair requirements (such as "must be compatible with historical data format", "ensure that the parsing efficiency is not lower than the original code", etc.) to form a complete prompt word.

[0085] It should be noted that the integration needs to follow the following progressive principles: first, describe the current problem scenario (such as network element information + error phenomenon), then introduce the reference case (such as "in the historical similar case, for the XX error of XX device, adopt XX idea to repair"), then list the basic information for model analysis, and finally clarify the repair target and constraint conditions.

[0086] For example, for the scenario of "signal_strength" field parsing of ZXR10 8900 series network element appearing null pointer exception, the integrated prompt word is as follows:

[0087] "The current need to repair a ZXR10 8900 network element V5.1 version of the parsing code, the complete content of the error stack is: 'Traceback (most recent call last): File "parser_zxr10.py", line 62, in parse_signal_data ['signal_strength'] = float (raw_signal.strip ())TypeError: float () argument must be a string or a number, not 'NoneType''; The original instruction output segment is: '...[signal_info] signal_strength: |signal_quality:85%...'(You can see that the signal_strength field value is empty); The exception parsing code segment (key part) is:

[0088] def parse_signal(raw_data):

[0089] data = {}

[0090] raw_signal = extract_value(raw_data,'signal_strength')

[0091] data['signal_strength'] = float(raw_signal.strip())

[0092] data['signal_quality'] = extract_value(raw_data,'signal_quality')

[0093] return data

[0094] The historical repair case retrieved by RAG is: the V3.5 version of a certain S6720 network element caused a null pointer exception due to the "temperature" field value being empty, with an error stack of TypeError: float () argument must be a string or a number, not 'NoneType', and no specific value after 'temperature:' in the original data. The repair idea for this case is: add a non-empty field value check before parsing, and assign a default value (such as -999) if it is empty and record the log; The key code segment after repair is:

[0095] def parse_temperature(raw_data):

[0096] data = {}

[0097] raw_temp = extract_value(raw_data, 'temperature')

[0098] # Add null value handling logic

[0099] if raw_temp is None or raw_temp.strip() == '':

[0100] data['temperature'] = -999

[0101] log.warning("temperature field is empty, set to -999")

[0102] else:

[0103] data['temperature'] = float(raw_temp.strip())

[0104] return data

[0105] Please refer to this approach to analyze the current exception parsing code and generate corresponding fix code. The code must be able to run correctly and the relevant fields must be parsed correctly.

[0106] In step S208 above, the aim is to output the corresponding repair code based on the constructed prompt words through the fault analysis model.

[0107] In this embodiment, after obtaining the code repair result corresponding to the network element, a dual verification mechanism is introduced, including: determining the last successfully collected and parsed data of the network element before the data collection failure as the historical baseline data; updating the parsing code of the network element according to the code repair result, and re-parseing the original instruction output of the network element according to the updated parsing code to obtain a first parsing result; determining a first verification result based on the first parsing result and the historical baseline data, and if the first verification result indicates that the parsing result is consistent with the historical baseline data, parsing the original instruction output of other successfully collected and parsed network elements in the same batch according to the code repair result to obtain a second parsing result; determining a second verification result based on the second parsing result, and if the second verification result indicates that the code repair result can parse other network elements, determining that the code repair result is correct.

[0108] Specifically, the introduction of the double verification mechanism aims to verify that the repaired parsing code not only ensures the accuracy of data parsing but also has compatibility with multiple devices to prevent new problems introduced by code modification. The specific analysis is as follows:

[0109] First verification: historical baseline data comparison.

[0110] First, the data collected and parsed by the network element before the data collection failed is selected as the historical baseline data. This data reflects the data structure and expected output of the network element in the normal working state and is the key reference for verifying whether the repaired code can accurately parse the network element data. Second, after updating the parsing code of the network element according to the repair result, the original instruction output of the network element is parsed again using the repaired parsing code to test the parsing ability of the repaired code for the target network element data, and the first parsing result is obtained. Then, the first parsing result is compared with the historical baseline data to check whether the data format and key field values are consistent, and the first verification result is determined. If the parsing result is consistent with the historical baseline data, it means that the repair code has correct parsing effect on the target network element; if it is not consistent, it means that the repair code may still have defects and needs to be further adjusted.

[0111] Second verification: compatibility test of network elements in the same batch.

[0112] In the case of passing the first verification, the repaired parsing code is applied to other successfully collected and parsed network elements in the same batch to reparse the original instruction output of these network elements, and the second parsing result is obtained. Network elements in the same batch usually have similar device models, software versions, and data formats, so this verification can test the universal applicability of the repaired code. By checking whether the second parsing result is consistent with the corresponding original collected data of the network elements and whether the accuracy of data parsing is maintained, the second verification result is determined. If the repaired code can correctly parse other network elements in the same batch, the second verification result indicates that the code repair result has good compatibility and stability among multiple devices; if there is a mismatch, it may mean that the code repair has insufficient compatibility for specific data formats or software versions, and further adjustment is needed to adapt to more devices.

[0113] In the self-healing mechanism of the parsing code, only when the repaired parsing code passes the double verification of historical baseline data comparison and compatibility test of network elements in the same batch, the code update operation will be performed; at the same time, in order to preserve the state before repair, the system will automatically backup the original parsing code before updating, thereby building a progressive and prudent code repair and deployment strategy.

[0114] If problems are found at any stage of the double verification, such as the repaired code fails to correctly parse data, or new problems are introduced on the same batch of network elements, the system will reconstruct the prompt, adjust the input information generated by the repair code, try different repair strategies, and perform double verification again. If the verification result still fails after multiple attempts (such as 3 times), manual intervention process will be automatically triggered, and detailed fault report and repair attempt record will be generated to facilitate the operation and maintenance personnel to quickly understand the problem background and the solutions that have been tried, so as to perform more in-depth analysis or manual adjustment of the code to ensure that the problem is solved.

[0115] In the embodiments of the present application, a knowledge base updating mechanism is also introduced, including: generating triples according to the parsed code, the code repair result and the corresponding verification result; storing the triples into the historical repair knowledge base.

[0116] Specifically, for successful repair cases, the system also records the original parsing code, the code repair result (including failure reason and repair code) and the corresponding verification result in detail, forms triples and stores them into the knowledge base, and builds an increasingly rich case library and experience pool. When facing new parsing code failures, the RAG technology will retrieve the most similar repair cases from the knowledge base according to the context and characteristics of the current problem, integrate the case information into the prompt, and guide the large model to generate more accurate repair code. This intelligent repair based on historical cases avoids blind debugging from scratch, greatly improving the efficiency and success rate of code repair.

[0117] Overall, in the embodiments of the present application, by constructing a context-aware fault classification mechanism, the fault root cause can be accurately locked, and a three-level root cause classification result with confidence is output. Especially in terms of parsing code errors, by using dynamic context capture and multiple prompt construction, repair code can be automatically generated and uniquely adopted historical baseline and same model network element compatibility double verification mechanism to ensure the accuracy and safety of repair. In addition, through the updating and application of the knowledge base, an automated closed loop of fault diagnosis, code repair, verification and deployment is formed, which not only greatly improves the operation and maintenance efficiency and reduces the frequency of manual intervention, but also realizes the knowledge transfer across devices, provides strong support for the intelligentization of data collection and parsing in communication network management, and effectively solves the industry pain points such as fault positioning difficulty, slow repair and low knowledge reuse rate of network element collection in large-scale network environment.

[0118] According to the embodiments of the present application, a fault diagnosis device for data collection is provided. It should be noted that the fault diagnosis device for data collection provided in the embodiments of the present application can be used to execute the fault diagnosis method for data collection provided in the embodiments of the present application. The fault diagnosis device for data collection provided in the embodiments of the present application is introduced as follows.

[0119] Figure 3 is a structural diagram of a data collection fault diagnosis device provided according to an embodiment of the present application. As shown in the figure, the device comprises: Figure 3

[0120] an acquisition module 30, configured to acquire multi-source heterogeneous logs corresponding to the network element in the case of network element data collection failure;

[0121] an analysis module 32, configured to analyze the multi-source heterogeneous logs by a fault analysis model to obtain a fault root cause classification result, wherein the fault root cause classification result comprises at least one of the following: scheduler execution abnormality, network element abnormality and parsing code abnormality;

[0122] a first generation module 34, configured to acquire parsing code corresponding to the network element in the case of the fault root cause classification result being the parsing code abnormality, and generate a prompt word according to the parsing code, historical repair cases and a preset repair requirement;

[0123] a second generation module 36, configured to take the prompt word as an input of the fault analysis model to guide the fault analysis model to generate a code repair result corresponding to the network element.

[0124] Through the acquisition module, the analysis module, the first generation module and the second generation module in the data collection fault diagnosis device, the purpose of accurately locating the reason for network element data collection failure and automatically repairing the parsing code is achieved, thereby realizing the technical effects of significantly improving operation and maintenance efficiency, optimizing collection success rate and promoting knowledge reuse, and further solving the technical problems in the related art that the log monitoring system cannot accurately locate the fault root cause and is highly dependent on manual experience to repair the parsing code in the case of high network element data collection failure rate.

[0125] In the data collection fault diagnosis device provided in the embodiment of the present application, the acquisition module is further configured to detect a network element data collection state after execution of a timing task, wherein the timing task is a network element data collection task containing a preset collection interval; in the case of abnormal collection state, acquire multi-source heterogeneous logs corresponding to the network element with data collection failure, and record identification information of the network element, wherein the multi-source heterogeneous logs at least include scheduling logs, network element logs and parsing code logs corresponding to the network element.

[0126] In the data collection fault diagnosis device provided in the embodiment of the present application, the analysis module is further configured to acquire thread information related to the scheduler by a thread monitoring module in the case of the fault root cause classification result being the scheduler execution abnormality, wherein the thread information comprises at least one of the following: thread quantity, thread state and thread resource occupation situation; analyze the thread information by the fault analysis model to obtain a scheduler execution repair result corresponding to the network element.

[0127] ​In the data acquisition fault diagnosis apparatus provided in the embodiments of the present application, the analysis module is further configured to, in the case that the fault root cause classification result is network element abnormality, send a connection request and authentication information to the network element according to the network protocol used by the network element in the data acquisition process; acquire response information of the network element after processing the connection request and the authentication information, and determine a connectivity verification result of the network element according to the response information; analyze the connectivity verification result through the fault analysis model to obtain a network element repair result corresponding to the network element.

[0128] In the data acquisition fault diagnosis apparatus provided in the embodiments of the present application, the analysis module is further configured to acquire original instruction output of the network element and abnormal stack information occurring in a running process of the analysis code corresponding to the network element; acquire a historical repair case corresponding to the analysis code through the retrieval enhancement algorithm according to the original instruction output, the analysis code and the abnormal stack information; and generate the prompt word according to the original instruction output, the analysis code, the abnormal stack information, the historical repair case and a preset repair requirement.

[0129] In the data acquisition fault diagnosis apparatus provided in the embodiments of the present application, the first generation module is further configured to acquire identification information of the network element; acquire a structural feature in the original instruction output, a format feature in the abnormal stack information and a function module label of the analysis code; and retrieve a plurality of historical repair cases with a similarity higher than a preset threshold to the analysis code from the historical repair knowledge base through the retrieval enhancement algorithm according to the identification information, the structural feature, the format feature and the function module label.

[0130] In the data acquisition fault diagnosis apparatus provided in the embodiments of the present application, the second generation module is further configured to determine data after successful collection and analysis of the network element for the last time before the data collection fails as historical baseline data; update the analysis code of the network element according to the code repair result, and re-analyze the original instruction output of the network element according to the updated analysis code to obtain a first analysis result; determine a first verification result according to the first analysis result and the historical baseline data, and in the case that the first verification result indicates that the analysis result is consistent with the historical baseline data, analyze the original instruction output of other network elements in the same batch which are successfully collected and analyzed according to the code repair result to obtain a second analysis result; determine a second verification result according to the second analysis result, and in the case that the second verification result indicates that the code repair result can analyze other network elements, determine that the code repair result is correct.

[0131] In the data acquisition fault diagnosis apparatus provided in the embodiments of the present application, the second generation module is further configured to generate a triple according to the analysis code, the code repair result and the corresponding verification result; and store the triple to the historical repair knowledge base.

[0132] The embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory is used to store program instructions; the processor is connected with the memory and is used to execute the above-mentioned fault diagnosis method of data collection.

[0133] It should be noted that the above-mentioned electronic device is used to execute the above-mentioned fault diagnosis method of data collection, so the related explanations in the above-mentioned fault diagnosis method of data collection are also applicable to the electronic device, and details are not described herein. Figure 2

[0134] The embodiment of the present application further provides a non-volatile storage medium, comprising a stored computer program, wherein a device where the non-volatile storage medium is located executes the above-mentioned fault diagnosis method of data collection by running the computer program.

[0135] It should be noted that the above-mentioned non-volatile storage medium is used to execute the above-mentioned fault diagnosis method of data collection, so the related explanations in the above-mentioned fault diagnosis method of data collection are also applicable to the non-volatile storage medium, and details are not described herein. Figure 2 The embodiment of the present application further provides a computer program product, comprising computer instructions, which are executed by a processor to implement the above-mentioned fault diagnosis method of data collection.

[0136] It should be noted that the above-mentioned computer program product is used to execute the above-mentioned fault diagnosis method of data collection, so the related explanations in the above-mentioned fault diagnosis method of data collection are also applicable to the computer program product, and details are not described herein.

[0137] Figure 2 The above-mentioned serial numbers of the embodiments of the present application are only for description, and do not represent the advantages or disadvantages of the embodiments.

[0138] In the above-mentioned embodiments of the present application, the descriptions of the various embodiments are each focused on, and the parts not described in detail in an embodiment can be referred to the relevant descriptions of other embodiments.

[0139] In the above-mentioned embodiments of the present application, the descriptions of the various embodiments are each focused on, and the parts not described in detail in an embodiment can be referred to the relevant descriptions of other embodiments.

[0140] In the several embodiments provided by the present application, it should be understood that the disclosed technology can be implemented in other ways. Of course, the unit division in the above-mentioned device embodiment is only a logical function division, and there can be another division manner during actual implementation; for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the shown or discussed units can be indirect coupling or communication connection through some interface, and can be electrical or other forms. ​​

[0141] The units described as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, i.e. may be located in one place, or may be distributed to multiple units. Part or all of the units may be selected according to actual needs to achieve the purpose of the embodiment.

[0142] In addition, the functional units in each embodiment of the present application can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software functional unit.

[0143] The integrated unit, if realized in the form of a software functional unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application, essentially or the part that contributes to the prior art, or all or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, including a number of instructions to make a computer device (which can be a personal computer, a server or a network device, etc.) execute all or part of the steps of the method described in each embodiment of the present application. The foregoing storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disk, and various program code storage media.

[0144] The above is only the preferred embodiment of the present application, and it should be pointed out that for those skilled in the art, without departing from the principles of the present application, a number of improvements and refinements can be made, which should be considered as the protection scope of the present application.

Claims

1. A method of fault diagnosis of data acquisition, characterized in that, include: In the event that network data collection fails, obtain the multi-source heterogeneous logs corresponding to the network element; The multi-source heterogeneous logs are analyzed using a fault analysis model to obtain fault root cause classification results, wherein the fault root cause classification results include at least one of the following: scheduler execution anomaly, network element anomaly, and parsing code anomaly; If the fault root cause classification result is that the parsing code is abnormal, obtain the parsing code corresponding to the network element, and generate prompt words based on the parsing code, historical repair cases and preset repair requirements; The prompt words are used as input to the fault analysis model to guide the model in generating code repair results corresponding to the network element.

2. The method of claim 1, wherein, In the event that network data collection fails, obtain the multi-source heterogeneous logs corresponding to the network element, including: Detect the network data acquisition status after the execution of a scheduled task, wherein the scheduled task is a network data acquisition task with a preset acquisition interval; In the event of an abnormal acquisition status, the multi-source heterogeneous logs corresponding to the network element where data acquisition failed are obtained, and the identification information of the network element is recorded. The multi-source heterogeneous logs include at least the scheduling log, network element log, and parsing code log corresponding to the network element.

3. The method of claim 1, wherein, The method further includes: If the root cause classification result indicates that the scheduler is executing abnormally, the thread monitoring module obtains thread information related to the scheduler, wherein the thread information includes at least one of the following: number of threads, thread status, and thread resource usage. The thread information is analyzed using the fault analysis model to obtain the scheduler execution repair result corresponding to the network element.

4. The method of claim 1, wherein, The method further includes: If the fault root cause classification result indicates that the network element is abnormal, a connection request and authentication information are sent to the network element according to the data acquisition network protocol, wherein the data acquisition network protocol is the network protocol used by the network element during the data acquisition process. Obtain the response information of the network element after processing the connection request and authentication information, and determine the connectivity verification result of the network element based on the response information; The connectivity verification results are analyzed using the fault analysis model to obtain the network element repair results corresponding to the network element.

5. The method of claim 1, wherein, Based on the parsed code, historical repair cases, and preset repair requirements, prompt words are generated, including: Obtain the original instruction output of the network element, as well as the exception stack information that occurs during the execution of the parsing code corresponding to the network element; Based on the original instruction output, the parsed code, and the exception stack information, a retrieval enhancement algorithm is used to obtain historical repair cases corresponding to the parsed code; The prompt text shown is generated based on the original instruction output, the parsed code, the exception stack information, the historical repair cases, and the preset repair requirements.

6. The method of claim 5, wherein, Based on the original instruction output, the parsed code, and the exception stack information, a retrieval enhancement algorithm is used to obtain historical repair cases corresponding to the parsed code, including: Obtain the identification information of the network element; obtain a structural feature in the original instruction output, a format feature in the exception stack information, and a function module label of the parsed code; retrieve, according to the identification information, the structural feature, the format feature, and the function module label, a plurality of historical repair cases with a similarity higher than a preset threshold to the parsed code from a historical repair knowledge base through the retrieval enhancement algorithm.

7. The method of claim 6, wherein, After obtaining the code repair result corresponding to the network element, the method further comprises: determining data collected and parsed by the network element last time before the data collection fails as historical baseline data; updating the parsed code of the network element according to the code repair result, and re-parsing the original instruction output of the network element according to the updated parsed code to obtain a first parsing result; determining a first verification result according to the first parsing result and the historical baseline data, and in the case that the first verification result indicates that the parsing result is consistent with the historical baseline data, parsing the original instruction output of other network elements in the same batch that are successfully collected and parsed according to the code repair result to obtain a second parsing result; determining a second verification result according to the second parsing result, and in the case that the second verification result indicates that the code repair result can parse the other network elements, determining that the code repair result is correct.

8. The method of claim 7, wherein, The method further comprises: generating a triple according to the parsed code, the code repair result, and the corresponding verification result; storing the triple to the historical repair knowledge base.

9. A failure diagnosing apparatus for data acquisition, characterized by comprising: comprises: an acquisition module, configured to acquire multi-source heterogeneous logs corresponding to a network element in the case of network element data collection failure; an analysis module, configured to analyze the multi-source heterogeneous logs through a fault analysis model to obtain a fault root cause classification result, wherein the fault root cause classification result comprises at least one of the following: scheduler execution exception, network element exception, and parsed code exception; a first generation module, configured to, in the case that the fault root cause classification result is a parsed code exception, acquire a parsed code corresponding to the network element, and generate a prompt word according to the parsed code, historical repair cases, and a preset repair requirement; a second generation module, configured to take the prompt word as an input of the fault analysis model to guide the fault analysis model to generate a code repair result corresponding to the network element.

10. An electronic device, comprising: comprises: a memory and a processor, wherein the memory is configured to store program instructions; the processor is connected with the memory and is configured to execute the fault diagnosis method for data collection according to any one of claims 1 to 8.

11. A non-volatile storage medium, comprising: The non-volatile storage medium comprises a stored computer program, wherein a device where the non-volatile storage medium is located executes the fault diagnosis method for data collection according to any one of claims 1 to 8 by running the computer program.

12. A computer program product comprising computer instructions, characterized in that, The computer instructions are executed by the processor to implement the fault diagnosis method for data collection according to any one of claims 1 to 8.

Images