Application monitoring method and device, equipment, storage medium and program product

Abstract

The embodiment of the invention provides an application monitoring method and device, equipment, a storage medium and a program product, and relates to the field of big data. The method comprises the following steps: in response to a captured memory exception event when a to-be-monitored application runs, acquiring memory stack information corresponding to the memory exception event; wherein the memory exception event comprises at least one of a memory leak event, a memory depletion event and an exceptional memory allocation event; the memory stack information, the crash event data and the operation behavior data are subjected to association analysis, an association analysis result is obtained, and the association analysis result comprises associated transaction identifiers and corresponding memory stack information within a preset duration before the crash triggering time; and according to the correlation analysis result, identifying an abnormal reason of the to-be-monitored application. According to the method, the abnormal problem identification accuracy of the application can be effectively improved.

Description

Technical Field

[0001] This application relates to the field of big data, and in particular to an application monitoring method, device, equipment, storage medium, and program product. Background Technology

[0002] With the rapid development of internet technology, mobile applications (APPs) have gradually become the core medium for interaction between service providers such as financial institutions, social platforms, and e-commerce platforms and users. Especially in the financial sector, APPs carry important businesses such as account management and payment settlement, and their operational stability is directly related to user asset security and user trust.

[0003] In the actual operation of an app, memory anomalies are one of the core causes of app stability issues. Specifically, when users perform daily operations (such as making payments) through the app, if the app crashes due to memory anomalies and terminates its process (i.e., it crashes), it will directly affect the user experience and may trigger business risks.

[0004] However, when monitoring applications, related technologies mainly focus on indicators such as crash rate and lag rate, but lack effective means to identify crashes caused by memory anomalies, making it difficult to accurately locate abnormal issues in apps. Summary of the Invention

[0005] This application provides an application monitoring method, apparatus, device, storage medium, and program product, which can effectively improve the accuracy of identifying application anomalies.

[0006] Firstly, this application provides an application monitoring method, including:

[0007] In response to capturing a memory anomaly event during the runtime of the application to be monitored, the memory stack information corresponding to the memory anomaly event is obtained; wherein, the memory anomaly event includes at least one of the following: memory leak event, memory exhaustion event, and abnormal memory allocation event;

[0008] The memory stack information, crash event data, and operation behavior data are correlated and analyzed to obtain correlation analysis results. The correlation analysis results include transaction identifiers and corresponding memory stack information associated within a preset time period before the crash trigger time.

[0009] Based on the correlation analysis results, the causes of anomalies in the application to be monitored are identified.

[0010] Secondly, an application monitoring device is provided, comprising:

[0011] The acquisition module is used to acquire memory stack information corresponding to the memory abnormal event in response to the capture of a memory abnormal event during the runtime of the application to be monitored; wherein the memory abnormal event includes at least one of the following: memory leak event, memory exhaustion event, and abnormal memory allocation event;

[0012] The association module is used to perform association analysis on the memory stack information, crash event data and operation behavior data to obtain association analysis results. The association analysis results include transaction identifiers and corresponding memory stack information associated within a preset time period before the crash trigger time.

[0013] The identification module is used to identify the cause of the anomaly in the application to be monitored based on the correlation analysis results.

[0014] Thirdly, an electronic device is provided, comprising: a processor, and a memory communicatively connected to the processor;

[0015] The memory stores computer-executed instructions;

[0016] The processor executes computer execution instructions stored in the memory to implement the application monitoring method provided in any of the first aspects above.

[0017] Fourthly, a computer-readable storage medium is provided, wherein computer-executable instructions are stored therein, which, when executed by a processor, are used to implement the application monitoring method provided in any of the first aspects above.

[0018] Fifthly, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the application monitoring method provided in any of the first aspects above.

[0019] The application monitoring method, apparatus, device, storage medium, and program product provided in this application, in response to capturing memory anomaly events during the runtime of the application to be monitored, obtains memory stack information corresponding to the memory anomaly events. These memory anomaly events include at least one of the following: memory leak events, memory exhaustion events, and abnormal memory allocation events. The application then performs correlation analysis on the memory stack information, crash event data, and operational behavior data to obtain correlation analysis results. These results include transaction identifiers and corresponding memory stack information associated with the events within a preset time period before the crash trigger time. Based on the correlation analysis results, the cause of the anomaly in the application to be monitored is identified. In this process, by real-time monitoring and capturing memory anomaly events during the runtime of the application to be monitored, and obtaining the corresponding memory stack information, the application performs correlation analysis on the memory stack information with crash event data and operational behavior data. Based on the correlation information between crash, memory, and user behavior, the cause of the anomaly in the application to be monitored can be accurately identified. This provides developers with clear clues for troubleshooting, effectively shortens the anomaly repair cycle, reduces user operation failures and function interruptions caused by application anomalies, and improves user experience. Especially for applications with extremely high reliability requirements, such as financial applications, it effectively reduces the impact of anomalies on core business operations (such as transactions and payments). Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0021] Figure 1 This is one of the flowcharts illustrating an application monitoring method provided in an embodiment of this application;

[0022] Figure 2 for Figure 1 A flowchart illustrating step S102;

[0023] Figure 3 A second schematic flowchart of an application monitoring method provided in this application embodiment;

[0024] Figure 4 A flowchart illustrating another application monitoring method provided in this application embodiment;

[0025] Figure 5 This is a schematic diagram of the structure of an application monitoring device provided in an embodiment of this application;

[0026] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0027] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0028] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0029] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0030] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0031] It should be noted that the application monitoring methods, devices, equipment, storage media, and program products provided in this application can be used in the field of big data technology, or in any field other than big data technology. The application fields of the application monitoring methods, devices, equipment, storage media, and program products in this application are not limited.

[0032] In practical applications, when users perform daily operations (such as transactions, account management, and payments) through an app, if the app terminates its process due to memory anomalies, such as memory leaks, large memory allocations, or Out of Memory (OOM), it will directly impact user experience and potentially trigger business risks. For example:

[0033] Financial apps: If an app crashes due to memory issues during critical operations such as money transfers and payments, it may result in transaction failure or data loss.

[0034] Social apps: Memory anomalies may cause message loss or function interruption during user chat, file upload, and other scenarios.

[0035] For e-commerce apps: If operations such as browsing products and placing orders are interrupted due to memory issues, it may affect user conversion rates and platform revenue.

[0036] Because the relevant technologies lack analysis of APP crashes caused by memory anomalies, it is difficult to accurately locate the cause of APP anomalies. This not only affects the continuity of user operations and user experience, but also prolongs the development team's troubleshooting cycle and repair efficiency for crash issues, increasing technical maintenance costs.

[0037] In view of this, the application monitoring method, apparatus, device, storage medium, and program product provided in this application, in response to capturing memory anomaly events during the runtime of the application to be monitored, obtains memory stack information corresponding to the memory anomaly events. These memory anomaly events include at least one of the following: memory leak events, memory exhaustion events, and abnormal memory allocation events. The memory stack information, crash event data, and operational behavior data are then correlated to obtain correlation analysis results. These results include transaction identifiers and corresponding memory stack information associated within a preset time period before the crash trigger time. Then, based on the correlation analysis results, the cause of the anomaly in the application to be monitored is identified. In this process, by real-time monitoring and capturing memory anomaly events during the runtime of the application to be monitored, and obtaining the corresponding memory stack information, the memory stack information is correlated with crash event data and operational behavior data. Based on the correlation information between crash, memory, and user behavior, the cause of the anomaly in the application to be monitored can be accurately identified. This provides developers with clear clues for troubleshooting, effectively shortens the anomaly repair cycle, reduces user operation failures and function interruptions caused by application anomalies, and improves user experience. Especially for applications with extremely high reliability requirements, such as financial applications, it effectively reduces the impact of anomalies on core business operations (such as transactions and payments).

[0038] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0039] Figure 1 This is a flowchart illustrating an application monitoring method, such as... Figure 1 As shown, the method includes steps S101-S103.

[0040] For example, the execution entity of the method provided in this embodiment can be a server. This could be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. Alternatively, it could be other execution entities besides servers, such as terminal devices. Terminal devices can include, but are not limited to, computers, smartphones, tablets, e-book readers, Moving Picture Experts Group audio layer III (MP3) players, Moving Picture Experts Group audio layer IV (MP4) players, portable computers, in-vehicle computers, wearable devices, desktop computers, set-top boxes, smart TVs, etc.

[0041] Step S101: In response to capturing a memory exception event during the runtime of the application to be monitored, obtain the memory stack information corresponding to the memory exception event; wherein, the memory exception event includes at least one of the following: memory leak event, memory exhaustion event, and abnormal memory allocation event.

[0042] In this embodiment, the application to be monitored can be a financial app or other types of apps. A memory monitoring framework (which can be an existing open-source framework, such as a lightweight memory monitoring and memory stack capture framework, or a custom-implemented framework; this embodiment does not specifically limit the type of framework) can be integrated into the terminal where the application is installed to monitor the application in real time and capture memory anomalies that occur during the application's operation.

[0043] Understandably, in response to, is used to indicate the conditions or states on which the operation being performed depends. When the conditions or states on which it depends are met, one or more operations being performed can be performed in real time or with a set delay. Unless otherwise specified, there is no restriction on the order in which the multiple operations being performed are executed.

[0044] In one alternative implementation, responding to the capture of a memory anomaly event during the runtime of the application to be monitored can be achieved in the following way:

[0045] The system monitors the running status of the application under monitoring in real time. If at least one of the following three conditions is detected, the system will respond by capturing a memory exception event during the runtime of the application under monitoring:

[0046] The system detected that the application under monitoring contains memory objects that have not been released and have reached a preset lifespan.

[0047] The process memory usage of the application under monitoring has reached the preset threshold.

[0048] The system detected that the size of a single memory allocation operation of the application under monitoring reached the preset single memory allocation threshold.

[0049] For example, methods for monitoring memory leaks include monitoring unreleased memory objects, such as Objective-C objects (e.g., view controllers that haven't been destroyed), recording the class name, allocation stack, and lifecycle of the leaking object. Alternatively, for monitoring dynamic memory allocation heap leaks, this involves detecting memory blocks allocated by dynamic memory allocation functions (functions used to request memory) but not released by memory release functions, outputting the address, size, and allocation stack of the leaked memory. Leak stack reconstruction involves using stack address translation tools to restore the stack addresses to readable function names / source code locations, relying on the compiler-preserved symbol table.

[0050] For monitoring memory exhaustion events, the method involves intercepting critical moments that cause process memory spikes (approaching or triggering the system OOM crash threshold, i.e., reaching a preset usage threshold) and obtaining a complete memory allocation stack dump. It identifies high-frequency memory allocation areas, such as function call paths or object creation chains that frequently request large amounts of memory. The types of memory covered can include heap memory (obtained through heap memory region allocation) and virtual memory (obtained through virtual memory allocation functions).

[0051] For monitoring large memory allocations, single large memory allocations can be tracked to capture memory blocks that exceed a single memory allocation threshold (configurable), recording their size, allocation address, and call stack. This helps to locate sudden memory pressure caused by abnormal large resource loading (such as image decoding or file reading) or unreasonable expansion of data structures.

[0052] It should be noted that those skilled in the art can adaptively set or adjust the preset lifespan, preset occupancy threshold, and single memory allocation threshold based on actual applications or experience values, and this embodiment does not impose any particular limitations on this.

[0053] In one optional implementation, the process of obtaining the memory stack information corresponding to the memory exception event can be as follows:

[0054] By integrating a memory monitoring framework into the application under monitoring, memory stack information is captured when memory anomaly events occur. The memory stack information includes the memory allocation stack and / or call path.

[0055] For example, a memory monitoring framework can be used to capture memory anomalies such as OOM and large memory allocation exceeding a set threshold during APP runtime. The memory stack information corresponding to the memory anomaly event can be obtained and stored or reported for subsequent processing. For example, data such as memory allocation stack, call path, device ID, user ID, trigger time, client version number, and operating system version can be reported to the memory management database.

[0056] In this way, by integrating a memory monitoring framework to capture key data of memory anomaly events in real time, we can provide data information corresponding to memory anomaly events for subsequent correlation analysis, thereby facilitating the location of the cause of application memory anomalies.

[0057] Step S102: Perform correlation analysis on memory stack information, crash event data and operation behavior data to obtain correlation analysis results. The correlation analysis results include transaction identifiers and corresponding memory stack information associated within a preset time period before the crash trigger time.

[0058] In one alternative implementation, such as Figure 2 As shown, step S102, which involves correlation analysis of memory stack information, crash event data, and operation behavior data, may include the following steps S1021 and S1022.

[0059] Step S1021: Based on the transaction identifier and crash trigger time, within a preset time period before the crash trigger time, filter out the memory stack information and operation behavior data that match the crash event data to obtain the filtering results.

[0060] For example, a mobile device, i.e., a terminal device, can integrate an Application Performance Management (APM) development kit (SDK). This SDK can capture crashes that occur during app runtime and report data such as crash stack traces, device ID, user ID, crash trigger time, client version number, and operating system version to the APM database. Furthermore, the mobile device can also integrate a data tracking SDK to capture app-level events, user click events, and page-level events, and report data such as transaction ID, device ID, user ID, event trigger time, client version number, and operating system version to the data tracking database.

[0061] In this embodiment, the server can utilize transaction identifiers (IDs) and combine them with device IDs, user IDs, and other information to determine the trigger time of a corresponding crash (problem). Within a preset timeframe before the crash trigger time (e.g., 30 seconds; this can be adjusted adaptively by those skilled in the art based on actual applications), the server filters memory stack information (e.g., memory allocation stack, call path) corresponding to the event and transaction identifier from the memory management database, and filters operation behavior data (e.g., user click sequences, page switching records) corresponding to the time and transaction identifier from the event tracking database. This ensures that these data are consistent with the crash event data (which may include crash stacks and crash types) in the application performance management database across dimensions such as transaction, time, and device, thus obtaining the filtering results.

[0062] Step S1022: Based on the filtering results, associate the crash event data with its matching memory stack information and operation behavior data.

[0063] In this embodiment, the server can use common fields such as transaction identifier, device identifier, user identifier, and timestamp to align and integrate the filtered crash event data, memory stack information, and operation behavior data, forming a correlated dataset that includes the complete chain of business operations, memory changes, and crash occurrence. For example, for a crash event of a transfer transaction, the correlation results can clearly show the complete process of the user clicking the transfer button → the system loading the recipient list (triggering a large memory allocation) → memory usage continuously surging → crash occurring 3 seconds later, providing data support for subsequent identification of the cause of the anomaly.

[0064] Furthermore, to further address the problems of obscure and difficult-to-understand memory stack information, and the difficulty in accurately correlating crash event data with specific code paths and business transactions, thus leading to difficulties in locating the cause of APP memory anomalies and low troubleshooting efficiency, this embodiment converts memory stack information into readable code paths and then correlates them. Specifically, as shown below... Figure 3 As shown, the method may further include step S301, and step S1022 is further divided into step S1022'.

[0065] Step S301: Convert the memory stack information into a readable code path.

[0066] Step S1022' Based on the filtering results, the crash event data is associated with the converted readable code path and the corresponding transaction identifier.

[0067] In this embodiment, by converting memory stack information into readable code paths, abstract memory addresses can be mapped to specific class names, function names, and line numbers. This allows developers to directly locate the source code corresponding to the memory anomaly, providing a clear technical link for subsequent correlation analysis with crash event data and transaction identifiers. It avoids troubleshooting obstacles caused by obscure and difficult-to-understand original stack information, thereby improving the efficiency of identifying the root cause of memory anomalies.

[0068] For example, the above step S301, which converts memory stack information into a readable code path, can be done in the following way: based on a preset symbol table, the memory stack address in the memory stack information is mapped to a function name or source code location to obtain a readable code path; wherein, the symbol table includes an application-level symbol table associated with the client version number of the application to be monitored, and a system-level symbol table associated with the operating system version of the terminal on which the application to be monitored runs.

[0069] Alternatively, a symbol table resolution tool can be used to convert the memory stack information into a readable code path.

[0070] Optionally, crash stacks in the APM database and memory stacks in the memory management database can be parsed separately, and a batch parsing scheduled task can be created. During the stack parsing process, the client version number is associated with the corresponding application-level symbol file, and the operating system version is associated with the corresponding system symbol file.

[0071] In related technologies, application stability monitoring mainly focuses on monitoring metrics such as crash rate, lag rate, and error rate. It also helps developers analyze code-level issues, providing intuitive feedback on the lines of code causing the crash and the problem description, thus solving the problem of developers relying on reproducing online crashes for analysis and localization. However, for crashes caused by abnormal application memory usage leading to the system actively exiting the application, the stack trace only contains system-level symbols, and currently lacks an analysis mechanism. Further analysis using application memory information is needed.

[0072] This embodiment, through the aforementioned method, captures the complete stack information of memory exception events and, combined with a symbol table, reconstructs readable code paths to directly locate the code line or function call chain that caused the memory exception, solving the problem that system-level stacks cannot parse application-level code. This embodiment ensures that the stack parsing results correspond to specific code locations (such as specific classes, functions, and line numbers in a particular application version), avoiding parsing errors caused by symbol file mismatches, while also reducing manual intervention costs and improving the parsing efficiency of large-scale stack information. Furthermore, through a version association mechanism, it adapts to the differences between different application versions and operating system versions, ensuring that stack parsing remains stable and effective during application iterations or system upgrades, providing accurate and standardized code path data support for subsequent correlation analysis between crash events and memory exceptions.

[0073] In one implementation, the process of filtering out memory stack information and operational behavior data that match crash event data includes:

[0074] From the crash event data, crash events containing system-level symbols are filtered out, and the filtered crash events are sorted according to preset dimensions. The crash problems in the preset sorting positions are taken as the target analysis objects.

[0075] Based on the transaction identifier and crash trigger time of the target analysis object, the corresponding memory stack information and operation behavior data are matched within a preset time before the crash trigger time.

[0076] For example, automated scripts can be used to batch parse crash stacks in the APM database and memory stacks in the memory management database, combining the client version number with the application-level symbol table and the operating system version with the system symbol table to reconstruct readable code paths. By filtering crash issues in the APM database that only contain system symbols, the Top 10 crash issues are extracted. For each crash issue, m data entries are extracted and matched against memory snapshot data (such as OOM events and large memory allocation records) within 10 minutes prior to the crash trigger time in the memory database. User behavior data (such as transaction IDs and page paths) within 10 minutes prior to the crash trigger time in the event tracking database is also matched.

[0077] This allows for the identification of high-priority crashes and the location of code issues by combining stack traces, thereby improving application repair efficiency.

[0078] See also Figure 1 Step S103: Based on the correlation analysis results, identify the causes of anomalies in the application to be monitored.

[0079] For example, consider a bank app crashing during verification code encryption for money transfers. Correlation analysis shows that the crash type corresponding to transaction identifier 1 is process termination caused by a memory leak. The readable code path points to the security module / encryption utility class. The operation record shows the user received SMS verification codes three times consecutively. The memory stack shows that each call to the encryption utility class created a new encryption object without garbage collection. After three operations, the accumulated memory usage reached 380MB. Based on this, the cause of the anomaly can be identified: the encryption utility class did not use the singleton pattern to manage the encryption object; each verification code encryption resulted in a repeated creation of an instance without release, leading to the accumulation of memory leaks and ultimately causing the crash.

[0080] Figure 4 A flowchart illustrating another application monitoring method provided in this application embodiment is shown below. Figure 4As shown, based on the above embodiments, this embodiment generates report data based on the correlation analysis results to facilitate further analysis of the causes of anomalies by users. Specifically, in addition to the above steps S101-S103, the method also includes steps S401 and S402.

[0081] Step S401: Based on the correlation analysis results, generate report data that includes crash scenarios, memory anomaly details, and related transaction identifiers.

[0082] Step S402: Send the report data to the monitoring personnel of the application to be monitored to trigger the analysis process for the cause of the anomaly.

[0083] In this embodiment, the matching results are integrated into report data. This report data clearly presents the business scenario in which the crash occurred (such as a transfer operation or page loading), the specific type of memory anomaly (such as memory exhaustion or persistent memory leaks), and the scope of impact (such as the number of users involved and the frequency of occurrence). Crash stack traces, memory stack traces, event tracking data, and transaction IDs can be attached, and the data is sent to stability monitoring personnel via a notification system. After receiving the notification, the monitoring personnel can perform preliminary analysis and filtering based on the event tracking transaction IDs, and assign the collected crash and memory data to the corresponding developers for further analysis to further improve application repair efficiency.

[0084] In an exemplary embodiment, the implementation process of the technical solution of this application may include two parts: data acquisition and data processing.

[0085] The data collection process can include three data sources: memory anomaly data from a memory snapshot tool (an open-source memory monitoring framework), crash event data from the APM mobile management platform, and event tracking data.

[0086] Memory snapshot tool: Captures OOM (Out of Memory) errors and large memory allocations exceeding set thresholds during app runtime, reporting data such as memory allocation stack trace, call path, device ID, user ID, trigger time, client version number, and operating system version to the memory management database. Memory collection scenarios include the following:

[0087] 1) OOM Stack Recording: Intercepts critical moments that cause process memory spikes (approaching or triggering the system OOM crash threshold) to obtain the complete memory allocation stack. Identifies memory allocation hotspots, such as function call paths or object creation chains that frequently request large amounts of memory. Coverage type: Includes heap memory and virtual memory.

[0088] 2) Large Memory Allocation Monitoring: Tracks single large memory allocations, capturing memory blocks allocated in a single instance that exceed a set threshold (configurable), and recording their size, allocation address, and call stack. This helps locate sudden memory pressure caused by abnormal large resource loading (such as image decoding, file reading) or unreasonable expansion of data structures.

[0089] 3) Memory Leak Detection: Monitors for leaks of unreleased Objective-C objects (such as ViewControllers that are not destroyed), recording the class name, allocation stack, and lifecycle of the leaked objects. For example, it monitors dynamic memory allocation heap leaks, detecting memory blocks allocated by dynamic memory allocation functions (functions used to request memory) but not released by memory release functions, outputting the address, size, and allocation stack of the leaked memory. Optionally, leak stack reconstruction: Combines stack address translation tools to restore the stack addresses to readable function names / source code locations, relying on the symbol table preserved by the compiler.

[0090] APM Mobile Management Platform: Integrates the APM SDK into the mobile app to capture crashes that occur during app runtime and report data such as crash stack, device ID, user ID, crash trigger time, client version number, and operating system version to the APM database.

[0091] Event tracking data: The mobile app integrates an event tracking SDK to capture App-level events, user click events, and page-level events, and reports data such as transaction ID, device ID, user ID, event trigger time, client version number, and operating system version to the event tracking database.

[0092] During data processing, preprocessing can be performed first, such as parsing crash stacks in the APM database and memory stacks in the memory management database separately, and scheduling batch parsing tasks. Stack parsing requires associating the corresponding application-level symbol file with the client version number and the corresponding system symbol file with the operating system version.

[0093] Next, an automated script is executed to filter and correlate data. This script is developed, configured to run automatically as a scheduled task or manually, filters and correlates data, generates reports, and alerts the application's stability monitoring personnel via a notification system. The script can perform the following steps:

[0094] Starting with the crash stack data from the APM mobile management platform, we first filtered out crashes whose crash stack information only contained system symbols and not application-level symbols, and then selected the top 10 crash issues.

[0095] For each crash issue, extract m crash data points, obtain the corresponding device ID, user ID, and crash trigger time, and package these data and crash stacks to generate report data.

[0096] Match the associated memory database and event tracking database based on device ID, user ID, and crash trigger time. Query for matching memory data within the 10 minutes prior to the crash trigger time and retrieve the memory stack; query user event tracking data within the 10 minutes prior to the crash trigger time, including all transaction IDs and other data during that period. Add the corresponding data to the report data.

[0097] The generated report data will be added as an attachment and sent to the application's stability monitoring personnel.

[0098] After receiving the notification, the monitoring personnel conducted a preliminary analysis and screening based on the transaction IDs of the tracking points, and assigned the collected crash and memory data to the corresponding developers for further analysis.

[0099] By combining the above technical solutions with a mobile stability monitoring platform and business event tracking system, and introducing a memory monitoring mechanism, we can better address the challenge of analyzing app crashes caused by memory issues during online app runtime. This adds memory monitoring metrics to the transaction dimension of online application stability and improves the monitoring system. Furthermore, by implementing automated script tools and scheduled tasks, these tools can be quickly deployed to transaction developers, further reducing the manpower costs of application stability governance and improving the efficiency of problem analysis and localization.

[0100] Figure 5 This is a schematic diagram of the structure of an application monitoring device provided in an embodiment of this application, as shown below. Figure 5 As shown, the device 500 includes an acquisition module 501, an association module 502, and an identification module 503, wherein,

[0101] The acquisition module 501 is used to acquire memory stack information corresponding to the memory exception event in response to the capture of a memory exception event during the runtime of the application to be monitored; wherein the memory exception event includes at least one of the following: memory leak event, memory exhaustion event, and abnormal memory allocation event;

[0102] The association module 502 is used to perform association analysis on memory stack information, crash event data and operation behavior data to obtain association analysis results. The association analysis results include the associated transaction identifiers and corresponding memory stack information within a preset time before the crash trigger time.

[0103] The identification module 503 is used to identify the cause of anomalies in the application to be monitored based on the correlation analysis results.

[0104] In one embodiment, the acquisition module 501 includes:

[0105] The monitoring unit is used to monitor the running status of the application under monitoring in real time. If at least one of the following three conditions is detected, it will respond by capturing a memory abnormal event during the runtime of the application under monitoring:

[0106] The system detected that the application under monitoring contains memory objects that have not been released and have reached a preset lifespan.

[0107] The process memory usage of the application under monitoring has reached the preset threshold.

[0108] The system detected that the size of a single memory allocation operation of the application under monitoring reached the preset single memory allocation threshold.

[0109] In one implementation, the association module 502 includes:

[0110] The filtering unit is used to filter out memory stack information and operation behavior data that match the crash event data within a preset time period before the crash trigger time, based on the transaction identifier and crash trigger time, and obtain the filtering results.

[0111] The association unit is used to associate crash event data with its matching memory stack information and operation behavior data based on the filtering results.

[0112] In one implementation, it further includes:

[0113] The conversion module is used to convert memory stack information into readable code paths;

[0114] The association unit is specifically used to associate crash event data with the converted readable code path and the corresponding transaction identifier.

[0115] In one implementation, the conversion module includes:

[0116] The mapping unit is used to map the memory stack address in the memory stack information to the function name or source code location based on the preset symbol table, so as to obtain the readable code path;

[0117] The symbol table includes an application-level symbol table associated with the client version number of the application to be monitored, and a system-level symbol table associated with the operating system version of the terminal on which the application to be monitored runs.

[0118] In one implementation, the filtering unit is specifically used for:

[0119] From the crash event data, crash events containing system-level symbols are filtered out, and the filtered crash events are sorted according to preset dimensions. The crash problems in the preset sorting positions are taken as the target analysis objects.

[0120] Based on the transaction identifier and crash trigger time of the target analysis object, the corresponding memory stack information and operation behavior data are matched within a preset time before the crash trigger time.

[0121] In one embodiment, the acquisition module 501 includes:

[0122] The capture unit is used to capture memory stack information when a memory anomaly occurs, including the memory allocation stack and / or call path, through a memory monitoring framework integrated into the application to be monitored.

[0123] In one embodiment, the apparatus further includes:

[0124] The generation module is used to generate report data containing crash scenarios, memory exception details, and related transaction identifiers based on the correlation analysis results;

[0125] The sending module is used to send report data to the monitoring personnel of the application to be monitored, so as to trigger the analysis process of the cause of the anomaly.

[0126] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 6 As shown, the electronic device includes: a processor 601, and a memory 602 communicatively connected to the processor 601;

[0127] Memory 602 stores computer-executed instructions;

[0128] The processor 601 executes computer execution instructions stored in the memory 602 to implement the application monitoring method corresponding to the above method embodiment.

[0129] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the application monitoring method provided in the above-described method embodiments.

[0130] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the application monitoring method provided in the above-described method embodiments.

[0131] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0132] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by 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 flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0133] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0134] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0135] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0136] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). 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 memory 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 of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0137] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0138] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0139] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. An application monitoring method characterized by, The method comprises: in response to capturing a memory exception event of a to-be-monitored application running, obtaining memory stack information corresponding to the memory exception event; wherein the memory exception event comprises at least one of the following: a memory leakage event, a memory depletion event, and an abnormal memory allocation event; performing correlation analysis on the memory stack information, crash event data, and operation behavior data to obtain a correlation analysis result, wherein the correlation analysis result comprises transaction identifiers and corresponding memory stack information associated within a preset time period before a crash triggering time; according to the correlation analysis result, identifying an abnormal cause of the to-be-monitored application.

2. The method of claim 1, wherein, The method comprises: monitoring the running state of the to-be-monitored application in real time, and in response to capturing a memory exception event of the to-be-monitored application running, if at least one of the following conditions is monitored: monitoring that the to-be-monitored application has a memory object that is continuously not released and reaches a preset survival period; monitoring that the process memory occupancy of the to-be-monitored application reaches a preset occupancy threshold; monitoring that the allocation size of a single memory allocation operation of the to-be-monitored application reaches a preset single memory allocation threshold.

3. The method according to claim 1 or 2, characterized in that, The method comprises: based on the transaction identifier and the crash triggering time, filtering out memory stack information and operation behavior data matching the crash event data within a preset time period before the crash triggering time to obtain a filtering result; according to the filtering result, correlating the crash event data with the memory stack information and operation behavior data matching the crash event data.

4. The method of claim 3, wherein, The method further comprises: converting the memory stack information into a readable code path; The method comprises: correlating the crash event data with the converted readable code path and the corresponding transaction identifier.

5. The method of claim 4, wherein, The method comprises: based on a preconfigured symbol table, mapping memory stack addresses in the memory stack information into function names or source code positions to obtain a readable code path; wherein the symbol table comprises an application-level symbol table associated with a client version number of the to-be-monitored application, and a system-level symbol table associated with an operating system version of a terminal on which the to-be-monitored application runs.

6. The method of claim 3, wherein, The method comprises: from the crash event data, filtering out a crash event containing a system-level symbol, and sorting the filtered crash event according to a preset dimension, and taking a crash problem at a preset sorting position in the sorting result as a target analysis object; based on the transaction identifier and the crash triggering time of the target analysis object, matching corresponding memory stack information and operation behavior data within a preset time period before the crash triggering time.

7. The method of claim 1, wherein, The method comprises: Memory stack information including a memory allocation stack and / or a call path when the memory exception event occurs is captured through a memory monitoring framework integrated in the application to be monitored.

8. The method of claim 1, wherein, Further comprising: According to the correlation analysis result, report data including a crash scenario, memory exception details and associated transaction identification is generated; The report data is sent to a monitoring personnel of the application to be monitored to trigger an analysis process of the exception cause.

9. An application monitoring apparatus characterized by comprising: Comprising: An acquisition module is configured to acquire memory stack information corresponding to a memory exception event of an application to be monitored in response to capturing the memory exception event when the application to be monitored runs; wherein the memory exception event includes at least one of the following: a memory leakage event, a memory depletion event, and an abnormal memory allocation event; A correlation module is configured to perform correlation analysis on the memory stack information, crash event data and operation behavior data to obtain a correlation analysis result, the correlation analysis result including transaction identification and corresponding memory stack information associated within a preset time length before a crash triggering time; An identification module is configured to identify an exception cause of the application to be monitored according to the correlation analysis result.

10. An electronic device, comprising: Comprising: A processor, and a memory in communication connection with the processor; The memory stores computer execution instructions; The processor executes the computer execution instructions stored in the memory to implement the application monitoring method according to any one of claims 1 to 8.

11. A computer readable storage medium, characterized in that, The computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by the processor to implement the application monitoring method according to any one of claims 1 to 8.

12. A computer program product, characterised in that, A computer program is executed by the processor to implement the application monitoring method according to any one of claims 1 to 8.

Images