Visualization method and device of cloud native monitoring data and computer equipment

Abstract

The invention relates to a visualization method and device for cloud native monitoring data and computer equipment. Relates to the technical field of data processing. The method comprises the following steps: generating a scene label of a cloud native environment based on pre-collected cloud native monitoring data of the cloud native environment; distributing dynamic weights of the system index data and the business index data based on a preset data processing algorithm, and generating a corresponding conventional baseline; dynamically adjusting the conventional base line based on the scene label to obtain a temporary base line; determining a deviation detection result and a traceability link of the cloud native monitoring data based on a pre-constructed multi-scale knowledge graph associated with the cloud native monitoring data, and generating a dynamic detection threshold in combination with a preset service evaluation standard; and based on the temporary baseline, the deviation detection result, the deviation traceability link and the dynamic detection threshold, visualizing a target dynamic baseline, a target deviation detection result and a target traceability link of the cloud native environment. By adopting the method, the visualization effect of the cloud native monitoring data can be improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, apparatus and computer equipment for visualizing cloud-native monitoring data. Background Technology

[0002] Among related technologies, cloud-native architecture has become mainstream. Its monitoring data exhibits significant characteristics such as high-frequency fluctuations, multi-dimensional interweaving, strong scene dependence, and noise interference. How to achieve accurate and efficient monitoring adapted to the cloud-native environment and meet the visualization requirements of cloud-native monitoring data has become a technical problem to be solved.

[0003] However, current methods for generating dynamic baselines in cloud-native monitoring data visualization primarily rely on static sliding window models. These models use historical data of fixed time periods for learning, resulting in rigid update mechanisms that cannot quickly respond to changes in business trends or fluctuations in specific scenarios. This leads to low accuracy of dynamic baselines. Furthermore, the inaccuracy of dynamic baseline generation directly impacts subsequent threshold-based monitoring and detection steps. Multi-scale deviation detection methods, which rely on independent scale judgments and globally fixed thresholds, lack cross-scale correlation logic and cannot automatically trace the root causes of anomalies, thus affecting the visualization efficiency and accuracy of cloud-native monitoring data. Therefore, there is currently a technical problem with poor visualization of cloud-native monitoring data. Summary of the Invention

[0004] Therefore, it is necessary to provide a method, device, and computer equipment for visualizing cloud-native monitoring data to address the aforementioned technical issues of poor visualization of cloud-native monitoring data.

[0005] Firstly, this application provides a method for visualizing cloud-native monitoring data, including:

[0006] Based on pre-collected cloud-native environment monitoring data, scene tags for the cloud-native environment are generated; the cloud-native monitoring data includes system indicator data and business indicator data.

[0007] Based on a preset data processing algorithm, dynamic weights are assigned to the system indicator data and the business indicator data to generate corresponding regular baselines; and the regular baselines are dynamically adjusted based on the scene labels to obtain temporary baselines.

[0008] Based on a pre-built multi-scale knowledge graph associated with the cloud-native monitoring data, the deviation detection results and deviation tracing links of the cloud-native monitoring data are determined, and corresponding dynamic detection thresholds are generated in combination with preset service evaluation standards.

[0009] Based on the temporary baseline, the deviation detection results, the deviation tracing link, and the dynamic detection threshold, the target dynamic baseline, target deviation detection results, and target tracing link of the cloud-native environment are visualized.

[0010] In one embodiment, the visualization method for cloud-native monitoring data further includes: determining the resource type, event type, event processing details, and event trigger time associated with the K8s event data based on the K8s event data included in the pre-collected cloud-native monitoring data; and generating the scene label of the cloud-native environment based on the resource type, event type, event processing details, and event trigger time associated with the K8s event data using a preset rule base.

[0011] In one embodiment, generating the scene tag for the cloud-native environment based on the resource type, event type, event processing details, and event trigger time associated with the K8s event data using a preset rule base includes: filtering candidate rules corresponding to the resource type, event type, event processing details, and event trigger time associated with the K8s event data based on the preset rule base; determining the scene corresponding to the K8s event data when all the judgment conditions of the candidate rules meet the preset threshold of the preset rule base, and generating the scene tag containing the scene type, start time, end time, involved resources, and key parameters.

[0012] In one embodiment, the step of allocating dynamic weights to the system indicator data and the business indicator data based on a preset data processing algorithm to generate a corresponding conventional baseline includes: constructing a real-time data stream processing pipeline based on a preset real-time stream processing framework included in the preset data processing algorithm, and storing the indicator data of the system indicator data for a preset duration; obtaining the correlation score of the system indicator data and the business indicator data through the attention mechanism included in the preset data processing algorithm, and allocating dynamic weights to the system indicator data and the business indicator data in combination with the preset service evaluation criteria included in the preset data processing algorithm to obtain weighted system indicator data and weighted business indicator data; and processing the weighted system indicator data and weighted business indicator data based on the time series prediction algorithm included in the preset data processing algorithm to generate the corresponding conventional baseline.

[0013] In one embodiment, determining the deviation detection result and deviation tracing link of the cloud-native monitoring data based on a pre-constructed multi-scale knowledge graph associated with the cloud-native monitoring data includes: acquiring in real time the deviation rate between the actual value of each scale indicator and the corresponding value of the temporary baseline in the pre-constructed multi-scale knowledge graph associated with the cloud-native monitoring data; if the deviation rate exceeds a preset threshold, obtaining the deviation contribution degree corresponding to the node in the multi-scale knowledge graph; locating candidate root cause nodes according to the ranking of the deviation contribution degrees; and repeating the above process until the deviation detection result and deviation tracing link of the cloud-native monitoring data are determined.

[0014] In one embodiment, the visualization method for cloud-native monitoring data further includes: collecting container data, node data, and cluster data of the cloud-native environment to obtain system indicator data of the cloud-native environment; collecting indicators corresponding to the business systems and business links carried by the cloud-native environment to obtain business indicator data of the cloud-native environment; and collecting log records of resource status changes within the K8s cluster of the cloud-native environment to obtain K8s event data of the cloud-native environment.

[0015] Secondly, this application also provides a visualization device for cloud-native monitoring data, including:

[0016] The scene tag generation module is used to generate scene tags for the cloud-native environment based on pre-collected cloud-native monitoring data; the cloud-native monitoring data includes system indicator data and business indicator data.

[0017] The baseline generation module is used to allocate dynamic weights to the system indicator data and the business indicator data based on a preset data processing algorithm to generate a corresponding regular baseline; and to dynamically adjust the regular baseline based on the scene label to obtain a temporary baseline.

[0018] The dynamic detection threshold generation module is used to determine the deviation detection results and deviation tracing links of the cloud-native monitoring data based on a pre-built multi-scale knowledge graph associated with the cloud-native monitoring data, and generate corresponding dynamic detection thresholds in combination with preset service evaluation standards.

[0019] The results visualization module is used to visualize the target dynamic baseline, target deviation detection results, and target source tracing link of the cloud-native environment based on the temporary baseline, the deviation detection results, the deviation tracing link, and the dynamic detection threshold.

[0020] Thirdly, this application also provides a computer device, the computer device including a memory and a processor, the memory storing a computer program, and the processor executing the computer program to perform the following steps:

[0021] Based on pre-collected cloud-native environment monitoring data, scene tags for the cloud-native environment are generated; the cloud-native monitoring data includes system indicator data and business indicator data.

[0022] Based on a preset data processing algorithm, dynamic weights are assigned to the system indicator data and the business indicator data to generate corresponding regular baselines; and the regular baselines are dynamically adjusted based on the scene labels to obtain temporary baselines.

[0023] Based on a pre-built multi-scale knowledge graph associated with the cloud-native monitoring data, the deviation detection results and deviation tracing links of the cloud-native monitoring data are determined, and corresponding dynamic detection thresholds are generated in combination with preset service evaluation standards.

[0024] Based on the temporary baseline, the deviation detection results, the deviation tracing link, and the dynamic detection threshold, the target dynamic baseline, target deviation detection results, and target tracing link of the cloud-native environment are visualized.

[0025] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0026] Based on pre-collected cloud-native environment monitoring data, scene tags for the cloud-native environment are generated; the cloud-native monitoring data includes system indicator data and business indicator data.

[0027] Based on a preset data processing algorithm, dynamic weights are assigned to the system indicator data and the business indicator data to generate corresponding regular baselines; and the regular baselines are dynamically adjusted based on the scene labels to obtain temporary baselines.

[0028] Based on a pre-built multi-scale knowledge graph associated with the cloud-native monitoring data, the deviation detection results and deviation tracing links of the cloud-native monitoring data are determined, and corresponding dynamic detection thresholds are generated in combination with preset service evaluation standards.

[0029] Based on the temporary baseline, the deviation detection results, the deviation tracing link, and the dynamic detection threshold, the target dynamic baseline, target deviation detection results, and target tracing link of the cloud-native environment are visualized.

[0030] Fifthly, this application also provides a computer program product, which includes a computer program that, when executed by a processor, performs the following steps:

[0031] Based on pre-collected cloud-native environment monitoring data, scene tags for the cloud-native environment are generated; the cloud-native monitoring data includes system indicator data and business indicator data.

[0032] Based on a preset data processing algorithm, dynamic weights are assigned to the system indicator data and the business indicator data to generate corresponding regular baselines; and the regular baselines are dynamically adjusted based on the scene labels to obtain temporary baselines.

[0033] Based on a pre-built multi-scale knowledge graph associated with the cloud-native monitoring data, the deviation detection results and deviation tracing links of the cloud-native monitoring data are determined, and corresponding dynamic detection thresholds are generated in combination with preset service evaluation standards.

[0034] Based on the temporary baseline, the deviation detection results, the deviation tracing link, and the dynamic detection threshold, the target dynamic baseline, target deviation detection results, and target tracing link of the cloud-native environment are visualized.

[0035] The aforementioned visualization methods, devices, and computer equipment for cloud-native monitoring data, through scene tags in the cloud-native environment and the dynamically adjusted temporary baseline based on these scene tags, can accurately match special scenarios such as peak business, reducing the probability of false alarms and missed alarms caused by environmental changes. Multi-scale knowledge graphs can quickly locate the root cause of indicator deviations. When a deviation occurs, it can not only output accurate deviation detection results but also automatically generate a complete tracing link, shortening the problem investigation time. By combining dynamic detection thresholds generated with preset service evaluation standards, the dynamic detection thresholds are no longer static values ​​but values ​​that can be dynamically adjusted according to baseline changes and business needs, thus providing early warnings when system resource utilization approaches the threshold. Therefore, the above process, from scene tag extraction and dynamic baseline generation to deviation detection, tracing analysis, and visualization of the target baseline and tracing link, forms a closed loop of monitoring, analysis, and decision-making. Baseline iteration and deviation location can be completed without manual intervention, reducing maintenance manpower costs while improving the visualization effect of cloud-native monitoring data. Attached Figure Description

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

[0037] Figure 1 This is a flowchart illustrating a cloud-native monitoring data visualization method in one embodiment;

[0038] Figure 2 This is a flowchart illustrating the steps for visualizing cloud-native monitoring data in one embodiment.

[0039] Figure 3 This is a flowchart illustrating the visualization steps for cloud-native monitoring data in yet another embodiment;

[0040] Figure 4 This is a flowchart illustrating a cloud-native monitoring data visualization method in another embodiment;

[0041] Figure 5 This is a structural block diagram of a cloud-native monitoring data visualization device in one embodiment.

[0042] Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0043] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0044] With cloud-native architecture becoming mainstream, its monitoring environment faces new challenges that traditional methods struggle to address. Monitoring data exhibits unique characteristics: first, high-frequency fluctuations, influenced by elastic scaling, instantaneous service startup and shutdown, and sudden surges in business traffic, resulting in constant and dramatic changes in system and business metrics; second, multi-dimensional interweaving, with data spanning multiple layers including containers, nodes, clusters, and business services, forming a complex observation system; and third, strong scenario dependence and noise interference, with the normal range of data highly dependent on the business scenario and prone to distortion due to agent failures or network jitter. Faced with this dynamic data, dynamic baseline generation technology for monitoring still largely relies on static sliding window models. These models learn from historical data of fixed time periods, resulting in rigid update mechanisms that cannot quickly respond to business trend changes (such as permanent traffic shifts caused by new feature launches), leading to severe baseline lag.

[0045] Furthermore, the inaccuracy of the baseline directly impacts subsequent threshold-based monitoring and detection steps. Firstly, in the multi-scale deviation detection stage, there are issues of isolated detection and rigid thresholds: because the system performs independent anomaly judgments for different scales such as containers, services, and clusters, it lacks cross-scale correlation logic. When cluster-level business metrics anomalies occur, the root cause cannot be automatically and quickly traced to a specific faulty node or container, forcing operations personnel to manually troubleshoot from massive amounts of alarms, significantly extending the mean time to repair faults. The widespread use of globally fixed thresholds ignores the differences in reliability requirements for different service types, leading to insufficient monitoring of core services with extremely high stability requirements, while generating numerous meaningless alarms for resource-intensive offline tasks, ultimately causing alarm fatigue and masking the real faults. Therefore, there is a serious lack of coordination between core components such as dynamic baseline generation and multi-scale deviation detection and the inherently highly variable nature of cloud-native monitoring data, ultimately making it difficult to support the refined and intelligent operation and maintenance needs required in a cloud-native environment.

[0046] To solve the above-mentioned technical problems, in one embodiment, such as Figure 1 As shown, a cloud-native monitoring data visualization method is provided. This embodiment illustrates the method applied to a terminal, but it can also be applied to a server, or a system including both a terminal and a server, and implemented through interaction between the terminal and the server. In this embodiment, the method includes the following steps S102 to S108. Wherein:

[0047] Step S102: Based on the pre-collected cloud-native monitoring data of the cloud-native environment, generate scene tags for the cloud-native environment; the cloud-native monitoring data includes system indicator data and business indicator data.

[0048] Cloud-native monitoring data refers to operational status data collected from cloud-native environments, which can be divided into two main categories: system metrics data and business metrics data. System metrics data may include memory utilization, container start / stop frequency, network bandwidth latency, database connection count, etc.; business metrics data may include transaction success rate, request response time, API call frequency, peak user access, order processing throughput, etc. Scenario tags are characteristic identifiers assigned to the operational status of cloud-native environments based on feature analysis of cloud-native monitoring data, used to distinguish different operational scenarios.

[0049] Step S104: Based on a preset data processing algorithm, dynamic weights are assigned to system indicator data and business indicator data to generate corresponding regular baselines; and the regular baselines are dynamically adjusted based on scenario labels to obtain temporary baselines.

[0050] Among them, dynamic weight allocation is a metric priority adjustment strategy based on a preset data processing algorithm. It is used to dynamically allocate the weight ratio of system metric data and business metric data according to the operating characteristics of the cloud-native environment during the baseline generation process. Unlike the fixed weight mode, dynamic weight allocation is adjusted in real time according to changes in the scenario. The regular baseline is a benchmark operating threshold range based on system metric data and business metric data, calculated by the dynamic weight allocation algorithm. It is the metric baseline for the cloud-native environment under normal and stable operating scenarios. The temporary baseline is a scenario-based benchmark threshold range obtained by dynamically adjusting the regular baseline in combination with scenario labels.

[0051] Step S106: Based on the pre-built multi-scale knowledge graph associated with cloud-native monitoring data, determine the deviation detection results and deviation tracing links of cloud-native monitoring data, and generate corresponding dynamic detection thresholds in combination with preset service evaluation standards.

[0052] Among them, the multi-scale knowledge graph is a pre-built hierarchical relational network that associates cloud-native monitoring data, covering multi-dimensional and multi-level objects in the cloud-native environment; the deviation detection result is the conclusion of the indicator anomaly judgment by comparing the difference between cloud-native monitoring data and temporary baseline, combined with dynamic detection threshold; the deviation tracing link is the anomaly root cause location path mined based on the multi-scale knowledge graph, used to trace the underlying cause of the deviation; the dynamic detection threshold is the deviation judgment threshold generated by combining preset service evaluation standards, which will be dynamically adjusted according to the operation scenario and service level requirements of the cloud-native environment.

[0053] S108 visualizes the target dynamic baseline, target deviation detection results, and target traceability link in a cloud-native environment based on temporary baselines, deviation detection results, deviation tracing links, and dynamic detection thresholds.

[0054] Among them, the target dynamic baseline, target deviation detection results, and target source tracing link are the final outputs of the entire process. They are visualized content after scenario-based adjustment, precise detection, and source tracing. The target dynamic baseline is the final benchmark threshold adapted to the current scenario. The target deviation detection results are abnormal indicator information that is accurately judged. The target source tracing link is the complete fault path that locates the root cause.

[0055] In the aforementioned visualization method for cloud-native monitoring data, the visualization process utilizes scene tags for the cloud-native environment. Based on these scene tags, a temporary baseline is dynamically adjusted to accurately match special scenarios such as peak business periods, reducing the probability of false alarms and missed alarms caused by environmental changes. Multi-scale knowledge graphs can quickly pinpoint the root cause of indicator deviations. When a deviation occurs, not only can accurate deviation detection results be output, but a complete tracing chain can also be automatically generated, shortening troubleshooting time. By combining dynamic detection thresholds generated from preset service evaluation standards, these thresholds are no longer static values ​​but can be dynamically adjusted according to baseline changes and business needs, thus providing early warnings when system resource utilization approaches the threshold. Therefore, the above process, from scene tag extraction and dynamic baseline generation to deviation detection, tracing analysis, and visualization of the target baseline and tracing chain, forms a closed loop of monitoring, analysis, and decision-making. Baseline iteration and deviation location can be completed without manual intervention, reducing operational manpower costs while improving the visualization effect of cloud-native monitoring data.

[0056] In an exemplary embodiment, the visualization method for cloud-native monitoring data further includes: determining the resource type, event type, event processing details, and event trigger time associated with the K8s event data based on the K8s event data included in the pre-collected cloud-native monitoring data; and generating scene tags for the cloud-native environment based on the resource type, event type, event processing details, and event trigger time associated with the K8s event data according to a preset rule base.

[0057] The above process corresponds to the steps of parsing K8s (Kubernetes, a record of state changes, operational behaviors, and abnormal situations of various resource objects in a K8s cluster) event data and extracting event types and key parameters. K8s events are records of state changes of resources within the cluster, generated by the K8sAPIServer (Kubernetes API server). The scenario identification unit first needs to convert these events into processable structured information. The parsing logic is as follows: Extract the involvedObject field (associated resource object): This determines the resource type (kind), name (name), and namespace associated with the event, used to locate the affected service, such as "order-serviceDeployment under the prod namespace"; Extract the reason field: This serves as the core identifier of the event type, such as "ScalingReplicaSet" corresponding to scaling up and down, and "ReplicaSetUpdated" corresponding to rolling updates; Extract the message field: This contains specific operational details of the event, such as the number of Pods before and after scaling up and down, and the image version for rolling updates; Extract the creationTimestamp field as the event trigger time; Because different types of K8s events have unique key parameters, these are used for subsequent matching with the rule base.The extraction logic needs to combine the event's reason and message fields, implemented through regular expressions or structured parsing; this includes extracting scaling parameters, rolling update events, and Serverless service start / stop events (ServerlessStart / Stop) parameters: 1. Extraction of scaling parameters includes identifying the scaling direction, quantity changes, and scaling ratio. For example, identifying "up" in "Scaleddpreplicaset..." indicates scaling, and "down" in "Scaleddown..." indicates scaling; 2. When the event reason is ReplicaSetUpdated, indicating a rolling update of the Deployment, extract the new replica set information, update progress, and Pod replacement rate from the event details. Specifically, the newly created ReplicaSet name is used to locate the updated resources. The update progress includes extracting the number of currently updated Pods and the target total number of Pods, expressed as "number of updated Pods". The calculation of "total number of target Pods" reflects the coverage of the update; 3. When the event-associated resource is a "Function" defined by the Serverless framework, and the event reason is "Activated" or "Deactivated", the function name and instance quantity changes are extracted; The rule base is the basis for scene identification and is used to store the trigger conditions of various cloud-native scenarios. The trigger conditions here are determined based on the extracted key parameters, adopting a three-element structure of scene type-trigger condition-judgment condition, and supporting dynamic updates through hot loading in the configuration center; Scene conditions include ScaleOut (scaling up), RollingUpdate (rolling update), etc. The trigger conditions are used to associate the reason field of the K8s event. For example, ScaleOut only matches the ScalingReplicaSet event. The judgment condition consists of multiple threshold parameters, including "ScaleOut" which must simultaneously meet the scaling direction of up and the scaling ratio > 20%.

[0058] In one embodiment, based on a preset rule base and the resource type, event type, event processing details, and event trigger time associated with Kubernetes event data, scene tags for the cloud-native environment are generated, including:

[0059] Based on a preset rule base, candidate rules are selected that correspond to resource types, event types, event processing details, and event trigger times associated with K8s event data. If all the judgment conditions of the candidate rules meet the preset thresholds of the preset rule base, the scenario corresponding to the K8s event data is determined, and scenario tags containing scenario type, start time, end time, involved resources, and key parameters are generated.

[0060] The above process corresponds to generating scenario tags based on a pre-configured cloud-native special scenario rule base, including the following steps: First, determine candidate rules: based on the event's reason field, filter rules associated with that reason from the rule base, such as the "ScalingReplicaSet" event only matching "ScaleOut" and "ScaleIn" rules. Second, verify if conditions are met: for each candidate rule, check if all its judgment conditions are met. For example, the RollingUpdate rule requires both a Pod replacement rate > 50% and the associated resource to be a Deployment. Third, determine the scenario type: if all conditions of a rule are met, the event is determined to belong to the scenario corresponding to that rule. Fourth, if multiple rules are matched simultaneously, prioritize them according to their impact scope: cluster level > service level > container level, and take the scenario with the highest priority. Fifth, generate scenario tags for successfully matched scenarios. Scenario tags include scenario type, start time, end time, involved resources, and key parameters. The scenario identification unit can accurately parse K8s events, extract key parameters, and match scenario rules, providing the dynamic baseline generation module with the core basis for when and how to adjust the baseline, thereby improving the scenario adaptability of cloud-native monitoring.

[0061] In one embodiment, such as Figure 2 As shown, based on a preset data processing algorithm, dynamic weights are assigned to system indicator data and business indicator data to generate corresponding conventional baselines, including:

[0062] Step S202: Based on the preset real-time stream processing framework included in the preset data processing algorithm, a real-time data stream processing pipeline is constructed to save the system indicator data for a preset duration. Step S204: Through the attention mechanism included in the preset data processing algorithm, the correlation scores of the system indicator data and business indicator data are obtained. Dynamic weights are assigned to the system indicator data and business indicator data in combination with the preset service evaluation criteria included in the preset data processing algorithm to obtain weighted system indicator data and weighted business indicator data. Step S206: Based on the time series prediction algorithm included in the preset data processing algorithm, the weighted system indicator data and weighted business indicator data are processed to generate the corresponding conventional baseline.

[0063] The above process corresponds to the dynamic baseline generation unit, which includes a data management subunit, a feature fusion and allocation subunit, and a baseline prediction and update unit. The dynamic baseline generation unit is used to generate a dynamic baseline based on the data processed by the noise filtering unit. Specifically, it includes: the data management subunit, which is used to build a real-time data stream processing pipeline based on the Flink framework, and saves the indicator data and intermediate calculation results of the most recent hour through Flink's state management function to ensure the continuity of baseline updates; and the feature fusion and allocation subunit, which is used to input features including preprocessed system indicators (such as CPU and memory) and business indicators (such as order volume), and calculates feature weights through an attention mechanism: using business indicators as queries and system indicators as key / value pairs, and calculating correlation scores through cosine similarity (such as the correlation score between order volume and payment service CPU utilization = 0.8), with higher scores resulting in greater weights.

[0064] The weights are dynamically adjusted based on the Service Level Agreement (SLA) profile. The service SLA profile predefines four levels: P0 (core services, such as payment), P1 (important services, such as orders), P2 (general services, such as product details), and P3 (non-core services, such as logs). The initial weight of business metrics for P0 services is 60%, and the weight of system metrics is 40%. The initial weight of business metrics for P3 services is 15%, and the weight of system metrics is 85%. The baseline prediction and update unit is used to generate regular baselines and receive scene labels from the adaptive processing module to trigger the generation of temporary baselines. The system uses an LSTM time-series prediction model to generate a regular baseline. The model contains three hidden layers, each with 64 neurons. The input is feature data from the past hour, and the output is the predicted value of the indicator for the next 1-2 minutes. The predicted value is fused with the real-time collected current value using the formula: Baseline value = 0.7 × Predicted value + 0.3 × Current value, generating the regular baseline. When the indicator in the scene label received from the adaptive preprocessing module exceeds a set threshold, a scene-based baseline adjustment is triggered, generating a temporary baseline. For example, in the ScaleOut scenario, if the number of Pods increases beyond a set threshold, the temporary baseline = regular baseline × (1 - 0.2 × scaling ratio). For instance, if the scaling ratio is 0.5, the temporary baseline = regular baseline × 0.9. In the rolling update scenario, the temporary baseline = regular baseline × 1.1, tolerating indicator fluctuations during the update period. Based on the degree of data fluctuation, the baseline update frequency is dynamically set by calculating the indicator fluctuation amplitude in real time. The fluctuation amplitude = standard deviation / mean of time t, where t can be set to 5 minutes. Different update frequencies correspond to different fluctuation amplitude threshold ranges.

[0065] In one embodiment, based on a pre-built multi-scale knowledge graph associated with cloud-native monitoring data, the deviation detection results and deviation tracing links of cloud-native monitoring data are determined, including:

[0066] In real time, the deviation rate between the actual value of each scale indicator and the corresponding value of the temporary baseline in the pre-built multi-scale knowledge graph associated with cloud-native monitoring data is obtained. When the deviation rate exceeds the preset threshold, the deviation contribution degree of the node in the multi-scale knowledge graph is obtained. Candidate root cause nodes are located according to the ranking of deviation contribution degree. The above process is repeated until the deviation detection result and deviation tracing link of cloud-native monitoring data are determined.

[0067] The process of repeating the above steps refers to obtaining in real time the deviation rate between the actual values ​​of each scale indicator and the corresponding values ​​of the temporary baseline in the pre-constructed multi-scale knowledge graph associated with cloud-native monitoring data. When the deviation rate exceeds a preset threshold, the deviation contribution degree of the node in the multi-scale knowledge graph is obtained. Candidate root cause nodes are located according to the ranking of deviation contribution degrees.

[0068] The above process corresponds to the calculation of the edge of the knowledge graph based on the contribution of resource proportion. The edge is the key to the subsequent deviation tracing. The indicator deviation of the upper-level node = the indicator deviation of all lower-level related nodes × the resource proportion weight of the lower-level node to the upper-level node. The association rules between node → (process pointing to) container computing nodes are quantified by calculating the proportion of container resource quota to the total resources of node. Taking the CPU (Central Processing Unit) utilization deviation as an example: the total CPU quota of a certain node (node-01) is 16 cores, of which container A has a CPU quota of 4 cores, accounting for 25%, container B has a CPU quota of 8 cores, accounting for 50%, and container C has a CPU quota of 4 cores, accounting for 25%. If the node CPU utilization deviation is 10%, meaning the actual utilization is 10% higher than the baseline, then: Node CPU deviation = Container A deviation × 25% + Container B deviation × 50% + Container C deviation × 25%. When a node deviation is detected, this formula can be used to deduce: If the deviation of container B is 18%, then its contribution to the node deviation is 18% × 50% = 9%, accounting for 90% of the total node deviation. This allows us to quickly locate container B as the main root cause of the node deviation.

[0069] The association rule between cluster and node is quantified by calculating the proportion of the total resources of a node to the total resources of the cluster. Taking the cluster memory utilization deviation as an example: The total memory of a certain cluster (prod-cluster-01) is 512GB, of which the total memory of node A is 128GB, accounting for 25%, the total memory of node B is 256GB, accounting for 50%, and the total memory of node C is 128GB, accounting for 25%. The cluster memory deviation = node A deviation × 25% + node B deviation × 50% + node C deviation × 25%. If the cluster deviation is 8% and the deviation of node B is 14%, then the contribution of node B is 14% × 50% = 7%, accounting for 87.5% of the total deviation of the cluster. It can be located that node B is the main source of the cluster deviation.

[0070] In one embodiment, such as Figure 3 As shown, cloud-native monitoring data visualization methods also include:

[0071] Step S302: Collect container data, node data, and cluster data of the cloud-native environment to obtain system indicator data of the cloud-native environment; Step S304: Collect indicators corresponding to the business systems and business links carried by the cloud-native environment to obtain business indicator data of the cloud-native environment; Step S306: Collect log records of resource status changes within the K8s cluster of the cloud-native environment to obtain K8s event data of the cloud-native environment.

[0072] The above process corresponds to collecting system metric data, business metric data, and Kubernetes event data in a cloud-native environment. System metric data includes container data, node data, and cluster data. Container data includes Pod CPU utilization, memory usage, network inbound and outbound traffic, and disk I / O; node data includes average load of physical machines or virtual machines, GPU (Graphics Processing Unit) utilization, and network packet loss rate; cluster data includes Pod scheduling success rate, node availability, and resource quota utilization of the Kubernetes cluster. Container data and node data are obtained by accessing containers and nodes through an Exporter (metric collector) and through the Kubelet API (Kubelet...). Application Programming Interface (API) is used to obtain Pod lifecycle data; business metric data includes key metrics of business systems and business links carried by the cloud-native environment, such as order creation volume, payment success rate, and interface response time (P99 / P95 percentile) in e-commerce scenarios, and message sending volume and number of online users in social scenarios. These are collected through HTTP interfaces exposed by business systems or Kafka message queues. The collected data is in the format of key-value pairs with timestamps and stored as {timestamp:1620000000,metric:"order_count",value:1000}.

[0073] Kubernetes event data is a log recording of state changes of resources (such as Pods, Deployments, and Nodes) within the cluster. It is generated and stored by the Kubernetes API Server. The official Kubernetes client library Client-go (in Go) listens to the API Server's event interface. Specifically, it includes: initializing ClientSet: creating a connection with the API Server through the Kubernetes configuration file (such as ~ / .kube / config), calling the Watch method of the corev1.EventInterface interface to establish a long connection to receive the event stream in real time. Event types include ADDED (addition event), MODIFIED (modification event), and DELETED (deletion event); and filtering by FieldSelector to focus only on events related to resource scheduling and lifecycle.

[0074] This application provides a method for visualizing cloud-native monitoring data. To better understand the process of the above-mentioned method for visualizing cloud-native monitoring data, combined with... Figure 4 As shown below, the specific process of a cloud-native monitoring data visualization method of this application is described in detail, including the following steps:

[0075] Step S402: Collect system indicator data, business indicator data, and K8s event data in the cloud-native environment.

[0076] Step S404: Noise filtering is performed on the collected indicator data, and cloud-native special scenarios are identified based on K8s event data and scene labels are generated.

[0077] Step S406: Based on the real-time stream processing framework, the time-series prediction algorithm is integrated to allocate indicator weights according to the service SLA profile to generate a regular baseline, or to generate a temporary baseline in response to scenario tags.

[0078] Step S408: Based on the multi-scale knowledge graph, cross-scale deviation detection and root cause tracing are realized, and dynamic thresholds are generated based on the service SLA profile. The detection logic is adjusted in response to baseline changes, and the dynamic baseline, deviation detection results and tracing links are output.

[0079] The above process is jointly completed by a data acquisition module, an adaptive preprocessing module, a dynamic baseline generation module, a multi-scale bias detection module, and an output module, wherein:

[0080] The data acquisition module collects system metrics, business metrics, and Kubernetes event data in a cloud-native environment. The adaptive preprocessing module uses the Isolation Forest algorithm to detect instantaneous outliers and a sliding window for mean compensation on the collected metrics data. It also identifies special cloud-native scenarios based on Kubernetes event data and generates scenario labels. The dynamic baseline generation module uses the Flink (distributed stream processing framework) real-time stream processing framework, integrating the LSTM (Long Short-Term Memory) time-series prediction algorithm and attention mechanism to dynamically weight the preprocessed system metrics and business metrics according to the service SLA profile, generating a regular baseline. It also responds to the scenario labels from the adaptive preprocessing module, triggering temporary baseline adjustments. The multi-scale deviation detection module constructs a multi-scale knowledge graph based on containers, nodes, clusters, and business domains, and uses this knowledge graph to trace cross-scale deviations. It also generates dynamic detection thresholds based on the service SLA profile and responds to baseline changes from the dynamic baseline generation module. The output module visualizes the dynamic baseline, multi-scale deviation detection results, and deviation tracing links.

[0081] Furthermore, the data acquisition module is used to collect system metric data, business metric data, and Kubernetes event data in the cloud-native environment. System metric data includes container data, node data, and cluster data. Container data includes Pod CPU utilization, memory usage, network inbound and outbound traffic, and disk I / O; node data includes average load of physical machines or virtual machines, GPU utilization, and network packet loss rate; and cluster data includes Pod scheduling success rate, node availability, and resource quota utilization of the Kubernetes cluster. Container data and node data are obtained by accessing containers and nodes through the Exporter, and Pod lifecycle data is obtained through the Kubelet API.

[0082] Business metrics data includes key indicators related to business systems and business chains hosted in the cloud-native environment, such as order creation volume, payment success rate, and interface response time (P99 / P95 percentile) in e-commerce scenarios, and message sending volume and online user count in social scenarios. These are collected through HTTP interfaces exposed by business systems or Kafka message queues. The collected data is in the format of timestamped key-value pairs, stored as {timestamp:1620000000,metric:"order_count",value:1000}. K8s event data consists of log records of changes in the state of resources within the cluster (such as Pods, Deployments, and Nodes). These are generated and stored by the K8s API Server and are monitored through the official K8s client library Client-go (Go language). Specifically, this includes: initializing the ClientSet: creating a client set that interacts with the API through the K8s configuration file (e.g., ~ / .kube / config). The server connection calls the Watch method of the corev1.EventInterface interface to establish a long connection to receive event streams in real time. Event types include ADDED (addition event), MODIFIED (modification event), and DELETED (deletion event). It also uses FieldSelector to filter and focus only on events related to resource scheduling and lifecycle.

[0083] The data acquisition module transmits the collected data to the adaptive preprocessing module. The adaptive preprocessing module is used to clean and identify the scene of the collected data. The adaptive preprocessing module includes a noise filtering unit, a scene identification unit, a dynamic baseline generation unit, and a baseline update unit. Each unit specifically includes: The noise filtering unit uses the isolated forest algorithm to detect instantaneous outliers and uses a sliding window for mean compensation. The isolated forest model is trained using normal monitoring data from the past 30 days after removing known fault periods. The model contains 100 decision trees. The data collected by the data acquisition module is input into the trained isolated forest model. When the anomaly score of the data exceeds 0.7, it is judged and marked as noise. For example, null values ​​caused by agent failure or jump values ​​caused by network jitter, such as CPU utilization suddenly increasing from 10% to 90% for less than 1 second, are marked as noise data. The data is collected using a 3-point sliding window composed of one normal data point before and one before it. The mean is calculated to replace the noise value. For example, if the noise value is null, the previous value is 20%, and the subsequent value is 22%, it is padded to 21%. At the same time, the original noise data is retained in the log system for later model optimization and verification.

[0084] The scenario identification unit involves parsing Kubernetes event data, extracting event types and key parameters, and generating scenario tags based on a pre-configured cloud-native special scenario rule base. Parsing Kubernetes event data and extracting event types and key parameters: Kubernetes events are records of state changes of resources within the cluster (such as Pods, Deployments, and Nodes), generated by the Kubernetes API Server. The scenario identification unit first needs to convert these events into processable structured information. The parsing logic is as follows: Extracting the involvedObject field: This determines the resource type (kind), name (name), and namespace associated with the event, used to locate the affected service, such as "order-serviceDeployment under the prod namespace"; Extracting the reason field: This serves as the core identifier of the event type, such as "ScalingReplicaSet" corresponding to scaling up and down, and "ReplicaSetUpdated" corresponding to rolling updates; Extracting the message field: This contains specific operational details of the event, such as the number of Pods before and after scaling up and down, and the image version for rolling updates; Extracting the creationTimestamp field as the event trigger time; Because different types of Kubernetes events have unique key parameters, these are used for subsequent matching with the rule base. The extraction logic needs to combine the event reason and message fields and be implemented through regular expressions or structured parsing; it includes extracting scaling parameters, rolling update events, and Serverless service start / stop event parameters.

[0085] The extraction of scaling parameters includes identifying the scaling direction, quantity changes, and scaling ratio. For example, "up" in "Scaled up replica set..." indicates scaling up, and "down" in "Scaled down..." indicates scaling down. When the event cause is "ReplicaSetUpdated," indicating a rolling update of the Deployment, the new replica set information, update progress, and Pod replacement rate are extracted from the event details. The name of the newly created ReplicaSet is used to locate the updated resources. The update progress includes extracting the number of currently updated Pods and the target total number of Pods, calculated using the formula "number of updated Pods / target total number of Pods" to reflect the update coverage. When the event-associated resource is a "Function" defined by the Serverless framework, and the event cause is "Activated" or "Deactivated," the function name and instance quantity changes are extracted.

[0086] The rule base serves as the basis for scene recognition and stores trigger conditions for various cloud-native scenarios. These trigger conditions are determined based on extracted key parameters and employ a three-element structure of scene type, trigger condition, and judgment condition. Dynamic updates are supported through hot reloading in the configuration center. Scene conditions include ScaleOut (scaling up) and RollingUpdate (rolling update). Trigger conditions are used to associate the reason field of K8s events. For example, ScaleOut only matches ScalingReplicaSet events. Judgment conditions consist of multiple set threshold parameters, including the requirement that "ScaleOut" must simultaneously satisfy the scaling direction as up and the scaling ratio > 20%.

[0087] More specifically, based on a pre-configured cloud-native special scenario rule base, scenario tags are generated, including: identifying candidate rules by filtering rules associated with the reason field of the event from the rule base, such as the "ScalingReplicaSet" event only matching "ScaleOut" and "ScaleIn" rules; verifying whether the conditions are met by checking all the judgment conditions of each candidate rule. For example, the RollingUpdate rule must simultaneously meet the conditions of Pod replacement rate > 50% and the associated resource is Deployment; determining the scenario type by determining that if all the conditions of a rule are met, the event belongs to the scenario corresponding to that rule; if multiple rules are matched simultaneously, they are sorted by the priority of the scope of influence: cluster level > service level > container level, and the scenario with the highest priority is selected; and generating scenario tags for successfully matched scenarios, which include scenario type, start time, end time, involved resources, and key parameters.

[0088] The scene recognition unit can accurately analyze Kubernetes events, extract key parameters, and match scene rules, providing the dynamic baseline generation module with the core basis for when and how to adjust the baseline, thereby improving the scene adaptability of cloud-native monitoring. The dynamic baseline generation unit includes a data management subunit, a feature fusion and allocation subunit, and a baseline prediction and update unit. It generates dynamic baselines based on data processed by the noise filtering unit. Specifically, the data management subunit builds a real-time data stream processing pipeline based on the Flink framework, using Flink's state management function to save the most recent hour's metric data and intermediate calculation results, ensuring the continuity of baseline updates. The feature fusion and allocation subunit takes preprocessed system metrics (such as CPU and memory) and business metrics (such as order volume) as input features and calculates feature weights using an attention mechanism: using business metrics as queries and system metrics as keys / values, it calculates a correlation score using cosine similarity (e.g., the correlation score between order volume and payment service CPU utilization is 0.8), with higher scores resulting in greater weights.

[0089] The weights are dynamically adjusted based on the service SLA profile. The service SLA profile is predefined into four levels: P0 (core services, such as payment), P1 (important services, such as orders), P2 (general services, such as product details), and P3 (non-core services, such as logs). The initial weight of business indicators for P0 services is 60%, and the weight of system indicators is 40%. The initial weight of business indicators for P3 services is 15%, and the weight of system indicators is 85%.

[0090] The baseline prediction update unit is used to generate regular baselines and receive scene labels from the adaptive processing module to trigger the generation of temporary baselines. The system uses an LSTM time-series prediction model to generate a regular baseline. The model contains three hidden layers, each with 64 neurons. The input is feature data from the past hour, and the output is the predicted value of the indicator for the next 1-2 minutes. The predicted value is fused with the real-time collected current value using the formula: Baseline value = 0.7 × Predicted value + 0.3 × Current value, generating the regular baseline. When the indicator in the scene label received from the adaptive preprocessing module exceeds a set threshold, a scene-based baseline adjustment is triggered, generating a temporary baseline. For example, in the ScaleOut scenario, if the number of Pods increases beyond a set threshold, the temporary baseline = regular baseline × (1 - 0.2 × scaling ratio). For instance, if the scaling ratio is 0.5, the temporary baseline = regular baseline × 0.9. In the rolling update scenario, the temporary baseline = regular baseline × 1.1, tolerating indicator fluctuations during the update period. Based on the degree of data fluctuation, the baseline update frequency is dynamically set by calculating the indicator fluctuation amplitude in real time. The fluctuation amplitude = standard deviation / mean of time t, where t can be set to 5 minutes. Different update frequencies correspond to different fluctuation amplitude threshold ranges.

[0091] The multi-scale deviation detection module includes a knowledge graph construction unit, a cross-scale deviation detection unit, and a dynamic threshold generation unit. The knowledge graph construction unit builds a multi-scale knowledge graph based on containers, nodes, clusters, and business domains, and uses this knowledge graph to trace the source of cross-scale deviations. Specifically, the multi-scale knowledge graph includes: a definition of graph nodes: containing four levels of entities: containers (Pods), nodes (Nodes), clusters (Clusters), and business domains (BusinessDomains). Each graph node corresponds to a management or monitoring dimension of the cloud-native environment, forming a top-down node relationship from the lowest level (containers), to nodes, then to clusters, and finally to the business domain. The edges between graph nodes record the association rules of the metrics, and these rules are generated through training on historical data.

[0092] The lowest layer, the Pod, corresponds to a Pod or independent container in the Kubernetes environment. It is the smallest deployment unit of cloud-native applications and the most granular source of monitoring data, such as Pod CPU and memory usage. This data is used to clearly identify the container's ownership and identity, avoiding confusion with other containers. The middle layer, the Node, is the carrier of the container. It corresponds to the physical machine, virtual machine, or cloud server that runs the container, such as a Node in a Kubernetes cluster. It is a resource pool for containers, and its metrics (such as node CPU usage) are the aggregated results of all underlying container metrics. Node data is used for basic identification attributes, such as node name, node IP address, cluster name (such as "prod-cluster-01"), and node role (such as "master node" or "worker node"), to locate the node's position and function in the cluster.

[0093] Cluster layer nodes are aggregations of middle layer nodes, corresponding to a complete Kubernetes cluster or other container orchestration cluster. They contain multiple nodes, and their metrics (such as overall cluster CPU utilization) reflect the resource load status of the entire cluster. They include cluster name, cluster ID, cluster region (e.g., "East China Region 1"), and the number of nodes, which are used to clarify the scope and geographical affiliation of the cluster. Business domain layer nodes are logical units divided according to business functions. They classify multiple clusters or parts of services within a single cluster into corresponding business scenarios. For example, the "Payment Business Domain" includes all clusters and services that handle payment requests, and the "Order Business Domain" includes all clusters and services that handle order creation and modification. Their tag attributes are used to clarify the functional scope of the business domain, including the business domain name, the business line it belongs to, and the list of clusters it contains.

[0094] The relationships between edges connecting nodes in the knowledge graph are as follows: Business Domain → Cluster: One business domain edge corresponds to multiple cluster nodes. For example, the payment domain contains two clusters, "prod-cluster-01" and "prod-cluster-02," indicating that all resources and services of this cluster serve this business domain. Cluster → Node: One cluster edge corresponds to multiple nodes. For example, "prod-cluster-01" contains three nodes, "node-01," "node-02," and "node-03," indicating that these nodes are components of the cluster and are managed uniformly by the cluster. Node → Container: One node edge corresponds to multiple containers. For example, "node-01" contains two containers, "order-service-pod-01" and "pay-service-pod-01," indicating that these containers run on this node and consume the node's resources.

[0095] The contribution of the knowledge graph is calculated based on the resource share. The edges are the key to subsequent deviation tracing. The indicator deviation of the upper-level node = the indicator deviation of all lower-level related nodes × the resource share weight of the lower-level node to the upper-level node. The association rules between node and container computing nodes are quantified by calculating the proportion of container resource quota to the total resources of the node. Taking CPU utilization deviation as an example: the total CPU quota of a certain node (node-01) is 16 cores, of which container A has a CPU quota of 4 cores, accounting for 25%, container B has a CPU quota of 8 cores, accounting for 50%, and container C has a CPU quota of 4 cores, accounting for 25%. If the node CPU utilization deviation is 10%, meaning the actual utilization is 10% higher than the baseline, then: Node CPU deviation = Container A deviation × 25% + Container B deviation × 50% + Container C deviation × 25%. When a node deviation is detected, this formula can be used to deduce: If the deviation of container B is 18%, then its contribution to the node deviation is 18% × 50% = 9%, accounting for 90% of the total node deviation. This allows us to quickly locate container B as the main root cause of the node deviation.

[0096] The association rules between clusters and nodes are quantified by calculating the proportion of a node's total resources to the total cluster resources. Taking cluster memory utilization deviation as an example: A certain cluster (prod-cluster-01) has a total memory of 512GB, of which node A has a total memory of 128GB, accounting for 25%, node B has a total memory of 256GB, accounting for 50%, and node C has a total memory of 128GB, accounting for 25%. The cluster memory deviation = node A deviation × 25% + node B deviation × 50% + node C deviation × 25%. If the cluster deviation is 8% and node B's deviation is 14%, then node B's contribution is 14% × 50% = 7%, accounting for 87.5% of the total cluster deviation. Therefore, node B can be identified as the main source of the cluster deviation. Similarly, the association rules between clusters and nodes are quantified by calculating the proportion of a node's total resources to the total cluster resources.

[0097] The knowledge graph construction process includes: collecting basic identifier attributes and resource configurations of entities at each level, such as Pod name, node IP, business domain name, CPU quota, and total memory, through Kubernetes API and business configurations (e.g., the mapping between business domains and clusters); transforming the collected entity data into graph nodes in the order of container → node → cluster → business domain, and filling each node with basic identifier attributes and monitoring association attributes, such as filling the Deployment name for container nodes and the list of clusters contained for business domain nodes; and creating edges based on inclusion relationships: associating each business domain node with its contained cluster nodes, and associating each cluster node with its contained nodes. It associates each node with the container it runs on; calculates initial association rules: based on collected resource configurations (such as container CPU quota, total node CPU) or business traffic data (such as the proportion of business traffic carried by the cluster), it calculates the weight of each edge, such as the proportion of CPU of the container to the node, the proportion of traffic of the cluster to the business domain, as the initial quantitative association rules; the constructed knowledge graph can clearly present the hierarchical relationship of the cloud-native environment, and can also support the accurate calculation of upper-layer deviation → lower-layer root cause through quantitative rules, providing structured and computable core support for multi-scale deviation detection, and solving the problem that traditional independent scale detection cannot trace the source.

[0098] The cross-scale deviation detection unit calculates the deviation rate for each scale, and calculates the deviation rate between the actual value of the indicator and the dynamic baseline in real time. Deviation rate = |actual value - baseline value| / baseline value × 100%. Cross-scale detection is performed: when the deviation rate of the upper-level scale (e.g., cluster) exceeds the threshold, the unit automatically queries the lower-level related nodes of the knowledge graph, calculates the deviation contribution of each lower-level node, and uses the contribution = lower-level node deviation rate × resource proportion. Candidate root cause nodes are located by sorting by contribution. This process is repeated until the container-level root cause is located, such as a Pod whose CPU deviation contribution accounts for 70% of the total node deviation. The dynamic threshold generation unit sets thresholds based on the service SLA profile and the normal deviation distribution (95th percentile) over the past 30 days: P0 service deviation threshold = 3%-5% (e.g., if the CPU deviation of the payment service exceeds 5%, an alarm is triggered); P1 service = 8%-10%; P2 service = 15%-20%; P3 service = 25%-30%. The thresholds can be manually fine-tuned (±2%) via a web interface. This is achieved through REST... The API works in conjunction with the dynamic baseline generation module. When the baseline module switches to a temporary baseline, the detection module adjusts the threshold synchronously. For example, during the period when the temporary baseline is in effect, the threshold is relaxed to 1.2 times the original threshold. The root cause tracing results of the detection module are fed back to the baseline module in real time to optimize the feature weights of the service to which the container belongs.

[0099] In the above process, adaptive preprocessing is first used to filter data noise using an isolated forest combined with a sliding window, and K8s event identification is performed to identify scenarios such as scaling up and down. Then, based on Flink real-time stream processing and LSTM prediction, dynamic baselines adapted to the scenarios are generated by combining business indicators and service SLA dynamic weights. Finally, relying on a multi-scale knowledge graph of containers-nodes-clusters-business domains, cross-scale deviation tracing is achieved according to quantitative association rules. Combined with dynamic SLA thresholds, false alarms and missed alarms are reduced. Each module forms a closed loop through scenario label synchronization and tracing results feedback to ensure that monitoring is accurately adapted to the cloud-native dynamic environment.

[0100] Through the above process, addressing the issues of delayed dynamic baseline response and detachment from business needs, unrelated multi-scale detection with high false positives, and data noise interference and poor scenario adaptability, a full-link solution is formed through the collaboration of multiple modules. By combining Flink real-time stream processing and LSTM time series prediction, the baseline update frequency is optimized to solve the delay problem. At the same time, a service SLA profile is introduced, and business and system indicator weights are allocated according to service level to bind the baseline with business value. Furthermore, through the container → node → cluster → business domain knowledge graph, association rules are quantified to achieve cross-scale root cause tracing, and dynamic thresholds are set based on SLA to avoid false positives and false negatives. In addition, an isolated forest combined with sliding window mean is used to filter noise, and scene labels are generated by combining K8s events to trigger temporary baseline adjustments to adapt to special cloud-native scenarios. This improves baseline response speed, reduces baseline deviation rate in business-related scenarios, and reduces the time for multi-scale deviation root cause investigation. A collaborative closed loop is formed between modules through scene label synchronization and feedback of tracing results.

[0101] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0102] Based on the same inventive concept, this application also provides a cloud-native monitoring data visualization device for implementing the cloud-native monitoring data visualization method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more cloud-native monitoring data visualization device embodiments provided below can be found in the limitations of the cloud-native monitoring data visualization method described above, and will not be repeated here.

[0103] In one exemplary embodiment, such as Figure 5 As shown, a cloud-native monitoring data visualization device is provided, including: a scene label generation module 501, a baseline generation module 502, a dynamic detection threshold generation module 503, and a result visualization module 504, wherein:

[0104] The scene tag generation module 501 is used to generate scene tags for the cloud-native environment based on pre-collected cloud-native monitoring data; the cloud-native monitoring data includes system indicator data and business indicator data.

[0105] The baseline generation module 502 is used to allocate dynamic weights to system indicator data and business indicator data based on a preset data processing algorithm to generate a corresponding regular baseline; and to dynamically adjust the regular baseline based on scene labels to obtain a temporary baseline.

[0106] The dynamic detection threshold generation module 503 is used to determine the deviation detection results and deviation tracing links of cloud-native monitoring data based on a pre-built multi-scale knowledge graph associated with cloud-native monitoring data, and generate corresponding dynamic detection thresholds in combination with preset service evaluation standards.

[0107] The results visualization module 504 is used to visualize the target dynamic baseline, target deviation detection results, and target traceability link in the cloud-native environment based on the temporary baseline, deviation detection results, deviation tracing link, and dynamic detection threshold.

[0108] Furthermore, in one embodiment, the scene tag generation module 501 is also used to determine the resource type, event type, event processing details and event trigger time associated with the K8s event data based on the K8s event data included in the pre-collected cloud-native monitoring data; and to generate scene tags for the cloud-native environment based on the resource type, event type, event processing details and event trigger time associated with the K8s event data according to the preset rule base.

[0109] Furthermore, in one embodiment, the scene tag generation module 501 is also used to filter candidate rules corresponding to resource types, event types, event processing details and event triggering times associated with K8s event data based on a preset rule base; when all the judgment conditions of the candidate rules meet the preset thresholds of the preset rule base, the scene corresponding to the K8s event data is determined, and scene tags containing scene type, start time, end time, involved resources and key parameters are generated.

[0110] Furthermore, in one embodiment, the baseline generation module 502 is also used to construct a real-time data stream processing pipeline based on a preset real-time stream processing framework included in the preset data processing algorithm, and to save the system indicator data under a preset duration; to obtain the correlation score between the system indicator data and the business indicator data through the attention mechanism included in the preset data processing algorithm, and to assign dynamic weights to the system indicator data and the business indicator data in combination with the preset service evaluation criteria included in the preset data processing algorithm, so as to obtain weighted system indicator data and weighted business indicator data; and to process the weighted system indicator data and weighted business indicator data based on the time series prediction algorithm included in the preset data processing algorithm, so as to generate the corresponding regular baseline.

[0111] Furthermore, in one embodiment, the result visualization module 504 is also used to obtain in real time the deviation rate between the actual value of each scale indicator and the corresponding value of the temporary baseline in the pre-constructed multi-scale knowledge graph associated with cloud-native monitoring data. If the deviation rate exceeds a preset threshold, the deviation contribution degree corresponding to the node in the multi-scale knowledge graph is obtained. Candidate root cause nodes are located according to the order of deviation contribution degree, and the above process is repeated until the deviation detection result and deviation tracing link of the cloud-native monitoring data are determined.

[0112] Furthermore, in one embodiment, the scene tag generation module 501 is also used to collect container data, node data, and cluster data in the cloud-native environment to obtain system indicator data of the cloud-native environment; collect indicators corresponding to the business systems and business links carried by the cloud-native environment to obtain business indicator data of the cloud-native environment; and collect log records of resource status changes in the K8s cluster of the cloud-native environment to obtain K8s event data of the cloud-native environment.

[0113] The modules in the aforementioned cloud-native monitoring data visualization device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0114] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 6As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs in the non-volatile storage media to run. The database stores visualization data for cloud-native monitoring data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a method for visualizing cloud-native monitoring data.

[0115] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0116] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0117] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0118] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0119] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, visualized data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0120] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0121] The technical features of the above embodiments can be combined in any way. For the sake of brevity, 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.

[0122] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for visualizing cloud-native monitoring data, characterized in that, The method includes: Based on pre-collected cloud-native monitoring data of the cloud-native environment, scene tags for the cloud-native environment are generated; the cloud-native monitoring data includes system indicator data and business indicator data. Based on a preset data processing algorithm, dynamic weights are assigned to the system indicator data and the business indicator data to generate corresponding regular baselines; and the regular baselines are dynamically adjusted based on the scene labels to obtain temporary baselines. Based on a pre-built multi-scale knowledge graph associated with the cloud-native monitoring data, the deviation detection results and deviation tracing links of the cloud-native monitoring data are determined, and corresponding dynamic detection thresholds are generated in combination with preset service evaluation standards. Based on the temporary baseline, the deviation detection results, the deviation tracing link, and the dynamic detection threshold, the target dynamic baseline, target deviation detection results, and target tracing link of the cloud-native environment are visualized.

2. The method according to claim 1, characterized in that, The method further includes: Based on the K8s event data included in the pre-collected cloud-native monitoring data, the resource type, event type, event processing details, and event trigger time associated with the K8s event data are determined. Based on the preset rule base and the resource type, event type, event processing details, and event trigger time associated with the K8s event data, the scene tag of the cloud-native environment is generated.

3. The method according to claim 2, characterized in that, The process of generating scene tags for the cloud-native environment based on the resource type, event type, event processing details, and event trigger time associated with the K8s event data using a preset rule base includes: Based on a preset rule base, candidate rules are selected corresponding to the resource type, event type, event processing details, and event trigger time associated with the K8s event data. If all the judgment conditions of the candidate rules meet the preset threshold of the preset rule base, the scene corresponding to the K8s event data is determined, and the scene tag containing scene type, start time, end time, resources involved and key parameters is generated.

4. The method according to claim 1, characterized in that, The step of assigning dynamic weights to the system indicator data and the business indicator data based on a preset data processing algorithm to generate a corresponding conventional baseline includes: Based on the preset data processing algorithm, a preset real-time stream processing framework is constructed to build a real-time data stream processing pipeline and save the system indicator data for a preset duration. The system indicator data and the business indicator data are obtained by using the attention mechanism included in the preset data processing algorithm. The system indicator data and the business indicator data are then assigned dynamic weights by combining the preset service evaluation criteria included in the preset data processing algorithm, resulting in weighted system indicator data and weighted business indicator data. Based on the time-series prediction algorithm included in the preset data processing algorithm, the weighted system indicator data and the weighted business indicator data are processed to generate the corresponding conventional baseline.

5. The method according to claim 1, characterized in that, The method of determining the deviation detection results and deviation tracing links of the cloud-native monitoring data based on a pre-constructed multi-scale knowledge graph associated with the cloud-native monitoring data includes: In real time, the deviation rate between the actual value of each scale indicator and the corresponding value of the temporary baseline in the pre-constructed multi-scale knowledge graph associated with the cloud-native monitoring data is obtained. If the deviation rate exceeds a preset threshold, the deviation contribution degree of the node corresponding to the multi-scale knowledge graph is obtained. Candidate root cause nodes are located according to the ranking of the deviation contribution, and the above process is repeated until the deviation detection result and deviation tracing link of the cloud-native monitoring data are determined.

6. The method according to claim 1, characterized in that, The method further includes: Collect container data, node data, and cluster data from the cloud-native environment to obtain system indicator data for the cloud-native environment; Collect metrics corresponding to the business systems and business links carried by the cloud-native environment to obtain business metric data of the cloud-native environment; Collect log records of resource status changes within the K8s cluster in the cloud-native environment to obtain K8s event data for the cloud-native environment.

7. A visualization device for cloud-native monitoring data, characterized in that, The device includes: The scene tag generation module is used to generate scene tags for the cloud-native environment based on pre-collected cloud-native monitoring data; the cloud-native monitoring data includes system indicator data and business indicator data. The baseline generation module is used to allocate dynamic weights to the system indicator data and the business indicator data based on a preset data processing algorithm to generate a corresponding regular baseline; and to dynamically adjust the regular baseline based on the scene label to obtain a temporary baseline. The dynamic detection threshold generation module is used to determine the deviation detection results and deviation tracing links of the cloud-native monitoring data based on a pre-built multi-scale knowledge graph associated with the cloud-native monitoring data, and generate corresponding dynamic detection thresholds in combination with preset service evaluation standards. The results visualization module is used to visualize the target dynamic baseline, target deviation detection results, and target source tracing link of the cloud-native environment based on the temporary baseline, the deviation detection results, the deviation tracing link, and the dynamic detection threshold.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images