Activity data monitoring method and device, computer equipment and readable storage medium

Abstract

The invention relates to an activity data monitoring method and device, computer equipment and a readable storage medium. The method comprises the following steps: detecting an external service interface of a request link of an activity request and a service calling interface corresponding to each activity node; obtaining active node data from the interaction data of each service calling interface, and obtaining link input data and link output data from the interaction data of the external service interface; detecting a request identifier of the activity request, a first interface identifier of an external service interface and a second interface identifier of each service calling interface; storing the request identifier, the first interface identifier, the link input data and the link output data in a preset behavior record table in an associated manner, and storing the request identifier, the plurality of second interface identifiers and all the active node data in a preset behavior step detail table in an associated manner; and performing data monitoring on the request link according to the behavior record table and the behavior step detail table. By adopting the method, activity data monitoring can be efficiently carried out.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to an activity data monitoring method, apparatus, computer equipment, and readable storage medium. Background Technology

[0002] With the progress of digital transformation in consumer finance, various types of activities, especially marketing activities, are becoming increasingly important for consumer finance companies. The types of activities are becoming more diversified and the complexity of activities is increasing. Ensuring the smooth operation of multiple activities poses certain challenges. Therefore, it is necessary to monitor data for various types of activities.

[0003] Currently, there are different solutions for each aspect of data monitoring in an event. Taking a marketing campaign as an example, application-oriented methods can be used to collect data monitoring parameters such as interface latency, success rate, and query rate per second. Regression testing relies on automated testing tools to execute historical test cases. User behavior tracking and analysis are customized through hard-coded development. Customer complaints rely on customer service personnel submitting work orders for R&D personnel to query and analyze system logs.

[0004] However, current methods of monitoring activity data are relatively inefficient. Summary of the Invention

[0005] Therefore, it is necessary to provide an efficient method, apparatus, computer equipment, computer-readable storage medium, and computer program product for monitoring activity data, addressing the aforementioned technical problems.

[0006] Firstly, this application provides a method for monitoring activity data, including:

[0007] Obtain the request chain of the activity request, and detect the service call interface corresponding to each activity node in the request chain, as well as the external business interface corresponding to the request chain.

[0008] The activity node data is obtained from the interaction data of each service call interface, and the link input data and link output data are obtained from the interaction data of external business interfaces.

[0009] The system detects the request identifier of the activity request, the first interface identifier of the external business interface, and the second interface identifier of each service call interface.

[0010] The request identifier, the first interface identifier, the link input data, and the link output data are associated and stored in a preset behavior record table, and the request identifier, multiple second interface identifiers, and all active node data are associated and stored in a preset behavior step details table.

[0011] Data monitoring is performed on the request chain based on the behavior record table and behavior step details table.

[0012] Secondly, this application also provides an activity data monitoring device, comprising:

[0013] The interface detection module is used to obtain the request chain of the activity request and detect the service call interface corresponding to each activity node in the request chain, as well as the external business interface corresponding to the request chain.

[0014] The data acquisition module is used to obtain active node data from the interaction data of each service call interface, and to obtain link input data and link output data from the interaction data of external business interfaces.

[0015] The identifier acquisition module is used to detect the request identifier of the activity request, the first interface identifier of the external business interface, and the second interface identifier of each service call interface;

[0016] The data association module is used to associate and store the request identifier, the first interface identifier, the link input data and the link output data in a preset behavior record table, and to associate and store the request identifier, multiple second interface identifiers and all active node data in a preset behavior step details table.

[0017] The data monitoring module is used to monitor the request chain based on the behavior record table and the behavior step details table.

[0018] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described activity data monitoring method.

[0019] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described activity data monitoring method.

[0020] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described activity data monitoring method.

[0021] The aforementioned activity data monitoring method, apparatus, computer equipment, computer-readable storage medium, and computer program product realize an automated activity data monitoring scheme throughout the process. By obtaining activity node data from the interaction data of the service call interface corresponding to each activity node in the request chain, and obtaining the link input data and link output data from the interaction data of the external business interface corresponding to the request chain, and associating the obtained data with the request identifier, the first interface identifier, and the second interface identifier, and storing them in a preset behavior record table and a preset behavior step detail table, the automated collection and updating of monitoring data is realized. Therefore, based on the behavior record table and the behavior step detail table, efficient and real-time data monitoring of the request chain of multiple activity requests can be performed. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is a diagram illustrating the application environment of an activity data monitoring method in one embodiment.

[0024] Figure 2 This is a flowchart illustrating an activity data monitoring method in one embodiment;

[0025] Figure 3 This is a schematic diagram of an interceptor in a specific application embodiment;

[0026] Figure 4 This is a flowchart illustrating the activity data monitoring method in another embodiment;

[0027] Figure 5 A complete flowchart of interface interceptor application under different current network environments in one embodiment;

[0028] Figure 6 A complete flowchart illustrating how an external interface interceptor is applied under different current network environments in one embodiment;

[0029] Figure 7 This is a schematic diagram of a user behavior list example in a specific application embodiment;

[0030] Figure 8 This is a structural block diagram of an activity data monitoring device in one embodiment;

[0031] Figure 9 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of this application.

[0033] The activity data monitoring method provided in this application embodiment can be applied to, for example... Figure 1 In the application environment shown, terminal 102 communicates with activity data monitoring system 104 via a network. The data storage system can store the data that activity data monitoring system 104 needs to process. The data storage system can be integrated into activity data monitoring system 104, or it can be located in the cloud or on another network server.

[0034] The user selects an activity identifier on the activity data monitoring interface of terminal 102 and triggers the activity data monitoring control. Terminal 102 responds to the trigger request of the activity data monitoring control, determines the activity link of the activity identifier, generates an activity request based on the activity link, and sends the activity request to the activity data monitoring system 104. The activity data monitoring system 104 obtains the activity link from the activity request and also uses the activity link as the request link of the activity request. It detects the service call interface corresponding to each activity node in the request link, as well as the external business interface corresponding to the request link. It obtains activity node data from the interaction data of each service call interface, and obtains link input data and link output data from the interaction data of the external business interface. It detects the request identifier of the activity request, the first interface identifier of the external business interface, and the second interface identifier of each service call interface. It associates and stores the request identifier, the first interface identifier, the link input data, and the link output data in a preset behavior record table, and associates and stores the request identifier, multiple second interface identifiers, and all activity node data in a preset behavior step detail table. It monitors the request link based on the behavior record table and the behavior step detail table.

[0035] The terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle systems, and projection devices. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted displays. Head-mounted displays can be virtual reality (VR) devices, augmented reality (AR) devices, and smart glasses. The activity data monitoring system 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0036] In one exemplary embodiment, such as Figure 2 As shown, an activity data monitoring method is provided, which can be applied to... Figure 1 The activity data monitoring system 104 in the example will be used for illustration. Among them:

[0037] S100: Obtain the request chain of the activity request, and detect the service call interface corresponding to each activity node in the request chain, as well as the external business interface corresponding to the request chain.

[0038] The term "activity" can encompass various types of events, such as marketing campaigns, competitions, and cultural and entertainment activities. The request chain is essentially the activity chain, referring to the sum of key information and interrelationships at each stage of an event's entire process, from planning to execution and conclusion. Additionally, "activity" can also refer to an event. Activity nodes in the request chain refer to each key step in the activity process. For example, when the activity is a marketing campaign, activity nodes might include querying database points information, notifying the benefits system to check interest-free coupon inventory information, deducting points from the database, or notifying the benefits system to issue interest-free coupons.

[0039] The external business interface corresponding to the request chain is the interface that external business systems need to call when they want to call the request chain of this activity data monitoring system to perform relevant business operations. The service call interface corresponding to each activity node refers to the interface that needs to call the internal callable sub-service of each activity node in different stages (nodes) of the entire activity process. The internal callable sub-service refers to the subdivided service or tool that each node can call independently to support the completion of specific functions in that stage. The service call interface is generally the interaction interface between internal modules or services of the system and belongs to the internal system dependency. The internal callable sub-service includes at least middleware and downstream application services. The middleware is the "technical bridge" between the activity system and the underlying resources (such as data, network, hardware), providing general technical capabilities. It does not directly carry business logic, but provides basic support for business operation. For example, middleware can be a database, message queue, etc. The downstream application service is the service that directly carries specific business logic. It is usually provided by other systems or teams and provides "business function output" for the activity node. It is strongly related to the actual scenario of the activity. For example, the downstream application service can be payment service, user identity authentication service, etc. External business interfaces and service call interfaces often form an upstream and downstream relationship in an "end-to-end business process". The result of the external business interface call will trigger the execution of the service call interface of the internal callable sub-service, and the execution result of the service call interface of the internal callable sub-service may affect the response of the external business interface.

[0040] Specifically, upon receiving an activity request, the entire process of the activity corresponding to the request is analyzed to obtain the request chain of the activity request. In the request chain, the information flow at each stage often needs to interface with external business systems to obtain data, call functions, or synchronize results. Therefore, it is also necessary to detect the external business systems associated with the request chain. At the same time, in each activity node of the activity chain, there are sub-services or tools that can be independently called to support the activity node in completing specific functions. Therefore, it is also necessary to detect the internal callable sub-services that match each of the multiple activity nodes in each request chain.

[0041] Furthermore, regarding the request chain, when calling each internal callable sub-service, the corresponding internal callable sub-service is called through the service call interface. Therefore, it is necessary to determine the service call interface provided by each internal callable sub-service for calling each internal callable sub-service. In addition, it is also possible to set the external business interface corresponding to each external business system, so that the external business system can use the corresponding external business interface to call the information in this activity data monitoring system to perform related business operations.

[0042] S200 obtains active node data from the interaction data of each service call interface, and obtains link input data and link output data from the interaction data of external business interfaces.

[0043] Specifically, the interaction data of a service call interface is the sum of information transmitted when a certain internal callable sub-service communicates through the interface. It includes the request data sent by the caller and the response data returned by the service provider. Therefore, the activity node data corresponding to each service call interface can be obtained from the interaction data of each service call interface. External business interfaces are the bridge for data interaction between different systems or services, and the input and output parameters are the core carriers of interface interaction. Therefore, the input and output parameters of external business interfaces can be obtained from the interaction data of external business interfaces, which are the link input data and link output data of the request link.

[0044] S300 detects the request identifier of the activity request, the first interface identifier of the external business interface, and the second interface identifier of each service call interface.

[0045] Specifically, in order to associate external business interfaces with activity requests, it is also necessary to detect the request identifier of the activity request and the first interface identifier of the external business interface. In order to associate the activity node data corresponding to each service call interface with the activity request, it is necessary to detect the second interface identifier of each service call interface based on the detection of the request identifier of the activity request.

[0046] S400, the request identifier, the first interface identifier, the link input data and the link output data are associated and stored in a preset behavior record table, and the request identifier, multiple second interface identifiers and all active node data are associated and stored in a preset behavior step details table.

[0047] Specifically, the request identifier of the activity request, the first interface identifier of the external business interface corresponding to the activity request, and the link input data and link output data corresponding to the external business interface are associated, and the associated series of data are stored in the specified log file according to the request identifier of the request link or the first interface identifier of the external business interface. At the same time, the request identifier of the activity request, the second interface identifier of the multiple service call interfaces corresponding to the activity request, and the activity node data corresponding to each service call interface can also be associated, and the associated series of data are stored in the specified log file according to the request identifier of the request link or the second interface identifier of the multiple service call interfaces.

[0048] The log file format is "type#request identifier#user id#interface information#start time#end time#call duration#input parameters#output parameters". The types include "behavior" and "behavior details", corresponding to a preset behavior record table and a preset behavior step details table, respectively. Therefore, the request identifier of the request chain, the first interface identifier of the external business interface, and the corresponding chain input and output data can be associated and stored in the preset behavior record table. Similarly, the request identifier of the request chain, the second interface identifier of multiple service call interfaces, and the activity node data corresponding to each service call interface can be associated and stored in the preset behavior step details table.

[0049] Furthermore, a scheduled task is started, which runs at preset time intervals, such as once every minute, to periodically pull execution log data. The log data is then parsed and written to a MySQL (My Structured Query Language, an open-source relational database) database. The Doris database is used to listen to the binlog of the MySQL database to synchronize the log data to the MySQL database. In particular, since the MySQL database only stores data from the most recent 7 days, historical cold data in the database will be deleted periodically.

[0050] Since the log format is fixed, when the scheduled task parses the log, it only needs to split the string by "#" and then map it to the database table structure according to a fixed mapping structure. Each log record corresponds to one database table record, and the specific data table to be written is determined according to the type.

[0051] Furthermore, in the process of parsing log data and writing it into the database, considering the issues of data volume and real-time data processing, a tiered storage solution is required. For hot data (e.g., data from the last 7 days), it is stored in both MySQL and Doris, leveraging MySQL's transaction features to ensure real-time performance. For cold data (historical data), it is stored in Doris, utilizing its MPP (Massively Parallel Processing) architecture to achieve petabyte-level (Petabyte) data analysis. Specifically, Doris is used to store the full amount of behavioral data, supporting real-time tracking of behavior. By utilizing its MPP architecture to achieve petabyte-level data analysis, both real-time and historical behavior can be analyzed.

[0052] In one embodiment, the behavior log table consists of request identifier, user identifier, interface information, start time, end time, call duration, input parameters, and output parameters. The request identifier is generally a request serial number, which is a unique serial identifier for the current request, used to identify the uniqueness of the request. The user information is a unique identifier of the initiator of the current request, used to identify the unique user identity. The interface information is the information of the currently called interface, i.e., the external business interface information, used to identify the current behavior. The start, end, and duration information refer to the start time, end time, and the difference between the start and end times of this request. The input and output parameters information refer to the input and output parameters of the current call request.

