Program performance monitoring method and device, equipment and storage medium

Abstract

The invention discloses a program performance monitoring method and device, equipment and a storage medium, and relates to the field of computers.The program performance monitoring method comprises the steps that a running log of a to-be-monitored program is obtained, dynamic resource information of the to-be-monitored program during running is obtained from a server-free platform, the running log and the dynamic resource information are processed according to a timestamp, and the dynamic resource information is obtained; performing performance analysis according to the performance data of the monitored program, and determining code snippets with abnormal performance. According to the log record based on the monitoring mark and the dynamic resource deployment information of the platform, the program performance in the non-service environment is monitored, the correlation analysis is performed on the program execution track and the underlying resource scheduling, the mutual influence relationship between the code logic and the operation environment is considered, and the program performance is improved. According to the method, a cross-level performance monitoring system is established, the accuracy of program performance monitoring is improved, abnormal program fragments with high resource consumption and low execution efficiency are recognized, and therefore a basis is provided for optimizing program quality and avoiding resource waste.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, device and storage medium for program performance monitoring. Background Technology

[0002] The development of cloud computing technology has brought a new mode of application deployment: serverless deployment. Applications deployed in a serverless development environment allow developers to run programs and implement application functions without worrying about resources. However, the more flexible resource allocation in a serverless environment also makes it more prone to resource waste.

[0003] Therefore, how to monitor the performance of programs in a serverless environment in order to optimize program quality and solve the problem of serverless resource waste has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0004] In view of the above problems, this application provides a program performance monitoring method, apparatus, device and storage medium to monitor program performance, thereby achieving the purpose of identifying program segments with high resource consumption and low execution efficiency, and providing a basis for optimizing program quality and avoiding resource waste.

[0005] The specific plan is as follows:

[0006] The first aspect of this application provides a method for program performance monitoring, including:

[0007] The system obtains the runtime logs of the program to be monitored and acquires dynamic resource information of the program during runtime from the serverless platform. The program to be monitored is deployed on the serverless platform, and the runtime logs include the execution information of pre-configured monitoring flags in the program to be monitored. The dynamic resource information includes resource usage information and resource allocation information that change over time.

[0008] The runtime log and dynamic resource information are processed based on timestamps to obtain the performance data of the program to be monitored. The performance data includes the execution time and resource consumption of the code segments corresponding to each monitoring marker under different resource conditions.

[0009] Based on the performance data of the program to be monitored, a performance analysis is performed on the program to be monitored to identify code segments with abnormal performance, including high resource consumption and / or low execution efficiency.

[0010] In one possible implementation, the program to be monitored includes at least one serverless function, and the monitoring tag configuration process for the serverless function includes:

[0011] Static code analysis is performed on the serverless function. If the analysis results determine that the serverless function is a complex function, then dense monitoring is performed on the serverless function; otherwise, light monitoring is performed on the serverless function. The monitoring is used to configure monitoring markers in the code of the serverless function.

[0012] In one possible implementation, the monitoring tag configuration process for the serverless function further includes, prior to performing static code analysis on the serverless function:

[0013] Obtain the expected resource usage of the serverless function;

[0014] If the expected resource usage is higher than the preset value, then the step of performing static code analysis on the serverless function is executed; otherwise, the serverless function is determined to be a simple function, and the step of performing lightweight logging on the serverless function is executed.

[0015] In one possible implementation, dense point marking is performed on the serverless functions, including:

[0016] The code of the serverless function is identified, and at least one of the following nodes is determined as an internal node: the start and end nodes of the loop structure, the recursive call point, and the external service call point contained in the serverless function.

[0017] Configure monitoring flags at the entry point, exit point, and internal nodes of the serverless function;

[0018] Lightweight logging of the serverless functions includes:

[0019] Configure monitoring flags at the entry and exit points of the serverless function.

[0020] In one possible implementation, the program to be monitored includes at least one serverless function; the resource allocation information carries the reason for the resource configuration adjustment;

[0021] Performance analysis of the program under monitoring is performed based on its performance data, including:

[0022] For each serverless function, if the deviation between the performance data of the serverless function and the benchmark performance data exceeds a preset limit, the serverless function is identified as an abnormal function.

[0023] Based on the pre-configured monitoring flags in the exception function, the code segment with performance abnormality in the exception function is identified as the exception code segment;

[0024] Based on the reasons for the resource configuration adjustment and the performance data of the abnormal function under different resource conditions, the cause of the abnormal code segment is determined, and the cause of the abnormality is either a code problem or a resource configuration problem.

[0025] In one possible implementation, the baseline performance data is determined based on historical performance data of the serverless function; or,

[0026] The benchmark performance data is determined based on the performance data of a specified function cluster, wherein the specified function cluster is a cluster containing the serverless function among n function clusters, and the n function clusters are clusters obtained by clustering the functions constituting the program to be monitored according to their functional characteristics and / or resource usage characteristics, where n is a preset integer not less than 2; or,

[0027] The benchmark performance data is determined based on the resource allocation information during the runtime of the serverless function.

[0028] In one possible implementation, after identifying the code snippet exhibiting performance anomalies, the following is also included:

[0029] Based on the code snippet with the performance anomaly and the corresponding cause of the anomaly, a performance optimization suggestion is generated, which includes at least one of the following: code modification suggestion and resource configuration adjustment suggestion.

[0030] Based on the optimization rules pre-set by the developer of the program to be monitored, the performance optimization suggestions are prioritized.

[0031] Output performance optimization suggestions after sorting.

[0032] A second aspect of this application provides a program performance monitoring device, comprising:

[0033] The data acquisition unit is used to acquire the running logs of the program to be monitored and to acquire dynamic resource information of the program to be monitored during its runtime from the serverless platform; the program to be monitored is deployed on the serverless platform, and the running logs include the execution information of the monitoring flags pre-configured in the program to be monitored; the dynamic resource information includes resource usage information and resource allocation information that change over time;

[0034] The data processing unit is used to process the running log and the dynamic resource information according to the timestamp to obtain the performance data of the program to be monitored. The performance data includes the execution time and resource consumption of the code segments corresponding to each monitoring mark under different resource conditions.

[0035] The data processing unit is also used to perform performance analysis on the program to be monitored based on the performance data of the program to be monitored, and to identify code segments with abnormal performance, including high resource consumption and / or low execution efficiency.

[0036] A third aspect of this application provides a program performance monitoring device, comprising at least one processor and a memory connected to the processor, wherein:

[0037] The memory is used to store computer programs;

[0038] The processor is used to execute the computer program to implement the program performance monitoring method of the first aspect or any implementation thereof.

[0039] A fourth aspect of this application provides a storage medium carrying one or more computer programs, which, when executed by an electronic device, enable the electronic device to implement the program performance monitoring method described in the first aspect or any implementation thereof.

[0040] Using the above technical solution, this application first obtains the runtime logs of the program to be monitored and acquires dynamic resource information of the program during runtime from the serverless platform. Then, it processes the runtime logs and dynamic resource information based on timestamps to obtain performance data of the monitored program. Based on this data, performance analysis is performed on the monitored program to identify code segments with abnormal performance. This application monitors program performance in a serverless environment based on log records with monitoring tags and dynamic resource deployment information from the platform. By analyzing the correlation between program execution trajectory and underlying resource scheduling, and considering the mutual influence between code logic and the runtime environment, a cross-level performance monitoring system is established. This helps improve the accuracy of program performance monitoring, identify abnormal program segments with high resource consumption and low execution efficiency, and thus provide a foundation for optimizing program quality and avoiding resource waste. Attached Figure Description

[0041] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0042] Figure 1 A flowchart illustrating a program performance monitoring method provided in this application;

[0043] Figure 2 A schematic diagram of the structure of a program performance monitoring device provided in this application;

[0044] Figure 3 This is a schematic diagram of the structure of a program performance monitoring device provided in this application. Detailed Implementation

[0045] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is only for explaining specific embodiments and is not intended to limit the application. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0046] The applicant found through research that, compared to the deployment of applications relying on traditional servers, when applications are deployed on serverless platforms, the platform automatically and dynamically allocates resources according to the application's needs. This makes it difficult for developers to accurately assess the resource consumption of the program under the serverless architecture, identify program segments with high resource consumption and low execution efficiency, and optimize program quality.

[0047] This application provides a serverless function performance monitoring method, apparatus, device, and storage medium, which can be applied to solve program performance monitoring tasks in serverless environments, so as to optimize program quality and alleviate resource waste problems in serverless architectures.

[0048] Figure 1 This is a flowchart illustrating a serverless function performance monitoring method according to an embodiment of this application. (Combined with...) Figure 1 As shown, the method may include the following steps:

[0049] Step S101: Obtain the running log of the program to be monitored, and obtain the dynamic resource information of the program to be monitored during its runtime from the serverless platform.

[0050] The program to be monitored is deployed on the serverless platform. Furthermore, in a serverless architecture, traditional monolithic applications are typically broken down into multiple independent functional units, or functions; that is, the program to be monitored may include at least one serverless function.

[0051] The runtime log may include execution information of pre-configured monitoring markers in the program to be monitored. It should be noted that monitoring markers, i.e., data points, can be pre-configured in the code of the program to be monitored, so that the execution status at the monitoring markers can be recorded in the program's runtime log, thereby capturing information related to program performance during execution. Optionally, the runtime log of the program to be monitored can be recorded using the logging system built into the serverless platform, or it can rely on other logging platforms to record logs. That is, the aforementioned runtime logs can be obtained from the serverless platform or other logging platforms, depending on the program deployment method.

[0052] The dynamic resource information may include resource usage and allocation information that changes over time, and can be represented as a timeline chart. It should be noted that the serverless platform provides the underlying resources for the monitored program, such as virtual machines / containers; furthermore, the different serverless functions constituting the monitored program are independent of each other. An independent call and execution lifecycle of a serverless function is called an instance, corresponding to the execution process from receiving a request to returning a response. Based on this, the dynamic resource information of the monitored program during runtime can exist in the form of instance information.

[0053] Based on this, the aforementioned resource allocation information may include the number of instances, specifications, etc.; resource usage information reflects the real-time status of the underlying resources provided by the platform, and may include metrics such as CPU utilization, memory usage, network bandwidth utilization, and disk I / O. Since the data obtained from the serverless platform reflects the resource status of the entire operating environment, if the program to be monitored includes more than one serverless function, concurrent function instances may exist during performance monitoring. Based on this, the resource usage information of the function instances can be accurately obtained based on the request ID.

[0054] In addition, dynamic resource information may also include resource cost information, such as the cost of each resource adjustment and the total cost corresponding to the program to be monitored. This application does not limit the specific composition of dynamic resource information reflecting the dynamic resource deployment during program operation.

[0055] Step S102: Process the running log and the dynamic resource information according to the timestamp to obtain the performance data of the program to be monitored.

[0056] It should be noted that by comparing the execution times of different monitoring markers, the execution time of the code segment corresponding to the monitoring marker can be determined. In addition, based on timestamps, the runtime logs can be associated with dynamic resource information. By aligning the execution time of the monitoring markers with the time when the serverless platform collects dynamic resource information, the resource status corresponding to the execution time of each monitoring marker in the program to be monitored can be determined. By comparing the resource status of different monitoring markers, the resource consumption of the code segment corresponding to the monitoring marker can be determined.

[0057] Because resource allocation information changes dynamically during program execution, execution time alone cannot reflect the actual execution efficiency of a serverless architecture, and resource usage information alone cannot reflect the actual resource consumption of a serverless architecture. Therefore, performance analysis requires combining execution time / resource usage information with resource allocation information. For example, during the generation of performance data for the program to be monitored, the acquired data can be preprocessed. This preprocessing can include data cleaning (to filter out abnormal data) and data standardization (such as normalization), such as converting execution time and resource usage information to a comparable scale to obtain resource usage information that incorporates resource allocation information at the corresponding moment. This provides a foundation for ensuring the accuracy and reliability of performance analysis.

[0058] The performance data may include: the execution time and resource consumption of the code segments corresponding to each monitoring marker under different resource conditions. The aforementioned performance data may include the performance data of each function instance of each serverless function. For example, resource consumption may include basic metrics such as CPU utilization and memory usage. Based on this, feature extraction can be performed on the acquired data to obtain derived metrics. That is, resource consumption may also include derived metrics such as resource consumption per unit of processing volume (specifically, it may include the memory increment when processing a unit of data volume), the rate of change of resource consumption (specifically, it may include the rate of increase corresponding to the increase in resource consumption), cold start time and the proportion of cold start time to total time, the number of different types of error / abnormal events, the number of retries and their causes, etc. Furthermore, during the execution of the program under monitoring, one or more serverless functions may be called more than once. Therefore, the aforementioned derived metrics may also include monitoring metrics characterizing the volatility of execution time.

[0059] Step S102 can process the acquired raw data, which may include messy timestamps, data values ​​and other information, into neat and standardized database tables for subsequent processing.

[0060] Step S103: Perform performance analysis on the program to be monitored based on the performance data of the program to be monitored, and identify code segments with abnormal performance.

