CN113297149A - Method and device for monitoring data processing request - Google Patents

Method and device for monitoring data processing request Download PDF

Info

Publication number
CN113297149A
CN113297149A CN202110687072.8A CN202110687072A CN113297149A CN 113297149 A CN113297149 A CN 113297149A CN 202110687072 A CN202110687072 A CN 202110687072A CN 113297149 A CN113297149 A CN 113297149A
Authority
CN
China
Prior art keywords
target transaction
exception
application
indication information
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202110687072.8A
Other languages
Chinese (zh)
Inventor
程思铤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Agricultural Bank of China
Original Assignee
Agricultural Bank of China
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Agricultural Bank of China filed Critical Agricultural Bank of China
Priority to CN202110687072.8A priority Critical patent/CN113297149A/en
Publication of CN113297149A publication Critical patent/CN113297149A/en
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/17Details of further file system functions
    • G06F16/1734Details of monitoring file system events, e.g. by the use of hooks, filter drivers, logs
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/18File system types
    • G06F16/1805Append-only file systems, e.g. using logs or journals to store data
    • G06F16/1815Journaling file systems

Abstract

The embodiment of the application provides a method and a device for monitoring a data processing request, wherein the method comprises the following steps: receiving a data processing request of a target transaction; acquiring log data generated by target transaction; and determining whether to perform exception processing on the data of the target transaction according to exception indication information in log data generated by the target transaction, wherein the exception indication information is used for indicating the exception type of application occurring when the target transaction is processed. By the method, when the data processing request of the target transaction is received, whether the data of the target transaction is subjected to exception processing is determined in real time according to the exception indication information in the log data, so that the exception processing time is shortened.

Description

Method and device for monitoring data processing request
Technical Field
The present invention relates to the field of computer technologies, and in particular, to a method and an apparatus for monitoring a data processing request.
Background
An exception may occur after the application program is put into production, and in order to ensure program reliability and repair the application program in time after the exception occurs, the application program needs to be monitored, especially when the transaction operation of the application program occurs.
The existing monitoring mode of the application program mainly comprises artificial monitoring and periodic monitoring. The program running state is checked manually through manual monitoring, and the program running state is determined through inquiring a service data table or system performance indexes and the like. The periodic monitoring schedules a monitoring program by configuring fixed time, monitors an application program or a log table, and accordingly recovers and processes the application when finding out the application abnormity.
However, in the two existing monitoring methods, no matter manual monitoring or periodic monitoring, the occurrence of an abnormality cannot be timely monitored and processed at the first time, so that the time for processing the abnormality is long, and the real-time repair of the abnormality cannot be realized.
Disclosure of Invention
The embodiment of the application provides a method and a device for monitoring a data processing request, so as to solve the technical problem that the time for exception handling is long in the prior art.
In a first aspect, an embodiment of the present application provides a method for monitoring a data processing request, where the method includes:
receiving a data processing request of a target transaction;
acquiring log data generated by the target transaction;
and determining whether to perform exception processing on the data of the target transaction according to exception indication information in log data generated by the target transaction, wherein the exception indication information is used for indicating an exception type applied when the target transaction is processed.
In an optional embodiment, the determining whether to exception the data of the target transaction includes:
matching the abnormal type indicated by the abnormal indication information with a white list, wherein the white list comprises the abnormal type meeting a preset rule;
and if the abnormal type indicated by the abnormal indication information is not in the white list, performing abnormal processing on the data of the target transaction.
In an optional implementation manner, after the matching the abnormality type indicated by the abnormality indication information with a white list, the method further includes:
and if the abnormal type indicated by the abnormal indication information is in the white list, releasing the data processing request of the target transaction.
In an optional implementation manner, the matching the abnormality type indicated by the abnormality indication information with a white list includes:
matching the application identifier in the log data generated by the target transaction with an application list to be monitored;
and if the application identifier is in the application list to be monitored, matching the abnormal type indicated by the abnormal indication information with the white list.
In an optional embodiment, after the matching the application identifier in the log data generated by the target transaction with the list of applications to be monitored, the method further includes:
and if the application identifier is not in the application list to be monitored, releasing the data processing request of the target transaction.
In an optional embodiment, the exception handling of the data of the target transaction includes:
storing description data of the target transaction;
wherein the description data of the target transaction comprises: the service identification of the target transaction, the application identification, the abnormal indication information, the generation time of the log data, the identification of the log data and the error information of the target transaction.
In an optional embodiment, the exception handling of the data of the target transaction further includes:
determining the terminal equipment to be alarmed according to the abnormal indication information and the application identifier;
and sending the alarm information of the target transaction to the terminal equipment to be alarmed.
In an optional embodiment, before receiving the data processing request of the target transaction, the method further includes:
receiving configuration modification information;
and according to the configuration modification information, modifying the abnormal type in the white list and/or modifying the application identifier in the application list to be monitored.
In a second aspect, an embodiment of the present application provides a device for monitoring a data processing request, where the device includes:
the receiving module is used for receiving a data processing request of a target transaction;
the processing module is used for acquiring log data generated by the target transaction; and determining whether to perform exception processing on the data of the target transaction according to exception indication information in log data generated by the target transaction, wherein the exception indication information is used for indicating an exception type applied when the target transaction is processed.
In an optional implementation manner, the processing module is specifically configured to match an exception type indicated by the exception indication information with a white list, where the white list includes an exception type meeting a preset rule; and if the abnormal type indicated by the abnormal indication information is not in the white list, performing abnormal processing on the data of the target transaction.
In an optional implementation manner, the processing module is further configured to, if the exception type indicated by the exception indication information is in the white list, release the data processing request of the target transaction.
In an optional implementation manner, the processing module is specifically configured to match an application identifier in log data generated by the target transaction with an application list to be monitored; and if the application identifier is in the application list to be monitored, matching the abnormal type indicated by the abnormal indication information with the white list.
In an optional implementation manner, the processing module is further configured to, if the application identifier is not in the list of applications to be monitored, pass through the data processing request of the target transaction.
In an optional embodiment, the processing module is specifically configured to store description data of the target transaction; wherein the description data of the target transaction comprises: the service identification of the target transaction, the application identification, the abnormal indication information, the generation time of the log data, the identification of the log data and the error information of the target transaction.
In an optional implementation manner, the processing module is specifically configured to determine, according to the abnormal indication information and the application identifier, a terminal device to be warned; and sending the alarm information of the target transaction to the terminal equipment to be alarmed.
In an optional embodiment, the receiving module is further configured to receive configuration modification information;
the processing module is further configured to modify the exception type in the white list and/or modify the application identifier in the application list to be monitored according to the configuration modification information.
In a third aspect, the present application further provides an electronic device, including:
a processor; and
a memory for storing a computer program for the processor;
wherein the processor is configured to implement any one of the possible methods of the first aspect by executing the computer program.
In a fourth aspect, the present application also provides a computer program product comprising a computer program that, when executed by a processor, performs the method of any of the first aspects.
In a fifth aspect, the present invention also provides a non-transitory computer readable storage medium having stored thereon a computer program of instructions for implementing any one of the possible methods of the first aspect when executed by a processor.
According to the monitoring method and device for the data processing request, the data processing request of the target transaction is received firstly, then, the log data generated by the target transaction are obtained, and finally, whether the data of the target transaction are subjected to exception processing or not is determined according to exception indication information in the log data generated by the target transaction, wherein the exception indication information is used for indicating an exception type applied when the target transaction is processed. By the method, when the data processing request of the target transaction is received, whether the data of the target transaction is subjected to exception processing is determined in real time according to the exception indication information in the log data, so that the exception processing time is shortened, and the exception is repaired in real time.
Drawings
In order to more clearly illustrate the technical solutions of the present invention or the prior art, the following briefly introduces the drawings needed to be used in the description of the embodiments or the prior art, and obviously, the drawings in the following description are some embodiments of the present invention, and those skilled in the art can obtain other drawings according to the drawings without inventive labor.
FIG. 1 is a diagram illustrating a conventional application exception monitoring method;
fig. 2 is a schematic view of an application scenario of a monitoring method for a data processing request according to an embodiment of the present application;
fig. 3 is a schematic flowchart of a method for monitoring a data processing request according to an embodiment of the present application;
fig. 4 is a schematic flowchart of another monitoring method for data processing requests according to an embodiment of the present application;
fig. 5 is a schematic flowchart of another data processing request monitoring method according to an embodiment of the present application;
fig. 6 is a schematic structural diagram of a monitoring apparatus for data processing requests according to an embodiment of the present application;
fig. 7 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some embodiments of the present application, but not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
An exception may occur after the application program is put into production, and in order to ensure program reliability and repair the application program in time after the exception occurs, the application program needs to be monitored, especially when the transaction operation of the application program occurs.
The existing monitoring mode of the application program mainly comprises artificial monitoring and periodic monitoring. The program running state is checked manually through manual monitoring, and the program running state is determined through inquiring a service data table or system performance indexes and the like. The periodic monitoring schedules a monitoring program by configuring fixed time, monitors an application program or a log table, and accordingly recovers and processes the application when finding out the application abnormity.
How to determine an application exception in the manual monitoring and the periodic monitoring will be described below.
Fig. 1 is a diagram illustrating a conventional application program exception monitoring method, as shown in fig. 1, the conventional application program exception monitoring method includes:
s101, extracting information in the application program log file according to a preset extraction rule, and recording the information into a data table.
In some embodiments, the communication keyword, the communication illegal keyword and the log timestamp data may be collected by the collection module, and then recorded in the data table as information in the application log file.
S102, analyzing the information in the data table, and analyzing whether the log data are matched with a preset abnormal rule or not.
S103, if the log data are matched with the preset abnormal rule, generating a fault recovery instruction according to the analysis result and a preset recovery strategy.
The abnormal rules comprise illegal keyword rules and legal keyword rules. For example, the communication illegitimate keyword and/or the communication illegitimate keywords may constitute a first anomaly rule for identifying an anomaly state, and the first anomaly rule may be one of the anomaly rules. When the log data is monitored to be matched with the first exception rule, the application program can be determined to be abnormal. For example, a single communication legal keyword and/or a plurality of communication legal keywords may constitute a second exception rule for identifying a normal state, and the second exception rule may be one of the exception rules. When the log data is matched with the second abnormal rule, the application program can be determined to be normal.
It should be appreciated that generating the fault recovery instructions described above may include: generating a thread-level recovery instruction for recovering the thread with the exception; and generating program level recovery, namely generating a program restart instruction for the exception which can be recovered only by restarting the program.
In some embodiments, if the log data matches a preset exception rule, the application program with the error may be analyzed, and then the application program with the error may be recovered through a fault recovery instruction. The fault recovery instruction may be a restart, or a recovery step performed according to error data after the error data is collected. It should be noted that the recovery instruction is preset, and the corresponding recovery instruction may be selectively called according to the analysis result.
In some embodiments, the fault information generated by the monitored application program may be recorded according to the analysis result, and a fault prompt may be performed to the user through one or more of a webpage popup, a short message, or a right button.
In some embodiments, before application exception monitoring, the extraction rules, exception rules, and recovery policies may be preset in configuring parameters,
however, based on the two existing monitoring methods, no matter manual monitoring or periodic monitoring, the occurrence of the abnormality cannot be timely monitored and processed at the first time, so that the time for processing the abnormality is long, and the real-time repair of the abnormality cannot be realized.
In order to solve the above technical problems, embodiments of the present application provide a method and an apparatus for monitoring a data processing request, where the method and apparatus determine whether to perform exception handling on data of a target transaction according to exception indication information in log data generated by the target transaction in real time by monitoring the data processing request of the target transaction, thereby shortening exception handling time and achieving real-time exception recovery.
An application scenario of the monitoring method for data processing requests according to the present application is described below.
Fig. 2 is a schematic view of an application scenario of a monitoring method for a data processing request according to an embodiment of the present application. As shown in fig. 2, the server 201 is an application server, and the server 202 is an application monitoring server. When a user generates a transaction in an application, the server 201 generates a target transaction and sends a data processing request of the target transaction sent by the server 202 to the server 202, so that the server 202 performs anomaly monitoring on the target transaction. After receiving the data processing request of the target transaction, the server 202 may obtain log data generated by the target transaction, and determine whether to perform exception processing on the data of the target transaction according to exception indication information in the log data generated by the target transaction. If the exception handling is not needed, the server 202 releases the target transaction, and if the exception handling is needed, the server 202 may send the alarm information to the terminal device 203 to be alarmed.
The server may be, but is not limited to, a single network server, a server group consisting of a plurality of network servers, or a cloud based on cloud computing, which is composed of a large number of computers or network servers.
The terminal device may be a mobile phone (mobile phone), a tablet computer (pad), a computer with a wireless transceiving function, a Virtual Reality (VR) terminal device, an Augmented Reality (AR) terminal device, a wireless terminal in a self driving (self driving), a wireless terminal in a remote surgery (remote medical supply), a wireless terminal in a smart grid (smart grid), a wireless terminal in a smart home (smart home), and the like. In the embodiment of the present application, the apparatus for implementing the function of the terminal may be the terminal, or may be an apparatus capable of supporting the terminal to implement the function, such as a chip system, and the apparatus may be installed in the terminal. In the embodiment of the present application, the chip system may be composed of a chip, and may also include a chip and other discrete devices.
It should be understood that the application scenario of the present technical solution may be a monitoring scenario of the data processing request in fig. 2, but is not limited thereto, and may also be applied to other scenarios that require monitoring of an application.
It can be understood that the above-mentioned monitoring method for data processing requests can be implemented by the monitoring device for data processing requests provided in the embodiments of the present application, and the monitoring device for data processing requests can be part or all of a certain device, such as a server.
The following takes a processor integrated or installed with relevant execution codes as an example, and details the technical solution of the embodiments of the present application with specific embodiments. The following several specific embodiments may be combined with each other, and details of the same or similar concepts or processes may not be repeated in some embodiments.
Fig. 3 is a flowchart of a method for monitoring a data processing request according to an embodiment of the present application, which relates to a process of monitoring a data processing request of a target transaction. As shown in fig. 3, the method includes:
s301, receiving a data processing request of the target transaction.
In the embodiment of the application, when a transaction is generated, a data processing request of a target transaction can be sent to the server, so that exception monitoring on data of the target transaction is requested.
It should be noted that the target transaction in the embodiments of the present application is not limited, and in some embodiments, the target transaction may be any transaction generated by any application, and in other embodiments, the target transaction may also be a transaction generated by a cross-system application.
It should be understood that, in the embodiment of the present application, the calling manner when the application generates the target transaction is also not limited in the embodiment of the present application, and for example, the calling manner may include a manner of a back-end instruction sending call and a manner of a front-end direct call.
S302, obtaining log data generated by target transaction.
In this step, after the server receives the data processing request of the target transaction, the log data generated by the target transaction may be acquired.
It should be understood that the embodiment of the present application is not limited to how to obtain log data generated by a target transaction, and in some embodiments, obtaining the log data may output the log data by using log frameworks such as log4net, log4j, log back, and the like, and the generated log data is provided for subsequent analysis.
In some embodiments, the output of the log data may be in an Extensible Markup Language (EML) tag format. The log data may include exception indication information and an application identifier.
For example, the abnormal indication information may be an application return code, the application identifier may be an application number, and the server may obtain a corresponding application number and a value of the application return code according to the application number and a tag name of the application return code. For example, the log with the application number YYBH0001 and the application return code WARN0001 outputs the log data in the form of XML tags "</application number > YYBH0001< application number > </return code > WARN0001< return code >.
It should be understood that the above mentioned application identifiers have uniqueness, that is, each application corresponds to a unique application identifier, and there is no case where one application identifier is used by multiple applications or one application uses multiple application identifiers.
It should be understood that exception indication information and application call success indication information may be included in the log data. The indication that the application call was successful is consistent. The exception indication information may be specifically set according to the exception type of the application, which may be a possible exception, or an unexpected exception may occur in the application calling process, and each type of exception corresponds to different exception indication information, so that the server may determine the type of the generated exception according to the exception indication information. For example, the anomaly indication information corresponding to the anomaly of the first type may be WARN0001, and the anomaly indication information corresponding to the anomaly of the second type may be ERROR 0001.
S303, determining whether to perform exception processing on the data of the target transaction according to exception indication information in log data generated by the target transaction, wherein the exception indication information is used for indicating an exception type applied when the target transaction is processed.
In this step, after the server obtains the log data generated by the target transaction, it may be determined whether to perform exception processing on the data of the target transaction according to the exception indication information in the log data generated by the target transaction.
It should be understood that, in the embodiment of the present application, how to determine whether to perform exception processing on data of a target transaction is not limited, in some embodiments, the server may match an exception type indicated by the exception indication information with a white list, where the white list includes an exception type meeting a preset rule. And if the abnormal type indicated by the abnormal indication information is not in the white list, performing abnormal processing on the data of the target transaction. And if the abnormal type indicated by the abnormal indication information is in the white list, releasing the data processing request of the target transaction.
Further, in other embodiments, before white list matching, the server may further match the application identifier in the log data generated by the target transaction with the list of applications to be monitored. And if the application identifier is in the application list to be monitored, matching the abnormal type indicated by the abnormal indication information with a white list. And if the application identifier is not in the application list to be monitored, releasing the data processing request of the target transaction.
It should be understood that, in the embodiment of the present application, there is no limitation to information included in the to-be-monitored application list, and in some embodiments, the to-be-monitored application list may include an application identifier and a configuration time written into the to-be-monitored application list. Illustratively, table 1 is a list of applications to be monitored provided in an embodiment of the present application.
TABLE 1
Serial number Application identification Configuring time
1 Applications A 2021/02/03
2 Application B 2021/02/05
It should be understood that the information included in the white list is not limited in the embodiments of the present application, and in some embodiments, the white list may include the application identifier, the abnormal indication information, and the configuration time written into the white list. The abnormal indication information of the application configured in the white list can be skipped without exception handling. Illustratively, table 2 is a white list provided in the embodiments of the present application.
TABLE 2
Serial number Application numbering Abnormality indication information Configuring time
1 Applications C Exception 1 2021/03/03
2 Applications D Anomaly 2 2021/03/05
It should be understood that, in the embodiment of the present application, how to perform exception handling is not limited, and may be specifically set according to an actual situation. In some embodiments, the server may store description data for the target transaction. Wherein the description data of the target transaction comprises: the method comprises the steps of service identification, application identification, abnormal indication information, log data generation time, log data identification and target transaction error information of target transaction.
For example, the description data of the target transaction may be stored in an exception information table, and table 3 is an exception information table provided in the embodiment of the present application.
TABLE 3
In other embodiments, the exception handling is performed on the data of the target transaction, and the method further includes determining a terminal device to be alerted according to the exception indication information and the application identifier. And then, the server sends the alarm information of the target transaction to the terminal equipment to be alarmed.
In some embodiments, before receiving the data processing request of the target transaction, the server may further receive configuration modification information, and modify the exception type in the white list and/or modify the application identifier in the application list to be monitored according to the configuration modification information.
In the application, the application identification needing to be monitored can be configured in the application list to be monitored by configuring the modification information, so that cross-system application with high complexity and large transaction amount in a system is concerned, the purpose is stronger, and a large amount of manpower and material resources are prevented from being spent on the application with low priority. And the abnormal indication information which accords with the preset rule can be eliminated by setting the white list, the abnormal indication information which can be predicted is automatically filtered, and the precision is improved.
The method for monitoring the data processing request provided by the embodiment of the application comprises the steps of firstly receiving the data processing request of the target transaction, then obtaining log data generated by the target transaction, and finally determining whether to carry out exception processing on the data of the target transaction according to exception indication information in the log data generated by the target transaction, wherein the exception indication information is used for indicating an exception type applied when the target transaction is processed. By the method, when the data processing request of the target transaction is received, whether the data of the target transaction is subjected to exception processing is determined in real time according to the exception indication information in the log data, so that the exception processing time is shortened, and the exception is repaired in real time.
On the basis of the above-described embodiment, how to determine whether to perform exception processing on data of a target transaction is described below. Fig. 4 is a schematic flowchart of another monitoring method for data processing requests according to an embodiment of the present application, and as shown in fig. 4, the method includes:
s401, receiving a data processing request of the target transaction.
S402, obtaining log data generated by the target transaction.
S403, matching the application identifier in the log data generated by the target transaction with the application list to be monitored, and determining whether the application identifier is in the application list to be monitored.
If yes, go to step S405, otherwise go to step S404.
S404, releasing the data processing request of the target transaction.
S405, matching the abnormal type indicated by the abnormal indication information with a white list, and determining whether the abnormal type indicated by the abnormal indication information is in the white list, wherein the white list comprises the abnormal type meeting a preset rule.
If yes, go to step S404, otherwise go to step S406.
And S406, performing exception processing on the data of the target transaction.
The technical terms, technical effects, technical features, and alternative embodiments of S401 to S406 can be understood with reference to S201 to S203 shown in fig. 3, and repeated descriptions thereof will not be repeated here.
On the basis of the above-described embodiment, how to perform exception handling is described below. Fig. 5 is a schematic flowchart of a monitoring method for a data processing request according to an embodiment of the present application, where as shown in fig. 5, the method includes:
s501, receiving a data processing request of the target transaction.
And S502, acquiring log data generated by the target transaction.
S503, determining whether to perform exception processing on the data of the target transaction according to exception indication information in log data generated by the target transaction, wherein the exception indication information is used for indicating an exception type applied when the target transaction is processed.
S504, storing description data of the target transaction;
wherein the description data of the target transaction comprises: the method comprises the steps of service identification, application identification, abnormal indication information, log data generation time, log data identification and target transaction error information of target transaction.
And S505, determining the terminal equipment to be alarmed according to the abnormal indication information and the application identifier.
S506, sending the alarm information of the target transaction to the terminal equipment to be alarmed.
The technical terms, technical effects, technical features and alternative embodiments of S501 to S506 can be understood by referring to S201 to S203 shown in fig. 3, and repeated descriptions will not be repeated here.
The method for monitoring the data processing request provided by the embodiment of the application comprises the steps of firstly receiving the data processing request of the target transaction, then obtaining log data generated by the target transaction, and finally determining whether to carry out exception processing on the data of the target transaction according to exception indication information in the log data generated by the target transaction, wherein the exception indication information is used for indicating an exception type applied when the target transaction is processed. By the method, when the data processing request of the target transaction is received, whether the data of the target transaction is subjected to exception processing is determined in real time according to the exception indication information in the log data, so that the exception processing time is shortened, and the exception is repaired in real time.
Those of ordinary skill in the art will understand that: all or part of the steps for implementing the method embodiments may be implemented by hardware related to program instructions, and the program may be stored in a computer readable storage medium, and when executed, the program performs the steps including the method embodiments; and the aforementioned storage medium includes: various media that can store program codes, such as ROM, RAM, magnetic or optical disks.
Fig. 6 is a schematic structural diagram of a monitoring device for data processing requests according to an embodiment of the present application. The monitoring device of the data processing request may be implemented by software, hardware or a combination of the two, and may be, for example, the server in the above embodiment, to execute the monitoring method of the data processing request in the above embodiment. As shown in fig. 6, the data processing request monitoring apparatus 600 includes:
a receiving module 601, configured to receive a data processing request of a target transaction;
the processing module 602 is configured to obtain log data generated by a target transaction; and determining whether to perform exception processing on the data of the target transaction according to exception indication information in log data generated by the target transaction, wherein the exception indication information is used for indicating the exception type of application occurring when the target transaction is processed.
In an optional implementation manner, the processing module 602 is specifically configured to match an exception type indicated by the exception indication information with a white list, where the white list includes an exception type meeting a preset rule; and if the abnormal type indicated by the abnormal indication information is not in the white list, performing abnormal processing on the data of the target transaction.
In an optional embodiment, the processing module 602 is further configured to release the data processing request of the target transaction if the exception type indicated by the exception indication information is in a white list.
In an optional implementation manner, the processing module 602 is specifically configured to match an application identifier in log data generated by a target transaction with an application list to be monitored; and if the application identifier is in the application list to be monitored, matching the abnormal type indicated by the abnormal indication information with a white list.
In an optional embodiment, the processing module 602 is further configured to release the data processing request of the target transaction if the application identifier is not in the list of applications to be monitored.
In an optional embodiment, the processing module 602 is specifically configured to store description data of the target transaction; wherein the description data of the target transaction comprises: the method comprises the steps of service identification, application identification, abnormal indication information, log data generation time, log data identification and target transaction error information of target transaction.
In an optional implementation manner, the processing module 602 is specifically configured to determine, according to the abnormal indication information and the application identifier, a terminal device to be warned; and sending alarm information of the target transaction to the terminal equipment to be alarmed.
In an optional embodiment, the receiving module 601 is further configured to receive configuration modification information;
the processing module 602 is further configured to modify the exception type in the white list and/or modify the application identifier in the application list to be monitored according to the configuration modification information.
It should be noted that the monitoring apparatus for data processing request provided in the embodiment shown in fig. 6 may be used to execute the method provided in any of the above embodiments, and the specific implementation manner and the technical effect are similar, and are not described herein again.
Fig. 7 is a schematic structural diagram of an electronic device according to an embodiment of the present application. As shown in fig. 7, the electronic device may include: at least one processor 701 and a memory 702. Fig. 7 shows an electronic device as an example of a processor.
And a memory 702 for storing programs. In particular, the program may include program code including computer operating instructions.
The memory 702 may comprise high-speed RAM memory, and may also include non-volatile memory (non-volatile memory), such as at least one disk memory.
The processor 701 is configured to execute computer-executable instructions stored in the memory 702 to implement the monitoring method for the data processing request;
the processor 701 may be a Central Processing Unit (CPU), an Application Specific Integrated Circuit (ASIC), or one or more Integrated circuits configured to implement the embodiments of the present Application.
Optionally, in a specific implementation, if the communication interface, the memory 702 and the processor 701 are implemented independently, the communication interface, the memory 702 and the processor 701 may be connected to each other through a bus and perform communication with each other. The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended ISA (EISA) bus, or the like. Buses may be classified as address buses, data buses, control buses, etc., but do not represent only one bus or type of bus.
Alternatively, in a specific implementation, if the communication interface, the memory 702 and the processor 701 are integrated into a chip, the communication interface, the memory 702 and the processor 701 may complete communication through an internal interface.
The embodiment of the application also provides a chip which comprises a processor and an interface. Wherein the interface is used for inputting and outputting data or instructions processed by the processor. The processor is configured to perform the methods provided in the above method embodiments. The chip can be applied to a monitoring device for data processing requests.
The present application also provides a computer-readable storage medium, which may include: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, are specifically, the computer-readable storage medium stores program information, and the program information is used in the monitoring method of the data processing request.
Embodiments of the present application further provide a program, which when executed by a processor, is configured to perform the monitoring method for data processing request provided in the above method embodiments.
Embodiments of the present application further provide a program product, such as a computer-readable storage medium, having stored therein instructions, which, when run on a computer, cause the computer to perform the method for monitoring a data processing request provided by the foregoing method embodiments.
In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. The procedures or functions according to the embodiments of the invention are brought about in whole or in part when the computer program instructions are loaded and executed on a computer. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wire (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wirelessly (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the available media. The usable medium may be a magnetic medium (e.g., floppy Disk, hard Disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., Solid State Disk (SSD)), among others.
Finally, it should be noted that: the above embodiments are only used to illustrate the technical solution of the present invention, and not to limit the same; while the invention has been described in detail and with reference to the foregoing embodiments, it will be understood by those skilled in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present invention.

Claims (19)

1. A method for monitoring data processing requests, the method comprising:
receiving a data processing request of a target transaction;
acquiring log data generated by the target transaction;
and determining whether to perform exception processing on the data of the target transaction according to exception indication information in log data generated by the target transaction, wherein the exception indication information is used for indicating an exception type applied when the target transaction is processed.
2. The method of claim 1, wherein the determining whether to exception data of the target transaction comprises:
matching the abnormal type indicated by the abnormal indication information with a white list, wherein the white list comprises the abnormal type meeting a preset rule;
and if the abnormal type indicated by the abnormal indication information is not in the white list, performing abnormal processing on the data of the target transaction.
3. The method according to claim 2, wherein after said matching the abnormality type indicated by the abnormality indication information with a white list, the method further comprises:
and if the abnormal type indicated by the abnormal indication information is in the white list, releasing the data processing request of the target transaction.
4. The method of claim 2, wherein the matching the anomaly type indicated by the anomaly indication information with a white list comprises:
matching the application identifier in the log data generated by the target transaction with an application list to be monitored;
and if the application identifier is in the application list to be monitored, matching the abnormal type indicated by the abnormal indication information with the white list.
5. The method of claim 4, wherein after matching the application identifier in the log data generated by the target transaction with the list of applications to be monitored, the method further comprises:
and if the application identifier is not in the application list to be monitored, releasing the data processing request of the target transaction.
6. The method of claim 4, wherein the exception handling of the data of the target transaction comprises:
storing description data of the target transaction;
wherein the description data of the target transaction comprises: the service identification of the target transaction, the application identification, the abnormal indication information, the generation time of the log data, the identification of the log data and the error information of the target transaction.
7. The method of claim 4, wherein the exception handling of the data of the target transaction further comprises:
determining the terminal equipment to be alarmed according to the abnormal indication information and the application identifier;
and sending the alarm information of the target transaction to the terminal equipment to be alarmed.
8. The method of claim 4, wherein prior to said receiving a data processing request for a target transaction, the method further comprises:
receiving configuration modification information;
and according to the configuration modification information, modifying the abnormal type in the white list and/or modifying the application identifier in the application list to be monitored.
9. An apparatus for monitoring data processing requests, the apparatus comprising:
the receiving module is used for receiving a data processing request of a target transaction;
the processing module is used for acquiring log data generated by the target transaction; and determining whether to perform exception processing on the data of the target transaction according to exception indication information in log data generated by the target transaction, wherein the exception indication information is used for indicating an exception type applied when the target transaction is processed.
10. The apparatus according to claim 9, wherein the processing module is specifically configured to match an exception type indicated by the exception indication information with a white list, where the white list includes an exception type that meets a preset rule; and if the abnormal type indicated by the abnormal indication information is not in the white list, performing abnormal processing on the data of the target transaction.
11. The apparatus of claim 10, wherein the processing module is further configured to pass the data processing request of the target transaction if the anomaly type indicated by the anomaly indication information is in the white list.
12. The apparatus according to claim 10, wherein the processing module is specifically configured to match an application identifier in log data generated by the target transaction with a list of applications to be monitored; and if the application identifier is in the application list to be monitored, matching the abnormal type indicated by the abnormal indication information with the white list.
13. The apparatus of claim 12, wherein the processing module is further configured to pass the data processing request of the target transaction if the application identifier is not in the list of applications to be monitored.
14. The apparatus according to claim 12, wherein the processing module is specifically configured to store description data of the target transaction; wherein the description data of the target transaction comprises: the service identification of the target transaction, the application identification, the abnormal indication information, the generation time of the log data, the identification of the log data and the error information of the target transaction.
15. The apparatus according to claim 12, wherein the processing module is specifically configured to determine, according to the abnormal indication information and the application identifier, a terminal device to be alerted; and sending the alarm information of the target transaction to the terminal equipment to be alarmed.
16. The apparatus of claim 12, wherein the receiving module is further configured to receive configuration modification information;
the processing module is further configured to modify the exception type in the white list and/or modify the application identifier in the application list to be monitored according to the configuration modification information.
17. A computer program product comprising a computer program, characterized in that the computer program realizes the method of any of claims 1-8 when executed by a processor.
18. A computer storage medium, characterized in that it stores a plurality of instructions adapted to be loaded by a processor and to perform the method steps according to any of claims 1-8.
19. An electronic device, comprising: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to perform the method according to any of claims 1-8.
CN202110687072.8A 2021-06-21 2021-06-21 Method and device for monitoring data processing request Pending CN113297149A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110687072.8A CN113297149A (en) 2021-06-21 2021-06-21 Method and device for monitoring data processing request

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110687072.8A CN113297149A (en) 2021-06-21 2021-06-21 Method and device for monitoring data processing request

Publications (1)

Publication Number Publication Date
CN113297149A true CN113297149A (en) 2021-08-24

Family

ID=77328967

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110687072.8A Pending CN113297149A (en) 2021-06-21 2021-06-21 Method and device for monitoring data processing request

Country Status (1)

Country Link
CN (1) CN113297149A (en)

Similar Documents

Publication Publication Date Title
CN110581887B (en) Data processing method, device, block chain node and storage medium
CN110716848A (en) Data collection method and device, electronic equipment and storage medium
CN108376110B (en) Automatic detection method, system and terminal equipment
CN107256167B (en) Upgrade control method and upgrade control equipment applied to application system migration
CN108255703B (en) SQL script fault repairing method and terminal thereof
CN113297149A (en) Method and device for monitoring data processing request
CN111381940B (en) Distributed data processing method and device
CN108255620B (en) Service logic processing method, device, service server and system
CN111130938A (en) Index acquisition method and device, electronic equipment and computer readable storage medium
CN109582655B (en) Method and device for positioning system log and computer readable storage medium
CN111679968A (en) Interface calling abnormity detection method and device, computer equipment and storage medium
CN110851207A (en) State transition management method and device, electronic equipment and computer readable storage medium
CN110727581A (en) Collapse positioning method and electronic equipment
CN108509322B (en) Method for avoiding excessive return visit, electronic device and computer readable storage medium
CN108595178B (en) Hook-based data acquisition method, device and equipment
CN108647102B (en) Service request processing method and device of heterogeneous system and electronic equipment
CN108804215B (en) Task processing method and device and electronic equipment
CN108459940B (en) Configuration information modification method and device of application performance management system and electronic equipment
CN112486510A (en) Method and device for software installation, terminal equipment and storage medium
CN112447279A (en) Task processing method and device, electronic equipment and storage medium
CN110807048A (en) Automatic task processing method and device, computer storage medium and electronic equipment
CN114116544A (en) Method, device and equipment for acquiring slot information and storage medium
CN111444057A (en) Page performance data acquisition method and device and computing equipment
CN113760635A (en) Method and device for determining connection abnormity, electronic equipment and storage medium
CN112035344A (en) Multi-scenario test method, device, equipment and computer readable storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination