CN107896172B - Monitoring fault processing method and device, storage medium and electronic equipment - Google Patents
Monitoring fault processing method and device, storage medium and electronic equipment Download PDFInfo
- Publication number
- CN107896172B CN107896172B CN201711193568.XA CN201711193568A CN107896172B CN 107896172 B CN107896172 B CN 107896172B CN 201711193568 A CN201711193568 A CN 201711193568A CN 107896172 B CN107896172 B CN 107896172B
- Authority
- CN
- China
- Prior art keywords
- message
- queue
- listener
- message queue
- monitoring
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
- H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0659—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities
- H04L41/0661—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities by reconfiguring faulty entities
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
Technical Field
The present invention relates to the field of data communication technologies, and in particular, to a monitoring fault processing method, a monitoring fault processing apparatus, a storage medium, and an electronic device.
Background
With the development of social informatization, data interaction among all business systems is more and more frequent. At present, RabbitMQ (a data communication method) is often adopted among service systems to realize data interaction. Specifically, first, the message Producer (Producer) may send a message to the message Exchange (Exchange); the message switch may then distribute the message to various queues (Queue) bound to the message switch; in addition, the message Consumer (Consumer) can Monitor the queue through a Monitor (Monitor), and after the messages in the queue are monitored and processed by the message Consumer, the message Consumer can feed back a Callback (Callback) to the queue; next, the queue may clear the current message. Thus, the current data interaction process ends.
On one hand, however, the problem that the length of the messages in the queue is accumulated too high due to the down of the listener and the like exists at present; on the other hand, for the message consumption end, the coupling degree of the listener and the message processing application for specifically processing the message is high, and when code maintenance is performed on the listener or the message processing application or project iteration is performed, a developer modifies a certain code, which may cause an error of the whole system, and this does not meet the design requirement of high cohesion and low coupling.
In view of this, there is a need for a snoop fault handling method, a snoop fault handling apparatus, a storage medium, and an electronic device.
It is to be noted that the information disclosed in the above background section is only for enhancement of understanding of the background of the present invention and therefore may include information that does not constitute prior art known to a person of ordinary skill in the art.
Disclosure of Invention
An object of the present invention is to provide a listening fault processing method, a listening fault processing apparatus, a storage medium, and an electronic device, which overcome one or more of the problems due to the limitations and disadvantages of the related art, at least to some extent.
According to one 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 consuming side, and the monitoring fault processing method includes:
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.
Optionally, decoupling the message listener from the message processing application comprises:
registering a message processing application;
acquiring message transmission conditions from a message processing application;
and sending the message to the corresponding message processing application through the message listener according to the message transmission condition.
Optionally, the snoop fault handling method further includes:
and adopting a RESTful architecture to realize data transmission between the message listener and the message processing application.
Optionally, the monitoring manager for notifying the message consumer of the abnormal message queue through the predetermined channel includes:
and informing the abnormal message queue to a monitoring manager of the message consumption end through an HTTP protocol or a RESTful interface.
Optionally, 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.
Optionally, the snoop manager determining a message listener corresponding to the exception message queue as the 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.
Optionally, the snoop fault handling method further includes:
and sending an alarm signal when the target monitor is detected to be in fault.
According to an aspect of the present invention, there is provided a snoop fault handling system, including a message queue and a message consuming side, the snoop fault handling system further including:
a decoupling module for decoupling the message listener from the message processing application at the message consuming side;
the queue monitoring module is used for monitoring the message queue and notifying the abnormal message queue to a monitoring manager of a message consumption end through a predetermined channel when the abnormal message queue exists in the monitored 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 target monitor is detected to be in fault.
Optionally, the decoupling module comprises:
a processing application registration unit for registering the message processing application;
a transmission condition acquisition unit for acquiring a message transmission condition from the message processing application;
and the message sending unit is used for sending the message to the corresponding message processing application through the message listener according to the message transmission condition.
Optionally, the snoop fault handling apparatus further includes:
and the data transmission module is used for realizing data transmission between the message listener and the message processing application by adopting a RESTful architecture.
Optionally, the queue monitoring module comprises:
and the abnormal queue notification unit is used for notifying the abnormal message queue to a monitoring manager of the message consumption end through an HTTP protocol or a RESTful interface when the abnormal message queue exists in the message queue.
Optionally, the exception message queue is a message queue with an exception queue length;
wherein, the queue monitoring module still includes:
and the length abnormity judging unit is used for judging whether the length of the message queue is abnormal or not.
Optionally, the snoop manager comprises:
and the monitoring unit is used for determining the message monitor corresponding to the abnormal message queue as a target monitor by the monitoring manager according to the corresponding relation table between the message monitors and the message queue.
Optionally, the listening manager further comprises:
and the alarm signal sending unit is used for sending an alarm signal under the condition that the target monitor is detected to be in fault.
According to an aspect of the present invention, there is provided a storage medium having stored thereon a computer program which, when executed by a processor, implements the snoop fault handling method of any one of the above.
According to an aspect of the present invention, there is provided an electronic apparatus including:
a processor; and
a memory for storing executable instructions of the processor;
wherein the processor is configured to perform any of the above-described snoop failure handling methods via execution of executable instructions.
In the technical solutions provided in some embodiments of the present invention, by decoupling a message listener from a message processing application, monitoring an abnormal message queue, determining a listener corresponding to the abnormal message queue as a target listener, detecting the target listener, and restarting the target listener when the target listener fails, on the one hand, by automatically restarting the listener, the problem of message queue abnormality caused by listener failure can be solved without manual involvement; on the other hand, the message listener and the message processing application are decoupled, so that the problem of whole system errors caused by modifying a certain code during code maintenance or project iteration can be avoided, and the design requirement of high cohesion and low coupling is realized.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.
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. It is obvious that the drawings in the following description are only some embodiments of the invention, and that for a person skilled in the art, other drawings can be derived from them without inventive effort. In the drawings:
fig. 1 schematically illustrates a block diagram of RabbitMQ mode-based data communication in some aspects of the prior art;
FIG. 2 schematically illustrates a flow diagram of a snoop fault handling method according to an exemplary embodiment of the present invention;
FIG. 3 schematically illustrates a block diagram of data communications after decoupling a message listener from a message processing application, according to an illustrative embodiment of the present invention;
FIG. 4 schematically illustrates a block diagram of data communications employing the snoop fault handling method of an exemplary embodiment of the present invention;
FIG. 5 schematically illustrates a block diagram of a snoop fault handling system according to an exemplary embodiment of the present invention;
FIG. 6 schematically illustrates a block diagram of a decoupling module according to an exemplary embodiment of the present invention;
FIG. 7 schematically illustrates another block diagram of a snoop fault handling system in accordance with an exemplary embodiment of the present invention;
FIG. 8 schematically illustrates a block diagram of a queue monitoring module according to an exemplary embodiment of the present invention;
FIG. 9 schematically illustrates another block diagram of a queue monitoring module according to an exemplary embodiment of the present invention;
FIG. 10 schematically illustrates a block diagram of a snoop manager in accordance with an exemplary embodiment of the present invention;
FIG. 11 schematically illustrates another block diagram of a snoop manager in accordance with an exemplary embodiment of the present invention;
FIG. 12 illustrates a schematic diagram of a storage medium according to an exemplary embodiment of the present invention; and
fig. 13 schematically shows a block diagram of an electronic device according to an exemplary embodiment of the present invention.
Detailed Description
Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different 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 to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention may be practiced without one or more of the specific details, or with other methods, components, devices, steps, and so forth. In other instances, well-known technical 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 repetitive description will be omitted. Some of the block diagrams shown in the figures are functional entities and do not necessarily correspond to physically or logically separate entities. These functional entities may be implemented in the form of 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 drawings are merely illustrative and do not necessarily include all of the steps. For example, some steps may be decomposed, and some steps may be combined or partially combined, so that the actual execution sequence may be changed according to the actual situation.
Fig. 1 schematically illustrates a block diagram of RabbitMQ mode-based data communication in some aspects of the prior art. The data communication process may be: first, the message producing end 11 can send the produced message data to the message switch 121 in the message queue server 12; next, the message switch 121 may send the message data to the message queue 122, the message queue 123, the message queue 124, or the message queue 125 bound thereto; taking the example of sending message data to message queue 122, message consumer 13 corresponding to message queue 122 can monitor message queue 122 through its message listener 131, and when message data is sent to message queue 122, message listener 131 can listen to and obtain the message data and send the message data to a message processing application (not shown) in message consumer 13 so that the message processing application processes the data. Thereby, the data communication process based on the RabbitMQ mode is completed. In addition, message consumer 14 including message listener 141 may correspond to message queue 123, message consumer 15 including message listener 151 may correspond to message queue 124, and message consumer 16 including message listener 161 may correspond to message queue 125, and their specific data communication manners may be the same as those corresponding to message queue 122, and are not described herein again.
However, disadvantages of such data communication approaches may include: on one hand, if a message listener is down, the problem of data accumulation of a corresponding message queue may occur, and developers or operation and maintenance personnel cannot find the problem in time; on the other hand, for the message consumption end, the coupling degree of the listener and the message processing application is high, and when the code maintenance is performed on the listener or the message processing application or the project iteration is performed, a developer modifies a certain code, which may cause an error of the whole system, and this does not meet the design requirement of high cohesion and low coupling.
In view of this, the present invention provides a monitoring fault handling method.
Fig. 2 schematically shows a flowchart of a snoop fault handling method of an exemplary embodiment of the present invention. The monitoring fault processing method can be applied to a system comprising a message queue and a message consuming terminal, and referring to fig. 2, the monitoring fault processing method of the present invention can comprise the following steps:
s20, decoupling the message listener from the message processing application at the message consumption end.
In an exemplary embodiment of the present invention, a message consumer may include a message listener and a message processing application. The message listener can be used for monitoring a message queue corresponding to the message consumption end, the message processing application can be an application for specifically processing message data, and can be used for processing, integrating, displaying and the like of the data.
According to some embodiments of the invention, the method of specific decoupling may for example comprise: first, a message handling application may be registered; next, the user may configure the message transmission condition at the client side, specifically, the user may configure the message transmission condition through a user operation interface corresponding to the message processing application; the server may then send the message via the message listener to the corresponding message processing application according to the message transmission conditions. In the above message transmission process, a RESTful architecture may be used to implement data transmission between the message listener and the message processing application, specifically, the message transmission condition may be converted into RESTful data compatible with each module, and a RESTful service interface may be provided to perform corresponding transmission service. In addition, data blocking and sorting can be performed based on various types of markup languages (such as URI) of RESTful, and data is classified according to historical records, so that not only can maximum data storage be obtained, but also more accurate guidance is provided for screening.
Based on RESTful architecture, a stateless resource-oriented loose coupling structure can be realized, the state of current message transmission does not need to be considered, and the design target of high-cohesion low-coupling of a message listener and a message processing application is met.
FIG. 3 schematically illustrates a block diagram of data communications after decoupling a message listener from a message processing application, according to an exemplary embodiment of the present invention. First, the message producing end 31 can send the message produced by it to the message switch 321 in the message queue server 32, and in addition, although not shown in the figure, it should be understood that the message queue server 32 can also include other message switches, and the number of message switches is not particularly limited by the present invention; subsequently, the message switch 321 can send the message to the message queue 322, the message queue 323, the message queue 324, or the message queue 325, and in addition, similarly, other message queues and/or other message queues corresponding to the message switch 321 can be included in the message queue server 32; next, taking the message sent to the message queue 322 as an example, the message listener 331 in the message consumer 33 can acquire the message after monitoring that the message queue 322 receives the message. Furthermore, on the one hand, the message listener 331 in the message consumer 33 can send the message to the message processing application 332 decoupled therefrom, so that the message processing application 332 processes the message, the decoupling being advantageous here in that if the code of the message listener 331 is modified, the message processing application 332 is not directly affected; on the other hand, although not shown in the figure, the message consumer 33 may further include other message processing applications corresponding to the message listener 331. Similarly, message consumer 34, which includes message listener 341 and message handling application 342 decoupled therefrom, may correspond to message queue 323, message consumer 35, which includes message listener 351 and message handling application 352 decoupled therefrom, may correspond to message queue 324, and message consumer 36, which includes message listener 361 and message handling application 362 decoupled therefrom, may correspond to message queue 325, and their specific data communication manners are the same as those corresponding to message queue 322, and are not described herein again.
In addition, the invention can adopt other architectures to realize the decoupling of the message listener and the message consuming end, for example, a lightweight open source architecture Spring can be adopted to realize the decoupling. It should be understood that the present invention contemplates the decoupling of a message listener from a message processing application in a message consuming side.
By decoupling the message listener from the message processing application, the problem of whole system errors caused by modifying a certain code during code maintenance or project iteration can be avoided, and the design requirement of high cohesion and low coupling is realized.
And S22, 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 the message consumption end through a preset channel.
In an exemplary embodiment of the present invention, a queue monitoring module may be configured in a message queue server. First, the queue monitoring module may monitor each message queue, specifically, an object monitored by the queue monitoring module may include, but is not limited to, a length of the message queue, and in this case, monitoring the message queue may include determining whether the length of the message queue is abnormal; next, a snoop manager for detecting message listeners can be configured at the message consumer. When the queue monitoring module monitors that an abnormal message queue exists in the message queue, the abnormal message queue can be notified to a monitoring manager of the message consumption end.
For example, the length of the predefined message queue is 1M, and when the queue monitoring module detects that the length of the message queue a is greater than 1M, the message queue a may be determined as an abnormal message queue and notified to the snoop manager.
According to some embodiments of the invention, the queue monitoring module may notify the snoop manager of the exception message queue through a predetermined channel. Specifically, the predetermined channel may be a transmission channel established by an HTTP protocol, however, the predetermined channel may also be a transmission channel for performing communication by using a RESTful interface, however, the present invention is not limited to this, and the present invention may also implement information transmission between the queue monitoring module and the monitoring manager by using other communication methods, which is not limited in this exemplary embodiment.
S24, the monitoring manager determines a message monitor corresponding to the abnormal message queue as a target monitor.
In an exemplary embodiment of the present invention, after the queue monitoring module notifies the listening manager of the abnormal message queue, the listening manager may determine a message listener corresponding to the abnormal message queue and may use the message listener as a target listener.
According to some embodiments of the invention, a message listener may correspond to one or more message queues. The snoop manager can 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 the message listener and the message queue, and may determine the message listener corresponding to the abnormal message queue by means of table lookup.
S26, detecting the target listener so as to restart the target listener under the condition that the target listener is detected to be in failure.
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. The cause of the failure of the target listener may include various aspects, such as software failure, data corruption, security breaches, and the like. These failures may cause the target listener to be down, which in turn may cause message queue length anomalies. That is, a failure of the target listener may be the cause of an exception to the message queue.
In addition, an alarm signal may be sent when the snoop manager is detecting a target listener, that is, when the snoop manager determines a message listener corresponding to an abnormal message queue. For example, the alarm information may be sent to the developer or the operation and maintenance staff in the form of a short message or an email so that the developer or the operation and maintenance staff can know the condition of the abnormal message queue.
The snoop failure handling method of the present invention will be described below by taking the data communication shown in fig. 4 as an example.
In one aspect, the message producer 41 may send the message produced by it to the message switch 421 in the message queue server 42, and the message switch 421 may send the received message data to the message queue 422, the message queue 423, the message queue 424, the message queue 425, the message queue 426, or the message queue 427. In addition, the queue detection module 4800 can monitor whether there is a message queue with abnormal length in the message queues 422 to 427 in real time; on the other hand, message listener 431 in message consumption peer 43 may be decoupled from message handling application 432 and message handling application 433, message listener 441 in message consumption peer 44 may be decoupled from message handling application 442 and message handling application 443, and message listener 451 in message consumption peer 45 may be decoupled from message handling application 452 and message handling application 453.
First, taking the length of the message queue 422 as an example, when the queue monitoring module 4800 monitors that the message queue 422 is abnormal, the message queue 422 may be notified to the snoop manager 4900 through the RESTful interface 4700; next, snoop manager 4900 may determine that the message listener corresponding to message queue 422 is message listener 431 and detect whether message listener 431 is down. If message listener 431 failure is detected, message listener 431 is restarted.
It can be seen from this process that, by applying the monitoring fault processing method of the present invention, the whole process does not need manual participation, and only when the fault of the message monitor is found, alarm information can be sent to developers or operation and maintenance personnel, and the sending of the alarm information only informs the system of the problem, and the fault does not need to be repaired manually. The invention can realize the automatic repairing process of the message queue abnormity, thereby shortening the time delayed by manual participation.
In the monitoring fault processing method of the exemplary embodiment 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, on the one hand, by automatically restarting the listener, the problem of message queue abnormality caused by listener failure can be solved without manual involvement; on the other hand, the message listener and the message processing application are decoupled, so that the problem of whole system errors caused by modifying a certain code during code maintenance or project iteration can be avoided, and the design requirement of high cohesion and low coupling is realized.
It should be noted that although the steps of the methods of the present invention are depicted in the drawings in a particular order, this does not require or imply that the steps must be performed in this particular order, or that all of the depicted steps must be performed, to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step execution, and/or one step broken down into multiple step executions, etc.
Further, the present exemplary embodiment also provides a snoop fault handling system.
FIG. 5 schematically illustrates a block diagram of a snoop fault handling system in accordance with an exemplary embodiment of the present invention. The snoop fault handling system may include a message queue and a message consumer. Referring to fig. 5, the snoop fault handling system 5 according to an exemplary embodiment of the present invention may include a decoupling module 51, a queue monitoring module 53, and a snoop manager 55, wherein:
a decoupling module 51 operable to decouple the message listener from the message processing application at the message consumer;
a queue monitoring module 53, configured to monitor the message queue, and notify the abnormal message queue to a monitoring manager of the message consuming side through a predetermined channel when it is monitored that the abnormal message queue exists in the message queue;
snoop manager 55 may be configured to determine a message listener corresponding to the exception message queue as a target listener, and detect the target listener to restart the target listener if a failure of the target listener is detected.
In the monitoring fault handling system of the exemplary embodiment of the present invention, on one hand, by automatically restarting the listener, the problem of message queue exception caused by listener failure can be solved without manual involvement; on the other hand, the message listener and the message processing application are decoupled, so that the problem of whole system errors caused by modifying a certain code during code maintenance or project iteration can be avoided, and the design requirement of high cohesion and low coupling is realized.
According to an exemplary embodiment of the present invention, referring to fig. 6, the decoupling module 51 may include a processing application registering unit 601, a transmission condition obtaining unit 603, and a message sending unit 605, wherein:
a processing application registration unit 601, which may be used to register a message processing application;
a transmission condition acquisition unit 603, which may be configured to acquire a message transmission condition from a 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.
The illustrative embodiments provide a solution for implementing message listener and message processing application decoupling.
According to an exemplary embodiment of the present invention, referring to fig. 7, the snoop fault handling system 7 may further include a data transmission module 71, in addition to the decoupling module 51, the queue monitoring module 53 and the snoop manager 55, with respect to the snoop fault handling system 5, wherein:
the data transmission module 71 may be configured to implement data transmission between the message listener and the message processing application by using a RESTful architecture.
Through RESTful architecture, stateless resource loose coupling can be realized, and the design target of high-cohesion low-coupling of the message listener and the message processing application is met.
According to an exemplary embodiment of the present invention, referring to fig. 8, the queue monitoring module 53 may include an abnormal queue notification unit 801, wherein:
the exception queue notification unit 801 may be configured to notify, when an exception message queue exists in the message queue, the exception message queue to a snoop manager of the message consuming side through an HTTP protocol or a RESTful interface.
And an information channel between the queue monitoring module and the monitoring manager is configured through an HTTP protocol or a RESTful interface, so that the process of determining the fault of the message monitor based on the monitoring result 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 exception queue length. Referring to fig. 9, the queue monitoring module 91 may further include a length abnormality determination unit 901 in addition to the abnormal queue notification unit 801 with respect to the queue monitoring module 53, wherein:
the length exception determining unit 901 may be configured to determine whether the length of the message queue is abnormal.
According to an exemplary embodiment of the present invention, referring to fig. 10, the listening manager 55 may comprise a listening unit 1001, wherein:
the snooping unit 1001 may be configured to determine, by the snoop manager, a message listener corresponding to the abnormal message queue as a target listener according to the correspondence table between the message listener and the message queue.
The target monitor is determined by means of table lookup, the process is simple and convenient, and the efficiency is high.
According to an exemplary embodiment of the present invention, referring to fig. 11, the listening manager 111 may include an alarm signal transmitting unit 1101, wherein:
the alarm signal sending unit 1101 may be configured to send an alarm signal when the target listener is detected to be faulty.
By sending alarm information, developers or operation and maintenance personnel can know the fault condition of the target monitor.
Since each functional module of the program operation performance analysis apparatus according to the embodiment of the present invention is the same as that in the embodiment of the present invention, it is not described herein again.
In an exemplary embodiment of the present invention, there is also provided a computer-readable storage medium having stored thereon a program product capable of implementing the above-described method of the present specification. In some possible embodiments, aspects of the invention may also be implemented in the form of a program product comprising program code means for causing a terminal device to carry out the steps according to various exemplary embodiments of the invention described in the above section "exemplary methods" of the present description, when said program product is run on the terminal device.
Referring to fig. 12, a program product 1200 for implementing the above method according to an embodiment of the present invention is described, which may employ a portable compact disc read only memory (CD-ROM) and include program code, and may be run on a terminal device, such as a personal computer. However, the program product of the present invention is not limited in this regard and, in the present document, a readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection 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. A readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable disk, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
A computer readable signal medium may include a propagated data signal with readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A readable signal medium may also be any readable medium that is not a readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
Program code embodied on a readable medium may be transmitted using any appropriate 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 for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computing device, partly on the user's device, as a stand-alone software package, partly on the user's computing device and partly on a remote computing device, or entirely on the remote computing device or server. 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 (e.g., through the internet using an internet service provider).
In an exemplary embodiment of the present invention, there is also provided an electronic device capable of implementing the above method.
As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or program product. Thus, various aspects of the invention may be embodied in the form of: an entirely hardware embodiment, an entirely software embodiment (including firmware, microcode, etc.) or an embodiment combining hardware and software aspects that may all generally be referred to herein as a "circuit," module "or" system.
An electronic device 1300 according to this embodiment of the invention is described below with reference to fig. 13. The electronic device 1300 shown in fig. 13 is only an example and should not bring any limitations to the function and scope of use of the embodiments of the present invention.
As shown in fig. 13, the electronic device 1300 is in the form of a general purpose computing device. The components of the electronic device 1300 may include, but are not limited to: the at least one processing unit 1310, the at least one memory unit 1320, the bus 1330 connecting the various system components (including the memory unit 1320 and the processing unit 1310), the display unit 1340.
Wherein the memory unit stores program code that is executable by the processing unit 1310 to cause the processing unit 1310 to perform steps according to various exemplary embodiments of the present invention as described in the "exemplary methods" section above in this specification. For example, the processing unit 1310 may execute step S20 as shown in fig. 2: decoupling a message listener from a message processing application at a message consuming end; step S22: 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; step S24: the monitoring manager determines a message monitor corresponding to the abnormal message queue as a target monitor; step S26: the target listener is detected to restart the target listener in the event that a failure of the target listener is detected.
The storage 1320 may include readable media in the form of volatile memory units, such as a random access memory unit (RAM)13201 and/or a cache memory unit 13202, and may further include a read-only memory unit (ROM) 13203.
The electronic device 1300 may also communicate with one or more external devices 1500 (e.g., keyboard, pointing device, bluetooth device, etc.), with one or more devices that enable a user to interact with the electronic device 1300, and/or with any devices (e.g., router, modem, etc.) that enable the electronic device 1300 to communicate with one or more other computing devices. Such communication may occur via input/output (I/O) interfaces 1350. Also, the electronic device 1300 may communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network, such as the internet) through the network adapter 1360. As shown, the network adapter 1360 communicates with other modules of the electronic device 1300 via the bus 1330. It should be appreciated that although not shown, other hardware and/or software modules may be used in conjunction with the 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, among others.
Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, or by software in combination with necessary hardware. Therefore, the technical solution according to the embodiment of the present invention can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to make a computing device (which can be a personal computer, a server, a terminal device, or a network device, etc.) execute the method according to the embodiment of the present invention.
Furthermore, the above-described figures are merely schematic illustrations of processes involved in methods according to exemplary embodiments of the invention, and are not intended to be limiting. It will be readily understood that the processes shown in the above figures are not intended to indicate or limit the chronological order of the processes. In addition, it is also readily understood that these processes may be performed synchronously or asynchronously, e.g., in multiple modules.
It should be noted that although in the above detailed description several modules or units of the device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functionality of two or more modules or units described above may be embodied in one module or unit, according to embodiments of the invention. Conversely, the features and functions of one module or unit described above may be further divided into embodiments by a plurality of modules or units.
Other embodiments of the invention will be apparent to those skilled in the art from 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 following, in general, the principles of the invention and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.
It will be understood that the invention is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the invention is only limited 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.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711193568.XA CN107896172B (en) | 2017-11-24 | 2017-11-24 | Monitoring fault processing method and device, storage medium and electronic equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711193568.XA CN107896172B (en) | 2017-11-24 | 2017-11-24 | Monitoring fault processing method and device, storage medium and electronic equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107896172A CN107896172A (en) | 2018-04-10 |
| CN107896172B true CN107896172B (en) | 2020-06-09 |
Family
ID=61804599
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201711193568.XA Active CN107896172B (en) | 2017-11-24 | 2017-11-24 | Monitoring fault processing method and device, storage medium and electronic equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107896172B (en) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110224922B (en) * | 2019-05-21 | 2022-04-19 | 成都路行通信息技术有限公司 | Asynchronous message retry method, system and system construction method based on RabbitMQ |
| CN111666170B (en) * | 2020-05-29 | 2024-04-12 | 中国工商银行股份有限公司 | Fault node processing method and device based on distributed framework |
| CN113806163A (en) * | 2020-06-12 | 2021-12-17 | 航天信息股份有限公司 | System monitoring method, device, equipment and storage medium |
| CN111600779B (en) * | 2020-06-24 | 2022-03-04 | 厦门长江电子科技有限公司 | Test platform compatible with various switches |
| CN115426209B (en) * | 2022-11-07 | 2023-02-10 | 湖南三湘银行股份有限公司 | High-reliability message queue broadcast control method based on message processing |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103019866A (en) * | 2012-10-24 | 2013-04-03 | 北京京东世纪贸易有限公司 | Distributed method and system based on message queue |
| CN103064731A (en) * | 2012-12-26 | 2013-04-24 | 人民搜索网络股份公司 | Device and method for improving message queue system performance |
| CN105868033A (en) * | 2016-04-06 | 2016-08-17 | 江苏物联网研究发展中心 | Method and system for achieving priority message queues based on Redis |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8286189B2 (en) * | 2007-09-27 | 2012-10-09 | American Express Travel Related Services Company, Inc. | System and method for automatically generating computer code for message flows |
-
2017
- 2017-11-24 CN CN201711193568.XA patent/CN107896172B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103019866A (en) * | 2012-10-24 | 2013-04-03 | 北京京东世纪贸易有限公司 | Distributed method and system based on message queue |
| CN103064731A (en) * | 2012-12-26 | 2013-04-24 | 人民搜索网络股份公司 | Device and method for improving message queue system performance |
| CN105868033A (en) * | 2016-04-06 | 2016-08-17 | 江苏物联网研究发展中心 | Method and system for achieving priority message queues based on Redis |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107896172A (en) | 2018-04-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107896172B (en) | Monitoring fault processing method and device, storage medium and electronic equipment | |
| US9292402B2 (en) | Autonomous service management | |
| US10158726B2 (en) | Supporting high availability for orchestrated services | |
| US11789760B2 (en) | Alerting, diagnosing, and transmitting computer issues to a technical resource in response to an indication of occurrence by an end user | |
| CN107370806B (en) | HTTP status code monitoring method, device, storage medium and electronic equipment | |
| CN111371898B (en) | Message monitoring method, device, equipment and storage medium | |
| CN110851471A (en) | Distributed log data processing method, device and system | |
| CN109299124B (en) | Method and apparatus for updating a model | |
| JP2011113122A (en) | Failure influence analysis device, application system, and failure influence analysis method | |
| CN112860504A (en) | Monitoring method and device, computer storage medium and electronic equipment | |
| EP2495660A1 (en) | Information processing device and method for controlling information processing device | |
| CN110851316A (en) | Abnormity early warning method, abnormity early warning device, abnormity early warning system, electronic equipment and storage medium | |
| US9864613B2 (en) | Configuration checker for application | |
| CN111290873B (en) | Fault processing method and device | |
| US9594622B2 (en) | Contacting remote support (call home) and reporting a catastrophic event with supporting documentation | |
| JP2012174079A (en) | Equipment management system | |
| US10296967B1 (en) | System, method, and computer program for aggregating fallouts in an ordering system | |
| CA3118098C (en) | Alerting, diagnosing, and transmitting computer issues to a technical resource in response to a dedicated physical button or trigger | |
| CN112433915B (en) | Data monitoring method and related device based on distributed performance monitoring tool | |
| US11271798B2 (en) | Automated network link repair | |
| CN116701040A (en) | Abnormal data processing method and device, electronic equipment and computer readable medium | |
| US10282775B1 (en) | System, method, and computer program for automatically remediating fallouts in an ordering system of a consumer telecommunications network | |
| CN113760635A (en) | Method and device for determining connection abnormity, electronic equipment and storage medium | |
| JP2016015021A (en) | Correction applicability judging program, information processing apparatus, and correction applicability judging method | |
| CN114579376A (en) | Gateway operation detection method and device, electronic equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |