CN111124906A

CN111124906A - Tracking method, compiling method and device based on dynamic embedded points and electronic equipment

Info

Publication number: CN111124906A
Application number: CN201911302448.8A
Authority: CN
Inventors: 董扬; 王京
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Ant Fortune Shanghai Financial Information Service Co Ltd
Priority date: 2019-12-17
Filing date: 2019-12-17
Publication date: 2020-05-08
Anticipated expiration: 2039-12-17
Also published as: CN111124906B

Abstract

The embodiment of the specification discloses a tracking method, a compiling method, a device and electronic equipment based on dynamic embedded points, wherein the tracking method comprises the following steps: acquiring service-related buried point configuration and service-unrelated buried point configuration of a target application; based on the service-related embedded point configuration and the service-unrelated embedded point configuration of the target application, implanting a tracking code into an original source code of the target application to form a source code after the tracking code is injected and compiling to obtain an application program of the target application; collecting a buried point log generated by the buried point when the target application runs; based on a click sequence of a user at a mobile terminal, a page jump link, a program flow call link and call stack information, carrying out segmentation and aggregation on the buried point log to generate a Trace record set; and performing Trace analysis display based on the Trace record set.

Description

Tracking method, compiling method and device based on dynamic embedded points and electronic equipment

Technical Field

The present invention relates to the field of computer software technologies, and in particular, to a tracking method, a compiling method, an apparatus, and an electronic device based on dynamic point burying.

Background

When the problem of the mobile terminal app is tracked and positioned, a developing student is not familiar with all relying party service logics and codes, problem troubleshooting needs to involve and consume a lot of manpower, and communication cost is high. In addition, the troubleshooting is difficult due to the dotting missing and the incomplete coverage of the main link, the troubleshooting difficulty is increased due to the excessive log output and mutual interference, and the log troubleshooting efficiency is low.

How to optimize the tracking method of the mobile terminal app problem becomes a technical problem to be solved urgently.

Disclosure of Invention

An embodiment of the present specification aims to provide a tracking method, a compiling method, a device and an electronic device based on dynamic point burying, so as to locate a failure point and realize rapid problem location and troubleshooting.

In order to solve the above technical problem, the embodiments of the present specification are implemented as follows:

in a first aspect, a tracking method based on dynamic embedded points is provided, and the method includes:

acquiring service-related buried point configuration and service-unrelated buried point configuration of a target application;

based on service-related embedded point configuration and service-unrelated embedded point configuration of a target application, implanting a tracking code into an original source code of the target application to form a source code after the tracking code is injected and compiling to obtain an application program of the target application, wherein the tracking code comprises embedded points corresponding to the service-related embedded point configuration and embedded points corresponding to the service-unrelated embedded point configuration;

collecting a buried point log generated by the buried point when the target application runs;

based on the combination of multiple types of click sequence, page jump link, program flow call link and call stack information of a user at a mobile terminal, carrying out segmentation and aggregation on the buried point log to generate a tracking Trace record set;

and performing Trace analysis display based on the Trace record set.

In a second aspect, a tracking apparatus based on dynamic embedded points is provided, the apparatus including:

the acquisition module is used for acquiring service-related embedded point configuration and service-unrelated embedded point configuration of the target application;

a code implantation module, configured to implant a tracking code into an original source code of a target application based on a service-related embedded point configuration and a service-unrelated embedded point configuration of the target application to form a source code into which the tracking code is injected, wherein the tracking code includes an embedded point corresponding to the service-related embedded point configuration and an embedded point corresponding to the service-unrelated embedded point configuration;

the compiling module is used for compiling and generating an application program of the target application based on the source code after the tracking code is injected;

the buried point log acquisition module is used for acquiring buried point logs generated by buried points when the target application runs;

the embedded point log aggregation processing module is used for segmenting and aggregating the embedded point log to generate a Trace record set based on a click sequence of a user at a mobile terminal, a page jump link, a program flow call link and call stack information;

and the analysis module is used for carrying out Trace analysis display based on the Trace record set.

In a third aspect, an electronic device is provided, which includes:

a processor; and

a memory arranged to store computer executable instructions that, when executed, cause the processor to:

based on a click sequence of a user at a mobile terminal, a page jump link, a program flow call link and call stack information, carrying out segmentation and aggregation on the buried point log to generate a Trace record set;

and performing Trace analysis display based on the Trace record set.

In a fourth aspect, a computer-readable storage medium is presented, the computer-readable storage medium storing one or more programs that, when executed by an electronic device that includes a plurality of application programs, cause the electronic device to:

and performing Trace analysis display based on the Trace record set.

In a fifth aspect, a compiling method based on dynamic embedding is provided, where the method includes:

based on service-related buried point configuration and service-unrelated buried point configuration of a target application, implanting a tracking code into an original source code of the target application, wherein the tracking code comprises a buried point corresponding to the service-related buried point configuration and a buried point corresponding to the service-unrelated buried point configuration;

and compiling the source code after the tracking code is injected to obtain the application program of the target application.

In a sixth aspect, a compiling apparatus based on dynamic embedding is provided, the apparatus including:

In a seventh aspect, an electronic device is provided, which includes:

a processor; and

In an eighth aspect, a computer-readable storage medium is presented, the computer-readable storage medium storing one or more programs that, when executed by an electronic device that includes a plurality of application programs, cause the electronic device to:

As can be seen from the technical solutions provided in the embodiments of the present specification, the embodiments of the present specification have at least one of the following technical effects:

on one hand, in the embodiment of the specification, dynamic point burying is performed on a target application through service-related point burying configuration and service-unrelated point burying configuration based on the target application, then the point burying logs after the dynamic point burying are collected during the operation of the target application, the point burying logs are segmented and aggregated according to a click sequence of a user at a mobile terminal, a page jump link, a program flow call link and call stack information, and Trace analysis and display are performed based on a Trace record set after the segmentation and aggregation, so that call link information can be visually displayed on a service, links at front and rear ends are opened, a failure point can be easily located, and rapid problem location and fault troubleshooting are realized.

On the other hand, in the embodiments of the present description, dynamic point burying is performed on a target application based on service-related point burying configuration and service-unrelated point burying configuration of the target application to generate a target application program capable of performing dynamic point burying, so that point burying loss caused by artificial point burying can be reduced, and a sufficient point burying log is provided for positioning a failure point, implementing problem positioning, and troubleshooting.

Drawings

In order to more clearly illustrate the embodiments of the present specification or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, it is obvious that the drawings in the following description are only some embodiments described in the present specification, and for those skilled in the art, other drawings can be obtained according to the drawings without any creative effort.

FIG. 1 shows a schematic diagram of a tracking system of an embodiment of the present description.

Fig. 2 is a flowchart of a tracking method based on dynamic embedding points according to an embodiment of the present disclosure.

FIG. 3 is a diagram of the operational flow and corresponding Trace tree for a financial investment application.

Fig. 4 is a flowchart of compiling an application based on dynamic embedding according to an embodiment of the present disclosure.

Fig. 5 is a schematic structural diagram of an electronic device according to an embodiment of the present specification.

Fig. 6 is a schematic structural diagram of an electronic device according to an embodiment of the present specification.

Fig. 7 is a schematic structural diagram of a tracking device based on dynamic burial points according to an embodiment of the present disclosure.

Fig. 8 is a schematic structural diagram of a compiling apparatus based on dynamic embedding according to an embodiment of the present specification.

Detailed Description

The embodiment of the specification provides a tracking method, a compiling method and a device based on dynamic embedded points.

In order to make those skilled in the art better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all of the embodiments. All other embodiments obtained by a person skilled in the art without making any inventive step based on the embodiments in this description shall fall within the scope of protection of this document.

FIG. 1 shows a schematic diagram of a tracking system of an embodiment of the present description. As shown in fig. 1, the tracking system of the embodiment of the present disclosure may include several subsystems, such as tracking implantation, data acquisition, data processing and storage, and data presentation analysis, according to the implementation process.

The tracking implantation subsystem is responsible for implanting tracking codes into a source program of the target application for embedding points, and the implanted tracking codes can comprise embedded point tracking codes related to business and embedded point tracking codes related to grammar of a development language; the data acquisition subsystem is responsible for acquiring buried point log data generated in the running process of the target application; the data processing and storing subsystem is responsible for aggregating, sorting and storing the generated embedded point log data for subsequent data analysis and display; and the data display analysis subsystem is responsible for analyzing, inquiring and displaying the aggregated and sorted log data.

The method of the embodiments of the present description will be further described with reference to the schematic diagram of the tracking system shown in fig. 1.

Fig. 2 is a flowchart of a tracking method based on dynamic embedding points according to an embodiment of the present disclosure. As shown in fig. 2, the method may include:

s210, acquiring service-related and service-unrelated embedded point configurations of the target application.

It should be understood that in order to enable a programmer to track information at a certain point in the code through a hook tool or the like when the application runs, log is required to be marked at the position of the code point so as to string the calling links, thereby facilitating the view of the calling context of the links to realize the monitoring of the key links of the code. The log of the location of the code point is called the buried point (or dye point).

It should be understood that existing service sites are typically set by developers according to product development requirements. As developers are unfamiliar with all the service logics and codes of the relying party, dotting loss and incomplete coverage of a main link are easily caused; in addition, as the functionality of application products expands, developers may miss service independent site configurations in certain functions, methods, or classes.

In order to avoid the similar situation, in the embodiment of the present specification, the service-related buried point configuration and the service-unrelated buried point configuration may be predetermined as needed and stored in the configuration database, the configuration table or the configuration file of the database, and the like. In executing the method of the embodiments of the present specification, the service-related and service-unrelated embedded point configurations may be obtained from a configuration database, a configuration table or a configuration file of the database, or the like.

It should be appreciated that the business independent burial point configuration is used to represent burial point requirements associated with the development language grammar of the target application and/or burial point requirements associated with the development framework of the target application. The service-independent embedded point configuration can comprise grammar-related embedded point configuration and framework-related embedded point configuration, and belongs to the common embedded point configuration of all services.

The grammar-related buried point configuration, namely the buried point configuration related to the grammar of the development language of the target application, can comprise at least one of the following buried point configurations:

(ii) a buried point for capturing exception statements;

a buried point for a loop statement;

the embedded point of the parameter of the function in the calling period;

a buried point for the return value of the function during the call period;

the buried point of the conditional statement.

For example, when an exception occurs, it indicates that there is a serious error in the code, which is a critical point of the failed code. When a developer is checking a problem, the information of the try catch exception is very important, and the try catch statement belongs to a code point needing hook during operation. And (4) capturing the buried points of the abnormal sentences, namely obviously, the buried points are configured without service, and are not related to the service.

The framework-related buried point configuration, i.e. the buried point configuration related to the development framework of the target application, may include at least one of the following buried point configurations:

a buried point of a calling interface in a development framework for a target application;

a buried point for a critical node in a development framework for a target application.

For example, part or all of the network requests in the framework are called through a certain calling interface, and at this time, a buried point of response to the part or all of the network requests can be configured for the calling interface, which also belongs to the service-independent buried point configuration.

Of course, there may be other buried point configurations associated with the development framework of the target application, and the embodiments of the present specification are not limited in this regard.

It will of course be appreciated that in addition to these common, syntax-related and framework-related, buried point configurations, there is some service-related, buried point configuration information that is relevant to a particular service. It should be understood that the service-related buried point configuration is used to represent service-related personalized buried point requirements in the target application.

The service-related embedded point configuration comprises at least one of the following embedded point configurations:

a buried point for tracking a specified private field value of a specified class;

a buried point for tracking parameters of the first specified network request during the invocation;

a buried point for tracking a return value of a second specified network request during invocation, wherein the return value of the specified network request cannot be tracked at a development framework level of a target application;

buried point of asynchronous calls.

For example, some private field values of classes need to be obtained, so a getter method for dynamically inserting the field is needed; for another example, some callbacks, such as processing of network request response, are implemented in the service layer itself, and cannot be uniformly tracked in the framework layer, and a buried point needs to be configured in the service layer.

S220, based on the service-related buried point configuration and the service-unrelated buried point configuration of the target application, a tracking code is implanted into the original source code of the target application to form a source code after the tracking code is injected, and the source code is compiled to obtain an application program of the target application.

And the tracking code comprises a buried point corresponding to the service-related buried point configuration and a buried point corresponding to the service-unrelated buried point configuration.

In this embodiment of the present description, a tracking code may be implanted in an original source code of a target application based on a service-related buried point configuration and a service-unrelated buried point configuration of the target application. One specific implementation of the embodiments of the present description to implant trace code may be found in the trace implant subsystem shown in FIG. 1. As shown in FIG. 1, the tracking implant core of the tracking implant subsystem may mainly include two parts, a utils implant module and a general implant module.

The general implantation module is used for implanting embedded point requirements related to grammar of a target application development language, such as embedded points related to capture abnormal sentences, embedded points related to loop sentences, embedded points related to condition judgment sentences and embedded points related to parameters of functions in a calling period; a buried point for the return value of the function during the call period; and so on. It should be understood that the syntax-dependent buried point requirements herein are generally business-independent.

In addition, the utils implantation module, which is used for implanting the buried point requirement related to the target application service, may include various kinds of Trace requirement configurations, such as Trace for tracking a specified private field value of a specified class, Trace for tracking a parameter of a specified function during a call, Trace for tracking a return value of the specified function during the call, Trace for asynchronous call, and the like.

In the embodiment of the present specification, the utils implantation module and the generic implantation module may be implemented by javasissst lib, Aspectj lib, and the like. In the embodiment of the present specification, the utils implantation module and the general implantation module are used to read the service-related embedded point configuration and the service-unrelated embedded point configuration, so as to rewrite the program code of the target application, and then compile the program code to form a brand new compiled file. For example, java is used, and the utils implantation module and the general implantation module need to read the service-related embedded point configuration and the service-unrelated embedded point configuration, so as to rewrite the original code of the target application, and compile to generate a new class file.

Specifically, step S220 may include:

invoking an utils module to implant an original source code of the target application into a corresponding buried point tracking code configured on the service-related buried point; and

and calling a general implantation module to implant the service-independent embedded point configuration corresponding embedded point tracking code into the original source code of the target application.

Taking the service-related embedded point configuration as an example, assuming that private field values of some classes need to be obtained, a getter method for dynamically inserting the fields into the files module can be called at the moment; and (4) configuring by using a service-independent embedded point, and calling the catch clips of the universal implantation module injection method at the moment if the try catch exception needs to be intercepted.

It should be understood that these buried trace codes may be implanted in a non-invasive hook fashion.

Furthermore, it should be understood that the utils module and the generic implant module may be implemented in the form of gradle plugin. As shown in the trace implant subsystem of FIG. 1, this may be accomplished by a trace implant manager calling an associated plug-in, such as an RPC implant plug-in, a container implant plug-in, a thread pool implant plug-in, and so forth.

Further, in order to avoid that the set embedded point tracking code has a great influence on the target application in actual operation, in the embodiment of the present specification, the data acquisition thread of the embedded point tracking code is set to have the lowest priority of the thread.

Of course, it should be understood that step S220 may be implemented in other ways, and this is not limited by the embodiment of this specification.

And S230, collecting a buried point log generated by the buried point when the target application runs.

In the embodiment of the specification, the buried point log of the target application can be collected during the running of the target application through various Trace tool sets. For example, the buried point data generated when the target application runs can be acquired and obtained through a Trace tool set such as a Trace API, a Trace annotation, a dotting tool and the like. It should be understood that the raw buried data may include Annotation data, Span data, Event data, Trace data, and the like.

As can be seen from fig. 1, through the Trace toolset, a system Trace data model of the target application may be obtained, including Annotation, Span, Trace, and so on.

It should be understood that in a Trace, three main elements are typically involved, namely Span, Trace tree and callout. Of course, it should be understood that one Trace should also have its unique identification and start and end times. In embodiments of the present specification, the Trace data structure may include fields such as traceId, startTime, endTime, Map < String, LinkedList < scanrecord >, etc. The traceId is a unique identifier of Trace, startTime represents the start time of Trace, endTime represents the end time of Trace, and a Map object is used for representing a Trace tree, wherein String represents a key value of the Map object, and LinkedList represents a value of the Map object, which is a Span list record in the embodiment of the description.

Of course, it should be understood that the above field names of the Trace data structure are only used for example, and in practical applications, other field names may be used or some of the fields in the field names may be added or deleted.

In this specification embodiment, the Span data structure may include: type, spanId, spanName, startTime, endTime, thredId/thredName, LingkedList < Annotation >, failureInfo, extensions, etc.

type represents Span type, and in the embodiment of the present specification, for example, rpc for application-level transparency (application-level transparency), openpageunique for application-level transparency (application-level transparency), message msg, call link, and the like may be included. The link comprises a calling link of the same thread and a calling link which spans the thread and has asynchronous callback.

And the Span Id is used for representing the identification of the Span, and is unique in one link.

The Span name is a globally unique identifier for representing the Span.

startTime denotes the start time of Span, endTime denotes the end time of Span.

the headId is the thread ID and the headname is the thread name, both of which are used to represent the thread.

LingkedList is an Annotation list used to record Annotation in Span.

The failureInfo is used to record error information of Span, and if there is no error, it is null.

extensions is the extension information of Span for putting in the related information of the server, such as the server TraceId.

Similarly, the above field names of the Span data structure are only used for example, and in practical applications, other field names may be used or some of the fields in the field names may be added or deleted.

It should be understood that annotation is a new property of java5, and that Annotations provide some data that would not otherwise belong to a program, such as: the author of a piece of code either tells the compiler to disable some special errors. Anannotation has little effect on the execution of the code. The indications apply to the code using the form @ indication: class (class), attribute (attribute), method (method), and the like.

Optionally, in this embodiment of the present specification, the data structure of the annotation data may include: function name, bundle, thread, parameter, and return value. In addition, the data structure of the annotation data may further include extension information, execution time, time ratio, and the like.

Further, in the embodiments of the present specification, the data structure of Event data may include: event type, event identification, function, bundle, event detailed information and the like. Among them, event types, such as exceptinonevent, ANREvent, flash back event, system background switching event, etc. An exceptinonevent is an abnormal event captured when an application is abnormal.

It should be understood that the Annotation data may constitute Span data, which may also decompose the Annotation data, as shown by the system trace data model transformation in fig. 1; similarly, Span data may constitute Trace data, which may also be decomposed. That is, the Annotation data and Span data can be converted into each other, and Span data and Trace data can be converted into each other. In this embodiment of the present specification, the data acquisition function of the buried point data may be implemented by using one data acquisition module, and specifically may be executed by calling a library file such as Dtrace Lib. Of course, in order to avoid generating too much buried point data, the data sampling module can be used for sampling the buried point data generated by the same buried point.

In order to understand the data relationship among Trace, Span, and Annotation, a specific application operation flowchart and a corresponding Trace tree are combined for example. FIG. 3 is a diagram of the operational flow and corresponding Trace tree for a financial investment application. The operational flow of FIG. 3 may include:

at 310, the launch application icon is clicked.

And 320, opening a home page of the application.

330, click on the fund Tab of the home page.

340, opening a fund market page.

350, clicking the fund self-selection button of the page.

As shown in FIG. 3, during this tracking operation, two click events, Event1 and Event2, are generated; in addition, after the application icon is clicked and started, the main thread sequentially generates three times of rpc calls, and the calls correspond to a span1, a span2 and a span3 respectively; in addition, the main thread creates a thread A and a thread B, the rpc call generated by the thread A corresponds to the span4 and the span5, and the rpc call generated by the thread B corresponds to the span 6; the Annotation list corresponding to the span5 sequentially comprises Annotation1, Annotation2 and Annotation 3. These integers form a Trace tree. Of course, it should be understood that system information, such as resource class system information (disk, memory, thread count, CPU, power, etc.), may also be included in the Trace tree. The specific structure of the Trace tree can be referred to as shown in fig. 3, and those skilled in the art can easily understand the relationship among Trace, span, and Annotation based on the content of fig. 3, and will not be described again.

It will of course be understood that for a Trace, it is of paramount importance how the beginning and end of the Trace are determined. In embodiments of the present description, the start and end of Trace can be determined in a variety of ways.

Optionally, in this embodiment of the present specification, the definition of Trace may be hooked up with a change of one user behavior of the target application, and one Trace corresponds to one valid user behavior. Herein, the valid user behavior refers to a user behavior that triggers the target application to perform a certain function.

It should be appreciated that the initiation of Trace may be an effective user action input. Such as a clicking operation, a gesture operation, a voice command input, and so forth. Taking the user behavior click as an example, for example, clicking a target application icon of the desktop → entering a page of the target application → sliding the page (e.g., sliding the page through a touch screen movement operation) → clicking a certain Button (Button) of the page, thereby triggering the start of Trace.

At this time, step S230 may include:

and determining the start of the acquired target Trace by effective target user behavior input when the target application runs.

Of course, it should be understood that there may be a variety of ways to terminate the Trace.

Optionally, the last Trace is ended by the next valid user action input. Also taking the user behavior click as an example, the next click start means the last trace end.

Or, optionally, determining whether to finish the Trace according to the maximum stay time of the set user on the Trace. For example, the maximum stay time of the user on a Trace is set to be 1min, and if the stay time of the user on one Trace exceeds 1min, the Trace is automatically ended. Of course, it should be understood that a uniform maximum dwell time may be set for all Trace of the target application, or different maximum dwell times may be set for different Trace of the target application, for example, a corresponding maximum dwell time is set for the Trace in each page separately, and so on.

At this time, step S230 may further include: determining the end of the target Trace through a next valid user behavior input of the target user behavior input.

Alternatively, step S230 may further include:

and determining the end of the target Trace when the staying time of the target Trace is longer than the preset staying time corresponding to the target Trace.

It should be understood that by hooking the effective user behavior of the Trace, it can be guaranteed that no other Trace exists in the time period occupied by one Trace. In addition, effective user behaviors are hooked by the Trace, the granularity of the Trace is ensured to be proper, and the problem codes are difficult to locate due to the fact that the fault location code area range is large because the granularity of the Trace is divided too coarsely; and too much Trace generated due to the fact that the granularity of the Trace is divided into too fine particles is avoided, and the running efficiency of the target application is reduced. In addition, by hooking effective user behaviors through Trace, seamless natural combination of a user link and a function call link can be realized

Of course, it should be understood that other implementations exist besides the definition of Trace and the hooking of changes in user behavior. Optionally, the definition of Trace can also follow service hooks and service routes. When the target application starts a new service, a new Trace is started at the same time.

At this time, step S230 may include:

and determining the start of the acquired target Trace through the calling of the target service when the target application runs.

It will of course be appreciated that when the target application jumps from one service to another, the start of the next Trace is decided, while the end of the last Trace is decided. Similarly, in this way, whether to end the Trace can also be determined according to the maximum stay time of the set user on the Trace. For specific setting, reference is made to the related contents, which are not described in detail.

At this time, step S230 may further include:

and determining the end of the target Trace through the calling of the next service of the target service.

Alternatively, step S230 may further include:

S240, based on the combination of the click sequence of the user at the mobile terminal, the page jump link, the program flow call link and the call stack information, the embedded point log is segmented and aggregated to generate a Trace record set.

After generating the buried point data, the generated buried point data needs to be summarized and subjected to segmentation and aggregation processing, so that a Trace table is obtained.

In a specific embodiment, as shown in the data collection pipeline in the data processing and storing stage of fig. 1, the data of the buried point collected in the data collection stage is written into a log file through a log module, then written into the data pipeline to converge the data of the buried point, and then the converged data of the buried point is subjected to log segmentation and aggregation according to a preset rule to generate a Trace table. Specifically, for example, the buried point Data may be processed by GB/TB/PB-level Data warehouse solution such as ODPS (Open Data Processing Service).

Of course, it should be understood that, when the aggregated buried point data is subjected to log segmentation and aggregation according to a preset rule to generate a Trace table, the Trace table to be generated is generally determined according to a combination of multiple types of click sequences, page jump links, program flow call links and call stack information of a user at a mobile terminal. Rules for the segmentation aggregation may be determined in conjunction with specific analysis exposure requirements.

Of course, generally, the user dimension and the time dimension exist in the Trace table generated finally, so as to query according to the user dimension (user identification) and/or the time dimension.

And S250, performing Trace analysis display based on the Trace record set.

It should be understood that in the embodiments of the present description, various forms of Trace analysis presentation can be performed through the set of Trace records.

Optionally, the Trace records in the Trace record set can carry an access user identifier and/or a timestamp; wherein step S250 may be implemented as:

obtaining a Trace record from the Trace record set according to an access user identifier and/or a query time period;

and performing data analysis on the calling link of the target application based on the acquired Trace record.

It should be appreciated that in performing fault analysis, the query time period and the access user identification are two important parameters in determining the fault. By accessing the user identification, the tracking data of which user needs to be queried can be determined; by querying the time period, it can be determined which time period of Trace records need to be queried. Therefore, the range of Trace records to be analyzed can be narrowed, and the fault positioning efficiency is improved.

Of course, it should be understood that the Trace analysis of the embodiments of the present application is not limited to locating when a fault occurs, and other applications may exist. For example, it may also be used for system optimization, code coverage analysis, and the like.

Further, it should be appreciated that the data analysis of the call link of the target application may employ a variety of different analysis approaches, depending on the needs of the user. For example, Trace waterfall plot show analysis; performing Trace thermal analysis; bundle calls link analysis; trace time consuming analysis, and so on. According to the needs of users, the users can select one display or select a plurality of analysis modes to carry out combined display.

For example, to check which codes have a higher calling frequency, Trace thermal analysis can be performed to determine high-frequency calling codes; for another example, to optimize the applied codes, Trace time consumption analysis can be performed to determine the codes which consume more time, so as to inform developers of which codes to start with for optimization; for another example, a call link condition of the code is analyzed, Bundle call link analysis may be performed, and the like.

It should be understood that, in the embodiments of the present specification, dynamic point burying is performed on a target application through service-related point burying configuration and service-unrelated point burying configuration based on the target application, then, a point burying log after the dynamic point burying is collected during the running of the target application, and the point burying log is segmented and aggregated according to a click sequence of a user at a mobile terminal, a page jump link, a program flow call link and call stack information, and Trace analysis and presentation are performed based on a Trace record set after the segmentation and aggregation, so that call link information can be visually presented on a service, links at front and rear ends are opened, a failure point is easily located, and rapid problem location and fault troubleshooting are realized.

Fig. 4 is a flowchart of compiling an application based on dynamic embedding according to an embodiment of the present disclosure. As shown in fig. 4, the method may include:

s410, acquiring service-related buried point configuration and service-unrelated buried point configuration of the target application.

And S420, implanting a tracking code into the original source code of the target application based on the service-related buried point configuration and the service-unrelated buried point configuration of the target application to form the source code after the tracking code is injected.

And S430, compiling the source code after the tracking code is injected to obtain the application program of the target application.

Step S210 may be referred to for specific implementation of step S410, and step S220 may be referred to for specific implementation of steps S420 and S430, which are not described again.

It should be understood that, in the embodiments of the present specification, application nodes are divided into service-related node configuration and service-unrelated node configuration, so that the node configuration types can be configured separately, the problem of missing dotting caused by unfamiliarity with service logic by developers is solved to a certain extent, and node configuration efficiency is also improved.

In addition, by configuring the buried points, the problem of the journal output flooding can be avoided to a certain extent, and even if the problem of the journal output flooding occurs, the journal output flooding can be corrected quickly by modifying the configuration.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

Fig. 5 is a schematic structural diagram of an electronic device according to an embodiment of the present specification. Referring to fig. 5, at a hardware level, the electronic device includes a processor, and optionally further includes an internal bus, a network interface, and a memory. The Memory may include a Memory, such as a Random-Access Memory (RAM), and may further include a non-volatile Memory, such as at least 1 disk Memory. Of course, the electronic device may also include hardware required for other services.

The processor, the network interface, and the memory may be connected to each other via an internal bus, which may be an ISA (Industry Standard Architecture) bus, a PCI (peripheral component Interconnect) bus, an EISA (Extended Industry Standard Architecture) bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one double-headed arrow is shown in FIG. 5, but this does not indicate only one bus or one type of bus.

And the memory is used for storing programs. In particular, the program may include program code comprising computer operating instructions. The memory may include both memory and non-volatile storage and provides instructions and data to the processor.

The processor reads a corresponding computer program from the nonvolatile memory into the memory and then runs the computer program to form the tracking device based on the dynamic buried point on the logic level. The processor is used for executing the program stored in the memory and is specifically used for executing the following operations:

and performing Trace analysis display based on the Trace record set.

The method executed by the tracking device based on the dynamic buried point as disclosed in the embodiment of fig. 2 in this specification can be applied to or implemented by a processor. The processor may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware in a processor or instructions in the form of software. The Processor may be a general-purpose Processor, including a Central Processing Unit (CPU), a Network Processor (NP), and the like; but also Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components. The various methods, steps and logic blocks disclosed in the embodiments of the present specification may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with the embodiments of the present specification may be embodied directly in a hardware decoding processor, or in a combination of hardware and software modules in the decoding processor. The software module may be located in ram, flash memory, rom, prom, or eprom, registers, etc. storage media as is well known in the art. The storage medium is located in a memory, and a processor reads information in the memory and completes the steps of the method in combination with hardware of the processor.

The electronic device may also execute the method of fig. 2, and implement the functions of the tracking apparatus based on dynamic point burying in the embodiment shown in fig. 2, which are not described herein again in this specification.

This specification embodiment also proposes a computer-readable storage medium storing one or more programs, the one or more programs comprising instructions, which when executed by a portable electronic device comprising a plurality of application programs, are capable of causing the portable electronic device to perform the method of the embodiment shown in fig. 2, and in particular to perform the following operations:

and performing Trace analysis display based on the Trace record set.

Fig. 6 is a schematic structural diagram of an electronic device according to an embodiment of the present specification. Referring to fig. 6, at a hardware level, the electronic device includes a processor, and optionally further includes an internal bus, a network interface, and a memory. The Memory may include a Memory, such as a Random-Access Memory (RAM), and may further include a non-volatile Memory, such as at least 1 disk Memory. Of course, the electronic device may also include hardware required for other services.

The processor, the network interface, and the memory may be connected to each other via an internal bus, which may be an ISA (Industry Standard Architecture) bus, a PCI (peripheral component Interconnect) bus, an EISA (Extended Industry Standard Architecture) bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one double-headed arrow is shown in FIG. 6, but that does not indicate only one bus or one type of bus.

The processor reads the corresponding computer program from the nonvolatile memory into the memory and then runs the computer program, and a compiling device based on the dynamic buried point is formed on the logic level. The processor is used for executing the program stored in the memory and is specifically used for executing the following operations:

The method executed by the compiling apparatus based on dynamic embedding point as disclosed in the embodiment of fig. 4 in this specification can be applied to or implemented by a processor. The processor may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware in a processor or instructions in the form of software. The Processor may be a general-purpose Processor, including a Central Processing Unit (CPU), a Network Processor (NP), and the like; but also Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components. The various methods, steps and logic blocks disclosed in the embodiments of the present specification may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with the embodiments of the present specification may be embodied directly in a hardware decoding processor, or in a combination of hardware and software modules in the decoding processor. The software module may be located in ram, flash memory, rom, prom, or eprom, registers, etc. storage media as is well known in the art. The storage medium is located in a memory, and a processor reads information in the memory and completes the steps of the method in combination with hardware of the processor.

The electronic device may further execute the method of fig. 4, and implement the functions of the compiling apparatus based on the dynamic embedding point in the embodiment shown in fig. 4, which are not described herein again in this specification.

Of course, besides the software implementation, the electronic device in this specification does not exclude other implementations, such as logic devices or a combination of software and hardware, and the like, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.

Fig. 7 is a schematic structural diagram of a tracking device based on dynamic burial points according to an embodiment of the present disclosure. Referring to fig. 7, in a software implementation, the tracking device based on dynamic burial point may include:

an obtaining module 710, configured to obtain a service-related buried point configuration and a service-unrelated buried point configuration of a target application;

a code implanting module 720, configured to implant a tracking code into an original source code of a target application based on a service-related embedded point configuration and a service-unrelated embedded point configuration of the target application to form a source code into which the tracking code is injected, where the tracking code includes an embedded point corresponding to the service-related embedded point configuration and an embedded point corresponding to the service-unrelated embedded point configuration;

a compiling module 730 for compiling and generating an application program of the target application based on the source code after the trace code is injected;

a buried point log collection module 740, configured to collect a buried point log generated by the buried point when the target application runs;

the embedded point log aggregation processing module 750 is used for performing segmentation and aggregation on the embedded point log to generate a tracking Trace record set based on a plurality of combinations of a click sequence, a page jump link, a program flow call link and call stack information of a user at a mobile terminal;

and the analysis module 760 is used for performing Trace analysis display based on the Trace record set.

The tracking device based on dynamic point burying in this specification can also execute the method in fig. 2, and implement the functions of the tracking device based on dynamic point burying in the embodiment shown in fig. 2, and the embodiments in this specification are not described herein again.

Fig. 8 is a schematic structural diagram of a compiling apparatus based on dynamic embedding according to an embodiment of the present specification. Referring to fig. 8, in a software implementation, the dynamic burial point based compiling apparatus may include:

an obtaining module 810, configured to obtain a service-related buried point configuration and a service-unrelated buried point configuration of a target application;

a code implanting module 820, configured to implant a tracking code into an original source code of a target application based on a service-related embedded point configuration and a service-unrelated embedded point configuration of the target application to form a source code into which the tracking code is injected, where the tracking code includes an embedded point corresponding to the service-related embedded point configuration and an embedded point corresponding to the service-unrelated embedded point configuration;

and a compiling module 830 for compiling and generating the application program of the target application based on the source code after the trace code is injected.

The compiling apparatus based on dynamic embedding point in this specification can also execute the method of fig. 4, and implement the functions of the compiling apparatus based on dynamic embedding point in the embodiment shown in fig. 4, and the embodiments of this specification are not described herein again.

In short, the above description is only a preferred embodiment of the present disclosure, and is not intended to limit the scope of protection of this document. Any modification, equivalent replacement, improvement and the like made within the spirit and principle of the present specification shall be included in the protection scope of this document.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.

Claims

1. A tracking method based on dynamic embedded points comprises the following steps:

and performing Trace analysis display based on the Trace record set.

2. The method of claim 1, wherein based on the service-dependent and service-independent burdening configurations of the target application, implanting a trace code into an original source code of the target application to form a source code into which the trace code is injected and compiling an application program of the target application, comprises:

3. The method of claim 2, wherein the first and second light sources are selected from the group consisting of a red light source, a green light source, and a blue light source,

the buried trace code is implanted in a non-invasive hook manner.

4. The method of claim 2, wherein the first and second light sources are selected from the group consisting of a red light source, a green light source, and a blue light source,

the utils module and the generic implant module are implemented in the form of a gradle plug.

5. The method of claim 2, wherein the first and second light sources are selected from the group consisting of a red light source, a green light source, and a blue light source,

and the data acquisition thread of the buried point tracking code is set as the lowest priority of the thread.

6. The method of claim 1, comprising:

7. The method of claim 6, wherein the first and second light sources are selected from the group consisting of a red light source, a green light source, and a blue light source,

collecting a buried point log generated by the buried point when the target application runs, further comprising:

determining the end of the target Trace through the next valid user behavior input of the target user behavior input; or

8. The method of claim 1, wherein the first and second light sources are selected from the group consisting of a red light source, a green light source, and a blue light source,

collecting a buried point log generated by the buried point when the target application runs, wherein the buried point log comprises:

9. The method of claim 8, wherein the first and second light sources are selected from the group consisting of,

determining the end of the target Trace through the calling of the next service of the target service; or

10. The method of claim 1, wherein the first and second light sources are selected from the group consisting of a red light source, a green light source, and a blue light source,

the Trace records in the Trace record set carry access user identifiers and timestamps, and the Trace analysis and presentation based on the Trace record set comprises the following steps:

11. The method of claim 10, the data analysis of the call link of the target application comprising at least one of:

performing Trace waterfall layout display analysis;

performing Trace thermal analysis;

bundle calls link analysis;

trace time consuming analysis.

12. A compiling method based on dynamic embedding points comprises the following steps:

13. A dynamic burrow-based tracking device, comprising:

the embedded point log aggregation processing module is used for segmenting and aggregating the embedded point log to generate a tracking Trace record set based on a plurality of combinations of a click sequence of a user at a mobile terminal, a page jump link, a program flow call link and call stack information;

14. A dynamic embedding based compiling apparatus, comprising:

and the compiling module is used for compiling and generating the application program of the target application based on the source code after the tracking code is injected.

15. An electronic device, comprising:

a processor; and

and performing Trace analysis display based on the Trace record set.

16. An electronic device, comprising:

a processor; and

17. A computer-readable storage medium storing one or more programs that, when executed by an electronic device including a plurality of application programs, cause the electronic device to:

and performing Trace analysis display based on the Trace record set.

18. A computer-readable storage medium storing one or more programs that, when executed by an electronic device including a plurality of application programs, cause the electronic device to: