Performance indicator monitoring method and related devices

Abstract

This application discloses a performance indicator monitoring method and related equipment to improve operation and maintenance efficiency. The method includes: in response to a terminal accessing a preset monitoring page, determining the terminal's model; sending a quota acquisition request for the monitoring page to a server, the quota acquisition request including the terminal's model; if a request approval message is received from the server, acquiring performance indicator data of the terminal running the monitoring page, the request approval message being determined based on the remaining monitoring quota of the model under the monitoring page, the remaining monitoring quota being the difference between the total monitoring quota of the model under the monitoring page and the quota acquisition request approved by the model under the monitoring page; and sending the performance indicator data of the terminal running the monitoring page to the server.

Description

Technical Field

[0001] This application relates to the field of software operation and maintenance, and in particular to methods and equipment for monitoring performance indicators. Background Technology

[0002] For apps with a large user base on app stores, maintaining their normal operation through app maintenance is particularly important. During the development phase, developers can deploy the app in different runtime environments to monitor its performance metrics and prevent crashes in those environments. Once an app is downloaded by users, it operates in a complex and diverse environment.

[0003] Because the runtime environments that can be tested during the development phase cannot cover all runtime environments available on the market, current operational methods typically involve capturing performance metrics data from the runtime environment when the app crashes and reporting it to the server for developers to analyze the cause of the problem.

[0004] In practical applications, relying solely on performance metrics data from the runtime environment at the time of an app crash requires developers to spend a significant amount of time locating the code that initially caused the performance anomalies, leading to low operational efficiency. Therefore, there is an urgent need for a technical solution that can improve developers' operational efficiency. Summary of the Invention

[0005] This application provides a method and related equipment for monitoring performance indicators to improve operational efficiency.

[0006] The first aspect of this application provides a performance indicator monitoring method, applied to a terminal, including:

[0007] In response to the terminal's access to a preset monitoring page, the model of the terminal is determined;

[0008] Send a quota acquisition request to the server for the monitoring page, the quota acquisition request including the model of the terminal;

[0009] If the server sends a request pass information, the performance index data of the terminal running the monitoring page is obtained. The request pass information is determined based on the remaining monitoring quota of the model under the monitoring page. The remaining monitoring quota is the difference between the total monitoring quota of the model under the monitoring page and the quota acquisition request passed by the model under the monitoring page.

[0010] The performance metrics data of the terminal running the monitoring page are sent to the server.

[0011] In one specific implementation, the step of obtaining performance indicator data of the terminal running the monitoring page if a request pass information is received from the server includes:

[0012] If the request passed information sent by the server is received, then the target monitoring node set corresponding to the terminal model is determined from the multiple preset monitoring node sets corresponding to the monitoring page. The target monitoring node set includes multiple target monitoring nodes, and each preset monitoring node refers to the time node when the monitoring page runs to any state.

[0013] If the monitoring page runs to any of the target monitoring nodes, the performance metrics data of the terminal running the monitoring page are obtained.

[0014] In one specific implementation, if the monitoring page runs to any of the target monitoring nodes, then obtaining the performance index data of the terminal running the monitoring page includes:

[0015] Obtain the monitoring configuration information of any of the target monitoring nodes, wherein the monitoring configuration information includes monitoring latency and / or performance acquisition duration;

[0016] If the monitoring page runs to any of the target monitoring nodes, the performance index data of the terminal running the monitoring page is obtained according to the monitoring configuration information of any of the target monitoring nodes.

[0017] In one specific implementation, the performance metric data includes performance metric values ​​for at least one dimension. After obtaining the performance metric data of the terminal running the monitoring page, the method further includes:

[0018] If the difference between the performance index value of any dimension and the corresponding historical average performance index is greater than the difference threshold of the monitoring page in any dimension, then the any dimension is determined to be an abnormal dimension, and the corresponding target monitoring node is determined to be an abnormal node. The corresponding historical average performance index is the historical average performance index of the monitoring page in any dimension, and the corresponding target monitoring node is the target monitoring node that collects the performance index value of any dimension.

[0019] An anomaly reporting information is sent to the server. The anomaly reporting information includes the anomaly dimension, the performance index value of the anomaly dimension, the anomaly node, and multiple operating environment information of the terminal.

[0020] A second aspect of this application provides a performance indicator monitoring method applied to a server, comprising:

[0021] The receiving terminal sends a quota acquisition request for the monitoring page, the quota acquisition request including the model of the terminal;

[0022] Based on the preset quota release strategy, determine the remaining monitoring quota for the model under the monitoring page;

[0023] If the remaining monitoring quota is not zero, a request to pass information is sent to the terminal. The remaining monitoring quota is the difference between the total monitoring quota of the model under the monitoring page and the quota acquisition request passed by the model under the monitoring page.

[0024] The system receives performance metrics data of the terminal running the monitoring page, the performance metrics data being obtained by the terminal through information based on the request.

[0025] In one specific implementation, the quota release strategy is to release quotas in batches at equal proportions, and the method further includes:

[0026] Obtain the pending request threshold and single batch release quota corresponding to the monitoring page;

[0027] In response to receiving the quota acquisition request, the number of pending requests corresponding to the model on the monitoring page is obtained, and the number of pending requests is the number of quota acquisition requests to be processed.

[0028] If the number of pending requests is not less than the pending request threshold, then the new total monitoring quota for the model on the monitoring page is determined to be the sum of the old total monitoring quota for the model on the monitoring page and the single batch release quota.

[0029] In one specific implementation, the performance metric data includes performance metric values ​​for at least one dimension, and the method further includes:

[0030] Receive each anomaly report information sent by at least one terminal, each anomaly report information including an anomaly dimension, a performance index value of the anomaly dimension, an anomaly node, and multiple operating environment information of the terminal;

[0031] Each abnormal reporting information sent by the at least one terminal is classified to obtain an abnormal reporting information set corresponding to each preset statistical dimension, wherein the preset statistical dimension includes at least one of the abnormal dimensions and / or at least one of the abnormal nodes;

[0032] The N most frequently occurring runtime environment information items in each anomaly report set are determined as the target anomaly cause for the preset statistical dimension corresponding to each anomaly report set.

[0033] In one specific implementation, the method further includes:

[0034] The performance index data sent by each terminal in the most recent M historical monitoring periods, which is used to run the monitoring page, are determined as candidate performance index data. The candidate performance index data includes candidate performance index values ​​of at least one dimension.

[0035] Based on at least some of the candidate performance index values ​​of the monitoring page in any dimension, the historical average performance index value of the monitoring page in any dimension is determined.

[0036] A third aspect of this application provides a computer device, including:

[0037] Central processing unit, memory, and input / output interfaces;

[0038] The memory is either a short-term storage memory or a persistent storage memory;

[0039] The central processing unit is configured to communicate with the memory and execute instructions in the memory to perform the method described in the first or second aspect.

[0040] A fourth aspect of this application provides a computer program product containing instructions that, when run on a computer, cause the computer to perform the method described in the first or second aspect.

[0041] A fifth aspect of this application provides a computer storage medium storing instructions that, when executed on a computer, cause the computer to perform the method described in the first or second aspect.

[0042] As can be seen from the above technical solutions, the embodiments of this application have the following advantages: The application's monitoring page is pre-configured. When a terminal accesses the application's monitoring page, a quota acquisition request is initiated to obtain the terminal's performance metrics data. In other words, the embodiments of this application can obtain the terminal's performance metrics data when the terminal accesses a specific page in the application, thereby achieving page-level monitoring of the application's operation. The implementation of page-level monitoring allows developers to narrow down the code location causing abnormal App data to the code location corresponding to the page with abnormal performance metrics data. Furthermore, the embodiments of this application only obtain the terminal's performance metrics data to monitor the application's operation after the server has responded with a request approval message. That is, by controlling the total monitoring quota for different device models under the monitoring page, as much performance metrics data of the App running on different device models as possible can be obtained without exceeding the server's processing capacity, achieving more comprehensive performance monitoring. Attached Figure Description

[0043] Figure 1This is a schematic diagram of a framework for the performance indicator monitoring method disclosed in an embodiment of this application;

[0044] Figure 2 This is a schematic diagram of an interface for configuring monitoring parameters disclosed in an embodiment of this application.

[0045] Figure 3 This is a flowchart illustrating the performance indicator monitoring method disclosed in an embodiment of this application;

[0046] Figure 4 This is a timing diagram illustrating the performance indicator monitoring disclosed in the embodiments of this application;

[0047] Figure 5 This is a schematic diagram of an interface for visual analysis disclosed in an embodiment of this application.

[0048] Figure 6 This is another schematic diagram of the visualization analysis interface disclosed in the embodiments of this application;

[0049] Figure 7 This is another schematic diagram of the visualization analysis interface disclosed in the embodiments of this application;

[0050] Figure 8 This is another schematic diagram of the visualization analysis interface disclosed in the embodiments of this application;

[0051] Figure 9 This is another schematic diagram of the visualization analysis interface disclosed in the embodiments of this application;

[0052] Figure 10 This is a schematic diagram of the structure of a computer device disclosed in an embodiment of this application. Detailed Implementation

[0053] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0054] This application provides a method and related equipment for monitoring performance indicators to improve operational efficiency.

[0055] To better implement the performance indicator monitoring method of this application embodiment, this application embodiment provides client service, background monitoring service and web service.

[0056] Specifically, developers implement the client service by deploying a client SDK on the terminal. Before using the client service, developers can configure performance monitoring parameters (including but not limited to monitoring pages, target monitoring nodes, and monitoring configuration information) through the web service. Then, when a terminal with the client SDK deployed runs the monitoring page configured in the web service, the terminal needs to request a monitoring quota from the backend monitoring service. Only after receiving a request approval message from the backend monitoring service (determined based on the quota service) can the terminal collect performance indicator data when running the monitoring page according to the target monitoring node and monitoring configuration information configured in the web service. Simultaneously, local anomaly analysis is performed on the terminal's performance indicator data, and anomaly reporting information is sent to the backend monitoring service. The backend monitoring service obtains the anomaly reporting information and performance indicator data sent by each terminal based on a data index. It then performs anomaly clustering on the performance of different terminal models running different monitoring pages, and finally analyzes and calculates to determine factors that may affect terminal performance. The performance indicator data and anomaly reporting information stored in the backend monitoring service are implemented based on a business database, and the backend monitoring service interacts with the web service and the terminal via APIs. Additionally, users can configure parameters, view performance metrics (obtained from the backend monitoring service), and access an anomaly list (various anomaly reports and analysis results obtained from the backend monitoring service) through a visual interface deployed via the web service. Finally, the web client can send the anomaly attribution results obtained from the backend monitoring service to third-party systems used by developers, enabling them to adjust monitoring configurations and software code based on the anomaly attribution results.

[0057] In some specific implementations, the visual parameter configuration interface provided by the Web service can be as follows: Figure 2 As shown, a certain number (configuration quota) of monitoring nodes (node ​​names) are configured for different pages of the software. Then, corresponding difference thresholds are configured for different performance metrics (such as physical memory, virtual memory, threads, frame rate, CPU, and file descriptors). Monitoring for a specific page is enabled via a monitoring status switch. If the monitoring status switch for any page is enabled, then that page is a monitored page; otherwise, it is not.

[0058] Please see Figure 3 This application provides a performance indicator monitoring method, including the following steps:

[0059] 301. In response to the terminal's access to the preset monitoring page, determine the terminal's model.

[0060] Considering that anomalies experienced by an app on a particular device model are likely to occur on other devices of the same model, performing performance monitoring on every terminal accessing the monitoring page, regardless of device model, would result in a large amount of similar performance metric data. To avoid meaninglessly consuming server resources, the performance metric monitoring scheme implemented in this application configures a certain total monitoring quota for different device models under each monitoring page, limiting the number of times performance metrics for each device model can be monitored on each monitoring page.

[0061] The monitoring page refers to any page within the app, including but not limited to pages that operations and maintenance personnel (or developers) believe may exhibit performance anomalies or cause the app to crash. Information from the monitoring page is recorded in the client SDK. When a user accesses (any) preset monitoring page through the client SDK deployed on a terminal, the terminal model needs to be obtained first to determine whether to monitor the aforementioned terminal.

[0062] 302. The terminal sends a quota acquisition request to the server for the monitoring page. The quota acquisition request includes the terminal's model.

[0063] The quota acquisition request is used to determine whether the device model corresponding to the aforementioned terminal on the monitoring page is eligible for performance metric monitoring. Since all terminals need to send a data acquisition request to the server before performing performance metric monitoring, the server can limit the number of performance metric monitoring sessions for different device models on the aforementioned monitoring page by either rejecting the request or by using a quota acquisition request.

[0064] 303. The server determines the remaining monitoring quota for each device under the monitoring page according to the preset quota release policy. The remaining monitoring quota is the difference between the total monitoring quota of each device under the monitoring page and the quota acquisition requests made by each device under the monitoring page.

[0065] Based on the device model included in the quota acquisition request and the monitoring page targeted by the request, the server can determine the remaining monitoring quota for the aforementioned device model on that monitoring page. It is understood that limiting the number of times performance metrics are monitored for each device model on each monitoring page can be achieved by configuring a certain total monitoring quota for each device model on each monitoring page. Therefore, the remaining monitoring quota for the device model on the aforementioned monitoring page (to which the terminal belongs in step 301) should be the difference between the corresponding total monitoring quota and the corresponding approved quota acquisition request. Here, an approved quota acquisition request refers to a quota acquisition request sent by the server that has received approval.

[0066] 304. If the remaining monitoring quota is not zero, the server sends a request to the terminal.

[0067] If the remaining monitoring quota is not zero, then the aforementioned terminals are allowed to monitor performance metrics, and a request for permission is sent to the terminals.

[0068] 305. If the terminal receives a request pass from the server, it will obtain the performance index data from the terminal's operation monitoring page.

[0069] If the request from the server is approved, the performance metrics data of the aforementioned terminal during the operation of the aforementioned monitoring page are obtained. In other words, after receiving the request approval information, the client SDK deployed on the terminal can obtain the current performance metrics data of the terminal it is running.

[0070] The performance metrics include, but are not limited to: virtual memory, physical memory, threads (number), FD (number), CPU and / or frame rate.

[0071] 306. The terminal sends its performance metrics data to the server.

[0072] The server analyzes the performance metrics of terminals running under different monitoring pages in different operating environments (including but not limited to the terminal's software and hardware environments) based on the large amount of performance metric data sent by each terminal.

[0073] In this embodiment, a monitoring page for the application is pre-configured. When a terminal accesses the application's monitoring page, it initiates a quota acquisition request to obtain the terminal's performance metrics data. In other words, this embodiment can acquire the terminal's performance metrics data when the terminal accesses a specific page in the application, thereby achieving page-level monitoring of the application's operation. This page-level monitoring allows developers to narrow down the code location causing app data anomalies to the code location corresponding to the page with the abnormal performance metrics data. Furthermore, this embodiment only acquires the terminal's performance metrics data to monitor the application's operation if the server responds with a request approval message. That is, by controlling the total monitoring quota for different device models under the monitoring page, as much performance metrics data of the app running on different device models as possible can be acquired without exceeding the server's processing capacity, achieving more comprehensive performance monitoring.

[0074] To cover as many problem scenarios as possible (i.e., problems that may occur on various device models across various pages) while minimizing redundant sampling, the core strategy of this embodiment is to ensure that a certain number of terminals of all device models entering the monitoring page are sampled (i.e., their requests are accepted). This way, even if the number of newly released device models is small, they can be monitored quickly to detect problems as early as possible. In some specific implementations, the quota release strategy used in the foregoing embodiments of this application to determine the remaining monitoring quota for device models on the monitoring page can be, but is not limited to: proportional batch release or equal release for each device model. Equal release for each device model means that, based on server performance, the total monitoring quota for each monitoring page of the App is first determined, and then the total monitoring quota for each monitoring page is evenly distributed to each device model that may access that monitoring page. For example, if the total monitoring quota for monitoring page 1 is 1000, and there are 50 device models that may access that monitoring page, then each device model on that monitoring page can obtain a total monitoring quota of 20.

[0075] If the quota release strategy is proportional batch release, the following steps can be used to allocate the total monitoring quota: obtain the pending request threshold and single batch release quota corresponding to the monitoring page; in response to the operation of receiving quota acquisition request, obtain the number of pending requests corresponding to the device model under the monitoring page, the number of pending requests is the number of pending quota acquisition requests; if the number of pending requests is not less than the pending request threshold, then the new total monitoring quota for the device model under the monitoring page is determined to be the sum of the old total monitoring quota for the device model under the monitoring page and the single batch release quota.

[0076] Proportional batch release determines the total monitoring quota allocated to each device model on the aforementioned monitoring page based on the number of quota acquisition requests reported by each model for that page. Specifically, a batch release strategy is employed, with pre-configured pending request thresholds and single-batch release quotas for each monitoring page. Whenever a device model sends quota acquisition requests for that monitoring page that reach the corresponding pending request threshold, an additional quota equal to the single-batch release quota is added to that monitoring page for that device model. In other words, to a certain extent, devices with more users will receive a relatively larger quota on the monitoring page.

[0077] It should be noted that the total monitoring quota configured above (for the monitoring page or for different machine models under different monitoring pages) can be for a certain period of time (such as a cycle). That is, when a cycle ends, regardless of the remaining monitoring quota for each machine model under each monitoring page, it will be uniformly cleared to zero, and a total monitoring quota will be allocated to each machine model under each monitoring page in the new cycle according to the corresponding quota release policy. A cycle can be one day or one week, etc., and is not limited here.

[0078] Furthermore, to reduce the need for developers to locate the code that initially caused the data anomaly, and also to minimize the impact of monitoring itself on users' app usage, this embodiment can reduce performance metric monitoring to the node level in some specific implementations. Step 305 can be implemented as follows: If a request pass is received from the server, a target monitoring node set corresponding to the terminal model is determined from the multiple preset monitoring node sets corresponding to the monitoring page. The target monitoring node set includes multiple target monitoring nodes, and each preset monitoring node refers to a time point when the monitoring page reaches any state. If the monitoring page reaches any target monitoring node, the performance metric data of the terminal running the monitoring page is obtained.

[0079] As can be seen from the above, based on the developers' high familiarity with the application, this embodiment only captures the performance indicator data of the target monitoring nodes without long-term data collection. Generally, the target monitoring nodes may include, but are not limited to, runtime nodes and core business nodes. Runtime nodes include nodes where the page monitor (the terminal monitors the performance of the corresponding page by creating a page monitor) is created (i.e., a state of the page) and destroyed (i.e., a state of the page). Core business nodes are configured as needed according to the business executed by the monitored page, and can be time nodes when a task within the page is completed (i.e., a state of the page), when a task within the page is started (i.e., a state of the page), or when a control within the page is selected (i.e., a state of the page).

[0080] Furthermore, to improve the accuracy of performance indicator monitoring, corresponding monitoring configuration information can be preset for each monitoring node to control the way performance indicator data is acquired when the monitoring page runs to any target monitoring node. See the following steps for details: Obtain the monitoring configuration information of any target monitoring node, including monitoring latency and / or performance acquisition duration; if the monitoring page runs to any target monitoring node, obtain the performance indicator data of the terminal running the monitoring page according to the monitoring configuration information of that target monitoring node.

[0081] Specifically, monitoring configuration information may include, but is not limited to, monitoring latency, performance collection duration, and business logic information accompanying the page when it reaches the corresponding node. It should be noted that performance metric data typically includes performance metric values ​​across multiple dimensions, and the performance metric value of any target monitoring node (in any performance metric dimension) can be the average performance metric value within the performance collection duration corresponding to that target monitoring node.

[0082] The following is based on Figure 4For example, in the business scenario of a singing app, this section describes the monitoring nodes and performance data acquisition diagrams for the recording page. The timeline shows four monitoring nodes: A, B, C, and D. A1-A2 represent the monitoring acquisition time corresponding to node A, and the monitoring acquisition times for the other nodes are similar. Additionally, C0-C1 in the diagram refer to the monitoring latency of node C. It should be noted that if two monitoring acquisition times overlap, only one performance data acquisition queue can run at any given time.

[0083] From the above Figure 1 As can be seen from the embodiments described, in addition to collecting performance index data, in order to resolve potential problems before anomalies occur, this application embodiment can also realize local anomaly analysis and background anomaly attribution based on the performance index data collected by the terminal.

[0084] 1. Local anomaly analysis.

[0085] In practical applications, the terminal acquires a set of performance metric data each time the monitoring page reaches a corresponding monitoring node. Each set of performance metric data may contain multiple dimensions, such as virtual memory, physical memory, threads, file descriptors (FD), CPU, and / or frame rate. Therefore, anomalies in performance metric data that the terminal can identify include, but are not limited to: abnormal fluctuations in neighboring nodes in any dimension (differences exceeding the neighboring node threshold) and abnormal month-on-month changes in the mean in any dimension (differences exceeding the mean month-on-month threshold). It should be noted that the anomaly thresholds include both the neighboring node threshold and the mean month-on-month threshold.

[0086] The following analysis focuses on anomalies in neighboring node fluctuations. Among the multiple target monitoring nodes on the monitoring page, any two time-adjacent target monitoring nodes constitute a group of neighboring nodes. Anomalies in neighboring node fluctuations refer to situations where the difference in performance indicator values ​​between two target monitoring nodes within a group exceeds the difference threshold for that performance indicator dimension on the monitoring page. The difference between the performance indicator values ​​of the two target monitoring nodes can be calculated as the difference between them or by using the formula: Difference in a group of neighboring nodes = (Performance indicator value of the node with a later time sequence - Performance indicator value of the node with a earlier time sequence) / Performance indicator value of the node with a later time sequence. If the difference between the performance indicator values ​​of a target monitoring node and its preceding monitoring node in any dimension exceeds the preset neighboring node threshold for that dimension, then the target monitoring node is considered an anomaly and requires anomaly reporting.

[0087] Next, an analysis is performed on the month-on-month change in the mean (the comparison between the acquired performance metric value and the historical mean of the corresponding dimension). Based on the historical mean of the performance metric (i.e., the target performance metric value) of any monitoring page in any historical time period and / or any historical version, it is determined whether the performance metric value of the corresponding dimension acquired by the terminal under any of the aforementioned monitoring pages is abnormal. Here, a historical time period is usually one day or one week, and the historical version is the application version, which can be set as needed. Specifically, after acquiring the terminal's performance metric data, this application embodiment also includes the following steps: the performance metric data includes performance metric values ​​of at least one dimension. If the difference between the performance metric value under any dimension and the historical mean of the performance metric of the monitoring page under any dimension is greater than the month-on-month change threshold of the mean of the monitoring page under any dimension, then the monitoring node corresponding to the performance metric value is determined to be an abnormal node, and any dimension is determined to be an abnormal dimension; and an abnormal reporting information is sent to the server.

[0088] The historical performance index average of dimension A corresponding to the monitoring page can be the average of multiple historical performance index values ​​of dimension A reported by the aforementioned terminal models within a historical period, which can be determined by the server. It should be noted that the inclusion of a dimension in the anomaly report information submitted by the terminal indicates that the terminal has an anomaly in that dimension under the corresponding monitoring page.

[0089] Specifically, the average historical performance metric of any monitoring page within any historical time period (or historical monitoring cycle) and / or any historical software version can be calculated based on the performance metric data received by the terminal for any historical time period and / or any historical version. Taking any historical monitoring cycle as an example, the performance metric data of the running monitoring page sent by each terminal in the most recent M historical monitoring cycles is determined as candidate performance metric data. The candidate performance metric data includes candidate performance metric values ​​for at least one dimension. Then, the average of at least some candidate performance metric values ​​of the monitoring page in any dimension is determined as the average historical performance metric of the monitoring page in any dimension.

[0090] In practical applications, anomaly reporting information includes performance metric data, anomaly dimensions, anomaly nodes, and various operating environment information of the terminal.

[0091] In practical applications, the app provides rules for determining whether a specific version number is a full version. The backend maintains the order of full versions reporting performance data, as well as the time of the first report for each version. The data in the full version table is dynamically generated and updated by the performance monitoring data reported by the external client. At the end of each day, only the latest version data in the current full version order table is processed. Before midnight (11 PM) each night, the average data of various indicators for the past three days (current full version) are calculated asynchronously. The sliding window size is 3D, and the calculation and storage stop at most 15 days after the current version is first reported (when the data has stabilized). Whenever a new full version appears, the calculation and storage of the previous version will stop. (In conjunction with the third point, normally there is a one-month interval between two full versions). After each version's data is fixed in the storage, the cache validity period is three versions (it is assumed that cases before three versions do not need to be calculated).

[0092] 2. Attribution of backend anomalies.

[0093] At the end of each statistical period, each anomaly report obtained within that period is clustered to determine the anomaly attribution. If the statistical period is one day, all anomaly reports for that day are acquired and clustered at the end of each day. Specifically, this can be achieved through the following steps: receiving each anomaly report sent by at least one terminal, each anomaly report including an anomaly dimension, the performance index value of the anomaly dimension, an anomaly node, and multiple operating environment information of the terminal; classifying each anomaly report sent by at least one terminal to obtain an anomaly report set corresponding to each preset statistical dimension, the preset statistical dimension including at least one anomaly dimension and / or at least one anomaly node; and determining the N operating environment information items that appear most frequently in each anomaly report set as the target anomaly cause for the preset statistical dimension corresponding to each anomaly report set.

[0094] Specifically, the above methods can identify the operating environment information that most frequently causes performance anomalies in each node or for each type of performance metric. Additionally, the preset statistical dimensions can include any preset monitoring page, thereby identifying the operating environment information that most frequently causes performance anomalies in each monitoring page. This operating environment information includes both hardware and software information.

[0095] Using an anomaly attribution analysis system, daily anomaly attribution analysis is performed on both the overall page and individual core nodes, based on two main categories: performance metric values ​​and the number of locally determined performance anomaly reports. This allows for convenient and quick analysis of the root causes of abnormal fluctuations in overall attribution metrics, i.e., the clustering of various basic information dimensions. For example: ① An abnormal 20% increase in overall page physical memory usage → mainly caused by a specific device model, XiaoMi13; ② A 15% increase in the number of overall page performance anomaly reports → mainly due to node B within the page; ③ A 30% increase in the number of performance anomaly reports for node E within the page → mainly due to abnormal thread fluctuations reported by this node.

[0096] In practical applications, after obtaining the target anomaly cause for each preset statistical dimension, the target anomaly cause for each preset statistical dimension and related performance indicator data can be sent to the corresponding developer's email or office account to improve operation and maintenance efficiency.

[0097] For further details, please refer to Figure 5 , Figure 6 , Figure 7 , Figure 8 as well as Figure 9 The web platform provides a visual page that displays information such as performance metrics data stored on the server, local anomaly analysis, and background attribution analysis.

[0098] Below are a pair Figure 5 , Figure 6 , Figure 7 , Figure 8 as well as Figure 9 Please provide an explanation.

[0099] Figure 5 Statistical analysis was performed on the performance metrics data of each dimension that met the first screening criteria, and then... Figure 5 The performance statistics page displays a combination of bar charts and line charts. The first filter includes software version, page, (monitoring) node, and (data reception or collection) time range, allowing developers to view performance metrics data of the software running on the terminal within a specific time range using bar charts. It should be noted that the performance statistics page can also display performance metric data statistics individually or in combination with other visualizations such as pie charts; this is not limited to this.

[0100] Please see Figure 6In other implementations, the performance statistics page counts the number of anomaly reports that meet the second filter criteria in each statistical period (day), and generates a trend chart of the number of anomalies received (or the number of anomaly reports) in each statistical period using a line chart. It should be noted that the number of anomalies received in each statistical period can also be displayed using other charts such as bar charts; this is not limited here. The second filter criteria can include, but are not limited to, software version, page, (monitoring) node, anomaly type (or anomaly dimension), and the time range (of data reception or collection).

[0101] Figure 7 Statistical analysis was performed on the abnormal reporting information of each dimension that met the third screening criteria, and the results were obtained through methods such as... Figure 7 The anomaly statistics page is shown below. The third filter criteria include software version, page, (monitoring) node, anomaly indicator (i.e., anomaly dimension), and (data reception or collection) time range. For example... Figure 7 As shown, for easier viewing, in addition to directly displaying each reported anomaly, users can also cluster reported anomalies that meet the third filtering criteria according to the triples (page, node, and anomaly indicator) shown in the figure. After clustering, users can view the statistics of the reported anomalies included in each triple (rows 1 and 2 in the figure), as well as the clustering analysis results corresponding to triple 2 shown in the dashed box in the figure. Clustering is performed on each reported anomaly in the triple based on values ​​under clustering dimensions including but not limited to software version and each type of operating environment information. This yields the n highest values ​​under each clustering dimension, and the proportion of reported anomalies for each value to the total number of reported anomalies in the triple.

[0102] Figure 8 This is another way to display anomaly reports. Anomaly reports that meet the third filtering criteria are displayed individually. After a user selects any anomaly report, they can... Figure 8 The section highlighted by the dashed box on the anomaly statistics page displays all information about the reported anomaly (such as anomaly details and additional information). The third filter criteria include, but are not limited to, software version (version number), page, (monitoring) node, anomaly indicator (i.e., anomaly dimension), (data reception or collection) time range, terminal model, and the user ID (i.e., user identifier) ​​of the user using the terminal software. The anomaly type, in addition to referring to the anomaly dimension, can also indicate which target performance indicator value the anomaly dimension fails to meet; this is not limited here. It is understood that each filter criterion can be included in the anomaly report information submitted by the terminal.

[0103] Figure 9Clustering of anomaly reports that meet the fourth screening criteria based on triples (page, node, and anomaly indicator) is performed, and the following is displayed for each triple: the target anomaly cause (attribution dimension), the rate of change of the performance indicator data (analysis index) of the triple in the current statistical period (i.e., analysis completion time) compared to the performance indicator data (reference index) in the historical statistical period (reference time), the rate of change of the performance indicator value of the analysis index compared to the corresponding dimension of the reference index, and the target anomaly cause and value (detailed attribution conclusion) of the triple.

[0104] The performance metric monitoring in this application embodiment, through comprehensive monitoring of both the local client and cloud backend, can quickly respond to and detect early performance metric anomalies on the external network, narrowing the problem scope to specific nodes and analyzing the characteristic information such as the device model and chip of the problem cluster. This greatly reduces the time cost for developers to discover and locate performance metric problems within a page.

[0105] Figure 10 This is a schematic diagram of a computer device structure provided in an embodiment of this application. The computer device 1000 may include one or more central processing units (CPUs) 1001 and a memory 1005, in which one or more application programs or data are stored.

[0106] The memory 1005 can be volatile or persistent storage. The program stored in the memory 1005 can include one or more modules, each module including a series of instruction operations on the computer device. Furthermore, the central processing unit 1001 can be configured to communicate with the memory 1005 and execute the series of instruction operations in the memory 1005 on the computer device 1000.

[0107] Computer device 1000 may also include one or more power supplies 1002, one or more wired or wireless network interfaces 1003, one or more input / output interfaces 1004, and / or one or more operating systems, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0108] The central processing unit 1001 can perform the aforementioned... Figures 1 to 9 The specific operations performed by the computer device in the illustrated embodiment will not be described in detail here.

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

[0110] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0111] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0112] 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.

[0113] 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.

[0114] If the integrated 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, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0115] This application also provides a computer program product containing instructions that, when run on a computer, cause the computer to perform the performance indicator monitoring method described above.

Claims

1. A performance indicator monitoring method characterized by, Applied to a terminal, the method includes: In response to the terminal's access to a preset monitoring page, the model of the terminal is determined, wherein the monitoring page is the page being monitored; Send a quota acquisition request to the server for the monitoring page, the quota acquisition request including the model of the terminal; If the server sends a request pass information, the performance index data of the terminal running the monitoring page is obtained. The request pass information is determined based on the remaining monitoring quota of the model under the monitoring page. The remaining monitoring quota is the difference between the total monitoring quota of the model under the monitoring page and the quota acquisition request passed by the model under the monitoring page. The performance metrics data of the terminal running the monitoring page are sent to the server.

2. The method according to claim 1, characterized in that, If the request is approved by the server, the performance metrics data of the terminal running the monitoring page are obtained, including: If the request passed information sent by the server is received, then the target monitoring node set corresponding to the terminal model is determined from the multiple preset monitoring node sets corresponding to the monitoring page. The target monitoring node set includes multiple target monitoring nodes, and each preset monitoring node refers to the time node when the monitoring page runs to any state. If the monitoring page runs to any of the target monitoring nodes, the performance metrics data of the terminal running the monitoring page are obtained.

3. The method according to claim 2, characterized in that, If the monitoring page runs to any of the target monitoring nodes, then the performance metrics data of the terminal running the monitoring page are obtained, including: Obtain the monitoring configuration information of any of the target monitoring nodes, wherein the monitoring configuration information includes monitoring latency and / or performance acquisition duration; If the monitoring page runs to any of the target monitoring nodes, the performance index data of the terminal running the monitoring page is obtained according to the monitoring configuration information of any of the target monitoring nodes.

4. The method according to any one of claims 2 to 3, characterized in that, The performance metric data includes performance metric values ​​for at least one dimension. After obtaining the performance metric data of the terminal running the monitoring page, the method further includes: If the difference between the performance index value of any dimension and the target performance index value of any dimension is greater than the difference threshold of the monitoring page in any dimension, then the any dimension is determined to be an abnormal dimension, and the corresponding target monitoring node is determined to be an abnormal node. The corresponding target monitoring node is the target monitoring node that collects the performance index value of any dimension. The target performance index value of any dimension includes the historical performance index average or the performance index value of the previous monitoring node. The target monitoring node and the previous monitoring node in the target monitoring node set are adjacent in time. An anomaly reporting information is sent to the server. The anomaly reporting information includes the anomaly dimension, the performance index value of the anomaly dimension, the anomaly node, and multiple operating environment information of the terminal.