[0053] The behavior step details table consists of request identifier, user identifier, interface information, start time, end time, call duration, input parameters, and output parameter information. The specific description information is the same as that of the behavior record table, except that the interface information is different. The behavior record table corresponds to the external business interface information provided by the current system, while the behavior step details table corresponds to the service call interface of each internal callable sub-service, such as the service call interface of downstream application services or the service call interface of middleware.

[0054] In an exemplary embodiment, a behavior record table and a behavior step detail table are designed to record the complete record and step details of a user's request. The behavior record table stores the input parameter information and result information of the corresponding interface called by the current user; the behavior step detail table stores the process step details of the user calling the corresponding interface. For example, if a user performs a points redemption action, firstly, the database is queried to obtain points information, and then the points quantity is verified according to the database's internal logic conditions. If the database's internal logic conditions are met, the downstream benefits system is queried to obtain interest-free coupon inventory information, and then the interest-free coupon inventory is verified according to the downstream benefits system's internal logic conditions. If the downstream benefits system's internal logic conditions are met, the database points are deducted, and the benefits system is notified to deduct the inventory. Finally, the points redemption output parameter information is returned. The entire process involves two database interactions and two downstream system interactions. Querying the database points information, deducting the database points, querying the benefits system's interest-free coupon inventory information, and notifying the benefits system to issue interest-free coupons are process step details, stored and recorded in the behavior step detail table; the overall result information of the interface is stored in the behavior record table.

[0055] S500 monitors the request chain based on the behavior log table and behavior step details table.

[0056] Specifically, the behavior log table and behavior step detail table store all interface behavior data, user behavior data, and activity-related data. This includes not only information about the request chain of the current activity request, but also information about the request chains of historical activity requests or other current activity requests. Because all behavior data is collected automatically, dynamic expansion of user behavior can be achieved, avoiding the need for hard-coding behavior events and reducing development costs. Furthermore, based on the behavior log table and behavior step detail table, performance analysis, user behavior tracking, and abnormal link analysis of each interface in the current request chain can be performed, thereby enabling data monitoring of the request chain.

[0057] In the above-mentioned activity data monitoring method, activity node data is obtained from the interaction data of the service call interface corresponding to each activity node in the request chain, and link input data and link output data are obtained from the interaction data of the external business interface corresponding to the request chain. The obtained data is associated with the request identifier, the first interface identifier, and the second interface identifier and stored in a preset behavior record table and a preset behavior step detail table. This realizes the automatic collection and updating of monitoring data, and thus enables efficient and real-time data monitoring of the request chain of multiple activity requests based on the behavior record table and the behavior step detail table.

[0058] In an exemplary embodiment, active node data is obtained from the interaction data of each service call interface, and link input data and link output data are obtained from the interaction data of external business interfaces, including:

[0059] Intercept the interaction data of each service call interface to obtain the activity node data of each service call interface; intercept the interaction data of external business interfaces to obtain the link input data and link output data of external business interfaces.

[0060] Intercepting the interaction data of each service call interface refers to performing "mid-process capture, inspection, and control" operations on the interaction data (such as request data and response data) generated by each service call interface. Similarly, intercepting the interaction data of external business interfaces refers to performing "mid-process capture, inspection, and control" operations on the interaction data (such as request data and response data) generated by each external business interface.

[0061] Specifically, the interaction data corresponding to each service call interface and the interaction data corresponding to the external business interface are intercepted separately to obtain the interception results. When intercepting the interaction data corresponding to each service call interface separately, the interception result can be the activity node data corresponding to each service call interface. When intercepting the interaction data corresponding to the external business interface, the interception result can be the link input data and link output data corresponding to the external business interface. In practical applications, interception is implemented through interceptors. Interceptors generally intercept relevant interface methods by adding aspects, that is, through dynamic proxy technology, the execution flow of a specified method is intercepted and enhanced without modifying the target code. In aspect interception, information such as link input data, link output data, time consumption information, and request identifiers of the method call are collected. To ensure the versatility of interception, multiple methods of method interception processing can also be supported. Specific examples are as follows. Figure 3 As shown, the interceptor will intercept the input and output parameters of the external business interface. At the same time, the service call interfaces of the middleware and downstream application services will also be intercepted by the external interceptor. However, the internal logic when calling the middleware and downstream application services will not go through the interception logic.

[0062] Regarding the internal logic, it's important to explain that, for example, when a user completes a loan task, three actions are involved: issuing 100 points, issuing 3 interest-free coupons, and storing the task completion record. Issuing points requires first querying the points account table to obtain account information, then adding points, and finally storing the increased points value in the database. Issuing interest-free coupons requires calling the benefits center to issue coupons. The task completion record needs to be added to its own database. This involves one database query, one database modification, one database write, and one downstream call. All four parts mentioned here are considered service API calls and should be intercepted. However, how the 100 points and 3 interest-free coupons are calculated is internal logic and does not require interception. If the points and coupon issuance logic is refactored, and it's necessary to verify whether the refactored code will cause functional abnormalities, all interactions with middleware and downstream application services can be simulated using mocks. The final result can then be used to verify the functionality's correctness. For example, if there is a problem with the calculation logic and the calculated number of interest-free coupons is 2, then the number of interest-free coupons sent when calling the benefits center will also be 2. Since the mock logic will check whether the parameters are correct, when it finds that the number of interest-free coupons is not 3, it will not return a result, and the final output data of the entire activity chain will also be incorrect.

[0063] In one embodiment, for example, when the activity is a marketing activity, the request chain of the marketing activity includes multiple activity nodes, such as querying the database to obtain points information, querying the downstream benefits system to obtain interest-free coupon inventory information, deducting points from the database and notifying the benefits system to deduct interest-free coupon inventory, etc. Taking querying the database to obtain points information as an example, the interaction data corresponding to each service call interface is intercepted. This means that the interaction data such as user identifier, points identifier, original points information, and points information acquisition result of the node querying the database to obtain points information are intercepted. After intercepting the interaction data corresponding to all service call interfaces, when intercepting the interaction data corresponding to the external business interface, the link output data that can be returned can be the final remaining interest-free coupon inventory, etc., and the corresponding link input data can be the initial interest-free coupon inventory, etc.

[0064] In the above embodiments, by intercepting the interaction data of each service call interface, the active node data of each service call interface can be accurately obtained. By intercepting the interaction data of the external business interface, the link input data and link output data of the external business interface can be accurately obtained.

[0065] In one exemplary embodiment, such as Figure 3 As shown, the interaction data of the external business interface is intercepted to obtain the link input data and link output data of the external business interface, including:

[0066] When a service implementation class in an external business interface is annotated, the interface interceptor intercepts the interaction data corresponding to the annotated service implementation class in the external business interface to obtain the link output data. When a service implementation class in an external business interface is not annotated, the interface interceptor intercepts the interaction data corresponding to all service implementation classes in the external business interface to obtain the link input data and link output data. When a service implementation class in an external business interface is not annotated and no interface interception is performed on the interaction data corresponding to all service implementation classes in the external business interface, the activity request is intercepted according to the preset matching rules of the external business interface to obtain the link input data and link output data.

[0067] An interface interceptor is a component in a software system that automatically intervenes and executes specific logic before an interface call request is sent, after a response is returned, or when an exception occurs. It does not directly modify the core business functionality of the interface, but rather enhances, monitors, controls, or extends the interface interaction by "intercepting" the call process. Essentially, an interface interceptor is a practice of AOP (Aspect-Oriented Programming) principles, primarily addressing cross-cutting concerns related to interface calls.

[0068] The service implementation class is the concrete implementation of the interface, responsible for handling business logic. For example, a service implementation class can be a local service (a service directly called by a local controller, such as `@RestController`) or a remote service (marked with annotations like `@DubboService`). `@DubboService` is an annotation provided by the Apache Dubbo framework, used to declare a Java class as a provider of Dubbo services (i.e., the service implementation class). Through this annotation, the service implementation class is registered with the Dubbo service registry for remote invocation by other services (consumers). `@RestController` is an annotation provided by the Spring Framework, used to declare a controller class as a RESTful web service. It is a combination of `@Controller` and `@ResponseBody` annotations, indicating that all methods of this class will automatically serialize the returned objects into response bodies in formats such as JSON / XML.

[0069] Specifically, the system detects the type of the external business interface corresponding to the request chain. Based on the type of the external business interface, an interface interceptor is used to intercept the interaction data corresponding to the external business interface in a way that matches the type of the external business interface. The type of external business interface can be a remote procedure call interface, or a resource state transfer and unified processing interface, etc.

[0070] When the external business interface is a Remote Procedure Call (RPC) interface, Spring AOP's global interception capabilities are leveraged to intercept all RPC requests through interface interception. Taking the Dubbo framework as an example, the code `@Pointcut("@within(org.apache.dubbo.config.annotation.DubboService)")` matches all methods in classes annotated with `@org.apache.dubbo.config.annotation.DubboService` (regardless of method access modifiers, return types, or parameters). By matching the `@DubboService` annotation on the methods, the interaction data corresponding to the service implementation class annotated with `@DubboService` in the RPC interface is intercepted. Intercepting the interaction data essentially involves intercepting the input and output data of the connection. After interception, the input and output data can be recorded within the interception method. More specifically, when an activity request is sent to an external business interface, the interface interceptor intercepts the activity request, obtains the link input data of the activity request, and records the start time, request identifier, and user identifier, where the request identifier and user identifier are part of the request input parameters. Then, the request is directly forwarded to the actual link to execute the real RPC request. After obtaining the call result, the return result of the external business interface is intercepted again by the interface interceptor to obtain the link output data of the activity request, record the end time, and calculate the time consumption information. Finally, a user behavior record is generated, and the corresponding record log is output to the log file. The user behavior record includes the request identifier, user identifier, start time, end time, time consumption information, link input data, and link output data.

[0071] The Remote Procedure Call Interface (RPC) is a communication protocol or interface specification that allows one computer (client) to call a program or function on another computer (server) over a network, just like calling a local program. It hides the low-level details of network communication (such as data transmission and address resolution), so that developers do not need to handle network programming manually, but only need to call remote functions according to the interface definition.

[0072] When the external business interface is a Resource State Transfer and Unified Processing REST interface, if there are service implementation classes marked with annotations in the Resource State Transfer and Unified Processing REST interface, the interaction data corresponding to the annotated service implementation classes can be intercepted directly. The annotation can be @RestController. The processing logic after interception is the same as that of the RPC interface. That is, by using the interface interceptor, the interaction data corresponding to the service implementation classes marked with @RestController in the Resource State Transfer and Unified Processing interface is intercepted to obtain the link input data and link output data.

[0073] Among them, the resource state transfer and unified processing interface refers to the REST (Representational State Transfer) interface. Resource state transfer and unification are core ideas in the REST architectural style. Resource state transfer refers to the client modifying the state of the server-side resources by manipulating the representation of the resources (such as JSON and XML). The essence of the interaction is the transfer and transformation of "resource state" between the client and the server. Unification means that the interaction between the client and the server follows a set of unified, predefined rules and standards, so that the interface has consistency, predictability and universality, reducing system complexity and improving compatibility.

[0074] For scenarios where annotations are not used, i.e., when the service implementation classes in the external business interface are not marked with annotations, in order to cover all application scenarios, an interface interceptor can be used to intercept the interaction data corresponding to all service implementation classes in the external business interface, and obtain the input and output data of the link. For example, there is a message processing interface MessageProcessInterface, and all message processing services in the system are implemented by implementing the MessageProcessInterface interface. At this time, there are no annotations on each service. This can be achieved by interface interception. The code used can be @Pointcut("execution(* com.yourpackage.MessageProcessInterface+.*(..))"), which matches all methods of all implementation classes of the MessageProcessInterface interface under the com.yourpackage package (regardless of method access modifiers, return types, or parameters).

[0075] When the service implementation classes in the external business interface are not annotated and no interface interception is performed on the interaction data corresponding to all service implementation classes in the external business interface, interception can be performed by specifying a path. That is, according to the preset matching rules of the external business interface, the activity request is intercepted to obtain the link input data and link output data. A specific example is: @Pointcut("execution(public * com.example.service..*.*(..))"), which matches all public methods in the com.example.service package and its sub-packages, regardless of the method name, return type or parameters.

[0076] In the above embodiments, an automated user behavior collection scheme is implemented, which supports data collection schemes for interactive data corresponding to external business interfaces that are interface-oriented, annotation-oriented, and path-oriented. This scheme covers all business scenarios, achieves automated data collection, and ensures that the business code is unaware of the data, minimizing code invasiveness.

[0077] In an exemplary embodiment, the service call interface includes at least the service call interface of the downstream application service and the service call interface of the middleware; the interaction data of each service call interface is intercepted to obtain the activity node data of each service call interface, including:

[0078] For each service call interface, when the service call interface is a remote procedure call interface of a downstream application service, an external interface interceptor is used to intercept the service implementation classes marked with annotations in each remote procedure call interface to obtain activity node data; when the service call interface is a service call interface of a downstream application service and is not a remote procedure call interface, the service call interface is defined as a resource state transfer and unified processing interface, and an external interface interceptor is used to intercept the interaction data corresponding to all service implementation classes in the resource state transfer and unified processing interface to obtain activity node data; when the service call interface is a service call interface of middleware, requests to access the service call interface are intercepted according to the preset matching rules of the middleware's service call interface to obtain activity node data.

[0079] The service call interface is the interface used when calling internal callable sub-services. Internal callable sub-services include downstream application services or middleware, and the service call interface includes at least the service call interface of the downstream application service and the service call interface of the middleware.

[0080] Specifically, the system detects the type of the service call interface corresponding to the request chain. Based on the type of each service call interface, an external interface interceptor is used to intercept the interaction data corresponding to the service call interface in a way that matches the type of the service call interface. In practical applications, the interception principle of the external interface interceptor is similar to that of the interface interceptor, but the annotations used for interception are different, and the interception methods also differ in different internal callable sub-service scenarios, such as in scenarios where data interception is performed on service call interfaces corresponding to downstream application services or middleware.

[0081] When the service call interface is a Remote Procedure Call (RPC) interface for a downstream application service, Spring AOP's global interception capabilities are leveraged to intercept all downstream RPC requests via annotation-based interception. Specifically, an external interface interceptor intercepts the interaction data corresponding to the service implementation class annotated with `@DubboReference` in each RPC interface, obtaining the activity node data for that RPC interface. Taking the Dubbo framework as an example, the interception code could be `@Pointcut("@annotation(org.apache.dubbo.config.annotation.DubboReference)")`, matching all methods annotated with `@org.apache.dubbo.config.annotation.DubboReference`. `@DubboReference` is an annotation provided by the Apache Dubbo framework used to inject remote Dubbo services, enabling the current service (consumer) to invoke methods of the remote service provider as if they were local methods. Through this annotation, Dubbo automatically discovers and connects to the service provider from the registry, completing the underlying communication for remote calls.

[0082] When the service call interface is the service call interface of the downstream application service and is not a remote procedure call interface, that is, if the downstream application service does not provide a remote procedure call (RPC) interface, a resource state transition and unified processing (REST) ​​interface can be defined. All service implementation classes that involve calling the REST interface of the downstream application service need to follow the contract defined by the REST interface and provide concrete implementations of all methods declared in the interface. At this time, by using an external interface interceptor, the interaction data corresponding to all service implementation classes in the resource state transition and unified processing interface can be intercepted to obtain the activity node data corresponding to the resource state transition and unified processing interface.

[0083] When the service call interface is a middleware service call interface, such as an interaction interface with a database or other middleware, it can be intercepted by specifying a path. That is, according to the preset matching rules of the middleware service call interface, the request to access the middleware service call interface is intercepted to obtain the activity node data corresponding to the middleware service call interface.

[0084] The above embodiments implement an automated user behavior collection scheme that supports collection schemes for interactive data corresponding to service call interfaces oriented towards interfaces, annotations, and paths. This covers all business scenarios, achieves automated data collection, and ensures that the business code is unaware of the data, minimizing code invasiveness.

[0085] In one exemplary embodiment, such as Figure 4 As shown, after S500, the method also includes:

[0086] S620 synchronizes the behavior record table and behavior step detail table to the test environment, and generates a test case record table that matches the behavior record table and a test case step detail table that matches the behavior step detail table in the test environment.

[0087] S640, in the current network environment as a test environment, when a test case request for the target request link is detected, it determines whether the test case request needs to perform request backtracking based on the test case record table, or determines whether the test service call interface corresponding to the multiple test activity nodes corresponding to the test case request needs to simulate interface logic based on the test case step details table.

[0088] S660: If the test case request indicates that the execution request backtracking is required, the test case request is forwarded to the external business interface corresponding to the test case request to execute the test case request, obtain the execution result, and determine whether the execution result is accurate according to the test case record table.

[0089] S680, if there is a test service call interface that needs to simulate interface logic, then simulate the test service call interface of the corresponding callable test sub-service, and in the process of intercepting the interaction data corresponding to each simulated test service call interface, obtain the active node test data corresponding to each simulated test service call interface according to the test case step details table.

[0090] In software engineering (especially in the fields of requirements analysis and testing), a use case is a description of the interaction process between a system and external stakeholders, used to clarify the behavior and functional boundaries of the system in a specific scenario.

[0091] Specifically, data monitoring of the request chain for activity requests is conducted in a real, customer-facing production environment. After monitoring the request chain based on the behavior log table and behavior step detail table, detailed and complete behavior data can be recorded. If backtracking of the behavior data is required, the behavior log table and behavior step detail table can be synchronized to the test environment to generate a test case log table matching the behavior log table and a test case step detail table matching the behavior step detail table in the test environment. The test case log table and test case step detail table have the same table structure, and the fields include request identifier, user identifier, interface information, input parameters, output parameters, etc.

[0092] It should be noted that the production environment and the testing environment are isolated from each other. It is impossible to trace back all the behaviors in the production environment in the testing environment. Therefore, it is necessary to select a very small number of behavior records and behavior steps from the behavior record table and behavior step details table for backtracking. These selected behavior records and behavior steps details can form a series of test case data. Then, the test case data is synchronized to the testing environment for backtracking in the testing environment.

[0093] Next, it checks whether the current network environment is a test environment. If the current network environment is a test environment, when a test case request for the target request chain is detected, firstly, according to the test case record table, it checks whether there is a relevant record in the test case record table indicating that the request corresponding to the test case request is a request that needs to be backtracked. If so, it is determined that the test case request needs to perform request backtracking. Alternatively, it can also check whether there is a relevant record in the test case step details table indicating whether the test service call interfaces corresponding to the multiple test activity nodes of the test case request need to simulate interface logic. If so, it is determined whether the test service call interfaces with records need to simulate interface logic.

[0094] If the test case request indicates that request backtracking needs to be performed, the test case request is forwarded to the external business interface corresponding to the test case request to execute the test case request, obtain the execution result, and query the link output result corresponding to the request identifier of the test case request from the test case record table. Based on the comparison between the link output result and the execution result, it is determined whether the execution result is accurate, that is, whether the behavior of the external business interface meets expectations.

[0095] If there is a test service call interface that requires simulating interface logic, then the test service call interface of the corresponding callable test sub-service is simulated. During the process of intercepting the interaction data corresponding to each simulated test service call interface, the test data of the activity node corresponding to each simulated test service call interface is queried according to the test case step details table to return the output parameter result of the simulated test service call interface. In this way, the request processing can be completed efficiently and controllably without relying on real business logic or external resources.

[0096] It's important to explain that mock interface logic is essentially the same as mock logic. Mock logic refers to alternative logic written during software development, testing, or debugging to simulate the behavior of real objects (such as services, interfaces, components, etc.). It doesn't rely on real external resources or systems but simulates the interaction process of real objects in specific scenarios by pre-setting fixed return values, response data, or behavioral patterns. This isolates the code under test from external dependencies, ensuring the independence, stability, and efficiency of the testing or development process. For example, when testing an order system that relies on a payment interface, mock logic can simulate the "payment successful" or "payment failed" responses of the payment interface without calling the real payment service, thereby verifying whether the order system's processing logic is correct under different payment results.

[0097] Specifically, in complex system testing, a sub-step (such as internal service A calling service call interface B) may depend on external resources (such as databases or third-party services) or be subject to unstable factors (such as network fluctuations). Therefore, mock logic can be used to simulate multiple service call interfaces, and the interaction data corresponding to each mock service call interface can be intercepted to obtain the activity node data corresponding to each service call interface. This can isolate external dependencies, avoid test interruptions due to dependency unavailability, and improve testing efficiency without waiting for the complete execution of the real link.

[0098] In one embodiment, during the behavioral data collection step, an interface interceptor can be used to intercept and process interactive data in external business interfaces, thereby enabling the interception and processing of interactive data in service call interfaces. Modifications are made to these two interceptors; the modifications to each interceptor are described in detail below.

[0099] 1. Modify the interface interceptor.

[0100] A complete flowchart illustrating how interface interceptors are applied under different current network environments is shown below. Figure 5As shown, the current network environment is determined. If it is a production environment, the start time and input parameters are recorded. After interception and forwarding, the end time and output parameters are recorded. The data collection logic is executed to generate a behavior record. For details, refer to the above embodiment for the content of storing data in the behavior record table and behavior step details table. If it is a test environment, the request backtracking logic is executed.

[0101] In a test environment, firstly, based on the request identifier of the test case request, such as the request serial number, query the test case record table. If a relevant record exists, it indicates that the current request needs to be backtracked. Then, forward the test case request to the corresponding external business interface to execute the logic, and verify and compare the execution result with the output parameter information in the test case record table, and output the verification result. If no relevant record exists, it indicates that it is a normal test environment test request, and there is no need to request backtracking. Just forward it to the actual link without verification.

[0102] Furthermore, to facilitate querying the backtracking results and analyzing the causes of anomalies, a backtracking result table can be designed to store the results of each verification. The backtracking record table includes execution time, test case identifier, execution result, and exception details. The test case identifier represents the primary key identifier of the test case record table, and the execution result represents the result of this backtracking. The result has two states: success and failure. If it is a failure state, the exception details data needs to be stored in the exception details field.

[0103] 2. Modification of external interface interceptor.

[0104] The following is a complete flowchart illustrating how external interface interceptors are applied under different current network environments. Figure 6 As shown, the current network environment is determined. If it is a production environment, the start time and input parameters are recorded. After interception and forwarding, the end time and output parameters are recorded. The data collection logic is executed to generate a behavior record. For details, refer to the above embodiment for the content of storing data in the behavior record table and behavior step details table. If it is a test environment, the data mock logic is executed.

[0105] If it is a test environment, first query the test case step details table. If relevant data exists, it means that the current request is a request that needs to be mocked. Then, the forwarding execution logic will not be performed. Instead, the active node test data in the test case step record table will be matched with the input parameter information in the test case request, that is, the preset output parameters will be obtained and the output parameter information will be returned. If no user record exists, it means that it is a normal test environment test request, and it can be forwarded directly to the actual link.

[0106] In one embodiment, the method for selecting a small portion of user behavior data from the behavior record table and behavior step details table for backtracking can be either manual or automated filtering, ensuring sufficient scalability and flexibility. Automated filtering refers to random filtering by interface, for example, randomly selecting 10 behavior records for each interface. Manual filtering refers to filtering representative behavior data by requesting serial numbers or user identifiers. By using both collection methods, it is possible to ensure that the backtracking use case data covers all business scenarios as much as possible.

[0107] In one embodiment, determining whether the current network environment is a production or test environment can be achieved by setting an environment variable ENV (or a similar name) in the system or container, and reading its value at runtime. The code would look like this: String env = System.getenv("ENV"); if ("prod".equals(env)) {… / / Production environment logic} elseif ("test".equals(env)) { … / / Test environment logic}.

[0108] In the above embodiments, all test cases are currently derived directly from production data, supporting both automatic and manual screening of test cases. This ensures the reliability, stability, and authenticity of test cases as much as possible. Furthermore, the use of test case backtracking avoids the impact of upstream and downstream systems on the test environment, preventing instability in upstream and downstream systems from causing test progress blockages and greatly improving testing efficiency.

[0109] In an exemplary embodiment, data monitoring of the request chain is performed based on the behavior log table and the behavior step details table, including:

[0110] From the behavior log table, detect the first statistical information of multiple first interface identifiers associated with the same request identifier, and the second statistical information of multiple request identifiers associated with the same first interface identifier; from the behavior step details table, detect the third statistical information of the second interface identifier associated with the same request identifier, and the fourth statistical information of multiple request identifiers associated with the same second interface identifier; based on the first statistical information, the second statistical information, the third statistical information and the fourth statistical information, perform data monitoring on the request chain.

[0111] Specifically, based on the data collected from the behavior record table and the behavior step details table, statistical analysis can be performed according to the interface dimension or the activity dimension. When performing statistical analysis according to the activity dimension, the first statistical information of multiple first interface identifiers associated with the same request identifier can be detected from the behavior record table, and the third statistical information of the second interface identifier associated with the same request identifier can be detected from the behavior step details table. When performing analysis according to the interface dimension, the second statistical information of multiple request identifiers associated with the same first interface identifier can be detected from the behavior record table, and the fourth statistical information of multiple request identifiers associated with the same second interface identifier can be detected from the behavior step details table.

[0112] More specifically, since the behavior log table records external business interface information, statistics can be directly performed based on this information to analyze the time consumption, qps (queries per second), and success rate of each external business interface, thus obtaining an overall picture of the external business interfaces. Furthermore, since the behavior log table records activity identifiers and interface information, statistics can be directly performed based on the activity identifiers to analyze the time consumption, qps, and success rate of each external business interface at the activity level, thus obtaining activity-level statistical information.

[0113] Since the behavior step details table records interface information, statistics can be directly performed based on the interface information to analyze the time consumption, QPS, and success rate of each service call interface, thus obtaining the overall situation of each service call interface. Since the behavior step details table records activity ID and service call interface information, statistics can be performed based on activity identifiers to analyze the list of service call interfaces involved in each activity, as well as the time consumption, QPS, and success rate of each service call interface, thus obtaining activity-level statistical information.

[0114] After obtaining the above statistical information, a comprehensive data monitoring of the request chain can be carried out based on the above statistical information.

[0115] In the above embodiments, by considering the behavior record table and behavior step details table from two dimensions—activity dimension and interface dimension—user behavior data can be analyzed accurately and automatically, and the interface information involved in a certain activity and the individual statistical data information of each interface can be statistically analyzed.

[0116] In an exemplary embodiment, the behavior record table and the behavior step detail table also include a user identifier associated with the request link; based on the behavior record table and the behavior step detail table, data monitoring of the request link is performed, including:

[0117] From the behavior record table and behavior step details table, query the user behavior records that match the user identifier and the behavior details of each user behavior record; based on the user behavior records and behavior details, locate the abnormal activity nodes in the request chain.

[0118] Specifically, based on the user identifier, the user behavior records corresponding to the user identifier can be retrieved from the behavior record table and displayed and analyzed as a Timeline. Furthermore, based on the request identifiers of multiple activity requests corresponding to the retrieved user behavior records, the behavior detail information corresponding to the request identifiers can be retrieved from the behavior step detail table. Simultaneously, the start time, end time, duration, input parameters, and output parameters of each activity node can be displayed. For example... Figure 7 The image shows an example of a user's actions, including browsing a page, purchasing points, redeeming points, and repaying points.

[0119] Based on user behavior records and behavior details, locate abnormal activity nodes among multiple activity nodes in the request chain.

[0120] Furthermore, when data anomalies are discovered through customer complaints, user behavior can be tracked using user identifiers. This involves querying the behavior record table and behavior step details table to find user behavior records matching the user identifiers and the behavior details of each user behavior record. Then, based on the time range specified by the user, the corresponding target user behavior records and the behavior details of each target user behavior record can be quickly filtered to rapidly locate the abnormal link. Customer service personnel can quickly locate the specific problem based on the user's behavior data, which can solve most production problems and reduce the time cost for R&D personnel.

[0121] In the above embodiments, when customer complaints arise, customer service personnel can directly track user behavior, quickly locate customer behavior issues, and independently resolve most marketing customer complaints, thereby greatly reducing the time spent by R&D personnel to troubleshoot production problems.

[0122] The activity data monitoring method of this application will now be described in detail using a specific embodiment, including:

[0123] When a user redeems points, the system first queries the database to retrieve points information, then verifies the number of points. If the conditions are met, it queries the downstream benefits system to retrieve the inventory information of interest-free coupons, then verifies the inventory of interest-free coupons. If the conditions are met, the system deducts points from the database and notifies the benefits system to deduct the inventory. Finally, it returns the points redemption parameters.

[0124] At this point, you can intercept relevant interface methods by adding aspects. Aspect-based interception will collect information such as the method call's input parameters, output parameters, result, execution time, and request serial number. To ensure the versatility of interception, multiple methods for method interception are supported. This will intercept the input and output parameters of external business interfaces, as well as service calls involving middleware and downstream application services. As before... Figure 3 As shown, the entire external interface will be intercepted by the interceptor to obtain the link input data and link output data corresponding to the external business interface. At the same time, the three internal sub-steps will also be intercepted by the interceptor to obtain the activity node data corresponding to each service call interface. The internal logic will not go through the interception logic.

[0125] After interception, the collected data is stored in the database. Based on the interception results, the preset behavior record table is updated in combination with the request identifier of each activity request and the first interface identifier of each external business interface. Based on the interception results, the preset behavior step details table is updated in combination with the request identifier of each activity request and the second interface identifier of each service call interface.

[0126] For the updated behavior log table and updated behavior step details table, data filtering is supported in both random and manual modes. The filtered data is then synchronized to the test environment for interface testing. For service calls to sub-steps, mock logic is used to intercept all service calls, preventing direct execution of the call logic. Output parameters are automatically matched based on input parameters and returned via deserialization. For external business interfaces, a verification logic is used to compare the actual returned results with the original collected results to determine the accuracy of the external business interface's behavior.

[0127] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0128] Based on the same inventive concept, this application also provides an activity data monitoring device for implementing the activity data monitoring method described above. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations in one or more activity data monitoring device embodiments provided below can be found in the limitations of the activity data monitoring method described above, and will not be repeated here.

[0129] In one exemplary embodiment, such as Figure 8 As shown, an activity data monitoring device is provided, including: an interface detection module 100, a data acquisition module 200, an identifier acquisition module 300, a data association module 400, and a data monitoring module 500, wherein:

[0130] The interface detection module 100 is used to obtain the request chain of the activity request and detect the service call interface corresponding to each activity node in the request chain, as well as the external business interface corresponding to the request chain.

[0131] The data acquisition module 200 is used to acquire active node data from the interaction data of each service call interface, and to acquire link input data and link output data from the interaction data of external business interfaces.

[0132] The identifier acquisition module 300 is used to detect the request identifier of the activity request, the first interface identifier of the external business interface, and the second interface identifier of each service call interface;

[0133] The data association module 400 is used to associate and store the request identifier, the first interface identifier, the link input data and the link output data in a preset behavior record table, and to associate and store the request identifier, multiple second interface identifiers and all active node data in a preset behavior step detail table.

[0134] The data monitoring module 500 is used to monitor the request chain based on the behavior record table and the behavior step details table.

[0135] In one embodiment, the data acquisition module 200 is further configured to intercept the interaction data of each service call interface to obtain the active node data of each service call interface; and to intercept the interaction data of the external business interface to obtain the link input data and link output data of the external business interface.

[0136] In one embodiment, the data acquisition module 200 is further configured to, when a service implementation class in an external business interface is annotated, use an interface interceptor to intercept the interaction data corresponding to the service implementation class annotated in the external business interface and obtain the link output data.

[0137] When the service implementation classes in the external business interface are not marked with annotations, the interface interceptor is used to intercept the interaction data corresponding to all service implementation classes in the external business interface to obtain the link input data and link output data. When the service implementation classes in the external business interface are not marked with annotations and the interface interception is not performed on the interaction data corresponding to all service implementation classes in the external business interface, the activity request is intercepted according to the preset matching rules of the external business interface to obtain the link input data and link output data.

[0138] In one embodiment, the service call interface includes at least the service call interface of the downstream application service and the service call interface of the middleware. The data acquisition module 200 is further configured to, for each service call interface, when the service call interface is a remote procedure call interface of the downstream application service, use an external interface interceptor to intercept the service implementation classes marked with annotations in each remote procedure call interface to obtain active node data; when the service call interface is a service call interface of the downstream application service and is not a remote procedure call interface, define the service call interface as a resource state transfer and unified processing interface, and use an external interface interceptor to intercept the interaction data corresponding to all service implementation classes in the resource state transfer and unified processing interface to obtain active node data; when the service call interface is a service call interface of the middleware, intercept the requests to access the service call interface according to the preset matching rules of the middleware service call interface to obtain active node data.

[0139] In one embodiment, the activity data monitoring device further includes a backtracking module. This module synchronizes the behavior record table and behavior step detail table to the test environment, and generates a test case record table matching the behavior record table and a test case step detail table matching the behavior step detail table in the test environment. When the current network environment is a test environment, upon detecting a test case request for the target request link, the module determines whether the test case request needs to perform request backtracking based on the test case record table, or whether the test service call interfaces corresponding to the multiple test activity nodes corresponding to the test case request need to simulate interface logic based on the test case step detail table. If the test case request indicates that request backtracking needs to be performed, the test case request is forwarded to the external business interface corresponding to the test case request to execute the test case request, obtain the execution result, and determine whether the execution result is accurate based on the test case record table. If there is a test service call interface that needs to simulate interface logic, the corresponding test service call interface is simulated, and during the interception of the interaction data corresponding to each simulated test service call interface, the activity node test data corresponding to each simulated test service call interface is obtained based on the test case step detail table.

