CN107896172B - Monitoring failure processing method and device, storage medium and electronic device - Google Patents

Abstract

The invention discloses a monitoring fault processing method and device, a storage medium and electronic equipment, and relates to the technical field of data communication. The monitoring fault processing method is applied to a system comprising a message queue and a message consumption end, and comprises the following steps: decoupling a message listener from a message processing application at a message consuming end; monitoring the message queue, and if the abnormal message queue exists in the message queue, notifying the abnormal message queue to a monitoring manager of a message consumption end through a predetermined channel; the monitoring manager determines a message monitor corresponding to the abnormal message queue as a target monitor; the target listener is detected to restart the target listener in the event that a failure of the target listener is detected. The invention can solve the problem of message queue abnormity caused by monitor fault, and can realize the design requirement of high cohesion and low coupling by decoupling the monitor and the message processing application.

Description

Monitoring failure processing method and device, storage medium and electronic device

technical field

The present invention relates to the technical field of data communication, and in particular, to a monitoring fault processing method, a monitoring fault processing device, a storage medium and an electronic device.

Background technique

With the development of social informatization, data interaction between various business systems is becoming more and more frequent. At present, RabbitMQ (a data communication method) is often used between various business systems to realize data interaction. Specifically, first, the message producer (Producer) can send the message to the message exchange (Exchange); then, the message exchange can distribute the message to each queue (Queue) bound to the message exchange; in addition, the message consumer (Consumer) ) can monitor the queue through the monitor (Monitor), and after the message in the queue is monitored and processed by the message consumer, the message consumer can feed back a Callback to the queue; next, the queue can send the current Message cleared. Thus, the current data interaction process ends.

However, on the one hand, there is a problem that the length of messages in the queue is too high due to the downtime of the listener; , During code maintenance of listeners or message processing applications or during project iteration, developers modifying a certain code may cause errors in the entire system, which does not meet the design requirements of high cohesion and low coupling.

In view of this, there is a need for a monitoring fault processing method, a monitoring fault processing device, a storage medium and an electronic device.

It should be noted that the information disclosed in the above Background section is only for enhancing understanding of the background of the invention, and therefore may contain information that does not form the prior art known to a person of ordinary skill in the art.

SUMMARY OF THE INVENTION

The purpose of the present invention is to provide a monitoring fault processing method, monitoring fault processing device, storage medium and electronic equipment, thereby at least to a certain extent overcoming one or more problems caused by the limitations and defects of the related art.

According to an aspect of the present invention, a monitoring fault processing method is provided, which is applied to a system including a message queue and a message consumer, and the monitoring fault processing method includes:

Decouple message listeners from message processing applications on the message consumer side;

Monitor the message queue. If an abnormal message queue is detected in the message queue, the abnormal message queue will be notified to the monitoring manager of the message consumer through a predetermined channel;

The listening manager determines the message listener corresponding to the exception message queue as the target listener;

The target listener is detected to restart the target listener if a target listener failure is detected.

Optionally, decoupling the message listener from the message processing application includes:

Register the message processing application;

Get the message transmission conditions from the message processing application;

The message is sent to the corresponding message processing application via the message listener according to the message transmission condition.

Optionally, the monitoring fault processing method further includes:

The RESTful architecture is used to realize the data transmission between the message listener and the message processing application.

Optionally, the monitoring manager that notifies the abnormal message queue to the message consumer through a predetermined channel includes:

Notify the abnormal message queue to the monitoring manager of the message consumer through the HTTP protocol or the RESTful interface.

Optionally, the abnormal message queue is a message queue with abnormal queue length;

Among them, monitoring the message queue includes:

Determine whether the length of the message queue is abnormal.

Optionally, the monitoring manager determining the message listener corresponding to the exception message queue as the target listener includes:

The monitoring manager determines the message listener corresponding to the abnormal message queue as the target listener according to the correspondence table between the message listener and the message queue.

Optionally, the monitoring fault processing method further includes:

In the event that a target listener failure is detected, an alarm signal is sent.

According to one aspect of the present invention, a monitoring fault processing system is provided, including a message queue and a message consumer, and the monitoring fault processing system further includes:

The decoupling module is used to decouple the message listener from the message processing application on the message consumer side;

The queue monitoring module is used to monitor the message queue, and when it is detected that there is an abnormal message queue in the message queue, it will notify the monitoring manager of the message consumer end of the abnormal message queue through a predetermined channel;

The monitoring manager is used for determining the message listener corresponding to the abnormal message queue as the target listener, and detecting the target listener so as to restart the target listener in the case of detecting the failure of the target listener.

Optionally, the decoupling module includes:

a processing application registration unit for registering message processing applications;

a transmission condition acquisition unit, used to acquire the message transmission conditions from the message processing application;

The message sending unit is configured to send the message to the corresponding message processing application via the message listener according to the message transmission condition.

Optionally, the monitoring fault processing device further includes:

The data transmission module is used to realize the data transmission between the message listener and the message processing application using the RESTful architecture.

Optionally, the queue monitoring module includes:

The abnormal queue notification unit is used to notify the monitoring manager of the message consumer end of the abnormal message queue through the HTTP protocol or the RESTful interface when an abnormal message queue is detected in the message queue.

Optionally, the abnormal message queue is a message queue with abnormal queue length;

Among them, the queue monitoring module also includes:

The length abnormality judgment unit is used to judge whether the length of the message queue is abnormal.

Optionally, the listening manager includes:

The monitoring unit is used for the monitoring manager to determine the message listener corresponding to the abnormal message queue as the target listener according to the correspondence table between the message listener and the message queue.

Optionally, the listening manager further includes:

The alarm signal sending unit is used for sending an alarm signal in the case of detecting the failure of the target listener.

According to one aspect of the present invention, there is provided a storage medium on which a computer program is stored, and when the computer program is executed by a processor, any one of the above-mentioned monitoring fault processing methods is implemented.

According to one aspect of the present invention, an electronic device is provided, comprising:

processor; and

memory for storing executable instructions for the processor;

Wherein, the processor is configured to execute any one of the above monitoring fault processing methods by executing the executable instructions.

In the technical solutions provided by some embodiments of the present invention, by decoupling the message listener from the message processing application, monitoring the abnormal message queue, and determining the listener corresponding to the abnormal message queue as the target listener, detecting the target listener and Restarting the target listener when the target listener fails , which can avoid the problem that the entire system is wrong due to modification of a certain code during code maintenance or project iteration, and achieves the design requirements of high cohesion and low coupling.

It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure.

Description of drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and together with the description serve to explain the principles of the invention. Obviously, the drawings in the following description are only some embodiments of the present invention, and for those of ordinary skill in the art, other drawings can also be obtained from these drawings without creative effort. In the attached image:

1 schematically shows a block diagram of data communication based on the RabbitMQ mode of some solutions in the prior art;

FIG. 2 schematically shows a flowchart of a method for processing a monitoring fault according to an exemplary embodiment of the present invention;

3 schematically shows a block diagram of data communication after decoupling a message listener from a message processing application according to an exemplary embodiment of the present invention;

FIG. 4 schematically shows a block diagram of data communication using the monitoring method for fault handling according to an exemplary embodiment of the present invention;

FIG. 5 schematically shows a block diagram of a monitoring fault processing system according to an exemplary embodiment of the present invention;

FIG. 6 schematically shows a block diagram of a decoupling module according to an exemplary embodiment of the present invention;

FIG. 7 schematically shows another block diagram of a monitoring fault processing system according to an exemplary embodiment of the present invention;

FIG. 8 schematically shows a block diagram of a queue monitoring module according to an exemplary embodiment of the present invention;

FIG. 9 schematically shows another block diagram of a queue monitoring module according to an exemplary embodiment of the present invention;

Figure 10 schematically shows a block diagram of a listening manager according to an exemplary embodiment of the present invention;

FIG. 11 schematically shows another block diagram of a listening manager according to an exemplary embodiment of the present invention;

FIG. 12 shows a schematic diagram of a storage medium according to an exemplary embodiment of the present invention; and

Figure 13 schematically shows a block diagram of an electronic device according to an exemplary embodiment of the present invention.

Detailed ways

Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments, however, can be embodied in various forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided in order to give a thorough understanding of the embodiments of the present invention. However, those skilled in the art will appreciate that the technical solutions of the present invention may be practiced without one or more of the specific details, or other methods, components, devices, steps, etc. may be employed. In other instances, well-known solutions have not been shown or described in detail to avoid obscuring aspects of the present disclosure.

Furthermore, the drawings are merely schematic illustrations of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and thus their repeated descriptions will be omitted. Some of the block diagrams shown in the figures are functional entities that do not necessarily necessarily correspond to physically or logically separate entities. These functional entities may be implemented in software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor devices and/or microcontroller devices.

The flow charts shown in the figures are merely illustrative and do not necessarily include all steps. For example, some steps can be decomposed, and some steps can be combined or partially combined, so the actual execution order may be changed according to the actual situation.

FIG. 1 schematically shows a block diagram of data communication based on RabbitMQ mode of some solutions in the prior art. The process of data communication can be: first, the message producer 11 can send the produced message data to the message exchange 121 in the message queue server 12; next, the message exchange 121 can send the message data to the message queue bound to it 122. The message queue 123, the message queue 124 or the message queue 125; taking the message data sent to the message queue 122 as an example, the message consumer 13 corresponding to the message queue 122 can monitor the message queue 122 through its message listener 131. When sending to the message queue 122, the message listener 131 can monitor and obtain the message data, and send the message data to the message processing application (not shown) in the message consumer 13 so that the message processing application can process the data . Thus, the data communication process based on the RabbitMQ mode is completed. In addition, the message consumer 14 including the message listener 141 may correspond to the message queue 123, the message consumer 15 including the message listener 151 may correspond to the message queue 124, and the message consumer 16 including the message listener 161 may Corresponding to the message queue 125, their specific data communication mode may be the same as the communication mode corresponding to the message queue 122, which will not be repeated here.

However, the disadvantages of such a data communication method may include: on the one hand, if a message listener goes down, the corresponding message queue data accumulation problem may occur, and developers or operation and maintenance personnel cannot find it in time; on the other hand, For the message consumer, the coupling between the listener and the message processing application is relatively high. During the code maintenance of the listener or the message processing application or when the project is iterated, the developer may modify a certain code, which may lead to errors in the entire system. Meet the design requirements of high cohesion and low coupling.

In view of this, the present invention provides a monitoring fault processing method.

FIG. 2 schematically shows a flow chart of a method for processing a monitoring fault according to an exemplary embodiment of the present invention. The monitoring fault processing method can be applied to a system including a message queue and a message consumer. Referring to FIG. 2 , the monitoring fault processing method of the present invention may include the following steps:

S20. Decouple the message listener from the message processing application at the message consuming end.

In an exemplary embodiment of the present invention, the message consumer may include a message listener and a message processing application. The message listener can be used to monitor the message queue corresponding to the message consumer, and the message processing application can be an application that specifically processes message data, and can be used to process, integrate, and display data. The specific functions of the application are not particularly limited.

According to some embodiments of the present invention, the specific decoupling method may include, for example: first, the message processing application may be registered; next, the user may configure message transmission conditions on the client side. Specifically, the user may use the message processing application The corresponding user operation interface configures the message transmission conditions; then, the server can send the message to the corresponding message processing application via the message listener according to the message transmission conditions. In the above message transmission process, the RESTful architecture can be used to realize the data transmission between the message listener and the message processing application. Specifically, the message transmission conditions can be converted into RESTful data compatible with each module, and a RESTful service interface can be provided for the corresponding transport service. In addition, data can be sorted into chunks based on various RESTful markup languages (for example, URI), and data can be classified according to historical records, thereby not only maximizing data storage, but also providing more accurate guidance for screening. .

Based on the RESTful architecture, a stateless, resource-oriented, loosely coupled structure can be implemented without considering the current state of message transmission, which satisfies the design goal of high cohesion and low coupling between message listeners and message processing applications.

FIG. 3 schematically shows a block diagram of data communication after decoupling a message listener from a message processing application according to an exemplary embodiment of the present invention. First, the message producer 31 can send the message produced by it to the message exchange 321 in the message queue server 32. In addition, although it is not shown in the figure, it should be understood that the message queue server 32 may also include other message exchanges, And the present invention does not limit the number of message exchanges; subsequently, the message exchange 321 can send the message to the message queue 322, the message queue 323, the message queue 324 or the message queue 325. In addition, similarly, the message queue server 32 also may include other message queues and/or other message queues corresponding to the message exchange 321; next, taking the message sent to the message queue 322 as an example, the message listener 331 in the message consumer 33 monitors that the message queue 322 receives a message after , you can get the message. In addition, on the one hand, the message listener 331 in the message consumer 33 can send the message to the message processing application 332 decoupled from it, so that the message processing application 332 can process the message. The code of the message listener 331 will not directly affect the message processing application 332; on the other hand, although not shown in the figure, the message consumer 33 may also include other message processing applications corresponding to the message listener 331. Similarly, the message consumer 34 including the message listener 341 and the message processing application 342 decoupled from it may correspond to the message queue 323, and the message consumer 35 including the message listener 351 and the message processing application 352 decoupled from it. It can correspond to the message queue 324, and the message consumer 36 including the message listener 361 and the message processing application 362 decoupled from it can correspond to the message queue 325, and their specific data communication mode is the same as the communication mode corresponding to the message queue 322, It is not repeated here.

In addition, other architectures can be used in the present invention to realize the decoupling of the message listener and the message consumer, for example, the lightweight open source architecture Spring can be used to realize the decoupling and so on. It should be understood that the solution of decoupling the message listener and the message processing application in the message consumer end belongs to the concept of the present invention.

By decoupling the message listener from the message processing application, it is possible to avoid the problem that the entire system is wrong due to modification of a certain code during code maintenance or project iteration, and achieves the design requirements of high cohesion and low coupling.

S22. Monitor the message queue, and if it is detected that there is an abnormal message queue in the message queue, notify the monitoring manager of the message consumer end of the abnormal message queue through a predetermined channel.

In an exemplary embodiment of the present invention, a queue monitoring module may be configured in the message queue server. First, the queue monitoring module can monitor each message queue. Specifically, the objects monitored by the queue monitoring module can include but are not limited to the length of the message queue. In this case, monitoring the message queue can include judging the length of the message queue. Is it abnormal? Next, you can configure a listener manager on the message consumer side to detect message listeners. When the queue monitoring module detects that there is an abnormal message queue in the message queue, it can notify the monitoring manager of the message consumer of the abnormal message queue.

For example, the length of the predefined message queue is 1M. When the queue monitoring module detects that the length of the message queue A is greater than 1M, it can determine the message queue A as an abnormal message queue and notify the monitoring manager of the message queue A.

According to some embodiments of the present invention, the queue monitoring module may notify the monitoring manager of the abnormal message queue through a predetermined channel. Specifically, the predetermined channel may be a transmission channel constructed by the HTTP protocol, however, the predetermined channel may also be a transmission channel using a RESTful interface for communication, however, not limited to this, the present invention may also use other communication methods to realize the communication between the queue monitoring module and the queue monitoring module. The information transmission between monitoring managers is not specially limited in this exemplary embodiment.

S24. The monitoring manager determines the message listener corresponding to the exception message queue as the target listener.

In the exemplary embodiment of the present invention, after the queue monitoring module notifies the monitoring manager of the abnormal message queue, the monitoring manager can determine the message listener corresponding to the abnormal message queue, and can use the message listener as the target monitoring device.

According to some embodiments of the present invention, a message listener may correspond to one or more message queues. The monitoring manager may determine the message listener corresponding to the abnormal message queue based on the corresponding relationship between the configured message listener and the message queue. For example, the server may store a correspondence table between message listeners and message queues, and may determine the message listener corresponding to the abnormal message queue by looking up the table.

S26. Detect the target listener so as to restart the target listener if a target listener failure is detected.

After the target listener is determined, the working state of the target listener can be detected. Specifically, if a failure of the target listener is detected, the target listener is restarted. Among them, the reasons for the failure of the target listener may include various aspects, for example, software failure, data corruption, security loopholes, and the like. These failures may cause the target listener to go down, resulting in an abnormal message queue length. That is, a target listener failure may be the cause of an exception to the message queue.

In addition, when the monitoring manager detects the target listener, that is, when the monitoring manager determines the message listener corresponding to the abnormal message queue, an alarm signal can be sent. For example, alarm information can be sent to developers or operation and maintenance personnel in the form of text messages or emails so that the developers or operation and maintenance personnel can learn about the abnormal message queue.

The method for handling monitoring faults of the present invention will be described below by taking the data communication shown in FIG. 4 as an example.

On the one hand, the message producer 41 can send the message produced by it to the message exchange 421 in the message queue server 42, and the message exchange 421 can send the received message data to the message queue 422, the message queue 423, the message queue 424, the message Queue 425, message queue 426 or message queue 427. In addition, the queue detection module 4800 can monitor in real time whether message queues with abnormal lengths exist in the message queues 422 to 427; In addition, the message listener 441 in the message consumer 44 can be decoupled from the message processing application 442 and the message processing application 443, and the message listener 451 in the message consumer 45 can be decoupled from the message processing application 452 and the message processing application. 453 Decoupling.

First, taking the abnormal length of the message queue 422 as an example, when the queue monitoring module 4800 detects that the message queue 422 is abnormal, it can notify the monitoring manager 4900 of the message queue 422 through the RESTful interface 4700; then, the monitoring manager 4900 can determine the The message listener corresponding to the message queue 422 is the message listener 431, and whether the message listener 431 is faulty is detected. If the failure of the message listener 431 is detected, the message listener 431 is restarted.

It can be seen from this process that, using the monitoring fault processing method of the present invention, the whole process does not require manual participation, and only when a fault of the message listener is found, alarm information can be sent to developers or operation and maintenance personnel, and the alarm information is sent only to inform the system of problems. , does not require manual repair of the fault. The invention can realize the automatic repairing process of abnormal message queue, thereby shortening the time delayed by manual participation.

In the monitoring fault processing method of the exemplary embodiment of the present invention, the abnormal message queue is monitored by decoupling the message listener from the message processing application, and the listener corresponding to the abnormal message queue is determined as the target listener, and the target listener is detected. And restart the target listener when the target listener fails. On the one hand, by automatically restarting the listener, the problem of abnormal message queue caused by the listener failure can be solved without manual participation; Coupling can avoid the problem of errors in the entire system caused by modifying a certain code during code maintenance or project iteration, and achieves the design requirements of high cohesion and low coupling.

It should be noted that although the various steps of the methods of the present invention are depicted in the figures in a particular order, this does not require or imply that the steps must be performed in that particular order, or that all illustrated steps must be performed to achieve the desired the result of. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step for execution, and/or one step may be decomposed into multiple steps for execution, and the like.

Further, the present exemplary embodiment also provides a monitoring fault processing system.

FIG. 5 schematically shows a block diagram of a listening fault processing system according to an exemplary embodiment of the present invention. The monitoring fault processing system may include a message queue and a message consumer. Referring to FIG. 5, a monitoring fault processing system 5 according to an exemplary embodiment of the present invention may include a decoupling module 51, a queue monitoring module 53 and a monitoring manager 55, wherein:

The decoupling module 51 can be used to decouple the message listener from the message processing application at the message consumer;

The queue monitoring module 53 can be used to monitor the message queue, and when an abnormal message queue is detected in the message queue, notify the abnormal message queue to the monitoring manager of the message consumer through a predetermined channel ;

The monitoring manager 55 can be used to determine a message listener corresponding to the abnormal message queue as a target listener, and to detect the target listener so as to restart the target when a failure of the target listener is detected listener.

In the monitoring fault processing system of the exemplary embodiment of the present invention, on the one hand, by automatically restarting the listener, the problem of the abnormal message queue caused by the listener failure can be solved without manual participation; on the other hand, the message listener and the message Dealing with application decoupling can avoid the problem of errors in the entire system caused by modifying a certain code during code maintenance or project iteration, and achieves the design requirements of high cohesion and low coupling.

According to an exemplary embodiment of the present invention, referring to FIG. 6 , the decoupling module 51 may include a processing application registration unit 601, a transmission condition obtaining unit 603 and a message sending unit 605, wherein:

A processing application registration unit 601, which can be used to register a message processing application;

A transmission condition acquisition unit 603, which can be used to acquire message transmission conditions from the message processing application;

The message sending unit 605 may be configured to send the message to the corresponding message processing application via the message listener according to the message transmission condition.

This exemplary embodiment provides a solution for decoupling a message listener from a message processing application.

According to an exemplary embodiment of the present invention, referring to FIG. 7 , compared to the monitoring fault processing system 5 , the monitoring fault processing system 7 may include a data transmission module in addition to the decoupling module 51 , the queue monitoring module 53 and the monitoring manager 55 71, of which:

The data transmission module 71 can be used to implement the data transmission between the message listener and the message processing application by adopting the RESTful architecture.

Through the RESTful architecture, stateless loose coupling of resources can be achieved, which satisfies the design goal of high cohesion and low coupling between message listeners and message processing applications.

According to an exemplary embodiment of the present invention, referring to FIG. 8 , the queue monitoring module 53 may include an exception queue notification unit 801, wherein:

The abnormal queue notification unit 801 can be configured to notify the monitoring manager of the message consumer end of the abnormal message queue through the HTTP protocol or the RESTful interface when it is detected that there is an abnormal message queue in the message queue.

The information channel between the queue monitoring module and the monitoring manager is configured through the HTTP protocol or the RESTful interface, and the process of determining the fault of the message listener based on the monitoring results of the queue monitoring module is realized.

According to an exemplary embodiment of the present invention, the exception message queue is a message queue with an abnormal queue length. Referring to FIG. 9, the queue monitoring module 91, relative to the queue monitoring module 53, may include, in addition to the abnormal queue notification unit 801, a length abnormality judgment unit 901, wherein:

The length abnormality judging unit 901 can be used to judge whether the length of the message queue is abnormal.

According to an exemplary embodiment of the present invention, referring to FIG. 10 , the monitoring manager 55 may include a monitoring unit 1001, wherein:

The monitoring unit 1001 can be used for the monitoring manager to determine the message listener corresponding to the abnormal message queue as the target listener according to the correspondence table between the message listener and the message queue.

The target listener is determined by looking up the table, the process is simple and the efficiency is high.

According to an exemplary embodiment of the present invention, referring to FIG. 11 , the monitoring manager 111 may include an alarm signal sending unit 1101, wherein:

The alarm signal sending unit 1101 may be configured to send an alarm signal when a fault of the target listener is detected.

By sending alarm information, developers or operation and maintenance personnel can be informed of the failure of the target listener.

Since each functional module of the program running performance analysis apparatus in the embodiment of the present invention is the same as that in the above-mentioned method in the embodiment of the present invention, it will not be repeated here.

In an exemplary embodiment of the present invention, there is also provided a computer-readable storage medium on which a program product capable of implementing the above-mentioned method of the present specification is stored. In some possible implementations, aspects of the present invention can also be implemented in the form of a program product comprising program code for enabling the program product to run on a terminal device The terminal device performs the steps according to various exemplary embodiments of the present invention described in the "Example Method" section above in this specification.

Referring to FIG. 12, a program product 1200 for implementing the above method according to an embodiment of the present invention is described, which can adopt a portable compact disk read only memory (CD-ROM) and include program codes, and can be stored in a terminal device, For example running on a personal computer. However, the program product of the present invention is not limited thereto, and in this document, a readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus or device, or a combination of any of the above. More specific examples (non-exhaustive list) of readable storage media include: electrical connections with one or more wires, portable disks, hard disks, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM or flash memory), optical fiber, portable compact disk read only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

A computer readable signal medium may include a propagated data signal in baseband or as part of a carrier wave with readable program code embodied thereon. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the foregoing. A readable signal medium can also be any readable medium, other than a readable storage medium, that can transmit, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

Program code embodied on a readable medium may be transmitted using any suitable medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Program code for carrying out operations of the present invention may be written in any combination of one or more programming languages, including object-oriented programming languages—such as Java, C++, etc., as well as conventional procedural Programming Language - such as the "C" language or similar programming language. The program code may execute entirely on the user computing device, partly on the user device, as a stand-alone software package, partly on the user computing device and partly on a remote computing device, or entirely on the remote computing device or server execute on. In the case of a remote computing device, the remote computing device may be connected to the user computing device through any kind of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computing device (eg, using an Internet service provider business via an Internet connection).

In an exemplary embodiment of the present invention, an electronic device capable of implementing the above method is also provided.

As will be appreciated by one skilled in the art, various aspects of the present invention may be implemented as a system, method or program product. Therefore, various aspects of the present invention can be embodied in the following forms: a complete hardware implementation, a complete software implementation (including firmware, microcode, etc.), or a combination of hardware and software aspects, which may be collectively referred to herein as implementations "circuit", "module" or "system".

An electronic device 1300 according to this embodiment of the present invention is described below with reference to FIG. 13 . The electronic device 1300 shown in FIG. 13 is only an example, and should not impose any limitation on the function and scope of use of the embodiments of the present invention.

As shown in FIG. 13, electronic device 1300 takes the form of a general-purpose computing device. Components of the electronic device 1300 may include, but are not limited to: the above-mentioned at least one processing unit 1310, the above-mentioned at least one storage unit 1320, a bus 1330 connecting different system components (including the storage unit 1320 and the processing unit 1310), and a display unit 1340.

Wherein, the storage unit stores program codes, and the program codes can be executed by the processing unit 1310, so that the processing unit 1310 executes various exemplary methods according to the present invention described in the above-mentioned “Exemplary Methods” section of this specification Implementation steps. For example, the processing unit 1310 can perform step S20 as shown in FIG. 2 : decouple the message listener from the message processing application at the message consumer; step S22 : monitor the message queue, if it is detected that there is a message in the message queue abnormal message queue, the abnormal message queue is notified to the monitoring manager of the message consumer through a predetermined channel; step S24: the monitoring manager determines the message listener corresponding to the abnormal message queue as the target listener; step S26: the target listener is processed Check to restart the target listener if a target listener failure is detected.

The storage unit 1320 may include a readable medium in the form of a volatile storage unit, such as a random access storage unit (RAM) 13201 and/or a cache storage unit 13202 , and may further include a read only storage unit (ROM) 13203 .

The storage unit 1320 may also include a program/utility 13204 having a set (at least one) of program modules 13205 including, but not limited to, an operating system, one or more application programs, other program modules, and program data, An implementation of a network environment may be included in each or some combination of these examples.

The bus 1330 may be representative of one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local area using any of a variety of bus structures bus.

The electronic device 1300 may also communicate with one or more external devices 1500 (eg, keyboards, pointing devices, Bluetooth devices, etc.), with one or more devices that enable a user to interact with the electronic device 1300, and/or with Any device (eg, router, modem, etc.) that enables the electronic device 1300 to communicate with one or more other computing devices. Such communication may occur through input/output (I/O) interface 1350 . Also, the electronic device 1300 may communicate with one or more networks (eg, a local area network (LAN), a wide area network (WAN), and/or a public network such as the Internet) through a network adapter 1360 . As shown, network adapter 1360 communicates with other modules of electronic device 1300 via bus 1330. It should be appreciated that, although not shown, other hardware and/or software modules may be used in conjunction with electronic device 1300, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives and data backup storage systems.

From the description of the above embodiments, those skilled in the art can easily understand that the exemplary embodiments described herein may be implemented by software, or may be implemented by software combined with necessary hardware. Therefore, the technical solutions according to the embodiments of the present invention can be embodied in the form of software products, and the software products can be stored in a non-volatile storage medium (which can be CD-ROM, U disk, mobile hard disk, etc.) or on the network , including several instructions to cause a computing device (which may be a personal computer, a server, a terminal device, or a network device, etc.) to execute the method according to an embodiment of the present invention.

Furthermore, the above-mentioned figures are merely schematic illustrations of the processes included in the methods according to the exemplary embodiments of the present invention, and are not intended to be limiting. It is easy to understand that the processes shown in the above figures do not indicate or limit the chronological order of these processes. In addition, it is also readily understood that these processes may be performed synchronously or asynchronously, for example, in multiple modules.

It should be noted that although several modules or units of the apparatus for action performance are mentioned in the above detailed description, this division is not mandatory. Indeed, according to embodiments of the present invention, the features and functions of two or more modules or units described above may be embodied in one module or unit. Conversely, the features and functions of one module or unit described above may be further divided into multiple modules or units to be embodied.

Other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses or adaptations of the invention which follow the general principles of the invention and which include common knowledge or conventional techniques in the art not disclosed by the invention . The specification and examples are to be regarded as exemplary only, with the true scope and spirit of the invention being indicated by the claims.

It should be understood that the present invention is not limited to the precise structures described above and illustrated in the accompanying drawings, and that various modifications and changes may be made without departing from its scope. The scope of the present invention is limited only by the appended claims.

Claims (9)

1. A monitoring fault processing method is applied to a system comprising a message queue and a message consumption end, and is characterized in that the monitoring fault processing method comprises the following steps:

at the message consumption end, a RESTful architecture is adopted to realize data transmission between the message listener and the message processing application so as to decouple the message listener and the message processing application; the message listener corresponds to one or more message queues;

monitoring the message queue, and if an abnormal message queue exists in the message queue, notifying the abnormal message queue to a monitoring manager of the message consumption end through a preset channel;

the monitoring manager determines a message monitor corresponding to the abnormal message queue as a target monitor;

detecting the target listener to restart the target listener if the target listener is detected as malfunctioning.

2. The snoop failure handling method of claim 1, wherein decoupling the message listener from the message processing application comprises:

registering a message processing application;

obtaining message transmission conditions from the message processing application;

and sending the message to the corresponding message processing application through the message listener according to the message transmission condition.

3. The snoop fault handling method according to claim 1, wherein notifying the snoop manager of the message consuming side of the exception message queue through a predetermined channel comprises:

and notifying the abnormal message queue to a monitoring manager of the message consumption end through an HTTP protocol or a RESTful interface.

4. The snoop fault handling method according to claim 1 or 3, wherein the exception message queue is a message queue with an exception queue length;

wherein monitoring the message queue comprises:

and judging whether the length of the message queue is abnormal or not.

5. The snoop fault handling method of claim 1, wherein said snoop manager determining a message listener corresponding to said exception message queue as a target listener comprises:

and the monitoring manager determines the message monitor corresponding to the abnormal message queue as a target monitor according to the corresponding relation table between the message monitors and the message queue.

6. The snoop fault handling method according to claim 1, wherein the snoop fault handling method further comprises:

and sending an alarm signal under the condition that the target monitor is detected to be in fault.

7. A monitoring fault processing system comprises a message queue and a message consumption end, and is characterized in that the monitoring fault processing system further comprises:

a decoupling module, configured to implement, at the message consumption end, data transmission between the message listener and the message processing application by using a RESTful architecture, so as to decouple the message listener from the message processing application; the message listener corresponds to one or more message queues;

the queue monitoring module is used for monitoring the message queue and notifying the abnormal message queue to a monitoring manager of the message consumption end through a preset channel when the abnormal message queue exists in the message queue;

and the monitoring manager is used for determining a message monitor corresponding to the abnormal message queue as a target monitor, and detecting the target monitor so as to restart the target monitor under the condition that the fault of the target monitor is detected.

8. A storage medium having stored thereon a computer program, wherein the computer program, when executed by a processor, implements the snoop fault handling method of any of claims 1 to 6.

9. An electronic device, comprising:

a processor; and

a memory for storing executable instructions of the processor;

wherein the processor is configured to perform the snoop fault handling method of any of claims 1-6 via execution of the executable instructions.

Images