Cluster visualization monitoring and debugging system and method based on cloud edge collaboration and medium

Abstract

The embodiment of the invention discloses a cluster visual monitoring and debugging system and method based on cloud edge collaboration and a medium. Comprising a data acquisition control module deployed at an edge side and used for acquiring multi-source heterogeneous monitoring data such as performance, links and logs of a cluster; a data storage module, wherein a built-in unified architecture server carries out unified modeling and storage on the monitoring data according to cluster topology; and the network data transmission module is responsible for cloud edge two-way transmission of data and forwarding of a control instruction. The cloud side comprises a container cloud platform and is used for data aggregation and instruction issuing; a cloud cluster virtual debugging environment maintained by the system serves as a digital twinborn body of a cluster and is used for high-simulation testing and change drilling; and the visual debugging module is deployed at a cloud end and / or an edge side, constructs a three-dimensional visual scene based on the monitoring data, supports state display and history playback, and directly regulates and controls cluster resources through interactive operation. According to the invention, unified integration of monitoring data, visual intelligent operation and maintenance, and simulation testing of safety are realized.

Description

Technical Field

[0001] Applications generally involve the fields of computer operation and maintenance and management technology, and in particular, a cloud-edge collaborative cluster visualization monitoring and debugging system, method and medium. Background Technology

[0002] With the widespread adoption of cloud computing and microservice architectures, containerized clusters, represented by Kubernetes, have become the core infrastructure for modern distributed applications. Ensuring the stable and efficient operation of such clusters requires comprehensive monitoring of system status and efficient operation and maintenance. Currently, industry monitoring of clusters mainly revolves around three dimensions: performance, logs, and distributed tracing, resulting in corresponding mainstream technical solutions.

[0003] For performance monitoring, a technology stack centered around Prometheus is typically used. Prometheus is responsible for periodically collecting various performance metrics (such as CPU, memory usage, network traffic, etc.) of cluster nodes, container groups, and applications, and then combining them with visualization tools such as Grafana to build custom monitoring dashboards for display.

[0004] For log management, the ELK (Elasticsearch, Logstash, Kibana) or EFK (Elasticsearch, Fluentd, Kibana) technology stack is commonly used. Logstash or Fluentd is responsible for collecting and initially processing log data, Elasticsearch provides efficient storage and retrieval capabilities, and Kibana is used for log visualization, analysis, and querying.

[0005] In distributed tracing, solutions such as OpenTelemetry and Jaeger are commonly used. OpenTelemetry provides standard APIs, software development kits (SDKs), and collectors for generating, collecting, and exporting telemetry data (tracing, metrics, and logs), while Jaeger serves as the backend, specifically designed for storing, retrieving, and visualizing complex distributed call chains.

[0006] While the three solutions mentioned above are relatively mature in their respective fields and collectively provide cluster observation capabilities, they also expose significant limitations and shortcomings in existing technologies. First, it is difficult to unify multi-source heterogeneous data. Performance, log, and link data originate from different acquisition components with varying formats and protocols, resulting in fragmented and disjointed data. Operations personnel often need to switch between multiple independent monitoring platforms to piece together information in order to complete fault diagnosis or performance analysis, greatly increasing the complexity of operations and the time cost of troubleshooting. Simultaneously, massive amounts of monitoring data (especially logs and historical metrics) are typically stored in local edge clusters, placing a heavy storage burden and performance pressure on edge nodes. Data management, cleaning, and long-term archiving also pose additional operational challenges. Second, existing solutions focus on "monitoring" rather than "debugging," lacking the ability for proactive intervention and in-depth verification. When problems are discovered, operations personnel still need to remotely log into the server using tools such as SSH to execute commands. This process is disconnected from the monitoring view, leading to inefficiency and a high risk of errors. In addition, traditional testing environments differ significantly from production environments in terms of data, traffic, and stress, making it difficult to realistically simulate sudden traffic spikes, long-term operational stress, and complex call scenarios in a production environment. This means that many potential problems cannot be fully exposed during the testing phase.

[0007] Digital twin technology was initially defined in the industrial field as building highly realistic virtual models with realistic geometric and physical properties, and integrating high-precision sensor data for mapping and simulation, for predictive maintenance and lifespan analysis. However, how to effectively apply this concept to virtual, dynamically changing cloud-native cluster environments, and build an intelligent operation and maintenance system that can not only provide unified monitoring but also support interactive debugging and high-fidelity testing, has become a key issue in improving the efficiency and reliability of cluster management in cloud-edge collaborative environments. Summary of the Invention

[0008] This disclosure addresses some of the shortcomings mentioned in the background art by providing a cloud-edge collaborative cluster visualization monitoring and debugging system, method, and medium.

[0009] In a first aspect, embodiments of this disclosure provide a cluster visualization monitoring and debugging system based on cloud-edge collaboration, including an edge subsystem deployed on the edge side and a cloud subsystem deployed on the cloud side, wherein, The edge subsystem includes: The data acquisition and control module is deployed within the edge production cluster and is used to collect multi-source heterogeneous monitoring data from the edge production cluster. The data storage module, connected to the data acquisition and control module, is used to receive and store the monitoring data. It has a unified architecture server deployed inside, which is used to convert and store the multi-source heterogeneous monitoring data in a unified format, and to provide a data access interface to the network data transmission module. The network data transmission module is connected to the data storage module and is used to transmit the monitoring data and control commands between the edge subsystem and the cloud subsystem. The cloud subsystem includes: The container cloud platform is used to receive and store monitoring data from the edge subsystem and provide an interface for issuing control commands. The cloud-based cluster virtual debugging environment is maintained by the container cloud platform. Its software configuration is consistent with that of the edge production cluster, forming a digital twin of the edge production cluster for simulation testing and change drills. The cloud-based visualization debugging module and / or the local node debugging module deployed on the edge side are used to construct and display a three-dimensional visualization scene of the edge production cluster based on the monitoring data, and receive control commands in the three-dimensional visualization scene, and convert them into control commands for the edge production cluster or the cloud cluster virtual debugging environment.

[0010] In one embodiment of the first aspect, the unified architecture server in the data storage module is an OPC UA server; the OPC UA server is configured to: construct a corresponding node network in the address space based on the physical and logical topology of the edge production cluster; map each monitored node, container and monitoring indicator to an object node or variable node in the node network, and set its attributes and interrelationships, and incorporate the multi-source heterogeneous monitoring data into a unified information model for management and access.

[0011] In one embodiment of the first aspect, the network data transmission module has a built-in client corresponding to the unified architecture server, which is used to obtain data from the unified architecture server and upload it to the cloud using a polling or subscription mechanism according to the data characteristics, and to receive control instructions from the cloud and write them to the unified architecture server.

[0012] In one embodiment of the first aspect, the data acquisition control module further includes: The performance data acquisition unit is used to periodically collect resource utilization indicators and application layer business indicators of nodes and containers. The link data acquisition unit is used to collect and associate the path and time information of distributed service calls to generate call chain data; The log data acquisition unit is used to collect and forward log event streams from nodes, containers, and system components; The command interpretation and execution unit is used to listen for, parse, and securely execute control commands from the unified architecture server.

[0013] In one embodiment of the first aspect, the visualization control module is specifically used for: Nodes are abstracted into a first type of 3D model, containers are abstracted into a second type of 3D model, and a 3D visualization scene model is constructed based on the relationship between nodes and containers and the service call relationship. Establish a mapping relationship between the three-dimensional visualization scene model and the backend data source, and map the monitoring data or health status information into changes in the visual attributes of the geometric model; Based on the selected historical time period or call chain identifier, the complete monitoring data is retrieved from the storage and the 3D visualization scene model is driven to perform a broadcast.

[0014] In one embodiment of the first aspect, the visualization control module supports visual interactive control, specifically used for: Respond to dragging and clicking operations performed by the user on the geometric model in the 3D visualization scene; Transform operation events into standard container orchestration instructions; The instruction is sent to the edge production cluster for execution via the network data transmission module. The 3D visualization scene is updated based on the cluster status feedback after execution.

[0015] In one embodiment of the first aspect, the system further includes a quality assessment module disposed in the container cloud platform, for: Configure personalized sets of monitoring metrics and weights for different types of nodes or containers; The collected monitoring indicator sequence is normalized, and the health sample value is calculated to obtain the health sample value sequence. Based on statistical process control methods, the health sample value sequence is analyzed to determine the health status of nodes or containers; The health status information is sent to the cloud-based visualization debugging module and / or the local node debugging module, and then visualized in the 3D visualization scene.

[0016] In a second aspect, embodiments of this disclosure provide a cluster visualization monitoring and debugging method based on cloud-edge collaboration, applied to the cluster visualization monitoring and debugging system based on cloud-edge collaboration as described in the first aspect, comprising the following steps: S1: In the edge production cluster, monitoring data of nodes and containers are collected through the data acquisition and control module; S2: In the data storage module, the monitoring data is constructed into a unified information model according to the cluster topology using a unified architecture server; S3: Through the network data transmission module, the monitoring data is uploaded to the container cloud platform using a polling or subscription mechanism based on the data characteristics, and the control instructions issued by the cloud subsystem are forwarded to the unified architecture server; S4: Receive and store the monitoring data in the container cloud platform, and perform simulation tests or change rehearsals in a cloud cluster virtual debugging environment that is consistent with the environment configuration of the edge production cluster. S5: Through the visualization control module, a three-dimensional visualization scene is generated based on the monitoring data, and state mapping and historical data playback are performed. Interactive operations are received to regulate the edge production cluster. S6: Based on statistical process control methods, personalized weight configuration, normalization processing and health sample value calculation are performed on the monitoring indicators of nodes and containers. Anomaly detection rules are applied to evaluate the health status of nodes or containers and perform visualization representation.

[0017] In one embodiment of the second aspect, step S5 further includes: responding to a user's drag operation on a 3D scene model in a 3D visualization scene, converting the operation event into a control command and sending it to the edge production cluster for execution, and synchronously updating the 3D visualization scene according to the execution result. In a third aspect, embodiments of this disclosure provide a computer-readable storage medium having computer instructions stored thereon, which, when executed, perform the cloud-edge collaborative cluster visualization monitoring and debugging method as described in the second aspect.

[0018] This disclosure proposes a cloud-edge collaborative cluster visualization monitoring and debugging system, method, and medium, which has the following beneficial effects: (1) This invention achieves unified integration and three-dimensional visualization interaction of monitoring data, significantly improving operation and maintenance efficiency. Through a cloud-edge collaborative architecture, this invention unifies and standardizes previously scattered multi-source heterogeneous monitoring data such as performance, logs, and links at the edge, and transmits it to the cloud for centralized management and long-term storage. Based on this, a three-dimensional visualization twin scene corresponding to the cluster's logical topology is constructed, merging fragmented data dimensions into a unified visual interface. This allows operation and maintenance personnel to obtain a complete system status view without switching between multiple tools. Simultaneously, interactive operations such as resource scheduling can be directly performed through this visualization interface, forming a "what you see is what you get" control loop, fundamentally solving the data silo problem and greatly simplifying the process of troubleshooting and system analysis.

[0019] (2) A high-fidelity digital twin simulation testing environment was constructed, enhancing the system's debugging capabilities and change security. This invention constructs a virtual cluster in the cloud, with a configuration completely identical to the production environment, as a digital twin. This environment can be injected with traffic data from the real production environment for high-fidelity testing and change rehearsals. Developers and testers can verify the robustness of new code versions in this environment that closely approximates real-world scenarios; operations and maintenance personnel can safely practice various architectural changes and intuitively observe the impact of each operation on system stability, thereby assessing and mitigating risks in advance. This effectively overcomes the drawbacks of traditional testing environments that suffer from distortion, integrating "monitoring-debugging-verification" into one, and improving software delivery quality and change reliability.

[0020] (3) An active quality assessment and early warning mechanism based on intelligent algorithms was introduced, realizing the intelligent transformation of the operation and maintenance mode. This invention innovatively applies the Statistical Process Control (SPC) method to cluster health assessment, which can configure personalized monitoring indicators and weights for different types of nodes and container groups, and perform quantitative analysis and intelligent anomaly detection on their performance trends. This mechanism can automatically identify patterns that are difficult to detect manually, such as early performance degradation and periodic anomalies, from massive amounts of data, and provide proactive and intuitive alerts through a three-dimensional visualization interface. This transforms the operation and maintenance work from passive "fault response" to proactive "risk prevention," which is conducive to intervention before problems affect business and improves the overall reliability of the system. Attached Figure Description

[0021] Figure 1 This is a diagram of the cloud-edge collaborative cluster visualization monitoring and debugging system architecture according to the present disclosure; Figure 2 The flowchart below illustrates the cluster visualization monitoring and debugging method based on cloud-edge collaboration according to this disclosure. Figure 3 This is a diagram of the edge production cluster system architecture consisting of five nodes in this embodiment. Figure 4 This is a schematic diagram illustrating the effect of centralized processing of multi-source data in Embodiment 1. Figure 5 This is a schematic diagram of the cyberspace visualization model in this embodiment. Detailed Implementation

[0022] The present application / disclosure will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application / disclosure and are not intended to limit the scope of the present application / disclosure. Furthermore, it should be noted that, for ease of description, only the parts relevant to the present application / disclosure are shown in the accompanying drawings, not the entire structure.

[0023] Example 1 Figure 1 Based on the cloud-edge collaborative cluster visualization monitoring and debugging system architecture diagram disclosed herein, the system architecture includes an edge subsystem 10 deployed on the edge side and a cloud subsystem 20 deployed on the cloud side. The edge subsystem 10 and the cloud subsystem 20 work collaboratively through network communication to achieve a complete closed loop from data acquisition, processing, and transmission to cloud analysis, visualization, and debugging. The following will refer to... Figure 1 This paper provides a detailed description of the cloud-edge collaborative cluster visualization monitoring and debugging system disclosed herein.

[0024] The edge subsystem 10 is deployed in an edge data center or field close to the data source, and includes an edge production cluster 110, a data acquisition and control module 120, a data storage module 130, and a network data transmission module 140. Edge production cluster 110, built on a container orchestration platform, includes multiple physical or virtual server nodes used to run business applications and supporting services.

[0025] In one embodiment, the edge production cluster 110 is deployed, managed, and elastically scaled using a mainstream container orchestration system (such as Kubernetes), and includes multiple server nodes. Based on the type of service carried by the nodes, they can be divided into business nodes and component nodes.

[0026] In this embodiment, the business nodes primarily carry the actual business logic and application services developed by R&D personnel. Their running entities are Kubernetes Pods, which are collections of one or more business containers. The component nodes, on the other hand, run the infrastructure services that support the management and operation of the edge production cluster 110. Typical examples include, but are not limited to, cluster management components, relational databases (such as MySQL), caching databases (such as Redis), message queues (such as Kafka), and search engines (such as ElasticSearch). These component nodes provide the business nodes with the necessary core capabilities such as data persistence, message passing, and search.

[0027] As an example, such as Figure 3 As shown, this is an edge production cluster 110 consisting of five nodes. After the edge production cluster 110 is deployed and started, it enters the service state. At the same time, various monitoring components deployed in the data acquisition and control module 120 are started, and begin to continuously collect various performance parameters, operating status and business data in the cluster environment.

[0028] The data acquisition and control module 120 is deployed inside the edge production cluster 110. It is used to collect performance index data, distributed call chain data and log data of nodes and container groups in the edge production cluster 110, and to receive and execute remote control commands.

[0029] In one embodiment, the data acquisition control module 120 includes a performance data acquisition unit, a link data acquisition unit, a log data acquisition unit, and a command interpretation and execution unit.

[0030] The performance data acquisition unit is used to periodically collect resource utilization metrics and application layer business metrics for nodes and container groups.

[0031] In one embodiment, the performance data acquisition unit collects time-series metrics reflecting the resource consumption and service processing capabilities of the edge production cluster 110 by deploying a performance metric collector compatible with the container orchestration platform. The acquisition targets cover two types of entities: first, the nodes themselves within the edge production cluster 110, primarily collecting basic resource metrics such as CPU utilization, memory usage, network interface throughput, and disk I / O performance; second, the container groups (Pods) running on the nodes, collecting not only their resource usage but also application-layer metrics related to business logic, such as application programming interface request rate, request latency, error rate, and the container group's own lifecycle status (e.g., running, waiting, terminated). For component nodes hosting infrastructure such as databases, message queues, caches, and search engines, specific metrics closely related to their service characteristics need to be collected, such as the number of active connections and slow query frequency for the database, message production and consumption rates and queue backlog depth for the message queue, key-value hit rate and data synchronization status for the cache service, and indexing rate and query load for the search engine.

[0032] The link data acquisition unit is used to collect and associate the entire link information of distributed service calls to generate call chain data.

[0033] In one embodiment, the link data acquisition unit follows the open distributed tracing specification, collecting tracing data of the distributed service call chain through a link tracing collector to fully depict the path and process of a single external request flowing between various microservices within the system. The link tracing collector captures the global tracing identifier of the request, the local span identifiers of each processing stage, the parent-child relationships between spans, timestamps, and key context information by embedding a lightweight software development kit (SDK) into the business application or deploying independent probes. This raw telemetry data is aggregated by the collector and then encapsulated and forwarded according to a standard protocol format.

[0034] The log data acquisition unit is used to collect and forward log data from nodes, containers, and system components in real time.

[0035] In one embodiment, the log data acquisition unit centrally collects and forwards log event streams generated by the operating system, edge production cluster components, and various business applications by deploying a lightweight log acquisition agent in each node or container. This log acquisition agent monitors specified log files or standard output streams in real time, parses and structures the log lines (e.g., converts them to JSON format), and appends rich contextual metadata (e.g., node name, container group name, namespace) before sending the log events to downstream processing units.

[0036] The command interpretation and execution unit is used to receive, parse and execute control commands from the cloud subsystem 20.

[0037] In one embodiment, the command interpretation and execution unit is implemented as an interpreter that supports a specific scripting language, which can convert received instructions into specific operation commands that can be executed on the edge production cluster 110 nodes, thereby enabling proactive intervention in the resource or application status of the edge production cluster 110.

[0038] In this embodiment, in terms of physical deployment and data flow, the data acquisition and control module 120 integrates or coordinates the aforementioned performance data acquisition unit, link data acquisition unit, and log data acquisition unit to form a comprehensive monitoring system covering all nodes and container groups within the edge production cluster 110. These acquisition units work continuously, performing preliminary local caching and tagging on the acquired multi-source, heterogeneous raw monitoring data (including metrics, links, and logs), and then summarizing and sending it to the data storage module 130. This completes the first stage of aggregation and preliminary organization of production environment monitoring data, providing a basic data source for subsequent unified data modeling and fusion processing.

[0039] The data storage module 130, connected to the data acquisition and control module 120, is used to receive and store multi-source heterogeneous monitoring data. It has an OPC UA server deployed inside, which is used to build the monitoring data into a standardized information model according to the topology of the edge production cluster 110.

[0040] In this embodiment, the data acquisition and control module 120 completed the initial collection and aggregation of monitoring data from the edge production cluster 110. However, the output data exhibits significant multi-source and heterogeneity. Specifically, performance indicator data typically follows a specific time-series data format, containing a large amount of repetitive tag information; log data often presents as nested semi-structured or unstructured text formats, containing many redundant fields; and distributed link data usually adopts a binary serialization format, which is not convenient for direct understanding and interaction. These differences in data formats make it difficult to perform consistent modeling, querying, and correlation analysis of the state of the edge production cluster 110.

[0041] In one embodiment, an OPC UA server is deployed in the data storage module 130. This OPC UA server establishes an information model that matches the physical and logical topology of the edge production cluster 110. During implementation, based on the actual structure of the edge production cluster 110 (such as the hierarchy and relationships of nodes and container groups), a corresponding node network is created in the address space of the OPC UA server. Each monitored entity (such as a physical node or a container group) is abstracted as an object node, and the specific monitoring metrics of this entity (such as CPU utilization, error log entries, and call chain span) are defined as variable nodes or attributes under this object node. By setting reference relationships between nodes (such as "contains" and "connects"), the organizational structure and interaction relationships of each element in the edge production cluster 110 are mapped.

[0042] As an example, such as Figure 4 As shown, taking KEPServerEX software as an example, channels are set up and nodes are added in the software. According to the required detection indicators and indicator data format of each Node and Pod, the tag group and tag are set to generate OPC UA server address space nodes. The server monitoring parameter table is refined according to the data attributes of Node and Pod. The two key attributes of node attributes and references are set to form a node network, and the OPC UA server is built.

[0043] In one embodiment, a layered data storage architecture is adopted on top of the unified information model based on OPC UA to further optimize data query performance and storage costs. This architecture divides data storage into a real-time data layer and a historical data layer. The real-time data layer uses a high-performance in-memory database (e.g., Redis) to store the latest, frequently accessed monitoring data snapshots of the edge production cluster 110, such as the core performance indicators of each node at the current moment and active call chain information. This layer provides extremely low-latency data read and write capabilities, supporting real-time updates and rapid status judgment of the monitoring interface. The historical data layer uses a search and analysis database (e.g., Elasticsearch) that supports fast retrieval and analysis to store short-term historical monitoring data processed by the unified model. Standardized data in the OPC UA server is periodically or triggered to be persisted to the historical data layer. This historical data layer is responsible for supporting requirements such as historical trend analysis, complex log retrieval, cross-dimensional data correlation queries, and historical scene playback.

[0044] In this embodiment, the hierarchical storage architecture fully leverages the performance advantages of different types of databases, achieving separate storage of data. While ensuring real-time monitoring, it also provides data support for in-depth offline analysis and problem backtracking, forming a complete data storage closed loop.

[0045] The network data transmission module 140 is connected to the data storage module 130 and has a built-in OPC UA client. It is used to obtain data from the OPC UA server according to the data characteristics using a polling or subscription mechanism and upload the data to the cloud subsystem 20. It is also used to receive instructions from the cloud subsystem 20 and write them to the OPC UA server.

[0046] In one embodiment, the network data transmission module 140 serves as a communication hub connecting the edge subsystem 10 and the cloud subsystem 20. An OPC UA client is built into the network data transmission module 140. This OPC UA client establishes a secure and stable communication session with the OPC UA server in the data storage module 130 by configuring the target server's communication address and port number. After establishing the connection, the OPC UA client can access and browse the complete node network topology built in the OPC UA server's address space, obtaining a list of all managed data nodes and their metadata information. By specifying a unique node identifier, the OPC UA client can perform read or write operations on the data variables associated with the node.

[0047] In one embodiment, the network data transmission module 140 includes an uplink data transmission unit and a downlink control command transmission unit. The uplink data transmission unit is used to transmit monitoring data of the edge production cluster 110 generated by the data acquisition and control module 120 to the cloud subsystem 20. The downlink control command transmission unit is used to receive and forward control commands from the cloud subsystem 20.

[0048] Specifically, the uplink data transmission unit employs a periodic polling mechanism for performance metrics data (such as CPU and memory utilization) that are frequently updated and highly continuous. The OPC UA client actively reads the latest values ​​of the corresponding performance data nodes from the OPC UA server at preset fixed time intervals and packages them for transmission to the cloud subsystem 20. When a new node or container group is detected joining and entering operation in the edge production cluster 110, it is automatically added to the polling list. For irregularly updated, event-driven log data and call chain data, a subscription-notification-based push mechanism is used. The OPC UA client subscribes to notifications of changes to relevant data nodes from the OPC UA server. Once the server updates the value of the corresponding node due to a new log event or call chain span (usually indicated by a timestamp change), it immediately sends a data change notification to the OPC UA client. Upon receiving the notification, the OPC UA client only retrieves the changed data, effectively avoiding the network and computing resource consumption caused by high-frequency polling and ensuring low latency and reliable reporting of event data.

[0049] Specifically, the downlink control command transmission unit, when the cloud subsystem 20 generates debugging or control commands, uses the OPC UA client of the network data transmission module 140 as a data writing end to write the command as a new data value to a predefined, dedicated node in the OPC UA server for command issuance. The data acquisition and control module 120, deployed within the edge production cluster 110, has subscribed to this command node. Once the command node value is updated, the OPC UA server immediately pushes the updated content to the data acquisition and control module 120. The command interpretation and execution unit of the data acquisition and control module 120 then parses and authenticates the command, and converts it into specific command-line operations for execution in the edge production cluster 110, thereby completing the closed loop from the control intent of the cloud subsystem 20 to the actual action of the edge production cluster 110.

[0050] The cloud subsystem 20 is deployed in the central cloud, including a container cloud platform 210 and a cloud-based visualization and debugging module 220. The container cloud platform 210 is deployed in the central cloud server and communicates with the network data transmission module 140. It is used to receive, store and manage monitoring data from the network data transmission module 140 in one or more edge subsystems 10 and maintain a cloud cluster virtual debugging environment consistent with the environment configuration of the edge production cluster 110. As a digital twin of the edge production cluster 110, it is used for high-fidelity testing and change rehearsal.

[0051] In this embodiment, the container cloud platform 210 continuously receives pre-processed cluster performance, link, and log data uploaded by the edge subsystem 10. This massive, multi-dimensional monitoring data is archived, indexed, and managed to form a globally unified data resource pool.

[0052] In one embodiment, the container cloud platform 210 provides a unified operation and maintenance management portal, enabling operation and maintenance personnel to intuitively view the status of each cluster and input or trigger control commands for a specific edge production cluster 110. Once a command is generated, the container cloud platform 210 encapsulates it into a standardized command message, which is then written to the OPC UA server of the data storage module 130 of the target edge production cluster 110 via the communication link and the network data transmission module 140 of the edge subsystem 10, and stored in a predefined command node.

[0053] In one embodiment, the data acquisition control module 120 of the edge subsystem 10 continuously monitors the status changes of the command node in the OPC UA server through a subscription mechanism. Once the command is issued, the change notification is immediately pushed to the data acquisition control module 120. The command interpretation and execution unit within the module immediately performs security parsing and verification on the command, and converts it into a specific operation command for execution in the edge production cluster 110. The execution result of the command (including success, failure status and related output information) is used as feedback data and synchronously written back to the corresponding feedback node of the OPC UA server by the data acquisition control module 120. This status change is again actively reported to the container cloud platform 210 via the network data transmission module 140 through the subscription mechanism. After receiving the report, the container cloud platform 210 updates the execution result and presents it in the operation and maintenance management portal for the operation and maintenance personnel who initiated the operation to view in real time. This embodiment constructs a complete two-way control closed loop from issuing commands from the cloud subsystem 20 to executing them in the edge subsystem 10, and then to synchronous feedback of status, realizing remote control of the distributed edge production cluster 110.

[0054] The system also includes a cloud-based visualization debugging module 220 deployed in the cloud subsystem 20 and a local node debugging module 150 deployed in the edge subsystem 10. By deploying a unified logic and collaborative view debugging module in the edge subsystem 10 and the cloud subsystem 20 respectively, the system provides maintenance personnel with a three-dimensional visualization monitoring and interactive interface from global to local perspectives. The cloud-based visualization debugging module 220 is integrated into the management portal of the container cloud platform 210, including a scenario building unit, a scenario interaction unit, a model data mapping unit, a simulation unit, and a visualization control unit.

[0055] In one embodiment, the scene building unit utilizes a 3D graphics engine to uniformly construct a 3D visualization scene based on the abstract logical topology of each edge cluster of the access platform. Specifically, cluster nodes are represented by cube models, container groups by sphere models, and an overall model reflecting cluster hierarchy and relationships is constructed in 3D space using connecting lines based on service call relationships and network topology. This scene is published as an interactive web application using Web graphics library technology and embedded in a cloud management portal. Cloud operations and maintenance personnel can access it through a browser to achieve unified panoramic 3D monitoring of multiple clusters and resource pools.

[0056] As an example, such as Figure 5As shown, taking a typical production business cluster as an example, a 3D tree-shaped network spatial model of the cluster is constructed in Unity3D software. The management node is used as the root node, and the business nodes and data storage and processing component nodes are used as leaf nodes. Each node spatial model is connected by lines based on user request links and network traffic. Similarly, by connecting the Pods in each node in the same way, a 3D visualization spatial model of the cluster can be formed.

[0057] In one embodiment, the model data mapping unit connects to cloud data storage centers (such as Redis and Elasticsearch) and quality assessment services. It dynamically binds real-time monitoring data, historical data streams, and intelligent assessment results (such as health scores and anomaly alarms) gathered from various edge computing points to corresponding models in a 3D scene. By driving real-time changes in the model's visual attributes such as color, size, and blinking status, it intuitively presents the overall health of the cluster, performance hotspots, and anomalies.

[0058] In one embodiment, the model data mapping unit further includes a historical link playback component to provide powerful historical analysis capabilities. Operations personnel can select a historical time period or a specific trace ID, and the module retrieves and associates the complete call chain, performance metric sequence, and log events within that time period from cloud historical storage. Subsequently, the model is driven to perform a time-series playback in a 3D scene, dynamically reconstructing the flow path of historical requests, and synchronously displaying the performance snapshot and log details at that time in an auxiliary view, achieving cross-dimensional fault backtracking.

[0059] In one embodiment, the simulation unit directly drives and displays a visual scene of the cloud-based cluster virtual debugging environment (digital twin). Developers or operations personnel can deploy new versions of applications or implement architectural change plans within this twin scene and observe system behavior under replayed real production traffic. Simultaneously, it supports intuitive interactive control within the 3D scene: for example, operations personnel can drag and drop a model representing a Pod from one node model area to another. This interactive event is captured by the module and converted into a standard container scheduling API request, sent to the backend service of the container cloud platform, and then distributed to the target edge cluster for execution via the command channel, forming a "what you see is what you get" cloud control closed loop.

[0060] The local node debugging module 150 is deployed on the local management terminal of the edge production cluster, focusing on in-depth, real-time monitoring and on-site debugging of that specific cluster.

[0061] In one embodiment, the local node debugging module 150 includes a local scene unit, a local alarm unit, and a local interaction unit.

[0062] In one embodiment, the local scene unit loads an abstract 3D model logic consistent with the cloud subsystem, but only renders and displays the topology of the single edge production cluster 110 to which it is connected. Its data source directly connects to the OPC UA server of the edge-side data storage module 130 or real-time cloud data synchronized via the network data transmission module 140, ensuring low-latency updates to the view. Local operations personnel can use this module to observe the status of each node and Pod in the cluster in real time and with fine detail, and quickly perceive anomalies through visualization methods such as color and alarm animations.

[0063] In one embodiment, the local alarm unit is used to subscribe to real-time monitoring data preferentially from the data storage and management module (OPCUA server) on the edge side or the local cache, so as to achieve low-latency and high-frequency visual updates of monitoring indicators. At the same time, it receives and quickly responds to the intelligent assessment alarm results for this cluster sent from the cloud, and provides visual prompts in the local 3D scene in a high-priority manner (such as strong flashing, pop-up window), so that on-site personnel can perceive and handle anomalies as soon as possible.

[0064] In one embodiment, the local interaction unit is used to prioritize calling local APIs or executing relevant debugging commands through the edge-side data acquisition and control module when operations and maintenance personnel perform interactive operations in the local 3D scene (such as clicking to view Pod details or triggering local log retrieval) to obtain the fastest response. For operations that need to be persistent, such as resource scheduling, they are converted into instructions and can be quickly tried through the local channel or forwarded to the cloud instruction channel for unified processing to ensure the consistency of operations.

[0065] In this embodiment, the cloud and edge visualization modules ensure consistency between their views by sharing a unified cluster metadata model and data mapping rules. The interaction logs and important status changes of the local node debugging module 150 can be synchronized to the cloud and included in global auditing; scheduling instructions and policies issued by the cloud can also synchronously affect the view of the local node debugging module 150. Together, these constitute a visualized monitoring and debugging system covering both "centralized global control" and "edge real-time response."

[0066] In one embodiment, the container cloud platform 210 further includes a quality assessment module, which is used to configure personalized monitoring indicator sets and weights for different types of nodes or container groups; normalize and comprehensively calculate the collected monitoring indicator sequences to obtain a health sample value sequence; analyze the health sample value sequence based on statistical process control methods, and determine whether it is in a controlled state according to preset rules; when it is determined to be abnormal, trigger an alarm and highlight it in the three-dimensional scene of the cloud visualization debugging module 220.

[0067] In this embodiment, considering that nodes with different functions (such as business nodes, database nodes, and message queue nodes) focus on different performance indicators, and that different instances of the same type of node may also have different indicator focuses, the quality assessment module allows operations and maintenance personnel to define a set of key monitoring indicators for each entity (node ​​or container group) being assessed in a personalized manner, and to configure a corresponding weight coefficient for each indicator in the set. The sum of the weight coefficients is 1 to reflect the relative importance of each indicator in the health evaluation of the entity. The assessment process is carried out periodically. In each assessment period, the raw sample values ​​of each monitoring indicator of the entity are obtained. First, the value of each indicator is normalized to eliminate the differences in the units and numerical ranges between different indicators. Normalization is based on a preset acceptable threshold range for the indicator. Subsequently, based on the normalized value of each indicator and its preset weight, the comprehensive health sample value of the entity in the current assessment period is calculated. The comprehensive health sample value of each entity is continuously collected over a continuous period of time to form a time series. Based on this series, a mean-range control chart is constructed using statistical process control theory. Specifically, the system calculates the upper limit of the mean control, the lower limit of the mean control, the upper limit of the range control, and the lower limit of the range control for the sequence. These control limits define the statistically "controlled" fluctuation range of the entity's health status. The system continuously plots newly generated comprehensive health sample values ​​on the control chart and applies a set of preset anomaly criteria (e.g., a single sample point exceeds the control limit; multiple consecutive sample points show an upward or downward trend; too many sample points are densely distributed near the center line, etc.) to analyze the process. Once the pattern of the current sample sequence triggers any of the anomaly criteria, the system determines that the entity's operating status may have deviated from the normal "controlled" range and entered a "sub-healthy" or "abnormal" state.

[0068] In one embodiment, the quality assessment module specifically performs the following steps: Suppose a node A set of monitoring parameters is obtained at all times. For monitoring indicators The corresponding weighting coefficient is It is manually set by the operation and maintenance monitoring personnel, and .

[0069] Normalization calculation of multi-dimensional monitoring indicators: Formula 1 in, For monitoring indicators The maximum value acceptable to maintenance personnel. For monitoring indicators The minimum acceptable value.

[0070] After normalization, the value of the node can be calculated. Sample values ​​at time 1 for: Formula 2 Assume that the normalized sample set of a node's monitorable metric over a continuous time period is as follows: The formula for the sample range is: Formula 3 in, For monitoring indicator samples The maximum value acceptable to maintenance personnel. For monitoring indicators The minimum acceptable value.

[0071] The formula for the mean of the sample range of monitoring indicators is: Formula 4 in, Let m represent the range of the m-th sample, and N represent the sample size.

[0072] The formula for the average of the sample means of the monitoring indicators is: Formula 5 in, This represents the mean of the sample mean of the k-th indicator.

[0073] The formula for the upper limit of mean control is: Formula 6 The formula for the lower limit of mean control is: Formula 7 in, The fixed parameters depend on the sample size.

[0074] The formula for controlling the upper limit of the sample range is: Formula 8 The formula for the lower limit of sample range control is: Formula 9 in, , The fixed parameters depend on the sample size.

[0075] The Nelson rule is used to judge the sample set of monitoring indicators: if the following conditions occur, the node performance is considered to be in an abnormal state and an alarm needs to be triggered to the operation and maintenance personnel.

[0076] (1) One metric exceeds UCL or is below LCL. (2) Two out of three consecutive measurement data are above μ+2σ or below μ-2σ. (3) Six consecutive measurement data are in an upward or downward trend. (4) 15 consecutive measurement data are between μ+σ and μ-σ. (5) The situation where 14 consecutive measurement data fluctuate up and down. (6) Eight consecutive measurement data are higher than μ+σ or lower than μ-σ. (7) Eight consecutive measurement data points are located above or below the center line.

[0077] (8) Four out of five consecutive measurement data are above μ+σ or below μ-σ.

[0078] Where μ is the sample mean. , It is related to the sample size.

[0079] In this embodiment, the evaluation conclusions obtained by the quality assessment module are linked with the cloud-based visualization debugging module 220. In the 3D visualization scene, the visual appearance (such as color, flashing status, and alarm icons) of the models corresponding to entities judged to be in abnormal condition or with poor trends will change significantly in real time, thereby providing operation and maintenance personnel with intuitive and proactive visual warnings. This mechanism enables operation and maintenance personnel to go beyond simple judgment of single indicator thresholds and discover performance degradation and potential failure risks at an early stage from statistical trends, realizing a shift from a passive response to a proactive prevention operation and maintenance mode.

[0080] This disclosure proposes a visualization construction scheme and architecture that combines edge cloud and central cloud for cluster monitoring and debugging. It utilizes the concept of digital twins to concretely visualize and model the abstract cluster concepts of Node and Pod, while simultaneously integrating and processing multi-dimensional heterogeneous monitoring data. A cloud-based visualization and debugging module 220 is deployed on both the cloud side and the local edge side, enabling both local and cloud-based visualization, adjustment, and control of the cluster. This fully utilizes the computing resources of both the edge cloud and central cloud, leveraging the advantages of cloud-edge collaboration.

[0081] This proposal suggests a solution to replace the traditional testing environment with a digital twin simulation testing environment. By digitally twinning the real production environment, a more realistic testing environment is built, which can perform more accurate simulation testing and changes, making it easier for development and testing personnel to test new versions of code, and making it easier for operations and maintenance personnel to conduct simulation exercises and evaluations of changes before going live.

[0082] This proposal puts forward a cluster monitoring quality assessment visualization scheme based on the improved SPC process control method. Combined with a three-dimensional twin monitoring system, it realizes personalized health assessment of multi-source heterogeneous performance monitoring parameters of Nodes and Pods with different functions, so that operation and maintenance personnel can timely and visually perceive the node status.

[0083] Example 2 Figure 2 To apply the cloud-edge collaborative cluster visualization monitoring and debugging method flowchart disclosed herein to the risk perception test orchestration system described above, the following will refer to... Figure 2 This paper provides a detailed description of the cloud-edge collaborative cluster visualization monitoring and debugging method disclosed herein.

[0084] In step 101, in the edge production cluster 110, monitoring data of nodes and containers are collected through the data acquisition control module 120.

[0085] In this embodiment, an edge production cluster 110 environment based on a container orchestration platform is deployed in the edge subsystem 10. The edge production cluster 110 environment currently primarily uses Kubernetes for containerized deployment, expansion, and management. The edge production cluster 110 consists of multiple server nodes, each of which can be roughly divided into business nodes and component nodes. Business nodes are those that run actual business logic, deploying application instances or service Pods developed by developers. Component nodes are those in the edge production cluster 110 that run infrastructure components or supporting services, typically management nodes, data storage service nodes, or processing service nodes (MySQL, Redis, Kafka, ElasticSearch, etc.). Figure 3 The edge production cluster 110, consisting of five nodes, represents a typical production business scenario. Once the production environment of the edge production cluster 110 is deployed, the data acquisition and control module 120 can collect various monitoring parameters in the environment through the deployed monitoring components.

[0086] In one embodiment, Prometheus is used to collect and report time-series performance data. For business nodes, the main monitoring metrics include CPU utilization, memory utilization, network traffic, and disk I / O. For Pods on business nodes, the main monitoring metrics include application API request volume and Pod running status. For component nodes, more personalized monitoring metrics are included. For example, database monitoring metrics include: request thread connections, slow queries, and connection usage. Message queue metrics include: message processing rate, message processing latency, and message retry rate. Caching metrics include: cache hit rate and master-slave replication status. For the ElasticSearch search engine within the component, its built-in monitoring component, Metricbeat, is used for monitoring, with metrics including: query load rate and index utilization.

[0087] In one embodiment, OpenTelemetry is used to collect call chain data. The OpenTelemetry Collector collects the request call telemetry data between business Pods collected by the OpenTelemetry Operator, organizes it, and sends the data outwards using the OTLP protocol.

[0088] In one embodiment, the ELK (Elasticsearch, Logstash, Kibana) solution is used. Logstash is mainly responsible for collecting logs, while Elasticsearch and Kibana are responsible for storing and displaying search logs. Therefore, only Logstash is deployed in the data collection control module 120 for log collection.

[0089] In this embodiment, Prometheus, OpenTelemetry, and Logstash are deployed to monitor each Node and Pod in the production environment of the edge production cluster 110, and the collected multi-source heterogeneous data is organized and sent to the OPC UA server.

[0090] In step 102, in the data storage module 130, the monitoring data is constructed into a unified information model according to the cluster topology using the OPC UA server.

[0091] In one embodiment, Prometheus outputs metric data in the following format:<metric name> { <label name>= <label value>}<metric value> This data format often contains a large amount of redundant data in the monitoring metric data sets for each Pod, leading to high processing and storage costs, especially in big data environments. Logstash output logs are primarily in a multi-level nested JSON format, with numerous redundant parameters. OpenTelemetry's ProtoBuf data format is serialized data, which is not easily understood intuitively. Therefore, OPC UA technology is used to manage large amounts of parallel, heterogeneous, and multi-source data. An OPC UA server is built to store various monitoring data as spatial nodes, forming a node network topology.

[0092] As an example, using KEPServerEX software, the process involves setting up channels and adding nodes. Based on the required monitoring metrics and data formats for each Node and Pod, tag groups and tags are set to generate OPC UA server address space nodes. The server monitoring parameter table is refined based on the Node and Pod data attributes. The two key attributes of the nodes—attributes and references—are set to form a node network, completing the OPC UA server setup. The resulting interface is shown below. Figure 4 As shown.

[0093] In one embodiment, ElasticSearch and Redis are used to store data in combination. ElasticSearch stores short-term historical monitoring data of Nodes and Pods in a unified data format after integration, while Redis stores real-time monitoring data, giving full play to the performance advantages of both.

[0094] In step 103, based on the data characteristics, the data obtained from the OPC UA server is uploaded to the cloud subsystem 20 using a polling or subscription mechanism, and the control commands issued by the cloud subsystem 20 are written into the designated command node of the OPC UA server.

[0095] In one embodiment, an OPC UA client is set up. The OPC UA client establishes a communication connection with the OPC UA server through a communication address and port number, obtains the data list and parameter-related information of the nodes in the OPC UA server's address space, and performs data read and write operations by accessing parameters through the node ID.

[0096] In one embodiment, in high-concurrency big data business scenarios, Node and Pod performance data needs to be monitored at the second level. When a new Node or Pod is found to be added and its status is running, a polling mechanism is used to cyclically read the performance data parameters of the node in the OPC UA server at a fixed rate and send them to the cloud subsystem 20. For certain data volumes with uncertain update frequencies (such as log data and link data), the timestamp data in this type of data group is monitored. Whenever the timestamp data is updated, it is considered that there is a relevant update in the log data group or link data group, avoiding the problem of duplicate data reporting due to too many monitored data items. A subscription push mechanism is used to obtain data change notifications in the OPC UA server and then transmit the relevant data to the cloud subsystem 20, reducing the resource consumption and data loss problems caused by polling. When the cloud subsystem 20 sends debug control commands to the edge subsystem 10, the control commands are written to the OPC UA server, the subscription push mechanism is used to obtain the control commands, and after parsing, the Nodes and Pods in the production environment of the edge production cluster 110 are controlled through the Shell command interpreter.

[0097] In one embodiment, a container cloud platform 210 is deployed in the cloud subsystem 20 to receive and store long-term performance, link, and log data from the edge production cluster 110 of the edge subsystem 10. Simultaneously, OPC UA server control commands input by operations personnel in the cloud subsystem 20 are sent to the OPC UA server, and the personnel subscribe to command monitoring items on the OPC UA server. When a new command updates the monitoring item, the relevant information is pushed to the Shell command interpreter, and the return information after command execution is synchronously transmitted back to the command monitoring item, and then synchronously transmitted back to the container cloud platform 210 through the subscription mechanism, allowing operations personnel to view it in the cloud subsystem 20.

[0098] In step 104, monitoring data is received and stored in the container cloud platform 210, and simulation tests or change rehearsals are performed in a cloud cluster virtual debugging environment that is consistent with the environment configuration of the edge production cluster 110.

[0099] As an example, in Unity3D software, scene simulation cannot be directly viewed through the webpage's front-end service, nor can users utilize the software's 3D walkthrough function. By packaging the Unity project into a WebGL project package, and embedding the index.html file within the package into the front-end project, the front-end webpage can display the Unity3D project's visuals. The front-end JavaScript and Unity3D agree on interaction scripts and functions, calling each other to achieve interactive functionality. Ultimately, the cluster's production 3D scene is displayed in real-time on the container cloud platform 210 page of cloud subsystem 20 and the monitoring page of edge subsystem 10. Operations personnel can interact with the scene in Unity3D in real-time via mouse and keyboard on the webpage.

[0100] As an example, the StackExchange.Redis library is imported into Unity3D software. A database query script is written to map real-time monitoring data from Redis in the cloud to objects in the Node and Pod models. The quality assessment module utilizes central cloud computing power to perform real-time evaluation of each Pod, using model colors to distinguish health status. Simultaneously, the evaluation data is sent to the edge production cluster 110 of edge subsystem 10, allowing maintenance personnel in both edge subsystem 10 and cloud subsystem 20 to quickly perceive the Pod status. If a Pod is deleted, created, or scheduled, the management node detects this and updates the Pod status to the OPC UA server via the data acquisition and control module 120, uploading it to cloud subsystem 20. In Unity3D software, the Pod model is simultaneously deleted from the Node space, a new model is created in the Node environment, and a tree-like spatial structure is constructed based on monitoring indicators and link data. The Pod is moved from the old Node space to the new Node space, and the old tree structure in the original space is deleted based on monitoring indicators and link data, while a new tree-like spatial structure is reconstructed.

[0101] As an example, the UnityWebRequest library in Unity3D is used to connect to the ElasticSearch data search engine on the container cloud platform. Based on the playback requirements, the traceId of the required playback path is searched in Elasticsearch. The searched text index data is restructured according to PodAddress, parentSpanId, SpanId, and request start and end times, and mapped to various twin models in Unity3D. The playback of the request's journey between Pods within this time period is then based on the request message's start and end times. Simultaneously, the historical logs and performance status of this request on the corresponding Pod are queried from Elasticsearch and the database using timestamps, and displayed in Unity3D. This achieves visualized monitoring by combining the trace, logs, and performance metrics, avoiding the need to separately query relevant information from various operational tools, thus improving operational efficiency.

[0102] As an example, compared to existing business testing processes where test cases may not cover all user scenarios of system operations, and short-term stress testing using JMeter failing to test system performance under long-term use, using the digital twin concept to build a real production business cluster for testing offers superior results. A cluster environment with the same configuration as the production environment of edge subsystem 10 is built on the central cloud server of cloud subsystem 20 and synchronously connected to container cloud platform 210. User requests for system operations collected by the edge subsystem 10 cluster are uploaded to container cloud platform 210 as link and log data. Container cloud platform 210 analyzes and processes the user request data and synchronously transmits virtual requests to the digital twin testing environment. When developers submit new versions of business code, testers can start new business Pods in the digital twin testing environment to replace the original business Pods. The robustness of the new program under high traffic and high concurrency can be observed through the monitoring interface of cloud subsystem 20. When problems occur, they can be centrally displayed through link, log, and performance data, allowing for faster troubleshooting. Meanwhile, the cloud subsystem 20 can compress the actual user requests and run them for a long time in the twin test environment to simulate the long-term stability of the system after future business growth under the existing environment configuration.

[0103] As an example, compared to the existing change management process which requires experienced professionals to evaluate the change plan, conduct change testing in a test environment, and finally implement the change in the production environment, this solution can test the impact of the change plan on the business system in a more realistic network traffic access twin test environment, simulating the potential impact of changing the plan on the real production environment. Change personnel execute the change plan step by step in the twin test environment, observing the performance stability of Nodes and Pods after each change step through the cloud subsystem 20, and checking for errors and anomalies in logs and link data.

[0104] In step 105, the cloud-based visualization debugging module 220 generates a three-dimensional visualization scene based on monitoring data, performs state mapping and historical data playback, and receives interactive operations to regulate the edge production cluster 110.

[0105] As an example, let's illustrate the typical scenario proposed in step 101, where business Pod1 is scheduled from business Node1 to business Node2. A visualization scenario of a single edge server cluster is deployed in edge subsystem 10, and a visualization scenario of a multi-server resource pool is deployed in cloud subsystem 20. In the visualization scenario of cloud subsystem 20, operations personnel can drag Pod1 from the Node1 cube space to the Node2 cube space using the mouse, or use Unity software to set coordinate parameters on the Node1 model to move it to the Node2 space. Unity's trigger module detects this operation and triggers a script file, translating the dynamic Pod movement operation into a static Pod scheduling instruction. This instruction is then sent from cloud subsystem 20 to edge subsystem 10 for parsing and subsequently to the instruction parameter table of the OPC UA server. The node control function of data acquisition control module 120, after receiving this instruction from the server, sends the command to the management node in the production environment. After being scheduled by the management component node, Pod1 is re-discovered and monitored for data collection by Prometheus, OpenTelemetry, and Logstash in data acquisition control module 120 on Node2. During the data reporting process to the OPC UA server, a new Pod1 monitoring item is generated in the Node2 node parameter table, while the existing Pod1 monitoring item data is deleted from the Node1 node parameter table. The monitoring data is then reported to the cloud visualization and debugging module 220 of both the edge subsystem 10 and the cloud subsystem 20, and a new tree-like spatial structure is generated through data mapping. During debugging, the operations and maintenance personnel in the edge production cluster 110 of the edge subsystem 10 focus more on the status of the local server edge production cluster 110, and use the edge production cluster 110 quality assessment scheme defined and calculated by the cloud subsystem 20 to perform visualized health monitoring of the local edge production cluster 110. Meanwhile, the operations and maintenance personnel in the cloud subsystem 20 focus on the overall monitoring of multiple locations, multiple resource pools, and multiple clusters, utilizing the central cloud computing power for unified management and calculation of performance, logs, and call chains.

[0106] In step 106, based on the statistical process control method, the monitoring indicators of nodes and containers are configured with personalized weights, normalized and health sample values ​​are calculated, and the outlier rules are applied to evaluate the health status of nodes or containers and perform visualization representation.

[0107] In one embodiment, step 101 has already described in detail that business nodes and component nodes have different performance monitoring metrics. Furthermore, nodes of the same type may have different emphases on performance metrics; some business nodes emphasize resource utilization, while others emphasize customer-perceptible metrics such as response time and request success rate. Therefore, a multi-dimensional and personalized evaluation of node performance is required.

[0108] Suppose a node A set of monitoring parameters is obtained at all times. For monitoring indicators The corresponding weighting coefficient is It is manually set by the operation and maintenance monitoring personnel, and .

[0109] Normalization calculation of multi-dimensional monitoring indicators:

[0110] In the formula For monitoring indicators The maximum value acceptable to maintenance personnel. For monitoring indicators The minimum acceptable value.

[0111] After normalization, the value of the node can be calculated. Sample values ​​at time 1 for:

[0112] Assume that the normalized sample set of a node's monitorable metric over a continuous time period is as follows: The formula for the sample range is:

[0113] In the formula For monitoring indicator samples The maximum value acceptable to maintenance personnel. For monitoring indicators The minimum acceptable value.

[0114] The formula for the mean of the sample range of monitoring indicators is:

[0115] In the formula Let m represent the range of the m-th sample, and N represent the sample size.

[0116] The formula for the average of the sample means of the monitoring indicators is:

[0117] In the formula This represents the mean of the sample mean of the k-th indicator.

[0118] The formula for the upper limit of mean control is:

[0119] The formula for the lower limit of mean control is:

[0120] In the formula The fixed parameters depend on the sample size.

[0121] In one embodiment, the formula for controlling the upper limit of the sample range is:

[0122] The formula for the lower limit of sample range control is:

[0123] In the formula , The fixed parameters depend on the sample size.

[0124] The Nelson rule is used to judge the sample set of monitoring indicators: if the following conditions occur, the node performance is considered to be in an abnormal state and an alarm needs to be triggered to the operation and maintenance personnel.

[0125] (1) One metric exceeds UCL or is below LCL. (2) Two out of three consecutive measurement data are above μ+2σ or below μ-2σ. (3) Six consecutive measurement data are in an upward or downward trend. (4) 15 consecutive measurement data are between μ+σ and μ-σ. (5) The situation where 14 consecutive measurement data fluctuate up and down. (6) Eight consecutive measurement data are higher than μ+σ or lower than μ-σ. (7) Eight consecutive measurement data points are located above or below the center line.

[0126] (8) Four out of five consecutive measurement data are above μ+σ or below μ-σ.

[0127] Where μ is the sample mean. , It is related to the sample size.

[0128] This disclosure provides a cloud-edge collaborative cluster visualization monitoring and debugging system, method, and medium. It utilizes the concept of digital twins to concretely visualize and model the abstract cluster concepts of Nodes and Pods, while simultaneously integrating and processing multi-dimensional heterogeneous monitoring data. A cloud-based visualization debugging module 220 is deployed on both the cloud and local edge sides, enabling both local and cloud-based visualization, adjustment, and control of the cluster. This fully leverages the computing resources of both edge and central clouds, maximizing the advantages of cloud-edge collaboration. A twin simulation testing environment replaces the traditional testing environment. By digitally twinning the real production environment, a more realistic testing environment is built, allowing for more accurate simulation testing and changes. This facilitates testing of new code by development and testing personnel and enables operations and maintenance personnel to conduct simulation exercises and evaluations of changes before deployment. Combined with a 3D twin monitoring system, personalized health assessments of multi-source heterogeneous performance monitoring parameters for Nodes and Pods with different functions are achieved, allowing operations and maintenance personnel to promptly and visually perceive node status.

[0129] In a second aspect, embodiments of this disclosure provide an electronic device, including a memory and a processor, wherein the memory stores a program that runs on the processor, and the processor executes the steps of the cloud-edge collaborative cluster visualization monitoring and debugging method described in the first aspect when running the program. In a third aspect, embodiments of this disclosure provide a computer-readable storage medium having computer instructions stored thereon, which, when executed, perform the steps of the cloud-edge collaborative cluster visualization monitoring and debugging method described in the first aspect.< / label> < / label>

Claims

1. A cluster visualization monitoring and debugging system based on cloud-edge collaboration, characterized in that, This includes edge subsystems deployed at the edge and cloud subsystems deployed in the cloud. The edge subsystem includes: The data acquisition and control module is deployed within the edge production cluster and is used to collect multi-source heterogeneous monitoring data from the edge production cluster. The data storage module, connected to the data acquisition and control module, is used to receive and store the monitoring data. It has a unified architecture server deployed inside, which is used to convert and store the multi-source heterogeneous monitoring data in a unified format, and to provide a data access interface to the network data transmission module. The network data transmission module is connected to the data storage module and is used to transmit the monitoring data and control commands between the edge subsystem and the cloud subsystem. The cloud subsystem includes: The container cloud platform is used to receive and store monitoring data from the edge subsystem and provide an interface for issuing control commands. The cloud-based cluster virtual debugging environment is maintained by the container cloud platform. Its software configuration is consistent with that of the edge production cluster, forming a digital twin of the edge production cluster for simulation testing and change drills. The cloud-based visualization debugging module and / or the local node debugging module deployed on the edge side are used to construct and display a three-dimensional visualization scene of the edge production cluster based on the monitoring data, and receive control commands in the three-dimensional visualization scene, and convert them into control commands for the edge production cluster or the cloud cluster virtual debugging environment.

2. The cloud-edge collaborative cluster visualization monitoring and debugging system according to claim 1, characterized in that, The unified architecture server in the data storage module is an OPC UA server; the OPC UA server is configured to: construct a corresponding node network in the address space based on the physical and logical topology of the edge production cluster; map each monitored node, container and monitoring indicator to an object node or variable node in the node network, and set its attributes and interrelationships, and incorporate the multi-source heterogeneous monitoring data into a unified information model for management and access.

3. The cloud-edge collaborative cluster visualization monitoring and debugging system according to claim 1, characterized in that, The network data transmission module has a built-in client corresponding to the unified architecture server, which is used to obtain data from the unified architecture server and upload it to the cloud according to the data characteristics using a polling or subscription mechanism, and to receive control commands from the cloud and write them to the unified architecture server.

4. The cloud-edge collaborative cluster visualization monitoring and debugging system according to claim 1, characterized in that, The data acquisition and control module further includes: The performance data acquisition unit is used to periodically collect resource utilization indicators and application layer business indicators of nodes and containers. The link data acquisition unit is used to collect and associate the path and time information of distributed service calls to generate call chain data; The log data acquisition unit is used to collect and forward log event streams from nodes, containers, and system components; The command interpretation and execution unit is used to listen for, parse, and securely execute control commands from the unified architecture server.

5. The cloud-edge collaborative cluster visualization monitoring and debugging system according to claim 1, characterized in that, The visualization control module is specifically used for: Nodes are abstracted into a first type of 3D model, containers are abstracted into a second type of 3D model, and a 3D visualization scene model is constructed based on the relationship between nodes and containers and the service call relationship. Establish a mapping relationship between the three-dimensional visualization scene model and the backend data source, and map the monitoring data or health status information into changes in the visual attributes of the geometric model; Based on the selected historical time period or call chain identifier, the complete monitoring data is retrieved from the storage and the 3D visualization scene model is driven to perform a broadcast.

6. The cloud-edge collaborative cluster visualization monitoring and debugging system according to claim 1, characterized in that, The visualization control module supports visual interactive adjustment, specifically used for: Respond to dragging and clicking operations performed by the user on the geometric model in the 3D visualization scene; Transform operation events into standard container orchestration instructions; The instruction is sent to the edge production cluster for execution via the network data transmission module. The 3D visualization scene is updated based on the cluster status feedback after execution.

7. The cloud-edge collaborative cluster visualization monitoring and debugging system according to claim 1, characterized in that, The system also includes a quality assessment module located in the container cloud platform, used for: Configure personalized sets of monitoring metrics and weights for different types of nodes or containers; The collected monitoring indicator sequence is normalized, and the health sample value is calculated to obtain the health sample value sequence. Based on statistical process control methods, the health sample value sequence is analyzed to determine the health status of nodes or containers; The health status information is sent to the cloud-based visualization debugging module and / or the local node debugging module, and then visualized in the 3D visualization scene.

8. A cluster visualization monitoring and debugging method based on cloud-edge collaboration, applied to the cluster visualization monitoring and debugging system based on cloud-edge collaboration as described in claims 1-7, characterized in that, Includes the following steps: S1: In the edge production cluster, monitoring data of nodes and containers are collected through the data acquisition and control module; S2: In the data storage module, the monitoring data is constructed into a unified information model according to the cluster topology using a unified architecture server; S3: Through the network data transmission module, the monitoring data is uploaded to the container cloud platform using a polling or subscription mechanism based on the data characteristics, and the control instructions issued by the cloud subsystem are forwarded to the unified architecture server; S4: Receive and store the monitoring data in the container cloud platform, and perform simulation tests or change rehearsals in a cloud cluster virtual debugging environment that is consistent with the environment configuration of the edge production cluster. S5: Through the visualization control module, a three-dimensional visualization scene is generated based on the monitoring data, and state mapping and historical data playback are performed. Interactive operations are received to regulate the edge production cluster. S6: Based on statistical process control methods, personalized weight configuration, normalization processing and health sample value calculation are performed on the monitoring indicators of nodes and containers. Anomaly detection rules are applied to evaluate the health status of nodes or containers and perform visualization representation.

9. The cluster visualization monitoring and debugging method based on cloud-edge collaboration according to claim 8, characterized in that, Step S5 further includes: responding to the user's drag operation on the 3D scene model in the 3D visualization scene, converting the operation event into a control command and sending it to the edge production cluster for execution, and synchronously updating the 3D visualization scene according to the execution result.

10. A computer-readable storage medium storing computer instructions thereon, characterized in that, The computer instructions, when executed, perform a cluster visualization monitoring and debugging method based on cloud-edge collaboration as described in any one of claims 8-9.

Images