Method, device and storage medium for analyzing running data of an application

Abstract

The application discloses an application running data analysis method and device and a storage medium. The application is applied to a target application. The method comprises the following steps: receiving a target instruction description sent by a target platform, wherein the target instruction description is used for indicating that the target application analyzes data generated in a process of executing a target task of the target application; determining a target semantic anchor point associated with the target task from a semantic anchor point library based on the target instruction description; acquiring running data of the target application and analyzing the running data to obtain a target result of the target task in the case that the target semantic anchor point is triggered. Through the application, the problem that the risk of analyzing the running data in the application is high is solved, and the effect of reducing the risk is achieved.

Description

Technical Field

[0001] This application relates to the field of computers, and more specifically, to a method, apparatus, and storage medium for analyzing the runtime data of an application. Background Technology

[0002] In related technologies, business users often want to dynamically observe the network interaction process without redeploying the application. However, traditional methods usually rely on external debugging connections and general script injection, or on fixed instrumentation points and pre-made SDKs (Software Development Kits), which are difficult to meet the requirements of low disturbance, cross-version adaptation, security control and verifiable results in the production environment at the same time.

[0003] This indicates that there are technical problems with the analysis of operational data in applications, which pose significant risks.

[0004] There is currently no effective solution to the aforementioned problems in the relevant technologies. Summary of the Invention

[0005] This application provides a method, apparatus, and storage medium for analyzing application runtime data, to at least address the technical problem of high risk in analyzing application runtime data in related technologies.

[0006] According to one aspect of the embodiments of this application, a method for analyzing the runtime data of an application is provided, applied to a target application, comprising: receiving a target instruction description sent by a target platform, wherein the target instruction description is used to instruct the target application to analyze data generated during the execution of a target task by the target application; determining a target semantic anchor associated with the target task from a semantic anchor library based on the target instruction description; and, when the target semantic anchor is triggered, acquiring the runtime data of the target application and analyzing the runtime data to obtain the target result of the target task.

[0007] In an exemplary embodiment, determining a target semantic anchor associated with the target task from a semantic anchor library based on the target instruction description includes: determining candidate semantic anchors based on first anchor information included in the target instruction description and second anchor information of semantic anchors included in the semantic anchor library; determining the target similarity between third anchor information of each candidate semantic anchor and the first anchor information; and determining the target semantic anchor based on multiple target similarities.

[0008] In an exemplary embodiment, determining the target semantic anchor point based on multiple target similarities includes: determining sub-similarities included in the target similarities that are greater than or equal to a first preset threshold; determining the difference between every two sub-similarities to obtain multiple target differences; if there is a difference among the multiple target differences that is greater than a second preset threshold, determining the candidate semantic anchor point corresponding to the maximum value included in the sub-similarities as the target semantic anchor point; and if each target difference is less than the second preset threshold, determining the target semantic anchor point based on the target instruction description and the third anchor point information of the candidate semantic anchor points corresponding to the sub-similarities.

[0009] In an exemplary embodiment, determining the target semantic anchor based on the third anchor information of the candidate semantic anchors corresponding to the target instruction description and the sub-similarity includes: for each candidate semantic anchor, performing the following operations to determine a target score for the candidate semantic anchor, and determining the candidate semantic anchors corresponding to the target scores that are greater than or equal to a third preset threshold as the target semantic anchors: determining a first consistency score between the first anchor relationship included in the third anchor information and the second anchor relationship included in the target instruction description; determining a second consistency score between the first information included in the third anchor information and the second information included in the target instruction description, wherein the first information is used to represent the identification information when the candidate semantic anchor is triggered; determining whether the candidate semantic anchor is a historical semantic anchor based on the third anchor information to obtain a third consistency score; and determining the target score based on the first consistency score, the second consistency score, and the third consistency score.

[0010] In one exemplary embodiment, before receiving the target instruction description sent by the target platform, the method further includes: determining the target code used by the target application when performing a task, the task including the target task; determining semantic anchors from the target code; determining second anchor information for each semantic anchor; and constructing the semantic anchor library based on the semantic anchors and the second anchor information.

[0011] In one exemplary embodiment, obtaining the runtime data of the target application includes: determining the response object of the target task; extracting a target list field and the target field value corresponding to the target list field from the response object; constructing a field value mapping table based on the target list field and the target field value; determining a target snapshot based on the field value mapping table, and determining the target snapshot as the runtime data.

[0012] In one exemplary embodiment, analyzing the runtime data to obtain the target result of the target task includes: determining a first field value from the runtime data according to the target field path included in the target instruction description; filtering the first field value based on the filtering rules included in the target instruction description to obtain a second field value; shaping the second field value based on the processing rules included in the target instruction description to obtain a third field value; and filling the result field template included in the target instruction description with the third field value to obtain the target result.

[0013] In an exemplary embodiment, the method further includes: determining target parameters during the execution of the target instruction description by the target application, wherein the target parameters include at least one of the following: processor runtime, memory, number of code instrumentation triggers, amount of data extracted, amount of data reported, and number of target instruction descriptions running simultaneously; if the target parameters are greater than or equal to a fourth preset threshold, determining a target level based on the target parameters, wherein the target level is used to represent the degree of resource consumption in the target application; and performing a target operation corresponding to the target level, wherein the target operation includes at least one of the following: a downgrade operation, stopping the execution of the target instruction description, and executing a historical target instruction description, wherein the downgrade operation includes at least one of the following: reducing the number of first fields extracted, reducing the number of target instruction descriptions running simultaneously, and not analyzing the running data.

[0014] According to another aspect of the embodiments of this application, a method for analyzing the runtime data of an application is provided, applied to a target platform, comprising: receiving an observation request, wherein the observation request includes a target task; generating a target instruction description based on the observation request, wherein the target instruction description is used to instruct a target application to analyze data generated during the execution of the target task by the target application; sending the target instruction description to the target platform to instruct the target platform to determine a target semantic anchor associated with the target task from a semantic anchor library based on the target instruction description; and, when the target semantic anchor is triggered, instructing the target application to obtain the runtime data of the target application and analyze the runtime data to obtain the target result of the target task.

[0015] According to another aspect of the embodiments of this application, an application runtime data analysis apparatus is also provided, applied to a target application, comprising: a first receiving module, configured to receive a target instruction description sent by a target platform, wherein the target instruction description is used to instruct the target application to analyze data generated during the execution of a target task by the target application; a determining module, configured to determine a target semantic anchor associated with the target task from a semantic anchor library based on the target instruction description; and an obtaining module, configured to obtain runtime data of the target application when the target semantic anchor is triggered, and analyze the runtime data to obtain the target result of the target task.

[0016] According to another aspect of the embodiments of this application, an application runtime data analysis apparatus is also provided, applied to a target platform, comprising: a second receiving module for receiving observation requirements, wherein the observation requirements include a target task; a generating module for generating a target instruction description based on the observation requirements, wherein the target instruction description is used to instruct a target application to analyze data generated during the execution of the target task by the target application; and a sending module for sending the target instruction description to the target platform to instruct the target platform to determine a target semantic anchor associated with the target task from a semantic anchor library based on the target instruction description, and, when the target semantic anchor is triggered, instruct the target application to obtain the runtime data of the target application and analyze the runtime data to obtain the target result of the target task. According to yet another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer program, wherein the computer program is configured to perform the steps in any of the above method embodiments when executed by a processor.

[0017] According to another aspect of the embodiments of this application, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, causing the computer device to perform the steps in any of the method embodiments described above.

[0018] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to perform the steps of any of the above method embodiments through the computer program.

[0019] This application demonstrates that upon receiving a target instruction description from the target platform, the target semantic anchor associated with the target task can be determined from a semantic anchor library using this description. The target instruction description instructs the target application to analyze the data generated during the execution of the target task. When the determined target semantic anchor associated with the target task is triggered, the target application's runtime data can be acquired and analyzed, thus obtaining the target task's outcome. Since the platform does not send an arbitrarily executable general script, but rather a verifiable and constrained observation description (i.e., the aforementioned target instruction description), the constrained observation description can be mapped to the current version's executable anchor (i.e., the aforementioned target semantic anchor) during the target application's runtime. This allows for obtaining the target outcome from analyzing the target application's runtime data while ensuring production environment stability and security. Therefore, it addresses the high risk associated with analyzing runtime data in applications, achieving a risk reduction effect. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of an application scenario for analyzing runtime data according to an embodiment of this application;

[0021] Figure 2 This is a flowchart illustrating an optional application runtime data analysis method according to an embodiment of this application. Figure 1 ;

[0022] Figure 3 This is a flowchart illustrating an optional application runtime data analysis method according to an embodiment of this application. Figure 2 ;

[0023] Figure 4 This is a flowchart illustrating the method for analyzing runtime data of the application in this optional example;

[0024] Figure 5 This is a structural block diagram of an application runtime data analysis system according to an embodiment of this application;

[0025] Figure 6 This is a structural block diagram of an optional application runtime data analysis device according to an embodiment of this application. Figure 1 ;

[0026] Figure 7 This is a structural block diagram of an optional application runtime data analysis device according to an embodiment of this application. Figure 2 ;

[0027] Figure 8 This is a computer system architecture block diagram of an optional electronic device according to an embodiment of this application. Detailed Implementation

[0028] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0029] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0030] According to one aspect of the embodiments of this application, a method for analyzing application runtime data is provided. Optionally, in this embodiment, the above-described method for analyzing application runtime data may be applied to, but is not limited to, applications such as... Figure 1 The hardware environment shown includes terminal device 102 and server 104. Server 104 can be connected to terminal device 102 via a network and can be used to provide services (e.g., application services, etc.) to terminal device 102 or clients installed on terminal device 102. A database can be set up on server 104 or independently of server 104 to provide data storage services for server 104.

[0031] The aforementioned network may include, but is not limited to, at least one of the following: wired network and wireless network. The aforementioned wired network may include, but is not limited to, at least one of the following: wide area network (WAN), metropolitan area network (MAN), and local area network (LAN). The aforementioned wireless network may include, but is not limited to, at least one of the following: Wireless Fidelity (WIFI) and Bluetooth. Terminal device 102 may be, but is not limited to, a personal computer (PC), mobile phone, tablet computer, etc. Server 104 may be, but is not limited to, a cloud server, server cluster, or other server types.

[0032] The method for analyzing the runtime data of the application in this embodiment can be executed by server 104, terminal device 102, or jointly by server 104 and terminal device 102. Alternatively, the method for analyzing the runtime data of the application in this embodiment can be executed by a client installed on the terminal device 102.

[0033] Figure 2 This is a flowchart illustrating an optional application runtime data analysis method according to an embodiment of this application. Figure 1 ,like Figure 2 As shown, the process of this method, when applied to the target application, may include the following steps:

[0034] Step S202: Receive a target instruction description sent by the target platform, wherein the target instruction description is used to instruct the target application to analyze the data generated during the execution of the target task by the target application;

[0035] The application runtime data analysis method in this embodiment can be applied to the fields of application runtime orchestration, dynamic observation, and network security technology. Specifically, it can be applied to scenarios involving restricted script dynamic orchestration, version mapping, secure execution, and execution result verification in application production environments. In modern applications, business users often want to dynamically observe, extract fields, diagnose links, or perform gray-scale analysis of network interactions without re-releasing the application version. However, traditional solutions typically rely on external debugging connections and general script injection tools, or on fixed tracking points and pre-built SDKs (Software Development Kits), making it difficult to simultaneously meet the requirements of low disturbance, cross-version adaptation, secure control, and verifiable results in a production environment. Moreover, when application versions are upgraded, network library implementations change, or page links are adjusted, existing scripts are prone to failure due to binding point drift, even leading to crashes, freezes, unauthorized access, or unauditable data collection behaviors. At the same time, while directly executing remotely distributed general scripts offers flexibility, the scripts may access unexpected system interfaces or business objects, leading to the exposure of sensitive information. Furthermore, the lack of unified budget control, rollback mechanisms, and execution proofs in the script execution logic makes it difficult for the platform to determine whether the script is actually executed according to constraints, and the client side also finds it difficult to quickly circuit break and restore to a stable state when an anomaly occurs.

[0036] To at least partially address the aforementioned technical issues, in this embodiment, when the platform receives an observation request including a target task from the observation console or policy platform, it does not directly send arbitrarily executable JavaScript or general script text to the target application. Instead, it standardizes the observation request into a task definition and then compiles the task definition into a restricted script intermediate representation (i.e., the aforementioned target instruction description). The target application can be a mobile application, desktop application, server application, etc., but is not limited to these. The restricted script intermediate representation may include, but is not limited to, task identifier, target anchor type, target field path, conditional filtering rules, allowed data transformation operator set, desensitization rules, result field template, maximum execution time, maximum memory usage, maximum number of hooks, maximum amount of data extracted, maximum reporting volume, minimum adaptation version, maximum adaptation version, and version constraint summary.

[0037] In at least one embodiment, after receiving the restricted script intermediate representation sent by the target platform, the client (i.e., the target application) can sequentially perform structural validity checks, field whitelist checks, operator whitelist checks, permission boundary checks, budget parameter validity checks, and version constraint pre-checks. Specifically, after receiving the restricted script intermediate representation, the client can first create a verification context for the task. The verification context may include a task identifier, client version identifier, anchor list version, verification status bits, failure reason codes, and the intermediate representation object to be compiled. Then, the client can sequentially call the structural validator, field validator, operator validator, permission validator, budget validator, and version validator according to a preset verification order. If any validator returns a failure result, subsequent verifications can be terminated immediately, the task status marked as refused execution, and the corresponding failure reason code recorded. The structure validator can parse and match patterns of restricted script intermediate representations based on intermediate representation pattern files built into the client or released with the application version. It verifies whether the intermediate representation contains required fields such as task identifier, target anchor type, target field path, conditional filtering rules, operator set, budget parameters, and version constraints. It can also verify whether field types, enumeration values, array lengths, nesting levels, and object structures conform to preset patterns, and rejects tasks containing unknown fields, illegally extended fields, or unparseable fields. The field validator can read the corresponding observable field whitelist from the local anchor list or field authorization table based on the target anchor type. It then splits the target field path into path nodes and matches them level by level (e.g., splitting response.body.userId into response, body, and userId). It determines whether each level of the path falls within the allowed access range. If the field path matches a privacy field, a business-sensitive field, a write field, or an unauthorized object, it returns a field privilege violation reason code. The operator validator can read the allowed operator identifiers, input parameter types, return types, maximum complexity, and composability rules from the client's pre-configured operator registry. It verifies each operator (field extraction, comparison, desensitization, aggregation, formatting, etc.) to ensure it belongs to the allowed set, and checks if the output type of the previous operator can be used as the input type of the next operator. The permission validator can determine that the task only has read-only observation permissions based on task permission bits and client security policies, and blocks file access, network access, system interface calls, reflection calls, thread creation, and business object writing capabilities before compilation. The budget validator can read the client's pre-configured resource limit table, verifying whether the maximum execution time, maximum memory usage, maximum number of hooks, maximum data extraction volume, and maximum reporting volume are within the allowed range, and initializes the corresponding budget counter for tasks that pass the verification.The version validator can read the current client version, build number, package hash, and anchor list version, and compare them with the minimum compatible version, maximum compatible version, and version constraint digest carried by the task. If they do not match, the execution will be rejected or an alternative stable plan that matches the current version will be selected.

[0038] Step S204: Based on the target instruction description, determine the target semantic anchors associated with the target task from the semantic anchor library;

[0039] In at least one embodiment, the target application can read the local anchor list (i.e., the semantic anchor library mentioned above) corresponding to the current version during runtime, and select the target semantic anchor that is most related to the target task to be observed from the semantic anchor library according to the restricted script intermediate representation. For example, the matching score of each semantic anchor in the semantic anchor library can be determined by the restricted script intermediate representation, and the semantic anchor corresponding to the maximum matching score is determined as the target semantic anchor.

[0040] Step S206: When the target semantic anchor is triggered, obtain the running data of the target application, analyze the running data, and obtain the target result of the target task.

[0041] In at least one embodiment, when the determined target semantic anchor is triggered at a certain point in the running process of the target application, the execution context of this observation task can be created according to the local execution plan, and a snapshot (i.e. the above-mentioned running data) can be formed on the request object, response object or intermediate business object within the read-only boundary. Then, according to the target field path, condition filtering rules and allowed data transformation operators, the running data is subjected to field extraction, result filtering and result shaping to obtain the target result.

[0042] In at least one embodiment, after the observation task is completed (i.e., the target task is generated), an execution proof summary can be generated based on the execution context of this task and returned to the target platform. The execution proof summary may include, but is not limited to, a task identifier, a plan version number, a client version identifier, the identifier of the hit semantic anchor (i.e., the aforementioned target semantic anchor), an anchor matching score, an actual call chain identifier or its summary value, a budget consumption value, the number of successfully extracted fields, a downgrade status, a rollback status, an exception code, a de-identified result summary, and an execution timestamp. It may also include a signature value, a verification value, or a summary value generated for the execution proof summary itself. When the client performs a rollback, the execution proof summary may also include a rollback status, a rollback plan identifier, a rollback reason, and the identifier of the original observation plan that was replaced. When the client refuses to execute, the target device can generate a task receipt or a refusal execution summary. The task receipt or refusal execution summary may include a refusal execution status, a refusal reason code, a task identifier, a client version identifier, and an anchor list version. The "Refuse to Execute" option applies to scenarios where the current task does not meet the conditions for secure execution, such as field paths hitting privacy or unauthorized fields, operators not being whitelisted, permission verification failing, strong version constraints not being met, target anchors being completely unmatched, candidate anchor semantics showing significant drift, or call chains being broken. In this case, the task carries risks of unauthorized access, misbinding, or being uncontrollable, so the client does not execute the task. The "Conservative Degradation" option applies to scenarios where the task can still be executed to a limited extent, but full execution is risky, such as insufficient anchor matching confidence but still above the minimum security threshold, some fields or operators being unsuitable for full execution in the current version, resource consumption approaching the threshold, or result integrity being risky. In this case, the client reduces the observation scope or execution intensity, for example, retaining only low-sensitivity fields, only reporting summaries, reducing trigger frequency, or disabling complex operators. The "Execution Rollback" option applies to scenarios where the current new plan is unstable, but there are historically validated stable plans, backup anchor plans, or low-risk compatible plans. In this case, the client does not execute the current new plan but switches to the previous stable plan and records the rollback status, rollback plan identifier, and rollback reason in the execution proof summary.

[0043] In at least one embodiment, the platform can predefine version constraints, anchor constraints, budget constraints, and result templates during the task definition or restricted script intermediate representation generation stage, and distribute them to the client along with the task. When the platform (i.e., the aforementioned target platform) receives the execution proof digest, it can perform a consistency check with the original task definition, version constraints, anchor constraints, budget constraints, and result templates. The version constraints can be used to limit the client version, build number, or anchor list version that the task is adapted to; the anchor constraints can be used to limit the target anchor type, call chain characteristics, context labels, and matching thresholds; the budget constraints can be used to limit the execution duration, memory, number of hooks, amount of data extracted, and amount of reporting; the result template can be used to limit the field names, field types, anonymization requirements, and output format that the observation results should include, i.e., whether the target results contain the required fields required by the result template, whether the field types are correct, whether the anonymized fields have been anonymized, whether the number of results matches the filtering rules, whether the result size does not exceed the maximum reporting amount, and whether the result digest corresponds to the task identifier, anchor identifier, and plan version in the execution context. If field extraction fails, resulting in missing required fields, or if the field names, types, and anonymization status after result shaping are inconsistent with the result template, the result integrity check is considered to have failed. This check is directly related to result filtering and result shaping, and is a post-validation of the output results. The client does not arbitrarily generate these constraints during runtime; instead, it validates, instantiates, and records these constraints based on the current version, actual hit anchors, budget consumption, and extraction results. When the validation passes, the platform can allow the corresponding observation results to enter the subsequent analysis chain. When the validation fails, the summary field is missing, or the constraints are inconsistent, the execution result is marked as unreliable, and further triggers re-issuance, manual review, cessation of the current plan, or switching to a backup stable plan.

[0044] This application demonstrates that upon receiving a target instruction description from the target platform, the target semantic anchor associated with the target task can be determined from a semantic anchor library using this description. The target instruction description instructs the target application to analyze the data generated during the execution of the target task. When the determined target semantic anchor associated with the target task is triggered, the target application's runtime data can be acquired and analyzed, thus obtaining the target task's outcome. Since the platform does not send an arbitrarily executable general script, but rather a verifiable and constrained observation description (i.e., the aforementioned target instruction description), the constrained observation description can be mapped to the current version's executable anchor (i.e., the aforementioned target semantic anchor) during the target application's runtime. This allows for obtaining the target outcome from analyzing the target application's runtime data while ensuring production environment stability and security. Therefore, it addresses the high risk associated with analyzing runtime data in applications, achieving a risk reduction effect.

[0045] Optionally, the entity performing the above steps may be the processor in the target application, or other devices with similar processing capabilities, but is not limited thereto.

[0046] In an exemplary embodiment, determining a target semantic anchor associated with the target task from a semantic anchor library based on the target instruction description includes: determining candidate semantic anchors based on first anchor information included in the target instruction description and second anchor information of semantic anchors included in the semantic anchor library; determining the target similarity between third anchor information of each candidate semantic anchor and the first anchor information; and determining the target semantic anchor based on multiple target similarities.

[0047] In at least one embodiment, the target application can read the local anchor list corresponding to the current version during runtime. Based on the target anchor type in the first anchor information included in the restricted script intermediate representation and the anchor type in the second anchor information of the semantic anchors included in the semantic anchor library, candidate semantic anchors with the same anchor type are first determined. Then, the candidate semantic anchors in the current version can be matched and scored according to the call chain features, parameter type features, context labels and version constraints in the first anchor information. That is, the target similarity corresponding to each candidate semantic anchor can be determined according to the call chain features, parameter type features, context labels and version constraints in the first anchor information and the third anchor information of the candidate semantic anchors. Finally, the target semantic anchor can be determined from multiple candidate semantic anchors according to the target similarity. For example, it can be determined whether the version information included in the third anchor information of the candidate semantic anchor is within the version constraint defined in the first anchor information, and the similarity score between the two can be determined. It can also be determined whether the intersection of the context label of the candidate semantic anchor and the context label in the first anchor information can be determined to further determine a similarity. Finally, the target similarity can be determined by weighted summation of the scores corresponding to the call chain feature, parameter type feature, context label and version constraint.

[0048] This embodiment extracts semantic anchors such as request construction points, sending points, response decoding points, and business deserialization points during the construction phase and generates version-related anchor description information for them. During runtime, restricted observation plans can be directly bound and validated based on the anchor description information, and rejection, downgrading, or rollback can be executed when anchor drift is detected. Because of the semantic anchor-version mapping mechanism, the observation logic does not directly depend on fixed hook points or specific function names, maintaining high execution stability and cross-version reusability during application version evolution, reducing the probability of observation plans failing or being misbound due to version upgrades.

[0049] In an exemplary embodiment, determining the target semantic anchor point based on multiple target similarities includes: determining sub-similarities included in the target similarities that are greater than or equal to a first preset threshold; determining the difference between every two sub-similarities to obtain multiple target differences; if there is a difference among the multiple target differences that is greater than a second preset threshold, determining the candidate semantic anchor point corresponding to the maximum value included in the sub-similarities as the target semantic anchor point; and if each target difference is less than the second preset threshold, determining the target semantic anchor point based on the target instruction description and the third anchor point information of the candidate semantic anchor points corresponding to the sub-similarities.

[0050] In at least one embodiment, two preset thresholds can be pre-set: a complete observation threshold (i.e., the first preset threshold mentioned above) and a minimum safety threshold, wherein the complete observation threshold is greater than the minimum safety threshold. When multiple target similarities include sub-similarity values ​​greater than or equal to the complete observation threshold, the difference between each pair of sub-similarity values ​​can be determined to obtain multiple target differences. For example, if the sub-similarity values ​​are A, B, C, and D, then the target differences are the differences between A and B, A and C, A and D, B and C, B and D, and C and D. When there is a difference among the multiple target differences that is greater than the second preset threshold, the candidate semantic anchor with the highest sub-similarity can be determined as the target semantic anchor. When each target difference is less than the second preset threshold, it indicates that the sub-similarity values ​​of the multiple candidate semantic anchors are close, and further trimming can be performed using the target instruction description and the third anchor information of the candidate semantic anchors.

[0051] In at least one embodiment, if no candidate anchor point that meets the minimum security threshold is found, or if the anchor point semantics are found to be significantly drifting, the call chain is broken, the key parameter types are inconsistent, the field access scope is exceeded, or the strong version constraint is not met, the client may refuse to execute the observation task and return the corresponding failure reason code. Here, "refuse to execute" can be understood as the client judging that the current observation task does not meet the conditions for safe execution, therefore it does not generate or start a local execution plan, directly terminates the task and returns the failure reason code, such as: field exceeding authority, operator exceeding authority, permission verification failure, strong version constraint not met, target anchor point cannot be matched at all, candidate anchor point semantics are significantly drifting, or the call chain is broken, etc.

[0052] In at least one embodiment, if the matching score of a candidate anchor point does not reach the full observation threshold but is higher than the minimum security threshold, or if some fields, operators, or reporting templates in the target task are not suitable for full execution in the current version, the client can enter a conservative degradation process in the anchor point mapping stage. This conservative degradation process can be understood as not directly performing full field extraction, but instead converting the original observation task into a low-risk backup plan, such as retaining only low-sensitivity fields, only reporting the execution status summary, switching to read-only snapshot verification, or waiting for rebinding in a subsequent version. If the current observation plan cannot be stably bound, but the client has a previous stable plan, backup anchor point plan, or historically verified low-risk plan that matches the current version, business scenario, or anchor point type, the client can roll back to that stable plan and record the rollback status, rollback plan identifier, and rollback reason in the execution proof summary. Rollback to a previous stable plan can be understood as follows: when the current new observation plan cannot be stably bound or executed, but the client has a historically validated stable plan, a backup anchor plan, or a low-risk compatible plan, the new plan is not executed; instead, the client switches to the previous stable plan to continue execution. During rollback execution, the client records the rollback status, rollback plan identifier, and rollback reason in the execution proof summary. In other words, refusal to execute means direct interception when there are no safe execution conditions, while rollback means switching the execution plan when an alternative stable solution exists.

[0053] In at least one embodiment, the score corresponding to each candidate semantic anchor can be determined based on the target similarity between the third anchor information and the first anchor information of each candidate semantic anchor. Then, a corresponding weight is assigned to each score. Finally, the target semantic anchor can be determined based on the total target score after weighted summation. Candidate anchors with a total target score greater than a preset threshold (e.g., 90 points) can be determined as target semantic anchors, and candidate anchors with a total target score less than 90 points but greater than 75 points undergo secondary arbitration. For example, for each candidate semantic anchor, its feature vector is extracted, which may include topological structure features (upstream and downstream anchor IDs), semantic features (method name, parameter type hash), context features (page ID at trigger time, business module identifier), and historical statistical features (historical hit success rate). Then, according to the preset scoring model, the sub-scores of the candidate semantic anchor and the target instruction description in terms of topological consistency, semantic similarity, and context matching degree are calculated respectively, and the total target score is generated according to the preset weights. In at least one embodiment, clustering can be performed based on multiple target similarities to divide them into multiple clusters. Then, the most matching candidate semantic anchor can be selected from each cluster. Finally, the target semantic anchor can be determined based on the target similarity of the selected candidate semantic anchors. For example, the candidate semantic anchor corresponding to the maximum target similarity can be determined as the target semantic anchor. A score can also be determined based on the target similarity of each candidate semantic anchor, and the one with the highest score can be determined as the target semantic anchor.

[0054] This embodiment allows the observation logic to not directly depend on specific function names, specific addresses, or fixed hook points, but instead rely on semantic anchor identifiers and matching rules that can be migrated across versions.

[0055] In an exemplary embodiment, determining the target semantic anchor based on the third anchor information of the candidate semantic anchors corresponding to the target instruction description and the sub-similarity includes: for each candidate semantic anchor, performing the following operations to determine a target score for the candidate semantic anchor, and determining the candidate semantic anchors corresponding to the target scores that are greater than or equal to a third preset threshold as the target semantic anchors: determining a first consistency score between the first anchor relationship included in the third anchor information and the second anchor relationship included in the target instruction description; determining a second consistency score between the first information included in the third anchor information and the second information included in the target instruction description, wherein the first information is used to represent the identification information when the candidate semantic anchor is triggered; determining whether the candidate semantic anchor is a historical semantic anchor based on the third anchor information to obtain a third consistency score; and determining the target score based on the first consistency score, the second consistency score, and the third consistency score.

[0056] In at least one embodiment, if each target difference is less than a second preset threshold, the target score of each candidate semantic anchor can be determined by combining the target instruction description and the third anchor information of the candidate semantic anchors. The candidate semantic anchor corresponding to the target score greater than or equal to the third preset threshold is determined as the target semantic anchor. For example, the candidate semantic anchor with the highest target score that is greater than or equal to the third preset threshold can be determined as the target semantic anchor. If it is still impossible to distinguish based on the target score, the observation task is not performed, and the anchor uncertainty state is output.

[0057] In at least one embodiment, the upstream and downstream anchors of the candidate semantic anchors can be compared to see if they are consistent with the anchor relationships in the target task definition. That is, the actual upstream and downstream anchor lists of the candidate semantic anchors can be determined from the third anchor information. Then, these are compared with the upstream and downstream anchor identifier sets in the second anchor relationship included in the target instruction description. A first consistency score can be determined by calculating their topological similarity. For example, the intersection and union of the upstream / downstream sets of the candidate anchors and the target definition sets can be calculated respectively. The calculated Jaccard similarity coefficient is then used as the first consistency score. Next, the page, business module, request path, or context label where the candidate semantic anchor is triggered can be compared to see if they are consistent with the task definition. That is, the business scenario labels to be parsed from the task definition can be extracted from the second information (target context labels) included in the target instruction description. These can include page identifiers, business modules, and request path features. Context labels (i.e., the aforementioned first information) can be extracted from the third anchor information. These can include the page to which the candidate semantic anchor belongs, the module to which it belongs, the URL path of the associated network request object, or the Host. Finally, a second consistency score is calculated between the two. It can also query local historical stable binding records to determine whether the candidate semantic anchor has been successfully bound and passed execution proof verification under the same client version and business scenario. In other words, it can also determine whether the candidate semantic anchor is a historical semantic anchor based on the third description information, thus determining the third consistency score. For example, if it is a historical semantic anchor, the third consistency score can be 1; if it is not a historical semantic anchor, the third consistency score can be 0. Finally, weights can be assigned to the above three scores (first consistency score, second consistency score, and third consistency score) to generate the target score.

[0058] This embodiment utilizes a first consistency score to ensure the structural correctness of the anchor call chain, a second consistency score to verify the business semantic matching degree of the trigger scenario, and a third consistency score to introduce historical execution reputation as a stability weight. The target score obtained by weighted fusion of these three factors can comprehensively reflect the overall adaptability of candidate anchors. Thus, it accurately locks the most stable semantic anchor among multiple highly similar candidates that not only conforms to the current version's code structure and business context but also has been historically verified. This significantly reduces the risk of misbinding caused by code refactoring or version iteration, and improves the execution success rate of dynamic observation tasks and the security of the production environment.

[0059] In one exemplary embodiment, before receiving the target instruction description sent by the target platform, the method further includes: determining the target code used by the target application when performing a task, the task including the target task; determining semantic anchors from the target code; determining second anchor information for each semantic anchor; and constructing the semantic anchor library based on the semantic anchors and the second anchor information.

[0060] In at least one embodiment, during the construction of the target application, static or semi-static analysis can be performed on the network link-related code paths (i.e., the target code mentioned above) in the target application to identify candidate execution locations such as request object construction, request sending, response decoding, business deserialization, and exception handling callbacks, and to filter out semantic anchors that can stably represent business semantics. For each semantic anchor, anchor description information (i.e., the second anchor information mentioned above) is generated. The anchor description information may include: anchor identifier, anchor type, module identifier, class name / method name characteristics, call chain fragment characteristics, input parameter type characteristics, return value type characteristics, context dependency tags, upstream anchor relationships, downstream anchor relationships, and version identifiers bound to the application build number, version number, or package body hash, etc. The generated anchor description information can be written to the client's local anchor list to construct a semantic anchor library containing semantic anchors and the corresponding second anchor information, used for runtime version mapping, anchor matching, and subsequent execution proof generation.

[0061] This embodiment not only shifts the time-consuming code parsing and anchor point extraction work from the runtime to the build phase, significantly reducing runtime resource overhead and performance fluctuation risks in the production environment, but also provides a solid data foundation for high-precision version mapping, semantic matching, and exception rollback based on restricted script instructions during runtime by pre-generating anchor point information containing rich contextual features. This ensures the stability, cross-version compatibility, and execution efficiency of the dynamic observation logic during application version iteration.

[0062] In one exemplary embodiment, obtaining the runtime data of the target application includes: determining the response object of the target task; extracting a target list field and the target field value corresponding to the target list field from the response object; constructing a field value mapping table based on the target list field and the target field value; determining a target snapshot based on the field value mapping table, and determining the target snapshot as the runtime data.

[0063] In at least one embodiment, after the target instruction description passes six-fold verification, the target application can update the verification status bit in the verification context to "pass" and compile the restricted script intermediate representation into an immutable local execution plan. The local execution plan can be a sequence of operations executed sequentially. For example, for an observation task that "extracts the response code and order status after response decoding is complete, and reports the user identifier after desensitization," the target application can compile it into the following operation sequence: wait for the target anchor point to trigger, create a read-only snapshot, determine if the response object meets the filtering conditions, extract the fields response.code and order.status, perform hash desensitization on userId, generate the observation result according to the result template, update the budget counter, and report the execution proof digest. The local execution plan can also be a state machine or a directed acyclic execution graph. For example, if the task contains conditional branches, the local execution plan can be represented as a state machine, for example, sequentially entering the waiting-for-trigger state, snapshot creation state, field extraction state, result shaping state, degradation state, and termination state. If there are dependencies between multiple field extraction and desensitization steps, the local execution plan can be represented as a directed acyclic execution graph, where each node represents a field extraction, conditional judgment, desensitization, aggregation, or reporting node, and the edges between nodes represent execution dependencies. The local execution plan only references field paths that have passed field whitelist validation, operator identifiers that have passed operator whitelist validation, and initialized budget counters, thereby avoiding runtime reinterpretation or execution of arbitrary script text.

[0064] In at least one embodiment, when the target semantic anchor is a response decoding completion anchor, the target application can create an execution context after the anchor is triggered. The execution context can record the task identifier, plan version number, anchor identifier, trigger time, budget counter, current thread identifier, and exception status. Subsequently, the target application can generate a read-only snapshot (i.e., the aforementioned target snapshot) of the response object. The read-only snapshot can be a copy of the whitelisted fields (i.e., the aforementioned target fields) in the response object or an immutable mapping structure. Finally, the read-only snapshot can be analyzed to obtain the target result.

[0065] This embodiment not only significantly reduces the storage and transmission overhead caused by non-critical data, but also ensures the consistency and integrity of observation data. This enables the platform to perform rapid analysis and verification based on standardized, lightweight snapshot data, thereby improving the utilization efficiency and analysis accuracy of dynamic observation data while ensuring low disturbance in the production environment.

[0066] In one exemplary embodiment, analyzing the runtime data to obtain the target result of the target task includes: determining a first field value from the runtime data according to the target field path included in the target instruction description; filtering the first field value based on the filtering rules included in the target instruction description to obtain a second field value; shaping the second field value based on the processing rules included in the target instruction description to obtain a third field value; and filling the result field template included in the target instruction description with the third field value to obtain the target result.

[0067] In at least one embodiment, the target application can read field values ​​from the read-only snapshot according to the target field paths included in the target instruction description to obtain the first field value, for example, reading response.code, response.body.orderStatus, and response.body.userId; then, the first field value can be filtered using the filtering rules included in the target instruction description to obtain the second field value, for example, judging whether response.code is equal to 200 according to the conditional filtering rules; if the condition is met, the second field value can be shaped using the processing rules included in the target instruction description to obtain the third field value, for example, performing a hash or truncation de-identification operator on userId; finally, the third field value can be used to fill the result field template included in the target instruction description to obtain the target result, for example, assembling code, orderStatus, and de-identified userId into a fixed format result (i.e., the above target result) according to the result field template. Throughout the process, the original response object is not modified, and the business write interface is not called.

[0068] This embodiment not only ensures the consistency and parsability of the data received by the platform, but also effectively avoids the risk of sensitive information leakage through upfront compliance processing, thereby significantly improving the availability, security, and automation efficiency of dynamic observation data and subsequent analysis.

[0069] In an exemplary embodiment, the method further includes: determining target parameters during the execution of the target instruction description by the target application, wherein the target parameters include at least one of the following: processor runtime, memory, number of code instrumentation triggers, amount of data extracted, amount of data reported, and number of target instruction descriptions running simultaneously; if the target parameters are greater than or equal to a fourth preset threshold, determining a target level based on the target parameters, wherein the target level is used to represent the degree of resource consumption in the target application; and performing a target operation corresponding to the target level, wherein the target operation includes at least one of the following: a downgrade operation, stopping the execution of the target instruction description, and executing a historical target instruction description, wherein the downgrade operation includes at least one of the following: reducing the number of first fields extracted, reducing the number of target instruction descriptions running simultaneously, and not analyzing the running data.

[0070] In at least one embodiment, during the entire execution of the target instruction description, the target parameters of the target application can be monitored in real time: processor runtime, memory, Hook count (i.e., the number of times the code instrumentation is triggered), data extraction volume, data reporting volume, and concurrency (i.e., the number of target instruction descriptions running simultaneously). A fourth preset threshold can be maintained for each target parameter, namely, budget counters for CPU time budget, memory budget, maximum Hook count, maximum data extraction volume, maximum reporting volume, and maximum concurrency. If any budget consumption reaches the warning threshold (i.e., the fourth preset threshold), the target level can be determined according to the target parameters, and the target operations corresponding to different target levels can be executed. The target operations can include downgrade operations (disabling high-frequency field extraction, reducing trigger frequency, retaining only read-only observations), stopping the execution of the target instruction description, and executing historical target instruction descriptions. Conservative downgrade can be understood as not continuing to execute the complete observation plan when the anchor matching confidence is insufficient, the version constraint is not met, or the resource consumption is close to the threshold, but instead reducing the observation range and execution intensity. Conservative degradation includes reducing the number of fields extracted, retaining only low-frequency, low-sensitivity fields; disabling computationally intensive operators such as aggregation, regular expression matching, and complex formatting; reducing trigger frequency, for example, changing execution from every anchor trigger to execution based on the sampling ratio; changing the reporting of complete observation results to only reporting execution status and summary information; performing only read-only snapshot verification without subsequent field extraction; or stopping the current plan and rolling back to the previous stable plan. The target application can select the appropriate degradation level based on the budget consumption ratio, anchor matching confidence, anomaly type, and task priority. Specifically, when the budget reaches the warning threshold, degradation can be triggered first. If the hard limit is still exceeded after degradation, it is considered that the budget has actually exceeded the limit, the client immediately terminates the current plan, records the anomaly code, and writes the corresponding budget consumption value and over-limit status into the execution proof summary. For example, when the actual budget is exceeded, the observed object is abnormal, the result integrity check fails, or unauthorized object access is detected, if only one of the target parameters reaches the warning threshold, a degradation operation can be performed first; if three of the target parameters reach the warning threshold, the current plan can be terminated immediately and an abnormal status can be output. During execution, only whitelisted observed objects and predefined operators are allowed to access; calling unauthorized system interfaces, modifying business object status, or accessing business-sensitive objects are not permitted. "Actual budget exceeding the limit" can be understood as the task exceeding the preset resource limit during execution, such as single execution time exceeding the maximum execution time, memory usage exceeding the maximum memory budget, Hook triggering times exceeding the maximum Hook count, field extraction count exceeding the maximum data extraction volume, or the size of the results to be reported exceeding the maximum reporting volume.

[0071] In at least one embodiment, the degradation operation here differs from the conservative degradation in the anchor mapping phase. This tiered degradation occurs after the target execution anchor has been determined and triggered, primarily to control resource consumption and outcome risks during actual execution. Specifically, the conservative degradation in the anchor mapping phase occurs when the target execution anchor is not yet fully determined or the anchor matching confidence is insufficient. At this time, complete field extraction is not performed; instead, the original observation task is converted into a low-risk backup plan, such as retaining only low-sensitivity fields, only reporting task status summaries, switching to read-only snapshot verification, or waiting for rebinding in subsequent versions. The conservative degradation in the execution phase occurs after the target execution anchor has been determined and triggered. At this point, the target application can reduce the number of fields extracted, disable complex operators, reduce triggering frequency, or stop the current plan and roll back to a stable plan based on budget consumption, field extraction results, or abnormal states.

[0072] This embodiment binds CPU time budget, memory budget, maximum number of hooks, and maximum reporting volume to each execution plan. When the budget is exceeded, degradation strategies are executed sequentially, including disabling high-frequency field extraction, retaining only read-only observations, and stopping and rolling back to a stable plan. Simultaneously, an execution proof digest containing anchor point identifiers, budget consumption, degradation status, and a result summary is generated, and its authenticity is verified by the platform. Because of the budget execution, tiered degradation, and automatic rollback mechanisms, the operational stability, rollback capability, and auditability in the production environment are improved, enabling the platform to verify whether the observation tasks are truly executed according to the constraints.

[0073] Figure 3 This is a flowchart illustrating an optional application runtime data analysis method according to an embodiment of this application. Figure 2 ,like Figure 3 As shown, the process of this method can be applied to the target platform and may include the following steps:

[0074] Step S302: Receive observation requirements, wherein the observation requirements include target tasks;

[0075] The application runtime data analysis method in this embodiment can be applied to the fields of application runtime orchestration, dynamic observation, and network security technology. Specifically, it can be applied to scenarios involving restricted script dynamic orchestration, version mapping, secure execution, and execution result verification in application production environments. In modern applications, business users often want to dynamically observe, extract fields, diagnose links, or perform gray-scale analysis of network interactions without re-releasing the application version. However, traditional solutions typically rely on external debugging connections and general script injection tools, or on fixed tracking points and pre-built SDKs (Software Development Kits), making it difficult to simultaneously meet the requirements of low disturbance, cross-version adaptation, secure control, and verifiable results in a production environment. Moreover, when application versions are upgraded, network library implementations change, or page links are adjusted, existing scripts are prone to failure due to binding point drift, even leading to crashes, freezes, unauthorized access, or unauditable data collection behaviors. At the same time, while directly executing remotely distributed general scripts offers flexibility, the scripts may access unexpected system interfaces or business objects, leading to the exposure of sensitive information. Furthermore, the lack of unified budget control, rollback mechanisms, and execution proofs in the script execution logic makes it difficult for the platform to determine whether the script is actually executed according to constraints, and the client side also finds it difficult to quickly circuit break and restore to a stable state when an anomaly occurs.

[0076] To at least partially address the aforementioned technical issues, in this embodiment, the platform can first receive observation requests from the observation console or policy platform. These observation requests contain target tasks. Specifically, observation requests can be understood as a collection of specific runtime data, behavior logs, or diagnostic information that the business wants to obtain from the target application. That is, when the target application executes the target task, the data related to the target task can be analyzed to obtain the data related to the observation requests. For example, an observation request could be "monitor the response time and success rate of all homepage interfaces," or it could be "I want to see if the user ID is correct in the order data actually submitted to the backend after the user clicks the 'Buy Now' button," and so on.

[0077] Step S304: Generate a target instruction description based on the observation requirements, wherein the target instruction description is used to instruct the target application to analyze the data generated during the execution of the target task by the target application;

[0078] In at least one embodiment, when the platform receives an observation request including the target task from the observation console or policy platform, it does not directly send arbitrarily executable JavaScript or general script text to the target application. Instead, it standardizes the observation request into a task definition and then compiles the task definition into a restricted script intermediate representation (i.e., the aforementioned target instruction description). The target application can be a mobile application, a desktop application, a server application, etc., but is not limited to these. The restricted script intermediate representation may include, but is not limited to, task identifier, target anchor type, target field path, conditional filtering rules, allowed set of data transformation operators, de-identification rules, result field template, maximum execution time, maximum memory usage, maximum number of hooks, maximum amount of data extracted, maximum reporting volume, minimum adaptation version, maximum adaptation version, and version constraint summary.

[0079] Step S306: The target instruction description is sent to the target platform to instruct the target platform to determine the target semantic anchor associated with the target task from the semantic anchor library based on the target instruction description. When the target semantic anchor is triggered, the target application is instructed to obtain the running data of the target application and analyze the running data to obtain the target result of the target task.

[0080] In at least one embodiment, after receiving the restricted script intermediate representation sent by the target platform, the client (i.e., the target application) can sequentially perform structural validity checks, field whitelist checks, operator whitelist checks, permission boundary checks, budget parameter validity checks, and version constraint pre-checks. Specifically, after receiving the restricted script intermediate representation, the client can first create a verification context for the task. The verification context may include a task identifier, client version identifier, anchor list version, verification status bits, failure reason codes, and the intermediate representation object to be compiled. Then, the client can sequentially call the structural validator, field validator, operator validator, permission validator, budget validator, and version validator according to a preset verification order. If any validator returns a failure result, subsequent verifications can be terminated immediately, the task status marked as refused execution, and the corresponding failure reason code recorded. The structure validator can parse and match patterns of restricted script intermediate representations based on intermediate representation pattern files built into the client or released with the application version. It verifies whether the intermediate representation contains required fields such as task identifier, target anchor type, target field path, conditional filtering rules, operator set, budget parameters, and version constraints. It can also verify whether field types, enumeration values, array lengths, nesting levels, and object structures conform to preset patterns, and rejects tasks containing unknown fields, illegally extended fields, or unparseable fields. The field validator can read the corresponding observable field whitelist from the local anchor list or field authorization table based on the target anchor type. It then splits the target field path into path nodes and matches them level by level (e.g., splitting response.body.userId into response, body, and userId). It determines whether each level of the path falls within the allowed access range. If the field path matches a privacy field, a business-sensitive field, a write field, or an unauthorized object, it returns a field privilege violation reason code. The operator validator can read the allowed operator identifiers, input parameter types, return types, maximum complexity, and composability rules from the client's pre-configured operator registry. It verifies each operator (field extraction, comparison, desensitization, aggregation, formatting, etc.) to ensure it belongs to the allowed set, and checks if the output type of the previous operator can be used as the input type of the next operator. The permission validator can determine that the task only has read-only observation permissions based on task permission bits and client security policies, and blocks file access, network access, system interface calls, reflection calls, thread creation, and business object writing capabilities before compilation. The budget validator can read the client's pre-configured resource limit table, verifying whether the maximum execution time, maximum memory usage, maximum number of hooks, maximum data extraction volume, and maximum reporting volume are within the allowed range, and initializes the corresponding budget counter for tasks that pass the verification.The version validator can read the current client version, build number, package hash, and anchor list version, and compare them with the minimum compatible version, maximum compatible version, and version constraint digest carried by the task. If they do not match, the execution will be rejected or an alternative stable plan that matches the current version will be selected.

[0081] In at least one embodiment, the target application can read the local anchor list (i.e., semantic anchor library) corresponding to the current version during runtime, and select the target semantic anchor most related to the target task to be observed from the semantic anchor library according to the restricted script intermediate representation. For example, the matching score of each semantic anchor in the semantic anchor library can be determined by the restricted script intermediate representation, and the semantic anchor corresponding to the maximum matching score is determined as the target semantic anchor.

[0082] In at least one embodiment, if each target difference is less than a second preset threshold, the target score of each candidate semantic anchor can be determined by combining the target instruction description and the third anchor information of the candidate semantic anchors. The candidate semantic anchor corresponding to the target score greater than or equal to the third preset threshold is determined as the target semantic anchor. For example, the candidate semantic anchor with the highest target score that is greater than or equal to the third preset threshold can be determined as the target semantic anchor. If it is still impossible to distinguish based on the target score, the observation task is not performed, and the anchor uncertainty state is output.

[0083] In at least one embodiment, the upstream and downstream anchors of the candidate semantic anchors can be compared to see if they are consistent with the anchor relationships in the target task definition. That is, the actual upstream and downstream anchor lists of the candidate semantic anchors can be determined from the third anchor information. Then, these are compared with the upstream and downstream anchor identifier sets in the second anchor relationship included in the target instruction description. A first consistency score can be determined by calculating their topological similarity. For example, the intersection and union of the upstream / downstream sets of the candidate anchors and the target definition sets can be calculated respectively. The calculated Jaccard similarity coefficient is then used as the first consistency score. Next, the page, business module, request path, or context label where the candidate semantic anchor is triggered can be compared to see if they are consistent with the task definition. That is, the business scenario labels to be parsed from the task definition can be extracted from the second information (target context labels) included in the target instruction description. These can include page identifiers, business modules, and request path features. Context labels (i.e., the aforementioned first information) can be extracted from the third anchor information. These can include the page to which the candidate semantic anchor belongs, the module to which it belongs, the URL path of the associated network request object, or the Host. Finally, a second consistency score is calculated between the two. It can also query local historical stable binding records to determine whether the candidate semantic anchor has been successfully bound and passed execution proof verification under the same client version and business scenario. In other words, it can also determine whether the candidate semantic anchor is a historical semantic anchor based on the third description information, thus determining the third consistency score. For example, if it is a historical semantic anchor, the third consistency score can be 1; if it is not a historical semantic anchor, the third consistency score can be 0. Finally, weights can be assigned to the above three scores (first consistency score, second consistency score, and third consistency score) to generate the target score.

[0084] In at least one embodiment, during the construction of the target application, static or semi-static analysis can be performed on the network link-related code paths (i.e., the target code mentioned above) in the target application to identify candidate execution locations such as request object construction, request sending, response decoding, business deserialization, and exception handling callbacks, and to filter out semantic anchors that can stably represent business semantics. For each semantic anchor, anchor description information (i.e., the second anchor information mentioned above) is generated. The anchor description information may include: anchor identifier, anchor type, module identifier, class name / method name characteristics, call chain fragment characteristics, input parameter type characteristics, return value type characteristics, context dependency tags, upstream anchor relationships, downstream anchor relationships, and version identifiers bound to the application build number, version number, or package body hash, etc. The generated anchor description information can be written to the client's local anchor list to construct a semantic anchor library containing semantic anchors and the corresponding second anchor information, used for runtime version mapping, anchor matching, and subsequent execution proof generation.

[0085] In at least one embodiment, after the target instruction description passes six-fold verification, the target application can update the verification status bit in the verification context to "pass" and compile the restricted script intermediate representation into an immutable local execution plan. The local execution plan can be a sequence of operations executed sequentially. For example, for an observation task that "extracts the response code and order status after response decoding is complete, and reports the user identifier after desensitization," the target application can compile it into the following operation sequence: wait for the target anchor point to trigger, create a read-only snapshot, determine if the response object meets the filtering conditions, extract the fields response.code and order.status, perform hash desensitization on userId, generate the observation result according to the result template, update the budget counter, and report the execution proof digest. The local execution plan can also be a state machine or a directed acyclic execution graph. For example, if the task contains conditional branches, the local execution plan can be represented as a state machine, for example, sequentially entering the waiting-for-trigger state, snapshot creation state, field extraction state, result shaping state, degradation state, and termination state. If there are dependencies between multiple field extraction and desensitization steps, the local execution plan can be represented as a directed acyclic execution graph, where each node represents a field extraction, conditional judgment, desensitization, aggregation, or reporting node, and the edges between nodes represent execution dependencies. The local execution plan only references field paths that have passed field whitelist validation, operator identifiers that have passed operator whitelist validation, and initialized budget counters, thereby avoiding runtime reinterpretation or execution of arbitrary script text.

[0086] In at least one embodiment, when the target semantic anchor is a response decoding completion anchor, the target application can create an execution context after the anchor is triggered. The execution context can record the task identifier, plan version number, anchor identifier, trigger time, budget counter, current thread identifier, and exception status. Subsequently, the target application can generate a read-only snapshot (i.e., the aforementioned target snapshot) of the response object. The read-only snapshot can be a copy of the whitelisted fields (i.e., the aforementioned target fields) in the response object or an immutable mapping structure. Finally, the read-only snapshot can be analyzed to obtain the target result.

[0087] In at least one embodiment, the target application can read field values ​​from the read-only snapshot according to the target field paths included in the target instruction description to obtain the first field value, for example, reading response.code, response.body.orderStatus, and response.body.userId; then, the first field value can be filtered using the filtering rules included in the target instruction description to obtain the second field value, for example, judging whether response.code is equal to 200 according to the conditional filtering rules; if the condition is met, the second field value can be shaped using the processing rules included in the target instruction description to obtain the third field value, for example, performing a hash or truncation de-identification operator on userId; finally, the third field value can be used to fill the result field template included in the target instruction description to obtain the target result, for example, assembling code, orderStatus, and de-identified userId into a fixed format result (i.e., the above target result) according to the result field template. Throughout the process, the original response object is not modified, and the business write interface is not called.

[0088] In at least one embodiment, during the entire execution of the target instruction description, the target parameters of the target application can be monitored in real time: processor runtime, memory, Hook count (i.e., the number of times the code instrumentation is triggered), data extraction volume, data reporting volume, and concurrency (i.e., the number of target instruction descriptions running simultaneously). A fourth preset threshold can be maintained for each target parameter, namely, budget counters for CPU time budget, memory budget, maximum Hook count, maximum data extraction volume, maximum reporting volume, and maximum concurrency. If any budget consumption reaches the warning threshold (i.e., the fourth preset threshold), the target level can be determined according to the target parameters, and the target operations corresponding to different target levels can be executed. The target operations can include downgrade operations (disabling high-frequency field extraction, reducing trigger frequency, retaining only read-only observations), stopping the execution of the target instruction description, and executing historical target instruction descriptions. Conservative downgrade can be understood as not continuing to execute the complete observation plan when the anchor matching confidence is insufficient, the version constraint is not met, or the resource consumption is close to the threshold, but instead reducing the observation range and execution intensity. Conservative degradation includes reducing the number of fields extracted, retaining only low-frequency, low-sensitivity fields; disabling computationally intensive operators such as aggregation, regular expression matching, and complex formatting; reducing trigger frequency, for example, changing execution from every anchor trigger to execution based on the sampling ratio; changing the reporting of complete observation results to only reporting execution status and summary information; performing only read-only snapshot verification without subsequent field extraction; or stopping the current plan and rolling back to the previous stable plan. The target application can select the appropriate degradation level based on the budget consumption ratio, anchor matching confidence, anomaly type, and task priority. Specifically, when the budget reaches the warning threshold, degradation can be triggered first. If the hard limit is still exceeded after degradation, it is considered that the budget has actually exceeded the limit, the client immediately terminates the current plan, records the anomaly code, and writes the corresponding budget consumption value and over-limit status into the execution proof summary. For example, when the actual budget is exceeded, the observed object is abnormal, the result integrity check fails, or unauthorized object access is detected, if only one of the target parameters reaches the warning threshold, a degradation operation can be performed first; if three of the target parameters reach the warning threshold, the current plan can be terminated immediately and an abnormal status can be output. During execution, only whitelisted observed objects and predefined operators are allowed to access; calling unauthorized system interfaces, modifying business object status, or accessing business-sensitive objects are not permitted. "Actual budget exceeding the limit" can be understood as the task exceeding the preset resource limit during execution, such as single execution time exceeding the maximum execution time, memory usage exceeding the maximum memory budget, Hook triggering times exceeding the maximum Hook count, field extraction count exceeding the maximum data extraction volume, or the size of the results to be reported exceeding the maximum reporting volume.

[0089] In at least one embodiment, the degradation operation here differs from the conservative degradation in the anchor mapping phase. This tiered degradation occurs after the target execution anchor has been determined and triggered, primarily to control resource consumption and outcome risks during actual execution. Specifically, the conservative degradation in the anchor mapping phase occurs when the target execution anchor is not yet fully determined or the anchor matching confidence is insufficient. At this time, complete field extraction is not performed; instead, the original observation task is converted into a low-risk backup plan, such as retaining only low-sensitivity fields, only reporting task status summaries, switching to read-only snapshot verification, or waiting for rebinding in subsequent versions. The conservative degradation in the execution phase occurs after the target execution anchor has been determined and triggered. At this point, the target application can reduce the number of fields extracted, disable complex operators, reduce triggering frequency, or stop the current plan and roll back to a stable plan based on budget consumption, field extraction results, or abnormal states.

[0090] This application enables the generation of target instruction descriptions upon receiving observation requests containing target tasks. These descriptions are then sent to the target application. Upon receiving the target instruction descriptions from the target platform, the target application can identify the target semantic anchors associated with the target task from a semantic anchor library. The target instruction descriptions instruct the target application to analyze the data generated during the execution of the target task. When the identified target semantic anchors associated with the target task are triggered, the application's runtime data can be acquired and analyzed to obtain the target task's outcome. Since the platform does not send arbitrarily executable general scripts but rather verifiable and constrained observation descriptions (i.e., target instruction descriptions), these descriptions can be mapped to the current version's executable anchors (i.e., target semantic anchors) during the application's runtime. This allows for obtaining the target results from analyzing the application's runtime data while ensuring production environment stability and security. Therefore, this addresses the high risk associated with analyzing runtime data in applications, effectively reducing risk.

[0091] Optionally, the entity performing the above steps may be the target platform or other devices with similar processing capabilities, but is not limited thereto.

[0092] Figure 4 This is a flowchart illustrating the method for analyzing runtime data of the application in this optional example, such as... Figure 4 As shown, the process of analyzing the application's runtime data may include the following steps:

[0093] Step S402, Begin;

[0094] Step S404: Extract semantic anchors and generate a local anchor list, identifying request construction points, sending points, response decoding points, and business deserialization points;

[0095] Step S406: Compile the restricted script intermediate representation to generate task definition, target anchor, budget parameters and version constraints;

[0096] Step S408: Perform version mapping and anchor binding, matching the current version with the target execution anchor;

[0097] Step S410: Determine if a target anchor point is matched. If yes, proceed to step S412; otherwise, proceed to step S426.

[0098] Step S412: Execute the rule task and perform budget control, including field extraction, result filtering, and result shaping;

[0099] Step S414: Determine if an exception or budget overrun has been triggered. If yes, proceed to step S416; otherwise, proceed to step S418.

[0100] Step S416: Downgrade or rollback, switch to stable computing;

[0101] Step S418: Generate an execution proof digest and send it back to the platform. The platform verifies the credibility of the result.

[0102] Step S420: Determine if the platform verification is successful. If yes, proceed to step S422; otherwise, proceed to step S424.

[0103] Step S422: Output a reliable result;

[0104] Step S424: Output an unreliable result and proceed to review or reissue.

[0105] Step S426: Reject execution or rollback, output stable plan results.

[0106] In at least one embodiment, Figure 5 This is a structural block diagram of an application runtime data analysis system according to an embodiment of this application, such as... Figure 5As shown, it can include a semantic anchor extraction module, a restricted script compilation module, a version mapping and binding module, and an execution proof digest module. The semantic anchor extraction module can analyze the network call chain during the application construction phase, extract semantic anchors such as request construction points, request sending points, response decoding points, and business deserialization points, and generate anchor description information for each semantic anchor. Anchor point description information can include the module identifier, call chain characteristics, parameter type characteristics, context dependencies, and version identifier bound to the application build number. This information can be used for version mapping and stable binding of subsequent runtime execution plans. The restricted script compilation module can be deployed on the platform side and can be used to compile observation tasks into a restricted script intermediate representation, and attach permission boundaries, execution budgets, version constraints, and reporting templates. The output of the restricted script compilation module is not a generic script text that can be executed arbitrarily, but a restricted execution description that only allows access to whitelisted observation objects and finite operators. The version mapping and binding module can be deployed on the client side and can be used to read the anchor point description information corresponding to the current application version at runtime and bind the restricted script intermediate representation issued by the platform to the semantic anchor points that can be executed in the current version. If an anchor point mismatch, semantic drift, or version constraint failure is found, execution is rejected or downgraded. The Constrained Execution and Budget Control module is responsible for executing constrained observation plans during runtime, and binding CPU time budget, memory budget, maximum number of hooks, maximum reporting volume, and maximum concurrency to each execution. It triggers tiered degradation and automatic rollback when budget limits are exceeded, observations are abnormal, or results are unreliable. The Execution Proof Summary module generates an execution proof summary for each observation plan's actual execution. The summary can include the script plan version, anchor point identifier, actual hit call chain identifier, budget consumption, degradation status, rollback status, and anonymized result summary. The platform can then verify whether the observation plan was truly executed according to the constraints based on the execution proof summary.

[0107] In this optional example, the platform does not directly issue freely executable JavaScript or general script text. Instead, it provides verifiable and constrained observation descriptions. The platform compiles the observation requirements into a constrained script intermediate representation, which only describes the allowed observation objects, field extraction rules, conditional filtering rules, allowed data transformation operators, budget parameters, and result reporting format. The client does not directly interpret and execute arbitrary scripts; it only performs structural, permission, and budget checks on the constrained intermediate representation before compiling it into a local execution plan. During execution, access is only allowed to whitelisted observation objects and predefined operators. The underlying integration capabilities can be implemented using Frida-Gadget, native system interception capabilities, or other equivalent runtime instrumentation components. Therefore, the dynamic observation logic no longer relies on direct execution of general scripts but achieves secure and controlled production environment operation through the constrained script intermediate representation. This reduces the risk of malicious, unauthorized, and uncontrollable scripts disrupting the main business logic, and enables the dynamic observation logic to possess verifiable, constrained, and rollback-capable operational characteristics.

[0108] 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 preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0109] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory (ROM) / random access memory (RAM), magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0110] According to another aspect of the embodiments of this application, an application runtime data analysis apparatus is also provided. This apparatus can be used to implement the application runtime data analysis method provided in the above embodiments, and details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0111] Figure 6 This is a structural block diagram of an optional application runtime data analysis device according to an embodiment of this application. Figure 1 ,like Figure 6 As shown, the device for analyzing the application's operational data includes:

[0112] The first receiving module 62 is used to receive a target instruction description sent by the target platform, wherein the target instruction description is used to instruct the target application to analyze the data generated during the execution of the target task by the target application;

[0113] The determination module 64 is used to determine the target semantic anchors associated with the target task from the semantic anchor library based on the target instruction description;

[0114] The acquisition module 66 is used to acquire the running data of the target application when the target semantic anchor is triggered, and to analyze the running data to obtain the target result of the target task.

[0115] The receiving module 62 corresponds to the aforementioned restricted script compilation module, and the determining module 54 and the obtaining module 66 correspond to the aforementioned version mapping and binding module.

[0116] In an exemplary embodiment, the determining module 64 may determine the target semantic anchor associated with the target task from the semantic anchor library based on the target instruction description in the following manner: determining candidate semantic anchors based on the first anchor information included in the target instruction description and the second anchor information of the semantic anchors included in the semantic anchor library; determining the target similarity between the third anchor information of each candidate semantic anchor and the first anchor information; and determining the target semantic anchor based on the multiple target similarities.

[0117] In an exemplary embodiment, the determining module 64 can determine the target semantic anchor point based on multiple target similarities in the following manner: determining sub-similarities included in the target similarities that are greater than or equal to a first preset threshold; determining the difference between every two sub-similarities to obtain multiple target differences; if there is a difference among the multiple target differences that is greater than a second preset threshold, determining the candidate semantic anchor point corresponding to the maximum value included in the sub-similarities as the target semantic anchor point; if each target difference is less than the second preset threshold, determining the target semantic anchor point based on the target instruction description and the third anchor point information of the candidate semantic anchor points corresponding to the sub-similarities.

[0118] In an exemplary embodiment, the determining module 64 can determine the target semantic anchor based on the third anchor information of the candidate semantic anchors corresponding to the target instruction description and the sub-similarity in the following manner: For each candidate semantic anchor, the following operations are performed to determine the target score of the candidate semantic anchor, and the candidate semantic anchor corresponding to the target score that is greater than or equal to a third preset threshold is determined as the target semantic anchor: determining a first consistency score between the first anchor relationship included in the third anchor information and the second anchor relationship included in the target instruction description; determining a second consistency score between the first information included in the third anchor information and the second information included in the target instruction description, wherein the first information is used to represent the identification information when the candidate semantic anchor is triggered; determining whether the candidate semantic anchor is a historical semantic anchor based on the third anchor information to obtain a third consistency score; and determining the target score based on the first consistency score, the second consistency score, and the third consistency score.

[0119] In one exemplary embodiment, the apparatus is further configured to: determine the target code used by the target application when performing a task, the task including the target task, before receiving a target instruction description sent by the target platform; determine semantic anchors from the target code; determine second anchor information for each semantic anchor; and construct the semantic anchor library based on the semantic anchors and the second anchor information.

[0120] In an exemplary embodiment, the acquisition module 66 may acquire the runtime data of the target application by: determining the response object of the target task; extracting the target list field and the target field value corresponding to the target list field from the response object; constructing a field value mapping table based on the target list field and the target field value; determining the target snapshot based on the field value mapping table, and determining the target snapshot as the runtime data.

[0121] In an exemplary embodiment, the acquisition module 66 can analyze the running data to obtain the target result of the target task in the following manner: determine the first field value from the running data according to the target field path included in the target instruction description; filter the first field value based on the filtering rules included in the target instruction description to obtain the second field value; shape the second field value based on the processing rules included in the target instruction description to obtain the third field value; and fill the result field template included in the target instruction description with the third field value to obtain the target result.

[0122] In an exemplary embodiment, the apparatus is further configured to: determine target parameters during the execution of the target instruction description by the target application, wherein the target parameters include at least one of the following: processor runtime, memory, number of code instrumentation triggers, amount of data extracted, amount of data reported, and number of target instruction descriptions running simultaneously; if the target parameters are greater than or equal to a fourth preset threshold, determine a target level based on the target parameters, wherein the target level is used to represent the degree of resource consumption in the target application; and execute a target operation corresponding to the target level, wherein the target operation includes at least one of the following: a downgrade operation, stopping the execution of the target instruction description, and executing a historical target instruction description, wherein the downgrade operation includes at least one of the following: reducing the number of first fields extracted, reducing the number of target instruction descriptions running simultaneously, and not analyzing the running data.

[0123] Figure 7 This is a structural block diagram of an optional application runtime data analysis device according to an embodiment of this application. Figure 2 ,like Figure 7 As shown, the device for analyzing the application's operational data includes:

[0124] The second receiving module 72 is used to receive observation requests, wherein the observation requests include target tasks;

[0125] The generation module 74 is used to generate a target instruction description based on the observation requirements, wherein the target instruction description is used to instruct the target application to analyze the data generated during the execution of the target task by the target application;

[0126] The sending module 76 is used to send the target instruction description to the target platform to instruct the target platform to determine the target semantic anchor associated with the target task from the semantic anchor library based on the target instruction description. When the target semantic anchor is triggered, the target application is instructed to obtain the running data of the target application and analyze the running data to obtain the target result of the target task.

[0127] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0128] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored program, wherein the program executes the steps in any of the above method embodiments when it is run.

[0129] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, ROMs, RAMs, portable hard drives, magnetic disks, or optical disks.

[0130] According to another aspect of the embodiments of this application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor is configured to perform the steps of any of the method embodiments described above via the computer program. In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0131] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0132] According to another aspect of the embodiments of this application, a computer program product is also provided, comprising a computer program / instructions containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication section 809, and / or installed from a removable medium 811. When the computer program is executed by a central processing unit 801, it performs various functions provided in the embodiments of this application. The sequence numbers of the embodiments of this application above are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0133] Figure 8 A schematic block diagram of a computer system architecture for implementing embodiments of the present application is shown. Figure 8As shown, the computer system 800 includes a Central Processing Unit (CPU) 801, which can perform various appropriate actions and processes based on programs stored in ROM 802 or programs loaded into RAM 803 from storage section 808. Random Access Memory 803 also stores various programs and data required for system operation. The CPU 801, ROM 802, and RAM 803 are interconnected via bus 804. Input / Output (I / O) interface 805 is also connected to bus 804.

[0134] The following components are connected to I / O interface 805: an input section 806 including a keyboard, mouse, etc.; an output section 807 including a cathode ray tube (CRT), liquid crystal display (LCD), and speakers, etc.; a storage section 808 including a hard disk, etc.; and a communication section 809 including a network interface card, such as a local area network card or modem, etc. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to I / O interface 805 as needed. Removable media 811, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 810 as needed so that computer programs read from them can be installed into storage section 808 as needed.

[0135] Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 809, and / or installed from removable medium 811. When the computer program is executed by central processing unit 801, it performs various functions defined in the system of this application.

[0136] It should be noted that, Figure 8 The computer system 800 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0137] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0138] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A method for analyzing operational data of an application, characterized in that, Applied to target applications, including: The target application receives a target instruction description sent by the target platform, wherein the target instruction description is used to instruct the target application to analyze the data generated during the execution of the target task by the target application; Based on the target instruction description, target semantic anchors associated with the target task are determined from the semantic anchor library; When the target semantic anchor is triggered, the running data of the target application is acquired, and the running data is analyzed to obtain the target result of the target task.

2. The method according to claim 1, characterized in that, Based on the target instruction description, determine the target semantic anchors associated with the target task from the semantic anchor library, including: Candidate semantic anchors are determined based on the first anchor information included in the target instruction description and the second anchor information of the semantic anchors included in the semantic anchor library; Determine the target similarity between the third anchor information and the first anchor information of each candidate semantic anchor; The target semantic anchor point is determined based on the similarity of multiple targets.

3. The method according to claim 2, characterized in that, Determining the target semantic anchor point based on multiple target similarities includes: Determine the sub-similarity values ​​that are greater than or equal to a first preset threshold included in the target similarity; The difference between every two sub-similarities is determined to obtain multiple target differences; If there is a difference greater than the second preset threshold among the multiple target differences, the candidate semantic anchor point corresponding to the maximum value included in the sub-similarity is determined as the target semantic anchor point; When each of the target differences is less than the second preset threshold, the target semantic anchor is determined based on the third anchor information of the candidate semantic anchor corresponding to the target instruction description and the sub-similarity.

4. The method according to claim 3, characterized in that, Determining the target semantic anchor point based on the third anchor point information of the candidate semantic anchor points corresponding to the target instruction description and the sub-similarity includes: For each candidate semantic anchor, the following operations are performed to determine the target score of the candidate semantic anchor, and to determine the candidate semantic anchor corresponding to the target score that is greater than or equal to a third preset threshold as the target semantic anchor: A first consistency score is determined between the first anchor relationship included in the third anchor information and the second anchor relationship included in the target instruction description; A second consistency score is determined between the first information included in the third anchor point information and the second information included in the target instruction description, wherein the first information is used to represent the identification information when the candidate semantic anchor point is triggered; Based on the third anchor point information, determine whether the candidate semantic anchor point is a historical semantic anchor point, and obtain the third consistency score; The target score is determined based on the first consistency score, the second consistency score, and the third consistency score.

5. The method according to claim 1, characterized in that, Before receiving the target instruction description sent by the target platform, the method further includes: Determine the target code used by the target application when performing a task, wherein the task includes the target task; Semantic anchors are determined from the target code; Determine the second anchor information for each of the semantic anchors; The semantic anchor library is constructed based on the semantic anchor and the second anchor information.

6. The method according to claim 1, characterized in that, Obtain the runtime data of the target application, including: Determine the response object for the target task; Extract the target list field and the target field value corresponding to the target list field from the response object; Construct a field value mapping table based on the target list field and the target field value; The target snapshot is determined based on the field value mapping table, and the target snapshot is identified as the running data.

7. The method according to claim 1, characterized in that, The operational data is analyzed to obtain the target result of the target task, including: The first field value is determined from the running data according to the target field path included in the target instruction description; The first field value is filtered based on the filtering rules included in the target instruction description to obtain the second field value; The second field value is shaped based on the processing rules included in the target instruction description to obtain the third field value; The target result is obtained by filling the result field template included in the target instruction description with the value of the third field.

8. The method according to claim 1, characterized in that, The method further includes: Determine the target parameters during the execution of the target instruction description by the target application, wherein the target parameters include at least one of the following: processor runtime, memory, number of code instrumentation triggers, amount of data extracted, amount of data reported, and number of target instruction descriptions running simultaneously; If the target parameter is greater than or equal to a fourth preset threshold, a target level is determined based on the target parameter, wherein the target level is used to represent the degree of resource consumption in the target application; Execute the target operation corresponding to the target level, wherein the target operation includes at least one of the following: downgrade operation, stop executing the target instruction description and execute historical target instruction description, and the downgrade operation includes at least one of the following: reduce the number of first fields extracted, reduce the number of target instruction descriptions running simultaneously, and do not analyze the running data.

9. A method for analyzing operational data of an application, characterized in that, Applied to target platforms, including: Receive observation requests, wherein the observation requests include target tasks; A target instruction description is generated based on the observation requirements, wherein the target instruction description is used to instruct the target application to analyze the data generated during the execution of the target task by the target application; The target instruction description is sent to the target platform to instruct the target platform to determine the target semantic anchor associated with the target task from the semantic anchor library based on the target instruction description. When the target semantic anchor is triggered, the target application is instructed to obtain the running data of the target application and analyze the running data to obtain the target result of the target task.

10. An analysis device for application operation data, characterized in that, Applied to target applications, including: The first receiving module is used to receive a target instruction description sent by the target platform, wherein the target instruction description is used to instruct the target application to analyze the data generated during the execution of the target task by the target application; The determination module is used to determine the target semantic anchors associated with the target task from the semantic anchor library based on the target instruction description; The acquisition module is used to acquire the running data of the target application when the target semantic anchor is triggered, and to analyze the running data to obtain the target result of the target task.

11. An analysis device for operational data of an application, characterized in that, Applied to target platforms, including: The second receiving module is used to receive observation requests, wherein the observation requests include target tasks; A generation module is used to generate a target instruction description based on the observation requirements, wherein the target instruction description is used to instruct the target application to analyze the data generated during the execution of the target task by the target application; The sending module is used to send the target instruction description to the target platform to instruct the target platform to determine the target semantic anchor associated with the target task from the semantic anchor library based on the target instruction description. When the target semantic anchor is triggered, the module instructs the target application to obtain the running data of the target application and analyze the running data to obtain the target result of the target task.

12. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 9 or claim 10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the method according to any one of claims 1 to 9 or claim 10.

14. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 9 or claim 10.

Images