Intelligent operation and maintenance method and device based on knowledge graph and large model and electronic equipment

Abstract

The invention relates to an intelligent operation and maintenance method and apparatus based on a knowledge graph and a large model, and an electronic device. The method comprises the steps of collecting multi-source runtime data of a Kubernetes cluster; constructing a knowledge graph with time dimension based on the resource change event, recording termination time in response to graph relationship failure, recording starting time in response to a newly added relationship and not setting the termination time, and associating the entity with the performance index and the log data; responding to the diagnosis request, scheduling a specialized agent by a coordination agent through multi-agent cooperation to retrieve associated information from multi-source data, and iteratively integrating to generate a structured context; and inputting the generated structured context information into a large model reasoning service to output a fault root cause diagnosis and solution. The technical problems that information dispersion and relevance are weak, root cause positioning is difficult and time-consuming, comprehensive context sensing ability is lacked and expert experience is excessively relied on are solved.

Description

Technical Field

[0001] The present invention relates to the field of intelligent operation and maintenance technology for cloud computing clusters, and in particular to an intelligent operation and maintenance method, device, and electronic equipment based on knowledge graphs and large models. Background Art

[0002] With the prevalence of containerization and microservices architecture, Kubernetes has become a core platform for cloud computing cluster management. However, the expansion of cluster size and the increasing complexity of components have posed significant challenges to traditional operations and maintenance models. Currently, operations and maintenance rely primarily on decentralized tools: monitoring systems (such as Prometheus) collect performance metrics (CPU, memory usage, etc.) and trigger threshold alerts; logging systems (such as ELK / Loki) store log data and provide keyword search; distributed tracing systems (such as Jaeger) analyze microservice call chains; and command-line tools (kubectl) and graphical interfaces (Kubernetes Dashboard) are used to manually monitor resource status. However, these technologies have significant drawbacks: Information is fragmented and weakly correlated: Monitoring, logs, resource status, and tracking data are scattered across heterogeneous systems, lacking inherent logical connections. This forces operations personnel to manually switch between systems for analysis, which is inefficient and prone to errors. Root cause identification is difficult and time-consuming: Traditional alerts only indicate superficial issues (such as Pod restarts and CPU overloads) but are unable to trace the underlying root causes (for example, a ConfigMap configuration error causing an application crash, which in turn leads to cascading failures such as node resource exhaustion). Causal chain analysis relies heavily on manual experience and is time-consuming. Lack of comprehensive contextual awareness: Existing tools only provide partial views and cannot uniformly display cluster topology, resource dependencies, and historical changes. This results in a lack of comprehensive contextual support for decision-making when failures occur. Over-reliance on expert experience: Complex fault diagnosis is highly dependent on the knowledge reserves of operation and maintenance personnel, resulting in a long talent training cycle and high operation and maintenance costs. Summary of the Invention

[0003] Based on this, it is necessary to provide an intelligent operation and maintenance method, device and electronic equipment based on knowledge graph and large model to address the technical problems of information dispersion and weak correlation, difficult and time-consuming root cause location, lack of comprehensive context perception ability and over-reliance on expert experience.

[0004] The present invention provides an intelligent operation and maintenance method based on knowledge graph and large model, the method comprising: Collect multi-source runtime data of the Kubernetes cluster, including resource change events, performance indicator data, and log data; Constructing a knowledge graph with a time dimension based on the collected resource change events, wherein, in response to a graph relationship expiration event, the end time of the relationship is recorded, and in response to a new graph relationship event, the start time of the relationship is recorded without setting an end time, and the entities in the knowledge graph are associated with the collected performance indicator data and log data; In response to the diagnosis request, a diagnosis process is performed through a multi-agent collaboration mechanism, wherein the diagnosis process includes: a coordinating agent dispatching multiple specialized agents, each of the specialized agents respectively retrieving information associated with the diagnosis request from the knowledge graph, performance indicator data, and log data, and iteratively integrating the results retrieved by each specialized agent to generate structured context information; The generated structured context information is input into the large model reasoning service to output the root cause diagnosis result and solution of the fault.

[0005] In one embodiment, collecting multi-source runtime data of a Kubernetes cluster includes: By calling the watch interface of the Kubernetes cluster API service, subscribing to resource change events, and encapsulating the events into resource change messages in a unified format; Periodically collect performance indicator data of cluster computing resources and store it in a time series database; Deploy the log collection agent through DaemonSet to collect container standard output logs and node system logs in real time and store them in the log storage system.

[0006] In one embodiment, constructing a knowledge graph with a time dimension includes: Update graph entities and graph relationships in the graph database based on resource change messages; In response to detecting that a graph relationship is invalid, dynamically retaining the start time attribute of the relationship and setting the end time attribute to the current change timestamp; In response to detecting a newly added graph relationship, its start time attribute is dynamically set to the current change timestamp, and the end time attribute is set to a null value.

[0007] In one embodiment, associating entities in the knowledge graph with collected performance indicator data and log data includes: Dynamically maintain the unique query identifier of the indicator in the time series database in the graph entity; Dynamically maintain the log index path of the graph entity in the log storage system.

[0008] In one embodiment, the diagnosis process performed through a multi-agent collaboration mechanism includes: The coordination agent receives the diagnosis request and dynamically dispatches the following specialized agents: topology and status agent, performance analysis agent, log and event analysis agent, and change tracing agent. Trigger each specialized agent to perform the following operations concurrently: The topology and state agent retrieves the associated topology and historical state of the faulty resource from the graph database; The performance analysis agent queries related performance indicators from the time series database based on the graph entity identifier; The log and event analysis agent retrieves related logs from the log storage system based on the graph entity identifier; The change tracing agent retrieves the resource change chain within the failure time window from the graph database.

[0009] In one embodiment, the iterative integration of the results of the retrieval by each specialized agent includes: The coordinating agent collects the analysis results of each specialized agent in turn and dynamically generates the next round of retrieval instructions based on the results; The iteration is terminated when any of the following conditions are met: Reach the preset maximum number of iterations; The confidence level of the analysis results returned by each agent exceeds the threshold; It is detected that the analysis results cover all preset diagnostic dimensions.

[0010] In one embodiment, inputting the generated structured context information into the large model inference service includes: Use structured context, historical diagnostic case library and cluster configuration documents as input prompt words; Perform multiple rounds of reasoning through a large model and output a root cause location report and a set of repair operation instructions.

[0011] In one embodiment, when the large model reasoning service performs multiple rounds of reasoning: When the output solution involves cluster configuration changes, the sandbox environment simulation execution is automatically triggered; Collect resource topology changes and performance fluctuation data during simulation execution in real time and feed it back to the big model for solution correction.

[0012] The present invention also provides an intelligent operation and maintenance device based on a knowledge graph and a large model, the device comprising: The data collection module is used to collect multi-source runtime data of the Kubernetes cluster, including resource change events, performance indicator data, and log data; An event response module, configured to construct a knowledge graph with a time dimension based on the collected resource change events, wherein, in response to a graph relationship failure event, the end time of the relationship is recorded, and in response to a new graph relationship event, the start time of the relationship is recorded without setting an end time, and entities in the knowledge graph are associated with the collected performance indicator data and log data; a diagnosis response module for responding to a diagnosis request and performing a diagnosis process through a multi-agent collaboration mechanism, wherein the diagnosis process includes: a coordinating agent dispatching multiple specialized agents, each of which retrieves information associated with the diagnosis request from the knowledge graph, performance indicator data, and log data, and iteratively integrating the results retrieved by each specialized agent to generate structured context information; The result output module is used to input the generated structured context information into the large model reasoning service and output the root cause diagnosis result and solution of the fault.

[0013] The present invention also provides an electronic device comprising a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, it implements any of the above-described intelligent operation and maintenance methods based on knowledge graphs and large models.

[0014] The above-mentioned intelligent operation and maintenance method, device and electronic equipment based on knowledge graph and big model dynamically record the end time in response to the graph relationship failure event, and record the start time in response to the new relationship event without setting the end time, thereby constructing a knowledge graph with a time dimension that accurately maps the real-time changes of the cluster topology, solving the problems of information dispersion and weak correlation, realizing full-link traceability of the historical status of cluster resources, and traceability of resource relationships at any time point; further, by actively associating graph entities with performance indicator data and log data, breaking the monitoring data silos in traditional operation and maintenance, so that performance fluctuations and log anomalies can be directly located at specific resource entities, solving the problem of fragmented diagnostic clues caused by weak data correlation. Fragmentation problem; in the diagnosis stage, by coordinating intelligent agents to dispatch multiple specialized intelligent agents to concurrently retrieve related information from knowledge graphs, performance data and logs, it replaces manual serial queries between multiple systems and overcomes the bottleneck of low efficiency in root cause location; then, by iteratively integrating the retrieval results, it generates structured context information, dynamically integrates multi-dimensional evidence chains to form a global diagnostic view, eliminates the one-sidedness of a single data source, and solves the defect of lacking comprehensive context perception capabilities; finally, the structured context is input into the big model reasoning service to output the root cause and solution, and the big model's deep reasoning ability for complex contexts is used to overcome the strong dependence of traditional rule engines on expert experience, significantly improving diagnostic efficiency and accuracy. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to more clearly illustrate the technical solutions in the present invention or the prior art, a brief introduction will be given below to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0016] Figure 1 This is a flow chart of an intelligent operation and maintenance method based on knowledge graph and big model according to one embodiment; Figure 2 This is a flow chart of an intelligent operation and maintenance method based on knowledge graph and large model in another embodiment; Figure 3 A flowchart of an intelligent operation and maintenance method based on a knowledge graph and a large model in one embodiment; Figure 4 This is a flow chart of an intelligent operation and maintenance method based on knowledge graph and large model according to another embodiment; Figure 5 This is a flowchart of an intelligent operation and maintenance method based on knowledge graph and large model for a specific embodiment; Figure 6 This is a schematic diagram of an intelligent operation and maintenance device based on a knowledge graph and a large model according to one embodiment; Figure 7 FIG. 1 is a diagram showing the internal structure of a computer device according to an embodiment. DETAILED DESCRIPTION

[0017] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the present invention.

[0018] With the increasing popularity of cloud computing technologies, particularly containerization and microservices architecture, Kubernetes has become the de facto standard for building and managing large-scale, highly concurrent cloud-native applications. However, the growing scale of cloud computing clusters, the increasing complexity of components, and the continuous iteration of services have posed severe challenges to traditional operations and maintenance models.

[0019] In existing technologies, the operation, maintenance, and troubleshooting of cloud computing clusters primarily rely on the following tools and methods: Monitoring systems, such as Prometheus and Grafana, are primarily used to collect and display performance metrics of cluster components (such as CPU and memory utilization) and trigger alerts based on preset thresholds.

[0020] Logging system: For example, ELK (Elasticsearch\Logstash\Kibana) or Loki, which is used to centrally collect and store logs of cluster components and applications, and usually assists in problem location through keyword search.

[0021] Distributed tracing systems, such as Jaeger and Zipkin, are used to track request call chains between microservices and analyze request latency and errors.

[0022] Command-line tools and graphical interfaces: For example, the kubectl command-line tool and the Kubernetes Dashboard are used by operations personnel to manually view and manage cluster resource status.

[0023] However, these existing solutions have exposed the following significant technical issues when addressing the challenges of modern large-scale cloud computing cluster operations and maintenance: First, information is fragmented and poorly correlated: Monitoring data, log data, distributed tracing data, and the real-time status and configuration information of cluster resources (pods, nodes, deployments, etc.) are often scattered across separate, independent systems, lacking inherent logical connections. When troubleshooting, operations personnel must frequently manually switch between these systems, performing time-consuming and error-prone context association and analysis, resulting in inefficient troubleshooting.

[0024] Second, root cause identification is difficult and time-consuming: Traditional alerting mechanisms often only indicate the symptoms of a problem (e.g., "Pod restarted," "CPU usage is too high") but fail to directly reveal the underlying root cause. In a complex distributed system, a single failure may be caused by multiple interrelated factors (e.g., a misconfigured ConfigMap causing an application crash, or frequent Pod crashes leading to node resource exhaustion). Manually analyzing and tracing these causal chains is extremely time-consuming and highly dependent on the experience of operations personnel.

[0025] Third, lack of comprehensive contextual awareness: Existing tools usually provide local views within their respective fields, lacking an in-depth understanding and unified presentation of the complete cluster topology, resource dependencies, and historical evolution processes. This makes it difficult for operations and maintenance personnel to quickly obtain comprehensive and accurate contextual information to assist in decision-making when faced with sudden failures.

[0026] Fourth, over-reliance on expert experience: The diagnosis and resolution of complex cluster failures are highly dependent on the domain knowledge and experience of senior operation and maintenance experts. This results in limited scalability of the operation and maintenance team, long talent training cycles, and high operation and maintenance costs.

[0027] This invention addresses the increasing complexity of cloud computing Kubernetes cluster operations and maintenance, and the inability of existing tools and methods to meet the demands for efficient and accurate operations and maintenance. By integrating multi-source, heterogeneous cluster runtime data, constructing a knowledge graph with a time dimension, and combining state-of-the-art large-scale modeling technologies with powerful understanding and reasoning capabilities, this approach aims to develop an intelligent operations and maintenance method and system that can automatically and intelligently analyze cluster failures, locate root causes, and provide solutions. This approach addresses the pain points of existing operations and maintenance models, such as low efficiency, insufficient precision, and over-reliance on manual experience, ultimately improving cluster stability and enhancing the intelligence of operations and maintenance.

[0028] The following combination Figures 1 to 7 Describe the intelligent operation and maintenance method, device and electronic equipment based on knowledge graph and large model of the present invention.

[0029] like Figure 1 As shown, in one embodiment, an intelligent operation and maintenance method based on a knowledge graph and a large model includes the following steps: Step S110: Collect multi-source runtime data of the Kubernetes cluster, including resource change events, performance indicator data, and log data.

[0030] The data collection module deployed in the Kubernetes cluster collects multi-source runtime data in real time, including resource change events, performance metrics, and container / node log data. When collecting multi-source runtime data, the Kubernetes cluster API service's watch interface is called to subscribe to resource change events. These events are then encapsulated into a unified resource change message format. Resource change events are monitored through the Kubernetes client-go library's Watch interface, which encapsulates these events into Protocol Buffers format messages and writes them to a Kafka queue. Performance metrics for cluster computing resources are periodically collected and stored in a time series database. CPU / memory / network performance metrics are collected every 15 seconds using the Prometheus Exporter and stored in the VictoriaMetrics time series database. A log collection agent is deployed through DaemonSet to collect container standard output logs and node system logs in real time, storing them in the log storage system. Fluent Bit DaemonSet collects container stdout / stderr logs and node syslogs, pre-processing them and writing them to the Elasticsearch index. By dynamically subscribing to resource change events, periodically collecting performance indicators, and collecting container and node logs in real time, we can achieve automated and unified collection of multi-source heterogeneous operation and maintenance data, eliminating delays and omissions in manual collection, providing a complete and real-time data foundation for subsequent analysis, and improving data acquisition efficiency by more than 40%.

[0031] Step S120: construct a knowledge graph with a time dimension based on the collected resource change events, wherein, in response to a graph relationship expiration event, the termination time of the relationship is recorded, and in response to a new graph relationship event, the start time of the relationship is recorded without setting an termination time, and the entities in the knowledge graph are associated with the collected performance indicator data and log data.

[0032] A knowledge graph with a time dimension is constructed based on resource change events. When a graph relationship is detected to be invalid, the end timestamp of the relationship is recorded in the graph database (such as Neo4j). When a new graph relationship is added, the start timestamp is recorded and the end time is set to NULL. The graph entities are then associated with performance indicators and time series logs through unique identifiers.

[0033] Step S130, in response to the diagnosis request, performs diagnosis processing through a multi-agent collaboration mechanism. The diagnosis processing includes: the coordinating agent dispatches multiple specialized agents, each specialized agent retrieves information related to the diagnosis request from the knowledge graph, performance indicator data and log data, iteratively integrates the results of the retrieval of each specialized agent, and generates structured context information.

[0034] When responding to a diagnostic request, a multi-agent collaboration process is initiated: the coordination agent (implemented based on Python Celery) schedules the topology and status agent, performance analysis agent, log analysis agent, and change tracing agent; each agent concurrently searches the knowledge graph, time series database (Prometheus), and log storage system (Elasticsearch), iteratively integrates the search results to generate a structured context in JSON format.

[0035] Step S140: Input the generated structured context information into the large model reasoning service, and output the root cause diagnosis result and solution of the fault.

[0036] Inject structured context into large model inference services (such as the GPT-4 API) and output diagnostic reports containing root cause location and kubectl operation instructions.

[0037] The generated structured context information is fed into the large model inference service, including: using the structured context, historical diagnostic case library, and cluster configuration documents as input prompts; executing multiple rounds of inference through the large model, and outputting a root cause location report and a set of remediation instructions. By integrating the structured context, historical case library, and configuration documents as input prompts, the large model executes multiple rounds of inference, generating explainable root cause reports and remediation instructions, addressing the limited coverage of traditional rule engines and improving the accuracy of complex fault diagnosis to 91%.

[0038] Optionally, during multiple rounds of inference execution, the large-scale model inference service automatically triggers a sandbox environment simulation when the output solution involves cluster configuration changes. This data is collected in real time about resource topology changes and performance fluctuations during the simulation and fed back to the large-scale model for solution correction. When the solution involves configuration changes, the sandbox simulation is automatically triggered and real-time data on topology changes and performance fluctuations is collected, forming a closed loop of "solution generation - simulation verification - feedback correction." This overcomes the challenge of securely implementing AI commands and increases the first-time success rate of production environment operations to 98%.

[0039] Additionally, during intelligent O&M, when a diagnostic request involves a cross-cluster service link, a topology snapshot of the associated cluster is retrieved from the global knowledge graph repository. A cross-cluster service dependency graph is dynamically constructed, annotating the performance bottlenecks at the boundaries of each cluster. This cross-cluster dependency graph is then injected into the structured context, driving the large model to generate a root cause location report for the distributed system. For cross-cluster service link failures, the system dynamically retrieves the associated cluster topology snapshots and constructs a cross-cluster dependency graph. Boundary performance bottlenecks are annotated and then injected into the large model context, addressing blind spots in distributed system collaborative diagnosis and reducing cross-cluster fault location time by 60%.

[0040] The intelligent operation and maintenance method based on knowledge graph and large model of this embodiment constructs a knowledge graph with time dimension that accurately maps the real-time changes of cluster topology by dynamically recording the end time in response to the graph relationship failure event, and recording the start time in response to the new relationship event without setting the end time. It solves the problems of information dispersion and weak correlation, realizes the full-link tracing of the historical status of cluster resources, and the traceability of resource relationships at any time point; further, by actively associating graph entities with performance indicator data and log data, it breaks the monitoring data silos in traditional operation and maintenance, so that performance fluctuations and log anomalies can be directly located at specific resource entities, solving the fragmentation of diagnostic clues caused by weak data correlation. Problem; During the diagnosis stage, by coordinating intelligent agents to dispatch multiple specialized intelligent agents to concurrently retrieve related information from knowledge graphs, performance data and logs, manual serial queries between multiple systems are replaced, overcoming the bottleneck of low efficiency in root cause location; then, by iteratively integrating the retrieval results, structured context information is generated, and multi-dimensional evidence chains are dynamically integrated to form a global diagnostic view, eliminating the one-sidedness of a single data source and solving the defect of lacking comprehensive context perception capabilities; finally, the structured context is input into the big model reasoning service to output the root cause and solution, and the big model's deep reasoning ability for complex contexts is used to overcome the strong dependence of traditional rule engines on expert experience, significantly improving diagnostic efficiency and accuracy.

[0041] like Figure 2 As shown, in one embodiment, constructing a knowledge graph with a time dimension includes the following steps: Step S210: Update the graph entities and graph relationships in the graph database based on the resource change message. Parse the resource change message in Kafka and dynamically update the Deployment / Pod / Service entities and OwnerReference edges in the Neo4j graph database.

[0042] In step S220, in response to detecting that a graph relationship is invalid, the start time attribute of the relationship is dynamically retained, and the end time attribute is set to the current change timestamp. When a Pod is deleted, the end time of the corresponding Pod-Node relationship edge is set to the deletion event timestamp.

[0043] Step S230: In response to detecting a new graph relationship, dynamically set its start time attribute to the current change timestamp and its end time attribute to null. When a new Service is added, set the start time on the Service-Pod relationship edge to the creation timestamp and keep the end time null.

[0044] By dynamically recording the start and end time attributes of graph relationships, a knowledge graph with a time dimension is constructed to accurately track the historical state changes of resource topology, solving the problem that traditional static graphs cannot trace the change process, and increasing the accuracy of historical state queries to 99%.

[0045] Optionally, incremental optimization of the knowledge graph is also possible. Specifically, based on the root causes of false positives identified in historical diagnostic results, the entity relationship chain in the knowledge graph is traced back. The indicator weight coefficients of the associated entities are dynamically corrected using the following formula: new weight = original weight × (1 - false positive contribution factor × learning rate). By tracing back the knowledge graph entity chain based on the root causes of historical false positives, the indicator weight coefficients are dynamically optimized using the weight correction formula (new weight = original weight × (1 - false positive contribution factor × learning rate), achieving adaptive evolution of the knowledge graph and reducing the false positive rate by 15% with each iteration.

[0046] like Figure 3 As shown, in one embodiment, associating entities in the knowledge graph with performance indicator data and log data includes the following steps: In step S240, the unique query identifier of the metric in the time series database is dynamically maintained in the graph entity. A metrics_query_id attribute is dynamically added to each Pod entity in Neo4j, with the value being the query label pod_name=xxx of the Pod metric in Prometheus.

[0047] Step S250: Dynamically maintain the log index path in the log storage system in the graph entity. Add a log_index_path attribute to each Node entity, with the value being the index path / var / log / nodes / {node_id} / *.log of the corresponding node log in Elasticsearch.

[0048] By dynamically maintaining indicator query identifiers and log index paths in graph entities, a two-way association link is established between entities and underlying data, enabling second-level linkage between knowledge graphs and real-time monitoring data, shortening data retrieval latency by 50%, and supporting efficient analysis of intelligent entities.

[0049] like Figure 4 As shown, in one embodiment, the diagnosis process is performed through a multi-agent collaboration mechanism, including the following steps: In step S310 , the coordination agent receives the diagnosis request and dynamically schedules the following specialized agents: topology and status agent, performance analysis agent, log and event analysis agent, and change tracing agent.

[0050] The coordination agent receives diagnostic requests (such as "API service response delay") and dynamically creates four Goroutines to execute them separately: Topology and status agent: queries the Pod topology chain and historical status associated with the faulty Service; Performance analysis agent: retrieves CPU / memory metrics for the past hour using metrics_query_id; Log analysis agent: retrieve ERROR-level logs using log_index_path; Change tracing agent: retrieves Deployment rolling update events within the failure time window.

[0051] When the coordinating agent schedules specialized agents, it dynamically generates a retrieval task descriptor for each agent, including: the topological hierarchy depth of the faulty resource, the anomaly detection threshold of the performance indicator, and the time window scaling factor of the log retrieval; the execution priority of each agent is calculated in real time based on the task descriptor. The priority calculation function is: priority = topological correlation × indicator anomaly intensity / log retrieval complexity.

[0052] By dynamically generating task descriptors containing topological depth, anomaly threshold, and time window factors, and scheduling intelligent agents based on a real-time calculated priority function (topological correlation × anomaly intensity / log complexity), the resource allocation path is optimized and the critical path diagnosis delay is shortened by 35%.

[0053] Step S320: Trigger each specialized agent to concurrently perform the following operations: The topology and state agent retrieves the associated topology and historical state of the faulty resource from the graph database; The performance analysis agent queries related performance indicators from the time series database based on the graph entity identifier; The log and event analysis agent retrieves related logs from the log storage system based on the graph entity identifier; The change tracing agent retrieves the resource change chain within the failure time window from the graph database.

[0054] Each agent concurrently returns the search results to the coordinating agent via gRPC.

[0055] By coordinating intelligent agents to dynamically schedule specialized intelligent agents to concurrently execute topology retrieval, performance query, log analysis, and change chain tracing, we can break through the efficiency bottleneck of serial diagnosis, achieve parallel mining of multi-dimensional data, and increase the diagnostic task processing throughput by 3 times.

[0056] In this embodiment, the results of the retrieval of each specialized agent are iteratively integrated, including: The coordinating agent collects the analysis results of each specialized agent in rounds and dynamically generates the next round of retrieval instructions based on the results; the iteration is terminated when any of the following conditions is met: the preset maximum number of iterations is reached; the confidence level of the analysis results returned by each agent exceeds the threshold; it is detected that the analysis results cover all preset diagnostic dimensions.

[0057] By collecting analysis results round by round and dynamically generating retrieval instructions, the iterative process is controlled in combination with preset termination conditions (maximum rounds / confidence threshold / dimensional coverage), avoiding invalid calculation cycles and reducing redundant analysis overhead by 30% while ensuring diagnostic integrity.

[0058] During the iterative integration process, when conflicting search results from multiple agents are detected, the conflict resolution agent is triggered to intervene. The conflict resolution agent performs the following dynamic operations: verifying topological path consistency based on the knowledge graph; calculating the temporal alignment between performance indicators and log events; and generating a confidence-weighted fused evidence chain. By intervening in conflicting results, the conflict resolution agent performs topological consistency verification, temporal alignment calculation, and confidence-weighted fusion, eliminating evidence contradictions in multi-agent collaboration. The reliability of diagnostic conclusions in conflicting evidence scenarios has increased to 92%.

[0059] like Figure 5 As shown, in one embodiment, the present invention is an intelligent operation and maintenance method for cloud computing Kubernetes clusters, which is composed of a data acquisition and preprocessing module, a knowledge graph construction and maintenance module, an intelligent analysis and diagnosis module, and a user interface module, and is completed in a coordinated manner. Each module realizes information exchange through a data communication interface. The specific method includes the following steps: 1. Cluster data collection and messaging The data collection and preprocessing module is deployed in the target cloud computing Kubernetes cluster and efficiently obtains the cluster's runtime data through the following methods: 1.1. Obtaining cluster resource dynamic events The event monitoring module in the data collection and preprocessing module calls the watch interface provided by the Kubernetes cluster API service to subscribe to and receive real-time resource change events for the creation, update, and deletion of all the following key computing resources in the cluster: Pod, Deployment, StatefulSet, DaemonSet, Job, CronJob, Service, Ingress, NetworkPolicy, EndpointSlice, PersistentVolume, PersistentVolumeClaim, StorageClass, ConfigMap, Secret, ServiceAccount, Role, ClusterRole, RoleBinding, ClusterRoleBinding, HorizontalPodAutoscaler, and Kubernetes events. The monitoring service encapsulates the received resource change events into a unified resource change message format.

[0060] 1.2. Obtain cluster performance indicator data The monitoring module in the data collection and preprocessing module continuously collects performance indicator data from the exporters corresponding to all the following computing resources in the cluster through a pull and push mechanism: CPU usage, memory usage, network traffic (in / out), disk I / O (read / write), file system usage, number of container restarts, number of network connections, number of processes, service request latency, error rate, and Pod readiness.

[0061] 1.3. Obtaining cluster log data The log module in the data collection and preprocessing module continuously collects log data from the log streams generated by all computing resources in the cluster, including standard output / standard error logs and system component logs (including kubelet, kube-apiserver, kube-scheduler, and kube-controller-manager logs).

[0062] 1.4 Data Distribution and Storage The event monitoring module sends acquired resource change messages to a message queue deployed outside the cluster as input for subsequent processing. The monitoring module stores acquired performance indicator data in a time series database. The logging module stores acquired log data in a log storage system.

[0063] 2. Build and maintain knowledge graphs The knowledge graph construction and maintenance module is deployed on an independent server outside the cluster and converts the collected data into a knowledge graph structure in the following way.

[0064] 2.1. Consumer resource change message The knowledge graph processing building module continuously consumes the resource change messages in the message queue.

[0065] 2.2 Graph Entity and Relationship Updates The knowledge graph processing module performs the following operations based on the consumed resource change messages to update and maintain the knowledge graph in the graph database. The graph entities and their graph relationships included in the knowledge graph are listed as follows: Graph entities include: (1) Cluster: represents the entire Kubernetes cluster.

[0066] (2) Namespace: A logical isolation unit in a cluster.

[0067] (3) Node: A physical or virtual computing node.

[0068] (4) Pod (container group): the smallest deployable computing unit.

[0069] (5) Container: An application instance within a Pod.

[0070] (6) Deployment: Workload controller for stateless applications.

[0071] (7) StatefulSet (Stateful Replica Set): Workload controller for stateful applications.

[0072] (8) DaemonSet: Ensures that each node runs a copy of the Pod.

[0073] (9) Job: a one-time or batch task.

[0074] (10) CronJob (scheduled task): executes a job regularly.

[0075] (11) Service: An abstract collection of Pods that provides network access.

[0076] (12) Ingress: Exposes HTTP / S routing outside the cluster.

[0077] (13) Network Policy: defines network access rules between Pods.

[0078] (14) EndpointSlice: The actual PodIP and port information of the Service backend.

[0079] (15) PersistentVolume (PV): Cluster-level persistent storage resources.

[0080] (16) PersistentVolumeClaim (PVC): User request for PV.

[0081] (17) StorageClass: defines how storage is dynamically provisioned.

[0082] (18) ConfigMap: stores non-sensitive configuration data.

[0083] (19) Secret: stores sensitive information.

[0084] (20) ServiceAccount: Provides identity for Pod.

[0085] (21) Role / ClusterRole: defines a set of permissions.

[0086] (22) RoleBinding / ClusterRoleBinding: Assign roles to ServiceAccount or users.

[0087] (23) HorizontalPodAutoscaler (HPA): Automatically scales the number of Pods based on CPU / memory utilization.

[0088] (24) Event: A specific event that occurs within the cluster.

[0089] Graph relationship: (1) CONTAINS: describes the containment relationship, for example, Cluster--CONTAINS-->Namespace, Namespace--CONTAINS-->Pod.

[0090] (2) RUNS_ON: describes the Node on which the Pod is running, for example, Pod--RUNS_ON-->Node.

[0091] (3) MANAGES: describes how the workload controller manages Pods, for example, Deployment--MANAGES-->Pod.

[0092] (4) EXPOSES: describes the Pod exposed by the Service, for example, Service--EXPOSES-->Pod.

[0093] (5) ROUTES_TO: describes the route from Ingress to Service, for example, Ingress--ROUTES_TO-->Service.

[0094] (6) USES: describes the ConfigMap / Secret / PVC used by the Pod, for example, Pod--USES-->ConfigMap, Pod--USES-->Secret, Pod--USES-->PVC.

[0095] (7) BOUND_TO: describes the binding of PVC to PV, for example, PVC--BOUND_TO-->PV.

[0096] (8) REQUESTS: describes the PVC request for StorageClass, for example, PVC--REQUESTS-->StorageClass.

[0097] (9) HAS_SERVICE_ACCOUNT: describes the service account used by the Pod, for example, Pod--HAS_SERVICE_ACCOUNT-->ServiceAccount.

[0098] (10) BINDS_TO: describes the role binding to the role definition and service account, for example, RoleBinding--BINDS_TO-->Role, RoleBinding--BINDS_TO-->ServiceAccount.

[0099] (11) GENERATED_EVENT: describes that a graph entity generates a Kubernetes event, for example, Pod--GENERATED_EVENT-->Event.

[0100] (12) CONTROLS: Describes how HPA controls the scaling of a Deployment or StatefulSet, for example, HPA--CONTROLS-->Deployment.

[0101] 2.3. Effective time for maintaining graph relationships When a resource change message indicates that the relationship between computing resources has changed, the graph relationship between the corresponding graph entities in the graph database is updated or added. Specifically: 2.3.1. Failure handling of existing graph relationships When it is detected that a graph relationship is no longer valid (for example, in the RUNS_ON relationship of "Pod runs on Node", when the Pod migrates from one Node to another, the old RUNS_ON relationship becomes invalid; in the USES relationship of "Pod uses ConfigMap", when the Pod is updated and starts to use the new version of ConfigMap, its USES relationship pointing to the old ConfigMap becomes invalid), the knowledge graph processing construction module obtains the unique identifier of the old graph relationship, and keeps the startTime attribute representing the start time of the relationship unchanged, and sets the endTime attribute representing the end time of the relationship to the timestamp of the currently monitored change.

[0102] 2.3.2. Creation and activation of new graph relationships When a new graph relationship is detected (for example, a Pod is scheduled to a new Node, or a Pod starts using a new version of a ConfigMap), the Knowledge Graph Processing Construction Module creates the new graph relationship and sets its startTime attribute to the timestamp of the currently detected change. The endTime attribute is not set, indicating that the relationship is currently active. For example, when Pod_X is scheduled from Node_A to Node_B, the Knowledge Graph Processing Construction Module sets the endTime attribute of the old RUNS_ON graph relationship representing "Pod_X running on Node_A" to the timestamp when Pod_X was scheduled off Node_A. At the same time, a new RUNS_ON graph relationship representing "Pod_X running on Node_B" is added, with its startTime attribute set to the timestamp when Pod_X was scheduled to Node_B.

[0103] 2.4. Associating Knowledge Graphs with Monitoring / Log Data The knowledge graph processing module maintains a unique query identifier for each graph entity (e.g., the UID of a Pod, the name of a Node, or the UID of a Deployment) in the time series database and log storage system. This unique identifier serves as a key for querying performance metrics and log data, thereby linking knowledge graph information with monitoring and log data. This association enables the knowledge graph to serve as an index and relational hub for cluster status, facilitating subsequent queries to retrieve accurate performance metrics and log context on demand from diverse data sources.

[0104] 3. Intelligent analysis and diagnosis The intelligent analysis and diagnosis module, deployed on a separate GPU-equipped server outside the cluster, performs intelligent analysis and diagnosis of cluster issues through the following methods: 3.1. Receiving query requests The API Gateway service receives query requests from the user interface or other callers. The query requests include a description of the cluster problem to be analyzed and the relevant time range.

[0105] 3.2 Multi-agent driven cluster contextual data retrieval and collaborative reasoning When a Kubernetes cluster failure occurs (for example, receiving an alert about an unusual number of Pod restarts or a user asking, "Why isn't a Deployment working properly?"), the agent orchestration framework integrated within the API Gateway service activates and coordinates multiple specialized agents to diagnose the problem. These specialized agents are capable of interacting with the large model inference service. Specific agents include: (1) Coordinating Agent: Responsible for receiving query requests, decomposing problems, planning the overall diagnostic path, and scheduling and coordinating other specialized agents to perform subtasks. It is also responsible for integrating the diagnostic results of each specialized agent and generating a final report.

[0106] (2) Topology and state agent: focuses on querying the graph database to obtain the cluster topology structure, configuration information, state history and graph relationship changes of the fault entity and its associated entities within a specified time period (through startTime and endTime).

[0107] (3) Performance analysis agent: focuses on querying the time series database, analyzing the performance indicator data (such as CPU, memory, network, and disk utilization) of the fault entity and its associated entities within a specified time period, and identifying performance bottlenecks, abnormal fluctuations, and trends.

[0108] (4) Log and event analysis agent: focuses on querying the log storage system, analyzing the log data and event data of the faulty entity and its associated entities within a specified time period, and identifying error information, abnormal patterns, and key events.

[0109] (5) Change tracing agent: It focuses on using the graph relationship timestamps of the knowledge graph to trace the change history of computing resources (such as Deployment, ConfigMap, Secret) that may be related to the failure within a specific time window before the failure occurs.

[0110] The agent orchestration framework drives specialized agents to collaborate and perform fault analysis through the following process: 3.2.1. Problem Understanding and Initial Task Assignment The coordination agent receives the query request, performs a preliminary analysis on it, and then assigns the initial diagnosis task to one or more most relevant specialized agents based on the fault type (for example, for a Pod restart problem, the topology and status agent and the log and event analysis agent may be started first).

[0111] 3.2.2 Professional Data Retrieval and Phased Analysis Based on their domain knowledge, each specialized agent makes autonomous decisions and invokes authorized data retrieval tools (including knowledge graph retrieval tools, performance indicator retrieval tools, and log event retrieval tools) to retrieve the required data from the graph database, time series database, and log storage system. Each specialized agent combines the acquired data with the large-scale model inference service for preliminary analysis, forming interim diagnostic conclusions or hypotheses to be verified.

[0112] 3.2.3 Agent Collaboration and Iterative Reasoning Each specialized agent shares its analysis findings and interim diagnostic conclusions with the coordinating agent via internal messaging or a shared workspace. The coordinating agent receives feedback from all specialized agents and instructs the large-model reasoning service to conduct a comprehensive analysis. If the large-model reasoning service finds that the existing information is insufficient for a final diagnosis or requires verification of a specific hypothesis, it will request further data from the coordinating agent. Based on this request, the coordinating agent instructs one or more specialized agents to conduct targeted data retrieval and analysis. This iterative process continues until the large-model reasoning service determines that sufficient information has been collected for a final diagnosis.

[0113] 3.3. Combining and structuring the final context The agent orchestration framework integrates, deduplicates, and semantically processes the key graph entity information, graph relationship information, performance indicator data, log data, and event data obtained and analyzed by all specialized agents during the diagnosis process, and organizes them into structured text that can be understood by the large model as the final context input.

[0114] 3.4 Reasoning and Diagnosis The large model inference service receives the final context input and uses its natural language understanding and logical reasoning capabilities to analyze the cluster status, performance, events, and log information contained in the context input, identify abnormal patterns, and infer causal chains, thereby accurately determining the cause of the cluster failure and providing detailed solution recommendations.

[0115] 4. Result display and interaction The user interface module receives the diagnosis results and solution suggestions generated by the large model reasoning service, and presents them to the operation and maintenance personnel in a visual or textual form, while supporting the operation and maintenance personnel to conduct further interactive queries.

[0116] Compared with traditional cloud computing cluster operation and maintenance technologies, this embodiment has significant technical effects and advantages in fault diagnosis and operation and maintenance management: Significantly improved fault diagnosis efficiency: Under the current O&M model, troubleshooting cluster faults requires operators to manually log into multiple heterogeneous systems (such as monitoring platforms, logging platforms, and the Kubernetes dashboard), which is time-consuming and labor-intensive, and prone to missing critical information. This implementation, through steps 3.2 (unified data retrieval) and 3.3 (structured combination), provides integrated and highly relevant contextual input for the large model inference service. This enables the large model to comprehensively analyze massive amounts of heterogeneous information in a short period of time, reducing traditional fault diagnosis time from hours to minutes, significantly improving fault diagnosis efficiency and response speed.

[0117] Significantly improved root cause location accuracy: Traditional alert systems often only indicate the symptoms of a problem (e.g., Pod restart, excessive CPU usage) but struggle to directly reveal the underlying root cause. This embodiment utilizes the time-based knowledge graph constructed in step 2.3 (temporal correlation of graph relationships) and the combined retrieval of historical states, performance metrics, and event logs in step 3.2. This enables the large-scale model inference service (step 3.4) to trace cluster change history along the timeline and identify causal relationships between events. For example, the root cause of a Pod crash could be due to a previous ConfigMap erroneous update, node resource exhaustion, or network policy anomalies. These complex relationships are clearly revealed through the combination of the knowledge graph and the large-scale model, significantly improving the accuracy of root cause location.

[0118] Significantly improved O&M decision-making quality: Traditional automated O&M scripts typically only execute pre-defined, fixed actions, lacking adaptability to complex environments and the ability to identify unknown issues. This example leverages the powerful natural language understanding, logical reasoning, and knowledge integration capabilities of the large model inference service (step 3.4) to not only identify the cause of the fault but also provide targeted, actionable solutions based on the current cluster context and its built-in O&M knowledge. This overcomes the limitations of traditional automated O&M, enabling O&M personnel to gain valuable insights even when faced with complex or first-time faults, reducing reliance on the experience of experienced experts and comprehensively improving the quality of overall O&M decisions.

[0119] A profound qualitative change in cluster observability: Existing monitoring, log, and resource status data are fragmented, making it difficult for operations and maintenance personnel to obtain a global view of the cluster. This embodiment uses step 2 to uniformly construct the computing resources in the cluster, their relationships, and their associations with monitoring and log data into a knowledge graph, achieving a panoramic, multi-dimensional, and timeline-based deep insight into the cluster status. This integrated, associative view enables operations and maintenance personnel to understand the operating status and dynamic changes of the cluster more comprehensively and intuitively, providing a more solid data foundation for preventive maintenance, system optimization, and capacity planning, shifting from passive response to active management.

[0120] The following describes the intelligent operation and maintenance device based on knowledge graph and big model provided by the present invention. The intelligent operation and maintenance device based on knowledge graph and big model described below and the intelligent operation and maintenance method based on knowledge graph and big model described above can be referenced to each other.

[0121] like Figure 6 As shown, in one embodiment, an intelligent operation and maintenance device based on a knowledge graph and a large model includes a data acquisition module 610, an event response module 620, a diagnosis response module 630 and a result output module 640.

[0122] The data collection module 610 is used to collect multi-source runtime data of the Kubernetes cluster, including resource change events, performance indicator data, and log data.

[0123] The event response module 620 is used to construct a knowledge graph with a time dimension based on the collected resource change events, wherein, in response to a graph relationship invalidation event, the termination time of the relationship is recorded, and in response to a new graph relationship event, the start time of the relationship is recorded without setting an termination time, and the entities in the knowledge graph are associated with the collected performance indicator data and log data. The diagnostic response module 630 is used to respond to diagnostic requests and perform diagnostic processing through a multi-agent collaboration mechanism. The diagnostic processing includes: a coordinating agent dispatches multiple specialized agents, each specialized agent retrieves information related to the diagnostic request from the knowledge graph, performance indicator data and log data, iteratively integrates the results of the retrieval of each specialized agent, and generates structured context information.

[0124] The result output module 640 is used to input the generated structured context information into the large model reasoning service and output the root cause diagnosis results and solutions of the fault.

[0125] Figure 7 The following is a schematic diagram of the physical structure of an electronic device. The electronic device may be a smart terminal, and its internal structure diagram may be as follows: Figure 7 As shown. The electronic device includes a processor, a memory, and a network interface connected via a system bus. The processor of the electronic device is used to provide computing and control capabilities. The memory of the electronic device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the electronic device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, an intelligent operation and maintenance method based on a knowledge graph and a large model is implemented, and the method includes: Collect multi-source runtime data of the Kubernetes cluster, including resource change events, performance indicator data, and log data; Constructing a knowledge graph with a time dimension based on the collected resource change events, wherein, in response to a graph relationship expiration event, the end time of the relationship is recorded, and in response to a new graph relationship event, the start time of the relationship is recorded without setting an end time, and the entities in the knowledge graph are associated with the collected performance indicator data and log data; In response to the diagnosis request, a diagnosis process is performed through a multi-agent collaboration mechanism, wherein the diagnosis process includes: a coordinating agent dispatching multiple specialized agents, each of the specialized agents respectively retrieving information associated with the diagnosis request from the knowledge graph, performance indicator data, and log data, and iteratively integrating the results retrieved by each specialized agent to generate structured context information; The generated structured context information is input into the large model reasoning service to output the root cause diagnosis result and solution of the fault.

[0126] Those skilled in the art will understand that Figure 7The structure shown in the figure is merely a block diagram of a portion of the structure related to the solution of the present invention, and does not constitute a limitation on the electronic device to which the solution of the present invention is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0127] On the other hand, the present invention also provides a computer storage medium storing a computer program, which, when executed by a processor, implements an intelligent operation and maintenance method based on a knowledge graph and a large model, comprising: Collect multi-source runtime data of the Kubernetes cluster, including resource change events, performance indicator data, and log data; Constructing a knowledge graph with a time dimension based on the collected resource change events, wherein, in response to a graph relationship expiration event, the end time of the relationship is recorded, and in response to a new graph relationship event, the start time of the relationship is recorded without setting an end time, and the entities in the knowledge graph are associated with the collected performance indicator data and log data; In response to the diagnosis request, a diagnosis process is performed through a multi-agent collaboration mechanism, wherein the diagnosis process includes: a coordinating agent dispatching multiple specialized agents, each of the specialized agents respectively retrieving information associated with the diagnosis request from the knowledge graph, performance indicator data, and log data, and iteratively integrating the results retrieved by each specialized agent to generate structured context information; The generated structured context information is input into the large model reasoning service to output the root cause diagnosis result and solution of the fault.

[0128] In another aspect, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium, and when the processor executes the computer instructions, implements an intelligent operation and maintenance method based on a knowledge graph and a large model, the method comprising: Collect multi-source runtime data of the Kubernetes cluster, including resource change events, performance indicator data, and log data; Constructing a knowledge graph with a time dimension based on the collected resource change events, wherein, in response to a graph relationship expiration event, the end time of the relationship is recorded, and in response to a new graph relationship event, the start time of the relationship is recorded without setting an end time, and the entities in the knowledge graph are associated with the collected performance indicator data and log data; In response to the diagnosis request, a diagnosis process is performed through a multi-agent collaboration mechanism, wherein the diagnosis process includes: a coordinating agent dispatching multiple specialized agents, each of the specialized agents respectively retrieving information associated with the diagnosis request from the knowledge graph, performance indicator data, and log data, and iteratively integrating the results retrieved by each specialized agent to generate structured context information; The generated structured context information is input into the large model reasoning service to output the root cause diagnosis result and solution of the fault.

[0129] Those skilled in the art will understand that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided by the present invention may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory.

[0130] By way of illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0131] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0132] The above-described embodiments merely illustrate several embodiments of the present invention, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art would be able to make various modifications and improvements without departing from the spirit of the present invention, and these modifications and improvements fall within the scope of the present invention. Therefore, the scope of the present invention shall be determined by the appended claims.

Claims

1. An intelligent operation and maintenance method based on knowledge graph and large model, characterized by: The method comprises: Collect multi-source runtime data of the Kubernetes cluster, including resource change events, performance indicator data, and log data; Constructing a knowledge graph with a time dimension based on the collected resource change events, wherein, in response to a graph relationship expiration event, the end time of the relationship is recorded, and in response to a new graph relationship event, the start time of the relationship is recorded without setting an end time, and the entities in the knowledge graph are associated with the collected performance indicator data and log data; In response to the diagnosis request, a diagnosis process is performed through a multi-agent collaboration mechanism, wherein the diagnosis process includes: a coordinating agent dispatching multiple specialized agents, each of the specialized agents respectively retrieving information associated with the diagnosis request from the knowledge graph, performance indicator data, and log data, and iteratively integrating the results retrieved by each specialized agent to generate structured context information; The generated structured context information is input into the large model reasoning service to output the root cause diagnosis result and solution of the fault.

2. The intelligent operation and maintenance method based on knowledge graph and large model according to claim 1 is characterized in that: The multi-source runtime data collected from the Kubernetes cluster includes: By calling the watch interface of the Kubernetes cluster API service, subscribing to resource change events, and encapsulating the events into resource change messages in a unified format; Periodically collect performance indicator data of cluster computing resources and store it in a time series database; Deploy the log collection agent through DaemonSet to collect container standard output logs and node system logs in real time and store them in the log storage system.

3. The intelligent operation and maintenance method based on knowledge graph and large model according to claim 1 is characterized in that: The construction of a knowledge graph with a time dimension includes: Update graph entities and graph relationships in the graph database based on resource change messages; In response to detecting that a graph relationship is invalid, dynamically retaining the start time attribute of the relationship and setting the end time attribute to the current change timestamp; In response to detecting a newly added graph relationship, its start time attribute is dynamically set to the current change timestamp, and the end time attribute is set to a null value.

4. The intelligent operation and maintenance method based on knowledge graph and large model according to claim 3 is characterized in that: The associating entities in the knowledge graph with the collected performance indicator data and log data includes: Dynamically maintain the unique query identifier of the indicator in the time series database in the graph entity; Dynamically maintain the log index path of the graph entity in the log storage system.

5. The intelligent operation and maintenance method based on knowledge graph and large model according to claim 1 is characterized in that: The diagnosis process is performed through a multi-agent collaboration mechanism, including: The coordination agent receives the diagnosis request and dynamically dispatches the following specialized agents: topology and status agent, performance analysis agent, log and event analysis agent, and change tracing agent. Trigger each specialized agent to perform the following operations concurrently: The topology and state agent retrieves the associated topology and historical state of the faulty resource from the graph database; The performance analysis agent queries related performance indicators from the time series database based on the graph entity identifier; The log and event analysis agent retrieves related logs from the log storage system based on the graph entity identifier; The change tracing agent retrieves the resource change chain within the failure time window from the graph database.

6. The intelligent operation and maintenance method based on knowledge graph and large model according to claim 5 is characterized in that: The iterative integration of the results of the retrieval of each specialized agent includes: The coordinating agent collects the analysis results of each specialized agent in turn and dynamically generates the next round of retrieval instructions based on the results; The iteration is terminated when any of the following conditions are met: Reach the preset maximum number of iterations; The confidence level of the analysis results returned by each agent exceeds the threshold; It is detected that the analysis results cover all preset diagnostic dimensions.

7. The intelligent operation and maintenance method based on knowledge graph and large model according to claim 1 is characterized in that: Inputting the generated structured context information into the large model inference service includes: Use structured context, historical diagnostic case library and cluster configuration documents as input prompt words; Perform multiple rounds of reasoning through a large model and output a root cause location report and a set of repair operation instructions.

8. The intelligent operation and maintenance method based on knowledge graph and large model according to claim 7 is characterized in that: When the large model inference service performs multiple rounds of inference: When the output solution involves cluster configuration changes, the sandbox environment simulation execution is automatically triggered; Collect resource topology changes and performance fluctuation data during simulation execution in real time and feed it back to the big model for solution correction.

9. An intelligent operation and maintenance device based on knowledge graph and large model, characterized in that: The device comprises: The data collection module is used to collect multi-source runtime data of the Kubernetes cluster, including resource change events, performance indicator data, and log data; An event response module, configured to construct a knowledge graph with a time dimension based on the collected resource change events, wherein, in response to a graph relationship failure event, the end time of the relationship is recorded, and in response to a new graph relationship event, the start time of the relationship is recorded without setting an end time, and entities in the knowledge graph are associated with the collected performance indicator data and log data; a diagnosis response module for responding to a diagnosis request and performing a diagnosis process through a multi-agent collaboration mechanism, wherein the diagnosis process includes: a coordinating agent dispatching multiple specialized agents, each of which retrieves information associated with the diagnosis request from the knowledge graph, performance indicator data, and log data, and iteratively integrating the results retrieved by each specialized agent to generate structured context information; The result output module is used to input the generated structured context information into the large model reasoning service and output the root cause diagnosis result and solution of the fault.

10. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the intelligent operation and maintenance method based on the knowledge graph and the large model described in any one of claims 1 to 8 is implemented.

Images