Traffic recording method and device
By setting recording identifiers for active recording services and passing recording marks, the problem that the existing technology cannot fully record the complete traffic, and the complete recording of complete traffic including inlet and intermediate service sub-calls is achieved, which improves the user experience.
Patent Information
- Application Number
- CN202411920083.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-24
- Publication Date
- 2025-03-28
AI Technical Summary
The prior art cannot fully record the complete traffic including entry and intermediate service sub-calls, resulting in a poor user experience.
By setting a recording identifier for the active recording service and passing the recording mark when the service sub calls other services, other services can record traffic based on the recording identifier.
It realizes complete recording of complete traffic including entry and intermediate service sub-calls, improving the user experience.
Smart Images
Figure CN119728470A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of big data technology, and in particular to a traffic recording method and device. Background Art
[0002] The essence of traffic is the request parameters and the corresponding return values, so traffic recording is to intercept and save the request and response data through technical means. At present, traffic recording sets a collection rate to control the recording percentage. The recording strategy using percentage cannot guarantee that the traffic collected on application A will be collected when it reaches application B. Assuming that the recording percentage of A is 10% and the recording percentage of B is 10%, the complete traffic recorded in the end may be only 10%×10%=1%, and the remaining 9% is incomplete and invalid traffic.
[0003] In the process of implementing the present invention, the inventors found that there are at least the following problems in the related art:
[0004] The entire traffic including the entry and intermediate service sub-calls cannot be fully recorded, resulting in a poor user experience. Summary of the invention
[0005] In view of this, an embodiment of the present invention provides a traffic recording method and device, which can set a recording identifier for an active recording service, and pass a recording mark when the active recording service sub-calls other services, so that other services can record traffic according to the recording identifier, thereby being able to fully record the complete traffic including the entry and intermediate service sub-calls, thereby improving the user experience.
[0006] To achieve the above object, according to one aspect of an embodiment of the present invention, a traffic recording method is provided, including:
[0007] In response to the service receiving the traffic access request, determining whether the service is an active recording service;
[0008] In response to the service being an active recording service, performing traffic recording according to a preset recording strategy and setting a recording flag for the service;
[0009] In response to monitoring that the service calls the target service, a recording identifier is passed to the target service, so that the target service performs traffic recording in response to the recording identifier.
[0010] Optionally, after setting the recording flag for the service, the following is also included:
[0011] The recording identifier is stored in the thread context of the current thread; the service calls the target service by calling the child thread;
[0012] Pass the recording ID to the target service, including:
[0013] Based on the pre-configured thread context transfer mechanism, the recording identifier is copied from the thread context of the current thread to the thread context of the child thread.
[0014] Optionally, based on a preconfigured thread context transfer mechanism, copying the recording identifier from the thread context of the current thread to the thread context of the child thread includes:
[0015] The recording identifier is obtained from the thread context of the current thread, and the recording identifier is encapsulated into an attachment of a remote procedure call request and sent to the thread context of the child thread; wherein the remote procedure call request is a request sent by a service calling a target service.
[0016] Optionally, traffic recording is performed according to a preset recording strategy, including:
[0017] Based on the remote procedure call framework, a start instruction is sent to the recording probe of the service, so that the recording probe collects traffic data of the service according to the received start instruction.
[0018] Optionally, in response to the service receiving the traffic access request, the method further includes:
[0019] Determine whether the traffic access request hits the pre-configured recording policy.
[0020] Optionally, the method further comprises:
[0021] A termination instruction is sent to the service to terminate the service for traffic collection. In response to the time after the service termination reaching a preset time threshold, a termination instruction is sent to the target service to terminate the traffic collection of the entire link.
[0022] According to a second aspect of an embodiment of the present invention, a traffic recording device is provided, including:
[0023] A determination module, configured to determine whether the service is an active recording service in response to the service receiving a traffic access request;
[0024] A setting module, for, in response to the service being an active recording service, performing traffic recording according to a preset recording strategy and setting a recording identifier for the service;
[0025] The calling module is used to transmit the recording identifier to the target service in response to monitoring that the service calls the target service, so that the target service performs traffic recording in response to the recording identifier.
[0026] According to a third aspect of an embodiment of the present invention, there is provided an electronic device, including:
[0027] one or more processors;
[0028] a memory for storing one or more programs,
[0029] When one or more programs are executed by one or more processors, the one or more processors are enabled to implement the method of any of the above embodiments.
[0030] According to a fourth aspect of an embodiment of the present invention, a computer-readable medium is provided, on which a computer program is stored, and when the program is executed by a processor, the method of any of the above embodiments is implemented.
[0031] According to a fifth aspect of an embodiment of the present invention, there is provided a computer program product, including a computer program, which implements the method of any of the above embodiments when the computer program is executed by a processor.
[0032] An embodiment of the above invention has the following advantages or beneficial effects: by responding to a service receiving a traffic access request, determining whether the service is an active recording service; in response to the service being an active recording service, performing traffic recording according to a preset recording strategy and setting a recording identifier for the service; in response to monitoring that the service calls a target service, passing the recording identifier to the target service, so that the target service performs traffic recording in response to the recording identifier; thereby being able to set a recording identifier for the active recording service, and passing a recording mark when the active recording service sub-calls other services, so that other services perform traffic recording according to the recording identifier, thereby being able to fully record the complete traffic including the entry and intermediate service sub-calls, thereby improving the user experience.
[0033] The further effects of the above-mentioned non-conventional optional manner will be described below in conjunction with the specific implementation manner. BRIEF DESCRIPTION OF THE DRAWINGS
[0034] The accompanying drawings are used to better understand the present invention and do not constitute an improper limitation of the present invention.
[0035] Figure 1 is a schematic diagram of the main process of the traffic recording method according to an embodiment of the present invention;
[0036] Figure 2 is a schematic diagram of the process of transmitting an identification between services according to a preferred embodiment of the present invention;
[0037] Figure 3 is a schematic diagram of the process of local identification transmission according to a preferred embodiment of the present invention;
[0038] Figure 4 is a schematic diagram of main modules of a traffic recording device according to an embodiment of the present invention;
[0039] Figure 5 is an exemplary system architecture diagram to which embodiments of the present invention may be applied;
[0040] Figure 6It is a schematic diagram of the structure of a computer system of a terminal device or a server suitable for implementing an embodiment of the present invention. DETAILED DESCRIPTION
[0041] The following is a description of exemplary embodiments of the present invention in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and conciseness, the description of well-known functions and structures is omitted in the following description.
[0042] It should be noted that the acquisition, storage and application of personal information etc. involved in the embodiments of the present invention are in compliance with the provisions of relevant laws and regulations and do not violate public order and good morals.
[0043] The essence of traffic is the request parameters and the corresponding return values, so traffic recording is to intercept and save the request and response data through technical means. The current traffic recording will set a collection rate to control the recording percentage. The recording strategy using percentage cannot guarantee that the traffic collected on application A will be collected when it reaches application B. Assuming that the recording percentage of A is 10% and the recording percentage of B is 10%, the final recorded complete traffic may be only 10% × 10% = 1%, and the remaining 9% is incomplete and invalid traffic; the complete traffic including the entrance and the intermediate service sub-call cannot be fully recorded, resulting in a poor user experience.
[0044] In view of this, according to one aspect of an embodiment of the present invention, a traffic recording method is provided.
[0045] Figure 1 FIG. 1 is a schematic diagram of the main process of the traffic recording method according to an embodiment of the present invention. Figure 1 As shown, the traffic recording method according to an embodiment of the present invention includes the following steps S101 to S103.
[0046] Step S101, in response to a service receiving a traffic access request, determining whether the service is an active recording service.
[0047] A service is a module that provides specific functions or business logic for other systems or applications in a distributed system. It can be an independent application or microservice, and provides an interface to the outside world through a network protocol. Traffic access requests are requests sent by external systems or users to the service to perform a specific operation or obtain data. These requests include a variety of input parameters used to drive the execution of business logic in the service.
[0048] An active recording service is a service that can actively start the traffic recording function after receiving a traffic recording request. An active recording service is generally located at the starting point of the call chain and can pass the generated recording identifier to the downstream service. The determination of whether a service is an active recording service can be based on predefined configurations or rules, such as the role of the service, its position in the call chain, etc. If the service is at the starting position of the link and is configured as an active recording service, it will start recording and set the corresponding recording identifier for it; if the service is a downstream service, it will decide whether to enter the passive recording mode based on whether the recording identifier is received.
[0049] Step S102, in response to the service being an active recording service, traffic recording is performed according to a preset recording strategy and a recording flag is set for the service.
[0050] The preset recording policy is the rules and processes defined for traffic recording behavior. These rules can be set based on business needs, performance considerations, and monitoring requirements. The recording policy can include which services need to be recorded, which traffic or request types need to be recorded, as well as the recording duration, data sampling rate, etc.; it can also specify how to handle different types of traffic, such as whether to record only error requests, operations of specific users, etc. The process of traffic recording involves intercepting all requests received by the service and the service's external responses, and saving this data to a log or database. The recorded content can include the request URL (Uniform Resource Locator), parameters, request header information, user identity, response data, etc., to form a comprehensive view of the service runtime. This recording can be used for debugging, performance analysis, or security auditing in distributed systems to accurately restore the request processing process.
[0051] A recording identifier is a unique mark used to identify a request or the entire link of a traffic recording. It can be a globally unique ID (Identifier) that can be passed in calls between services. Through this identifier, traffic across multiple services can be associated to form a complete call link. In an active recording service, a recording identifier is generated at the start of traffic recording and is set in the service. Specifically, the service can generate a unique recording identifier after receiving a traffic recording request and store it in the current thread context so that it can be passed between the service and downstream services. In addition, the recording identifier can also be pre-allocated by the service registration system and passed through the RPC framework (Remote Procedure Call) so that all nodes in the service link can obtain the same identifier.
[0052] Step S103, in response to monitoring that the service calls the target service, the recording identifier is transmitted to the target service, so that the target service performs traffic recording in response to the recording identifier.
[0053] The target service refers to the downstream service called by the current service, that is, the microservice or system module that provides a specific function or data for the current service. When the upstream service calls the target service, the recording identifier is passed to it so that the target service can also perform the corresponding traffic recording. There are many ways to implement the transmission of the recording identifier; the recording identifier can be transmitted through the remote procedure call (RPC) protocol. In the RPC request that calls the target service, the service uses the protocol extension mechanism of the RPC framework to attach the recording identifier to the request as metadata or extension field. These metadata are parsed when the request reaches the target service. The target service extracts the recording identifier from it and starts the corresponding traffic recording process based on it; or, the recording identifier is transmitted through the HTTP request header (Hyper Text Transfer Protocol). The service can attach the recording identifier to the custom field in the HTTP request header. When the target service receives the request, it extracts the recording identifier from the HTTP request header and uses it as the basis to start its own traffic recording operation. In this way, the recording identifiers between services can remain consistent in multiple cross-service calls.
[0054] The embodiment of the present invention determines whether a service is an active recording service in response to a service receiving a traffic access request; in response to the service being an active recording service, performs traffic recording according to a preset recording strategy and sets a recording identifier for the service; in response to monitoring that the service calls a target service, passes the recording identifier to the target service, so that the target service performs traffic recording in response to the recording identifier; thereby, a recording identifier can be set for the active recording service, and a recording mark can be passed when the active recording service sub-calls other services, so that other services perform traffic recording according to the recording identifier, thereby fully recording the complete traffic including the entry and intermediate service sub-calls, thereby improving the user experience.
[0055] Optionally, after setting the recording identifier for the service, it also includes: storing the recording identifier in the thread context of the current thread; the service calls the target service by calling the child thread; passing the recording identifier to the target service, including: based on a pre-configured thread context transfer mechanism, copying the recording identifier from the thread context of the current thread to the thread context of the child thread.
[0056] After setting the recording flag for the service, you can store the recording flag in the thread context of the current thread. The thread context is a thread-level storage space that allows programs to access shared variables in the same thread. The recording flag is placed in the context of the current thread so that all methods and operations executed in the thread can read the recording flag and associate related recording data. When the service needs to call the target service, it can perform asynchronous operations by creating a child thread and pass the recording flag to the child thread to ensure that the child thread can also perform traffic recording.
[0057] Based on the pre-configured thread context transfer mechanism, the recording identifier can be transferred in a variety of ways. For example, when creating a child thread, the recording identifier in the current thread context can be manually copied to the child thread context by encapsulating the thread pool or thread object; for another example, an automated thread context management tool, such as ThreadLocal (thread local storage) or a custom thread context transfer mechanism, can be used to automatically copy the context information of the main thread, including the recording identifier, when the child thread starts. When the child thread executes the call to the target service, the context of the child thread already contains the recording identifier copied from the main thread, so the child thread can read the identifier through the thread context and pass it to the target service. After the target service receives the recording identifier, it can continue to record traffic based on the identifier, so that the traffic data in the entire service link is fully associated and collected.
[0058] Optionally, based on a preconfigured thread context transfer mechanism, the recording identifier is copied from the thread context of the current thread to the thread context of the child thread, including: obtaining the recording identifier from the thread context of the current thread, and encapsulating the recording identifier into an attachment of a remote procedure call request and sending it to the thread context of the child thread; wherein the remote procedure call request is a request sent by the service to call the target service.
[0059] In the thread context delivery mechanism based on pre-configuration, the recording identifier is obtained from the thread context of the current thread and encapsulated into the attachment of the remote procedure call request. This process can be done by creating a request object, adding the recording identifier as a field of the request to the object, and then sending the request to the target service; the recording identifier can also be converted into a byte stream using the serialization mechanism and delivered as additional information of the RPC call; or, the recording identifier can be directly attached to the context of the RPC request using the existing framework support.
[0060] Optionally, based on a preconfigured thread context transfer mechanism, the recording identifier is copied from the thread context of the current thread to the thread context of the child thread. An event-driven mechanism can also be used. When the current thread triggers an event during execution, the recording identifier can be passed as additional information of the event. The event can be implemented through a message queue or a publish / subscribe mechanism. When the child thread processes the event, it can extract the recording identifier from the event and store it in its own thread context.
[0061] Optionally, traffic recording is performed according to a preset recording strategy, including: sending a start instruction to a recording probe of the service based on a remote procedure call framework, so that the recording probe collects traffic data of the service according to the received start instruction.
[0062] Specifically, when the service starts, the service will automatically initialize the recording probe according to the system configuration and establish a connection with it. When the service receives a traffic access request or a traffic recording request, it can send a start instruction through an RPC call. This instruction can contain necessary context information, such as a recording identifier, the start time of the recording, etc. After receiving the instruction, the recording probe will start collecting traffic data according to the instruction content and store the collected data in a specified location for subsequent analysis. In addition, you can also listen for specific events (such as the arrival of a traffic recording request). Once the event is triggered, the service immediately sends a start instruction to the recording probe through the RPC framework to start collecting traffic data. The service can set a callback function so that it can receive the collection results in time after the recording process ends. This method can improve the flexibility of the system. The recording strategy can be dynamically adjusted according to different events, and traffic recording can be started in a timely and effective manner to ensure the integrity and real-time nature of the data.
[0063] Optionally, in response to the service receiving the traffic access request, the method further includes: determining that the traffic access request hits a pre-configured recording strategy.
[0064] The recording strategy is defined as a set of rules, which include specific URL paths (Uniform Resource Locator), request methods, request parameters, etc. When the service receives a traffic access request, it parses the various components of the request and matches them with the pre-configured recording strategy. For example, if the recording strategy specifies that only a specific API endpoint (Application Programming Interface) is to be recorded, the service will extract the requested URL after receiving the request and compare it with the rules. If the requested URL path matches the path defined in the recording strategy, it is confirmed that the request hits the recording strategy, and the service can start the recording process, which improves the accuracy and effectiveness of the recording.
[0065] Optionally, the method further includes: sending a termination instruction to the service to terminate the service for traffic collection, and in response to the time after the service termination reaching a preset time threshold, sending a termination instruction to the target service to terminate the traffic collection of the entire link.
[0066] A specific termination command is sent to the service through the remote procedure call framework. This termination command can be designed as a request with a status identifier, such as "STOP_RECORDING". The request is sent to the specified interface of the service. When the service receives this instruction, it will immediately stop data collection and process and save its currently collected data to ensure the integrity of the traffic record, so that the service can respond to the termination instruction in time, thereby reducing the waste of resources. After terminating the active recording service, the same remote procedure call framework is used to send an instruction to terminate traffic collection to the target service. This instruction can be "STOP_LINK_RECORDING", which is used to instruct the target service to stop its current traffic collection task. After receiving the instruction, the target service will complete the current request processing and safely end the traffic recording so that all relevant data are properly saved.
[0067] Figure 2 It is a flowchart of inter-service identity transmission according to a preferred embodiment of the present invention.
[0068] like Figure 2 As shown in the figure, the structure and identifier transmission process of service A and service B during traffic recording. Service A receives an HTTP request and enters Tomcat (Java container) and JSF (JavaServer Faces) modules. During this process, a recording identifier is generated and stored in the thread context of the current thread, so that all operations in service A can share this identifier. When service A calls service B through RPC, the recording identifier is passed to service B through the RPC protocol. After receiving the RPC request, service B still processes it through the JSF module and continues to pass and store this recording identifier in its thread context, so that the recording identifier is visible in all steps executed by service B. This context mechanism keeps the traffic recording across services consistent and improves the integrity of the recording link.
[0069] According to the flow direction of traffic, this embodiment divides services into active recording and passive recording. Active recording services can collect any traffic passing through them, while passive recording services can only record traffic transmitted by active recording services and marked as recorded by active recording services. To implement this traffic marking logic and transmit it between applications, a transmission medium is required. The communication framework between microservices can be JSF. There is an attachment attribute on the request of the JSF communication protocol, which is used to transmit additional information between microservices. Assuming that the service call link is A->B->C, A is actively recorded, and B and C are passively recorded. When a request on service A hits the sampling strategy or recording strategy, the recording collection code implanted by the recording probe will generate a recording identifier for the request. This recording identifier will be placed in the thread context of the current request execution. When a cross-application RPC call occurs, that is, when service A calls service B internally, this recording identifier existing in the thread context can be taken out and placed in the attachment of the JSF communication protocol, and passed to the downstream service B through the RPC request. The behavior set for downstream service B is passive recording. When there is a request from service A, the recording probe on service B will parse the attachment in the request. If it is found that the attachment contains a recording identifier, it will start collecting current traffic and put the recording identifier in the thread context that executes the request from service A. If a cross-application RPC call occurs at this time, that is, service B calls service C internally, the identifier in the thread context of service B will be taken out and put in the request attachment sent by service B to service C, and so on.
[0070] When recording starts, first send a passive recording command to service B and service C. Since service A has not started active recording at this time, any traffic passing through service B and service C will not have a recording mark, so service B and service C will not collect any traffic at this time; when service B and service C are fully prepared, send an active recording command to service A. At this time, service A starts to collect traffic according to the set collection rate, and generates a recording mark to pass to the downstream service. When recording ends, first send a stop command to service A. At this time, service A will no longer generate a new recording mark. Service B and service C can continue to collect traffic that has not been executed. After waiting for a while, send a stop command to service B and service C, and the recording of this batch of traffic is completed. Through the above strategy, the traffic of the call link A->B->C can be collected and associated together according to the recording mark. The complete link collected can avoid the loss of recording links due to state asynchrony by sending commands to control the start and end of recording.
[0071] Figure 3 It is a schematic diagram of the process of local identification transmission according to a preferred embodiment of the present invention.
[0072] like Figure 3As shown in the figure, the thread context saves the recording identifier. When the local method is executed, the recording probe will be triggered in sequence. Components such as JSF Provider (Java server-oriented provider), JimDB Client (client), MyBatis (persistence layer framework) will use the recording identifier in the same thread context. During the execution process, if the thread starts a child thread, such as JSF Consumer (Java server-oriented consumer) and Local Cache (local cache), the recording identifier in the main thread context is copied to the child thread context through the thread context transfer mechanism, so that the child thread can also read and use the same recording identifier. This transfer mechanism ensures the consistency of recording data across threads, and can ensure the full-link traffic recording effect even in high concurrency or asynchronous scenarios.
[0073] In this embodiment, a thread needs to be started to execute local methods in Java. The methods in the program will be executed sequentially in the thread according to the method call stack. The thread provides a mechanism called thread context for maintaining visible variables in the thread, and stores the recording identifier in the local storage area in the thread context, so that the recording identifier is visible to all local methods executed in the thread. During the execution of the main thread of the business, there is a situation where a sub-thread is started to asynchronously make certain operations to improve concurrency and reduce business response time. In this scenario, a thread context transfer mechanism is required to transfer the recording identifier in the main thread context to the sub-thread context, otherwise the sub-call in the sub-thread will not be collected, and the recorded traffic will be incomplete. At this time, the business code is required to use a dedicated SDK to package the thread pool, so as to realize the information transmission capability from the main thread context to the sub-thread context, where packaging is a coding method in Java, which is used to expand existing functions. The native thread pool of Java does not have the ability of context transmission. The ability of the thread pool is expanded through packaging to enable it to have the ability of thread context transmission. The wrapped thread pool can save the contents of the current thread context as a snapshot and hold it as an attribute of a Runnable or Callable object. When the run() method or call() method is called, the thread context information can be restored from the snapshot to the current thread context, thereby realizing the recording identifier transfer between the main thread and the child thread.
[0074] According to a second aspect of an embodiment of the present invention, a traffic recording device is provided.
[0075] Figure 4 is a schematic diagram of main modules of a traffic recording device according to an embodiment of the present invention.
[0076] like Figure 4 As shown, a traffic recording device 400 includes:
[0077] The determination module 401 is used to determine whether the service is an active recording service in response to the service receiving the traffic access request;
[0078] A setting module 402, for performing traffic recording according to a preset recording strategy and setting a recording flag for the service in response to the service being an active recording service;
[0079] The calling module 403 is used to transmit the recording identifier to the target service in response to the monitored service calling the target service, so that the target service performs traffic recording in response to the recording identifier.
[0080] Optionally, the recording device 400 further includes a storage module, and the storage module is used to:
[0081] The recording identifier is stored in the thread context of the current thread; the service calls the target service by calling the child thread;
[0082] Calling module 403, used to:
[0083] Based on the pre-configured thread context transfer mechanism, the recording identifier is copied from the thread context of the current thread to the thread context of the child thread.
[0084] Optionally, calling module 403 is used to:
[0085] The recording identifier is obtained from the thread context of the current thread, and the recording identifier is encapsulated into an attachment of a remote procedure call request and sent to the thread context of the child thread; wherein the remote procedure call request is a request sent by a service calling a target service.
[0086] Optionally, a module 402 is provided for:
[0087] Based on the remote procedure call framework, a start instruction is sent to the recording probe of the service, so that the recording probe collects traffic data of the service according to the received start instruction.
[0088] Optionally, the recording device 400 further includes a determination module, and the determination module is used to:
[0089] Determine whether the traffic access request hits the pre-configured recording policy.
[0090] Optionally, the recording device 400 further includes a termination module, and the termination module is used to:
[0091] A termination instruction is sent to the service to terminate the service for traffic collection. In response to the time after the service termination reaching a preset time threshold, a termination instruction is sent to the target service to terminate the traffic collection of the entire link.
[0092] It should be noted that the specific implementation content of the traffic recording device of the present invention has been described in detail in the above traffic recording method, so the repeated content will not be described again here.
[0093] According to a third aspect of an embodiment of the present invention, there is provided an electronic device, comprising: one or more processors; a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method provided by the first aspect of the embodiment of the present invention.
[0094] According to a fourth aspect of an embodiment of the present invention, a computer-readable medium is provided, on which a computer program is stored, and when the program is executed by a processor, the method provided by the first aspect of the embodiment of the present invention is implemented.
[0095] According to a fifth aspect of an embodiment of the present invention, a computer program product is provided, including a computer program, and when the computer program is executed by a processor, the method provided by the first aspect of the embodiment of the present invention is implemented.
[0096] Figure 5 An exemplary system architecture 500 is shown to which the traffic recording method or traffic recording device according to the embodiment of the present application can be applied.
[0097] like Figure 5 As shown, system architecture 500 may include terminal devices 501, 502, 503, a network 504 and a server 505. Network 504 is used to provide a medium for communication links between terminal devices 501, 502, 503 and server 505. Network 504 may include various connection types, such as wired, wireless communication links or optical fiber cables, etc.
[0098] Users can use terminal devices 501, 502, 503 to interact with server 505 through network 504 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 501, 502, 503, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (only as examples).
[0099] The terminal devices 501 , 502 , and 503 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, desktop computers, and the like.
[0100] The server 505 may be a server that provides various services, such as a background management server (only an example) that provides support for shopping websites browsed by users using the terminal devices 501, 502, and 503. The background management server may analyze and process the received traffic recording request and other data, and feed back the processing results (such as recording data - only an example) to the terminal device.
[0101] It should be noted that the traffic recording method provided in the embodiment of the present application is generally executed by the server 505 , and accordingly, the traffic recording device is generally arranged in the server 505 .
[0102] It should be understood that Figure 5 The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to implementation requirements.
[0103] Reference below Figure 6 , which shows a schematic diagram of the structure of a computer system 600 of a terminal device suitable for implementing an embodiment of the present application. Figure 6 The terminal device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.
[0104] like Figure 6 As shown, the computer system 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage part 608 into a random access memory (RAM) 603. In the RAM 603, various programs and data required for the operation of the computer system 600 are also stored. The CPU 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.
[0105] The following components are connected to the I / O interface 605: an input section 606 including a keyboard, a mouse, etc.; an output section 607 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, a modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the I / O interface 605 as needed. A removable medium 611, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 610 as needed, so that a computer program read therefrom is installed into the storage section 608 as needed.
[0106] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 609, and / or installed from the removable medium 611. When the computer program is executed by the central processing unit (CPU) 601, the above-mentioned functions defined in the system of the present application are executed.
[0107] It should be noted that the computer-readable medium shown in the present application may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. Computer-readable storage media may include, for example, but are not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, in which a computer-readable program code is carried. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination of the above.
[0108] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the above-mentioned module, program segment or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.
[0109] The units involved in the embodiments described in the present application may be implemented by software or by hardware. The units described may also be set in a processor. For example, they may be described as: a processor includes a judgment module, a setting module, and a calling module. The names of these modules do not, in some cases, constitute a limitation on the module itself. For example, the judgment module may be described as "a module for judging whether a service is an active recording service in response to a service receiving a traffic access request."
[0110] As another aspect, the present application also provides a computer-readable medium, which may be included in the device described in the above embodiment; or it may exist independently without being assembled into the device. The above computer-readable medium carries one or more programs, and when the above one or more programs are executed by a device, the device includes: in response to a service receiving a traffic access request, determining whether the service is an active recording service; in response to the service being an active recording service, performing traffic recording according to a preset recording strategy and setting a recording identifier for the service; in response to monitoring that the service calls a target service, passing the recording identifier to the target service, so that the target service performs traffic recording in response to the recording identifier.
[0111] The computer program product provided by the embodiment of the present invention includes a computer program, and when the computer program is executed by a processor, the traffic recording method in the embodiment of the present invention is implemented.
[0112] The technical solution according to the embodiment of the present invention has the following advantages or beneficial effects: by responding to the service receiving a traffic access request, determining whether the service is an active recording service; in response to the service being an active recording service, performing traffic recording according to a preset recording strategy and setting a recording identifier for the service; in response to monitoring that the service calls a target service, passing the recording identifier to the target service, so that the target service performs traffic recording in response to the recording identifier; thereby, a recording identifier can be set for the active recording service, and a recording mark can be passed when the active recording service sub-calls other services, so that other services perform traffic recording according to the recording identifier, thereby being able to fully record the complete traffic including the entry and intermediate service sub-calls, thereby improving the user experience.
[0113] The above specific implementations do not constitute a limitation on the protection scope of this application. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of this application should be included in the protection scope of this application.
[0114] It should be noted that the acquisition, storage and application of user personal information involved in the technical solution of the present disclosure are in compliance with the provisions of relevant laws and regulations and do not violate public order and good morals.
Claims
1. A traffic recording method, characterized in that: include: In response to a service receiving a traffic access request, determining whether the service is an active recording service; In response to the service being an active recording service, performing traffic recording according to a preset recording strategy and setting a recording identifier for the service; In response to monitoring that the service calls a target service, the recording identifier is passed to the target service, so that the target service performs traffic recording in response to the recording identifier.
2. The method according to claim 1, characterized in that After setting the recording mark for the service, the method further includes: The recording identifier is stored in the thread context of the current thread; the service calls the target service by calling the child thread; The step of transmitting the recording identifier to the target service includes: Based on a preconfigured thread context transfer mechanism, the recording identifier is copied from the thread context of the current thread to the thread context of the child thread.
3. The method according to claim 2, characterized in that Based on a preconfigured thread context transfer mechanism, copying the recording identifier from the thread context of the current thread to the thread context of the child thread includes: The recording identifier is obtained from the thread context of the current thread, and the recording identifier is encapsulated into an attachment of a remote procedure call request and sent to the thread context of the child thread; wherein the remote procedure call request is a request sent by the service calling the target service.
4. The method according to claim 1, characterized in that Traffic recording is performed according to the preset recording strategy, including: A start instruction is sent to the recording probe of the service based on the remote procedure call framework, so that the recording probe collects the traffic data of the service according to the received start instruction.
5. The method according to claim 1, characterized in that In response to the service receiving the traffic access request, the method further includes: It is determined that the traffic access request hits a pre-configured recording policy.
6. The method according to claim 1, characterized in that The method further comprises: A termination instruction is sent to the service to terminate the service for traffic collection. In response to the time after the service is terminated reaching a preset time threshold, a termination instruction is sent to the target service to terminate the traffic collection of the entire link.
7. A flow recording device, characterized in that: include: A determination module, configured to determine whether the service is an active recording service in response to receiving a traffic access request from the service; A setting module, configured to, in response to the service being an active recording service, perform traffic recording according to a preset recording strategy and set a recording identifier for the service; The calling module is used for transmitting the recording identifier to the target service in response to monitoring that the service calls the target service, so that the target service performs traffic recording in response to the recording identifier.
8. An electronic device, characterized in that: include: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 6.
9. A computer readable medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.
10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.