[0061] The performance anomalies may include high resource consumption and / or low execution efficiency. In one possible implementation, machine learning algorithms can be used to analyze resource consumption and execution time during program execution to identify code segments with high resource consumption and low execution efficiency, providing a starting point for subsequent program quality optimization. Optionally, after identifying the code segments with performance anomalies, an anomaly cause analysis can also be performed.

[0062] This application first obtains the runtime logs of the program to be monitored and acquires dynamic resource information of the program during runtime from a serverless platform. Then, it processes the runtime logs and dynamic resource information based on timestamps to obtain performance data of the monitored program. Based on this data, performance analysis is performed on the monitored program to identify code segments with abnormal performance. This application monitors program performance in a serverless environment based on log records with monitoring tags and dynamic resource deployment information from the platform. By performing correlation analysis between program execution trajectory and underlying resource scheduling, and considering the mutual influence between code logic and the runtime environment, a cross-level performance monitoring system is established. This helps improve the accuracy of program performance monitoring, identify abnormal program segments with high resource consumption and low execution efficiency, and thus provide a foundation for optimizing program quality and avoiding resource waste.

[0063] In one or more embodiments provided in this application, the program to be monitored may include at least one serverless function.

[0064] Based on the above, taking any function as an example, the monitoring tag configuration process for the serverless function may include:

[0065] Static code analysis is performed on the serverless function. If the analysis results determine that the serverless function is a complex function, then dense code points are added to the serverless function; otherwise, light code points are added to the serverless function.

[0066] Among them, static code analysis targets serverless function code written by developers. Function code has different code structures and contains different operation types, which can reflect the functional characteristics of the function. Based on this, it is possible to initially determine whether the function is a complex function or a simple function, and to initially determine the granularity of monitoring tag configuration.

[0067] The markers are used to configure monitoring tags in the code of the serverless function. Compared with monitoring tags configured by lightweight markers, monitoring tags configured by dense markers can obtain more granular function performance data, so as to achieve the purpose of comprehensively capturing key information in the function execution process.

[0068] Optionally, a serverless function can be classified as a complex function if its code contains deep loops, recursive calls, or code segments with high algorithmic complexity. Deep loops refer to loop structures with at least three nested levels; for example, recursive calls can have a call depth greater than five. It should be noted that deep loops cause memory consumption to increase quadratically with each iteration, and recursive calls cause stack memory consumption to increase exponentially, resulting in non-linear latency growth.

[0069] Optionally, if a serverless function explicitly calls a known resource-intensive operation, it can be determined that the serverless function is a complex function. It should be noted that resource-intensive operations will directly cause instantaneous peaks in CPU / IO resources; if synchronous calls block threads, latency will increase significantly.

[0070] In one possible implementation, densely marking the serverless function may include:

[0071] The code of the serverless function is identified, and at least one of the following nodes is determined as an internal node: the start and end nodes of the loop structure, the recursive call point, and the external service call point contained in the serverless function.

[0072] Configure monitoring flags at the entry point, exit point, and internal nodes of the serverless function.

[0073] In one possible implementation, lightweight logging of the serverless functions includes:

[0074] Configure monitoring flags at the entry and exit points of the serverless function.

[0075] It should be noted that setting monitoring markers at the function's entry and exit points allows for the recording of function call counts, execution time, and resource consumption. Specifically, these monitoring markers enable the acquisition of resource snapshots at the start and end points of the current function instance, such as process-level memory usage and cumulative CPU time, to calculate the resource increment during the function's execution cycle. For example, the difference between the resource value recorded by the platform at the execution time of the monitoring marker at the exit point and the resource value recorded by the platform at the execution time of the monitoring marker at the entry point can be used as the resource consumption of the function instance.

[0076] Building upon the above, setting monitoring markers at key logical nodes within a function allows for more granular function execution data. These key logical nodes correspond to complex computational steps within the function, and the operations corresponding to these code snippets are typically the core operations of the function. Specifically, the execution status within a loop can be obtained through the start / end points of loop iterations; the call depth information can be obtained through the recursion point of a recursive call; and external service or resource call points, such as the positions before and after database query statements, file read / write operations, and network request sending / receiving points, can be obtained. Furthermore, information such as the execution time and success / failure status of operations corresponding to each node, as well as the incremental resource consumption within the execution interval of each node, can be obtained through internal nodes and their adjacent nodes.

[0077] In addition, techniques such as aspect-oriented programming can be used to mark nodes at the function entry / exit / internal points to record necessary call information and exception events, such as the function name corresponding to this function instance, the call timestamp, the execution success / failure status, and the error code, providing a basis for performance anomaly analysis.

[0078] This embodiment uses different levels and granularities of data tracking for serverless functions with varying execution logic complexity. This achieves the goal of comprehensively capturing key performance information during program execution, ensuring the integrity of data collection at critical stages, while also avoiding the collection of excessive redundant information and improving performance monitoring efficiency.

[0079] In one or more embodiments provided in this application, before performing static code analysis on the serverless function, the monitoring tag configuration process for the serverless function may further include:

[0080] Obtain the expected resource usage of the serverless function; if the expected resource usage is higher than a preset value, perform static code analysis on the serverless function; otherwise, determine that the serverless function is a simple function and perform lightweight logging on the serverless function.

[0081] For example, the expected resource usage can be the amount of resources required for the serverless function to run as preset by the developer, or the amount of resources required for the serverless function to run as recommended by the serverless platform. This application does not limit it.

[0082] In addition, after configuring the initial monitoring flags for serverless functions, the monitoring flags can be reconfigured according to the function's execution characteristics to better achieve program performance monitoring tasks.

[0083] For example, when a serverless function contains code segments that have historically run into errors, the serverless function can be classified as a complex function for fine-grained monitoring, or monitoring flags corresponding to the historically error-prone code segments can be configured within the function. These historically error-prone code segments can be those identified from historical execution records as having exhibited significantly higher CPU peak utilization or abnormal fluctuations in memory usage.

[0084] For example, an alarm can be triggered if the deviation between the actual resource consumption and the expected resource usage of a function exceeds a certain threshold (such as exceeding 30%), allowing for analysis of the serverless function or reconfiguration of the function's monitoring flags.

[0085] In one or more embodiments provided in this application, the program to be monitored may include at least one serverless function.

[0086] Furthermore, the resource allocation information may carry the reason for the resource configuration adjustment. The aforementioned reason refers to the specific event that triggers the serverless platform to expand, shrink, initialize, or terminate resource instances. For example, the reason for expansion might be the arrival of a new request or a cold start response; the reason for shrinking might be a decrease in request load or the reclamation of idle instances; the reason for initialization might be a cold start; and the reason for termination might be an execution error, execution timeout, or the serverless platform's scheduling policy. The reason for the resource configuration adjustment can be obtained by directly accessing the serverless platform's event logs. These logs may include the event type and the reason provided by the serverless platform.

[0087] Based on the above, performance analysis of the program under monitoring based on its performance data may include:

[0088] For each serverless function, perform the following steps S201-S203:

[0089] Step S201: If the deviation between the performance data of the serverless function and the benchmark performance data exceeds a preset limit, the serverless function is identified as an abnormal function.

[0090] Optionally, the benchmark performance data can be determined based on the historical performance data of the serverless function. For example, the benchmark performance data can be the average of historical performance data. Based on this, serverless functions with historical anomalies can be identified, such as serverless functions whose actual performance data exceeds the average of historical performance data by a certain limit.

[0091] Optionally, the benchmark performance data can be determined based on the performance data of a specified function cluster, wherein the specified function cluster is a cluster containing the serverless function among n function clusters, and the n function clusters are clusters obtained by clustering the functions constituting the program to be monitored according to their functional characteristics and / or resource usage characteristics, where n is a preset integer not less than 2. For example, the benchmark performance data can be the median performance time of each function in the specified function cluster. Based on this, serverless functions with abnormal performance compared to similar functions can be identified. The aforementioned similar functions can refer to functions with similar functional characteristics and / or resource usage characteristics, such as serverless functions whose actual performance data is significantly higher than most functions in the specified function cluster.

[0092] Optionally, the benchmark performance data can be determined based on the resource allocation information during the runtime of the serverless function. Based on this, the performance data of the same function under different resource configurations can be compared to assess the impact of resource configuration on function performance and identify serverless functions with abnormal resource allocation pressure, such as functions whose actual resource usage during execution continuously approaches the upper limit of resource allocation.

[0093] Step S202: Based on the pre-configured monitoring flags in the exception function, determine the code segment with performance abnormality in the exception function as the exception code segment.

[0094] Optionally, the top N code snippets with the highest resource consumption or lowest execution efficiency can be identified as abnormal code snippets. Here, N is a preset positive integer.

[0095] Step S203: Based on the reasons for the resource configuration adjustment and the performance data of the abnormal function under different resource conditions, determine the cause of the abnormal code segment.

[0096] The cause of the anomaly is either a code issue or a resource configuration issue. For example, anomaly analysis can be performed through decision-making. For instance, if performance degradation occurs following code changes, it is determined to be a code issue; if function performance (e.g., execution time) improves with increased resource allocation, it is indeed a resource configuration issue, such as insufficient resource allocation or a mismatch between resource allocation and function.

[0097] In one or more embodiments provided in this application, after identifying the code segment with abnormal performance, the following may also be included:

[0098] Step S301: Based on the code snippet with the performance error and the corresponding cause of the error, generate performance optimization suggestions.

[0099] The performance optimization suggestions include at least one of code modification suggestions and resource configuration adjustment suggestions. For example, resource configuration adjustment suggestions may include algorithm optimization, data structure modification, and reduction of unnecessary computations. Furthermore, code modification suggestions can be generated based on the type of performance anomaly. For example, if the anomaly is due to an algorithm or loop structure, the algorithm or logic can be modified, such as by implementing sharding; if there are memory management issues, such as leaks or fragmentation, the release logic can be modified; if the anomaly is due to synchronous I / O blocking, asynchronous modification can be implemented. For resource configuration adjustment suggestions, for example, when the actual memory usage of a function consistently approaches or exceeds the allocated memory, memory configuration can be increased; when cold starts are time-consuming and account for a high percentage of the total time, pre-configured concurrency or initialization acceleration can be enabled.

[0100] Optionally, performance optimization suggestions can be generated through pattern recognition and rule-based reasoning. For example, a predefined condition-action rule base can be used. Based on this, the cause of the anomaly can be matched with the conditions in the rule base. When a matching condition is determined, suggestions are generated based on the action corresponding to the matching condition. Specifically, if multiple matching conditions exist but their corresponding actions conflict, the final generated suggestion can be determined based on preset priorities or weights.

[0101] In addition, the performance optimization suggestions accepted by developers and the corresponding reasons for exceptions can be abstracted to generate new condition-action pairs to expand the condition-action rule library.

[0102] Step S302: Prioritize the performance optimization suggestions according to the optimization rules preset by the developer of the program to be monitored.

[0103] For example, optimization rules may include at least one of cost constraint rules and code criticality rules. For instance, based on cost constraint rules, optimization suggestions related to an exception function can be marked as high-priority optimization items when the single execution cost of the exception function exceeds a preset cost threshold; based on code criticality rules, optimization suggestions related to code segments located in critical core steps can be given higher optimization priorities. Furthermore, performance optimization conditions can be filtered based on technical restriction rules, such as prohibiting asynchronous modifications to special code segments involving specific encryption logic.

[0104] Step S303: Output performance optimization suggestions after sorting.

[0105] Building upon the foregoing, the performance monitoring solution provided in this application can be further optimized based on user feedback. For example, the data tracking scheme can be optimized based on the validity of data marked by developers; the suggestion generation scheme can be optimized based on the validity of suggestions marked by developers and whether developers accept or ignore performance optimization suggestions, such as adjusting optimization rules or the rule base; and the exception analysis scheme can be optimized based on abnormal code snippets or corresponding exception causes manually modified by developers, etc.

[0106] Based on the above, the quality of performance monitoring, the accuracy and practicality of suggestions generated can be continuously optimized during long-term performance monitoring, and can be kept in sync with the actual needs of developers.

[0107] The program performance monitoring device provided in the embodiments of this application is described below. The program performance monitoring device described below can be referred to in correspondence with the program performance monitoring method described above.

[0108] Figure 2 This is a schematic diagram of the structure of a program performance monitoring device disclosed in an embodiment of this application. Figure 2 As shown, the device may include:

[0109] The data acquisition unit 11 is used to acquire the running log of the program to be monitored and to acquire the dynamic resource information of the program to be monitored during its operation from the serverless platform; the program to be monitored is deployed on the serverless platform, and the running log includes the execution information of the monitoring flags pre-configured in the program to be monitored; the dynamic resource information includes resource usage information and resource allocation information that change over time.

[0110] Data processing unit 12 is used to process the running log and the dynamic resource information according to the timestamp to obtain the performance data of the program to be monitored. The performance data includes the execution time and resource consumption of the code segments corresponding to each monitoring mark under different resource conditions.

[0111] The data processing unit 12 is further configured to perform performance analysis on the program to be monitored based on the performance data of the program to be monitored, and to identify code segments with abnormal performance, wherein the abnormal performance includes high resource consumption and / or low execution efficiency.

[0112] In one or more embodiments provided in this application, the program to be monitored includes at least one serverless function. Based on the above, the data processing unit 12 is further configured to configure monitoring flags for the serverless function. The process by which the data processing unit 12 configures the monitoring flags for the serverless function may include:

[0113] Static code analysis is performed on the serverless function. If the analysis results determine that the serverless function is a complex function, then dense monitoring is performed on the serverless function; otherwise, light monitoring is performed on the serverless function. The monitoring is used to configure monitoring markers in the code of the serverless function.

[0114] In one or more embodiments provided in this application, the process of configuring the monitoring flags of the serverless function by the data processing unit 12 may further include:

[0115] Before performing static code analysis on the serverless function, the expected resource usage of the serverless function is obtained; if the expected resource usage is higher than a preset value, the step of performing static code analysis on the serverless function is executed; otherwise, the serverless function is determined to be a simple function, and the step of performing lightweight data logging on the serverless function is executed.

[0116] In one or more embodiments provided in this application, the process of the data processing unit 12 performing intensive point marking on the serverless function may include:

[0117] The code of the serverless function is identified, and at least one of the following nodes is determined as an internal node: the start and end nodes of the loop structure, the recursive call point, and the external service call point contained in the serverless function.

[0118] Configure monitoring flags at the entry point, exit point, and internal nodes of the serverless function.

[0119] In one or more embodiments provided in this application, the process by which the data processing unit 12 performs lightweight logging on the serverless function may include:

[0120] Configure monitoring flags at the entry and exit points of the serverless function.

[0121] In one or more embodiments provided in this application, the program to be monitored includes at least one serverless function; the resource allocation information carries the reason for the resource configuration adjustment;

[0122] The process by which the data processing unit 12 performs performance analysis on the program under monitoring based on the performance data of the program under monitoring may include:

[0123] For each serverless function, if the deviation between the performance data of the serverless function and the benchmark performance data exceeds a preset limit, the serverless function is identified as an abnormal function.

[0124] Based on the pre-configured monitoring flags in the exception function, the code segment with performance abnormality in the exception function is identified as the exception code segment;

[0125] Based on the reasons for the resource configuration adjustment and the performance data of the abnormal function under different resource conditions, the cause of the abnormal code segment is determined, and the cause of the abnormality is either a code problem or a resource configuration problem.

[0126] In one or more embodiments provided in this application, the benchmark performance data is determined based on historical performance data of the serverless function; or,

[0127] The benchmark performance data is determined based on the performance data of a specified function cluster, wherein the specified function cluster is a cluster containing the serverless function among n function clusters, and the n function clusters are clusters obtained by clustering the functions constituting the program to be monitored according to their functional characteristics and / or resource usage characteristics, where n is a preset integer not less than 2; or,

[0128] The benchmark performance data is determined based on the resource allocation information during the runtime of the serverless function.

[0129] In one or more embodiments provided in this application, the data processing unit 12 is further configured to:

[0130] After identifying the code segment with abnormal performance, performance optimization suggestions are generated based on the code segment with abnormal performance and the corresponding cause of the abnormality. The performance optimization suggestions include at least one of code modification suggestions and resource configuration adjustment suggestions.

[0131] Based on the optimization rules pre-set by the developer of the program to be monitored, the performance optimization suggestions are prioritized.

[0132] Output performance optimization suggestions after sorting.

[0133] The program performance monitoring device provided in this application embodiment can be applied to program performance monitoring equipment, such as terminals with data processing capabilities: mobile phones, computers, servers, etc. Optionally, Figure 3 The hardware structure block diagram of the program performance monitoring device is shown below. Figure 3 The hardware structure of the program performance monitoring device may include: at least one processor 1, at least one communication interface 2, at least one memory 3, and at least one communication bus 4;

[0134] In this embodiment of the application, the number of processor 1, communication interface 2, memory 3, and communication bus 4 is at least one, and processor 1, communication interface 2, and memory 3 communicate with each other through communication bus 4;

[0135] Processor 1 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention.

[0136] Memory 3 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device;

[0137] The memory is used to store computer programs, and the processor is used to execute the computer programs so that the program performance monitoring device can implement any of the above-mentioned program performance monitoring methods.

[0138] This application also provides a storage medium that carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the program performance monitoring methods provided in this application.

[0139] This application also provides a computer program product including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the program performance monitoring methods provided in this application.

[0140] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0141] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.

[0142] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for monitoring program performance, characterized in that, include: Obtain the runtime logs of the program to be monitored, and obtain the dynamic resource information of the program during runtime from the serverless platform; The program to be monitored is deployed on the serverless platform, and the operation log includes the execution information of the monitoring flags pre-configured in the program to be monitored; the dynamic resource information includes resource usage information and resource allocation information that change over time. The runtime log and dynamic resource information are processed based on timestamps to obtain the performance data of the program to be monitored. The performance data includes the execution time and resource consumption of the code segments corresponding to each monitoring marker under different resource conditions. Based on the performance data of the program to be monitored, a performance analysis is performed on the program to be monitored to identify code segments with abnormal performance, including high resource consumption and / or low execution efficiency.

2. The program performance monitoring method according to claim 1, characterized in that, The program to be monitored includes at least one serverless function, and the monitoring tag configuration process for the serverless function includes: Static code analysis is performed on the serverless function. If the analysis results determine that the serverless function is a complex function, then dense monitoring is performed on the serverless function; otherwise, light monitoring is performed on the serverless function. The monitoring is used to configure monitoring markers in the code of the serverless function.

3. The program performance monitoring method according to claim 2, characterized in that, Before performing static code analysis on the serverless function, the monitoring tag configuration process for the serverless function also includes: Obtain the expected resource usage of the serverless function; If the expected resource usage is higher than the preset value, then the step of performing static code analysis on the serverless function is executed; otherwise, the serverless function is determined to be a simple function, and the step of performing lightweight logging on the serverless function is executed.

4. The program performance monitoring method according to claim 2 or 3, characterized in that, Dense point marking is performed on the serverless functions, including: The code of the serverless function is identified, and at least one of the following nodes is determined as an internal node: the start and end nodes of the loop structure, the recursive call point, and the external service call point contained in the serverless function. Configure monitoring flags at the entry point, exit point, and internal nodes of the serverless function; Lightweight logging of the serverless functions includes: Configure monitoring flags at the entry and exit points of the serverless function.

5. The program performance monitoring method according to any one of claims 1-3, characterized in that, The program to be monitored includes at least one serverless function; the resource allocation information carries the reason for the resource configuration adjustment. Performance analysis of the program under monitoring is performed based on its performance data, including: For each serverless function, if the deviation between the performance data of the serverless function and the benchmark performance data exceeds a preset limit, the serverless function is identified as an abnormal function. Based on the pre-configured monitoring flags in the exception function, the code segment with performance abnormality in the exception function is identified as the exception code segment; Based on the reasons for the resource configuration adjustment and the performance data of the abnormal function under different resource conditions, the cause of the abnormal code segment is determined, and the cause of the abnormality is either a code problem or a resource configuration problem.

6. The program performance monitoring method according to claim 5, characterized in that, The benchmark performance data is determined based on the historical performance data of the serverless function; or... The benchmark performance data is determined based on the performance data of a specified function cluster, wherein the specified function cluster is a cluster containing the serverless function among n function clusters, and the n function clusters are clusters obtained by clustering the functions constituting the program to be monitored according to their functional characteristics and / or resource usage characteristics, where n is a preset integer not less than 2; or, The benchmark performance data is determined based on the resource allocation information during the runtime of the serverless function.

7. The program performance monitoring method according to any one of claims 1-3, characterized in that, After identifying the code snippet with performance issues, the following is also included: Based on the code snippet with the performance anomaly and the corresponding cause of the anomaly, a performance optimization suggestion is generated, which includes at least one of the following: code modification suggestion and resource configuration adjustment suggestion. Based on the optimization rules pre-set by the developer of the program to be monitored, the performance optimization suggestions are prioritized. Output performance optimization suggestions after sorting.

8. A program performance monitoring device, characterized in that, include: The data acquisition unit is used to acquire the running logs of the program to be monitored and to acquire dynamic resource information of the program to be monitored during its runtime from the serverless platform. The program to be monitored is deployed on the serverless platform, and the operation log includes the execution information of the monitoring flags pre-configured in the program to be monitored; the dynamic resource information includes resource usage information and resource allocation information that change over time. The data processing unit is used to process the running log and the dynamic resource information according to the timestamp to obtain the performance data of the program to be monitored. The performance data includes the execution time and resource consumption of the code segments corresponding to each monitoring mark under different resource conditions. The data processing unit is also used to perform performance analysis on the program to be monitored based on the performance data of the program to be monitored, and to identify code segments with abnormal performance, including high resource consumption and / or low execution efficiency.

9. A program performance monitoring device, characterized in that, It includes at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program so that the program performance monitoring device can implement the program performance monitoring method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium carries one or more computer programs, which, when executed by an electronic device, enable the electronic device to implement the program performance monitoring method as described in any one of claims 1 to 7.

Images