An online service computing power optimization method based on big data

Abstract

The application discloses an online service computing power optimization method based on big data, which comprises the following steps: step S1, multidimensional data acquisition and association: the performance index data, the call chain data, the infrastructure monitoring data and the configuration snapshot data of the target online service are collected, the call chain data contains the track node information of the request with a unique identifier in the processing process at each service node; all data are associated and aligned according to a unified timestamp and a service instance identifier to form an associated data set; step S2, service dependency weight calculation and key path identification: based on the historical statistics of the call chain data, the frequency and the average response time of the service call are calculated. The application realizes fine and efficient optimization of online service computing power, considers safety and observability at the same time, and solves the core problem that the existing method cannot accurately and reliably optimize computing power.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of computing power optimization, in particular to an online service computing power optimization method based on big data. BACKGROUND

[0002] With the rapid development of Internet business, online services generally adopt distributed architecture, with a large number of service nodes, complex cross-level dependency relationships, and the need to cope with periodic fluctuations in user traffic. Computing power, as the core supporting resource of online services, its rationality of distribution directly determines the service quality and operating cost: if the supply of computing power is insufficient, it will lead to the extension of service response time and the increase of error rate, which seriously affects user experience and business availability; if the computing power is redundant, it will cause waste of resources such as servers and storages, and increase the operating cost of enterprises. Therefore, the core demand of online service computing power optimization is to achieve the balance between service performance and resource utilization by accurately matching the supply of computing power with the actual load of the business, which is the key link to ensure the stable operation of online services and control costs.

[0003] The existing online service computing power optimization related methods and systems have obvious deficiencies, such as single index, one-sided global performance judgment, fuzzy attribution, poor targetedness of optimization strategies, lack of quantitative standards, reliance on subjective experience, and insufficient connection between security protection and computing power optimization. Therefore, an online service computing power optimization method based on big data is proposed. SUMMARY

[0004] The present application solves the above technical problems through the following technical solutions, which includes the following steps:

[0005] Step S1, multi-dimensional data collection and correlation: collect performance index data, call chain data, infrastructure monitoring data and configuration snapshot data of the target online service, and the call chain data contains track node information of requests with unique identifiers formed in each service node during processing;

[0006] Align all data according to the unified timestamp and service instance identifier to form a correlation data set;

[0007] Step S2, service dependency weight calculation and key path identification: based on the historical statistics of call chain data, calculate the frequency and average response time of service calls, construct a service dependency relationship graph, and assign a dynamic weight to each edge in the graph , the calculation formula is:

[0008] ;

[0009] Among them, is the daily call frequency normalization value of service i calling service j, This is the normalized value of the average response time for service j during this call;

[0010] Based on this weight, the shortest path algorithm is used to identify the critical call paths of the system;

[0011] Step S3, Joint Attribution Analysis of Performance Degradation: Periodically scan the associated dataset. When a global performance metric degradation is detected, initiate attribution analysis and obtain the attribution analysis results.

[0012] S4. Generate and verify optimization strategies: Based on the attribution analysis results, if the root cause is a configuration error or suboptimal configuration, first characterize the current load characteristics of the service by weighted combination of CPU, memory and QPS, then retrieve health history records similar to the current load characteristics of the service from the historical configuration library, and use the configuration as the recommended configuration.

[0013] S5. Security Implementation and Feedback Calibration: The recommended configuration will be applied to some instances in a canary release manner, and its performance indicators will be continuously monitored.

[0014] If the performance improvement of the critical path after application is significant If the system exceeds the preset threshold and remains stable, the optimization will be fully implemented. At the same time, the load characteristics and configuration mapping relationship of this successful optimization will be recorded and stored in the historical configuration library for use in generating subsequent optimization strategies.

[0015] Furthermore, in step S1, the configuration snapshot data includes operating system kernel parameters, middleware connection pool size, application thread pool size, JVM garbage collector type, and heap memory size parameters.

[0016] Furthermore, when periodically scanning the associated dataset, if a global performance metric degradation is detected, attribution analysis is initiated. This degradation is detected by calculating a weighted composite score S of the average request response time and error rate within a sliding time window. An alarm is triggered when S exceeds its historical high percentile value. The calculation formula is as follows:

[0017] ;

[0018] in, and These are the average response times for the current period and the baseline period, respectively. It is the standard deviation of the baseline response time. and These are the error rates for the current period and the baseline period, respectively. and These are the weighting coefficients.

[0019] Further, the method for determining the historical health period in step S3.2 is: selecting a time period with the same periodic characteristics as the current time and a comprehensive score S that is continuously lower than the historical low percentile value as the baseline period from the historical data.

[0020] Further, the specific process of the attribution analysis is: first locating the service node with the largest response time change on the key call path, determining the instance corresponding to the service node as the problem instance, and then executing the following two sub-steps in parallel:

[0021] Step S3.1, horizontal comparison analysis: comparing the differences in resource configuration, version number and core configuration items between the problem instance and the healthy instances of the same type within the same time window;

[0022] Step S3.2, longitudinal historical analysis: comparing the performance indicators and configuration snapshots of the problem instance with the data of its own historical healthy period, and calculating the configuration deviation , the calculation formula of which is:

[0023] ;

[0024] Among them, and are the values of the kth configuration item in the current and baseline configurations, is the span of the allowed value range of the configuration item, is the preset weight coefficient of the performance impact of the configuration item.

[0025] Further, the specific method for retrieving historical records with similar load characteristics in step S4 is: calculating the Euclidean distance between the current load characteristic vector and the load characteristic vectors in the historical records, selecting the top K historical records with the smallest Euclidean distance, and taking the mode or the value after weighted averaging of the corresponding configurations as the recommended configuration.

[0026] Further, it further includes an effectiveness evaluation step of log and observability code: periodically analyzing the association between the call chain data and the application log, if it is found that there is a high-time-consuming or high-error-rate call chain segment, and the corresponding application log output is low-level or missing, a suggestion is generated to prompt to supplement or improve the log level in the code area to enhance observability.

[0027] Further, the effectiveness evaluation step includes calculating an observability coverage score :

[0028] Among them, is the time consumption of each trajectory node on the key path, is the preset weight of the highest level of logs generated by the service instance corresponding to the trajectory node during request processing, is the total number of trace nodes on the critical path; when is below a threshold value, an alarm is triggered.

[0029] Further, in step S3, if neither the lateral comparative analysis nor the longitudinal historical analysis finds significant abnormalities, the root cause is speculated to be a performance degradation of dependent services or an infrastructure problem, and a drill-down query is initiated on the performance indicators of the downstream dependent services, and the logic of steps S3-S4 is repeatedly executed until the root cause service or infrastructure component at the bottom layer is located.

[0030] Further, the performance improvement amplitude in step S5 is calculated according to the following formula:

[0031] ;

[0032] wherein, and are the average response times before and after the application configuration, and are the error rates before and after the application configuration, and are weight coefficients.

[0033] Further, the method also establishes a historical configuration library for storing each successful optimization strategy and its effect data; when a similar performance degradation pattern is encountered again, the system preferentially matches and recommends the optimization strategy that has been verified to be effective in history from the historical configuration library, thereby accelerating the optimization process.

[0034] Compared with the prior art, the online service computing power optimization method based on big data has the following advantages: the online service computing power optimization method based on big data collects multi-dimensional data, integrates performance indicators, call chains, infrastructure monitoring and configuration snapshot data, provides comprehensive data support for subsequent analysis, avoids one-sided analysis caused by data isolation, accurately identifies system key call paths with the help of dynamic weight calculation and shortest path algorithm, focuses on core links for optimization, and avoids blind investment; the performance degradation joint attribution analysis can accurately locate the root cause of configuration errors, suboptimal configuration, dependent service degradation or infrastructure problems by comparing problem instances and healthy instances horizontally, comparing historical healthy data of instances vertically and calculating configuration deviation, solving the problem of traditional fuzzy attribution; when generating optimization strategies, the health records of similar load characteristics are searched based on the historical configuration library, the recommended configuration has historical effectiveness verification, and successful optimization cases are supplemented to the library to form a closed loop, accelerating the optimization of similar scenes in the future; the optimization is safely implemented by using the gray release method, the performance improvement and system stability are verified in part of the instances, and the risk of overall implementation is reduced; at the same time, through the log and observability coverage score evaluation, the log loss or low-level problem of high-time-consuming / high-error-rate call chain segments is found in time, the system observability is improved to assist subsequent problem troubleshooting, and the online service computing power is accurately, safely and efficiently optimized, and the optimization capacity can be continuously improved, solving the problems of blind optimization, high risk, difficult attribution and low efficiency of existing related methods. BRIEF DESCRIPTION OF DRAWINGS

[0035] Figure 1 The flowchart of the present application. DETAILED DESCRIPTION

[0036] The embodiments of the present application will be described in detail below. The embodiments are implemented on the premise of the technical solutions of the present application, and detailed implementation methods and specific operation processes are given. However, the protection scope of the present application is not limited to the following embodiments.

[0037] As shown in Figure 1 , the present application provides a technical solution: an online service computing power optimization method based on big data, comprising the following steps:

[0038] Step S1, multi-dimensional data collection and association: collecting performance indicator data, call chain data, infrastructure monitoring data and configuration snapshot data of the target online service, the call chain data containing track node information formed by the request with a unique identifier in the processing process at each service node;

[0039] Align all data according to a unified timestamp and service instance identifier to form an associated data set;

[0040] Step S2, service dependency weight calculation and critical path identification: based on the historical statistics of the call chain data, the frequency and average response time of service calling are calculated, the service dependency relationship graph is constructed, and a dynamic weight is assigned to each edge in the graph , the calculation formula is:

[0041] ;

[0042] Wherein, is the daily call frequency normalization value of service i calling service j, is the average response time normalization value in this call of service j;

[0043] Based on this weight, the shortest path algorithm is used to identify the critical call path of the system;

[0044] Step S3, performance degradation joint attribution analysis: periodically scan the associated data set, and when detecting that the global performance index degrades, start the attribution analysis, and obtain the attribution analysis result;

[0045] S4, generating and verifying optimization strategy: based on the attribution analysis result, if the reason is configuration error or suboptimal configuration, first represent the current load characteristics of the service through the weighted combination of CPU, memory and QPS, and then retrieve the similar healthy historical record from the historical configuration library according to the current load characteristics of the service, and take the configuration as the recommended configuration;

[0046] S5, safe implementation and feedback calibration: apply the recommended configuration to part of the instances in a gray release manner, and continuously monitor the performance index change;

[0047] If the performance improvement range of the critical path after application Exceeds the preset threshold and the system is stable, it is implemented comprehensively; at the same time, the load characteristics and configuration mapping relationship of this optimization success are recorded and stored in the historical configuration library, which is used for generating subsequent optimization strategy.

[0048] Further, in step S1, the configuration snapshot data includes operating system kernel parameters, middleware connection pool size, application thread pool size, JVM garbage collector type and heap memory size parameters.

[0049] Further, when periodically scanning the associated data set, if it is detected that the global performance index degrades, the attribution analysis is started, and the degradation of the global performance index is detected by calculating the weighted comprehensive score S of the request average response time and the error rate in the sliding time window, and when S exceeds the historical high percentile value, an alarm is triggered, and the calculation formula is:

[0050] ;

[0051] wherein, and are the average response time in the current and baseline period, respectively, is the standard deviation of the response time in the baseline period, and are the error rate in the current and baseline period, respectively, and are weight coefficients;

[0052] The core benefits of the design of calculating the weighted comprehensive score S of the average response time and error rate of the request in the sliding time window, and taking the condition that S exceeds the historical high percentile value as the performance degradation alarm trigger condition, are reflected in the following four aspects:

[0053] Both the average response time (directly affecting user experience) and the error rate (directly affecting service availability) are taken into account, rather than relying on a single indicator, which can cover scenarios such as a sudden increase in error rate with normal response time (e.g., abnormal function of a service) or a sharp increase in response time with normal error rate (e.g., resource bottleneck), and comprehensively reflect the overall performance state of the system. The historical high percentile value is taken as the trigger threshold of S, rather than a fixed value, which can adapt to the normal periodic fluctuations of the system (such as the difference in response time between daily traffic and peak traffic on e-commerce platforms, and the difference in load between weekdays and weekends in office systems), avoiding frequent false alarms caused by a fixed threshold that does not match the scenario (e.g., triggering an alarm when the response time is slightly high during off-peak hours). The introduction of the standard deviation of the response time in the baseline period can correct the effectiveness of the difference between the current and baseline response times. If the baseline response time itself fluctuates greatly, even if there is some difference between the current and baseline, it will not be easily determined as degradation. At the same time, the weight coefficients λ and μ can be flexibly adjusted to prioritize the two indicators, which can meet the actual business needs. Based on the sliding time window, the data is continuously scanned, which can track the performance trend in real time or near real time, and compared with the traditional fixed-period sampling monitoring (e.g., statistics once an hour), it can quickly discover the performance degradation signs, which can save time for subsequent root cause analysis and optimization strategies, and reduce the impact of performance problems on users.

[0054] Taking a product detail page service of an e-commerce platform as an example (business priority: user experience first, so the response time weight λ = 0.5, service availability second, error rate weight μ = 0.5; historical high percentile value S threshold = 1.5, i.e., 95% of the historical data S ≤ 1.5 in healthy periods):

[0055] Determine the baseline period: select last Tuesday 10:00-12:00 (non-peak, non-peak, no performance problems, comprehensive score S continuously below the historical low percentile value 0.3) as the baseline period, and the baseline data is:

[0056] Baseline average response time ;

[0057] Baseline response time standard deviation (reflects the normal fluctuation range of the baseline period response time);

[0058] Baseline error rate (only 5 failures per 10,000 requests).

[0059] Collect current sliding window data: take the current week's 10:00-10:05 sliding window (5-minute real-time data), and the current performance data is:

[0060] Current average response time (obviously higher than the baseline, and the user's loading of the product detail page is slower);

[0061] Current error rate (increased by 10 times compared with the baseline, and some users failed to load the product detail page after clicking it).

[0062] Calculate the comprehensive score S:

[0063] According to the formula , substitute the data:

[0064] ;

[0065] Trigger alarm judgment: the current S=1.50225> historical high percentile value threshold 1.5, the system triggers a global performance degradation alarm, prompting the operation and maintenance personnel to start subsequent attribution analysis.

[0066] If only relying on a single indicator (such as only looking at response time: , it may be misjudged as serious degradation; or only looking at error rate: 0.5%-0.05%=0.45%, it may ignore the response time problem), and the comprehensive score S not only captures the abnormal fluctuation of the response time, but also includes the surge of the error rate, and through the dynamic threshold 1.5 avoids false positives of non-abnormal fluctuations, accurately identifies the real performance degradation.

[0067] Further, the determination method of the historical healthy period in step S3.2 is: selecting a time period with the same periodic characteristics as the current time from the historical data and with a comprehensive score S continuously lower than the historical low percentile value as the baseline period.

[0068] Further, the specific process of attribution analysis is to first locate the service node with the largest response time change on the key call path, determine the instance corresponding to the service node as the problem instance, and then perform the following two sub-steps in parallel:

[0069] Step S3.1, horizontal comparison and analysis: compare the differences in resource configuration, version number and core configuration items between the problem instance and the healthy instance of the same type in the same time window;

[0070] Step S3.2, longitudinal history analysis: compare the performance indicators of the current problem instance with the configuration snapshot with the data of its own historical health period, calculate the configuration deviation , the calculation formula is:

[0071] ;

[0072] , wherein, and are the values of the kth configuration item in the current and baseline configurations, is the value range span allowed by the configuration item, is the preset weight coefficient of the performance impact of the configuration item;

[0073] By first locating the service node with the largest response time change on the key call path, then performing parallel comparison analysis and longitudinal history analysis, and simultaneously quantitatively calculating the configuration deviation, if no abnormalities are found, the downstream dependency is extended for attribution design, which closely meets the precise positioning of the root cause requirement of the entire computing power optimization method;

[0074] First, lock the service node with the largest response time change in the key call path identified in step S2, rather than indiscriminately investigating all service nodes, which can directly focus on the core source of performance degradation, avoid the low efficiency caused by too large investigation range (such as irrelevant service nodes), and make the attribution analysis more targeted;

[0075] Lateral comparison analysis can quickly identify individual differences of instances; longitudinal history analysis can capture changes in instances themselves, both of which cover individual abnormalities and changes in themselves, avoiding attribution bias caused by relying on single-dimensional analysis;

[0076] The configuration deviation is calculated by the formula , which converts the difference between the current and baseline configurations into a measurable value, rather than a subjective judgment of the difference size; at the same time, combined with the preset weight of the performance impact of the configuration item (such as the weight of key configuration items such as JVM heap memory and application thread pool size), it can accurately identify the significant deviation of high-weight configuration items, avoid misjudgment of the root cause caused by ignoring key configuration differences; if no significant abnormalities are found through lateral and longitudinal analysis, it is clear that the root cause is the performance degradation of dependent services or infrastructure problems, and the performance indicator drilling query of downstream dependent services is started, the attribution logic is repeated, forming a complete attribution chain from core nodes to similar instances to their own history to downstream dependencies, avoiding the indirect root cause of missing the performance problem of downstream services (such as databases and middleware) caused by the degradation of upstream services.

[0077] As an e-commerce platform product detail page service scenario: the known baseline period is Tuesday 10:00-12:00 last week (system health, comprehensive score S continues to be lower than the historical low percentile value, baseline average response time , error rate ), the current Wednesday 10:00-10:05 triggers performance degradation alarm due to comprehensive score S=1.50225 (threshold value 1.5), step S2 identifies the key call path as "user request→product detail main service→product image loading sub-service→image CDN service", and locates the product image loading sub-service as the node with the largest response time change on the key path (current response time 600ms, an increase of 200% compared with the baseline period 200ms), the specific attribution process is as follows:

[0078] Determine the configuration snapshot data type of step S1 of the core configuration item combined with the weight, select the configuration items that have a key impact on the performance of the product image loading sub-service: application thread pool size (affecting concurrent processing capability, having a large impact on performance, preset weight , allowed value range ), JVM heap memory size (affecting image caching capability, preset weight , allowed value range );

[0079] Select 3 healthy instances (numbers A, B, and C, current response time ≤250ms, no performance problems) of the product image loading sub-service within the same cluster, and compare the configurations of the same time window (10:00-10:05) with the problem instance (number D): the application thread pool size of the problem instance D is 30, while the application thread pool sizes of the healthy instances A, B, and C are 80, 75, and 85 respectively; the JVM heap memory sizes of the problem instance D and the 3 healthy instances are all 8GB, and the service version numbers are consistent, with no version difference;

[0080] Extract the configuration snapshot data of the problem instance D in the baseline period (Tuesday 10:00-12:00 last week): the baseline period application thread pool size is 80, and the JVM heap memory size is 8GB; calculate the configuration deviation degree : substitute the formula , where k=1 (application thread pool), , , , multiplied by 0.4375; k=2 (JVM heap memory), , , , multiplied by 0; finally (far exceeds the preset normal deviation threshold 0.1);

[0081] Combining the transverse comparison (the problem instance thread pool is significantly smaller than the healthy instance) with the longitudinal analysis (the problem instance thread pool is significantly reduced compared to the healthy baseline, and the configuration deviation exceeds the standard), it can be determined that the application thread pool size configuration of the commodity picture loading sub-service is too low, which is the root cause of the performance degradation. There is no need to extend the investigation of downstream dependent services.

[0082] The specific method of retrieving the history record of similar load characteristics in step S4 is to calculate the Euclidean distance between the current load characteristic vector and the load characteristic vector in the history record, select the top K history records with the smallest Euclidean distance, and take the mode or weighted average value of the corresponding configuration as the recommended configuration.

[0083] The core benefits of the design of calculating the Euclidean distance between the current and historical load characteristic vectors, selecting the top K similar records, and taking the mode / weighted average as the recommended configuration revolve around accurately matching historical effective configurations, improving the reliability and efficiency of optimization strategies, and closely linking the demand of step S4 to generate optimization strategies, which is reflected in four aspects:

[0084] Using Euclidean distance to calculate the similarity of current and historical load characteristics (CPU, memory, and QPS weighted combination), the subjective judgment of similar load is converted into a quantifiable value, ensuring that the selected historical records are highly consistent with the current load scenario, and avoiding invalid recommended configurations due to inaccurate load judgment; selecting the top K historical records with the smallest Euclidean distance (instead of only selecting one most similar record) and then determining the recommended configuration through mode or weighted average can avoid the accidental deviation of a single historical record, improving the stability and reliability of the recommended results; the load characteristics are based on the weighted combination of CPU, memory, and QPS, which can be flexibly adjusted according to the service type, ensuring that the load characteristics can truly reflect the current running pressure of the service, and then accurately match the current load demand of the recommended configuration; relying on the historical configuration library, the recommended configuration is directly selected from the verified effective historical configuration, without the need to redesign the configuration scheme, significantly shortening the time to generate optimization strategies, especially when the attribution analysis has clearly identified the configuration problem, which can quickly link to the implementation link (step S5), reducing the impact of performance degradation on business for a long time.

[0085] For example, in the e-commerce platform commodity picture loading sub-service scenario: it has been determined that the root cause of the current performance degradation is the application thread pool size configuration, which is too low, and the healthy configuration of similar load needs to be retrieved from the historical configuration library. The specific process is as follows:

[0086] Set the load characteristic parameters:

[0087] According to step S4, the load feature is represented by the weighted combination of CPU utilization, memory usage and QPS, and the commodity picture loading sub-service is CPU and memory intensive (picture decoding occupies CPU and cache occupies memory). The load feature vector weight is set as: CPU utilization = 0.4, memory usage = 0.3, and QPS = 0.3; and each index is normalized (mapped to the 0-1 interval to eliminate dimensional differences).

[0088] The current load feature vector is collected:

[0089] After normalization of the current (performance degradation) service load, the load feature vector is:

[0090] = [CPU: 0.7 (70%), memory: 0.6 (60%), QPS: 0.8 (8000 times / minute, normalized to 0.8)];

[0091] Extracting historical configuration library candidate records:

[0092] Selecting 4 candidate records from the historical configuration library, whose load feature vectors and corresponding configurations (application thread pool size) are as follows:

[0093] Record 1 (historical optimization success, similar load): V1 = [0.65, 0.55, 0.75], configuration: thread pool size = 80;

[0094] Record 2 (historical optimization success, similar load): V2 = [0.72, 0.62, 0.82], configuration: thread pool size = 80;

[0095] Record 3 (historical optimization success, slightly lower load): V3 = [0.5, 0.4, 0.6], configuration: thread pool size = 60;

[0096] Record 4 (historical optimization success, slightly higher load): V4 = [0.8, 0.7, 0.9], configuration: thread pool size = 100;

[0097] Calculate the Euclidean distance and select the top K:

[0098] According to the Euclidean distance formula (general formula for vectors of two or more dimensions: , n = 3, x is the current vector, and y is the historical vector), the distance between the current and each record is calculated:

[0099] Distance from record 1: ;

[0100] Distance from record 2: ;

[0101] Distance from record 3: ;

[0102] Distance from record 4: ;

[0103] Order by distance from small to large: record 2 (0.0346) < record 1 (0.0866) < record 4 (0.1732) < record 3 (0.3464), take K=3 (top 3 most similar records: record 2, record 1, record 4).

[0104] Determine the recommended configuration:

[0105] The application thread pool configuration of the 3 records is respectively: 80 (record 2), 80 (record 1), 100 (record 4). Since "80" is the mode (appears twice), the final recommended configuration is "application thread pool size = 80", which matches the health configuration of the service under similar load.

[0106] Further, it further includes an effectiveness evaluation step of log and observability code: periodically analyze the association of call chain data and application log, if it is found that there is a high time-consuming or high error rate call chain segment, and the corresponding application log output is low level or missing, a suggestion is generated to prompt to supplement or improve the log level in the code area to enhance observability;

[0107] By periodically analyzing the association of call chain data and application log, if it is found that there is a high time-consuming or high error rate call chain segment, and the corresponding application log output is low level or missing, a suggestion is generated to prompt to supplement or improve the log level in the code area to enhance observability. The design can complete the key scene observability gap and provide fine-grained data support for performance degradation attribution. Although it can identify the key call path, it cannot obtain the specific business logic details in the high time-consuming / high error rate segment by relying only on call chain data. This design can obtain more accurate code link information for subsequent attribution analysis by optimizing the log, avoiding the problem of being able to locate the call chain segment but unable to determine the specific problem point.

[0108] Early detection of observability defects can avoid passive post-mortem. Instead of checking logs only after performance problems occur, the periodic analysis mode can detect potential log deficiencies before the system shows obvious performance degradation, preventing the extension of troubleshooting period due to log loss when a subsequent performance problem occurs, and reducing the impact on online services.

[0109] Fourth, focus on high-value log optimization to avoid invalid log redundancy and power consumption, and avoid blindly adjusting logs for all service nodes or code regions. Only optimize logs for high-time-consuming / high-error-rate call chain segments that are strongly related to power optimization. This ensures observability in critical scenarios and avoids excessive low-value logs occupying storage and processing resources, which is consistent with the core goal of power optimization. Fourth, support continuous iteration of the optimization closed loop. The load characteristics and configuration mapping relationship of successful optimization need to be recorded and stored in the historical configuration library. Complete logs can record key data before and after high-time-consuming / high-error-rate segment optimization, providing evidence for verifying the effectiveness of optimization strategies (such as the calculation of performance improvement amplitude ΔP in step S5). At the same time, it also provides a log reference for similar call chain problems in the future, strengthening the coherence and iteration of the overall optimization method.

[0110] The effectiveness evaluation step includes calculating an observability coverage score :

[0111] wherein, is the time consumption of each trajectory node on the critical path, is the highest preset weight of the log generated by the service instance corresponding to the trajectory node during the request processing, is the total number of trajectory nodes on the critical path; when is lower than the threshold, an alarm is triggered;

[0112] Converting observability from qualitative judgment to quantitative evaluation avoids subjective judgment bias of low-level / missing logs (such as whether the log is sufficient without relying on human experience). By associating the time consumption of the critical path node with the log level weight through the formula, the observability coverage has a clear numerical standard, ensuring that the evaluation of observability by different scenarios and different personnel is unified;

[0113] Focusing on the core nodes of the critical path avoids resource waste, only calculating the trajectory nodes on the critical path, not all service nodes, and through (node time consumption) weighting, high-time-consuming nodes have a greater impact on the score, ensuring that observability optimization prioritizes covering the most critical links that affect power and performance, rather than performing meaningless full-node log evaluation;

[0114] Precise triggering of log optimization alarms avoids over-optimization and insufficiency. Only when is lower than the threshold, it prompts to supplement the log, which prevents excessive suggestions for low-impact node logs and avoids the lack of data support in subsequent step S3 (performance attribution) due to insufficient key node logs (but not detected), ensuring that log optimization is only started when it affects performance analysis;

[0115] The effect verification of the support optimization closed loop requires monitoring the performance indicators after optimization in step S5, which can be used as a quantitative basis for the optimization effect of the log. If the score is improved to above the threshold, it indicates that the observability of the key node meets the standard, and when performance problems occur subsequently, they can be quickly attributed. This echoes the optimization effect recorded in the historical configuration library and strengthens the iterative nature of the overall method.

[0116] For example, in the scenario of an e-commerce platform's product image loading sub-service, the known key call path is "user request → product detail main service (node A) → product image loading sub-service (node B, high-time-consuming core node) → image CDN service (node C)", i.e., the total number of key path trajectory nodes .

[0117] The preset log level weights are: DEBUG = 0.2 (low level), INFO = 0.4, WARN = 0.7, and ERROR = 1.0 (high level); the observability coverage score The preset threshold is 80 (set according to historical healthy period data; if it is lower than 80, the observability of the key node is insufficient).

[0118] Collect key node data:

[0119] In the current performance degradation troubleshooting phase, real-time data of the three trajectory nodes of the key path is obtained:

[0120] Node A (detail main service → image loading sub-service call): time consumption (low time consumption), and the highest log level during processing requests is INFO (corresponding );

[0121] Node B (image loading sub-service internal decoding processing): time consumption (high time consumption, accounting for 67% of the total time consumption of the key path), and the highest log level during processing requests is DEBUG (corresponding , the log level is low and cannot record decoding exception details);

[0122] Node C (image loading sub-service → CDN call): time consumption (medium time consumption), and the highest log level during processing requests is WARN (corresponding ).

[0123] Calculate the observability coverage score :

[0124] The root formula , substitute the data to calculate:

[0125] Numerator (sum of key node time consumption and log weight product): ;

[0126] Denominator (total number of critical path trace nodes):

[0127] Finally .

[0128] Alarm judgment and processing:

[0129] Because of the calculation (lower than the preset threshold 80), the system triggers an observability insufficient alarm, prompting: the critical path high time-consuming node B (picture loading sub-service decoding link) log level is too low (current DEBUG, it is recommended to be upgraded to INFO and above), and the business log of this link (such as decoding time-consuming, cache hit situation) needs to be supplemented. Subsequent performance problem attribution upgrade to 92 (higher than the threshold), observability meets the standard, ensuring that if the node performance problem occurs again in the future, it can be quickly located through the log.

[0130] In step S3, if neither horizontal comparative analysis nor longitudinal historical analysis finds significant abnormalities, the root cause is speculated to be dependent service performance degradation or infrastructure problems, and performance indicators of downstream dependent services are drilled to query, and the logic of steps S3-S4 is repeated until the bottom layer root cause service or infrastructure component is located.

[0131] The performance improvement amplitude in step S5 is calculated by the formula:

[0132]

[0133] Among them, and are the average response times before and after application configuration, and are the error rates before and after application configuration, and are weight coefficients;

[0134] Convert the optimization effect from qualitative description to quantitative calculation to avoid subjective judgment deviation of whether the performance is improved (such as feeling the response is faster), and through the formula to associate the average response time and error rate before and after application configuration, let the optimization effect have a clear numerical basis, and ensure that different personnel and different scenes judge the optimization effect uniformly;

[0135] ​​The integration of two core metrics comprehensively evaluates the value of optimization. It considers both the average response time (a direct reflection of computing power utilization efficiency) that directly affects user experience and the error rate that affects service availability. This avoids misjudgment based on a single metric (such as only looking at the reduction in response time while ignoring the increase in error rate, which may lead to seemingly effective optimizations that actually damage service quality), and fully covers the core performance objectives of online services.

[0136] The weighting system flexibly adapts to business needs, improving the accuracy of judgments through weighting coefficients. , The importance of metrics can be adjusted based on service priority (e.g., for product detail page services in e-commerce scenarios, response time can be given higher weight). Prioritize ensuring a smooth user loading experience; financial payment services, on the other hand, can increase the weighting of error rates. Prioritizing transaction stability), The calculations align with actual business needs; fourth, they support the implementation and iteration of the optimization loop, with step S5 clearly defined. "If the system exceeds the preset threshold and remains stable, the optimization will be fully implemented." It is also required that successfully optimized mapping relationships be stored in the historical configuration database. Not only does it serve as a basis for decision-making on whether to fully implement it, but its quantitative results will also become core data in the historical configuration database, providing a "verified effect" reference for subsequent optimization strategy recommendations for similar load scenarios, and strengthening the iterative nature and reliability of the overall optimization method.

[0137] For example, in the scenario of "product image loading sub-service on an e-commerce platform": the recommended configuration has been confirmed as "application thread pool size = 80", and it has been applied to 3 instances (total of 10 instances) in a canary release manner according to step S5. It is necessary to calculate... Determine whether to implement it comprehensively. Specific parameters and calculation process are as follows:

[0138] Set basic parameters:

[0139] Business weighting: The product details page service prioritizes user loading experience, therefore average response time is given weight. Error rate weighting ;

[0140] Preset threshold: Set based on historical optimization results. To optimize the effective threshold (i.e., performance improvement exceeding 25% can be fully implemented);

[0141] Data collection before and after configuration: Under the same load scenario (CPU utilization 70%, memory utilization 60%, QPS 8000 times / minute), performance data was collected for 3 canary deployment instances before and after application configuration (thread pool = 80).

[0142] Average response time before configuration ;

[0143] Average response time after configuration ;

[0144] Error rate before configuration (5 failures per 1000 requests, mostly caused by request timeout due to thread pool full);

[0145] Error rate after configuration (0.8 failures per 1000 requests, only occasional network fluctuations).

[0146] Performance improvement rate :

[0147] According to the formula , the data is calculated as follows:

[0148] Response time improvement contribution value: (i.e. 37.98%);

[0149] Error rate reduction contribution value: (i.e. 33.6%);

[0150] Finally (i.e. 71.58%).

[0151] Because the calculated is greater than the preset threshold of 25%, and after 1 hour of continuous monitoring, the 3 gray release instances are running stably (no new abnormal logs, normal resource utilization), the step S5 decision "comprehensively implement the configuration" (adjust the thread pool size of the remaining 7 instances to 80) is made; At the same time, the mapping relationship between the "load characteristics (CPU=70%, memory=60%, QPS=8000)" and "configuration (thread pool=80)" of this optimization, and the effect data of are recorded, and stored in the historical configuration library, which provides a reference for the optimization strategy generation of the same load scenario in the future.

[0152] The method also establishes a historical configuration library for storing each successful optimization strategy and its effect data; When similar performance degradation patterns are encountered again, the system preferentially matches and recommends the historical optimization strategies that have been verified to be effective from the historical configuration library, thereby speeding up the optimization process.

[0153] In addition, the terms "first", "second" are only for descriptive purposes, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features. Therefore, the features defined with "first", "second" can explicitly or implicitly include at least one of the features. In the description of the present application, the meaning of "a plurality of" is at least two, such as two, three, etc., unless otherwise specifically limited.

[0154] In the description of the present specification, the description of the terms "one embodiment", "some embodiments", "an example", "a specific example", or "some examples" and the like means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. In the present specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Also, the specific features, structures, materials or characteristics described can be combined in any appropriate manner in any one or more embodiments or examples. Furthermore, the person skilled in the art can combine and combine the different embodiments or examples described in the present specification and the features of the different embodiments or examples, without contradiction.

[0155] Although the embodiments of the present application have been shown and described above, it is understood that the above-described embodiments are exemplary and are not to be construed as limiting the present application, and the person skilled in the art can make changes, modifications, replacements and variations to the above-described embodiments within the scope of the present application.

Claims

1. A big data-based online service computing power optimization method, characterized in that, The method comprises the following steps: Step S1, multi-dimensional data collection and association: collecting performance indicator data, call chain data, infrastructure monitoring data and configuration snapshot data of the target online service, wherein the call chain data comprises trajectory node information of a request with a unique identifier formed at each service node in the processing process; Aligning all the data according to a unified timestamp and a service instance identifier to form an associated data set; Step S2, service dependency weight calculation and critical path identification: based on the historical statistics of the call chain data, the frequency and average response time of service calling are calculated, the service dependency relationship graph is constructed, and a dynamic weight is assigned to each edge in the graph ; Based on the weight, the shortest path algorithm is used to identify the key call path of the system; Step S3, joint performance degradation attribution analysis: periodically scanning the associated data set, when detecting that the global performance indicator degrades, starting the attribution analysis, and obtaining the attribution analysis result; S4, generating and verifying the optimization strategy: based on the attribution analysis result, if the reason is a configuration error or a suboptimal configuration, first representing the current load characteristics of the service with a configuration error or a suboptimal configuration pointed to by the attribution analysis through the weighted combination of CPU, memory and QPS, and then retrieving a health history record similar to the current load characteristics of the service from a historical configuration library, and taking the configuration as a recommended configuration; S5, safe implementation and feedback calibration: applying the recommended configuration to part of the instances in a gray release manner, and continuously monitoring the performance indicator changes; If the application of the critical path performance improvement range exceeds the preset threshold and the system is stable, then the optimization is fully implemented; at the same time, the load characteristics and configuration mapping relationship of this optimization success are recorded and stored into the historical configuration library for the generation of subsequent optimization strategies; Performance improvement range in step S5 The calculation formula is: ； wherein, and are the average response times before and after the application configuration, respectively, and are the error rates before and after the application configuration, respectively, and are the weight coefficients.

2. The big data-based online service computing power optimization method according to claim 1, characterized in that: In step S1, the configuration snapshot data comprises operating system kernel parameters, middleware connection pool size, application thread pool size, JVM garbage collector type and heap memory size parameters.

3. The big data-based online service computing power optimization method of claim 2, wherein: When periodically scanning the associated data set, if it is detected that the global performance indicator degrades, the attribution analysis is started, and the detection of the degradation of the global performance indicator is realized by calculating the weighted comprehensive score S of the request average response time and the error rate in the sliding time window, and the alarm is triggered when S exceeds the historical high percentile value.

4. The big data-based online service computing power optimization method of claim 3, wherein: The specific process of the attribution analysis is to first locate the service node with the largest response time change on the key call path, determine the instance corresponding to the service node as the problem instance corresponding to the service node with the largest response time change on the key call path, and then perform the following two sub-steps in parallel: Step S3.1, horizontal comparison analysis: comparing the resource configuration, version number and core configuration item differences of the problem instance and similar healthy instances in the same time window; Step S3.2, longitudinal history analysis: compare the performance indicators of the problem instance at the current time with the configuration snapshot, with data from its own history of healthy periods, calculate the configuration deviation degree .

5. The big data-based online service computing power optimization method according to claim 4, characterized in that: The determination method of the historical health period in step S3.2 is: selecting a time period with the same periodic characteristics as the current time and a comprehensive score S continuously lower than the historical low percentile value from the historical data as the baseline period.

6. The big data-based online service computing power optimization method of claim 1, wherein: The specific method of retrieving a historical record with similar load characteristics in step S4 is: calculating the Euclidean distance of the current load characteristic vector and the load characteristic vector in the historical record, selecting the top K historical records with the smallest Euclidean distance, and taking the mode or the value after weighted averaging of the corresponding configuration as the recommended configuration.

7. The big data-based online service computing power optimization method according to claim 1, characterized in that: Also included is an effectiveness evaluation step for the log and observability code: periodically analyze the association of the call chain data and the application logs, if a call chain segment with high time consumption or high error rate is found, and the application log output corresponding to it is low level or missing, a suggestion is generated, prompting to supplement or upgrade the log level in the code area corresponding to the call chain segment with high time consumption or high error rate to enhance observability. 8.The online service computing power optimization method based on big data according to claim 7, characterized in that: The validity assessment step includes calculating an observability coverage score ; when the alert is triggered when the score is below a threshold value. wherein, is the time consumption of each trajectory node on the critical path, is the preset weight of the highest level of the log generated by the service instance corresponding to the trajectory node during processing the request, is the total number of trajectory nodes on the critical path. 9.The online service computing power optimization method based on big data according to claim 1, characterized in that: In step S3, if neither the horizontal comparative analysis nor the longitudinal historical analysis finds significant abnormalities, the root cause is speculated to be a performance degradation of dependent services or infrastructure problems, and a drill-down query is started on the performance indicators of the downstream dependent services, and the logic of steps S3-S4 is repeatedly executed until the bottom layer root cause service or infrastructure component is located.

Images