CN112039701B - Interface call monitoring method, device, equipment and storage medium - Google Patents
Interface call monitoring method, device, equipment and storage medium Download PDFInfo
- Publication number
- CN112039701B CN112039701B CN202010879202.3A CN202010879202A CN112039701B CN 112039701 B CN112039701 B CN 112039701B CN 202010879202 A CN202010879202 A CN 202010879202A CN 112039701 B CN112039701 B CN 112039701B
- Authority
- CN
- China
- Prior art keywords
- interface
- call
- data
- calling
- monitoring
- 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.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
- H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3051—Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
- G06F11/324—Display of status information
- G06F11/327—Alarm or error message display
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/04—Processing captured monitoring data, e.g. for logfile generation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/548—Queue
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Signal Processing (AREA)
- Quality & Reliability (AREA)
- Computer Networks & Wireless Communication (AREA)
- Software Systems (AREA)
- Data Mining & Analysis (AREA)
- Mathematical Physics (AREA)
- Environmental & Geological Engineering (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Telephonic Communication Services (AREA)
Abstract
The invention relates to the field of artificial intelligence, and discloses an interface call monitoring method, device, equipment and storage medium, wherein the method comprises the following steps: receiving an interface calling instruction sent by a client and used for calling a communication interface on a providing end, acquiring calling data and/or interaction data generated in the process of calling the communication interface based on the interface calling instruction, generating a queue message according to the calling data and/or interaction data, synchronizing the queue message into a monitoring database for recording, monitoring the queue message in real time, determining the actual calling condition of the communication interface, and judging whether to send an alarm mail or not based on the actual calling condition. The present invention also relates to blockchain techniques, the queue messages being stored in the blockchain. The invention realizes the integrated monitoring of calling and data and the monitoring of service operation, and improves the operability of interface maintenance. The interface invokes monitoring.
Description
Technical Field
The present invention relates to the field of artificial intelligence, and in particular, to a method, apparatus, device, and storage medium for monitoring interface call.
Background
With the development of service diversity, the complexity, stability and maintainability of the corresponding system are also more and more difficult to control. With the rising and developing of service system service, another problem brought about by the system service is the secure implementation of communication interfaces, especially for traditional finance companies, internet finance companies and other business internet companies, where the business of these companies often involves the arrival and departure of a large number of businesses. Interface calls to these corporate systems often affect the interactive use of business by users or companies, so they need to be monitored to quickly intervene in unusual situations, preventing further development of adverse events.
At present, the processing of interface call abnormality in the industry is mainly realized through a unified background technology framework, and the mode can monitor the call abnormality of a single interface, but cannot sense the influence of the abnormality of service data interaction on the system operation, especially the call of a personalized interface with the system interface type in near real time, and is difficult to realize the simultaneous monitoring of interface call and interface data.
Disclosure of Invention
The invention mainly aims to solve the technical problem that the operation condition and the service operation condition of an integrated monitoring system are difficult to realize in the prior art.
The first aspect of the present invention provides an interface call monitoring method, including:
receiving an interface calling instruction sent by a client for calling a communication interface on a provider;
acquiring call data and/or interaction data generated in the process of calling the communication interface based on the interface call instruction;
generating a queue message according to the call data and/or the interaction data, and synchronizing the queue message to a monitoring database for recording;
and monitoring the queue information in real time, determining the actual calling condition of the communication interface, and judging whether to send an alarm mail or not based on the actual calling condition.
Optionally, in a first implementation manner of the first aspect of the present invention, the acquiring call data and/or interaction data generated in a process of calling the communication interface based on the interface call instruction includes:
analyzing the interface calling instruction to obtain the interface type of the communication interface requested to be called;
based on the interface type, inquiring corresponding interface protocol information from the providing end, wherein the interface protocol information comprises an input parameter, an output parameter, a routing rule, a calling timeout time and a data mapping rule;
Calling the communication interface by using the routing rule, and recording the parameter entering and exiting, the actual calling time and the calling times when the communication interface is called;
and acquiring interaction data returned in the process of calling the communication interface, and sending the interaction data to a user according to the data mapping rule.
Optionally, in a second implementation manner of the first aspect of the present invention, the generating a queue message according to the call data and/or the interaction data, and synchronizing the queue message to a monitoring database for recording includes:
judging whether the calling times are larger than the preset maximum repeated calling times or not to obtain a judging result;
determining an interface alarm type based on the judging result;
generating an interface call log by the parameter entering, parameter exiting, interface alarm type and interaction data, and writing the interface call log into a queue message;
and synchronizing the queue information containing the interface call log to a monitoring database for recording.
Optionally, in a third implementation manner of the first aspect of the present invention, synchronizing the queue message including the interface call log to the monitoring database for recording includes:
Acquiring a push function of the communication interface to the queue message;
extracting annotation parameters in the push function, and judging the value of the annotation parameters, wherein the annotation parameters are used for indicating the type of the queue message;
and based on the value, selecting information which does not accord with the type from the queue information to delete, obtaining new queue information, and synchronizing the new queue information to the monitoring database for recording.
Optionally, in a fourth implementation manner of the first aspect of the present invention, the types include a normal interface alarm type and a personalized interface alarm type; and selecting information which does not accord with the type from the queue information to delete according to the value to obtain new queue information, and synchronizing the new queue information to the monitoring database for recording, wherein the method comprises the following steps:
judging whether the value is empty or not;
if the value is empty, determining that the alarm type carried in the queue message is common interface call, and shielding information about interface personalized call in the queue message to obtain a second queue message;
if the value is not empty, determining that the alarm type carried in the queue message is interface personalized call, and shielding information about common interface call in the queue message to obtain a third queue message;
And sending the second queue message or the third queue message to the monitoring database for storage.
Optionally, in a fifth implementation manner of the first aspect of the present invention, the sending the second queue message or the third queue message to the monitoring database storage includes:
setting two different data table templates in the monitoring database, wherein each data table template corresponds to one type of queue message;
and mapping the parameter entering, parameter exiting, actual calling time and calling times carried in the second queue message or the third queue message into corresponding data table templates in sequence according to the data mapping rule and the actual calling time to obtain a data record table.
Optionally, in a sixth implementation manner of the first aspect of the present invention, the monitoring the queue message in real time, determining an actual call condition of the communication interface, and determining whether to send an alert mail based on the actual call condition includes:
monitoring the calling times in the data record table through a queue monitor;
judging whether the calling times meet the preset maximum repetition times or not;
if not, determining that the communication interface call fails, and sending an alarm mail;
If yes, detecting whether the interaction data recorded in the data recording table is effective interaction;
if not, determining that the communication interface call fails, and sending an alarm mail.
The second aspect of the present invention provides an interface call monitoring device, including:
the receiving module is used for receiving an interface calling instruction sent by the client and used for calling a communication interface on the providing end;
the acquisition module is used for acquiring call data and/or interaction data generated in the process of calling the communication interface based on the interface call instruction;
the processing module is used for generating a queue message according to the calling data and/or the interaction data, and synchronizing the queue message to a monitoring database for recording;
and the alarm module is used for monitoring the queue message in real time, determining the actual calling condition of the communication interface and judging whether to send alarm mail or not based on the actual calling condition.
Optionally, in a first implementation manner of the second aspect of the present invention, the acquisition module includes:
the analyzing unit is used for analyzing the interface calling instruction to obtain the interface type of the communication interface which is requested to be called;
the query unit is used for querying interface protocol information corresponding to the interface type from the providing end based on the interface type, wherein the interface protocol information comprises an input parameter, an output parameter, a routing rule, a calling timeout time and a data mapping rule;
The call recording unit is used for calling the communication interface by utilizing the routing rule and recording the input parameters, the output parameters, the actual calling time and the calling times when the communication interface is called;
and the interaction unit is used for acquiring interaction data returned in the process of calling the communication interface and sending the interaction data to a user according to the data mapping rule.
Optionally, in a second implementation manner of the second aspect of the present invention, the processing module includes:
the judging unit is used for judging whether the calling times are larger than the preset maximum repeated calling times or not to obtain a judging result;
the determining unit is used for determining the interface alarm type based on the judging result;
the writing unit is used for generating an interface call log from the input parameter, the output parameter, the interface alarm type and the interaction data and writing the interface call log into a queue message;
and the synchronizing unit is used for synchronizing the queue information containing the interface call log to the monitoring database for recording.
Optionally, in a third implementation manner of the second aspect of the present invention, the synchronization unit is specifically configured to:
acquiring a push function of the communication interface to the queue message;
Extracting annotation parameters in the push function, and judging the value of the annotation parameters, wherein the annotation parameters are used for indicating the type of the queue message;
and based on the value, selecting information which does not accord with the type from the queue information to delete, obtaining new queue information, and synchronizing the new queue information to the monitoring database for recording.
Optionally, in a fourth implementation manner of the second aspect of the present invention, the types include a normal interface alarm type and a personalized interface alarm type; the synchronization unit is specifically configured to:
judging whether the value is empty or not;
if the value is empty, determining that the alarm type carried in the queue message is common interface call, and shielding information about interface personalized call in the queue message to obtain a second queue message;
if the value is not empty, determining that the alarm type carried in the queue message is interface personalized call, and shielding information about common interface call in the queue message to obtain a third queue message;
and sending the second queue message or the third queue message to the monitoring database for storage.
Optionally, in a fifth implementation manner of the second aspect of the present invention, the synchronization unit is specifically configured to:
setting two different data table templates in the monitoring database, wherein each data table template corresponds to one type of queue message;
and mapping the parameter entering, parameter exiting, actual calling time and calling times carried in the second queue message or the third queue message into corresponding data table templates in sequence according to the data mapping rule and the actual calling time to obtain a data record table.
Optionally, in a sixth implementation manner of the second aspect of the present invention, the alarm module is specifically configured to:
monitoring the calling times in the data record table through a queue monitor;
judging whether the calling times meet the preset maximum repetition times or not;
if not, determining that the communication interface call fails, and sending an alarm mail;
if yes, detecting whether the interaction data recorded in the data recording table is effective interaction;
if not, determining that the communication interface call fails, and sending an alarm mail.
A third aspect of the present invention provides an interface call monitoring apparatus, comprising: a memory and at least one processor, the memory having instructions stored therein, the memory and the at least one processor being interconnected by a line; the at least one processor invokes the instructions in the memory to cause the interface call monitoring device to execute the interface call monitoring method described above.
A fourth aspect of the present application provides a computer readable storage medium having instructions stored therein which, when run on a computer, cause the computer to perform the interface call monitoring method described above.
In the technical scheme of the application, in the process of monitoring and controlling, the monitoring client sends an interface calling instruction for calling the interface on the server, call data and interaction data of the interface are obtained based on the instruction, then queue information is generated through the call data and the interaction data and synchronously recorded, and finally the condition of calling the interface is judged through monitoring the queue information in real time, so that corresponding interface alarm is generated; the application monitors the call data of the interface call and the interactive data after the call, not only realizes the integrated monitoring of the call and the data, but also realizes the monitoring of the service operation, and the monitoring of the queue information can reduce the consumption expenditure of the system for monitoring the interface, realize the monitoring of supporting a large data amount at the same time, and greatly improve the operability of the interface maintenance.
Drawings
FIG. 1 is a diagram of a first embodiment of an interface call monitoring method according to an embodiment of the present application;
FIG. 2 is a diagram of a second embodiment of an interface call monitoring method according to an embodiment of the present invention;
FIG. 3 is a diagram of a third embodiment of an interface call monitoring method according to an embodiment of the present invention;
FIG. 4 is a schematic diagram of an interface call record encoding provided in an embodiment of the present invention;
FIG. 5 is a schematic diagram of an embodiment of an interface call monitor according to an embodiment of the present invention;
FIG. 6 is a schematic diagram of another embodiment of an interface call monitor according to an embodiment of the present invention;
FIG. 7 is a schematic diagram of an embodiment of an interface call monitor device according to an embodiment of the present invention.
Detailed Description
The embodiment of the invention provides an interface call monitoring method, an interface call monitoring device, interface call monitoring equipment and a storage medium. The monitor in the scheme monitors the messages, decides whether to record the running condition of the system and the running condition of the service according to the preset monitoring type, and simultaneously judges whether to send an Internet alarm notification or other preset alarm short messages so as to facilitate the staff to rapidly process the alarm and reduce more adverse effects of the alarm problem on the system or the service. The scheme improves the accuracy of monitoring the system and service operation conditions, greatly shortens the time difference of occurrence of problems and manual intervention, has extremely low additional performance cost of interface call, can support billion-level monitoring information at the same time, and can basically meet the monitoring requirements of most enterprises.
The terms "first," "second," "third," "fourth" and the like in the description and in the claims and in the above drawings, if any, are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments described herein may be implemented in other sequences than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed or inherent to such process, method, article, or apparatus.
For easy understanding, the following describes a specific flow of an embodiment of the present invention, referring to fig. 1, and a first embodiment of an interface call monitoring method in an embodiment of the present invention includes:
101. receiving an interface calling instruction sent by a client;
it can be understood that the execution body of the present invention may call the monitoring device for the interface, and may also be a terminal or a server, which is not limited herein. The embodiment of the invention is described by taking a server as an execution main body as an example.
In this embodiment, the interface call instruction refers to an instruction for calling a communication interface on the interface providing end, and the communication interface may be understood as a network interface or a wireless interface, or may even be an NFC interface or the like, so long as the interface can achieve communication and data interaction between the client and the providing end.
In this step, the interface call instruction is an interface call command generated when the user initiates service processing through access software or the terminal, where the command includes type information of a communication interface to be invoked, and even may be a function type implemented by the initiated service, and the corresponding communication interface may be directly found through a mapping relationship of the interface based on the function type or the type information.
In practical application, the instruction may also carry the data of the service to be interacted, and after the service system completes the call of the interface, the data of the service is directly sent out through the communication interface.
In practical application, when receiving the interface call instruction, the server monitors the service condition of each interface on the interface providing end, specifically can monitor the 0 or 1 setting state of the interface, when 1, it indicates that the interface has been called, and then the interface call instruction of the interface is obtained from the control device connected with the providing end, or the interface call instruction is obtained from the instruction library on the providing end.
102. Acquiring call data and/or interaction data generated in the process of calling a communication interface based on an interface call instruction;
in this embodiment, an interface call instruction is first parsed to obtain an interface type and an interface number carried in the instruction, an interface list on a providing end is traversed based on the interface type and the interface number, a corresponding interface is found, then an IP address of the interface is obtained, a log of the operation of the interface is determined based on the IP address, in practical application, all the records of the call of the interface of the providing end are recorded in a large log table, the call or the operation record of the corresponding interface can be determined through the inquiry of the IP address, the operation record of the interface is extracted after the time of executing the interface call instruction, call data of the interface is formed, and the call data includes call parameters when the communication connection between the interface and a client is realized according to the instruction.
In this embodiment, after the call data is obtained, the method further includes determining whether the data recorded in the call data is a record of successful call, and if so, obtaining the interactive data implemented by the interface between the client side providing ends, specifically, calling from the buffer corresponding to the interface. In practical application, the method for calling the interactive data further comprises the step of acquiring the data interacted by the interface through the monitoring interception mode.
In this embodiment, the call data includes a parameter in, a parameter out, interface information, interface response time consumption, and flag information for marking whether the communication interface call is successful; the call data is generated by the service processing system when the interface call is triggered.
In practical applications, the call data is necessarily present, and the interactive data may exist, for example, the interactive data is null, because the call of the interface is successful, but the service function implemented through the communication interface is not completed, so that the interactive data will not be generated.
Optionally, when the call is turned on, protocol information required by each communication interface in the background system maintenance interface warehouse is recorded, protocol information such as the entering parameter, the exiting parameter, the calling time, the interface type, the routing rule, the data mapping rule and the like required by the call of the interfaces is recorded, and the protocol information is stored in a database. The following is an example of a third party communication interface url: http:// a.jd.com/fetcha=zhang & b= 3&c =4, the communication interface needs to be disassembled during call, call data is formed in the form of json strings, and finally a database storage file is formed.
Call data of an in-parameter, an out-parameter, a call time, an interface type, a routing rule, a data mapping rule and the like which are required when the interfaces are called can be obtained through the json string. Since the interface repository has background system storage management.
103. Generating a queue message according to the call data and/or the interaction data, and synchronizing the queue message to a monitoring database for recording;
in this embodiment, when generating the queue message, the queue message is mainly generated based on the call data, and the interaction data is carried in the queue message, which is naturally added to the queue message after being processed according to the communication protocol in the communication interface. It should be emphasized that, to further ensure the privacy and security of the queue messages, the queue messages may be stored in a blockchain node in the monitoring database when synchronized to the monitoring database records.
In practical application, the queue message can be generated specifically by monitoring the record requirement of the database, even can be generated by a message conversion model, optionally, the disassembled call data is converted according to the storage format of the monitoring database to generate the queue message, then whether the interactive data is generated in the interface interaction is judged, if so, the interactive data is embedded into the queue message and sent out, and the monitoring database is preferably selected as a queue message assisting server (MQ browser) to realize.
104. And monitoring the queue information in real time, determining the actual calling condition of the communication interface, and judging whether to send the alarm mail or not based on the actual calling condition.
In this embodiment, the actual call condition of the communication interface is determined by monitoring the queue message, specifically, by monitoring the call times and alarm type information in the queue message, whether the call of the interface is successful is determined.
In this embodiment, whether the interface call is successful or not is determined, and it is required to determine from two aspects, that is, whether the communication connection between the communication interface and the client is successfully established and there is data interaction on the communication interface, that is, whether the connection state of the communication interface is 1 is determined first, if yes, whether the queue message carries interactive data or whether the interactive data carried in the queue message is empty is detected, if no carrying or the data is empty is detected, it is determined that the interface call is unsuccessful, and an alarm mail is sent. If the carried data are detected to be non-empty, the interface call is determined to be successful, further, the interactive data are acquired to be analyzed, whether the interactive data are service data appointed in the interface call instruction or not is analyzed, and if yes, the interface call is determined to be successful.
If the connection state of the communication interface is not 1, the interface call is directly determined to be unsuccessful, and the alarm processing step is executed.
In practical application, the queue message is set to have a function of repeated sending, so that the step can also determine whether the call of the interface is successful or not by detecting the call times carried in the queue message according to the call times for repeated call times, and retry the designated times when the MQ consumer does not return the consumption success. If the test fails after the specified number of retries, an alarm is given. Of course, it may also be determined by detecting whether a queue message is received in the monitoring database.
By executing the method, the monitoring is performed according to the calling data and the interaction data of the interface, so that whether the calling of the interface is successful or not can be realized, whether the called service function of the interface is realized or not can be also be realized, and the accuracy of the monitoring of the calling of the interface is greatly improved.
Referring to fig. 2, a second embodiment of an interface call monitoring method according to an embodiment of the present invention includes:
201. Receiving an interface calling instruction sent by a client for calling a communication interface on a provider;
202. analyzing the interface calling instruction to obtain the interface type of the communication interface which is requested to be called;
203. based on the interface type, inquiring interface protocol information corresponding to the interface type from the providing end, wherein the interface protocol information comprises an input parameter, an output parameter, a routing rule, a calling timeout time and a data mapping rule;
204. calling a communication interface by using a routing rule, and recording the parameter entering and exiting, the actual calling time and the calling times when the communication interface is called;
205. acquiring interactive data returned in the process of calling a communication interface, and sending the interactive data to a user according to a data mapping rule;
in this embodiment, the protocol information of the corresponding interface may be queried, specifically by querying from an interface repository in the provider, where the interface repository may be understood as a database or a data table of the provider for storing information of the third party communication interface.
In practical applications, the interface types include, but are not limited to: http Get and Http Post, and Web service. The routing rules include, but are not limited to: default routing rules, cookie routing rules, and request header routing rules. When the communication interface is called according to the routing rule, calculating a cache key of the called communication interface according to the routing rule, storing the called communication interface in a shared cache of Nginx or Redis, establishing a corresponding relation table, and directly inquiring and calling according to the stored corresponding relation table when in actual use.
In practical application, the acquired interactive data can be acquired through the following two modes, namely, the interactive data is directly acquired from an interface calling instruction, and the interactive data is directly received and read from a user terminal after the interface calling is successful, and the mode can be used for receiving the data of the user terminal after the interface calling is successful.
206. Generating a queue message according to the call data and/or the interaction data, and synchronizing the queue message to a monitoring database for recording;
in this embodiment, since the queue message itself has a retry function, when the communication interface is called, multiple call retries can be performed, and each retry corresponds to recording a parameter, determining whether the interface call is successful based on the parameter, and generating a corresponding interface alarm type in combination with the outbound setting of the message corresponding to the providing end;
further, other parameters generated when the interface is called, such as parameters of in-parameter, out-parameter, interaction data and the like, are obtained, and a corresponding queue message is generated with the interface alarm type.
Of course, after the queue message is generated, the operation may be retried based on the queue message, and the record of the repetition number of the retry operation parameter may be embedded into the queue message and synchronized to the database, so as to realize synchronous monitoring of the message. The method can achieve the purpose of monitoring and can also improve the success rate of interface calling.
In this embodiment, the specific implementation of this step may obtain the determination result by determining whether the number of calls is greater than a preset maximum number of repeated calls; determining an interface alarm type based on the judging result; generating an interface call log by the parameter entering, parameter exiting, interface alarm type and interaction data, and writing the interface call log into a queue message; and synchronizing the queue information containing the interface call log to a monitoring database for recording.
207. And monitoring the queue information in real time, determining the actual calling condition of the communication interface, and judging whether to send the alarm mail or not based on the actual calling condition.
In the embodiment of the invention, the unified monitoring on whether the interface call is successful or not is realized through the monitoring queue message MQ, and meanwhile, the interactive data is carried in the MQ message, so that the real-time monitoring on the interface data is further realized, and the problem that the interface call is not matched with the data after the call is solved.
Referring to fig. 3, a third embodiment of an interface call monitoring method according to an embodiment of the present invention includes:
301. receiving an interface calling instruction sent by a client;
302. acquiring call data and/or interaction data generated in the process of calling a communication interface based on an interface call instruction;
303. Generating a queue message according to the call data and/or the interaction data;
304. obtaining a pushing function of a communication interface on a queue message;
305. extracting annotation parameters in the push function, and judging the value of the annotation parameters;
306. judging whether the value is empty or not;
in this step, it is determined whether the value is null, specifically by detecting a binary set level in the annotation parameter, where the level is 1 is non-null and the level is 0 is null, specifically, the interface shown in fig. 4 calls the record code.
307. If the value is empty, determining that the alarm type carried in the queue message is a common interface call;
in this embodiment, the generic interface call expressed herein refers to a call not associated with service settlement, such as: only interactions of ordinary traffic, such as sending notification messages, etc., are performed using the interface.
308. Shielding information about interface personalized call in the queue message to obtain a second queue message;
309. if the value is not empty, determining that the alarm type carried in the queue message is interface personalized call;
in this embodiment, the personalized call expressed herein refers to a call associated with service settlement, such as: only the interactions of the business bill, such as transaction codes, amounts, transaction bills, etc., are performed using the interface. In addition, the interface call of the user's custom transmission format is also a personalized call, for example: define business data interaction templates, etc.
310. Shielding information about common interface call in the queue information to obtain a third queue information;
in this embodiment, when synchronizing the queue message to the monitoring database, the providing end controls the type of the synchronized queue message specifically through the sending function, and for different communication interfaces, the specific content of the queue message generated by the providing end may be different, optionally, the queue message may be controlled through an annotation parameter in the function, for example, all data generated when the interface on the providing end is called, and only the call data of the common interface is synchronized in the current synchronization period, where the annotation parameter of the function is set to be synchronous sending of the call data of the common interface only, and of course, the queue message may be controlled through the annotation parameter, that is, the corresponding call data is acquired for the corresponding interface type, so as to generate the queue message meeting the interface type. It should be emphasized that, to further ensure the privacy and security of the queue messages, the queue messages may be stored in a blockchain node in the monitoring database when synchronized to the monitoring database records.
311. Sequentially mapping the input parameter, the output parameter, the actual calling time and the calling times carried in the queue message into corresponding data table templates according to the data mapping rule and the actual calling time to obtain a data record table;
In this embodiment, for the queue messages (MQ messages), two types of MQ topic may be divided, namely, whether the common interface is successful or not alerts topic, and interface individualization alerts topic, whether to send these topics depends on parameters in the comments of the functions of the provider, and only one of them may be sent, or MQ messages of multiple topics may be sent, for example: the parameter type is normal, then only interface level monitoring messages (MQ messages, supra) are sent; if the parameter type is custom, only personalized monitoring messages are sent; if the parameter is both, both types of monitoring messages are sent. It is emphasized that in order to further ensure the accuracy and security of the above data record table, the conversion is stored and recorded in the blockchain when the data record table is generated, specifically by the blockchain technique.
After the listener of the interface alarm MQ topic consumes the MQ message, the success and failure information of the interface is written into the monitoring database DB.
In practical applications, the MQ itself has a retry function, and if the MQ consumer does not return a successful consumption, the MQ consumer retries a specified number of times. If the test fails after the specified number of retries, an alarm is given. Wherein the success and failure of the interface are determined based on a binary error code. As shown in fig. 4, a black-bottomed 0 indicates that no manual intervention is required, and other values indicate that manual intervention is required and that the call fails. In addition, the success of the interface does not indicate the success of the service response, for example, the system returns an interface calling error in the process of paying the premium, and the error information is 'the insufficient balance of the bank card of the user'. Interface invocation errors indicate that technician attention is required, such as a timeout of the downstream system response during a large period.
In this embodiment, after synchronizing the queue message to BD, the method further includes writing or updating the following information into DB: serial number, interface name, minutes (year, month, day, time, minute, second), call total number, call success total number, call failure total number, record creation time, record update time. And inserts the following information into the DB according to the configuration of the provider side: serial number, interface name, key parameter of entering into parameter (can be filled in as id, can be positioned quickly after the problem is solved), entering into parameter, exiting out parameter (including error information error code), recording creation time and recording update time.
The key parameters of the entry are obtained by the entry realization interface of the provider side, the entry and the exit can only store 256 bytes at most in consideration of performance, wherein DB divides a plurality of databases according to years, and the data tables are divided according to months and days. For example: the invention provides an index_2019_db, namely index_08_28_info, wherein the index_2019_db is the DB name, the index_08_28_info is the table name, 2019 is the year, 08 is the month, and 28 is the day, namely 365 physical tables exist in 2019.
After writing or updating the DB, the MQ monitor judges whether to send alarm mail according to the configuration. If the failure rate of one minute exceeds 80%, the failure times of one minute exceeds 20 times. If the sending of the warning mail fails, the retry is performed three times, and if the sending of the warning mail still fails, the sending of the warning mail is ignored.
312. Monitoring a data record table in real time, and determining the actual calling condition of a communication interface;
313. and judging whether to send the alarm mail or not based on the actual calling condition.
In this embodiment, when monitoring the data record table in real time, specifically, monitoring the number of calls in the data record table by a queue monitor;
judging whether the calling times meet the preset maximum repetition times or not;
if not, determining that the communication interface call fails, and sending an alarm mail;
if yes, detecting whether the interaction data recorded in the data recording table is effective interaction;
if not, determining that the communication interface call fails, and sending an alarm mail.
In this embodiment, when monitoring the queue message, specifically, a plug-in may be set on the providing end, and indirect call to the interface may be implemented by controlling the plug-in, and the consumer may call the instruction to schedule the plug-in through the interface, and control the plug-in to call the interface I on the providing end. The plugin asynchronously sends the name of the access parameters and the name of the interface I required by the consumer when the consumer calls the interface of the provider end to the MQ browser as an MQ message. If the MQ message fails to be sent for the first time, the MQ message is retried twice and is ignored if all the MQ messages fail, and the MQ message is not sent any more. The first or second transmission is successful and no more retries are made. The MQ sending exception refers to the communication exception of the application where the plug-in is located as an MQ client and the brooker as an MQ server.
In practical application, the abnormal judging process may be that the MQ monitor judges whether to send the alarm mail according to the configuration. If the failure rate of one minute exceeds 80%, the failure times of one minute exceeds 20 times. If the sending of the warning mail fails, the retry is performed three times, and if the sending of the warning mail still fails, the sending of the warning mail is ignored.
By implementing the scheme, the problem of unified monitoring interface call of a monitored system without success or failure of unified interface call is solved, and the scheme also provides a scheme of near-real-time personalized monitoring by expanding the MQ monitor, such as whether near-real-time monitoring transaction can be checked successfully or not, namely, monitoring whether the function required to be realized by the interface is successful or not is also realized while the interface is called, the integration of calling monitoring and function monitoring is realized, and the monitoring cost is reduced.
The method for monitoring interface call in the embodiment of the present invention is described above, and the device for monitoring interface call in the embodiment of the present invention is described below, referring to fig. 5, where an embodiment of the device for monitoring interface call in the embodiment of the present invention includes:
a receiving module 501, configured to receive an interface call instruction sent by a client and used for calling a communication interface on a provider;
The acquisition module 502 is configured to acquire call data and/or interaction data generated in a process of calling the communication interface based on the interface call instruction;
a processing module 503, configured to generate a queue message according to the call data and/or the interaction data, and synchronize the queue message to a monitoring database for recording;
it should be emphasized that, to further ensure the privacy and security of the queue messages, the queue messages may be stored in a blockchain node in the monitoring database when synchronized to the monitoring database records.
And the alarm module 504 is used for monitoring the queue message in real time, determining the actual calling condition of the communication interface, and judging whether to send an alarm mail or not based on the actual calling condition.
In the embodiment of the invention, the interface call data and the interface interaction data are stored by expanding the queue information, the call condition and the use condition of the interface are monitored based on the queue information, the small overhead monitoring and the unified monitoring of the data are realized, the interface is monitored based on the mode, the intervention can be quickly inserted to solve the problem when the problem occurs, the use of a user is convenient, and the monitoring requirement is met.
Referring to fig. 6, another embodiment of an interface call monitor apparatus according to an embodiment of the present invention includes:
a receiving module 501, configured to receive an interface call instruction sent by a client and used for calling a communication interface on a provider;
the acquisition module 502 is configured to acquire call data and/or interaction data generated in a process of calling the communication interface based on the interface call instruction;
a processing module 503, configured to generate a queue message according to the call data and/or the interaction data, and synchronize the queue message to a monitoring database for recording;
and the alarm module 504 is used for monitoring the queue message in real time, determining the actual calling condition of the communication interface, and judging whether to send an alarm mail or not based on the actual calling condition.
Wherein, the acquisition module 502 includes:
the parsing unit 5021 is configured to parse the interface call instruction to obtain an interface type of the communication interface that is requested to be called;
a query unit 5022, configured to query, based on the interface type, interface protocol information corresponding to the interface type from the providing end, where the interface protocol information includes an in parameter, an out parameter, a routing rule, a call timeout time and a data mapping rule;
A call recording unit 5023, configured to call the communication interface using the routing rule, and record an in-parameter, an out-parameter, an actual call time, and a call number when the communication interface is called;
and the interaction unit 5024 is used for acquiring interaction data returned in the process of calling the communication interface and sending the interaction data to a user according to the data mapping rule.
Wherein, the processing module 503 includes:
a judging unit 5031, configured to judge whether the number of calls is greater than a preset maximum number of repeated calls, to obtain a judgment result;
a determining unit 5032, configured to determine an interface alarm type based on the determination result;
a writing unit 5033, configured to generate an interface call log from the input parameter, the output parameter, the interface alarm type, and the interaction data, and write the interface call log into a queue message;
and the synchronizing unit 5034 is configured to synchronize the queue message including the interface call log to the monitoring database for recording.
Optionally, the synchronization unit 5034 is specifically configured to:
acquiring a push function of the communication interface to the queue message;
extracting annotation parameters in the push function, and judging the value of the annotation parameters, wherein the annotation parameters are used for indicating the type of the queue message;
And based on the value, selecting information which does not accord with the type from the queue information to delete, obtaining new queue information, and synchronizing the new queue information to the monitoring database for recording.
The types comprise a common interface alarm type and a personalized interface alarm type; the synchronization unit 5034 is specifically configured to:
judging whether the value is empty or not;
if the value is empty, determining that the alarm type carried in the queue message is common interface call, and shielding information about interface personalized call in the queue message to obtain a second queue message;
if the value is not empty, determining that the alarm type carried in the queue message is interface personalized call, and shielding information about common interface call in the queue message to obtain a third queue message;
and sending the second queue message or the third queue message to the monitoring database for storage.
Optionally, the synchronization unit 5034 is specifically configured to:
setting two different data table templates in the monitoring database, wherein each data table template corresponds to one type of queue message;
and mapping the parameter entering, parameter exiting, actual calling time and calling times carried in the second queue message or the third queue message into corresponding data table templates in sequence according to the data mapping rule and the actual calling time to obtain a data record table.
Optionally, the alarm module 504 is specifically configured to:
monitoring the calling times in the data record table through a queue monitor;
judging whether the calling times meet the preset maximum repetition times or not;
if not, determining that the communication interface call fails, and sending an alarm mail;
if yes, detecting whether the interaction data recorded in the data recording table is effective interaction;
if not, determining that the communication interface call fails, and sending an alarm mail.
In the embodiment of the invention, the calling data and the interaction data are stored in a data record table to obtain the queue information, and the judgment of whether the calling fails or not is realized for the calling times of the interfaces in the monitoring data record table.
The interface call monitoring device in the embodiment of the present invention is described in detail above in fig. 5 and fig. 6 from the point of view of modularized functional entities, and the interface call monitoring apparatus in the embodiment of the present invention is described in detail below from the point of view of hardware processing.
Fig. 7 is a schematic structural diagram of an interface call monitor device according to an embodiment of the present application, where the interface call monitor device 700 may have a relatively large difference due to different configurations or performances, and may include one or more processors (central processing units, CPU) 710 (e.g., one or more processors) and a memory 720, and one or more storage media 730 (e.g., one or more mass storage devices) storing application programs 733 or data 732. Wherein memory 720 and storage medium 730 may be transitory or persistent. The program stored on the storage medium 730 may include one or more modules (not shown), each of which may include a series of instruction operations in the interface call monitoring device 700. Still further, the processor 710 may be configured to communicate with the storage medium 730 and execute a series of instruction operations in the storage medium 730 on the interface call monitoring device 700 to implement the steps of the methods provided by the embodiments described above.
The interface call monitor 700 may also include one or more power supplies 740, one or more wired or wireless network interfaces 750, one or more input/output interfaces 760, and/or one or more operating systems 731, such as Windows Serve, mac OS X, unix, linux, freeBSD, etc. It will be appreciated by those skilled in the art that the interface call monitoring device structure shown in fig. 7 is not limiting of the interface call monitoring device provided by the embodiments of the present application, and may include more or fewer components than shown, or may combine certain components, or may be a different arrangement of components.
The present invention also provides a computer readable storage medium, which may be a non-volatile computer readable storage medium, or a volatile computer readable storage medium, having stored therein instructions that, when executed on a computer, cause the computer to perform the steps of the interface call monitoring method.
It will be clearly understood by those skilled in the art that, for convenience and brevity of description, the specific working process of the system or apparatus and unit described above may refer to the corresponding process in the foregoing method embodiment, which is not repeated herein.
The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present invention may be embodied essentially or in part or all of the technical solution or in part in the form of a software product stored in a storage medium, including instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a read-only memory (ROM), a random access memory (random access memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.
The blockchain is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanism, encryption algorithm and the like. The Blockchain (Blockchain), which is essentially a decentralised database, is a string of data blocks that are generated by cryptographic means in association, each data block containing a batch of information of network transactions for verifying the validity of the information (anti-counterfeiting) and generating the next block. The blockchain may include a blockchain underlying platform, a platform product services layer, an application services layer, and the like.
The above embodiments are only for illustrating the technical solution of the present invention, and not for limiting the same; although the invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present invention.
Claims (10)
1. An interface call monitoring method, characterized in that the interface call monitoring method comprises:
Receiving an interface calling instruction sent by a client for calling a communication interface on a provider;
acquiring call data and/or interaction data generated in the process of calling the communication interface based on the interface call instruction;
generating a queue message according to the call data and/or the interaction data, and synchronizing the queue message to a monitoring database for recording;
monitoring the queue information in real time, determining the actual calling condition of the communication interface, and judging whether to send an alarm mail or not based on the actual calling condition;
the real-time monitoring of the queue information, the determination of the actual calling condition of the communication interface, includes:
judging whether the call of the communication interface is successful or not by monitoring the call times and the alarm type information in the queue information;
wherein, judging whether the call of the communication interface is successful or not through the alarm type information comprises:
determining whether the communication connection between the communication interface and the client is successful,
if the connection is successful, detecting whether the queue message carries interactive data or not, or detecting whether the interactive data carried in the queue message is empty or not;
if the fact that the interactive data are not carried or the interactive data are empty is detected, determining that the communication interface call is unsuccessful;
If the interactive data is detected to be carried or the interactive data is not empty, judging whether the interactive data is service data appointed in the interface calling instruction, if so, determining that the communication interface is successfully called;
if the connection fails, determining that the communication interface call is unsuccessful.
2. The interface call monitoring method according to claim 1, wherein the acquiring call data and/or interaction data generated in the process of calling the communication interface based on the interface call instruction includes:
analyzing the interface calling instruction to obtain the interface type of the communication interface requested to be called;
based on the interface type, inquiring interface protocol information corresponding to the interface type from the providing end, wherein the interface protocol information comprises an input parameter, an output parameter, a routing rule, a calling timeout time and a data mapping rule;
calling the communication interface by using the routing rule, and recording the parameter entering and exiting, the actual calling time and the calling times when the communication interface is called;
and acquiring interaction data returned in the process of calling the communication interface, and sending the interaction data to a user according to the data mapping rule.
3. The interface call monitoring method according to claim 2, wherein generating a queue message according to the call data and/or the interaction data and synchronizing the queue message to a monitoring database for recording comprises:
judging whether the calling times are larger than the preset maximum repeated calling times or not to obtain a judging result;
determining an interface alarm type based on the judging result;
generating an interface call log by the parameter entering, parameter exiting, interface alarm type and interaction data, and writing the interface call log into a queue message;
and synchronizing the queue information containing the interface call log to a monitoring database for recording.
4. The method for monitoring interface calls according to claim 3, wherein synchronizing the queue message containing the interface call log to the monitoring database for recording comprises:
acquiring a push function of the communication interface to the queue message;
extracting annotation parameters in the push function, and judging the value of the annotation parameters, wherein the annotation parameters are used for indicating the type of the queue message;
and based on the value, selecting information which does not accord with the type from the queue information to delete, obtaining new queue information, and synchronizing the new queue information to the monitoring database for recording.
5. The interface call monitoring method of claim 4, wherein the types include a generic interface alarm type and a personalized interface alarm type; and selecting information which does not accord with the type from the queue information to delete according to the value to obtain new queue information, and synchronizing the new queue information to the monitoring database for recording, wherein the method comprises the following steps:
judging whether the value is empty or not;
if the value is empty, determining that the alarm type carried in the queue message is common interface call, and shielding information about interface personalized call in the queue message to obtain a second queue message;
if the value is not empty, determining that the alarm type carried in the queue message is interface personalized call, and shielding information about common interface call in the queue message to obtain a third queue message;
and sending the second queue message or the third queue message to the monitoring database for storage.
6. The interface call monitoring method of claim 5, wherein the sending the second queue message or the third queue message to the monitoring database store comprises:
Setting two different data table templates in the monitoring database, wherein each data table template corresponds to one type of queue message;
and mapping the parameter entering, parameter exiting, actual calling time and calling times carried in the second queue message or the third queue message into corresponding data table templates in sequence according to the data mapping rule and the actual calling time to obtain a data record table.
7. The interface call monitoring method according to claim 6, wherein the monitoring the queue message in real time, determining an actual call condition of the communication interface, and judging whether to send an alert mail based on the actual call condition, comprises:
monitoring the calling times in the data record table through a queue monitor;
judging whether the calling times meet the preset maximum repetition times or not;
if not, determining that the communication interface call fails, and sending an alarm mail;
if yes, detecting whether the interaction data recorded in the data recording table is effective interaction;
if not, determining that the communication interface call fails, and sending an alarm mail.
8. An interface call monitoring device, characterized in that the interface call monitoring device comprises:
The receiving module is used for receiving an interface calling instruction sent by the client and used for calling a communication interface on the providing end;
the acquisition module is used for acquiring call data and/or interaction data generated in the process of calling the communication interface based on the interface call instruction;
the processing module is used for generating a queue message according to the calling data and/or the interaction data, and synchronizing the queue message to a monitoring database for recording;
the alarm module is used for monitoring the queue information in real time, determining the actual calling condition of the communication interface and judging whether to send an alarm mail or not based on the actual calling condition;
the alarm module is specifically configured to:
judging whether the call of the communication interface is successful or not by monitoring the call times and the alarm type information in the queue information;
wherein, judging whether the call of the communication interface is successful or not through the alarm type information comprises:
determining whether the communication connection between the communication interface and the client is successful,
if the connection is successful, detecting whether the queue message carries interactive data or not, or detecting whether the interactive data carried in the queue message is empty or not;
If the fact that the interactive data are not carried or the interactive data are empty is detected, determining that the communication interface call is unsuccessful;
if the interactive data is detected to be carried or the interactive data is not empty, judging whether the interactive data is service data appointed in the interface calling instruction, if so, determining that the communication interface is successfully called;
if the connection fails, determining that the communication interface call is unsuccessful.
9. An interface call monitoring device, the interface call monitoring device comprising: a memory and at least one processor, the memory having instructions stored therein, the memory and the at least one processor being interconnected by a line;
the at least one processor invoking the instructions in the memory to cause the interface call monitoring device to perform the interface call monitoring method of any of claims 1-7.
10. A computer readable storage medium having stored thereon a computer program, which when executed by a processor implements the interface call monitoring method according to any of claims 1-7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010879202.3A CN112039701B (en) | 2020-08-27 | 2020-08-27 | Interface call monitoring method, device, equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010879202.3A CN112039701B (en) | 2020-08-27 | 2020-08-27 | Interface call monitoring method, device, equipment and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112039701A CN112039701A (en) | 2020-12-04 |
| CN112039701B true CN112039701B (en) | 2023-08-15 |
Family
ID=73585896
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010879202.3A Active CN112039701B (en) | 2020-08-27 | 2020-08-27 | Interface call monitoring method, device, equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112039701B (en) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113296982B (en) * | 2021-05-27 | 2024-06-14 | 北京京东振世信息技术有限公司 | Interface calling method and device |
| CN113377616B (en) * | 2021-06-11 | 2022-04-12 | 湖南快乐阳光互动娱乐传媒有限公司 | Interface monitoring method, device and computer readable medium |
| CN113608962A (en) * | 2021-07-30 | 2021-11-05 | 平安普惠企业管理有限公司 | Method, device and equipment for predicting abnormal application interface and storage medium |
| CN113904951B (en) * | 2021-09-28 | 2023-07-25 | 济南浪潮数据技术有限公司 | Data monitoring method and device of gateway equipment and related equipment |
| CN113971508A (en) * | 2021-09-30 | 2022-01-25 | 北京蓝海医信科技有限公司 | Method and device for processing interface call exception based on information integration platform |
| CN114327436B (en) * | 2022-03-12 | 2022-07-08 | 联信弘方(北京)科技股份有限公司 | Development method, system, terminal and storage medium for monitoring target plug-in |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2017167062A1 (en) * | 2016-03-30 | 2017-10-05 | 阿里巴巴集团控股有限公司 | Application program interface deadlock monitoring method and device |
| CN109739727A (en) * | 2019-01-03 | 2019-05-10 | 优信拍（北京）信息科技有限公司 | Service monitoring method and device in micro services framework |
| CN110022221A (en) * | 2018-01-08 | 2019-07-16 | 车伯乐（北京）信息科技有限公司 | A kind of monitoring method of system interface data, apparatus and system |
| CN111049673A (en) * | 2019-11-21 | 2020-04-21 | 山东健康医疗大数据有限公司 | Method and system for counting and monitoring API call in service gateway |
-
2020
- 2020-08-27 CN CN202010879202.3A patent/CN112039701B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2017167062A1 (en) * | 2016-03-30 | 2017-10-05 | 阿里巴巴集团控股有限公司 | Application program interface deadlock monitoring method and device |
| CN110022221A (en) * | 2018-01-08 | 2019-07-16 | 车伯乐（北京）信息科技有限公司 | A kind of monitoring method of system interface data, apparatus and system |
| CN109739727A (en) * | 2019-01-03 | 2019-05-10 | 优信拍（北京）信息科技有限公司 | Service monitoring method and device in micro services framework |
| CN111049673A (en) * | 2019-11-21 | 2020-04-21 | 山东健康医疗大数据有限公司 | Method and system for counting and monitoring API call in service gateway |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112039701A (en) | 2020-12-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112039701B (en) | Interface call monitoring method, device, equipment and storage medium | |
| US8135827B2 (en) | Distributed capture and aggregation of dynamic application usage information | |
| US11356337B2 (en) | System and method for tracking service requests | |
| US20060085361A1 (en) | Anomaly detector in a health care system using adapter | |
| US20230014346A1 (en) | Indexing data at a data intake and query system based on a node capacity threshold | |
| EP1623300A2 (en) | Method and system for reducing information latency in a business enterprise | |
| US20200089669A1 (en) | Pattern-based detection using data injection | |
| CN107798037A (en) | The acquisition methods and server of user characteristic data | |
| JPH10207838A (en) | Device and method for counting frequency of information reference in interactive hypertext information reference system, and medium recorded with information reference frequency counting program | |
| US7930404B2 (en) | Cross-system log in a distributed system environment | |
| CN113220633B (en) | Unified file coding management method and system | |
| CN110334147A (en) | A kind of method of data synchronization and device | |
| CN114090529A (en) | Log management method, device, system and storage medium | |
| US7840705B2 (en) | System and program product for replicating message status changes across messaging systems | |
| CN113065953B (en) | Futures relay trading system based on distribution type | |
| CN111078764A (en) | Data processing method and device, computer readable storage medium and electronic equipment | |
| US7873715B1 (en) | Optimized instrumentation of web pages for performance management | |
| CN115757642A (en) | Data synchronization method and device based on filing log file | |
| US10320632B1 (en) | Pattern-based detection for services in distributed systems | |
| CN118153245B (en) | Distributed computing gas pipeline simulation method, equipment and medium | |
| CN115426253B (en) | Web server monitoring method and system based on log file | |
| US11843706B1 (en) | Gradual certificate rotation | |
| CN114257612B (en) | Data processing method | |
| CN117234672A (en) | Transaction processing method, apparatus, product, device, and medium | |
| CN115776491A (en) | Data sharing method and data sharing system |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |