A software performance data analysis method, device and medium

Abstract

This application belongs to the field of computer science, and particularly relates to a software performance data analysis method, device, and medium. The method includes collecting, cleaning, and judging the data monitored in each time window in chronological order. During the data collection process, the data collection intensity can be dynamically adjusted by changing the error rate of the monitored data, making the data collection process flexible. This avoids server overload during the data collection process and prevents the data collection task from being hindered in abnormal scenarios.

Description

Technical Field

[0001] This application belongs to the field of computer science, and in particular relates to a method, device and medium for software performance data analysis. Background Technology

[0002] In the field of software performance monitoring, existing technical solutions are generally built around APM (Application Performance Management) tools. The core process is to pull all link tracing data in full and without discrimination through the APM tool interface, store it in general storage media after simple batch processing, and then perform anomaly detection based on fixed thresholds and display the data through independent views.

[0003] The main problems with existing technologies are the lack of stability of the monitoring system itself and the lack of data governance. Specifically, the APM data collection process has no protection mechanism. When the system experiences large-scale anomalies and a surge in error traces, the high-frequency full query of the APM server interface can easily overload the server and even make it unavailable, creating the risk of "downtime due to monitoring". Summary of the Invention

[0004] In view of this, embodiments of this application provide a software performance data analysis method, device, and medium that can solve the above-mentioned technical problems.

[0005] A first aspect of this application provides a software performance data analysis method, the method comprising: S1: Divide the monitoring period into several time windows; S2: For each time window, retrieve the basic data of all traces in that time window and calculate the percentage of erroneous traces to obtain the error rate; S3: Compare the error rate with a pre-set threshold, determine the data collection intensity of the current time window based on the comparison result, and perform data query with the new data collection intensity in the current time window to obtain the target data, so as to avoid server overload and downtime caused by full query. S4: Load preset data cleaning rules from the configuration center to clean the target data; S5: An anomaly detection model based on a combination of dynamic baseline and custom baseline is used to detect anomalies in the cleaned target data.

[0006] A second aspect of this application provides a terminal device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the software performance data analysis method.

[0007] A third aspect of this application provides a terminal-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the software performance data analysis method.

[0008] The beneficial effects of the embodiments of this application compared with the prior art are: the method provided by the present invention includes dividing the monitoring period into several time windows; For each time window, the basic data of all traces within that time window is retrieved, and the proportion of erroneous traces is calculated to obtain the error rate. The error rate is compared with a pre-set error rate threshold, and the data collection intensity for the current time window is determined based on the comparison result. Data is then queried in the current time window with the new data collection intensity to obtain the target data, thus avoiding server overload and downtime caused by full queries. Pre-set data cleaning rules are loaded from the configuration center to clean the target data. Anomaly detection is performed on the cleaned target data based on a dual-track judgment model combining dynamic baselines and custom baselines. In this application, the data monitored in each time window is collected, cleaned, and anomaly detected sequentially according to the order of each time window. During the data collection process, the data collection intensity can be dynamically adjusted based on changes in the error rate of the monitored data, making the data collection process flexible and thus avoiding server overload during data collection, which would hinder the sustainability of the data collection task in abnormal scenarios. Attached Figure Description

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

[0010] Figure 1 This is a schematic diagram illustrating the implementation process of the software performance data analysis method provided in this application embodiment; Figure 2 This is a schematic diagram of the terminal device provided in the embodiments of this application. Detailed Implementation

[0011] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0012] To illustrate the technical solution described in this application, specific embodiments are provided below.

[0013] Figure 1 This application illustrates a software performance data analysis method according to Embodiment 1, the method comprising: S1: Divide the monitoring period into several time windows; S2: For each time window, retrieve the basic data of all traces in that time window and calculate the percentage of erroneous traces to obtain the error rate; S3: Compare the error rate with the preset error rate threshold, determine the data collection intensity of the current time window based on the comparison result, and perform data query with the new data collection intensity in the current time window to obtain the target data, so as to avoid server overload and downtime caused by full query. S4: Load preset data cleaning rules from the configuration center to clean the target data; S5: An anomaly detection model based on a combination of dynamic baseline and custom baseline is used to detect anomalies in the cleaned target data.

[0014] In this embodiment, the method is executed in a terminal device, which can be an independent physical server or terminal, or a server cluster consisting of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud servers, cloud databases, cloud storage and CDN.

[0015] In this embodiment, the monitoring period is the latest data monitoring cycle, such as the previous day or the previous hour. During the monitoring cycle, the monitored data is automatically stored. The monitoring period is divided into several consecutive time windows of equal length, such as one window every 10 minutes. In this embodiment, for each time window, the `queryBasicTraces` interface of APM is called to retrieve the basic information of all traces in that window, including: `traceId`, `serviceName`, `endpointName`, `startTime`, `duration`, and `isError`. APM stands for Application Performance Management, a tool / technology system used to collect and analyze distributed system trace data for performance monitoring and troubleshooting. Here, it specifically refers to the application performance management tool that provides the `queryBasicTraces` interface. The `queryBasicTraces` interface is the basic trace data query interface provided by the APM tool, used to retrieve the basic core information of the trace, but does not include detailed trace information. A trace refers to the complete execution trajectory record of a single request in a distributed system. `traceId` is the trace identifier, a string that uniquely identifies a complete trace (full-link request), used to associate all related operation records of that request. `serviceName` is the service name, referring to the distributed system... The service node name that provides specific functions (such as user service, order service); endpointName: endpoint name, which can be translated as "interface name", refers to the specific business interface name (such as login interface, data query interface), and is the specific entry point for the service to provide functions to the outside world; startTime: start time, which can be translated as "request start time", refers to the timestamp of the request corresponding to this Trace that started execution, used to locate the time when the request was initiated; duration: duration, which can be translated as "request time", refers to the total time (usually in milliseconds) of the request corresponding to this Trace from start to finish, and is one of the core indicators for measuring interface performance; isError: error identifier, which can be translated as "error status identifier", is a boolean value (true / false), true indicates that the request corresponding to this Trace failed to execute, and false indicates that the request executed successfully.

[0016] In this embodiment, the data monitored in each time window is collected, cleaned, and anomaly detected one by one according to the order of each time window. During the data collection process, the data collection intensity can be dynamically adjusted by changing the error rate of the monitored data, making the data collection process flexible. This can avoid server overload during the data collection process and prevent the data collection task from being unsustainable in abnormal scenarios.

[0017] As a preferred embodiment, the basic data for each Trace includes isError; the percentage of erroneous Traces is calculated to obtain the error rate, which includes: Determine the number of traces corresponding to isError=true. ; The error rate is calculated using the following formula: Where R is the error rate. This represents the total number of traces retrieved within this time window.

[0018] Error rate thresholds include circuit breaker thresholds and sampling thresholds; comparing the error rate with a pre-set error rate threshold, determining the data acquisition intensity for the current time window based on the comparison result, and performing data queries with the new data acquisition intensity within the current time window includes: Determine if the error rate is greater than the circuit breaker threshold. If so, pause the Trace call for that time window, use only the base data of the already called error Trace as the target data, and generate a system overload alarm. If not, determine whether the error rate is greater than the sampling threshold; If the error rate is greater than the sampling threshold, random sampling is performed only on the already invoked error traces according to the preset sampling rate. For each sampled error trace, the queryTrace interface is called to obtain the corresponding error details. The basic data and corresponding error details of each error trace are summarized into target data, and an error rate increase alarm is generated. If the error rate is not greater than the sampling threshold, sample all the error traces that have been called, call the queryTrace interface for each error trace to obtain the corresponding error details, and summarize the basic data and corresponding error details of each error trace into the target data.

[0019] In this embodiment, the error rate threshold is pre-configured in the terminal device and is divided into two levels: the circuit breaker threshold (T1) and the sampling threshold (T2), where T2 is less than T1. The specific values ​​can be flexibly configured according to the actual business scenario. For example, the circuit breaker threshold T1 can be set to 5% and the sampling threshold T2 to 0.5%, which is used to dynamically adjust the APM data collection intensity under different error rate scenarios, avoid overloading the APM server during the collection process, and ensure the effective collection of core error data.

[0020] In the specific implementation process, after the terminal device starts the daily data collection task, it first divides the target date (such as T-1 day) into N consecutive time windows. The duration of each time window can be set according to the data collection accuracy requirements. For example, each time window is 10 minutes. Data collection and error rate threshold comparison are performed on each time window in turn.

[0021] For the current pending time window, the terminal device first calls the queryBasicTraces interface of the APM tool to retrieve the basic information of all traces within the time window. The basic information includes traceId (trace ID), serviceName (service name), endpointName (interface name), startTime (request start time), duration (request duration), and isError (error status indicator), where isError is a boolean value, true indicates that the request corresponding to the trace failed to execute, and false indicates that the request executed successfully.

[0022] After the data is retrieved, the terminal device performs statistics on the Trace data for that time window, calculates the proportion of the number of erroneous Traces with isError=true in the current window to the total number of Traces in that window, which is the error rate (R) of the current time window. Then, the error rate R is compared with the pre-set circuit breaker threshold T1 and sampling threshold T2 in turn. Based on the comparison results, the data acquisition intensity of the current time window is determined, and the corresponding acquisition operation is performed.

[0023] The first step is to determine whether the error rate R is greater than the circuit breaker threshold T1. If R > T1, it indicates that there is a large-scale anomaly in the current system and the number of error traces has surged. At this time, in order to protect the APM server from overload, the circuit breaker policy is executed, and the queryTrace interface (a high-consumption interface used to obtain trace details) for all traces within this time window is suspended. Only the basic data of the error traces that have been pulled through the queryBasicTraces interface is retained as the target data. At the same time, the terminal device automatically generates a system overload alarm and pushes it to the operation and maintenance management terminal to remind the operation and maintenance personnel to check the system anomaly in a timely manner. After completing the data collection operation of this time window, the processing flow of the next time window is entered.

[0024] The second step involves determining whether the error rate R is greater than the circuit breaker threshold T1 (R≤T1) if the error rate R is not greater than the sampling threshold T2. If R>T2, it indicates that the current system error rate has increased but has not reached the overload level. At this point, a sampling strategy is executed. Based on a preset sampling rate (e.g., 10%), random sampling is performed on the error traces retrieved through the queryBasicTraces interface. The sampling process uses a uniform random sampling algorithm to ensure that the sampling results are representative. For each sampled error trace, the queryTrace interface of the APM tool is called to obtain detailed error information of the error trace, including the error status code, exception stack, and error occurrence node. Subsequently, the basic data (traceId, serviceName, etc.) of each sampled error trace are associated and summarized with the corresponding error details as the target data for this time window. At the same time, an error rate increase alarm is generated and pushed to the operation and maintenance management terminal to remind operation and maintenance personnel to pay attention to changes in system performance.

[0025] Third, if the error rate R is not greater than the sampling threshold T2 (R≤T2), it indicates that the current system is running stably and the error rate is within the normal range. At this time, the full data collection strategy is executed, and all error traces that have been pulled through the queryBasicTraces interface are fully collected. For each error trace, the queryTrace interface of the APM tool is called to obtain the corresponding error details. The basic data of all error traces are associated and summarized one by one with the corresponding error details as the target data for this time window, ensuring that all error data is fully collected, providing comprehensive data support for subsequent performance analysis and troubleshooting.

[0026] After each time window completes the data collection operation according to the above process, the terminal device standardizes the target data of that window, unifies the time format, adds relevant fields such as error_type, and then appends it to a temporary file. After all time windows have been processed, the temporary file is atomically renamed to generate the original data file for that day, thus completing the entire data collection process.

[0027] In a preferred embodiment, the target data is a dataset, and the basic data of each Trace includes endpointName, serviceName, and duration; Data cleaning rules include endpoint name rules, service name rules, and dynamic feature rules; Data cleaning of the target data includes: S41: For each target data, select one Trace as the target Trace; S42: Determine whether the target Trace meets the endpoint name rules. If not, exclude the target Trace. S43: If yes, then determine whether the target Trace meets the service name rule; if not, then exclude the target Trace. S44: If yes, then determine whether the target Trace satisfies the dynamic feature rules; if not, then exclude the target Trace. S45: If so, preserve the target Trace; S46: Select another Trace as the target Trace, execute steps S42 to S45, and repeat this step until the cleaning of each target Trace in the target data is completed, and the cleaned target Trace is obtained.

[0028] Determining whether a target trace meets the endpoint name rules includes: Determine if the endpointName of the target Trace is exactly equal to any string in the exact_match list of the endpoint name rules; if not, filter the target Trace. If so, determine whether the endpointName of the target Trace starts with any string in the prefix_match list in the endpoint name rules; if not, filter the target Trace. If yes, then determine whether the endpointName of the target Trace matches any regular expression in the regex_match list of the endpoint name rules; if not, then filter the target Trace. If so, does the target Trace satisfy the endpoint name rules?

[0029] Determining whether a target trace meets the service name rules includes: Determine whether the serviceName of the target Trace matches the regular expression pattern in the service.regex_match list of the rules. If it does, filter the target Trace; otherwise, the target Trace satisfies the service name rule. Determining whether a target trace satisfies dynamic feature rules includes: Determine if the duration of the target Trace is less than the min_duration_threshold defined in the dynamic feature rules. If it is, filter the target Trace; otherwise, the target Trace satisfies the dynamic feature rules.

[0030] In this embodiment, the target data is a dataset, including multiple collected data points, namely the basic data and error details of each trace. In this embodiment, the endpoint naming rule is pre-entered into the terminal device via a declarative JSON configuration file. This rule is used to filter the collected target traces, removing noise data irrelevant to the business logic, ensuring that subsequent analysis focuses on core business interfaces. The rule includes three correlation judgment lists: the exact_match list, the prefix_match list, and the regex_match list. The functions and implementation details of each list are as follows: The `exact_match` list is a "precise match list" used to store endpoint name strings that need to be matched precisely. Only when the endpointName (interface name) of the target trace exactly matches any string in the list can it proceed to the next judgment stage. The `prefix_match` list is a "prefix match list" used to store prefix strings for endpoint names. The endpointName of the target trace must start with any string in the list to ensure that relevant interfaces of the same business type are filtered out. The `regex_match` list is a "regular expression match list" used to store preset regular expressions. The regular expression matching rules are used to further refine the filtering of endpoints that meet business requirements and filter out abnormal or irrelevant interfaces. `regex` (Regular Expression) is a "regular expression" that is a syntax rule used to match string patterns and can flexibly match endpoint names that conform to a specific format.

[0031] In the specific judgment process, after the terminal device obtains the collected target Trace (including basic data, including endpointName), it determines whether the target Trace meets the endpoint name rules in the following steps. The Trace can be retained only if all steps are met, and the Trace is directly filtered if any step is not met.

[0032] The first step is precise matching: The terminal device extracts the endpointName of the target Trace and performs a complete match comparison with each string in the exact_match list of the endpoint name rules. For example, if the exact_match list is configured as [" / user / login", " / order / pay"], if the endpointName of the target Trace is " / user / login", then a complete match is successful, and the process proceeds to the next step; if the endpointName is " / user / register" or " / order / pay1", neither of which is completely consistent with the strings in the list, it is determined that the rule is not met, and the target Trace is directly filtered out.

[0033] The second step is prefix matching: If the first step passes, the endpointName of the target trace is further extracted, and it is determined whether it begins with any string in the prefix_match list. For example, if the prefix_match list is configured as [" / user / ", " / order / "], and the endpointName of the target trace is " / user / login", it starts with " / user / ", and the match is successful, proceeding to the next step; if the endpointName is " / admin / login", it does not start with any prefix in the list, and the rule is not met, thus the target trace is filtered out.

[0034] The third step is regular expression matching: If the second step's matching passes, the target Trace's endpointName is matched against any regular expression in the `regex_match` list. For example, the `regex_match` list might be configured as `["^ / user / [az]+$", "^ / order / \\d+$"]`, where `^ / user / [az]+$` matches endpoints that begin with ` / user / ` followed by lowercase letters, and `^ / order / \\d+$` matches endpoints that begin with ` / order / ` followed by numbers. If the target Trace's endpointName is ` / user / login`, the first regular expression is matched, and the matching passes. If the endpointName is ` / order / 12345`, the second regular expression is matched, and the matching passes. If the endpointName is ` / user / 123`, no regular expression is matched, and the target Trace is filtered out because it does not meet the rules.

[0035] The fourth step is the final determination: If the target trace passes the above three determinations in sequence, that is, it simultaneously satisfies the exact match (exact_match), prefix match (prefix_match), and regular expression match (regex_match), then the target trace is determined to meet the endpoint name rule, and the trace is retained and passed to the subsequent exception determination stage; if any determination step fails, the trace is directly filtered and does not enter the subsequent processing flow, thereby achieving accurate screening of core business traces and improving data quality.

[0036] In this embodiment, both the service name rule and the dynamic feature rule are pre-entered into the terminal device through a declarative JSON configuration file. Together with the endpoint name rule mentioned above, they further filter target traces and remove noisy data, ensuring that the retained traces are all data that are related to the core business and have analytical value.

[0037] "Service Name" refers to the name of the service node providing specific functions in the distributed system (such as user service, order service); the "service.regex_match" list is the "service regular expression matching list", which is the core configuration item of the service name rule. It is used to store preset regular expression patterns (regular expression patterns are string matching rules based on regular expressions (regex). They define the format, start, end and other features of the string to be matched through specific syntax symbols (such as ^, *, etc.), which can flexibly and accurately filter strings that match specific patterns), and are used to filter non-core services that need to be filtered; "duration" refers to the total time (usually in milliseconds) of the request corresponding to the Trace from start to finish. It is the core judgment indicator of dynamic feature rules; "min_duration_threshold" is the "minimum time threshold", which is the core configuration parameter of dynamic feature rules and is used to define the lower limit of request time with analytical value.

[0038] The target trace must pass the judgment of service name rules and dynamic feature rules in sequence. If the condition is not met in any step, the trace is directly filtered out. Only after both conditions are met can it proceed to the next processing stage. The specific judgment steps are as follows: The core purpose of service name rules is to filter traces corresponding to non-core business services (such as internal middleware services and health check services), retaining only traces of core business services. In practice, the terminal device extracts the serviceName of the target trace and compares it against all regular expression patterns in the service.regex_match list within the service name rules. The matching logic is consistent with the endpoint name regular expression matching described earlier, both based on string pattern matching rules using regular expressions.

[0039] For example, the `service.regex_match` list is configured as `["^middleware.*", "^health.*"]`, where `"^middleware.*"` matches all service names starting with "middleware" (e.g., `middleware_redis`, `middleware_mq`, both internal middleware services), and `"^health.*"` matches all service names starting with "health" (e.g., `health_check`, a health check service). If the target trace's `serviceName` is "middleware_redis" and matches the first regular expression pattern in the list, it is determined that the service name rule is not met, and the trace is directly filtered. If the target trace's `serviceName` is "user_service" (user service) or "order_service" (order service) and does not match any regular expression pattern in the list, then the target trace is determined to meet the service name rule, and enters the dynamic feature rule determination stage.

[0040] The core purpose of dynamic feature rules is to filter traces that are too short to be of analytical value (such as empty or invalid requests with quick responses), ensuring that the retained traces reflect the business performance status. In practice, the terminal device extracts the duration (request time) of the target trace and compares it with the min_duration_threshold (minimum time threshold) defined in the dynamic feature rules. The minimum time threshold can be configured according to actual business needs, for example, set to 50 milliseconds.

[0041] If the duration of the target trace is 30 milliseconds, which is less than the preset min_duration_threshold (50 milliseconds), it means that the request time is too short and has no performance analysis value. It is determined that the dynamic feature rule is not met and the trace is directly filtered out. If the duration of the target trace is 80 milliseconds, which is greater than or equal to min_duration_threshold (50 milliseconds), it means that the request has performance analysis value and the target trace is determined to meet the dynamic feature rule.

[0042] In summary, the target trace must pass the judgment of service name rules and dynamic feature rules in succession. That is, it must not match any regular expression pattern in the service.regex_match list, and the duration must not be less than min_duration_threshold to be determined to satisfy both types of rules. In this case, it will be retained and passed to the subsequent anomaly judgment stage. If either step fails to meet the requirements, it will be directly filtered out, which will further improve the data quality and provide accurate and valuable core data support for subsequent performance analysis and troubleshooting.

[0043] In a preferred embodiment, the terminal device includes a storage and service layer, which is the core carrier for data storage, association, and querying in the terminal device system. It is responsible for receiving target data and providing stable and consistent data support for the visualization platform. It contains four main entities, and the functions and relationships of each entity are as follows: The dimension table (dim_service_hierarchy, 301) is a static mapping table, which is used to store static association information related to storage services. Its fields include service_id (primary key, used to uniquely identify the service), service_name (service name), business_line (business line), and team (team to which it belongs). The service_name field is used to establish a relationship with the fact table, realizing the binding of technical dimension data and business organization dimension data.

[0044] The fact table (daily_interface_performance, 302) is the core data storage table, partitioned by the date field. It mainly stores daily interface-level performance metrics data, with fields including id (unique identifier), date, service_id (foreign key, related to the service_id of dimension table 301), endpoint (interface name), total_requests (total number of requests), p95_response_time (P95 response time), failure_rate (failure rate), etc. Its data comes directly from the output of the data cleaning process described above and forms the basis for subsequent data queries and analysis.

[0045] The hotspot view (agg_daily_hotspot, 303) is a virtual view, not a pre-stored entity table. Instead, it is a pre-query statement defined using the SQL CREATE VIEW statement. Logically, it is related to dimension table 301 and fact table 302. Its core function is to calculate a real-time ranking of hot interfaces. For example, it can retrieve the top 20 interfaces by request volume using the query logic "SELECT ... ORDER BY total_requests DESCLIMIT 20".

[0046] During the data query process, when the visualization platform (400) requests "Today's Hot Topics TOP20", the database system does not read the pre-stored results, but dynamically executes the SQL statement behind the hot topic view 303, immediately associates the dimension table 301 and the fact table 302, and returns the results after completing the data sorting, filtering and restriction operations, ensuring that the list data is completely consistent with the underlying detailed data and ensuring data accuracy.

[0047] When the page loads, the front-end automatically calls the back-end API to synchronously retrieve three types of data: yesterday's global KPI metrics, performance trend chart data, and "Global Risk Ranking" data provided by the 303 hotspot view. Specifically, the "Interface Path" cell for each API data entry in the ranking is wrapped as a hyperlink carrying parameters during front-end rendering, with an example format as follows: / api / order / submit The link contains core parameters such as business line, service name, and interface name, providing contextual support for subsequent drill-down operations.

[0048] The one-click linkage from the overview page to the in-depth analysis page is as follows: a. The user clicks the target interface hyperlink in the performance overview page (401) list; b. The browser automatically navigates to the in-depth analysis page (402) based on the URL parameters in the hyperlink; c. When the in-depth analysis page (402) is initialized, the front-end code automatically parses the query parameters such as business lines, services, and interfaces in the URL; d. The front-end automatically fills the parsed parameters into the corresponding filter components (business line drop-down box, service drop-down box, interface input box) on the page, without requiring the user to manually input; e. After the filter is filled, the front-end automatically triggers a series of API requests to obtain detailed data such as the exception list, related lists, and data coverage under the corresponding dimension of the interface; f. After receiving the request, the back-end queries the fact table 302 of the storage and service layer according to the parameters, and obtains complete data by associating it with the dimension table 301, and returns it to the front-end after processing; g. The front-end receives the data and completes the rendering, presenting the in-depth analysis page focusing on the specific problem interface, realizing rapid positioning from macro-level exceptions to micro-level details.

[0049] As a preferred embodiment, the anomaly detection of the cleaned target data based on a dual-track judgment model combining dynamic baselines and custom baselines includes: For each target data point, determine the current performance metric value of the target data; Based on historical data from the same period of the target data, the dynamic baseline value and fluctuation range of the performance index are calculated using a sliding window algorithm to determine whether the current performance index value exceeds the fluctuation range. Call the custom baseline configuration of the preset business interface to determine whether the current performance indicator value exceeds the custom threshold of the corresponding interface; If the results of the two baselines are merged, the target data is marked as abnormal if either baseline result is abnormal; otherwise, it is marked as normal data. For marked abnormal data, associate it with the corresponding link tracing basic information, generate an abnormality detail log, synchronously trigger the corresponding level alarm, and complete the abnormality judgment process.

[0050] In this embodiment, the core performance metrics of the current target data are determined. For each piece of target data, its core performance metrics are extracted one by one, including but not limited to: total number of interface requests, request start time, response time, failure status identifier (isError), service name, interface path, etc. All metrics are extracted strictly according to a unified format to ensure data standardization and consistency, providing a reliable data foundation for subsequent anomaly detection and preventing judgment bias caused by missing metrics or inconsistent formats. Among them, the failure status identifier (isError) is a Boolean value, where true indicates that the request execution failed and false indicates that the request executed normally. This identifier is the core basis for subsequent error rate calculation and anomaly detection.

[0051] The second step involves calculating and determining the dynamic baseline and fluctuation range based on the target data. For each target data point and its corresponding business scenario, historical data from the same period within the last 30 days is selected as a reference. A sliding window algorithm is used to calculate the baseline, with the window duration set at 10 minutes per window to ensure the independence and integrity of the data within each time window. During the calculation, the total number of requests within the window is first counted, followed by the number of erroneous requests where isError is true. The error rate of the current window is calculated by dividing the number of erroneous requests by the total number of requests. Simultaneously, the fluctuation range of "dynamic baseline value ± 2 standard deviations" is determined by combining this with the standard deviation of historical data. This range represents the normal range for the current performance indicator, ensuring that the baseline value closely reflects the actual business operation status and avoiding rigid judgments caused by fixed thresholds.

[0052] The third step is to conduct a dual-baseline comparison and judgment. A preset custom baseline configuration is invoked, and for each business interface corresponding to the target data, its own custom threshold is matched (the threshold settings differ for different interfaces due to varying business importance and processing complexity; for example, the response time threshold for the login interface is set to 500ms, and the response time threshold for the data export interface is set to 2000ms). Simultaneously, the current performance metrics are compared with the normal range of the dynamic baseline, forming a dual verification mechanism.

[0053] During the specific comparison process, if the performance indicators of the current target data exceed the normal fluctuation range of the dynamic baseline or exceed the custom threshold of the corresponding interface, it is judged as abnormal; if both comparisons meet the requirements, it is judged as normal. It should be clarified here that the dynamic baseline and the custom baseline complement and work together. The dynamic baseline ensures the rationality of the data, while the custom baseline adapts to the personalized needs of different interfaces, avoiding misjudgments or omissions caused by a single baseline, and ensuring the scientific nature of the judgment results.

[0054] The fourth step is to integrate the results of the dual baseline assessment. Strictly adhering to the principle that "any anomaly constitutes an overall anomaly," if either the dynamic baseline comparison or the custom baseline comparison is deemed anomaly, the target data is marked as anomalous; if neither comparison shows anomalies, it is marked as normal data. For anomalous data, its corresponding link tracing information is further correlated, supplementing and improving details such as error type and occurrence node to ensure that the specific cause of each anomalous data point can be traced.

[0055] The fifth step is abnormal data processing and alarm push. For target data marked as abnormal, the system automatically generates a detailed abnormal report, including abnormal indicators, the time of occurrence of the abnormality, the service nodes involved, and a preliminary analysis of the cause of the error. At the same time, according to the severity of the abnormality, the system triggers the corresponding level of alarm (general abnormalities trigger a reminder alarm, and severe abnormalities trigger an emergency alarm). The alarm information is pushed to the operation and maintenance management terminal, clearly indicating the type of abnormality, the scope of impact, and handling suggestions, so as to facilitate the operation and maintenance personnel to respond quickly and troubleshoot problems.

[0056] Step 6: Data Archiving and Subsequent Support. All target data (normal and abnormal) are archived by date and uniformly named in the format of "Year-Month-Original Data" to ensure data traceability. At the same time, complete judgment records are retained, including the comparison process, judgment results, alarm information, etc., to provide comprehensive data support for subsequent performance analysis and fault review, and also to provide a reference for subsequent baseline threshold adjustments and business process optimization.

[0057] This implementation method, through clear step division, detailed parameter description, and a sound exception handling mechanism, not only satisfies all the requirements of the claims, but also takes into account the flexibility of actual business scenarios. It ensures that those skilled in the art can understand and implement this technical solution without creative effort, while effectively balancing the comprehensiveness of data collection and the operational pressure on the server side, ensuring the stable and efficient operation of the system.

[0058] Embodiment 2 of this application provides a terminal device, including a memory and a processor. The memory stores a computer program, and when the computer program is executed by the processor, it causes the processor to perform the steps of the software performance data analysis method, specifically including: S1: Divide the monitoring period into several time windows; S2: For each time window, retrieve the basic data of all traces in that time window and calculate the percentage of erroneous traces to obtain the error rate; S3: Compare the error rate with the preset error rate threshold, determine the data collection intensity of the current time window based on the comparison result, and perform data query with the new data collection intensity in the current time window to obtain the target data, so as to avoid server overload and downtime caused by full query. S4: Load preset data cleaning rules from the configuration center to clean the target data; S5: An anomaly detection model based on a combination of dynamic baseline and custom baseline is used to detect anomalies in the cleaned target data.

