Transaction monitoring method and device, equipment and storage medium

Abstract

The invention discloses a transaction monitoring method, device and equipment and a storage medium, and relates to the technical field of information processing, and the transaction monitoring method comprises the steps: obtaining the request time, response time and real-time performance index value of a transaction interface; inputting the interface type of the transaction interface, the request time, the response time and the real-time performance index value into a transaction response duration prediction model to obtain an actual business processing duration and an expected processing duration range output by the transaction response duration prediction model; and based on the interface type, the actual business processing duration and the expected processing duration range, determining whether to carry out transaction alarm. According to the method and the device, the accuracy of transaction response monitoring is improved by realizing the functions of real-time monitoring of the response duration, customized alarm and the like, and meanwhile, all transaction interfaces are monitored, so that the incomprehensiveness of sampling inspection is avoided, the false alarm and the missing alarm are reduced, and personalized alarm is realized.

Description

Technical Field

[0001] The present application relates to the field of information processing technology, and in particular to a transaction monitoring method, device, equipment and storage medium. Background Art

[0002] In payment transactions, the response time of the transaction interface is an important factor affecting transaction efficiency and user satisfaction. With the continuous expansion of merchant business, the number of users is increasing day by day, and the transaction volume is also growing rapidly. The stability and response speed of the transaction interface provided by banks to merchants are crucial to merchant experience and transaction security. However, traditional monitoring methods rely on sampling or estimation, resulting in low accuracy. For example, only monitoring part of the transactions or using rough timing methods cannot accurately reflect the actual transaction response time, and it relies on manual sampling or simple monitoring tools, which cannot fully and accurately monitor the response time of all transactions. For example, for a large number of concurrent transactions, spot-checking and monitoring part of the transactions will result in incomplete monitoring results. Summary of the invention

[0003] The main purpose of this application is to provide a transaction monitoring method, device, equipment and storage medium, aiming to solve the technical problems of low accuracy and incomplete monitoring in traditional methods.

[0004] To achieve the above objectives, the present application proposes a transaction monitoring method, which comprises:

[0005] Obtain the request time, response time and real-time performance index values ​​of the transaction interface;

[0006] Inputting the interface type of the transaction interface, the request time, the response time and the real-time performance index value into a transaction response time prediction model to obtain an actual business processing time and an expected processing time range output by the transaction response time prediction model;

[0007] Whether to issue a transaction alarm is determined based on the interface type, the actual business processing time, and the expected processing time range.

[0008] In one embodiment, the training process of the transaction response time prediction model includes:

[0009] Obtain several groups of interface types, historical business processing durations, and historical performance indicator values;

[0010] Vectorizing each of the interface types, the historical service processing duration, and the historical performance indicator value;

[0011] The vectorized interface types, historical business processing durations, and historical performance indicator values ​​are input into an initial transaction response duration prediction model for iterative training to obtain the transaction response duration prediction model.

[0012] In one embodiment, determining whether to issue a transaction alarm based on the interface type, the actual service processing time, and the expected processing time range includes:

[0013] Compare the actual business processing time with the expected processing time range;

[0014] If the actual business processing time is longer than the expected processing time range, the transaction exception type is obtained;

[0015] Based on the transaction abnormality type, determine to issue a transaction alarm.

[0016] In one embodiment, determining to issue a transaction alert based on the transaction abnormality type includes:

[0017] If the transaction exception type is a timeout type, then based on the interface type, a timeout alarm level is determined, and a timeout alarm is generated;

[0018] If the transaction exception type is a failure type, a failure alarm is generated based on the failure type.

[0019] In one embodiment, generating a failure alarm based on the failure type includes:

[0020] Check whether the error code is configured;

[0021] If yes, determine whether the error code configuration affects the transaction and obtain a determination result;

[0022] Based on the judgment result and the failure type, a failure alarm level is determined, and a failure alarm is generated.

[0023] In one embodiment, after determining the timeout alarm level based on the interface type and generating the timeout alarm, the method further includes:

[0024] Matching the interface type and the timeout alarm level with a preset responsible person database to determine the responsible person corresponding to the timeout alarm;

[0025] Obtain the push method and push interface of the person in charge;

[0026] Based on the push mode and the push interface, the timeout alarm is pushed.

[0027] In one embodiment, after determining whether to issue a transaction alarm based on the interface type, the actual service processing time, and the expected processing time range, the method further includes:

[0028] Obtain log information and transaction information generated by the transaction interface;

[0029] Generate a transaction monitoring report based on the log information and the transaction information;

[0030] The transaction monitoring report is pushed to the security manager for review by the security manager.

[0031] In addition, to achieve the above-mentioned purpose, the present application also proposes a transaction monitoring device, which includes:

[0032] The acquisition module is used to obtain the request time, response time and real-time performance index values ​​of the transaction interface;

[0033] An output module, used to input the interface type of the transaction interface, the request time, the response time and the real-time performance indicator value into a transaction response time prediction model, and obtain an actual business processing time and an expected processing time range output by the transaction response time prediction model;

[0034] The determination module is used to determine whether to issue a transaction alarm based on the interface type, the actual business processing time and the expected processing time range.

[0035] In addition, to achieve the above objectives, the present application also proposes a transaction monitoring device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the transaction monitoring method described above.

[0036] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the transaction monitoring method described above are implemented.

[0037] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps of the transaction monitoring method described above are implemented.

[0038] The present application provides a transaction monitoring method, apparatus, device and storage medium. The transaction monitoring method obtains the request time, response time and real-time performance index value of the transaction interface, and then inputs the interface type of the transaction interface, the request time, the response time and the real-time performance index value into a transaction response time prediction model to obtain the actual business processing time and the expected processing time range output by the transaction response time prediction model, thereby determining whether to issue a transaction alarm based on the interface type, the actual business processing time and the expected processing time range, thereby improving the accuracy of transaction response monitoring, and at the same time, by monitoring all transaction interfaces, avoiding the incompleteness of random inspections, thereby reducing false positives and missed positives, and achieving personalized alarms. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0040] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0041] Figure 1 A flowchart of the first embodiment of the transaction monitoring method of the present application is provided;

[0042] Figure 2 A brief example diagram of the overall transaction process provided for the transaction monitoring method of this application;

[0043] Figure 3 A brief example diagram of the process for determining the alarm level provided for the transaction monitoring method of this application;

[0044] Figure 4 An example diagram of the overall process provided for the transaction monitoring method of this application;

[0045] Figure 5 This is a schematic diagram of the module structure of the transaction monitoring device according to an embodiment of the present application;

[0046] Figure 6 Schematic diagram of the device structure of the hardware operating environment involved in the transaction monitoring method in the embodiment of the present application.

[0047] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0048] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0049] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0050] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device capable of realizing the above functions, a big data service platform, a transaction monitoring system, etc. The following takes the transaction monitoring system as an example to illustrate this embodiment and the following embodiments.

[0051] Based on this, the present application embodiment provides a transaction monitoring method, referring to Figure 1 , Figure 1 A flowchart of the first embodiment of the transaction monitoring method of the present application is provided.

[0052] In this embodiment, the transaction monitoring method includes steps S11 to S13:

[0053] Step S11, obtaining the request time, response time and real-time performance index value of the transaction interface;

[0054] It should be noted that the request time refers to the time when the client (such as the merchant system) sends a request to the transaction interface, and the response time refers to the time when the transaction interface processes the request and returns a response to the client.

[0055] It should be further explained that the real-time performance indicator value is the performance data collected in real time during the transaction processing process, so as to timely reflect the operating status of the system when processing transactions, including system resource usage (such as CPU utilization, memory usage, disk I / O, network traffic, etc.), throughput (the number of transactions that the system can process per unit time), number of concurrent users, transaction success rate: the ratio of successfully completed transactions to total transactions, and response time distribution (statistical distribution of response time, such as average response time, median response time, maximum / minimum response time, etc.), without any restriction here.

[0056] Furthermore, since the merchant's active deduction process is relatively cumbersome, you can refer to Figure 2 , Figure 2 A brief example diagram of the overall transaction process provided for the transaction monitoring method of this application, Figure 2The example in this article takes the transaction between a bank and a merchant as an example. In one embodiment, the merchant first initiates a deduction request to the acceptance institution bank. After processing, the bank forwards the transaction to the corresponding customer's payment institution for deduction, such as the bank's mobile banking, Alipay, WeChat, UnionPay and other institutions; then wait for these payment institutions to return the payment results to the bank after payment; the bank then informs the merchant of the payment results. The entire payment chain is very long, and the merchant may encounter a timeout when receiving the payment result. The traditional method is to wait for a timeout and then analyze it. This method is not real-time and often cannot fundamentally solve the problem. Therefore, the monitoring code can be embedded in the transaction interface to record the timestamps of the request and response in real time to calculate the business processing time.

[0057] Specifically, by setting a monitoring code at the transaction interface or directly reading real-time data through a system monitoring tool, the request time, response time and real-time performance index value of the transaction interface can be obtained, and then the request time, response time and real-time performance index value of the transaction interface are stored in a preset database, thereby providing a data analysis basis for subsequent model training and system optimization.

[0058] Step S12, inputting the interface type of the transaction interface, the request time, the response time and the real-time performance index value into a transaction response time prediction model, and obtaining the actual business processing time and the expected processing time range output by the transaction response time prediction model;

[0059] It should be noted that the interface type refers to the interface classification of different functions in the transaction system, including but not limited to query interfaces (used to retrieve information, such as account balance query, transaction record query, etc.), transaction interfaces (processing actual financial transactions, such as payment, transfer, deduction, etc.), clearing interfaces (used to process the clearing process after the transaction, such as settlement, reconciliation, etc.), accounting interfaces (involving account management, such as account opening, closing, modification, etc.), reporting interfaces (used to generate various business reports, such as financial statements, transaction statistics, etc.), notification interfaces (used to send notifications or messages, such as transaction confirmation notifications, system status updates, etc.) and maintenance interfaces, etc. In addition, the transaction response time prediction model is used to provide accurate predictions of transaction processing time, thereby helping to optimize system performance and improve user experience.

[0060] It should be further explained that the actual business processing time refers to the total time required from the receipt of the request by the transaction interface to the completion of the processing and generation of the response. The expected processing time range refers to the ideal transaction response time range for this transaction, so as to ensure the efficiency, real-time and user experience of the transaction by setting a reasonable threshold. In addition, for different types of transactions (i.e. interface types), different expected processing time ranges can be set according to their business characteristics and importance to ensure the optimal allocation of resources and the smooth operation of the business.

[0061] Specifically, the interface type of the transaction interface, the request time, the response time and the real-time performance indicator value are input into the transaction response time prediction model to obtain the actual business processing time and the expected processing time range output by the transaction response time prediction model, wherein the actual business processing time is directly calculated from the request time and the response time, for example, the actual business processing time is obtained by subtracting the request message timestamp from the response message timestamp.

[0062] Step S13, determining whether to issue a transaction alarm based on the interface type, the actual service processing time, and the expected processing time range.

[0063] Specifically, the actual business processing time and the expected processing time range are compared, and if the actual business processing time is less than the expected processing time range, the transaction process is determined to be normal. In addition, if the actual business processing time is greater than the expected processing time range, based on the transaction abnormality type, it is determined to issue a transaction alarm.

[0064] This embodiment obtains the request time, response time and real-time performance indicator value of the transaction interface, and then inputs the interface type of the transaction interface, the request time, the response time and the real-time performance indicator value into the transaction response time prediction model to obtain the actual business processing time and the expected processing time range output by the transaction response time prediction model, and then determines whether to issue a transaction alarm based on the interface type, the actual business processing time and the expected processing time range, thereby improving the accuracy of transaction response monitoring, and at the same time, by monitoring all transaction interfaces, avoiding the incompleteness of random inspections, thereby reducing false alarms and missed alarms, and realizing personalized alarms.

[0065] In a feasible implementation manner, the training process of the transaction response time prediction model includes:

[0066] Step S21, obtaining several groups of interface types, historical service processing durations, and historical performance index values;

[0067] It should be noted that the historical business processing time refers to the total time required for this historical transaction from the time the transaction interface receives the request to the time the transaction is completed and a response is generated. The historical performance index value is the ideal transaction response time range for this historical transaction.

[0068] Specifically, several groups of interface types, historical business processing durations, and historical performance index values ​​are obtained through historical logs and preset databases. There is no restriction on the acquisition method, and it can be set according to the actual method.

[0069] Step S22, vectorizing each of the interface types, the historical service processing duration, and the historical performance indicator value;

[0070] Specifically, data preprocessing, such as data cleaning and normalization, is performed on each of the interface types, the historical business processing time, and the historical performance indicator values, so as to vectorize each of the interface types, the historical business processing time, and the historical performance indicator values. Since vector operations are usually more efficient than processing complex data structures, the training and prediction speed of the model can be effectively accelerated, which facilitates processing and analysis, thereby improving the model's prediction ability for new data.

[0071] Step S23, inputting the vectorized interface types, the historical business processing durations, and the historical performance indicator values ​​into an initial transaction response duration prediction model for iterative training to obtain the transaction response duration prediction model.

[0072] Specifically, the vectorized interface types, the historical business processing time, the historical performance index values, and the corresponding sample labels are input into the initial transaction response time prediction model to obtain the predicted value output by the initial transaction response time prediction model, and then based on the predicted value and the sample label, the model loss value is calculated using the loss function. In this embodiment, the loss function can be set according to actual needs and is not specifically limited here. After the model loss value is calculated, the training process ends, and the error back propagation algorithm is used to update the model parameters in the initial transaction response time prediction model, and then the next training is carried out. During the training process, it is determined whether the updated initial transaction response time prediction model meets the preset training end conditions. If it does, the updated initial transaction response time prediction model is used as the transaction response time prediction model. If it does not, the model training continues, wherein the preset training end conditions include loss convergence and reaching the maximum number of iterations threshold.

[0073] This embodiment obtains several groups of interface types, historical business processing times and historical performance index values, and then vectorizes each of the interface types, historical business processing times and historical performance index values, and then inputs the vectorized interface types, historical business processing times and historical performance index values ​​into the initial transaction response time prediction model for iterative training to obtain the transaction response time prediction model, and then generates a corresponding expected processing time range for the real-time data of this transaction, thereby effectively improving the model's prediction accuracy for the current expected processing time range, and adapts to different interface types and business scenarios through multiple data sources, thereby expanding the robustness and adaptability of the model.

[0074] In a feasible implementation manner, determining whether to issue a transaction alarm based on the interface type, the actual service processing time, and the expected processing time range includes:

[0075] Step S31, comparing the actual service processing time with the expected processing time range;

[0076] Specifically, the actual business processing time is compared with the expected processing time range. If the actual business processing time is less than the expected processing time range, it is determined that the current transaction has not timed out, but the possibility of transaction failure cannot be ruled out. Therefore, it is necessary to check whether the log information at the transaction interface contains error codes and other information indicating transaction failure.

[0077] Further, if not, it is determined that the transaction process is normal, and then the information such as the actual business processing time and the expected processing time range are associated and combined to generate a transaction success log, and then the transaction success log is stored in a preset log library for subsequent viewing.

[0078] Step S32, if the actual business processing time is greater than the expected processing time range, obtaining the transaction abnormality type;

[0079] It should be noted that the transaction anomaly type refers to the classification of abnormal situations that occur during the transaction process, which is used to identify whether the transaction is successful and the type of problem encountered.

[0080] Specifically, if the actual business processing time is longer than the expected processing time range, detection is performed through the monitoring tool of the transaction interface to obtain the transaction abnormality type, which is not limited here and can be set according to actual conditions.

[0081] Step S33: If the actual business processing time is longer than the expected processing time range, it is determined to issue a transaction alarm based on the transaction abnormality type.

[0082] Specifically, if the transaction exception type is a timeout type, a timeout alarm level is determined based on the interface type, and a timeout alarm is generated. Additionally, if the transaction exception type is a failure type, a failure alarm is generated based on the failure type.

[0083] This embodiment compares the actual business processing time with the expected processing time range, and if the actual business processing time is greater than the expected processing time range, the transaction abnormality type is obtained, and based on the transaction abnormality type, a transaction alarm is determined to reduce false alarms, ensuring that the alarm is triggered only when the transaction performance obviously deviates from the normal level, and realizing rapid identification and response of transaction abnormalities, which helps to solve problems in a timely manner, prevent potential system failures, and prevent system downtime and transaction termination, etc., so as to flexibly set the alarm type according to different business needs and transaction types to achieve personalized notification.

[0084] In a feasible implementation manner, determining to issue a transaction alarm based on the transaction abnormality type includes:

[0085] Step S41, if the transaction exception type is a timeout type, then based on the interface type, determine the timeout alarm level and generate a timeout alarm;

[0086] It should be noted that the timeout type indicates that the transaction processing time exceeds a predetermined threshold or an expected duration. Different emergency levels can be set according to the severity and impact scope of the timeout. For example, three timeout alarm levels, low, medium, and high, can be set to distinguish timeout problems of different degrees. There is no restriction on the setting of the timeout alarm level, which can be set according to actual conditions.

[0087] It should be further explained that the timeout alarm refers to a notification mechanism triggered when the transaction processing time exceeds a preset threshold, which usually includes detailed information of the transaction, such as transaction ID, timestamp, interface type involved, etc.; comparison of actual response time with preset threshold; analysis of the cause of the timeout; recommended response measures or person responsible for notification, etc. Different alarm contents can be set according to different timeout alarm levels, and there is no restriction here, and it can be set according to actual conditions.

[0088] Specifically, if the transaction exception type is a timeout type, the timeout alarm level is determined based on the interface type, and a timeout alarm is generated. In one embodiment, the interface types include merchant query interface, merchant settlement interface, and merchant account interface timeouts, and then different alarm levels and alarm contents are formulated according to different timeout situations and interface types. For example, when the timeout level is 3, if the merchant query interface times out, the person in charge of the interface is notified, and the timeout ratio is calculated through the expected response time and actual response time corresponding to the interface, and then a timeout alarm is generated based on the timeout ratio and information such as the alarm template corresponding to the interface.

[0089] Step S42: if the transaction exception type is a failure type, a failure alarm is generated based on the failure type.

[0090] It should be noted that the failure type indicates that the transaction was not successfully completed due to various reasons, and the failure alarm level can be set according to the failure type, wherein the failure alarm level refers to different levels set according to the impact and urgency of the failure, which can be set according to actual conditions and is not limited here.

[0091] It should be further explained that the failure alarm refers to the notification mechanism triggered when a transaction fails. The failure alarm usually includes the following: specific error information of the transaction failure, such as error code, error message, etc.; details of the failed transaction, such as transaction ID, timestamp, type of interface involved, etc.; possible reasons for the failure and impact analysis; recommended troubleshooting steps or responsible persons for notification, etc.

[0092] Specifically, it is detected whether an error code is configured, and if so, it is determined whether the error code configuration affects the transaction to obtain a judgment result, thereby determining the failure alarm level based on the judgment result and the failure type, and generating a failure alarm.

[0093] In this embodiment, if the transaction exception type is a timeout type, the timeout alarm level is determined based on the interface type, and a timeout alarm is generated. Additionally, if the transaction exception type is a failure type, a failure alarm is generated based on the failure type, thereby taking different response measures according to different exception types to ensure that the problem can be solved in a targeted manner. At the same time, by setting different alarm levels, it is clear which problems are more urgent, thereby reasonably allocating technical resources and human resources, reducing false alarms, avoiding alarm fatigue, and promptly handling transaction exceptions to reduce potential economic losses.

[0094] In a feasible implementation manner, the generating a failure alarm based on the failure type includes:

[0095] Step S51, detecting whether an error code is configured;

[0096] It should be noted that the error code refers to a code generated by the system for identifying a specific error or problem.

[0097] Specifically, by detecting the failure log information of the system interface, it is determined whether to configure the error code. There is no restriction on the detection method, which can be set according to the actual situation.

[0098] Step S52: If yes, determine whether the error code configuration affects the transaction and obtain a determination result;

[0099] It should be noted that the judgment result refers to the judgment result of whether the error code configuration affects the transaction, including the result of affecting and the result of not affecting.

[0100] Specifically, the error code is matched with a preset influencing error code library to obtain a judgment result. Furthermore, if the judgment result is not influencing the result, no failure alarm is generated to notify relevant personnel, and only the transaction records generated this time are stored in the database for subsequent statistical analysis.

[0101] Step S53: determine the failure alarm level based on the judgment result and the failure type, and generate a failure alarm.

[0102] Specifically, if the judgment result is an impact result, then according to different failure types (or error code types), a corresponding failure level is formulated, and a failure alarm is generated. In one embodiment, failure level 2: If the error code is a development-focused error code in the subscription configuration and does not affect the transaction, a failure alarm such as "A certain error code has occurred, please optimize later" is generated, and the person in charge of the interface is notified. In another embodiment, failure level 1: If the error code is in the configuration and affects the transaction, a failure alarm such as "A level 1 configuration error code has occurred in a certain system transaction and needs to be resolved immediately" is generated, and the person in charge of the system is notified. For reference, Figure 3 , Figure 3 A simplified flowchart of the transaction monitoring method for determining the alarm level is provided in this application.

[0103] This embodiment detects whether an error code is configured. If so, it determines whether the error code configuration affects the transaction to obtain a judgment result, and then determines the failure alarm level based on the judgment result and the failure type, and generates a failure alarm, thereby quickly and concisely identifying the alarm type, thereby achieving rapid identification and response of the alarm type, and clarifying the alarm priority, so as to reasonably allocate technical support and operation and maintenance resources, give priority to handling problems that have a greater impact on the business, and effectively improve system stability.

[0104] In a feasible implementation manner, after determining the timeout alarm level based on the interface type and generating the timeout alarm, the method further includes:

[0105] Step S61, matching the interface type and the timeout alarm level with a preset responsible person database to determine the responsible person corresponding to the timeout alarm;

[0106] It should be noted that the preset responsible person database is used to store responsible person information corresponding to different interface types and timeout alarm levels, including responsible person name, contact information, push method, department, etc., and no restrictions are imposed here.

[0107] Step S62, obtaining the push method and push interface of the person in charge;

[0108] It should be noted that the push method refers to the communication channel or method for sending alarm information to the person in charge, and the push interface refers to the technical interface or service within the system used to send alarm information, including API interface, integration platform, internal system interface, hardware interface and software service interface, etc.

[0109] Specifically, it is obtained through a preset responsible person database, and no limitation is made here.

[0110] Step S63: Push the timeout alarm based on the push mode and the push interface.

[0111] Specifically, the timeout alarm is pushed according to the push method and the push interface. If the interface type is a merchant query interface, the timeout alarm is pushed to the person in charge of the interface; if the interface type is a merchant settlement interface, the timeout alarm is pushed to the person in charge of the interface and the system; if the interface type is a merchant account interface, the timeout alarm is pushed to the person in charge of system and framework operation and maintenance, so as to achieve personalized and accurate push.

[0112] This embodiment determines the person in charge of the timeout alarm by matching the interface type and the timeout alarm level with a preset person in charge database, and then obtains the push method and push interface of the person in charge, so as to push the timeout alarm based on the push method and the push interface, thereby speeding up the response time and reducing the need for manual search for persons in charge and notifications, thereby effectively improving processing efficiency, and enhancing the sense of responsibility by clarifying the persons in charge of various interface problems, and realizing flexible configuration of different persons in charge and notification methods, thereby improving the scalability of the configuration.

[0113] In a feasible implementation manner, after determining whether to issue a transaction alarm based on the interface type, the actual service processing time, and the expected processing time range, the method further includes:

[0114] Step S71, obtaining log information and transaction information generated by the transaction interface;

[0115] It should be noted that the log information refers to the records automatically generated by the system during the transaction processing process, which is used to record operation history and system events, including user activities (login attempts, user queries, transaction initiation, etc.), system events (system startup, shutdown, errors, warnings, etc.) and response time: (interface response time, processing time, etc.), error codes and security events (such as unauthorized access attempts, suspicious activity detection, etc.), without limitation here.

[0116] It should be further explained that the transaction information refers to all relevant data and details involved in the transaction process, including the transaction parties, transaction amount, transaction timestamp, transaction status: the current status of the transaction, transaction type and transaction channel, etc.

[0117] Specifically, the log information and transaction information generated by the transaction interface are obtained through channels such as system detection logs. There is no restriction here and it can be set according to actual conditions.

[0118] Step S72, generating a transaction monitoring report based on the log information and the transaction information;

[0119] It should be noted that the transaction monitoring report refers to a summary document generated based on log information and transaction information, which is used to reflect transaction activities and monitoring results over a period of time, including transaction statistics, abnormal transactions, security incident summaries, performance indicators (such as average response time, system availability, etc.), risk assessments, trend analysis, suggestions and improvement measures, compliance checks, and system and network status.

[0120] Specifically, feature extraction is performed on the log information and the transaction information, such as inputting the log information and the transaction information into a bag-of-words analysis model for feature extraction, and then inputting the extracted features into a semantic analysis model and a sentiment tendency analysis model for analysis, so as to determine the report content in the transaction monitoring report and the sentiment tendency corresponding to the report content (such as positive or negative, etc.), thereby filling the report content and the sentiment tendency corresponding to the report content into a transaction monitoring report template to generate an initial transaction monitoring report.

[0121] Furthermore, the initial transaction monitoring report is checked to ensure the consistency and accuracy of the report data. After ensuring that there are no errors, the checked initial transaction monitoring report is used as the transaction monitoring report, wherein some data information can also be visualized to enrich the report content and facilitate managers to intuitively understand the report content.

[0122] Step S73: Push the transaction monitoring report to the security manager for the security manager to review.

[0123] Specifically, the transaction monitoring report is pushed to the security manager for review by the security manager. The push can be performed through APP notification, mini-program push, URL link, and email, etc. There is no restriction on the push method, and it can be set according to the actual method.

[0124] This embodiment obtains log information and transaction information generated by the transaction interface, and then generates a transaction monitoring report based on the log information and the transaction information, and then pushes the transaction monitoring report to security management personnel for review by the security management personnel, thereby increasing the visibility and transparency of security measures. At the same time, by continuously monitoring transaction activities and system security status, it helps to continuously improve security measures and processes, and provides management personnel with decision-making directions and data foundations for assessing potential risks and taking preventive measures, thereby improving the efficiency, professionalism and traceability of decision-making.

[0125] For example, to help understand the implementation process of the transaction monitoring method, please refer to Figure 4 , Figure 4 An example diagram of the overall process provided for the transaction monitoring method of this application.

[0126] Specifically, by placing monitoring code in the subscribed merchant service system interface, transaction requests and response times are monitored in real time, and the monitoring data is stored in the database, and then the monitoring data is statistically analyzed and analyzed in real time, so as to generate and push alarm information.

[0127] It should be noted that the examples in the figure are only used to understand the present application and do not constitute a limitation on the transaction monitoring method of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0128] It should be understood that the order of execution of the steps in the above embodiment does not necessarily mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present invention.

[0129] This application also provides a transaction monitoring device, please refer to Figure 5 , the transaction monitoring device comprises:

[0130] The acquisition module 51 is used to obtain the request time, response time and real-time performance index value of the transaction interface;

[0131] An output module 52 is used to input the interface type of the transaction interface, the request time, the response time and the real-time performance indicator value into a transaction response time prediction model to obtain an actual business processing time and an expected processing time range output by the transaction response time prediction model;

[0132] The determination module 53 is used to determine whether to issue a transaction alarm based on the interface type, the actual service processing time and the expected processing time range.

[0133] The transaction monitoring device is also used for:

[0134] Obtain several groups of interface types, historical business processing durations, and historical performance indicator values;

[0135] Vectorizing each of the interface types, the historical service processing duration, and the historical performance indicator value;

[0136] The vectorized interface types, historical business processing durations, and historical performance indicator values ​​are input into an initial transaction response duration prediction model for iterative training to obtain the transaction response duration prediction model.

[0137] The transaction monitoring device is also used for:

[0138] Compare the actual business processing time with the expected processing time range;

[0139] If the actual business processing time is less than the expected processing time range, it is determined that the transaction process is normal;

[0140] If the actual business processing time is longer than the expected processing time range, a transaction alarm is determined based on the transaction abnormality type.

[0141] The transaction monitoring device is also used for:

[0142] Get the transaction exception type;

[0143] If the transaction exception type is a timeout type, then based on the interface type, a timeout alarm level is determined, and a timeout alarm is generated;

[0144] If the transaction exception type is a failure type, a failure alarm is generated based on the failure type.

[0145] The transaction monitoring device is also used for:

[0146] Check whether the error code is configured;

[0147] If yes, determine whether the error code configuration affects the transaction and obtain a determination result;

[0148] Based on the judgment result and the failure type, a failure alarm level is determined, and a failure alarm is generated.

[0149] The transaction monitoring device is also used for:

[0150] Matching the interface type and the timeout alarm level with a preset responsible person database to determine the responsible person corresponding to the timeout alarm;

[0151] Obtain the push method and push interface of the person in charge;

[0152] Based on the push mode and the push interface, the timeout alarm is pushed.

[0153] The transaction monitoring device is also used for:

[0154] Obtain log information and transaction information generated by the transaction interface;

[0155] Generate a transaction monitoring report based on the log information and the transaction information;

[0156] The transaction monitoring report is pushed to the security manager for review by the security manager.

[0157] The transaction monitoring device provided by the present application adopts the transaction monitoring method in the above embodiment, which can solve the technical problems in the background technology. Compared with the prior art, the beneficial effects of the transaction monitoring device provided by the present application are the same as the beneficial effects of the transaction monitoring method provided by the above embodiment, and the other technical features in the transaction monitoring device are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0158] The present application provides a transaction monitoring device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the transaction monitoring method in the above-mentioned embodiment one.

[0159] Reference below Figure 6 , which shows a schematic diagram of the structure of a transaction monitoring device suitable for implementing the embodiment of the present application. The transaction monitoring device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 6 The transaction monitoring device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0160] like Figure 6 As shown, the transaction monitoring device may include a processing device 1001 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the transaction monitoring device are also stored. The processing device 1001, ROM1002, and RAM1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the transaction monitoring device to communicate with other devices wirelessly or by wire to exchange data. Although the transaction monitoring device with various systems is shown in the figure, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or have alternatively.

[0161] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0162] The transaction monitoring device provided by the present application adopts the transaction monitoring method in the above embodiment, which can solve the technical problems in the background technology. Compared with the prior art, the beneficial effects of the transaction monitoring device provided by the present application are the same as the beneficial effects of the transaction monitoring method provided by the above embodiment, and the other technical features in the transaction monitoring device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0163] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0164] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0165] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, and the computer-readable program instructions are used to execute the transaction monitoring method in the above-mentioned embodiment.

[0166] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

[0167] The computer-readable storage medium may be included in the transaction monitoring device; or may exist independently without being assembled into the transaction monitoring device.

[0168] The computer-readable storage medium carries one or more programs. When the one or more programs are executed by the transaction monitoring device, the transaction monitoring device:

[0169] Obtain the request time, response time and real-time performance index values ​​of the transaction interface;

[0170] Inputting the interface type of the transaction interface, the request time, the response time and the real-time performance index value into a transaction response time prediction model to obtain an actual business processing time and an expected processing time range output by the transaction response time prediction model;

[0171] Whether to issue a transaction alarm is determined based on the interface type, the actual business processing time, and the expected processing time range.

[0172] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0173] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0174] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0175] The readable storage medium provided in this application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned transaction monitoring method, and can solve the technical problems in the background technology. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the transaction monitoring method provided in the above-mentioned embodiment, and will not be repeated here.

[0176] An embodiment of the present application provides a computer program product, including a computer program, which implements the steps of the transaction monitoring method as described above when executed by a processor.

[0177] The computer program product provided in this application can solve the technical problems in the background technology. Compared with the prior art, the beneficial effects of the computer program product provided in the embodiment of this application are the same as the beneficial effects of the transaction monitoring method provided in the above embodiment, which will not be repeated here.

[0178] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A transaction monitoring method, characterized in that: include: Obtain the request time, response time and real-time performance index values ​​of the transaction interface; Inputting the interface type of the transaction interface, the request time, the response time and the real-time performance index value into a transaction response time prediction model to obtain an actual business processing time and an expected processing time range output by the transaction response time prediction model; Whether to issue a transaction alarm is determined based on the interface type, the actual business processing time, and the expected processing time range.

2. The transaction monitoring method according to claim 1, characterized in that: The training process of the transaction response time prediction model includes: Obtain several groups of interface types, historical business processing durations, and historical performance indicator values; Vectorizing each of the interface types, the historical service processing duration, and the historical performance indicator value; The vectorized interface types, historical business processing durations, and historical performance indicator values ​​are input into an initial transaction response duration prediction model for iterative training to obtain the transaction response duration prediction model.

3. The transaction monitoring method according to claim 1, characterized in that: The determining whether to issue a transaction alarm based on the interface type, the actual service processing time, and the expected processing time range includes: Compare the actual business processing time with the expected processing time range; If the actual business processing time is longer than the expected processing time range, the transaction exception type is obtained; Based on the transaction abnormality type, determine to issue a transaction alarm.

4. The transaction monitoring method according to claim 3, characterized in that: The determining to issue a transaction alarm based on the transaction abnormality type includes: If the transaction exception type is a timeout type, then based on the interface type, a timeout alarm level is determined, and a timeout alarm is generated; If the transaction exception type is a failure type, a failure alarm is generated based on the failure type.

5. The transaction monitoring method according to claim 4, characterized in that: The generating a failure alarm based on the failure type includes: Check whether the error code is configured; If yes, determine whether the error code configuration affects the transaction and obtain a determination result; Based on the judgment result and the failure type, a failure alarm level is determined, and a failure alarm is generated.

6. The transaction monitoring method according to claim 4, characterized in that: After determining the timeout alarm level based on the interface type and generating the timeout alarm, the method further includes: Matching the interface type and the timeout alarm level with a preset responsible person database to determine the responsible person corresponding to the timeout alarm; Obtain the push method and push interface of the person in charge; Based on the push mode and the push interface, the timeout alarm is pushed.

7. The transaction monitoring method according to claim 1, characterized in that: After determining whether to issue a transaction alarm based on the interface type, the actual service processing time, and the expected processing time range, the method further includes: Obtain log information and transaction information generated by the transaction interface; Generate a transaction monitoring report based on the log information and the transaction information; The transaction monitoring report is pushed to the security manager for review by the security manager.

8. A transaction monitoring device, characterized in that: include: The acquisition module is used to obtain the request time, response time and real-time performance index values ​​of the transaction interface; An output module, used to input the interface type of the transaction interface, the request time, the response time and the real-time performance indicator value into a transaction response time prediction model, and obtain an actual business processing time and an expected processing time range output by the transaction response time prediction model; The determination module is used to determine whether to issue a transaction alarm based on the interface type, the actual business processing time and the expected processing time range.

9. A transaction monitoring device, characterized in that: The transaction monitoring device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the transaction monitoring method according to any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the transaction monitoring method according to any one of claims 1 to 7 are implemented.

Images