Fault diagnosis method and device, storage medium and electronic equipment

Abstract

The invention discloses a fault diagnosis method and device, a storage medium and electronic equipment, and relates to the technical field of artificial intelligence, the method is applied to a container platform, and the method comprises the following steps: obtaining context information of a container scheduling unit from a front-end page, generating first request information according to the context information and a natural language instruction input by a target object; querying associated information corresponding to the first request information from a database to obtain a query result; executing an execution instruction determined according to the first request information and the query result to obtain an execution result, the execution result comprising state information of the container scheduling unit and fault log information; and inputting the first request information, the query result and the execution result into a large language model to obtain a fault diagnosis result output by the large language model. The technical problem of low operation and maintenance efficiency of the container platform is solved, and the technical effect of improving the operation and maintenance efficiency of the container platform is achieved.

Description

Technical Field

[0001] The present application relates to the field of artificial intelligence technology, and in particular to a fault diagnosis method and device, a storage medium, and an electronic device. Background Art

[0002] With the rise in popularity of cloud computing and the prevalence of microservices architectures, container orchestration platforms, with their powerful declarative APIs (Application Programming Interfaces) and extensible architectures, have become the cornerstone of modern application deployment and operations. However, this powerful capability comes with dramatically increased system complexity. A typical cloud-native environment typically consists of dozens of interrelated resource objects, hundreds of configuration parameters, and a massive toolchain comprised of multiple subsystems, including monitoring, logging, tracing, and security. When a system failure occurs, troubleshooting often involves tedious analysis across multiple tools and data sources, relying heavily on the intuition and experience of experienced experts. This is inefficient and difficult to scale. Existing knowledge, whether from official documentation or internal knowledge bases, is often static and fragmented, failing to provide immediate, interactive guidance when operations personnel need it most.

[0003] This shows that the related technologies have the problem of low operation and maintenance efficiency of container platforms. Summary of the Invention

[0004] The present application provides a fault diagnosis method and apparatus, a storage medium, and an electronic device to at least solve the problem in the related art that system anomalies are prone to occur during concurrent upgrades of distributed storage systems.

[0005] The present application provides a fault diagnosis method, which is applied to a container platform, wherein the container platform is used to manage containers through a container scheduling unit; the method comprises: obtaining context information of the container scheduling unit from a front-end page, and generating first request information based on the context information and a natural language instruction input by a target object; querying associated information corresponding to the first request information from a database to obtain a query result; executing an execution instruction determined based on the first request information and the query result to obtain an execution result, wherein the execution result includes status information of the container scheduling unit and fault log information; and inputting the first request information, the query result, and the execution result into a large language model to obtain a fault diagnosis result output by the large language model.

[0006] The present application also provides a fault diagnosis device, including: an acquisition module, used to obtain context information of the container scheduling unit from a front-end page, and generate first request information based on the context information and the natural language instructions input by the target object; a query module, used to query the associated information corresponding to the first request information from the database to obtain a query result; an execution module, used to execute the execution instruction determined according to the first request information and the query result to obtain an execution result, wherein the execution result includes the container scheduling unit status information and fault log information; an acquisition module, used to input the first request information, the query result and the execution result into a large language model to obtain a fault diagnosis result output by the large language model.

[0007] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned fault diagnosis methods when executing the computer program.

[0008] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned fault diagnosis methods are implemented.

[0009] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned fault diagnosis methods when executed by a processor.

[0010] This application generates a request based on the natural language input by the target object and the contextual information of the container scheduling unit captured from the front-end page. Based on the request, the database is queried for content related to the request to obtain a query result. Then, based on the request and the queried content, a planned execution instruction is generated and executed to obtain an execution result including the container scheduling unit status information and fault log information. The request, query, and execution results are then input into a large language model for fault diagnosis to obtain a fault diagnosis result. This solves the technical problem of low container platform operation and maintenance efficiency and achieves the technical effect of improving the container platform operation and maintenance efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0012] Figure 1 This is a schematic diagram of an application scenario of a fault diagnosis method according to an embodiment of the present application;

[0013] Figure 2 is a flowchart of an optional fault diagnosis method according to an embodiment of the present application;

[0014] Figure 3 is a schematic diagram of an optional fault diagnosis system according to an embodiment of the present application;

[0015] Figure 4 This is a structural block diagram of an optional fault diagnosis device according to an embodiment of the present application. DETAILED DESCRIPTION

[0016] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0017] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0018] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0019] According to one aspect of the embodiment of the present application, a fault diagnosis method is provided. Optionally, in this embodiment, the fault diagnosis method can be applied to, but is not limited to, Figure 1 The hardware environment shown includes a terminal device 102 and a server 104. The server 104 can be connected to the terminal device 102 via a network and can be used to provide services (e.g., application services, etc.) for the terminal device 102 or a client installed on the terminal device 102. A database can be set on the server 104 or independently of the server 104 to provide data storage services for the server 104.

[0020] The aforementioned network may include, but is not limited to, at least one of the following: a wired network and a wireless network. The aforementioned wired network may include, but is not limited to, at least one of the following: a wide area network, a metropolitan area network, or a local area network. The aforementioned wireless network may include, but is not limited to, at least one of the following: Wi-Fi (Wireless Fidelity) and Bluetooth. The terminal device 102 may be, but is not limited to, a personal computer (PC), a mobile phone, a tablet computer, etc. The server 104 may be, but is not limited to, a cloud server, a server cluster, or other server types.

[0021] The fault diagnosis method of the embodiment of the present application can be executed by the server 104, or by the terminal device 102, or jointly by the server 104 and the terminal device 102. The fault diagnosis method of the embodiment of the present application can also be executed by the client installed on the terminal device 102.

[0022] Taking the fault diagnosis method in this embodiment executed by the terminal device 102 as an example, here, the terminal device 102 can be a physical host, and the fault diagnosis method in this embodiment is applied to the physical host. The memory that can be called by the physical host is divided into multiple memory levels, and one memory level of the multiple memory levels contains at least one type of memory, and the multiple memory levels include a first memory level corresponding to the physical memory of the physical host. Here, the physical host can be enterprise-level servers, cluster servers, office computers, embedded devices, and other physical devices that can serve as the underlying hardware support in a virtualized environment. Physical memory refers to the physical memory module directly and closely connected to the host hardware. It is the core and foundation of the memory architecture. Typically composed of dynamic random access memory (DRAM), physical memory boasts extremely fast read and write speeds, responding to processor memory access requests with nanosecond response times. This makes physical memory suitable for hosting the core code of the virtual machine's operating system, frequently called system function libraries, and data from critical, high-speed processes. For example, during the initial startup of a virtual machine, the operating system kernel needs to quickly load and initialize various hardware drivers and establish a basic system operating environment. During this time, physical memory can efficiently complete data read and write operations, ensuring the rapid and stable startup of the virtual machine. During virtual machine operation, applications with extremely demanding memory read and write performance, such as the transaction processing module of a database management system and the real-time rendering engine, also rely on physical memory to ensure efficient operation, thereby maintaining the smoothness and responsiveness of the entire virtual machine system.

[0023] Figure 2 FIG. 1 is a flow chart of an optional fault diagnosis method according to an embodiment of the present application, such as Figure 2As shown, the process of the method may include the following steps:

[0024] Step S202: Obtain context information of the container scheduling unit from the front-end page, and generate first request information according to the context information and the natural language instruction input by the target object;

[0025] Optionally, in step S202, the container scheduling unit is the smallest scheduling unit in the container platform. For example, a developer is viewing the details page of a Pod (the smallest scheduling unit in Kubernetes, also known as a container group) in the Kubernetes console and discovers that its status is abnormal. They then activate the container platform's built-in troubleshooting system and ask, "There seems to be a problem with this Pod. Can you help me check it out?" The intelligent assistant then immediately captures the context of the current page and automatically identifies that the user is viewing the Pod with the ID "shopping-cart-7f..." in the "dev" namespace. This contextual information and the user's question are sent as initial data to the backend to generate the request information.

[0026] Step S204: querying the database for associated information corresponding to the first request information to obtain a query result;

[0027] Step S206: executing the execution instruction determined according to the first request information and the query result to obtain an execution result, wherein the execution result includes container scheduling unit status information and fault log information;

[0028] Optionally, in the above step S206 , the execution instruction includes a series of tool calling requests, and executing the above execution instruction is to obtain the container scheduling unit status information and fault log information by calling the tool.

[0029] Step S208: input the first request information, the query result, and the execution result into the large language model to obtain the fault diagnosis result output by the large language model.

[0030] Through the above steps, a request message is generated based on the natural language input by the target object and the context information of the container scheduling unit captured from the front-end page. Based on the request message, the database is queried for content related to the request message to obtain a query result. Then, based on the request message and the queried content, a planned execution instruction is generated and executed to obtain an execution result including the container scheduling unit status information and fault log information. The request message, query result, and execution result are then input into the large language model for fault diagnosis to obtain a fault diagnosis result. This solves the technical problem of low container platform operation and maintenance efficiency and achieves the technical effect of improving the container platform operation and maintenance efficiency.

[0031] In an exemplary embodiment, the database includes a knowledge base and an experience base, and the corresponding associated information of the first request information is queried from the database to obtain the query result, including: querying the knowledge base according to the first request information to obtain the knowledge base query result, wherein the knowledge base query result includes the technical document information corresponding to the first request information; and querying the experience base according to the first request information to obtain the experience base query result, wherein the experience base query result includes the fault case information corresponding to the first request information; determining the query result based on the knowledge base query result and the experience base query result.

[0032] Optionally, in the above embodiment, for example, if the keyword "Pod restart" is contained in the user's question in the first request information, technical documents related to Pod restart will be queried from the knowledge base, and fault cases related to Pod restart will be queried from the experience base.

[0033] Through the above-mentioned embodiments, the dual-drive mechanism of a knowledge base and an experience base has enabled a shift from blind exploration to empirical guidance. When encountering difficult and complex problems, the system can instantly call upon previously successfully resolved cases, directly locate the most likely cause, and develop an optimal diagnostic path. This shortens the troubleshooting process, which could take tens of minutes or even hours and involve multiple rounds of manual inspection, to one or two rounds of automated diagnosis in just a few minutes. This experience-based reasoning acceleration capability is unmatched by simple tools or documentation, saving enterprises significant troubleshooting time.

[0034] In an exemplary embodiment, a knowledge base is queried based on first request information to obtain a knowledge base query result, including: vectorizing the first request to obtain a first vector; determining a first index vector based on the similarity between the first vector and each knowledge base index vector in the knowledge base, wherein the similarity between the first index vector and the first vector is greater than a first preset similarity; and determining the document information in the knowledge base corresponding to the first index vector as the knowledge base query result.

[0035] In an exemplary embodiment, before querying the knowledge base based on the first request information and obtaining the knowledge base query results, the method also includes: performing text segmentation on all acquired technical documents based on text semantics to obtain multiple text blocks; performing semantic vectorization on each text block to obtain a semantic vector; determining the semantic vector as a knowledge base index vector, and determining the text block corresponding to the semantic vector as the document information corresponding to the knowledge base index vector.

[0036] Optionally, in the above embodiment, the built-in fault diagnosis system of the container platform provides an independent and configurable data processing pipeline. This pipeline is responsible for connecting to different data sources, such as Markdown-formatted documents in the remote code repository Git, instruction documents in the official website of Kubernetes, etc., using a text segmentation algorithm to divide technical documents into semantically complete blocks, converting text blocks into vectors by calling the API of the text vectorization model, and storing them together with the original text and metadata in a dedicated vector database. When processing user requests, the key information extracted from the request information is vectorized, and an efficient approximate nearest neighbor search is performed in the vector database to recall the most relevant text blocks.

[0037] In an exemplary embodiment, an experience library is queried based on first request information to obtain an experience library query result, including: vectorizing the first request to obtain a second vector; determining a second index vector based on the similarity between the second vector and each experience library index vector in the experience library, wherein the similarity between the second index vector and the first vector is greater than a second preset similarity; and determining the fault case information corresponding to the second index vector in the experience library as the experience library query result.

[0038] In an exemplary embodiment, after obtaining the fault diagnosis result output by the large language model, the method also includes: generating structured data based on the first request information, query results, execution results and fault diagnosis results; vectorizing the structured data to obtain a third vector; determining the third vector as an experience library index vector, and determining the structured data as fault case information corresponding to the experience library index vector.

[0039] Optionally, in the above embodiment, when a complex problem is successfully resolved, the system encapsulates the complete interaction process into an "experience case." This case is a structured object that includes the initial problem description, key resource status characteristics, the complete "LLM (Large Language Model) thinking - tool invocation - result feedback" sequence, and the final solution. These cases are vectorized and stored in a dedicated experience library. When processing new user requests, the system performs a similarity search in the experience case library. If a highly similar case is recalled, the successful resolution path of this case is given a high-priority reference.

[0040] Through the above examples, various scattered implicit knowledge can be structured and computable through the document knowledge base and experience case library. It is not only a static query system, but also a dynamic knowledge engine that can proactively push relevant knowledge based on the problems encountered by users in real time. More importantly, by continuously accumulating successful solutions into new experience cases, the system builds a knowledge system that can self-improve and continuously evolve, continuously empowering all users of the platform.

[0041] In an exemplary embodiment, executing an execution instruction determined based on the first request information and the query result to obtain an execution result includes: obtaining a tool list of the container platform, wherein the tool list includes multiple tools, and each tool corresponds to a packaged executable operation unit; inputting the first request information, the query result, the tool list, and the first prompt word into a large language model to obtain an execution instruction output by the large language model, wherein the first prompt word is used to instruct the large language model to directly determine the execution result through the tool in the tool list, and the execution instruction is used to initiate a tool call request to the tool in the tool list; initiating a tool call request to the tool in the tool list according to the execution instruction to obtain a call result, and determining the call result as the execution result.

[0042] Optionally, in the above embodiment, the tools in the tool list are obtained by standardizing and encapsulating application programming interfaces, system commands, database commands, etc. through the Model Context Protocol (MCP). For example, initiating a tool call request includes viewing Pod details using the Kubernetes "get_pod_details" command and viewing Pod log information using the "get_pod_logs" command.

[0043] Optionally, in the above embodiment, for example, the first request information includes user question information, context information captured by the page, and the query results include technical documents in the knowledge base and similar cases in the case library. Then all the above information and tool list are sent to the large language model. The large language model understands the user's intention based on multi-source information, and then generates an action plan. The plan includes specific execution steps, and then determines the tools to be called for each step and then determines the specific execution instructions. Finally, the instructions are executed to obtain the execution results.

[0044] In an exemplary embodiment, executing an execution instruction determined based on the first request information and the query result to obtain an execution result includes: obtaining a tool list of the container platform, wherein the tool list includes multiple tools, and each tool corresponds to a packaged executable operation unit; inputting the first request information, the query result, the tool list, and the second prompt word into a large language model, obtaining a data acquisition instruction and a data processing script output by the large language model, wherein the second prompt word is used to instruct the large language model to process the target data to obtain an execution result; initiating a tool call request to the tool in the tool list according to the data acquisition instruction to obtain the target data; and determining the execution result based on the target data and the data processing script.

[0045] In an exemplary embodiment, determining an execution result based on target data and a data processing script includes: creating a sandbox code interpreter, which is an independent temporary code execution environment; inputting the target data and the data processing script into the sandbox code interpreter; and executing the data processing script on the target data in the sandbox code interpreter to obtain an execution result.

[0046] Optionally, in the above embodiment, for analytical queries requiring aggregate calculations, such as calculating the total CPU requests for each namespace, there are no readily available tools. In this case, LLM generates a tool call chain, first calling the "get_all_pods_with_metrics" tool to obtain raw data for all pods, then passing this data to a built-in, sandboxed code interpreter. Simultaneously, LLM generates a data processing script that aggregates, calculates, and sorts the data in a secure execution environment, and returns the final results.

[0047] In an exemplary embodiment, before initiating a tool call request to a tool in a tool list according to an execution instruction, the method also includes: determining whether the tool call request requires approval according to a preset approval policy; pushing the approval request to the target object on the front-end page if it is determined that approval is required; after receiving the approval instruction of the target object, obtaining the identity credentials of the target object; and initiating a tool call request through the identity credentials.

[0048] Optionally, in the above embodiment, the system supports configuring policies for different tools or operations to determine whether manual approval is required. Furthermore, all tool invocation requests in the system must pass through a unified security gateway. This gateway enforces the use of the identity token of the end user initiating the operation and, through Kubernetes' user impersonation feature, executes the operation as that user.

[0049] Through the above implementation, deep integration with the platform's existing role-based access control system ensures that all AI operations strictly adhere to the end user's permissions, eliminating abuse of permissions. Approval policies provide a safety net for high-risk operations such as deletion and modification, ensuring that critical changes are performed under human supervision.

[0050] In an exemplary embodiment, after generating the first request information based on the context information of the container scheduling unit obtained from the front-end page and the natural language instructions input by the target object, the method also includes: determining a progress display area in the front-end page; and displaying the processing progress of the first request information to the target object in real time in the progress display area.

[0051] Optionally, in the above embodiment, throughout the lifecycle of a task, the backend proactively pushes structured messages with specific event types. For example, it pushes a "tool call started" event to notify the frontend that a tool is being called, with the event payload containing the tool name and parameters. After the call is complete, it pushes a "tool call completed" event with the tool call result. This allows the frontend to render rich, dynamic UI elements, such as displaying "Calling 'kubectl get pod'..." in a card window.

[0052] Through the above embodiments, the traditional black box waiting mode of request to response is broken, and the user's understanding and trust in the system behavior is greatly enhanced.

[0053] An optional fault diagnosis method of the embodiment of the present application is described below in conjunction with an optional embodiment. In an optional embodiment, the fault diagnosis method can be implemented by building a fault diagnosis system into the container platform, such as Figure 3 As shown in the figure, the fault diagnosis system is logically divided into five layers with clear responsibilities and high decoupling:

[0054] Context-aware interaction layer: A portal for users to collaborate with the system. Deeply integrated into the container platform web console, it is the place where intent is input and results are presented.

[0055] Intent understanding and strategy generation layer: responsible for converting natural language, context, and external knowledge into structured action plans.

[0056] Unified capability scheduling and governance layer: responsible for dynamically connecting, managing, authenticating, and calling all back-end tools.

[0057] Persistent memory and experience library layer: Responsible for persistent storage of sessions, configurations, checkpoints, and success cases, and provides a foundation for future auditing and reasoning acceleration.

[0058] External tools and knowledge sources: All external content that the system can perceive and operate, including all Kubernetes APIs encapsulated by the MCP protocol, as well as various vectorized technical documents and troubleshooting cases.

[0059] Optional, such as Figure 3 As shown in the figure, the context-aware interaction layer includes the following modules:

[0060] 1. Visual interface for cognitive processes: This interface is more than just a chat box; it's a window for users to observe the system's thinking process. Its technical core lies in real-time streaming communication established by the backend through server-sent events. In the system, the API controller responsible for processing chat requests returns a streaming response. Throughout the lifecycle of a task, the backend proactively pushes structured messages with clear event types. For example, it pushes a "tool call started" event to notify the frontend that a tool is being called. The event payload contains the name and parameters of the called tool. After the call is complete, it pushes a "tool call completed" event. The event payload contains the tool call result. This allows the frontend page to render rich, dynamic interface elements, such as displaying "Calling 'kubectl get pod'..." in a card window.

[0061] 2. Automatic Context Capture: As a component deeply embedded in the container platform's web console, it is aware of the user's current operational context. By monitoring the web application's routing changes or accessing its global state manager, the front-end plug-in can automatically extract key information about the resource the user is viewing, such as the Pod name, namespace, and resource type. When a user activates the fault diagnosis system's intelligent assistant, this contextual information is automatically sent to the backend as part of the initial payload, along with the user's first question (e.g., "What's wrong with this Pod?"). This capability allows users to ask questions naturally and concisely, without having to manually specify the target of the operation, greatly improving the fluidity and efficiency of the interaction.

[0062] 3. Interactive Clarification Mechanism: When the intent understanding and policy generation layer encounters uncertainty, for example, when a user says "Create a Pod" but doesn't specify an image, a special "clarification_required" event is generated. The event's payload contains a question (such as "Please select a container image") and a data structure (such as a JSON object containing a list of recommended images). After receiving this event, the frontend renders the corresponding interactive component, such as a drop-down menu or a set of option buttons. The user's selection is sent back to the backend as supplementary information for the current plan, driving multiple rounds of dialogue.

[0063] 4. High-risk operation approval card: When an operation initiated by the backend requires user approval, an "approval_required" event is pushed. The frontend renders a card containing the operation details and an "Approve / Reject" button. The user's decision determines the subsequent process.

[0064] 5. Deeply integrated web console interface: As an embedded sidebar in the web console, it provides accompanying assistance and can also be maximized into an independent window for handling complex problems and providing an immersive conversation experience.

[0065] Optional, such as Figure 3 As shown in the figure, the intent understanding and strategy generation layer includes the following modules:

[0066] 1. Retrieval Enhancement Engine: The system provides an independent, configurable data processing pipeline. This pipeline is responsible for connecting to different data sources (such as Markdown documents in Git repositories and Confluence pages), using text segmentation algorithms to split long documents into semantically complete text blocks, converting text blocks into vectors by calling the text vectorization model's API, and storing them together with the original text and metadata in a dedicated vector database. When processing user requests, the engine vectorizes the user's original question or extracted key error information, performs an efficient approximate nearest neighbor search in the vector database, and recalls the K most relevant text blocks. These recalled text blocks, as "instant knowledge", are dynamically injected into the context scaffolding of the prompt word to improve the accuracy and depth of the LLM answer.

[0067] 2. Multi-turn Conversation and State Management Module: To support continuous tasks such as virtual machine creation and step-by-step debugging, the system maintains a state object for each conversation session in the persistent memory and experience library layer. This object, stored in a memory cache or database in JSON format, records key information from each conversation round, such as confirmed parameters, pending questions, and historical tool call results. During each round of interaction, this state object is loaded into the context, enabling the LLM to understand the continuity of the conversation.

[0068] 3. Complex Query Reasoning Engine: This engine is the core for solving complex problems that are not straightforward and require in-depth analysis.

[0069] 3.1 Query Decomposition: When receiving a complex query (e.g., "List all Deployments in the production environment that have restarted more than 5 times"), the first task of the LLM is to decompose it into a subtask graph with logical dependencies. For example, the nodes of the graph may include: (1) List all Pods; (2) Filter out Pods in the production environment; (3) Filter out Pods with more than 5 restarts; (4) Get the parent ReplicaSet of each Pod; (5) Get the parent Deployment of each ReplicaSet; (6) Dedupe and output a list of Deployments.

[0070] 3.2 Execution Coordinator: An execution coordinator is responsible for executing the above task graph in sequence. It calls the corresponding tool to execute each node and saves the execution results (such as the Pod list) in the state object of the current session as the input of the next node.

[0071] 4. Code Interpreter: For analytical queries requiring aggregate calculations, such as calculating the total CPU requests per namespace, there are no readily available tools. LLM generates a tool call chain, first calling the "get_all_pods_with_metrics" tool to obtain raw data for all pods. This data is then passed to a built-in, sandboxed code interpreter. Simultaneously, LLM generates a data processing script that aggregates, calculates, and sorts the data in a secure execution environment and returns the final results. This capability enables the system to answer a virtually unlimited number of open-ended analytical questions.

[0072] 5. LLM-driven Intent-to-Plan Converter: This component is responsible for parsing the action plans generated by the LLM and containing MCP tags. A key enhancement is that when a user's question is not matched to any available tools and the knowledge base does not return a high-confidence answer, the system is designed to return a clear prompt: "Sorry, I cannot match your question to any known operational tools or knowledge base entries. My capabilities are primarily focused on assisting you in managing and querying container platform resources." This tool matching restriction ensures that the system focuses on its core mission.

[0073] Optional, such as Figure 3 As shown, the unified capacity scheduling and governance layer includes the following modules:

[0074] 1. Dynamic Capability Discovery and Configuration Center: Administrators manage all MCP tool servers through a visual interface. Each registered tool has a status switch. When this layer provides the list of available capabilities to the intent understanding and policy generation layer, it filters out any disabled tools. The system provides a policy configuration module to implement approval management for tool calls. Administrators can granularly configure whether approval is required for each tool, and this configuration is stored along with the tool metadata.

[0075] 2. Unified Security and Permission Enforcement Gateway: This is the only way for all tool calls to pass through, and it enforces security checks before execution.

[0076] 3. Approval Process Executor: When a tool invocation request is sent by an upper-layer service, the gateway first checks the tool's approval policy. If approval is required, it pauses execution, pushes an "approval_required" event to the context-aware interaction layer, and marks the current execution process status as "pending_approval" and persists it.

[0077] 4. Permission control and user impersonation: The system integrates with the container platform's authentication system. When a user logs in, the system obtains their identity token. Each time a tool call is initiated, the token is passed along with the request to the MCP protocol scheduling hub, which ultimately executes the operation. When the MCP protocol scheduling hub interacts with the Kubernetes API service, it must use this token for user impersonation. This means that all operations are performed as the end user, naturally inheriting the platform's existing RBAC (Role-Based Access Control) permission policy to ensure that users can only operate resources within their authorized scope.

[0078] 5.MCP protocol scheduling center: responsible for scheduling tool call requests and distributing the requests to the corresponding service providers.

[0079] Optional, such as Figure 3 As shown, the persistent memory and experience library layer includes the following modules:

[0080] 1. Structured session storage and audit logs:

[0081] Conversation persistence: All user interactions with the agent, including every message, tool call, knowledge base search, and approval decision, are modeled using object-relational mapping and persisted as structured data in a relational database. Users can review and restore historical conversations.

[0082] Audit log: A persistent and detailed log that forms a complete audit trail for security administrators to query.

[0083] 2. Conversation Checkpoint and Rollback: This feature is implemented by snapshotting and restoring the session state. At key points in a multi-round conversation, the system automatically creates snapshots of the current session state. When a user requests a rollback, the system retrieves the latest state snapshot and restores it to the current active session state, allowing users to safely explore complex operation sequences.

[0084] 3. Experience Case Library and Reasoning Acceleration:

[0085] Case Generation and Storage: When a complex problem is successfully resolved, the system encapsulates the entire interaction process into an "experience case." This case is a structured object that includes the initial problem description, key resource status characteristics, the complete "LLM (Large Language Model)" thinking-tool invocation-result feedback" sequence, and the final solution. These cases are vectorized and stored in a dedicated experience database. When processing new user requests, the system searches the experience case database for similarities. If a highly similar case is recalled, its successful resolution path is prioritized for reference.

[0086] Case-based reasoning: When the intent understanding and policy generation layer receives a new question, it simultaneously searches for similarities in the document knowledge base and the empirical case library. If a highly similar case is retrieved, the successful solution path (i.e., the tool invocation sequence) for that case is provided as a high-priority reference to the LLM. This allows the LLM to skip numerous exploratory intermediate steps and directly propose a proven, efficient solution, thereby shortening the reasoning process and accelerating reasoning.

[0087] Optional, such as Figure 3 As shown, external tools and knowledge sources can access Kubernetes APIs, container image repository tools, monitoring system tools, document knowledge base tools, and other tools. All tools are encapsulated using the MCP protocol.

[0088] In an optional embodiment, the fault diagnosis system in the above embodiment is used to illustrate the fault determination method of the present application in combination with a specific application scenario.

[0089] Take the complete life cycle of a user from asking a question to solving the problem as an example to illustrate.

[0090] Step 1: Initialization and context information capture.

[0091] In this embodiment, the system is deployed as a front-end plug-in and a back-end service cluster for the container management web platform used by users. When a user logs in to the web platform and navigates to the details page of a resource (for example, a Pod named api-gateway-xyz in the production namespace), the context-aware interaction layer (front-end plug-in) of the present invention is activated. The plug-in automatically obtains and temporarily stores the current context information by listening to the routing events of the front-end application or accessing its global state management library. Its data structure can be represented as: {"context_type":"resource_view","resource":{"kind":"Pod","name":"api-gateway-xyz","namespace":"production"}}. At this time, an interactive smart assistant icon or sidebar appears on the interface.

[0092] Step 2: User intent initiation and preliminary processing.

[0093] The user clicks the assistant icon and enters the question: "Why does this Pod keep restarting?" The front-end plug-in packages the user's natural language question with the contextual information captured in the previous step and sends it to the back-end "Intent Understanding and Policy Generation Layer" via a secure HTTPS request. An example of the request payload is as follows: {"session_id": "session-12345","query": "Why does this Pod keep restarting?","context": {...}}. The back-end entry point is an API service built on the Python asynchronous framework. It first creates or loads a session state object for the session_id, which is stored in a memory cache such as Redis to support multiple rounds of conversation.

[0094] Step 3: Knowledge-enhanced intention understanding and action planning.

[0095] After the intent understanding and strategy generation layer receives the request, its internal "complex query reasoning engine" is started.

[0096] 1. Knowledge Base Search: The engine first extracts keywords from user questions, such as "Pod restart." These keywords are vectorized and then fed into a document knowledge base built on a vector database for similarity search. For example, a snippet from the official documentation describing the "CrashLoopBackOff" status is retrieved, explaining possible causes (e.g., a crash immediately after program startup, configuration errors, etc.).

[0097] 2. Experience Database Search: The engine vectorizes the more specific problem feature, "Pod 'api-gateway-xyz' in 'production' restarting," and searches for it in the experience database. Suppose a highly similar case is found, with the following summary: "Case 78: The 'billing-service' pod entered the 'CrashLoop-BackOff' state due to a database 'ConfigMap' configuration error. A 'connection refused' error was detected in the logs and resolved by correcting the 'ConfigMap'."

[0098] 3. LLM-driven plan generation: The engine constructs a rich prompt and submits it to the LLM. The prompt consists of the following parts:

[0099] System role definition: You are a senior Kubernetes SRE assistant.

[0100] List of available tools (compliant with MCP specifications): Obtained by querying the unified capability scheduling and governance layer, such as "k8s_tools.get_pod_details" and "k8s_tools.get_pod_logs".

[0101] Injected knowledge: Contains text recalled from the document knowledge base and the experience case base.

[0102] Conversation history and current context: Contains the history of "session_id" and the context of the current Pod.

[0103] User Instructions: Based on the above information, develop the most efficient diagnostic plan for the user's question, "Why does this Pod keep restarting?"

[0104] After receiving this hint word containing prior knowledge, LLM's reasoning process is significantly optimized. Instead of generating a general plan, it generates a highly targeted and structured action plan (output in JSON format) based on the hints from the experience library: {"plan": [{"step":1,"thought":"The user reported that the Pod restarted, which is usually CrashLoopBackOff. The experience library suggests that this may be related to the configuration. First, I need to call get_pod_details to confirm the exact status and restart count of the Pod.","action":{"tool_name":"k8s_tools.get_pod_details","parameters":{"name":"api-gatew ay-xyz","namespace":"production"}}},{"step":2,"thought":"If the status is confirmed to be CrashLoopBackOff, both the experience base and the knowledge base point to checking the logs to find the direct cause of the startup failure. I will get the latest logs of the Pod. ","action":{"tool_name":"k8s_tools.get_pod_logs","parameters":{"name":"api-gateway-xyz","namespace":"production","lines":200}}}]}.

[0105] Step 4: Controlled, auditable execution of actions.

[0106] The system's stateful execution coordinator parses the above plans and executes them one by one.

[0107] 1. The coordinator sends a request to the unified capability scheduling and governance layer to call "k8s_tools.get_pod_details".

[0108] 2. Security and Permissions Gateway: The request first passes through the gateway. The gateway checks the tool's metadata and finds that this is a read-only operation, requiring no approval. The gateway extracts the user's identity token from the session and appends it to the request header sent to the "k8s_tools" tool server.

[0109] 3. Tool Server Execution: The "k8s_tools" server is a standalone microservice. Upon receiving the request, it uses the user token it receives to interact with the Kubernetes API server via the Kubernetes client library, setting the "User Impersonation" header in its request. This means that the operation is performed as the end user, fully constrained by that user's existing RBAC permissions in Kubernetes. If the user does not have permission to view pods in the "production" namespace, the API server will simply reject the request.

[0110] 4. Result Return and Logging: The "k8s_tools" server returns the Pod configuration description obtained from the API server to the coordinator. Simultaneously, the audit module in the persistent memory and experience database layer records the call (caller, tool, parameters, and timestamp) in the database.

[0111] Step 5: Iterative analysis and expert translation of results.

[0112] The coordinator updates the execution results of the first step (Pod configuration, confirmation status of CrashLoopBackOff, and restart count of 15) to the session state and continues with the second step of the plan: obtaining logs. The execution process is the same as above. Assume that the returned log fragment contains the key error message Error: Invalid connection string in config file / etc / config / db.conf. The coordinator submits all execution results (Pod status, restart count, key logs) along with the original question and retrieved knowledge to the LLM again, and issues the final translation instruction: "Task completed. Please integrate all information and provide the user with a complete root cause analysis report and clear remediation suggestions." The LLM finally generates a user-friendly natural language response and pushes it to the front end:

[0113] "I noticed that the pod 'api-gateway-xyz' you are viewing is in a state of repeatedly restarting (CrashLoopBackOff) and has restarted 15 times.

[0114] Root cause analysis: According to the Pod logs, the program failed at startup because it couldn't parse the database connection string located in / etc / config / db.conf. Based on information I've found in the knowledge base, this is usually because a key in this configuration file (most likely from a ConfigMap named api-gateway-config) is malformed or references a non-existent key.

[0115] Repair suggestions:

[0116] 1. Please check: The ConfigMap resource named api-gateway-config associated with this Pod.

[0117] 2. Please check the db.conf data to ensure that the database address, port, and username are in the correct format.

[0118] 3. Action: You can modify the ConfigMap directly using the platform's YAML editor. After saving the changes, the relevant Pods will be automatically recreated and loaded with the new configuration. Do you want me to help you retrieve the contents of this ConfigMap?

[0119] Step 6: Experience accumulation.

[0120] After the problem is solved, the system may prompt the user or administrator: "This troubleshooting seems to have been successfully resolved. Would you like to save it as a case study to help quickly solve similar problems in the future?" If the user agrees, the system background will start a task to package the key elements of this session (initial problem, resource characteristics, successful diagnostic step sequence, final solution) into a structured JSON object. After vectorization, it is stored in the case study library, completing a closed loop of self-learning and evolution.

[0121] The above implementation frees users from the tedious and error-prone configuration writing and complex command line memorization. Developers and junior operations personnel no longer need to deeply learn the full details and command parameters of dozens of resource objects. Instead, they simply describe their intent in natural language, and the system intelligently translates it into accurate configuration and operation. This significantly reduces the learning curve for cloud native technology and the mental burden of daily use, enabling a wider range of technical personnel to efficiently and confidently leverage the capabilities of the container platform, thereby improving the productivity of the entire R&D team. This significantly improves the container platform's ease of use, operational efficiency, knowledge management, and security governance capabilities.

[0122] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the existing technology can be embodied in the form of a software product, which is stored in a storage medium (for example, read-only memory (ROM) / random access memory (RAM), a magnetic disk, or an optical disk), and includes a number of instructions for enabling a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods of each embodiment of the present application.

[0123] According to another aspect of the embodiments of the present application, a fault diagnosis device is also provided, which can be used to implement the fault diagnosis method provided in the above embodiments, and will not be repeated hereafter. As used below, the term "module" can implement a combination of software and / or hardware for a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and contemplated.

[0124] Figure 4 is a structural block diagram of an optional fault diagnosis device according to an embodiment of the present application, such as Figure 4 As shown in , the fault diagnosis device includes:

[0125] An acquisition module 42 is configured to acquire context information of the container scheduling unit from a front-end page and generate first request information according to the context information and a natural language instruction input by a target object;

[0126] A query module 44 is configured to query the database for associated information corresponding to the first request information and obtain a query result;

[0127] An execution module 46 is configured to execute an execution instruction determined according to the first request information and the query result, and obtain an execution result, wherein the execution result includes container scheduling unit status information and fault log information;

[0128] The obtaining module 48 is used to input the first request information, the query result and the execution result into the large language model to obtain the fault diagnosis result output by the large language model.

[0129] The fault diagnosis device provided in this application generates a request message based on the natural language input by the target object and the context information of the container scheduling unit captured from the front-end page. Based on the request message, the database is queried for content related to the request message to obtain a query result. Then, based on the request message and the queried content, a planned execution instruction is generated and executed to obtain an execution result including the container scheduling unit status information and fault log information. The request message, query result, and execution result are then input into a large language model for fault diagnosis to obtain a fault diagnosis result. This solves the technical problem of low container platform operation and maintenance efficiency, achieving the technical effect of improving the container platform operation and maintenance efficiency.

[0130] In an exemplary embodiment, the database includes a knowledge base and an experience base, and the query module 44 is used to query the knowledge base according to the first request information to obtain a knowledge base query result, wherein the knowledge base query result includes technical document information corresponding to the first request information; and query the experience base according to the first request information to obtain an experience base query result, wherein the experience base query result includes fault case information corresponding to the first request information; and determine the query result based on the knowledge base query result and the experience base query result.

[0131] In an exemplary embodiment, the query module 44 is used to vectorize the first request to obtain a first vector; determine the first index vector based on the similarity between the first vector and each knowledge base index vector in the knowledge base, wherein the similarity between the first index vector and the first vector is greater than a first preset similarity; and determine the document information in the knowledge base corresponding to the first index vector as the knowledge base query result.

[0132] In an exemplary embodiment, the query module 44 is used to perform text segmentation on all acquired technical documents according to text semantics to obtain multiple text blocks; perform semantic vectorization on each text block to obtain a semantic vector; determine the semantic vector as a knowledge base index vector, and determine the text block corresponding to the semantic vector as the document information corresponding to the knowledge base index vector.

[0133] In an exemplary embodiment, the query module 44 is used to vectorize the first request to obtain a second vector; determine the second index vector based on the similarity between the second vector and each experience library index vector in the experience library, wherein the similarity between the second index vector and the first vector is greater than a second preset similarity; and determine the fault case information corresponding to the second index vector in the experience library as the experience library query result.

[0134] In an exemplary embodiment, a module 48 is obtained, which is used to generate structured data based on the first request information, query results, execution results and fault diagnosis results; vectorize the structured data to obtain a third vector; determine the third vector as an experience library index vector, and determine the structured data as fault case information corresponding to the experience library index vector.

[0135] In an exemplary embodiment, the execution module 46 is used to obtain a tool list of the container platform, wherein the tool list includes multiple tools, and each tool corresponds to an encapsulated executable operation unit; the first request information, the query result, the tool list and the first prompt word are input into the large language model to obtain the execution instruction output by the large language model, wherein the first prompt word is used to instruct the large language model to directly determine the execution result through the tool in the tool list, and the execution instruction is used to initiate a tool call request to the tool in the tool list; according to the execution instruction, a tool call request is initiated to the tool in the tool list to obtain a call result, and the call result is determined as the execution result.

[0136] In an exemplary embodiment, the execution module 46 is used to obtain a tool list of the container platform, wherein the tool list includes multiple tools, and each tool corresponds to a packaged executable operation unit; input the first request information, the query result, the tool list, and the second prompt word into the large language model, and obtain the data acquisition instruction and data processing script output by the large language model, wherein the second prompt word is used to instruct the large language model to process the target data to obtain the execution result; initiate a tool call request to the tool in the tool list according to the data acquisition instruction to obtain the target data; and determine the execution result based on the target data and the data processing script.

[0137] In an exemplary embodiment, the execution module 46 is used to create a sandbox code interpreter, which is an independent temporary code execution environment; input target data and a data processing script into the sandbox code interpreter; execute the data processing script on the target data in the sandbox code interpreter to obtain an execution result.

[0138] In an exemplary embodiment, the execution module 46 is used to determine whether a tool call request requires approval based on a preset approval policy; if approval is determined to be required, the approval request is pushed to the target object on the front-end page; after receiving the approval instruction of the target object, the identity credentials of the target object are obtained; and the tool call request is initiated through the identity credentials.

[0139] In an exemplary embodiment, the device is further configured to determine a progress display area in a front-end page; and display the processing progress of the first request information to the target object in real time in the progress display area.

[0140] For the description of the features in the above-mentioned embodiments corresponding to the fault diagnosis device, reference can be made to the relevant description of the embodiments corresponding to the fault diagnosis method, which will not be repeated here.

[0141] An embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any of the above-mentioned fault diagnosis method embodiments.

[0142] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any of the above-mentioned fault diagnosis method embodiments when running.

[0143] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0144] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any of the above-mentioned fault diagnosis method embodiments are implemented.

[0145] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above-mentioned fault diagnosis method embodiments are implemented.

[0146] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0147] The above is a detailed introduction to the method and device, storage medium and electronic device of a distributed storage system provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core ideas of the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A fault diagnosis method, characterized in that: Applied to a container platform, the container platform is used to manage containers through a container scheduling unit; include: Acquire context information of the container scheduling unit from a front-end page, and generate first request information according to the context information and a natural language instruction input by a target object; Querying the database for associated information corresponding to the first request information to obtain a query result; executing an execution instruction determined according to the first request information and the query result to obtain an execution result, wherein the execution result includes status information and fault log information of the container scheduling unit; The first request information, the query result, and the execution result are input into a large language model to obtain a fault diagnosis result output by the large language model.

2. The fault diagnosis method according to claim 1, characterized in that: The database includes a knowledge base and an experience base, and the query result obtained by querying the database for the corresponding associated information of the first request information includes: querying the knowledge base according to the first request information to obtain a knowledge base query result, wherein the knowledge base query result includes technical document information corresponding to the first request information; and querying the experience database according to the first request information to obtain an experience database query result, wherein the experience database query result includes fault case information corresponding to the first request information; The query result is determined according to the knowledge base query result and the experience base query result.

3. The fault diagnosis method according to claim 2, characterized in that: The knowledge base is queried according to the first request information to obtain a knowledge base query result, including: Vectorizing the first request to obtain a first vector; determining a first index vector according to a similarity between the first vector and each knowledge base index vector in the knowledge base, wherein the similarity between the first index vector and the first vector is greater than a first preset similarity; The document information corresponding to the first index vector in the knowledge base is determined as the knowledge base query result.

4. The fault diagnosis method according to claim 2, characterized in that: Before querying the knowledge base according to the first request information and obtaining a knowledge base query result, the method further includes: Segment all acquired technical documents based on text semantics to obtain multiple text blocks; Perform semantic vectorization on each text block to obtain a semantic vector; The semantic vector is determined as a knowledge base index vector, and the text block corresponding to the semantic vector is determined as document information corresponding to the knowledge base index vector.

5. The fault diagnosis method according to claim 2, characterized in that: The experience database is queried according to the first request information to obtain an experience database query result, including: Vectorizing the first request to obtain a second vector; determining a second index vector according to a similarity between the second vector and each experience library index vector in the experience library, wherein the similarity between the second index vector and the first vector is greater than a second preset similarity; The fault case information corresponding to the second index vector in the experience database is determined as the experience database query result.

6. The fault diagnosis method according to claim 1, characterized in that: After obtaining the fault diagnosis result output by the large language model, the method further includes: generating structured data according to the first request information, the query result, the execution result, and the fault diagnosis result; Vectorizing the structured data to obtain a third vector; The third vector is determined as an experience library index vector, and the structured data is determined as fault case information corresponding to the experience library index vector.

7. The fault diagnosis method according to claim 1, characterized in that: Executing an execution instruction determined according to the first request information and the query result to obtain an execution result, including: Obtain a tool list of the container platform, wherein the tool list includes a plurality of tools, each tool corresponding to a packaged executable operation unit; inputting the first request information, the query result, the tool list, and a first prompt word into the large language model, and obtaining the execution instruction output by the large language model, wherein the first prompt word is used to instruct the large language model to directly determine the execution result through the tool in the tool list, and the execution instruction is used to initiate a tool call request to the tool in the tool list; A tool call request is initiated to the tool in the tool list according to the execution instruction, a call result is obtained, and the call result is determined as the execution result.

8. The fault diagnosis method according to claim 1, characterized in that: Executing an execution instruction determined according to the first request information and the query result to obtain an execution result, including: Obtain a tool list of the container platform, wherein the tool list includes a plurality of tools, each tool corresponding to a packaged executable operation unit; inputting the first request information, the query result, the tool list, and the second prompt word into the large language model, and obtaining the data acquisition instruction and data processing script output by the large language model, wherein the second prompt word is used to instruct the large language model to process the target data to obtain the execution result; Initiate a tool call request to the tool in the tool list according to the data acquisition instruction to obtain the target data; The execution result is determined according to the target data and the data processing script.

9. The fault diagnosis method according to claim 8, characterized in that: Determining the execution result according to the target data and the data processing script includes: Creating a sandbox code interpreter, wherein the sandbox code interpreter is an independent temporary code execution environment; Inputting the target data and the data processing script into the sandbox code interpreter; The data processing script is executed on the target data in the sandbox code interpreter to obtain the execution result.

10. The fault diagnosis method according to claim 7, characterized in that: Before initiating a tool call request to the tool in the tool list according to the execution instruction, the method further includes: Determining whether the tool call request requires approval according to a preset approval policy; If approval is determined to be required, pushing an approval request to the target object on the front-end page; After receiving the approval instruction of the target object, obtaining the identity certificate of the target object; The tool call request is initiated through the identity credential.

11. The fault diagnosis method according to claim 7, characterized in that: After generating the first request information according to the context information of the container scheduling unit obtained from the front-end page and the natural language instruction input by the target object, the method further includes: Determine a progress display area in the front-end page; The processing progress of the first request information is displayed to the target object in real time in the progress display area.

12. A fault diagnosis device, characterized in that: include: an acquisition module, configured to acquire context information of the container scheduling unit from a front-end page, and generate first request information according to the context information and a natural language instruction input by a target object; A query module, configured to query the database for associated information corresponding to the first request information to obtain a query result; an execution module, configured to execute an execution instruction determined according to the first request information and the query result, and obtain an execution result, wherein the execution result includes status information of the container scheduling unit and fault log information; The obtaining module is used to input the first request information, the query result and the execution result into a large language model to obtain the fault diagnosis result output by the large language model.

13. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the fault diagnosis method according to any one of claims 1 to 11 when executing the computer program.

14. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the fault diagnosis method according to any one of claims 1 to 11.

15. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the fault diagnosis method according to any one of claims 1 to 11 are implemented.

Images