5. A method for monitoring performance indicators, characterized in that, Applied to a server, the method includes: The receiving terminal sends a quota acquisition request for a monitoring page, the quota acquisition request including the model of the terminal, wherein the monitoring page is the page being monitored; Based on the preset quota release strategy, determine the remaining monitoring quota for the model under the monitoring page; If the remaining monitoring quota is not zero, a request to pass information is sent to the terminal. The remaining monitoring quota is the difference between the total monitoring quota of the model under the monitoring page and the quota acquisition request passed by the model under the monitoring page. The system receives performance metrics data of the terminal running the monitoring page, the performance metrics data being obtained by the terminal through information based on the request.

6. The method according to claim 5, characterized in that, The quota release strategy is to release quotas in batches in equal proportions, and the method further includes: Obtain the pending request threshold and single batch release quota corresponding to the monitoring page; In response to receiving the quota acquisition request, the number of pending requests corresponding to the model on the monitoring page is obtained, and the number of pending requests is the number of quota acquisition requests to be processed. If the number of pending requests is not less than the pending request threshold, then the new total monitoring quota for the model on the monitoring page is determined to be the sum of the old total monitoring quota for the model on the monitoring page and the single batch release quota.

7. The method according to claim 5, characterized in that, The performance metric data includes performance metric values ​​for at least one dimension, and the method further includes: Receive each anomaly report information sent by at least one terminal, each anomaly report information including an anomaly dimension, a performance index value of the anomaly dimension, an anomaly node, and multiple operating environment information of the terminal; Each abnormal reporting information sent by the at least one terminal is classified to obtain an abnormal reporting information set corresponding to each preset statistical dimension, wherein the preset statistical dimension includes at least one of the abnormal dimensions and / or at least one of the abnormal nodes; The N most frequently occurring runtime environment information items in each anomaly report set are determined as the target anomaly cause for the preset statistical dimension corresponding to each anomaly report set.

8. The method according to claim 5, characterized in that, The method further includes: The performance index data sent by each terminal in the most recent M historical monitoring periods, which is used to run the monitoring page, are determined as candidate performance index data. The candidate performance index data includes candidate performance index values ​​of at least one dimension. Based on at least some of the candidate performance index values ​​of the monitoring page in any dimension, the historical average performance index value of the monitoring page in any dimension is determined.

9. A performance indicator anomaly monitoring device, characterized in that, include: Central processing unit, memory, and input / output interfaces; The memory is either a short-term storage memory or a persistent storage memory; The central processing unit is configured to communicate with the memory and execute instructions in the memory to perform the method of any one of claims 1 to 4 or 5 to 8.

10. A computer storage medium, characterized in that, The computer storage medium stores instructions that, when executed on the computer, cause the computer to perform the method as described in any one of claims 1 to 4 or 5 to 8.

Images