Point burying log reporting method and computer program product

Abstract

The embodiment of the invention discloses a point burying log reporting method and a computer program product, and belongs to the technical field of networks. The method comprises the following steps: intercepting a buried point node in a service link through a section, the service link being a link for processing a service request, and the buried point node being a service node having a buried point statistics demand in the service link; summarizing the intercepted burying point data of the burying point nodes; and reporting a burying point log based on the burying point data obtained by data summarization under the condition that the service request processing is completed. By adopting the scheme provided by the embodiment of the invention, the event tracking logs can be prevented from being reported for multiple times.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of network technology, and in particular to a method for reporting tracking logs and a computer program product. Background Art

[0002] When a business system processes complex business requests, it often requires multiple business nodes on the business chain to cooperate with each other.

[0003] In order to monitor the task execution status of each business node, in related technologies, after each business node completes its own task, it will report the task execution results in the form of tracking logs, that is, there are multiple tracking log reports during the business request processing process. Summary of the Invention

[0004] The present application provides a method and computer program product for reporting tracking logs. The technical solution is as follows:

[0005] In one aspect, an embodiment of the present application provides a method for reporting tracking logs, the method comprising:

[0006] Intercept tracking nodes in a service link through a slice. The service link is a link that processes service requests, and the tracking nodes are service nodes in the service link that have tracking statistics requirements.

[0007] Summarizing the intercepted tracking data of the tracking nodes;

[0008] When the business request processing is completed, the tracking data obtained based on the data aggregation is reported to the tracking log.

[0009] On the other hand, an embodiment of the present application provides a device for reporting tracking logs, the device comprising:

[0010] A slice interception module is used to intercept the tracking nodes in the business link through the slice, where the business link is the link that processes business requests, and the tracking nodes are business nodes in the business link that have tracking statistics requirements;

[0011] A data processing module is used to aggregate the intercepted tracking data of the tracking nodes;

[0012] The log reporting module is used to report the tracking log based on the tracking data obtained by data aggregation when the business request processing is completed.

[0013] On the other hand, an embodiment of the present application provides a server, which includes a processor and a memory, wherein the memory stores at least one computer instruction, and the at least one computer instruction is loaded and executed by the processor to implement the tracking log reporting method as described in the above aspects.

[0014] On the other hand, an embodiment of the present application provides a computer-readable storage medium, which stores at least one computer instruction, and the at least one computer instruction is used to be executed by a processor to implement the tracking log reporting method as described in the above aspects.

[0015] On the other hand, an embodiment of the present application provides a computer program product, which includes computer instructions, and the computer instructions are stored in a computer-readable storage medium; the processor reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to implement the tracking log reporting method as described in the above aspects.

[0016] In an embodiment of the present application, aspect interception technology is used to intercept business nodes (point-buffering nodes) with point-buffering statistics requirements in the business chain that processes business requests, and the point-buffering data of the intercepted business nodes are summarized, so that when the business request processing is completed, a point-buffering log is reported based on the summarized point-buffering data. In the entire business request processing process, there is no need for each business node to independently report its own point-buffering log, which helps to reduce the impact of multiple log writes on interface performance; and the use of aspect interception technology can avoid intrusion into the business logic code of the business node, reducing the difficulty of implementing point-buffering log reporting. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 is a schematic diagram of an implementation environment shown in an exemplary embodiment of the present application;

[0018] Figure 2 A flowchart of a method for reporting tracking logs provided by an exemplary embodiment of the present application is shown;

[0019] Figure 3 A flowchart of a method for reporting tracking logs provided by another exemplary embodiment of the present application is shown;

[0020] Figure 4 This is a schematic diagram of an exemplary embodiment showing a process in which different service nodes report tracking logs multiple times;

[0021] Figure 5 This is a flowchart of a process for generating buried point data, shown in an exemplary embodiment of the present application;

[0022] Figure 6This is a schematic diagram of a tracking log reporting process shown in an exemplary embodiment of the present application;

[0023] Figure 7 2 is a schematic diagram of a tracking log reporting process shown in another exemplary embodiment of the present application;

[0024] Figure 8 A structural block diagram of a tracking log reporting device provided by another exemplary embodiment of the present application is shown;

[0025] Figure 9 A structural block diagram of a server provided by an exemplary embodiment of the present application is shown. DETAILED DESCRIPTION

[0026] In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0027] In this document, "plurality" refers to two or more. "And / or" describes a relationship between associated objects, indicating that three possible relationships exist. For example, "A and / or B" can mean: A exists alone, A and B exist simultaneously, or B exists alone. The character " / " generally indicates an "or" relationship between the associated objects.

[0028] For ease of understanding, the terms involved in the embodiments of this application are explained below:

[0029] Aspect: refers to a programming unit that modularizes cross-cutting concerns scattered across different classes, methods, or interfaces, while Aspect Interception refers to the process of dynamically intercepting calls to the target (class, method, or interface) at runtime and inserting additional logic before and after execution.

[0030] The core components of aspects include advice and pointcuts. Advice refers to additional logic executed before and after interception, and includes types such as before, after, and around advice. Pointcuts are regular expressions for interception targets, and can include method signatures, class names, annotations, and more.

[0031] Instrumentation Point: refers to inserting data collection code into a specific execution node of the system to record the runtime status, performance indicators, or business behavior of the specific node.

[0032] In related technologies, when a business system processes a business request, multiple business nodes along the business chain must sequentially execute their respective tasks. To monitor the task execution of each business node and identify problems promptly, additional tracking log reporting code is inserted into the business logic code of each business node. This tracking log reporting code collects and reports tracking logs during task execution. For example, the task execution results of the current business node are collected and reported as tracking logs.

[0033] For example, when a business request is used to request data delivery, the raw input data is fed into the business chain, where each business node in the chain filters the data according to its own filtering rules. Each business node is required to report the filtered data in the form of a tracking log.

[0034] Obviously, in this process, on the one hand, the business logic code of each business node needs to be modified, which is difficult to implement; on the other hand, each business node needs to report the tracking log, that is, multiple tracking log reports are required during the processing of a single business request, and frequent log writing will affect the interface performance.

[0035] In the method for reporting tracking logs provided in the embodiment of the present application, aspect interception technology is used to intercept business nodes with tracking statistics requirements in the business chain that processes business requests, and the tracking data of the intercepted business nodes are summarized. Moreover, only one tracking log report is required based on the summarized tracking data when the business request processing is completed. There is no need for each business node to independently report its own tracking log, thus avoiding the impact of multiple log writes on interface performance. In addition, when the aspect interception technology is used, there is no need to insert additional tracking log reporting code into the business logic code of the business node, thus avoiding code intrusion into the business node and reducing the difficulty of implementing tracking log reporting.

[0036] Please refer to Figure 1 , which shows a schematic diagram of an implementation environment provided by an exemplary embodiment of the present application, the implementation environment includes a terminal 110, a business server 120 and a log server 130.

[0037] Terminal 110 is an electronic device with a service requirement. This electronic device can be a smartphone, tablet computer, wearable device, personal computer, etc. The service requirement can be a service requirement of an installed application or an operating system. When a service requirement is generated, terminal 110 sends a service request to service server 120.

[0038] The business server 120 is a server for providing business services. The server can be a physical server, a server cluster consisting of several physical servers, or a cloud computing center. In some embodiments, the business server 120 is a server that provides business services for applications, or a server that provides business services for operating systems.

[0039] In some embodiments, the service server 120 runs a service system that is used to provide service services through various service nodes in the service chain. After data input into the service chain is processed by each service node, the final output data is fed back to the terminal 110 as a service response. For example, different service nodes in the service chain are used to filter data input from upstream service nodes according to different filtering rules, and provide the filtered data to downstream service nodes. Ultimately, the data filtered by each service node is fed back to the terminal 110.

[0040] In one possible design, the business server 120 supports aspect interception. This is achieved by defining an aspect for intercepting business nodes in the business chain that require tracking statistics. The aspect is then used to aggregate the tracking data of the intercepted business nodes. Finally, the aggregated tracking data obtained when the business request is processed is reported as a tracking log.

[0041] Log server 130 is a server for storing tracking logs. The server can be a physical server, a server cluster consisting of multiple physical servers, or a cloud computing center. In some embodiments, for each business request received, business server 120 generates a single tracking log corresponding to the business request and reports the single tracking log to log server 130.

[0042] In some embodiments, the log server 130 also has a log analysis function. By analyzing the tracking logs reported by the service server 120, it can be determined whether there are any abnormalities or data loopholes in the task execution of each service node in the service chain, so as to optimize the service chain or service node in a timely manner.

[0043] In some embodiments, the functions of the above-mentioned log server can also be implemented by the business server, that is, aspect interception, embedded point log reporting and log analysis are all performed by the business server.

[0044] The method for reporting tracking logs provided in the embodiment of the present application can be performed by Figure 1 The service server 120 is shown as executing the above-mentioned operations. For the convenience of description, the following embodiments are described by taking the server as the execution subject.

[0045] Please refer to Figure 2, which shows a flow chart of a method for reporting tracking logs provided by an exemplary embodiment of the present application. This embodiment uses the method for a server as an example to illustrate the method, which may include the following steps:

[0046] Step 201: intercept the tracking nodes in the business link through the slice. The business link is the link that processes business requests, and the tracking nodes are business nodes in the business link that have tracking statistics requirements.

[0047] In one possible implementation, in response to a service request, the server processes the service request through a service link. During the processing of the service request, the server intercepts the embedded nodes in the service link through the aspect.

[0048] The service request may be a request for obtaining service data from the server. For example, the service request may be a content recommendation request sent by the terminal to the server to request the acquisition of recommended content; or the service request may be a red dot status request sent by the terminal to the server to request the issuance of a red dot (for example, to prompt the user that there is new content or unread messages). The embodiments of the present application do not limit the content of the specific service data requested by the service request.

[0049] In some embodiments, the service chain includes multiple service nodes, and different service nodes are connected sequentially, that is, the output of the previous service node will be the input of the next service node, and the output of the last service node in the service chain is the request result of the service request.

[0050] Optionally, the embedded nodes intercepted by the slice can be all business nodes in the business link (i.e., full-link embedded nodes) or some business nodes, and the embedded nodes required to be intercepted by the slice can be manually configured. The embodiment of the present application does not limit the number of embedded nodes intercepted by the slice.

[0051] In some embodiments, the aspect intercepts before (before) and / or after (after) the execution of the tracking node.

[0052] Step 202: Aggregate the intercepted tracking data of the tracking nodes.

[0053] Unlike related technologies, each burial point node needs to report the burial point log independently. In the embodiment of the present application, for each burial point node intercepted, the server determines the burial point data corresponding to the burial point node and summarizes the burial point data of different burial point nodes, instead of directly reporting the burial point log for different burial point nodes separately.

[0054] In some embodiments, the burial data of the burial node is obtained by processing the data of the burial node intercepted by the section.

[0055] Step 203: When the business request processing is completed, the tracking data obtained based on the data aggregation is reported to the tracking log.

[0056] In some embodiments, when all business nodes in the business chain have completed execution, the business request processing is completed, and the server reports the point-of-sale log based on the point-of-sale data obtained by data aggregation in the aspect, that is, for one business request, the server only reports the point-of-sale log once.

[0057] Optionally, before reporting the burial point log based on the burial point data obtained based on data aggregation, the burial point data needs to be further processed to make it conform to the log format and content requirements of the burial point log. The specific generation process of the burial point log will be described in the following embodiment.

[0058] In summary, in the embodiment of the present application, the aspect interception technology is used to intercept the business nodes (burying point nodes) with the need for burying point statistics in the business link that processes the business request, and the burying point data of the intercepted business nodes are summarized, so that when the business request processing is completed, a burying point log is reported based on the summarized burying point data. In the entire business request processing process, there is no need for each business node to independently report its own burying point log, which helps to reduce the impact of multiple log writes on interface performance; and the use of aspect interception technology can avoid intrusion into the business logic code of the business node, reducing the difficulty of implementing burying point log reporting.

[0059] When aggregating the tracking data of different tracking nodes, in one possible implementation, the server may define a global variable and implement tracking data aggregation by transferring the global variable between the tracking nodes.

[0060] In another possible implementation, in order to avoid code intrusion into tracking nodes and to avoid modifying data structures transmitted between business nodes, the server sets a thread-local variable for the business request processing thread that processes business requests, and uses the thread-local variable to implement tracking data aggregation.

[0061] Please refer to Figure 3 , which shows a flow chart of a method for reporting tracking logs provided by another exemplary embodiment of the present application. This embodiment uses the method for a server as an example to illustrate the method, which may include the following steps:

[0062] Step 301: intercept the tracking node in the business link through the slice. The business link is the link that processes business requests, and the tracking node is the business node in the business link that has the tracking statistics requirement.

[0063] The implementation process of this step can refer to the above step 201, and this embodiment will not be described in detail here.

[0064] Step 302: Determine the intercepted tracking data of the tracking node.

[0065] In one possible implementation, the server generates the data required for tracking log reporting based on intercepted tracking node data. Furthermore, to identify the tracking node to which the data corresponds, the server processes the data based on the tracking node, obtaining tracking data that can identify the source of the data. This allows the server to subsequently determine which tracking node in the service chain the tracking data belongs to.

[0066] Step 303: Add the tracking data to the thread local variables of the business request processing thread, where the business request processing thread is a thread used to process business requests.

[0067] In one possible implementation, in response to a service request, the server creates a corresponding service request processing thread for the service request, and creates thread-local variables in the service request processing thread for storing tracking data of each tracking node.

[0068] In one possible implementation, the server adds the tracking data of each tracking node to the thread-local variable by means of a union. After each tracking node is passed, new tracking data is added to the thread-local variable.

[0069] In an illustrative example, after the execution of the tracking node 1 is completed, the thread local variable is D1, where D1 is the tracking data of the tracking node 1; after the execution of the tracking node 2 is completed, the thread local variable is updated to D1∪D2, where D2 is the tracking data of the tracking node 2, and so on. As the number of intercepted tracking nodes continues to increase, the amount of data contained in the thread local variable continues to increase.

[0070] Step 304: When the service request processing is completed, the tracking log is reported based on the tracking data in the thread local variables.

[0071] In some embodiments, when the last service node in the service chain completes execution, the service request is processed and the server generates and reports a tracking log based on the tracking data in the thread local variables at this time.

[0072] In this embodiment, by allocating thread-local variables to the business request processing thread and using the thread-local variables to store the tracking data corresponding to each tracking node, there is no need to modify the business logic code of each tracking node and the data transmission format between business nodes, which reduces the difficulty and cost of implementing tracking data aggregation and avoids code intrusion on business nodes.

[0073] In order to accurately intercept the tracking nodes with tracking statistics requirements and ensure the accuracy of the tracking data summary, in one possible implementation, in response to the business request, the server defines the aspect and entry point, and initializes the thread local variables of the business request processing thread.

[0074] The defined entry point includes the embedded node, and the thread local variables are empty after initialization.

[0075] In some embodiments, when defining a facet, it is necessary to define the facet's specific interception logic, such as before, after, around, etc.

[0076] In some embodiments, when defining an entry point, methods such as execution path (excution), annotation (annotation), bean name, and parameter type (args) can be used, and this embodiment of the application does not limit this. For example, when defining an entry point based on an execution path, subsequent aspects intercept the point-of-entry node by matching method signatures (the method signature of the point-of-entry node matches the method signature defined to be intercepted); when defining an entry point based on annotations, subsequent aspects intercept the point-of-entry node by matching annotations (the method or class corresponding to the point-of-entry node has a specific annotation).

[0077] In one possible application scenario, a service chain performs multi-level filtering on raw input data, ultimately feeding the filtered data back to the client. Accordingly, service nodes in the service chain each have their own filtering rules. During service request processing, a service node filters input data based on these rules and then feeds the filtered data to the next service node.

[0078] In related technologies, after each business node completes data filtering, it will report the data obtained after filtering as the embedded point data in the embedded point log. Figure 4 As shown in Figure 1, the service chain includes n service nodes. After the original input data D0 is filtered by the filtering rules of service node 1, D1 is obtained (D1 is a subset of D0); after D1 is filtered by the filtering rules of service node 2, D2 is obtained (D2 is a subset of D1), and so on. n-1 After filtering by the filtering rules of business node n, D n (D n It's D n-1 subset of ).

[0079] Obviously, not only does each business node need to report the embedded point log, but the embedded point data in the embedded point log reported by different business nodes are repeated (for example, the embedded point data reported by all business nodes contains D n), that is, there is a problem of repeated reporting of the same data, which will cause a waste of storage resources.

[0080] In addition, when the data reported by different business nodes is subsequently checked, the duplicate data increases the amount of data to be checked, affecting the efficiency of data checking.

[0081] For the above scenario, in order to reduce the number of log reports and avoid repeated data reporting to reduce the amount of reported data, in one possible implementation, the aspect can determine the data filtered by each intercepted tracking node and use the filtered data as tracking data. Figure 5 As shown, the above step 302 may further include the following sub-steps:

[0082] Step 302A: Determine a filtered data set of the intercepted tracking node, where the filtered data set includes filtered data filtered out by the tracking node based on the filtering rules.

[0083] For each intercepted tracking node, the server determines a filtered data set consisting of filtered data filtered out by the filtering rule corresponding to the tracking node.

[0084] Since the data input to the burying node includes filtered data that is subsequently filtered out by the corresponding filtering rules of the burying node, and the data output by the burying node does not include filtered data filtered out by the filtering rules, in one possible implementation method, the server determines the intercepted node input data and node output data of the burying node, and determines the data difference between the node output data and the node input data as the filtered data set of the burying node.

[0085] In some embodiments, the interception logic of the server-defined aspect includes before and after, that is, the aspect intercepts before and after the execution of the tracking node. Specifically, before the tracking node is executed, the node input data input to the tracking node is intercepted, and after the tracking node is executed, the node output data output by the tracking node is intercepted.

[0086] Indicative, such as Figure 6 As shown, the aspect intercepts business node 1 (point-of-interest node) and obtains the node input data D0 and node output data D1 of business node 1, thereby determining the data difference set of D0 and D1 as the filtered data set F1 of business node 1.

[0087] The aspect intercepts business node 2 (embedded node) and obtains the node input data D1 and node output data D2 of business node 2, thereby determining the data difference set of D1 and D2 as the filtered data set F2 of business node 2.

[0088] Similarly, the slice intercepts the business node n-1 (embedded node) and obtains the node input data D of the business node n-1 n-2 , and node output data D n-1 , thus D n-1 and D n-2 The data difference set is determined as the filtered data set F of business node n-1 n-1 .

[0089] Step 302B: Generate the buried point data of the buried point node based on the filtered data set and filtering rules of the buried point node.

[0090] The filtered data from different tracking nodes is added to the same thread-local variable. To easily identify the filtering rule that each filtered data item is filtered by, after obtaining the filtered data set for the tracking node, the server processes the filtered data set based on the filtering rule corresponding to the tracking node to obtain the tracking data for the tracking node, and then adds the tracking data to the thread-local variable. The processed tracking data has the function of indicating the filtering rule that was used.

[0091] In a possible implementation, for each piece of filtering data in the filtering data set, the server adds a filtering rule identifier representing the filtering rule to the filtering data.

[0092] The filtering rule identifier is used to uniquely identify the filtering rule.

[0093] Optionally, the server adds a filtering rule field to the filtering data and adds the filtering rule identifier to the filtering rule field. i For each piece of filtering data in the filter data, the server adds a rule identifier rule i corresponding to the filtering rule of the business node i to the filtering data, which is recorded as (F ij , rule i), where F ij Represents the filtered data set F i The j-th filtered data in .

[0094] Furthermore, the server adds the filtered data identified by the filtering rules as the tracking data of the tracking node and adds it to the thread local variable.

[0095] Indicative, such as Figure 6 As shown, after adding the filter rule identifier to each filter data in the filter data set F1 corresponding to the service node 1, the server adds the filter data set F1 containing the filter rule identifier to the thread local variable. At this time, the thread local variable is

[0096] After adding the filter rule identifier to each filter data in the filter data set F2 corresponding to the service node 2, the server adds the filter data set F2 containing the filter rule identifier to the thread local variable. At this time, the thread local variable is

[0097] Similarly, for business node n-1, the corresponding filtered data set F n-1 After adding the filter rule identifier to each filter data in the server, the server will include the filter data set F n-1 Add to the thread local variable, the thread local variable is

[0098] When the business request processing is completed, the thread local variables contain all the filtered data filtered out by the corresponding filtering rules of the business node, and there is no redundant filtered data.

[0099] In a possible implementation, when the service request processing is completed, the server generates and reports the tracking log based on each piece of filtering data with a filtering rule identifier added in the thread local variable.

[0100] Indicative, such as Figure 6 As shown, after the business node n completes the data filtering, the server uses the thread local variable Conduct and report the tracking logs.

[0101] Optionally, when generating tracking logs based on thread-local variables, the server determines the filtering reason for each piece of filtered data based on the filter rule identifier corresponding to each piece of filtered data, and generates the tracking log based on the filtering reason. That is, the generated tracking log has the function of indicating the reason why the filtered data was filtered. The server can use the filter rule identifier as the value of the filtering reason field corresponding to the filtered data in the tracking log.

[0102] In this embodiment, by intercepting the node input and output data of the tracking node through the aspect, the filtered data filtered out by the tracking node can be determined, thus preventing the node code of the tracking node from being invaded. Furthermore, for each piece of filtered data, a filter rule identifier is added to the filtered data, and the filtered data containing the filter rule identifier is added to the thread-local variable. Subsequently, based on the thread-local variable, a tracking log indicating the reason why each piece of data was filtered can be generated.

[0103] In addition, since there is no duplicate data between the filtered data sets corresponding to different tracking nodes, generating and reporting tracking data based on the filtered data sets can avoid the waste of storage resources caused by storing redundant data, and help reduce the amount of data for subsequent data screening and improve data screening efficiency.

[0104] In a possible application scenario, when a business request requires at least two business links (at least two business links can correspond to different services (or microservices), and different services can be maintained by different teams, or at least two business links can be regarded as a complete business link, but different business nodes are maintained by different teams) to be processed sequentially, in order to achieve single log reporting during the business request processing, in a possible implementation method, when the current business link completes processing the business request, it is necessary to determine whether the current business link is the last business link among the at least two business links.

[0105] Optionally, when the current business link completes processing the business request and the current business link is the last business link among at least two business links, the server reports the tracking log based on the tracking data in the thread local variable, that is, the tracking log is reported only after the last business node of the last business link completes processing the business request.

[0106] Optionally, when the current business link completes processing the business request and the current business link is not the last business link among at least two business links, in order to enable the next business link to continue processing the business request based on the business request processing result of the current business link, the server adds the embedded data in the thread local variable to the request header and sends a request to the next business link of the current business link. The next business link can continue processing the request based on the embedded data in the request header.

[0107] Schematically, when a business request needs to be processed by the first business link, the second business link, and the third business link, after the first business link completes the business request processing, it adds the embedded data in the thread local variables to the request header and sends the request to the second business link. The second business link continues to process the business request based on the embedded data in the request header, and after completing the business request processing, it adds the embedded data in the thread local variables to the request header and sends the request to the third business link. The third business link continues to process the business request based on the embedded data in the request header, and after completing the business request processing, it reports the embedded log based on the embedded data in the thread local variables.

[0108] In some embodiments, the service node in the next service link obtains the embedded point data from the request header of the request and continues to process the embedded point data. In particular, each service link in at least two service links has its own corresponding aspect, which is used to intercept the embedded point node and write the embedded point data of the embedded point node into the thread local variable. The process of intercepting the embedded point nodes in each service link through the aspect and aggregating the embedded point data of the intercepted embedded point nodes can refer to the above embodiment and will not be repeated in this embodiment.

[0109] In some embodiments, when the embedded data in the thread-local variable includes filtering data with a filtering rule identifier added, and filtering result data including a sending identifier (i.e., the filtering result output by the previous business link), the first business node of the next business link adds the filtering data including the filtering rule identifier in the request header to the thread-local variable, and performs further business processing on the filtering result data including the sending identifier in the request header (for example, further filtering the filtering result data based on the filtering rules).

[0110] In this embodiment, for business requests that require multiple business links to be executed sequentially, by adding tracking data in the request header of the request between business links, the next business link can continue business processing based on the business processing results of the previous business link based on the tracking data in the request header, thereby ensuring the accuracy of complex business request processing; and, multiple business links ultimately only need to report the tracking log once, avoiding multiple reporting of the tracking log to affect interface performance.

[0111] Regarding the processing method of the tracking point log, in one possible implementation method, the server can determine the filtering quantity level of the filtering rules corresponding to each tracking point node based on the tracking point log, and thus adjust the filtering rules based on the filtering quantity level of each filtering rule.

[0112] In some embodiments, the server counts the number of filtered data corresponding to the same filtering rule (filtering reason) in the tracking log to obtain the filtering quantity magnitude of the filtering rule.

[0113] In some embodiments, the server analyzes the filtering data levels of different filtering rules and may determine the filtering rules with abnormal filtering data levels (the filtering data levels are too large or too small), thereby modifying the abnormal filtering rules.

[0114] In other embodiments, the server analyzes the filtering data levels of different filtering rules and can adjust the node execution timing of the service nodes corresponding to the different filtering rules (ie, adjust the execution order of the filtering rules) in descending order of the filtering data levels.

[0115] To facilitate subsequent analysis of the delivery of the original input data of the input service link and the reason for filtering, in a possible implementation, the server may add the filtering result data output by the service link to a thread local variable.

[0116] Optionally, after the node output parameters and node input parameters of the last tracking node are obtained through aspect interception, in addition to being used to determine the filtered data set based on the node output parameters and the node input parameters, they are also added to the thread local variables.

[0117] Indicatively, in Figure 6 On the basis of Figure 7 As shown, after the business node n completes the data filtering, the server will include the filtered data set F n Add to the thread local variable and output the node data D of the business node n n (ie, filter result data) is added to the thread local variable. At this time, the thread local variable That is, the thread local variables contain all the original input data of the business link.

[0118] To distinguish the filtered data from the filtered data, in one possible implementation, the server adds a delivery identifier to each piece of filtered result data output by the service link, and adds the filtered result data with the delivery identifier to a thread-local variable. The delivery identifier is used to indicate that the filtered result data is delivered as a service response to the service request.

[0119] Optionally, the server adds a delivery field to the filtering result data and adds a delivery identifier to the delivery field.

[0120] Furthermore, when reporting the tracking log, in one possible implementation, when the business request processing is completed, the server determines the delivery status or filtering reason of each original input data of the business link based on the tracking data and filtering result data in the thread local variables, and thus generates and reports the tracking log based on the delivery status or filtering reason of each original input data.

[0121] In some embodiments, for data containing a delivery identifier, the server determines that the data was delivered normally. For data that does not contain a delivery identifier, the server determines that the data was not delivered normally, and further determines the reason why the data was filtered based on the filtering rule identifier carried by the data. After completing the above analysis of each piece of data in the thread local variable, the server generates a tracking log.

[0122] In an illustrative example, when the business link contains m pieces of original input data, the tracking log reported by the server is shown in Table 1.

[0123] Table 1

[0124]

[0125]

[0126] Among them, 1 means that the data is sent normally, and 0 means that the data is not sent normally.

[0127] In combination with the above embodiments, in a possible application scenario, when receiving a content recommendation request sent by a client, the server defines a section to intercept each content filtering node in the content recommendation link and initialize the thread local variables of the content recommendation thread.

[0128] When processing the content recommendation request, the server inputs the content recommendation list into the content recommendation link. The content filtering nodes filter the candidate recommended contents in the content recommendation list in turn according to their respective content filtering rules.

[0129] The aspect intercepts the node input data and node input data of each content filtering node, thereby determining the filter data set of each content filtering node, and adding a content filtering rule identifier to each candidate recommended content in the filter data set, thereby adding the candidate recommended content carrying the content filtering rule identifier to the thread local variable.

[0130] After all content filtering nodes complete content filtering, the aspect further adds a delivery flag to the node output data of the last content filtering node and adds it to the thread local variable.

[0131] After completing the above operations, the server generates a tracking log based on the thread local variables. The tracking log is used to indicate whether each candidate recommended content in the content recommendation list has been sent, and the reasons for filtering the candidate recommended content that has not been sent.

[0132] Please refer to Figure 8 , which shows a structural block diagram of a tracking log reporting device provided by an exemplary embodiment of the present application. The device includes:

[0133] A slice interception module 801 is used to intercept tracking nodes in a service link through a slice. The service link is a link that processes service requests, and the tracking nodes are service nodes in the service link that have tracking statistics requirements.

[0134] The data processing module 802 is used to aggregate the intercepted tracking data of the tracking nodes;

[0135] The log reporting module 803 is used to report the tracking log based on the tracking data obtained by data aggregation when the business request processing is completed.

[0136] In some embodiments, the data processing module 802 is configured to:

[0137] Determining the intercepted tracking data of the tracking node;

[0138] Adding the tracking data to the thread local variable of the business request processing thread, where the business request processing thread is a thread used to process the business request;

[0139] The log reporting module 803 is used to:

[0140] When the business request processing is completed, the tracking log is reported based on the tracking data in the thread local variable.

[0141] In some embodiments, the service node in the service link is used to filter the input data according to the filtering rules and input the filtered data into the next service node;

[0142] The data processing module 802 is configured to:

[0143] Determine a filtered data set of the intercepted tracking node, where the filtered data set includes filtered data filtered out by the tracking node based on the filtering rule;

[0144] Based on the filtered data set and the filtering rules of the burying point node, the burying point data of the burying point node is generated.

[0145] In some embodiments, the data processing module 802 is configured to:

[0146] Determine the node input data and node output data of the intercepted tracking node;

[0147] The data difference set between the node output data and the node input data is determined as the filtered data set of the buried node.

[0148] In some embodiments, the data processing module 802 is configured to:

[0149] For each piece of filtering data in the filtering data set, adding a filtering rule identifier representing the filtering rule to the filtering data;

[0150] The filtered data after adding the filtering rule identifier is used as the burying data of the burying node.

[0151] In some embodiments, the data processing module 802 is further configured to:

[0152] When the service request processing is completed, the filtering result data output by the service link is added to the thread local variable.

[0153] In some embodiments, the data processing module 802 is configured to:

[0154] adding a delivery flag to each piece of the filtering result data output by the service link, wherein the delivery flag is used to indicate that the filtering result data is delivered as a service response to the service request;

[0155] The filtering result data after adding the issuing identifier is added to the thread local variable.

[0156] In some embodiments, the log reporting module 803 is used to:

[0157] When the service request processing is completed, determining the delivery status or filtering reason of each piece of original input data of the service link based on the embedded data and the filtering result data in the thread local variable;

[0158] The tracking log is generated and reported based on the delivery status or filtering reason of each piece of the original input data.

[0159] In some embodiments, the apparatus further comprises a log analysis module for:

[0160] Based on the tracking log, determine the filtering quantity magnitude of the filtering rule corresponding to each tracking node;

[0161] The filtering rules are adjusted based on the filtering quantity magnitude of each filtering rule.

[0162] In some embodiments, the section interception module 801 is further configured to:

[0163] In response to the business request, the aspect and entry point are defined, and the thread local variables of the business request processing thread are initialized, wherein the entry point includes the tracking node, and the thread local variables after initialization are empty.

[0164] In some embodiments, when the service request is processed sequentially by at least two service links, the log reporting module 803 is configured to:

[0165] When the current business link completes processing the business request and the current business link is not the last business link of the at least two business links, add the embedded data in the thread local variable to the request header, and send a request to the next business link of the current business link, and the next business link is used to continue request processing based on the embedded data in the request header;

[0166] When the current business link completes processing of the business request and the current business link is the last business link of at least two business links, the burial point log is reported based on the burial point data in the thread local variable.

[0167] In summary, in the embodiment of the present application, the aspect interception technology is used to intercept the business nodes (burying point nodes) with the need for burying point statistics in the business link that processes the business request, and the burying point data of the intercepted business nodes are summarized, so that when the business request processing is completed, a burying point log is reported based on the summarized burying point data. In the entire business request processing process, there is no need for each business node to independently report its own burying point log, which helps to reduce the impact of multiple log writes on interface performance; and the use of aspect interception technology can avoid intrusion into the business logic code of the business node, reducing the difficulty of implementing burying point log reporting.

[0168] It should be noted that the apparatus provided in the above embodiments is merely exemplified by the division of the above functional modules. In actual applications, the above functions can be distributed among different functional modules as needed, that is, the internal structure of the apparatus can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments are based on the same concept. The implementation process is detailed in the method embodiments and will not be repeated here.

[0169] See also Figure 9 , Figure 9 9 is a block diagram of a server provided by an exemplary embodiment of the present application. The server may include one or more of the following components: a processor 910 and a memory 920.

[0170] Optionally, the processor 910 utilizes various interfaces and lines to connect various parts of the entire electronic device, and executes various functions of the electronic device and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 920, and calling data stored in the memory 920. Optionally, the processor 910 can be implemented in the form of at least one hardware of digital signal processing (DSP), field-programmable gate array (FPGA), and programmable logic array (PLA).

[0171] The processor 910 may integrate one or a combination of a central processing unit (CPU), a graphics processing unit (GPU), a neural network processing unit (NPU), and a baseband chip. Among them, the CPU mainly processes the operating system, user interface, and application programs; the GPU is responsible for rendering and drawing the content to be displayed on the touch screen; the NPU is used to implement artificial intelligence (AI) functions; and the baseband chip is used to process wireless communications. It is understandable that the above-mentioned baseband chip may not be integrated into the processor 910, but may be implemented separately through a single chip.

[0172] The memory 920 may include a random access memory (RAM) or a read-only memory (ROM). Optionally, the memory 920 includes a non-transitory computer-readable storage medium. The memory 920 may be used to store instructions, programs, codes, code sets, or instruction sets. The memory 920 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for at least one function, instructions for implementing the various method embodiments described above, and the data storage area may store data created based on the use of the server.

[0173] In addition, those skilled in the art will understand that the structure of the server shown in the above figures does not constitute a limitation on the server, and the computer equipment may include more (such as power components, network communication components) or fewer components than shown in the figure, or a combination of certain components, or a different arrangement of components.

[0174] An embodiment of the present application provides a computer-readable storage medium, which stores at least one computer instruction, and the at least one computer instruction is used to be executed by a processor to implement the tracking log reporting method as described in the above embodiment.

[0175] On the other hand, an embodiment of the present application provides a computer program product, which includes computer instructions, and the computer instructions are stored in a computer-readable storage medium; the processor reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to implement the tracking log reporting method as described in the above embodiment.

[0176] Those skilled in the art will appreciate that in one or more of the above examples, the functions described in the embodiments of the present application can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any media that facilitates the transmission of computer programs from one place to another. The storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0177] The above description is merely an optional embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A method for reporting embedded logs, characterized in that: The method comprises: Intercept tracking nodes in a service link through a slice. The service link is a link that processes service requests, and the tracking nodes are service nodes in the service link that have tracking statistics requirements. Summarizing the intercepted tracking data of the tracking nodes; When the business request processing is completed, the tracking data obtained based on the data aggregation is reported to the tracking log.