[0059] Embodiment 3 of this application provides a terminal-readable storage medium storing a computer program. When the computer program is executed by a processor, the processor performs the steps of the software performance data analysis method described above. S1: Divide the monitoring period into several time windows; S2: For each time window, retrieve the basic data of all traces in that time window and calculate the percentage of erroneous traces to obtain the error rate; S3: Compare the error rate with the preset error rate threshold, determine the data collection intensity of the current time window based on the comparison result, and perform data query with the new data collection intensity in the current time window to obtain the target data, so as to avoid server overload and downtime caused by full query. S4: Load preset data cleaning rules from the configuration center to clean the target data; S5: An anomaly detection model based on a combination of dynamic baseline and custom baseline is used to detect anomalies in the cleaned target data.

[0060] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0061] It should be understood that, when used in this application specification, the term "comprising" indicates the presence of the described feature, integral, step, operation, element, and / or component, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof.

[0062] It should also be understood that the term “and / or” as used in this application specification means any combination of one or more of the associated listed items, as well as all possible combinations, and includes such combinations.

[0063] As used in this application specification, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [the described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [the described condition or event] is detected," or "in response to detection of [the described condition or event]."

[0064] Furthermore, in the description of this application, the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance. It should also be understood that although the terms "first," "second," etc., are used in the text to describe various elements in some embodiments of this application, these elements should not be limited by these terms. These terms are merely used to distinguish one element from another. For example, a first table may be named a second table, and similarly, a second table may be named a first table, without departing from the scope of the various described embodiments. Both the first table and the second table are tables, but they are not the same table.

[0065] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0066] The software performance data analysis method provided in this application can be applied to terminal devices such as mobile phones, tablets, wearable devices, in-vehicle devices, augmented reality (AR) / virtual reality (VR) devices, laptops, ultra-mobile personal computers (UMPCs), netbooks, and personal digital assistants (PDAs). This application does not impose any restrictions on the specific type of terminal device.

[0067] For example, the terminal device may be a station (STAION, ST) in a WLAN, a cellular phone, a cordless phone, a Session Initiation Protocol (SIP) phone, a Wireless Local Loop (WLL) station, a Personal Digital Assistant (PDA) device, a handheld device with wireless communication capabilities, a computing device or other processing device connected to a wireless modem, an in-vehicle device, a vehicle networking terminal, a computer, a laptop computer, a handheld communication device, a handheld computing device, a satellite wireless device, a wireless modem card, a set-top box (STB), customer premises equipment (CPE), and / or other devices used for communication over a wireless system, as well as next-generation communication systems, such as mobile terminals in 5G networks or mobile terminals in future evolved Public Land Mobile Network (PLMN) networks.

[0068] As an example and not a limitation, when the terminal device is a wearable device, the term "wearable device" can also refer to any device that utilizes wearable technology to intelligently design and develop everyday wearables, such as glasses, gloves, watches, clothing, and shoes. Wearable devices are portable devices worn directly on the body or integrated into a user's clothing or accessories. Wearable devices are not merely hardware devices; they achieve powerful functions through software support, data interaction, and cloud interaction. Broadly defined, wearable smart devices include those with comprehensive functions, large sizes, and the ability to perform complete or partial functions without relying on a smartphone, such as smartwatches or smart glasses, as well as those focused on a specific application function that require interaction with other devices such as smartphones, such as various smart bracelets and smart jewelry for vital sign monitoring.

[0069] Figure 2This is a schematic diagram of the structure of a terminal device provided in an embodiment of this application. For example... Figure 2 As shown, the terminal device of this embodiment includes: at least one processor ( Figure 2 Only one is shown in the diagram, and a memory is stored in which a computer program executable on the processor is stored. When the processor executes the computer program, it implements the steps in the various software performance data analysis method embodiments described above, for example... Figure 1 Steps S1 to S5 are shown.

[0070] The terminal device may be a desktop computer, laptop, handheld computer, or cloud server, etc. The terminal device may include, but is not limited to, a processor and memory. Those skilled in the art will understand that... Figure 2 This is merely an example of a terminal device and does not constitute a limitation on the terminal device. It may include more or fewer components than shown, or combine certain components, or different components. For example, the terminal device may also include input transmission devices, network access devices, buses, etc.

[0071] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0072] In some embodiments, the memory may be an internal storage unit of the terminal device, such as a hard drive or RAM. The memory may also be an external storage device of the terminal device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory may include both internal and external storage units. The memory is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory can also be used to temporarily store data that has been sent or will be sent.

[0073] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0074] This application provides a computer program product that, when run on a mobile terminal device, enables the mobile terminal device to implement the steps described in the above-described method embodiments.

[0075] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.

[0076] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0077] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0078] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0079] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A software performance data analysis method, characterized in that, The method includes: S1: Divide the monitoring period into several time windows; S2: For each time window, retrieve the basic data of all traces in that time window and calculate the percentage of erroneous traces to obtain the error rate; S3: Compare the error rate with the preset error rate threshold, determine the data collection intensity of the current time window based on the comparison result, and perform data query with the new data collection intensity in the current time window to obtain the target data, so as to avoid server overload and downtime caused by full query. S4: Load preset data cleaning rules from the configuration center to clean the target data; S5: An anomaly detection model based on a combination of dynamic baseline and custom baseline is used to detect anomalies in the cleaned target data.

2. The method according to claim 2, characterized in that, The basic data for each trace includes isError; the percentage of erroneous traces is calculated to obtain the error rate, which includes: Determine the number of traces corresponding to isError=true. ; The error rate is calculated using the following formula: Where R is the error rate. This represents the total number of traces retrieved within this time window.

3. The method according to claim 2, characterized in that, Error rate thresholds include circuit breaker thresholds and sampling thresholds; comparing the error rate with a pre-set error rate threshold, determining the data acquisition intensity for the current time window based on the comparison result, and performing data queries with the new data acquisition intensity within the current time window includes: Determine if the error rate is greater than the circuit breaker threshold. If so, pause the Trace call for that time window, use only the base data of the already called error Trace as the target data, and generate a system overload alarm. If not, determine whether the error rate is greater than the sampling threshold; If the error rate is greater than the sampling threshold, random sampling is performed only on the already invoked error traces according to the preset sampling rate. For each sampled error trace, the queryTrace interface is called to obtain the corresponding error details. The basic data and corresponding error details of each error trace are summarized into target data, and an error rate increase alarm is generated. If the error rate is not greater than the sampling threshold, sample all the error traces that have been called, call the queryTrace interface for each error trace to obtain the corresponding error details, and summarize the basic data and corresponding error details of each error trace into the target data.

4. The method according to claim 3, characterized in that, The target data is a dataset, and the basic data for each Trace includes endpointName, serviceName, and duration. Data cleaning rules include endpoint name rules, service name rules, and dynamic feature rules; Data cleaning of the target data includes: S41: For each target data, select one Trace as the target Trace; S42: Determine whether the target Trace meets the endpoint name rules. If not, exclude the target Trace. S43: If yes, then determine whether the target Trace meets the service name rule; if not, then exclude the target Trace. S44: If yes, then determine whether the target Trace satisfies the dynamic feature rules; if not, then exclude the target Trace. S45: If so, preserve the target Trace; S46: Select another Trace as the target Trace, execute steps S42 to S45, and repeat this step until the cleaning of each target Trace in the target data is completed, and the cleaned target Trace is obtained.

5. The method according to claim 4, characterized in that, Determining whether a target trace meets the endpoint name rules includes: Determine if the endpointName of the target Trace is exactly equal to any string in the exact_match list of the endpoint name rules; if not, filter the target Trace. If so, determine whether the endpointName of the target Trace starts with any string in the prefix_match list in the endpoint name rules; if not, filter the target Trace. If yes, then determine whether the endpointName of the target Trace matches any regular expression in the regex_match list of the endpoint name rules; if not, then filter the target Trace. If so, does the target Trace satisfy the endpoint name rules? 6. The method according to claim 4, characterized in that, Determining whether a target trace meets the service name rules includes: Determine whether the serviceName of the target Trace matches the regular expression pattern in the service.regex_match list of the rules. If it does, filter the target Trace; otherwise, the target Trace satisfies the service name rule. Determining whether a target trace satisfies dynamic feature rules includes: Determine if the duration of the target Trace is less than the min_duration_threshold defined in the dynamic feature rules. If it is, filter the target Trace; otherwise, the target Trace satisfies the dynamic feature rules.

7. The method according to claim 4, characterized in that, Anomaly detection based on a dual-track judgment model combining dynamic and custom baselines for cleaned target data includes: For each target data point, determine the current performance metric value of the target data; Based on historical data from the same period of the target data, the dynamic baseline value and fluctuation range of the performance index are calculated using a sliding window algorithm to determine whether the current performance index value exceeds the fluctuation range. Call the custom baseline configuration of the preset business interface to determine whether the current performance indicator value exceeds the custom threshold of the corresponding interface; If the results of the two baselines are merged, the target data is marked as abnormal if either baseline result is abnormal; otherwise, it is marked as normal data. For marked abnormal data, associate it with the corresponding link tracing basic information, generate an abnormality detail log, synchronously trigger the corresponding level alarm, and complete the abnormality judgment process.

8. A terminal device, characterized in that, The method includes a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor causes the processor to perform the steps of the software performance data analysis method according to any one of claims 1 to 7.

9. A terminal-readable storage medium, characterized in that, The terminal-readable storage medium stores a computer program, which, when executed by a processor, causes the processor to perform the steps of the software performance data analysis method according to any one of claims 1 to 7.

Images