CN112039701A - Interface call monitoring method, device, equipment and storage medium - Google Patents

Abstract

The invention relates to the field of artificial intelligence, and discloses an interface calling monitoring method, an interface calling monitoring device, interface calling monitoring equipment and a storage medium, wherein the method comprises the following steps: receiving an interface calling instruction which is sent by a client and used for calling a communication interface on a providing end, acquiring calling data and/or interactive data generated in the process of calling the communication interface based on the interface calling instruction, generating queue information according to the calling data and/or the interactive data, synchronizing the queue information into 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 based on the actual calling condition. The invention also relates to a block chain technique, the queue messages being stored in a block chain. The invention realizes the integrated monitoring of calling and data and the monitoring of service operation, and improves the operability of interface maintenance. And calling and monitoring by an interface.

Description

Interface call monitoring method, device, equipment and storage medium

Technical Field

The invention relates to the field of artificial intelligence, in particular to an interface calling monitoring method, device, equipment and storage medium.

Background

With the development of business diversification, the complexity, stability and maintainability of the corresponding system are more and more difficult to control. With the rise and development of business system services, another problem brought by the system services is the secure implementation of communication interfaces, especially traditional financial companies, internet financial companies and other business type internet companies, whose businesses often involve the traffic of a large amount of business. Interface calls of these company systems often affect the business interactive use of users or companies, and therefore they need to be monitored so as to quickly intervene in an abnormal scene and prevent further development of adverse events.

At present, the processing of the interface calling abnormity in the industry is mainly realized by a uniform background technical framework, the monitoring of the single interface calling abnormity can be realized by the mode, but the influence of the abnormity of service data interaction on the system operation cannot be sensed, and particularly, the simultaneous monitoring of the interface calling and the interface data is difficult to realize for the calling of a personalized interface with a near-real-time system interface type.

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 which is sent by a client and used for calling a communication interface on a providing end;

acquiring calling data and/or interactive 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 the interactive data, and synchronizing the queue message to a monitoring database for recording;

and 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.

Optionally, in a first implementation manner of the first aspect of the present invention, the obtaining, based on the interface call instruction, call data and/or interaction data generated in a process of calling the communication interface includes:

analyzing the interface calling instruction to obtain the interface type of the communication interface which is requested to be called;

based on the interface type, inquiring corresponding interface protocol information from the providing terminal, wherein the interface protocol information comprises an access parameter, a routing rule, calling timeout time and a data mapping rule;

calling the communication interface by using the routing rule, and recording the input parameter, the output parameter, the actual calling time and the calling times when the communication interface is called;

and acquiring interactive data returned in the process of calling the communication interface, and sending the interactive 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 judgment result;

determining an interface alarm type based on the judgment result;

generating interface call logs by the input parameter, the output parameter, the interface alarm types and the interactive data, and writing the interface call logs into a queue message;

and synchronizing the queue message 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, the synchronizing the queue message including the interface call log into 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 values 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 conform to the type from the queue information to delete to obtain a 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 common interface alarm type and a personalized interface alarm type; and selecting information which does not conform to the type from the queue messages according to the value to delete to obtain a new queue message, and synchronizing the new queue message to the record in the monitoring database, wherein the steps of:

judging whether the value is empty;

if the value is empty, determining that the alarm type carried in the queue message is common interface calling, and shielding information about interface personalized calling in the queue message to obtain a second queue message;

if the value is not null, 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 for 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 input parameter, the output parameter, the actual calling time and the calling times carried in the second queue message or the third queue message to 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 situation of the communication interface, and determining whether to send an alert mail based on the actual call situation 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 is failed to call, and sending an alarm mail;

if yes, detecting whether the interactive data recorded in the data record table is effective interaction;

if not, determining that the communication interface is failed to call, and sending an alarm mail.

A second aspect of the present invention provides an interface call monitoring apparatus, including:

the receiving module is used for receiving an interface calling instruction which is sent by the client and used for calling a communication interface on the providing end;

the acquisition module is used for acquiring calling data and/or interactive data generated in the process of calling the communication interface based on the interface calling instruction;

the processing module is used for generating queue messages according to the calling data and/or the interactive data and synchronizing the queue messages to a monitoring database for recording;

and the warning 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 a warning 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 analysis unit is used for analyzing the interface calling instruction to obtain the interface type of the communication interface requested to be called;

the query unit is used for querying interface protocol information corresponding to the interface type from the providing terminal based on the interface type, wherein the interface protocol information comprises an access parameter, a routing rule, calling timeout time and a data mapping rule;

the calling and recording unit is used for calling the communication interface by utilizing the routing rule and recording the input parameter, the output parameter, 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 judgment result;

the write-in unit is used for generating an interface call log from the input parameter, the output parameter, the interface alarm type and the interactive data and writing the interface call log into a queue message;

and the synchronization unit is used for synchronizing the queue message 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 values 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 conform to the type from the queue information to delete to obtain a 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 common interface alarm type and a personalized interface alarm type; the synchronization unit is specifically configured to:

judging whether the value is empty;

if the value is empty, determining that the alarm type carried in the queue message is common interface calling, and shielding information about interface personalized calling in the queue message to obtain a second queue message;

if the value is not null, 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 input parameter, the output parameter, the actual calling time and the calling times carried in the second queue message or the third queue message to 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 is failed to call, and sending an alarm mail;

if yes, detecting whether the interactive data recorded in the data record table is effective interaction;

if not, determining that the communication interface is failed to call, and sending an alarm mail.

A third aspect of the present invention provides an interface call monitoring apparatus, including: a memory having instructions stored therein and at least one processor, the memory and the at least one processor interconnected by a line; the at least one processor calls the instructions in the memory to cause the interface call monitoring device to execute the interface call monitoring method.

A fourth aspect of the present invention provides a computer-readable storage medium having stored therein instructions, which, when run on a computer, cause the computer to execute the above-described interface call monitoring method.

In the technical scheme of the invention, in the monitoring and controlling process, an interface calling instruction which is sent by a monitoring client and used for calling an interface on a server is monitored, calling data and interactive data of the interface are obtained based on the instruction, then queue information is generated through the calling data and the interactive data and is 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; according to the method and the device, the calling data called by the interface and the interaction data after the calling are monitored, so that not only is the integrated monitoring of the calling and the data realized, but also the monitoring of the service operation is realized, the consumption overhead of the system for monitoring the interface can be reduced by monitoring the queue information, the monitoring supporting large data volume is realized, and the operability of interface maintenance is greatly improved.

Drawings

FIG. 1 is a diagram illustrating a first embodiment of an interface call monitoring method according to an embodiment of the present invention;

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 illustrating 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 according to an embodiment of the present invention;

FIG. 5 is a diagram of an embodiment of an interface call monitoring apparatus according to an embodiment of the present invention;

FIG. 6 is a schematic diagram of another embodiment of an interface call monitoring apparatus according to an embodiment of the present invention;

fig. 7 is a schematic diagram of an embodiment of an interface call monitoring device in the embodiment of the present invention.

Detailed Description

The embodiment of the invention provides an interface calling monitoring method, an interface calling monitoring device, an interface calling monitoring equipment and a storage medium. The monitor in the scheme monitors the messages, determines whether to record the system operation condition and the service operation condition according to a preset monitoring type, and simultaneously judges whether to send an Internet alarm notification or other preset alarm short messages, so that a worker can rapidly process the alarm, and more adverse effects on the system or the service caused by the alarm problem are reduced. According to the scheme, the accuracy degree of monitoring of the system and the service operation condition is improved, the time difference between the occurrence of problems and manual intervention is greatly shortened, the extra performance overhead of interface calling brought by the scheme is extremely low, billion-level monitoring information can be supported at the same time, and the monitoring requirements of most enterprises can be basically met.

The terms "first," "second," "third," "fourth," and the like in the description and in the claims, as well as in the drawings, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It will be appreciated that the data so used may be interchanged under appropriate circumstances such that the embodiments described herein may be practiced otherwise than as specifically illustrated or described herein. Furthermore, the terms "comprises," "comprising," or "having," and any variations thereof, are intended to cover non-exclusive inclusions, 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, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

For convenience of understanding, a specific flow of the embodiment of the present invention is described below, and referring to fig. 1, a first embodiment of the interface call monitoring method according to the embodiment of the present invention includes:

101. receiving an interface calling instruction sent by a client;

it is to be understood that the execution subject of the present invention may be an interface call monitoring device, and may also be a terminal or a server, which is not limited herein. The embodiment of the present invention is described by taking a server as an execution subject.

In this embodiment, the interface call instruction refers to an instruction for calling a communication interface on the providing end of the interface, and the communication interface may be understood as a network interface or a wireless interface, and may even be an NFC interface, etc., as long as the interface can implement 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 a user initiates service processing through access software or a terminal, where the command includes type information of a communication interface to be called, and may even be a function type implemented by the initiated service, and the corresponding communication interface may be directly found through a mapping relationship of the interfaces based on the function type or the type information.

In practical application, the instruction may also carry data of a 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 an interface call instruction, the server monitors the use condition of each interface on the providing end of the interface, specifically, monitoring can be realized by monitoring the 0 or 1 setting state of the interface, when the interface is 1, the interface is called, and then the interface call instruction of the interface is acquired from the control device connected with the providing end, or the interface call instruction is acquired from an instruction library on the providing end.

102. Acquiring calling data and/or interactive data generated in the process of calling the communication interface based on the interface calling instruction;

in this embodiment, the interface call instruction is first analyzed to obtain the interface type and the interface number carried in the instruction, an interface list on the providing end is traversed based on the interface type and the interface number to find a corresponding interface, then an IP address of the interface is obtained, a log of interface operation is determined based on the IP address, in practical application, all records of interface call of the providing end are recorded in a large log table, the call or operation record of the corresponding interface can be determined through IP address query, the operation record of the interface after the moment of executing the interface call instruction is extracted to form call data of the interface, and the call data includes call parameters when the communication connection between the interface and the client is realized according to the instruction.

In this embodiment, after the calling data is obtained, it is further determined whether the data recorded in the calling data is a record of successful calling, and if the data is the record of successful calling, interactive data implemented through an interface between client providing terminals is obtained, specifically, the interactive data is called from a buffer corresponding to the interface. In practical application, the method for calling the interactive data further comprises the step of obtaining the data interacted between the two through the interface in a monitoring interception mode.

In this embodiment, the call data includes entry, exit, 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 application, the call data is definitely present, and the interactive data does not generate the interactive data because the interface call is successful but the service function realized through the communication interface is not completed, and may also be present, for example, the interactive data is empty.

Optionally, for each communication interface in the background system maintenance interface warehouse, protocol information required when the call is connected is recorded, protocol information such as entry, exit, call time, interface type, routing rule, data mapping rule and the like required when the call is performed is recorded, and the protocol information is stored in the database. A third-party communication interface url is illustrated below as an example: http:// a.jd.com/fetch? When calling, the communication interface needs to be disassembled, calling data is formed in a json string mode, and finally a database storage file is formed.

Calling data of input parameters, output parameters, calling time, interface types, routing rules, data mapping rules and the like required when the interfaces are called can be obtained through the json string. The interface warehouse has a background system storage management.

103. Generating a queue message according to the calling data and/or the interactive 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 by using the call data as a main component, the interactive data is carried in the queue message, and the interactive data can be added to the queue message after being processed according to the communication protocol in the communication interface. It should be emphasized that, in order to further ensure the privacy and security of the queue message, the queue message may be specifically stored in a node of a block chain in the monitoring database when being synchronized to the monitoring database record.

In practical application, the queue message can be generated specifically by the record requirement of the monitoring database, even can be generated by the message conversion model, optionally, the disassembled call data is converted to generate the queue message according to the storage format of the monitoring database, 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 is sent out, and the monitoring database is preferably implemented by a queue message assistance server (MQ broker).

104. And monitoring the queue message 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 calling condition of the communication interface is determined by monitoring the queue information, specifically, whether the calling of the interface is successful is determined by monitoring the calling times and the alarm type information in the queue information.

In this embodiment, whether the interface call is successful or not is determined, and it needs to be determined from two aspects, that is, whether the communication connection between the communication interface and the client is successfully established and data interaction exists on the communication interface is determined, that is, whether the connection state of the communication interface is 1 is determined, if yes, it is detected whether the queue message carries the interactive data or whether the interactive data carried in the queue message is empty, and if it is detected that the interactive data is not carried or the data is empty, it is determined that the interface call is unsuccessful, and an alarm mail is sent. If the carried data or the data is detected to be non-empty, the interface calling is determined to be successful, further, the interactive data is obtained for analysis, whether the interactive data is the service data specified in the interface calling instruction or not is analyzed, and if the carried data or the data is not empty, the interface calling is determined to be successful.

If the connection state of the communication interface is not 1, directly determining that the interface calling is unsuccessful, and executing the step of alarm processing.

In practical application, the queue message itself is set to have a function of repeatedly sending, so that the step can determine whether the call of the interface itself is successful by detecting the number of calls carried in the queue message and determining whether the call of the interface itself is successful according to the number of repeated calls in the number of calls, and the step can retry for the specified number of times if the MQ consumer does not return consumption success. If the failure still occurs after a specified number of retries, an alarm is raised. Of course, this may be determined by detecting whether a queue message is received in the monitoring database.

By executing the method, the data and the interactive data are called according to the interface to monitor, so that whether the calling of the interface is successful or not can be monitored, whether the called service function of the interface is monitored or not is also monitored, and the accuracy of monitoring the calling of the interface is greatly improved.

Referring to fig. 2, a second embodiment of the interface call monitoring method according to the embodiment of the present invention includes:

201. receiving an interface calling instruction which is sent by a client and used for calling a communication interface on a providing end;

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 terminal, wherein the interface protocol information comprises access parameters, routing rules, calling timeout time and data mapping rules;

204. calling a communication interface by utilizing a routing rule, and recording the input parameter, the output parameter, the actual calling time and the calling times when the communication interface is called;

205. acquiring interactive data returned in the process of calling the 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 specifically queried from an interface repository in the providing end, where the interface repository may be understood as a database or a data table used by the providing end to store 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 a communication interface is called according to the routing rule, calculating the cache key of the called communication interface according to the routing rule, storing the called communication interface into a shared cache of Nginx or Redis, establishing a corresponding relation table, and directly inquiring and calling according to the stored corresponding relation table during actual use.

In practical applications, the obtained interactive data can be obtained by directly obtaining the interactive data from the interface calling instruction, or directly receiving and reading the interactive data from the user side after the interface calling is successful, and the data of the user side can be received only after the interface calling is successful.

206. Generating a queue message according to the calling data and/or the interactive 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 a communication interface is called, multiple call retries can be performed, and one parameter is correspondingly recorded every retry, whether the interface call is successful is determined based on the parameter, and a corresponding interface alarm type is generated in combination with an outgoing setting of a providing end corresponding message;

further, other parameters generated when the interface is called, such as parameters of entry, exit, interactive data and the like, are obtained, and corresponding queue messages are generated according to the type of the interface alarm.

Of course, after the queue message is generated, the operation may be retried based on the queue message, and the record of the number of times of repeating the retry operation parameter may be embedded in the queue message and synchronized in the database, so as to implement the synchronous monitoring of the message. The method can achieve the purpose of monitoring and improve the success rate of interface calling.

In this embodiment, the specific implementation of this step may obtain a 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 judgment result; generating interface call logs by the input parameter, the output parameter, the interface alarm types and the interactive data, and writing the interface call logs into a queue message; and synchronizing the queue message containing the interface call log to a monitoring database for recording.

207. And 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 uniform monitoring on whether the interface calling is successful is realized by monitoring the queue message MQ, and meanwhile, the MQ message carries interactive data, thereby further realizing the real-time monitoring on the interface data and solving the problem that the interface calling is not matched with the called data.

Referring to fig. 3, a third embodiment of the interface call monitoring method according to the embodiment of the present invention includes:

301. receiving an interface calling instruction sent by a client;

302. acquiring calling data and/or interactive data generated in the process of calling the communication interface based on the interface calling instruction;

303. generating a queue message according to the calling data and/or the interactive data;

304. acquiring a push function of a communication interface to a queue message;

305. extracting annotation parameters in the push function, and judging the values of the annotation parameters;

306. judging whether the value is null 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 a level of 1 is non-null and a level of 0 is null, specifically, as shown in fig. 4, the interface calls a 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 described herein refers to a call unrelated to service settlement, such as: the interface is only used for carrying out the interaction of common services, such as sending notification messages and the like.

308. Shielding information about interface personalized call in the queue message to obtain a second queue message;

309. if the value is not null, determining the alarm type carried in the queue message as interface personalized call;

in this embodiment, the personalized call described herein refers to a call associated with service settlement, such as: the transaction billing interaction is simply done using an interface, such as transaction code, amount, transaction bill, etc. Besides, the interface call of the user customized transmission format is also included, and belongs to personalized call, for example: defining a business data interaction template, and the like.

310. Shielding information related to common interface calling in the queue message to obtain a third queue message;

in this embodiment, when synchronizing a queue message to a monitoring database, a providing end is specifically controlled by sending a function to control the type of the synchronized queue message, where there is a difference in the specific content of the queue message generated by different communication interfaces, optionally, the providing end may be controlled by an annotation parameter in the function, for example, all data is generated when an interface on the providing end is called, only call data of a common interface is synchronized in a current synchronization period, at this time, the annotation parameter of the function is set to be only synchronous sending of the call data of the common interface, and of course, the queue message may be controlled by the annotation parameter, that is, corresponding call data is obtained for a corresponding interface type to generate the queue message satisfying the interface type. It should be emphasized that, in order to further ensure the privacy and security of the queue message, the queue message may be specifically stored in a node of a block chain in the monitoring database when being synchronized to the monitoring database record.

311. Sequentially mapping the input parameter, the output parameter, the actual calling time and the calling times carried in the queue message to corresponding data table templates according to a data mapping rule and the actual calling time to obtain a data record table;

in this embodiment, the queue messages (MQ messages) may be divided into two classes of MQ topocs, which are respectively a warning topoc whether the common interface succeeds or not and an interface personalized warning topoc, whether to send these topocs depends on parameters in the annotation of the function of the provider, and only one of the topocs may be sent, or MQ messages of multiple topocs may be sent, for example: if the parameter type is normal, only interface level monitoring messages (MQ messages, the same below) are sent; if the parameter type is custom, only sending personalized monitoring information; if the parameter is both, both types of monitoring messages are sent. It should be emphasized that, in order to further ensure the accuracy and security of the data record table, when the data record table is generated, the conversion is stored and recorded in the blockchain, specifically by using 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 actual practice, since the MQ itself has a retry function, the specified number of retries will occur without the MQ consumer returning a consumption success. If the failure still occurs after a specified number of retries, an alarm is raised. Wherein the success and failure of the interface is determined based on a binary error code. As shown in fig. 4, a black undercolored 0 indicates that no manual intervention is required, and other values indicate that manual intervention is required and the call fails. In addition, the success of the interface does not indicate the success of the service response, for example, in the process of paying the premium, the system returns an interface calling error, and the error information is 'the balance of the user bank card is insufficient'. Interface call errors, indicating that technician attention is required, such as a brief period of downstream system response timeout.

In this embodiment, after synchronizing the queue message to the BD, the method further includes writing or updating the following information into the DB: the number, the interface name, the minute (year, month, day, hour, minute, second), the total number of calls, the total number of call successes, the total number of call failures, the record creation time, and the record update time. And inserts the following information into the DB according to the configuration of the provider side: serial number, interface name, entry-entry key parameter (id can be filled in, so that the location is fast after the problem is solved), entry-entry, exit (including error information error code), record creation time and record updating time.

The key parameter of the entry and the exit is obtained by an entry and entry implementation interface of a provider end, and the entry and the exit can only store 256 bytes at most due to the consideration of performance, wherein the DB divides a plurality of databases according to the year, and the data tables are divided according to the month and the day. For example: invoke _08_28_ info, wherein the invoke _2019_ DB is the name of DB, the invoke _08_28_ info is the name of table, 2019 is the name of year, 08 is the month, 28 is the date, that is, 2019 has 365 physical tables.

After the DB is written or updated, the MQ listener judges whether to send the alarm mail according to the configuration. If the failure rate of one minute exceeds 80 percent, the failure times of one minute exceed 20 times. If the sending of the alarm mail fails, the sending is retried for three times, and if the sending of the alarm mail still fails, the sending of the alarm 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 based on the actual calling condition.

In this embodiment, when the data record table is monitored in real time, the number of calls in the data record table is monitored specifically by a queue monitor;

judging whether the calling times meet the preset maximum repetition times or not;

if not, determining that the communication interface is failed to call, and sending an alarm mail;

if yes, detecting whether the interactive data recorded in the data record table is effective interaction;

if not, determining that the communication interface is failed to call, and sending an alarm mail.

In this embodiment, when monitoring a queue message, specifically, a plug-in may be set on the providing end, and indirect call to the interface is implemented by controlling the plug-in, and the consumer calls the instruction scheduling plug-in through the interface, and the control plug-in performs a call operation to the interface I on the providing end. The plug-in will send the name of interface I and access reference required when the consumer calls the interface of the providing end asynchronously as MQ messages to the MQ browser. If the first transmission of the MQ message fails, the MQ message is retried twice again for three times in total, and if all the messages fail, the MQ message is ignored and is not transmitted any more. If the first or second transmission is successful, no retry is performed. The MQ sending exception refers to the exception that the application where the plug-in is located communicates with the broker as an MQ client and an MQ server.

In practical application, the abnormal judgment process may be that the MQ listener judges whether to send the alert mail according to the configuration. If the failure rate of one minute exceeds 80 percent, the failure times of one minute exceed 20 times. If the sending of the alarm mail fails, the sending is retried for three times, and if the sending of the alarm mail still fails, the sending of the alarm mail is ignored.

Through the implementation of the scheme, the problem that the unified monitoring interface of the system is called when the unified interface is not successfully called is solved, the scheme also provides a scheme for realizing near-real-time personalized monitoring by extending the MQ listener, if the near-real-time monitoring transaction can be successfully checked, namely, when the monitoring interface is called, whether the function required to be realized by the interface is successfully monitored is also realized, the integration of calling monitoring and function monitoring is realized, and the monitoring expense is reduced.

With reference to fig. 5, the interface call monitoring apparatus in the embodiment of the present invention is described below, and an embodiment of the interface call monitoring apparatus in the embodiment of the present invention includes:

areceiving module 501, configured to receive an interface call instruction sent by a client and used for calling a communication interface on a providing end;

anacquisition module 502, configured to acquire, based on the interface call instruction, call data and/or interaction data generated in a process of calling the communication interface;

theprocessing module 503 is configured to generate a queue message according to the call data and/or the interaction data, and synchronize the queue message into a monitoring database for recording;

it should be emphasized that, in order to further ensure the privacy and security of the queue message, the queue message may be specifically stored in a node of a block chain in the monitoring database when being synchronized to the monitoring database record.

And analarm module 504, configured to monitor the queue message in real time, determine an actual call condition of the communication interface, and determine whether to send an alarm mail based on the actual call condition.

In the embodiment of the invention, the interface calling data and the interface interaction data are stored by expanding the queue message, the calling condition and the using condition of the interface are monitored based on the queue message, the small-overhead monitoring and the unified monitoring of the data are realized, and the interface monitoring is based on the mode, so that the problem can be solved by fast insertion intervention when the problem occurs, the use of a user is facilitated, and the monitoring requirement is met.

Referring to fig. 6, another embodiment of the interface call monitoring apparatus according to the embodiment of the present invention includes:

areceiving module 501, configured to receive an interface call instruction sent by a client and used for calling a communication interface on a providing end;

anacquisition module 502, configured to acquire, based on the interface call instruction, call data and/or interaction data generated in a process of calling the communication interface;

theprocessing module 503 is configured to generate a queue message according to the call data and/or the interaction data, and synchronize the queue message into a monitoring database for recording;

and analarm module 504, configured to monitor the queue message in real time, determine an actual call condition of the communication interface, and determine whether to send an alarm mail based on the actual call condition.

Wherein theacquisition module 502 comprises:

theparsing unit 5021 is used for parsing the interface calling instruction to obtain the interface type of the communication interface requested to be called;

aquerying unit 5022, configured to query, based on the interface type, interface protocol information corresponding to the interface type from the providing terminal, where the interface protocol information includes an entry parameter, an exit parameter, a routing rule, a call timeout time, and a data mapping rule;

a callingrecording unit 5023, configured to call the communication interface using the routing rule, and record the entry, exit, actual calling time and calling times when calling the communication interface;

and theinteraction 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 theprocessing module 503 comprises:

a determiningunit 5031, configured to determine whether the call frequency is greater than a preset maximum call repetition frequency to obtain a determination result;

a determiningunit 5032, configured to determine an interface alarm type based on the determination result;

awriting unit 5033, configured to generate an interface call log from the entry, exit, interface alarm type and the interaction data, and write the interface call log into a queue message;

asynchronizing unit 5034, configured to synchronize the queue message including the interface call log to the monitoring database for recording.

Optionally, thesynchronizing 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 values 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 conform to the type from the queue information to delete to obtain a 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; thesynchronization unit 5034 is specifically configured to:

judging whether the value is empty;

if the value is empty, determining that the alarm type carried in the queue message is common interface calling, and shielding information about interface personalized calling in the queue message to obtain a second queue message;

if the value is not null, 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, thesynchronizing 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 input parameter, the output parameter, the actual calling time and the calling times carried in the second queue message or the third queue message to corresponding data table templates in sequence according to the data mapping rule and the actual calling time to obtain a data record table.

Optionally, thealarm 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 is failed to call, and sending an alarm mail;

if yes, detecting whether the interactive data recorded in the data record table is effective interaction;

if not, determining that the communication interface is failed to call, and sending an alarm mail.

In the embodiment of the invention, the calling data and the interactive data are stored in a data recording table to obtain the queue information, and the judgment on whether the calling is failed or not is realized on the calling times of the interfaces in the monitoring data recording table.

Fig. 5 and fig. 6 describe the interface call monitoring apparatus in the embodiment of the present invention in detail from the perspective of the modular functional entity, and the interface call monitoring apparatus in the embodiment of the present invention is described in detail from the perspective of hardware processing.

Fig. 7 is a schematic structural diagram of an interfacecall monitoring apparatus 700 according to an embodiment of the present invention, where the interfacecall monitoring apparatus 700 may have a relatively large difference due to different configurations or performances, and may include one or more processors (CPUs) 710 (e.g., one or more processors) and amemory 720, and one or more storage media 730 (e.g., one or more mass storage devices) for storingapplications 733 ordata 732.Memory 720 andstorage medium 730 may be, among other things, transient storage or persistent storage. The program stored on thestorage medium 730 may include one or more modules (not shown), each of which may include a sequence of instruction operations that invoke the interface in themonitoring device 700. Further, theprocessor 710 may be configured to communicate with thestorage medium 730, and execute a series of instruction operations in thestorage medium 730 on the interfacecall monitoring apparatus 700 to implement the steps of the method provided by the above embodiments.

The interfacecall monitoring device 700 may also include one ormore power supplies 740, one or more wired or wireless network interfaces 750, one or more input-output interfaces 760, and/or one ormore operating systems 731, such as Windows Server, Mac OS X, Unix, Linux, FreeBSD, and the like. Those skilled in the art will appreciate that the interface call monitoring device architecture shown in fig. 7 does not constitute a limitation of the interface call monitoring device provided by the embodiments of the present application, and may include more or fewer components than those shown, or some components in combination, or 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, and which may also be a volatile computer-readable storage medium, having stored therein instructions, which, when run on a computer, cause the computer to perform the steps of the interface calling the monitoring method.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses, and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present invention may be embodied in the form of a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: 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.

The block chain is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. A block chain (Blockchain), which is essentially a decentralized database, is a series of data blocks associated by using a cryptographic method, and each data block contains information of a batch of network transactions, so as to verify the validity (anti-counterfeiting) of the information and generate a next block. The blockchain may include a blockchain underlying platform, a platform product service layer, an application service layer, and the like.

The above-mentioned embodiments are only used for illustrating the technical solutions of the present invention, and not for limiting the same; although the present 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 solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and such modifications or substitutions do not depart from the spirit and scope of the corresponding 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 which is sent by a client and used for calling a communication interface on a providing end;

acquiring calling data and/or interactive 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 the interactive data, and synchronizing the queue message to a monitoring database for recording;

and 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.

2. The interface call monitoring method according to claim 1, wherein the obtaining call data and/or interaction data generated in the process of calling the communication interface based on the interface call instruction comprises:

analyzing the interface calling instruction to obtain the interface type of the communication interface which is requested to be called;

based on the interface type, inquiring interface protocol information corresponding to the interface type from the providing terminal, wherein the interface protocol information comprises access parameters, routing rules, calling timeout time and data mapping rules;

calling the communication interface by using the routing rule, and recording the input parameter, the output parameter, the actual calling time and the calling times when the communication interface is called;

and acquiring interactive data returned in the process of calling the communication interface, and sending the interactive data to a user according to the data mapping rule.

3. The interface call monitoring method according to claim 2, wherein 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 comprises:

judging whether the calling times are larger than the preset maximum repeated calling times or not to obtain a judgment result;

determining an interface alarm type based on the judgment result;

generating interface call logs by the input parameter, the output parameter, the interface alarm types and the interactive data, and writing the interface call logs into a queue message;

and synchronizing the queue message containing the interface call log to a monitoring database for recording.

4. The interface call monitoring method according to claim 3, wherein synchronizing the queue message including the interface call log to a 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 values 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 conform to the type from the queue information to delete to obtain a 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 conform to the type from the queue messages according to the value to delete to obtain a new queue message, and synchronizing the new queue message to the record in the monitoring database, wherein the steps of:

judging whether the value is empty;

if the value is empty, determining that the alarm type carried in the queue message is common interface calling, and shielding information about interface personalized calling in the queue message to obtain a second queue message;

if the value is not null, 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 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 input parameter, the output parameter, the actual calling time and the calling times carried in the second queue message or the third queue message to 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 situation of the communication interface, and determining whether to send an alert mail based on the actual call situation 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 is failed to call, and sending an alarm mail;

if yes, detecting whether the interactive data recorded in the data record table is effective interaction;

if not, determining that the communication interface is failed to call, and sending an alarm mail.

8. An interface call monitoring apparatus, the interface call monitoring apparatus comprising:

the receiving module is used for receiving an interface calling instruction which is sent by the client and used for calling a communication interface on the providing end;

the acquisition module is used for acquiring calling data and/or interactive data generated in the process of calling the communication interface based on the interface calling instruction;

the processing module is used for generating queue messages according to the calling data and/or the interactive data and synchronizing the queue messages to a monitoring database for recording;

and the warning 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 a warning mail or not based on the actual calling condition.

9. An interface call monitoring device, the interface call monitoring device comprising: a memory having instructions stored therein and at least one processor, the memory and the at least one processor 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, on which a computer program is stored, which, when being executed by a processor, carries out an interface call monitoring method according to any one of claims 1 to 7.

Images