2. The method according to claim 1, characterized in that The step of aggregating the intercepted tracking data of the tracking node includes: Determining the intercepted tracking data of the tracking node; Adding the tracking data to the thread local variable of the business request processing thread, where the business request processing thread is a thread used to process the business request; When the service request processing is completed, reporting the tracking data obtained based on the data aggregation to the tracking log includes: When the business request processing is completed, the tracking log is reported based on the tracking data in the thread local variable.

3. The method according to claim 2, characterized in that The service node in the service link is used to filter the input data according to the filtering rules and input the filtered data into the next service node; The determining the intercepted tracking data of the tracking node includes: Determine a filtered data set of the intercepted tracking node, where the filtered data set includes filtered data filtered out by the tracking node based on the filtering rule; Based on the filtered data set and the filtering rules of the burying point node, the burying point data of the burying point node is generated.

4. The method according to claim 3, characterized in that The determining of the filtered data set of the intercepted tracking node includes: Determine the node input data and node output data of the intercepted tracking node; The data difference set between the node output data and the node input data is determined as the filtered data set of the buried node.

5. The method according to claim 3, characterized in that The generating the buried point data of the buried point node based on the filtered data set and the filtering rule of the buried point node includes: For each piece of filtering data in the filtering data set, adding a filtering rule identifier representing the filtering rule to the filtering data; The filtered data after adding the filtering rule identifier is used as the burying data of the burying node.

6. The method according to claim 3, characterized in that The method further comprises: When the service request processing is completed, the filtering result data output by the service link is added to the thread local variable.

7. The method according to claim 3, characterized in that The method further comprises: Based on the tracking log, determine the filtering quantity magnitude of the filtering rule corresponding to each tracking node; The filtering rules are adjusted based on the filtering quantity magnitude of each filtering rule.

8. The method according to claim 2, characterized in that The method further comprises: In response to the business request, the aspect and entry point are defined, and the thread local variables of the business request processing thread are initialized, wherein the entry point includes the tracking node, and the thread local variables after initialization are empty.

9. The method according to claim 2, characterized in that When the service request is processed sequentially by at least two service links, and when the service request is processed, reporting the tracking log based on the tracking data in the thread local variable includes: When the current business link completes processing the business request and the current business link is not the last business link of the at least two business links, add the embedded data in the thread local variable to the request header, and send a request to the next business link of the current business link, and the next business link is used to continue request processing based on the embedded data in the request header; When the current business link completes processing of the business request and the current business link is the last business link of at least two business links, the burial point log is reported based on the burial point data in the thread local variable.

10. A computer program product, characterized in that The computer program product includes computer instructions, which are stored in a computer-readable storage medium; the processor reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to implement the tracking log reporting method as described in any one of claims 1 to 9.

Images