[0140] In one embodiment, the data monitoring module 500 is further configured to detect first statistical information of multiple first interface identifiers associated with the same request identifier and second statistical information of multiple request identifiers associated with the same first interface identifier from the behavior record table; detect third statistical information of second interface identifiers associated with the same request identifier and fourth statistical information of multiple request identifiers associated with the same second interface identifier from the behavior step details table; and perform data monitoring on the request chain based on the first statistical information, second statistical information, third statistical information and fourth statistical information.

[0141] In one embodiment, the behavior record table and the behavior step details table also include user identifiers associated with the request link; the data monitoring module 500 is also used to query user behavior records matching the user identifier and behavior details information of each user behavior record from the behavior record table and the behavior step details table; and to locate abnormal activity nodes in the request link based on the user behavior records and behavior details information.

[0142] Each module in the aforementioned activity data monitoring device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of a computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0143] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 9 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores relevant data for request chains of multiple active requests. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When executed by the processor, the computer program implements an activity data monitoring method.

[0144] Those skilled in the art will understand that Figure 9The structure shown is a block diagram of a partial structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0145] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0146] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0147] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0148] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0149] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0150] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0151] The above embodiments merely illustrate several implementation methods of this application, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of this application's patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for monitoring activity data, characterized in that, The method includes: Obtain the request chain of the activity request, and detect the service call interface corresponding to each activity node in the request chain, as well as the external business interface corresponding to the request chain; Active node data is obtained from the interaction data of each of the service call interfaces, and link input data and link output data are obtained from the interaction data of the external business interfaces. The request identifier of the activity request, the first interface identifier of the external business interface, and the second interface identifier of each service call interface are detected. The request identifier, the first interface identifier, the link input data, and the link output data are associated and stored in a preset behavior record table, and the request identifier, multiple second interface identifiers, and all the activity node data are associated and stored in a preset behavior step detail table. Data monitoring is performed on the request chain based on the behavior record table and the behavior step details table.

2. The method according to claim 1, characterized in that, The steps of obtaining active node data from the interaction data of each service call interface and obtaining link input data and link output data from the interaction data of the external business interface include: Intercept the interaction data of each of the service call interfaces to obtain the activity node data of each of the service call interfaces; Intercept the interaction data of the external business interface to obtain the link input data and link output data of the external business interface.

3. The method according to claim 2, characterized in that, The interception of interaction data from the external business interface to obtain the link input data and link output data of the external business interface includes: When a service implementation class is annotated in the external business interface, the interface interceptor is used to intercept the interaction data corresponding to the annotated service implementation class in the external business interface to obtain the link output data. When the service implementation class in the external business interface is not marked with annotation, the interface interceptor is used to intercept the interaction data corresponding to all service implementation classes in the external business interface to obtain the link input data and link output data. When the service implementation class in the external business interface is not marked with annotations and no interface interception is performed on the interaction data corresponding to all service implementation classes in the external business interface, the activity request is intercepted according to the preset matching rules of the external business interface to obtain the link input data and link output data.

4. The method according to claim 2, characterized in that, The service call interface includes at least the service call interface of the downstream application service and the service call interface of the middleware. The step of intercepting the interaction data of each service call interface to obtain the activity node data of each service call interface includes: For each of the service call interfaces, when the service call interface is a remote procedure call interface of the downstream application service, the external interface interceptor is used to intercept the service implementation class marked with annotation in each remote procedure call interface to obtain the active node data. When the service call interface is the service call interface of the downstream application service and is not a remote procedure call interface, the service call interface is defined as a resource state transfer and unified processing interface, and an external interface interceptor is used to intercept the interaction data corresponding to all service implementation classes in the resource state transfer and unified processing interface to obtain the activity node data. When the service call interface is the service call interface of the middleware, the requests to access the service call interface are intercepted according to the preset matching rules of the middleware's service call interface to obtain the active node data.

5. The method according to claim 1, characterized in that, After monitoring the request chain based on the behavior record table and the behavior step details table, the method further includes: The behavior record table and the behavior step detail table are synchronized to the test environment, and a use case record table matching the behavior record table and a use case step detail table matching the behavior step detail table are generated in the test environment. In the current network environment being a test environment, when a test case request for the target request link is detected, the test case request is determined according to the test case record table to determine whether request backtracking needs to be performed, or, according to the test case step details table, the test service call interfaces corresponding to the multiple test activity nodes corresponding to the test case request need to simulate interface logic. If the test case request indicates that request backtracking needs to be performed, the test case request is forwarded to the external business interface corresponding to the test case request to execute the test case request, obtain the execution result, and determine whether the execution result is accurate according to the test case record table; If the test service call interface requires simulated interface logic, then the corresponding test service call interface is simulated. During the process of intercepting the interaction data corresponding to each simulated test service call interface, the activity node test data corresponding to each simulated test service call interface is obtained according to the test case step details table.

6. The method according to claim 1, characterized in that, The step of monitoring the request chain based on the behavior record table and the behavior step details table includes: From the behavior record table, detect the first statistical information of multiple first interface identifiers associated with the same request identifier, and the second statistical information of multiple request identifiers associated with the same first interface identifier; From the behavior step details table, detect the third statistical information of the second interface identifier associated with the same request identifier, and the fourth statistical information of multiple request identifiers associated with the same second interface identifier; The request link is monitored based on the first, second, third, and fourth statistical information.

7. The method according to claim 1, characterized in that, The behavior record table and the behavior step details table also include the user identifier associated with the request link; the step of monitoring the request link based on the behavior record table and the behavior step details table includes: From the behavior record table and the behavior step details table, query the user behavior record that matches the user identifier and the behavior details information of each user behavior record; Based on the user behavior records and behavior details, the abnormal activity nodes in the request chain are located.

8. An activity data monitoring device, characterized in that, The device includes: The interface detection module is used to obtain the request chain of the activity request, and detect the service call interface corresponding to each activity node in the request chain, as well as the external business interface corresponding to the request chain. The data acquisition module is used to acquire active node data from the interaction data of each of the service call interfaces, and to acquire link input data and link output data from the interaction data of the external business interfaces. The identifier acquisition module is used to detect the request identifier of the activity request, the first interface identifier of the external business interface, and the second interface identifier of each service call interface; The data association module is used to associate and store the request identifier, the first interface identifier, the link input data and the link output data in a preset behavior record table, and to associate and store the request identifier, multiple second interface identifiers and all the activity node data in a preset behavior step detail table; The data monitoring module is used to monitor the request chain based on the behavior record table and the behavior step details table.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images