Method and system for software performance analysis in a virtualized environment with cross-layer data correlation

Abstract

This invention discloses a method and system for software performance analysis in a virtualized environment with cross-layer data association. The method includes: building a data acquisition system and completing data standardization processing; setting initial thresholds for each indicator by combining historical performance data and business SLAs; using LSTM to predict short-term business load and correct the load coefficient; integrating a custom time factor to generate dynamic thresholds and periodically synchronizing them to the alarm system; based on a stream processing framework, associating three-layer performance data with ternary identifiers; triggering anomalies according to the dynamic thresholds; determining the anomaly level by combining the business scenario dependency graph; optimizing the inference tree through reinforcement learning to locate the root cause; recording logs containing the anomaly propagation path; extracting affected business and user data; calculating the business impact coefficient; generating an analysis report with priority for repair suggestions; and triggering alarms and order dispatching in a closed-loop push for high-impact anomalies. This provides a reliable basis for timely detection of performance problems.

Description

Technical Field

[0001] This invention belongs to the field of virtualization testing technology, and more specifically, relates to a method and system for software performance analysis in a virtualized environment with cross-layer data association. Background Technology

[0002] In virtualized environments, software systems often adopt a layered architecture, encompassing multiple layers such as infrastructure, middleware, and application. Performance data generated at each layer is characterized by its dispersed sources and diverse formats. As business complexity increases, cross-layer performance data correlation analysis becomes crucial for ensuring stable software operation; however, current technologies still face numerous practical challenges in data processing and anomaly management.

[0003] First, existing performance data collection and processing methods lack unified standards. Performance data at different levels are often collected independently without establishing effective correlation markers, resulting in severe data fragmentation and making it difficult to form a complete end-to-end performance view. Furthermore, the collected data has not undergone systematic standardization processing, leading to significant differences in units of measurement. This directly affects the accuracy of subsequent analysis results and fails to provide a reliable data foundation for anomaly detection.

[0004] Secondly, the setting and triggering mechanisms for performance anomaly thresholds have limitations. Most systems use fixed thresholds for anomaly monitoring, without considering the dynamic changes and time-period characteristics of business load. When business is at its peak or during special periods, fixed thresholds are prone to false alarms or missed alarms, either leading to a waste of operational resources or missing the best opportunity to handle critical performance issues, making it difficult to adapt to complex and ever-changing business scenarios.

[0005] Furthermore, the root cause analysis and business impact assessment of performance anomalies are inefficient. Current technologies, after triggering anomalies, largely rely on manual investigation or simple correlation analysis to locate the root cause, lacking deep correlation and intelligent reasoning capabilities across data layers, resulting in lengthy root cause analysis processes. Simultaneously, the extent of business impact cannot be quickly quantified after anomalies occur, making it difficult to determine repair priorities. This hinders operations personnel from efficiently allocating resources, potentially leading to increased business losses.

[0006] Furthermore, the current performance analysis process lacks a complete closed loop. From data collection and anomaly triggering to root cause identification and problem remediation, the links between each stage are loosely connected, and a standardized analysis and response mechanism has not been formed. Especially in the handling of high-impact anomalies, it is impossible to quickly trigger alarms and dispatch orders, which further prolongs the problem resolution cycle and adversely affects the stability of the software system and the user experience.

[0007] Against this backdrop, there is an urgent need for a performance analysis solution that can achieve cross-layer data association, precise dynamic threshold triggering, intelligent root cause localization, and efficient business impact assessment, in order to solve the pain points of existing technologies, improve the efficiency and accuracy of software performance management in virtualized environments, and ensure stable business operation. Summary of the Invention

[0008] This invention aims to solve problems such as data fragmentation, rigid thresholds, inefficient root cause identification, and insufficient business impact assessment in existing technologies. It achieves standardized collection and dynamic correlation of performance data across the entire chain, accurately triggers anomalies and intelligently locates root causes, and quantifies business impact to form a closed loop of "collection-analysis-location-repair", thereby improving software performance management efficiency and business stability.

[0009] To address the aforementioned deficiencies or improvement needs of existing technologies, as a first aspect of this invention, the present invention provides a method for software performance analysis in a virtualized environment with cross-layer data association, comprising:

[0010] S1. Build a system including an adaptive data collection scheduler and a "three-element identifier + business scenario tag" generation module, start full-link performance data collection, and complete the standardization processing of the collected data;

[0011] S2. Combine historical performance data and business SLA to set initial thresholds for each performance indicator, introduce the LSTM method to predict short-term business load to correct the load factor, integrate a custom time factor to generate dynamic thresholds, and periodically synchronize the dynamic thresholds to the alarm system.

[0012] S3. Based on the stream processing framework, the performance data of the infrastructure layer, middleware layer and application layer are associated with the "ternary identifier" as the association key. After an abnormal event is triggered according to the dynamic threshold, the abnormal level is determined by combining the business scenario dependency graph. The root cause of the performance bottleneck is located by the inference tree optimized by reinforcement learning, and logs containing the abnormal propagation path are recorded.

[0013] S4. Extract relevant business and user data affected by performance issues, calculate the business impact coefficient, generate a performance analysis report that includes priority ranking of repair suggestions, display the analysis results in an interactive visualization manner, and trigger a closed-loop "alarm-dispatch" push for high-impact anomalies.

[0014] Furthermore, the adaptive acquisition scheduler in S1 is configured to dynamically adjust the acquisition frequency of performance data according to the business load: increase the acquisition frequency in high-concurrency business scenarios to ensure the real-time performance and precision of key performance indicators; reduce the acquisition frequency during low-load periods to reduce system resource consumption while meeting analysis needs, and achieve a dynamic balance between acquisition efficiency and resource consumption.

[0015] Furthermore, the "three-element identifier + business scenario tag" generation module in S1 specifically comprises:

[0016] When a user request enters the system, a three-element identifier is automatically generated and injected, which includes a unique link ID configured to track the entire request flow, a timestamp configured to associate time-series data, and a service instance ID configured to locate a specific service node.

[0017] At the same time, the system automatically matches and attaches business scenario tags based on the corresponding business interface of the request, so that the full-link performance data can be associated across layers through the three-element identifier and can be directly associated with specific business scenarios through the business scenario tags.

[0018] Furthermore, the specific process of standardizing the collected data in S1 is as follows:

[0019] For the performance data collected from different layers and dimensions in the infrastructure layer, middleware layer, and application layer, the Z-Score standardization method is first used to perform a unified transformation to eliminate the difference in dimensions. On this basis, the isolated forest method is combined to identify instantaneous outliers, and normal data from adjacent time periods in the same link are used to smooth them. Finally, standardized data that meets the requirements of subsequent cross-layer data association and dynamic threshold calculation is output.

[0020] Furthermore, the method for correcting the load factor in S2 is as follows:

[0021] Let the LSTM algorithm predict the future The predicted business load for the time period is The standardized historical load data sequence for the same period is , Given the historical data sample size, calculate the deviation rate series between the predicted value and the historical data:

[0022] ,

[0023] Take the deviation rate sequence The median is Combined with the number of link nodes in the business scenario dependency graph The corrected load factor is obtained through the formula. :

[0024] ,

[0025] in, Standardized results of linked historical data The relationship between business scenarios and dependencies is considered; the greater the deviation between predicted load and historical data, or the more complex the data link, the more important it is to consider these factors. The value is reduced to make the dynamic threshold more sensitive to adapt to high-risk scenarios.

[0026] Furthermore, the calculation method for the dynamic threshold in S2 is as follows:

[0027] Let the initial threshold set based on historical data and business SLA be... The upper limit of the historical normal fluctuation range of the standardized indicator is That is, the 95th percentile of the standardized value in historical normal data corresponds to the original value, combined with the corrected load factor. and custom time factors ;

[0028] Calculate the dynamic threshold using the formula. :

[0029] ,

[0030] in, The standardized processing results of historical data of related indicators The associated load factor correction logic adjusts the denominator when load fluctuations are large or during high load periods. The term decreases, resulting in Towards To increase the normal threshold range and avoid false alarms under high load; conversely, to increase the threshold range by moving closer to the threshold. Towards Shrink to improve anomaly sensitivity under low load, and achieve deep linkage with historical data characteristics, real-time load and time period.

[0031] Furthermore, the specific method for root cause localization in S3 is as follows:

[0032] After an abnormal event is triggered by a dynamic threshold, the set of abnormal indicators in the three layers of performance data associated with the "ternary identifier" is as follows: , The number of abnormal indicators is represented by the deviation between the actual value of each indicator and its corresponding dynamic threshold. , This is the dynamic threshold for the indicator. For the first The actual value of each abnormal indicator;

[0033] Based on the business scenario dependency graph, define the direct correlation weights between metrics. If the indicator Direct impact but Otherwise, the value is 0. Calculate the anomalous propagation breadth of each indicator. :

[0034] ,

[0035] Historical root cause frequency of each metric in the reasoning tree optimized by reinforcement learning This refers to the number of times a certain indicator has acted as a root cause in historical anomalies, calculated using a formula to determine the root cause probability. :

[0036] ,

[0037] in, Associate the dynamic threshold calculation results. Related business scenarios rely on the relationships within the graph. The reinforcement learning optimization process of the inference tree; taking The indicator corresponding to the maximum value is taken as the root cause. If there are upstream related indicators for this indicator, the above calculation is repeated for the upstream indicators until the root cause is located, so as to achieve linkage with the severity of the anomaly, the business link, and the historical root cause pattern.

[0038] Furthermore, the calculation method for the business impact coefficient in S4 is as follows:

[0039] Let the duration of service interruption due to performance issues be... The number of transactions per unit time for the affected business is The number of affected users is Combine the business link levels associated with the identified root cause indicators. The infrastructure layer has a link level of 1, and the application layer has a level of 3. The higher the level, the closer it is to the business. The historical normal completion rate of the business scenario is also included. This refers to the percentage of business operations successfully completed without performance issues; the business impact coefficient is calculated using a formula. :

[0040] ,

[0041] in, and Related extracted business data, Linked extracted user data, For business scenarios that rely on the graph's link structure Associate with historical business operation data; the longer the business interruption time, the larger the transaction volume, the more affected users, the higher the link level, or the higher the historical completion rate, the more likely it is to cause disruption. The higher the value, the more it can be used to prioritize repair recommendations. The higher the value of the performance problem, the higher its repair suggestion will be ranked in the report, and at the same time trigger the "alarm-dispatch" closed loop push, realizing deep linkage with business losses, user scope and link correlation.

[0042] As a second aspect of the present invention, a software performance analysis system for cross-layer data association in a virtualized environment is also provided, comprising:

[0043] The data acquisition system building unit is used to build a system including an adaptive acquisition scheduler and a "three-element identifier + business scenario tag" generation module, start full-link performance data acquisition, and complete the standardization processing of the acquired data.

[0044] The dynamic threshold generation unit is used to set initial thresholds for each performance indicator by combining historical performance data and business SLA, introduce the LSTM method to predict short-term business load to correct the load coefficient, integrate a custom time factor to generate dynamic thresholds, and periodically synchronize the dynamic thresholds to the alarm system.

[0045] The root cause localization unit is used to associate performance data of the infrastructure layer, middleware layer and application layer based on the stream processing framework and with "ternary identifier" as the association key. After triggering an abnormal event according to the dynamic threshold, it determines the abnormal level by combining the business scenario dependency graph, locates the root cause of the performance bottleneck through the inference tree optimized by reinforcement learning, and records logs containing the abnormal propagation path.

[0046] The results report generation unit is used to extract relevant business and user data affected by performance issues, calculate the business impact coefficient, generate a performance analysis report that includes priority ranking of repair suggestions, display the analysis results in an interactive and visual way, and trigger a closed-loop "alarm-dispatch" push for high-impact anomalies.

[0047] As a third aspect of the invention, a computer-readable storage medium is also provided, on which a computer program is stored, which is executed by a processor of any step of the software performance analysis method in a virtualized environment with cross-layer data association.

[0048] In summary, compared with the prior art, the above-described technical solutions conceived by this invention can achieve the following beneficial effects:

[0049] 1. The software performance analysis method for cross-layer data association in a virtualized environment of the present invention establishes a system containing an adaptive acquisition scheduler and a "three-element identifier + business scenario tag" generation module to initiate full-link performance data acquisition and complete standardized processing, thereby achieving unified and standardized management of multi-layer performance data. This technical feature eliminates the dimensional differences between infrastructure, middleware, and application layer data, making performance data from different sources comparable and correlated. This lays the foundation for subsequent cross-layer data association analysis, avoids analytical biases caused by inconsistent data formats, improves the efficiency and accuracy of data preprocessing, and ensures that subsequent analysis stages can be conducted based on high-quality, standardized data.

[0050] 2. The software performance analysis method in a virtualized environment with cross-layer data association of the present invention combines historical performance data with business SLA to set an initial threshold, introduces the LSTM method to predict short-term business load and correct the load coefficient, integrates a custom time factor to generate a dynamic threshold and synchronizes it to the alarm system, thus constructing a dynamic and accurate threshold system. This technical feature allows the threshold to be dynamically adjusted with changes in business load and time period, avoiding the problem of false alarms or missed alarms when fixed thresholds are used during business fluctuations. This enables the alarm system to more accurately trigger anomaly alerts in accordance with actual business scenarios, improves the sensitivity and accuracy of performance anomaly detection, and provides a reliable basis for timely detection of performance problems.

[0051] 3. The software performance analysis method for cross-layer data association in a virtualized environment of this invention associates three levels of performance data using a "ternary identifier" based on a stream processing framework. It determines the anomaly level by combining dynamic thresholds and business scenario dependency graphs, locates the root cause using a reinforcement learning-optimized inference tree, extracts affected data to calculate business impact coefficients, and generates a report with repair priorities, forming a complete analysis chain of "data association - anomaly determination - root cause location - impact assessment - report output". This technical feature enables deep cross-layer data association and accurate analysis of performance issues throughout the entire process. It can not only quickly locate the root cause of performance bottlenecks but also clarify the degree of business impact and provide priority repair suggestions, helping operations and maintenance personnel efficiently handle performance issues and reduce the impact of performance failures on business and users. Attached Figure Description

[0052] Figure 1 This is a flowchart of a software performance analysis method for cross-layer data association in a virtualized environment, according to an embodiment of the present invention.

[0053] Figure 2 This is a diagram illustrating the integrated architecture for network security and performance analysis in a data center private cloud area, according to an embodiment of the present invention.

[0054] Figure 3 This is a schematic diagram of the system units in an embodiment of the present invention. Detailed Implementation

[0055] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Furthermore, the technical features involved in the various embodiments of this invention described below can be combined with each other as long as they do not conflict with each other.

[0056] Example 1

[0057] Please refer to Figure 1 This embodiment 1 provides a software performance analysis method for cross-layer data association in a virtualized environment, including:

[0058] S1. Build a system including an adaptive data collection scheduler and a "three-element identifier + business scenario tag" generation module, start full-link performance data collection, and complete the standardization processing of the collected data;

[0059] S2. Combine historical performance data and business SLA to set initial thresholds for each performance indicator, introduce the LSTM method to predict short-term business load to correct the load factor, integrate a custom time factor to generate dynamic thresholds, and periodically synchronize the dynamic thresholds to the alarm system.

[0060] S3. Based on the stream processing framework, the performance data of the infrastructure layer, middleware layer and application layer are associated with the "ternary identifier" as the association key. After an abnormal event is triggered according to the dynamic threshold, the abnormal level is determined by combining the business scenario dependency graph. The root cause of the performance bottleneck is located by the inference tree optimized by reinforcement learning, and logs containing the abnormal propagation path are recorded.

[0061] S4. Extract relevant business and user data affected by performance issues, calculate the business impact coefficient, generate a performance analysis report that includes priority ranking of repair suggestions, display the analysis results in an interactive visualization manner, and trigger a closed-loop "alarm-dispatch" push for high-impact anomalies.

[0062] This embodiment 1 further elaborates on the above steps.

[0063] (1) Data acquisition system setup

[0064] In software performance management within a virtualized environment, building an efficient data acquisition and processing system is fundamental to achieving accurate performance analysis. This system first needs to include an adaptive acquisition scheduling mechanism and tag generation capabilities. Through collaborative operation, it completes the acquisition and standardized processing of performance data across the entire value chain, laying a solid data foundation for subsequent cross-layer correlation analysis.

[0065] The adaptive data acquisition scheduling mechanism addresses the shortcomings of traditional fixed-frequency data acquisition. In real-world business scenarios, system load exhibits dynamic changes. During peak periods, business requests are dense, and performance metrics fluctuate dramatically. If a fixed-frequency acquisition is still used, critical performance inflection points are easily missed. Conversely, during low-load periods, metric changes are gradual, and excessively high acquisition frequencies only increase system resource consumption. By dynamically adjusting the acquisition frequency based on business load, the mechanism can increase acquisition density in high-concurrency scenarios, ensuring real-time capture of subtle changes in core metrics and providing data support for quickly locating sudden performance issues. Simultaneously, it can automatically reduce acquisition intensity during low-load periods, meeting basic analysis needs while reducing the consumption of CPU, memory, and other resources, preventing the acquisition process from becoming a new performance burden. This achieves the optimal balance between data integrity and system lightweighting.

[0066] The construction of an identification and tagging system addresses the practical pain points of difficult cross-layer data association and weak business mapping. In complex layered architectures, performance data is scattered across multiple layers such as infrastructure, middleware, and applications. The lack of a unified identifier leads to data fragmentation, making it difficult to trace the performance of the entire chain. By automatically generating a combined identifier for each request, including a unique link identifier, a timestamp, and a service node identifier, full-path tracing from request initiation to response completion can be achieved. This allows data scattered across layers to be aggregated according to the link, clearly presenting the propagation path of performance bottlenecks. At the same time, scenario tags, such as transaction and login, are automatically attached to the corresponding business interface of the request, enabling technical performance data to be directly associated with specific business scenarios. This solves the problem of the disconnect between technical indicators and business value in traditional performance analysis, providing a direct basis for subsequent assessment of the actual impact of performance issues on the business.

[0067] Data standardization is a crucial step in eliminating data silos and ensuring the accuracy of analysis. Performance data at different levels often have different units of measurement; for example, CPU utilization is measured as a percentage, while response time is measured in milliseconds. These differences prevent direct comparison and analysis of cross-level data. Through unified standardization transformation, various types of data can be mapped to a consistent analytical dimension, making cross-level performance comparison possible. Meanwhile, outliers inevitably arise during data collection due to network jitter and momentary equipment failures. Directly using such data for analysis can distort the results. By introducing anomaly identification and correction mechanisms, outlier data can be effectively filtered or smoothed, ensuring that the output performance data conforms to a unified standard and accurately reflects the system's operating status, providing high-quality data input for subsequent dynamic threshold calculations and cross-level correlation analysis.

[0068] (2) Dynamic threshold generation

[0069] In software performance management within virtualized environments, building a threshold system that adapts to business dynamics is key to improving the accuracy of anomaly detection. This process begins by setting basic standards based on historical performance data and business SLAs, and then uses intelligent prediction and time-based feature optimization to create dynamically changing thresholds that are synchronized to the alarm system, fundamentally solving the pain point that traditional fixed thresholds are unable to cope with business fluctuations.

[0070] Traditional fixed threshold modes often have two major problems: First, during peak business periods when load surges, fixed thresholds can easily misjudge normal fluctuations as anomalies, leading to a flood of alarms; second, during low-load periods, thresholds are too lenient, making it difficult to capture early, subtle anomalies and causing missed alarms. Setting initial thresholds based on historical data and business SLAs can both anchor the baseline for normal system operation and meet the minimum performance requirements of the business, providing a reasonable starting point for dynamic threshold adjustments and avoiding unrealistic threshold settings.

[0071] By introducing business load prediction and scenario-specific optimized thresholds, the system can accurately adapt to load changes. Intelligent algorithms predict short-term business load, compare it with historical data to identify fluctuations, and then dynamically adjust the load coefficient based on the complexity of the business chain—the more complex the chain, the higher the risk of anomaly propagation. When the predicted load deviates significantly from historical norms or the chain is complex, the threshold becomes more sensitive, ensuring that anomalies in high-risk scenarios are not missed; conversely, it remains moderately lenient, reducing invalid alarms in low-risk scenarios. This adjustment solves the problem of traditional thresholds lagging in responding to load changes, ensuring that anomaly judgment always matches the business risk level.

[0072] Specifically, the method for correcting the load factor is as follows:

[0073] Let the LSTM algorithm predict the future The predicted business load for the time period is The standardized historical load data sequence for the same period is , Given the historical data sample size, calculate the deviation rate series between the predicted value and the historical data:

[0074] ,

[0075] Take the deviation rate sequence The median is Combined with the number of link nodes in the business scenario dependency graph The corrected load factor is obtained through the formula. :

[0076] ,

[0077] in, Standardized results of linked historical data The relationship between business scenarios and dependencies is considered; the greater the deviation between predicted load and historical data, or the more complex the data link, the more important it is to consider these factors. The value is reduced to make the dynamic threshold more sensitive to adapt to high-risk scenarios.

[0078] The final dynamic threshold is generated by incorporating time factors to better align with the time patterns of business operations. Business characteristics vary across different time periods; for example, the load patterns during e-commerce promotional periods and company commuting hours are fixed, and fixed thresholds cannot adapt to these cyclical fluctuations. By customizing time factors, the threshold is appropriately relaxed during peak hours to avoid false alarms triggered by normal traffic growth, and tightened during off-peak hours to improve the ability to detect potential problems. Specifically, the dynamic threshold is calculated as follows:

[0079] Let the initial threshold set based on historical data and business SLA be... The upper limit of the historical normal fluctuation range of the standardized indicator is That is, the 95th percentile of the standardized value in historical normal data corresponds to the original value, combined with the corrected load factor. and custom time factors ;

[0080] Calculate the dynamic threshold using the formula. :

[0081] ,

[0082] in, The standardized processing results of historical data of related indicators The associated load factor correction logic adjusts the denominator when load fluctuations are large or during high load periods. The term decreases, resulting in Towards To increase the normal threshold range and avoid false alarms under high load; conversely, to increase the threshold range by moving closer to the threshold. Towards Shrink to improve anomaly sensitivity under low load, and achieve deep linkage with historical data characteristics, real-time load and time period.

[0083] After the dynamic threshold is periodically synchronized to the alarm system, it ensures that the alarm standards are always synchronized with the current business status. This reduces the burden on maintenance personnel to handle invalid alarms and ensures that real anomalies are captured in a timely manner, laying the foundation for rapid response to performance issues.

[0084] (3) Root cause localization

[0085] In software performance management in virtualized environments, cross-layer data correlation analysis and root cause localization leverage a stream processing framework. Using "ternary identifiers" as the core link, it integrates performance data from various levels. After an anomaly occurs, it combines business dependencies and intelligent reasoning to pinpoint the root cause of the problem, fundamentally solving the pain points of data isolation and delayed localization in traditional analysis.

[0086] The combination of stream processing frameworks and "ternary identifiers" breaks down the hierarchical barriers of performance data. Performance data at the infrastructure, middleware, and application layers was previously stored in a scattered manner, making it difficult to form a complete performance view. Through "ternary identifiers"—comprising a unique identifier tracking the entire chain, a timestamp, and a service node identifier—related data from different levels and time points can be correlated and aggregated, providing a complete picture of a business request's performance throughout the entire chain. This correlation method solves the problem of data fragmentation in traditional analysis, allowing operations personnel to observe the interconnected changes in performance metrics from a global perspective, providing a complete data chain for subsequent anomaly analysis.

[0087] The severity level determination after an anomaly is triggered requires combining dynamic thresholds and a business scenario dependency graph. When performance metrics exceed dynamic thresholds, the system automatically triggers an anomaly, but the impact of different anomalies on the business varies significantly. The business scenario dependency graph records the relationships between various service nodes and metrics. For example, an anomaly in a payment interface may directly affect transaction completion, while the impact of a log service anomaly is relatively limited. Based on this graph, the propagation range and depth of impact of the anomaly in the business chain can be determined, thereby determining the anomaly level—anomalies affecting core business chains have a higher level and require priority handling. This determination process solves the problem of traditional alarms relying solely on metric values ​​and ignoring business impact, making anomaly handling more aligned with business priorities.

[0088] In general implementation, root cause localization is accomplished using the following methods:

[0089] Suppose that when a dynamic threshold triggers an anomaly, the set of anomaly indicators obtained through cross-layer data correlation is: , The number of abnormal indicators; the deviation between the actual value of each abnormal indicator and the dynamic threshold is: , This sets the dynamic threshold for the corresponding indicator; and defines the "anomaly propagation impact" based on the correlation between various indicators in the business scenario dependency graph. This refers to the number of other indicators that become abnormal after a certain indicator becomes abnormal; the root cause suspicion for each abnormal indicator is calculated using a formula:

[0090] ,

[0091] in, Associate the dynamic threshold calculation results. Related business scenarios rely on the graph's metric association logic; Suspicion level determination. The indicator corresponding to the maximum value is taken as the first-level root cause. The above calculation is repeated for the upstream indicators associated with this indicator to obtain the second-level and third-level root causes, and finally a complete root cause chain is formed.

[0092] In a preferred embodiment, root cause localization achieves accuracy and efficiency through a reinforcement learning-optimized inference tree. Faced with multiple anomalous indicators, it is necessary to identify the most fundamental root cause problem. Specifically, the root cause localization method is as follows:

[0093] After an abnormal event is triggered by a dynamic threshold, the set of abnormal indicators in the three layers of performance data associated with the "ternary identifier" is as follows: , The number of abnormal indicators is represented by the deviation between the actual value of each indicator and its corresponding dynamic threshold. , This is the dynamic threshold for the indicator. For the first The actual value of each abnormal indicator;

[0094] Based on the business scenario dependency graph, define the direct correlation weights between metrics. If the indicator Direct impact but Otherwise, the value is 0. Calculate the anomalous propagation breadth of each indicator. :

[0095] ,

[0096] Historical root cause frequency of each metric in the reasoning tree optimized by reinforcement learning This refers to the number of times a certain indicator has acted as a root cause in historical anomalies, calculated using a formula to determine the root cause probability. :

[0097] ,

[0098] in, Associate the dynamic threshold calculation results. Related business scenarios rely on the relationships within the graph. The reinforcement learning optimization process of the inference tree; taking The indicator corresponding to the maximum value is taken as the root cause. If there are upstream related indicators for this indicator, the above calculation is repeated for the upstream indicators until the root cause is located, so as to achieve linkage with the severity of the anomaly, the business link, and the historical root cause pattern.

[0099] Simultaneously, the system records the propagation path of the anomaly in the chain, generating detailed logs. This process solves the problems of low efficiency and reliance on experience in traditional manual troubleshooting, making root cause identification more objective and efficient, and providing a clear direction for quickly fixing performance issues.

[0100] (4) Generation of results report

[0101] In the performance analysis of virtualized environment software with cross-layer data association, the process of quantifying the business impact of performance issues requires first extracting the affected business data and user data, determining the degree of business impact through multi-dimensional calculations, generating an analysis report with priority sorting and visual presentation, and triggering an alarm-dispatch closed loop for high-impact anomalies to solve the problems of "emphasizing technology over business" and "untimely response" in traditional performance analysis.

[0102] Extracting key data is fundamental to quantifying business impact and addresses the pain point of "vague impact scope" in traditional analysis. After a performance issue occurs, it's crucial to first identify core data: Regarding business data, focus on extracting the duration of business interruption and the transaction volume per unit time for affected businesses—the former reflects the duration of the problem's disruption, while the latter reflects the potential scale of lost business per unit time. Regarding user data, it's necessary to count the number of affected users to clarify the scope of users impacted by the problem. For example, when an e-commerce platform experiences payment performance anomalies, it's necessary to record the duration of the payment function interruption, the normal payment volume per minute, and the number of users currently unable to pay. Extracting this data transforms the business impact from "subjective perception" to "objective quantification," preventing misallocation of resources due to inaccurate assessment of the impact scope.

[0103] The calculation of the business impact coefficient enables precise ranking of impact levels, resolving the issue of "confused repair priorities." In addition to referencing extracted business and user data, the calculation also considers two key business dimensions: first, the business chain level. The application layer directly interacts with user operations, so performance issues there have a more direct impact on the business than those at the infrastructure layer; higher levels have greater weight. Second, the historical normal completion rate of the business. Businesses with high historical completion rates are typically core businesses, and performance issues there result in more significant losses. The business impact coefficient, calculated comprehensively from these dimensions, directly reflects the severity of different performance issues—the higher the coefficient, the greater the business loss and the more users affected. Corresponding repair recommendations are ranked higher in the report, allowing operations personnel to prioritize issues without relying on experience, thus preventing delays in addressing core business problems.

[0104] Specifically, the calculation method for the business impact coefficient is as follows:

[0105] Let the duration of service interruption due to performance issues be... The number of transactions per unit time for the affected business is The number of affected users is Combine the business link levels associated with the identified root cause indicators. The infrastructure layer has a link level of 1, and the application layer has a level of 3. The higher the level, the closer it is to the business. The historical normal completion rate of the business scenario is also included. This refers to the percentage of business operations successfully completed without performance issues; the business impact coefficient is calculated using a formula. :

[0106] ,

[0107] in, and Related extracted business data, Linked extracted user data, For business scenarios that rely on the graph's link structure Associate with historical business operation data; the longer the business interruption time, the larger the transaction volume, the more affected users, the higher the link level, or the higher the historical completion rate, the more likely it is to cause disruption. The higher the value, the more it can be used to prioritize repair recommendations. The higher the value of the performance problem, the higher its repair suggestion will be ranked in the report, and at the same time trigger the "alarm-dispatch" closed loop push, realizing deep linkage with business losses, user scope and link correlation.

[0108] The generation of analysis reports and the "alarm-dispatch" closed loop improve the efficiency and transparency of problem resolution. Performance analysis reports not only include a priority ranking of remediation suggestions but also use interactive visualizations to present results, such as charts to visually represent the impact coefficient of each performance issue and the distribution of affected users, allowing both technical and business personnel to quickly understand the core of the problem. More importantly, for anomalies with high business impact coefficients, the system automatically triggers the "alarm-dispatch" closed loop: alarm information is pushed to the corresponding operations team in real time, and a dispatch task is generated, clearly defining the responsible person and processing deadline, avoiding the problem suspension caused by "delayed information transmission" and "unclear responsibility" in traditional alarms. This mechanism ensures that high-impact performance issues can be responded to quickly and followed up by dedicated personnel, minimizing business downtime and reducing the impact on user experience and business revenue.

[0109] This embodiment 1 also provides an explanation of a practical application scenario, specifically: In the virtualized environment of a company's data center private cloud zone, the cross-layer data association performance analysis method of this invention is used to achieve efficient operation and maintenance. After a business user initiates access via the Internet, the traffic is filtered through hardware egress firewall, cloud firewall (with IPS enabled), and WAF layer by layer before entering the application server and database server cluster in the Wuchuang Park VPC zone.

[0110] During the data acquisition phase, relying on the "three-element identifier + business scenario tag" generation module, a unique link ID, timestamp, and service instance ID (such as the external IP of application server 1, 12..5.233, and the IP of database server 1, 17..57, etc.) are injected into each user request, along with business scenario tags such as "transaction" and "query." The adaptive acquisition scheduler dynamically adjusts the acquisition frequency according to the business load, increasing the acquisition density of indicators such as CPU utilization and response time during peak business periods (such as when users concentrate on accessing application server 1), and reducing the acquisition frequency during low-load periods. At the same time, the acquired infrastructure layer (server hardware), middleware layer (database), and application layer (business system) performance data are standardized using Z-Score and outliers are smoothed to provide high-quality data in a unified format for subsequent analysis.

[0111] In the dynamic threshold generation process, an initial threshold is set by combining historical performance data and business SLA. The short-term business load is predicted and the load coefficient is corrected by using the LSTM algorithm. Then, the time factor is integrated to generate a dynamic threshold that adapts to business fluctuations. For example, during e-commerce promotion periods, the response time threshold of application server 1 will be appropriately relaxed to avoid false alarms, while the threshold will be tightened during off-peak periods to increase sensitivity. The dynamic threshold is also regularly synchronized to the alarm system of the cloud security management center.

[0112] When a dynamic threshold triggers an anomaly (such as the response time of database server 2 exceeding the threshold), the system uses a "ternary identifier" as the association key to integrate cross-layer information such as the operation and maintenance logs of the cloud bastion host, access records of database audits, and vulnerability scanning data of host security, and combines it with the business scenario dependency graph to determine the anomaly level; the reasoning tree optimized by reinforcement learning comprehensively considers the degree of anomaly deviation, the breadth of propagation, and the frequency of historical root causes to quickly locate the root cause (such as slow query due to unreasonable index design of database server 2), and records the anomaly propagation path from user request to database query.

[0113] Finally, the affected transaction data, number of users, and other information are extracted to calculate the business impact coefficient, and a performance analysis report with priority ranking of repair suggestions is generated (such as prioritizing the optimization of the index of database server 2). The performance correlation and anomaly details of each layer are displayed through interactive visualization. For high-impact anomalies (such as the interruption of the core transaction link), an alarm-dispatch closed loop is triggered to push to the operation and maintenance terminal (via VPN secure access) to ensure that operation and maintenance personnel can respond quickly and repair, thereby achieving efficient end-to-end management of software performance in the virtualization environment.

[0114] This embodiment 1 has broad application prospects in industries such as the internet, finance, and e-commerce that rely on complex virtualization architectures. For enterprises with high concurrency scenarios, its dynamic threshold adaptation and cross-layer data correlation capabilities can accurately capture performance anomalies and avoid service interruptions during peak business periods. Financial institutions, with the help of root cause localization and business impact quantification functions, can quickly repair core transaction link problems, meet compliance and stability requirements, and significantly reduce the risk of financial loss.

[0115] In the process of enterprise digital transformation, this Implementation Example 1 can adapt to the iterative upgrade needs of microservices and distributed architectures, and dynamically expand performance analysis capabilities as business expands. At the same time, its closed-loop mechanism of "detection-repair-iteration" can accumulate industry performance optimization experience, help small and medium-sized enterprises quickly build a professional performance management system, reduce technical investment costs, and provide core support for the efficient operation and secure maintenance of software systems in various industries.

[0116] Example 2

[0117] Please refer to Figure 3This embodiment 2 provides a software performance analysis system in a virtualized environment with cross-layer data association, including:

[0118] The data acquisition system building unit is used to build a system including an adaptive acquisition scheduler and a "three-element identifier + business scenario tag" generation module, start full-link performance data acquisition, and complete the standardization processing of the acquired data.

[0119] The dynamic threshold generation unit is used to set initial thresholds for each performance indicator by combining historical performance data and business SLA, introduce the LSTM method to predict short-term business load to correct the load coefficient, integrate a custom time factor to generate dynamic thresholds, and periodically synchronize the dynamic thresholds to the alarm system.

[0120] The root cause localization unit is used to associate performance data of the infrastructure layer, middleware layer and application layer based on the stream processing framework and with "ternary identifier" as the association key. After triggering an abnormal event according to the dynamic threshold, it determines the abnormal level by combining the business scenario dependency graph, locates the root cause of the performance bottleneck through the inference tree optimized by reinforcement learning, and records logs containing the abnormal propagation path.

[0121] The results report generation unit is used to extract relevant business and user data affected by performance issues, calculate the business impact coefficient, generate a performance analysis report that includes priority ranking of repair suggestions, display the analysis results in an interactive and visual way, and trigger a closed-loop "alarm-dispatch" push for high-impact anomalies.

[0122] Example 3

[0123] This embodiment 3 also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement any step of a software performance analysis method in a virtualized environment with cross-layer data association.

[0124] The computer-readable storage medium may include various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0125] For a description of the computer-readable storage medium provided in this application, please refer to the above method embodiments; further details will not be repeated here.

[0126] Those skilled in the art will readily understand that the above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for software performance analysis in a virtualized environment with cross-layer data association, characterized in that, include: S1. Build a system including an adaptive data collection scheduler and a "three-element identifier + business scenario tag" generation module, start full-link performance data collection, and complete the standardization processing of the collected data; S2. Combine historical performance data and business SLA to set initial thresholds for each performance indicator, introduce the LSTM method to predict short-term business load to correct the load factor, integrate a custom time factor to generate dynamic thresholds, and periodically synchronize the dynamic thresholds to the alarm system. S3. Based on the stream processing framework, the performance data of the infrastructure layer, middleware layer and application layer are associated with the "ternary identifier" as the association key. After an abnormal event is triggered according to the dynamic threshold, the abnormal level is determined by combining the business scenario dependency graph. The root cause of the performance bottleneck is located by the inference tree optimized by reinforcement learning, and logs containing the abnormal propagation path are recorded. S4. Extract relevant business and user data affected by performance issues, calculate business impact coefficients, generate a performance analysis report that includes priority ranking of repair suggestions, display the analysis results in an interactive visualization manner, and trigger a closed-loop "alarm-dispatch" push for high-impact anomalies; The "three-element identifier + business scenario tag" generation module in S1 is specifically as follows: When a user request enters the system, a three-element identifier is automatically generated and injected, which includes a unique link ID configured to track the entire request flow, a timestamp configured to associate time-series data, and a service instance ID configured to locate a specific service node. At the same time, the system automatically matches and attaches business scenario tags based on the corresponding business interface of the request, so that the full-link performance data can be associated across layers through the three-element identifier and can be directly associated with specific business scenarios through the business scenario tags.

2. The software performance analysis method for cross-layer data association in a virtualized environment according to claim 1, characterized in that, In S1, the adaptive acquisition scheduler is configured to dynamically adjust the acquisition frequency of performance data according to the business load: increase the acquisition frequency in high-concurrency business scenarios to ensure the real-time performance and precision of key performance indicators. By reducing the acquisition frequency during periods of low load, the system resource consumption can be reduced while still meeting analysis requirements, thus achieving a dynamic balance between acquisition efficiency and resource usage.

3. The software performance analysis method for cross-layer data association in a virtualized environment according to claim 1, characterized in that, The specific process of standardizing the collected data in S1 is as follows: For the performance data collected from different layers and dimensions in the infrastructure layer, middleware layer, and application layer, the Z-Score standardization method is first used to perform a unified transformation to eliminate the difference in dimensions. On this basis, the isolated forest method is combined to identify instantaneous outliers, and normal data from adjacent time periods in the same link are used to smooth them. Finally, standardized data that meets the requirements of subsequent cross-layer data association and dynamic threshold calculation is output.

4. The software performance analysis method for cross-layer data association in a virtualized environment according to claim 1, characterized in that, The method for correcting the load factor in S2 is as follows: Let the LSTM algorithm predict the future The predicted business load for the time period is The standardized historical load data sequence for the same period is , Given the historical data sample size, calculate the deviation rate series between the predicted value and the historical data: ， Take the deviation rate sequence The median is Combined with the number of link nodes in the business scenario dependency graph The corrected load factor is obtained through the formula. : ， in, Standardized results of linked historical data The relationship between business scenarios and dependencies is considered; the greater the deviation between predicted load and historical data, or the more complex the data link, the more important it is to consider these factors. The value is reduced to make the dynamic threshold more sensitive to adapt to high-risk scenarios.

5. The software performance analysis method for cross-layer data association in a virtualized environment according to claim 4, characterized in that, The method for calculating the dynamic threshold in S2 is as follows: Let the initial threshold set based on historical data and business SLA be... The upper limit of the historical normal fluctuation range of the standardized indicator is That is, the 95th percentile of the standardized value in historical normal data corresponds to the original value, combined with the corrected load factor. and custom time factors ; Calculate the dynamic threshold using the formula. : ， in, The standardized processing results of historical data of related indicators The associated load factor correction logic adjusts the denominator when load fluctuations are large or during high load periods. The term decreases, resulting in Towards To increase the normal threshold range and avoid false alarms under high load; conversely, to increase the threshold range by moving closer to the threshold. Towards Shrink to improve anomaly sensitivity under low load, and achieve deep linkage with historical data characteristics, real-time load and time period.

6. The software performance analysis method for cross-layer data association in a virtualized environment according to claim 1, characterized in that, The specific method for root cause localization in S3 is as follows: After an abnormal event is triggered by a dynamic threshold, the set of abnormal indicators in the three layers of performance data associated with the "ternary identifier" is as follows: , The number of abnormal indicators is represented by the deviation between the actual value of each indicator and its corresponding dynamic threshold. , This is the dynamic threshold for the indicator. For the first The actual value of each abnormal indicator; Based on the business scenario dependency graph, define the direct correlation weights between metrics. If the indicator Direct impact but Otherwise, the value is 0. Calculate the anomalous propagation breadth of each indicator. : ， Historical root cause frequency of each metric in the reasoning tree optimized by reinforcement learning This refers to the number of times a certain indicator has acted as a root cause in historical anomalies, calculated using a formula to determine the root cause probability. : ， in, Associate the dynamic threshold calculation results. Related business scenarios rely on the relationships within the graph. The reinforcement learning optimization process of the inference tree; taking The indicator corresponding to the maximum value is taken as the root cause. If there are upstream related indicators for this indicator, the above calculation is repeated for the upstream indicators until the root cause is located, so as to achieve linkage with the severity of the anomaly, the business link, and the historical root cause pattern.

7. A software performance analysis system in a virtualized environment with cross-layer data association, used to implement the software performance analysis method in a virtualized environment with cross-layer data association as described in claim 1, characterized in that, include: The data acquisition system building unit is used to build a system including an adaptive acquisition scheduler and a "three-element identifier + business scenario tag" generation module, start full-link performance data acquisition, and complete the standardization processing of the acquired data. The dynamic threshold generation unit is used to set initial thresholds for each performance indicator by combining historical performance data and business SLA, introduce the LSTM method to predict short-term business load to correct the load coefficient, integrate a custom time factor to generate dynamic thresholds, and periodically synchronize the dynamic thresholds to the alarm system. The root cause localization unit is used to associate performance data of the infrastructure layer, middleware layer and application layer based on the stream processing framework, using "ternary identifier" as the association key. After triggering an abnormal event according to the dynamic threshold, it determines the abnormal level by combining the business scenario dependency graph, locates the root cause of the performance bottleneck through the inference tree optimized by reinforcement learning, and records logs containing the abnormal propagation path. The results report generation unit is used to extract relevant business and user data affected by performance issues, calculate the business impact coefficient, generate a performance analysis report that includes priority ranking of repair suggestions, display the analysis results in an interactive and visual way, and trigger a closed-loop "alarm-dispatch" push for high-impact anomalies.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, The computer program is executed by a processor as described in any one of claims 1-6, which is a method for software performance analysis in a virtualized environment with cross-layer data association.

Images