CN113890819A - Fault processing method, device and system - Google Patents

Fault processing method, device and system Download PDF

Info

Publication number
CN113890819A
CN113890819A CN202111147582.2A CN202111147582A CN113890819A CN 113890819 A CN113890819 A CN 113890819A CN 202111147582 A CN202111147582 A CN 202111147582A CN 113890819 A CN113890819 A CN 113890819A
Authority
CN
China
Prior art keywords
return information
terminal equipment
fault
opposite terminal
opposite
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202111147582.2A
Other languages
Chinese (zh)
Inventor
李耀东
葛奇维
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hangzhou DPTech Technologies Co Ltd
Original Assignee
Hangzhou DPTech Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hangzhou DPTech Technologies Co Ltd filed Critical Hangzhou DPTech Technologies Co Ltd
Priority to CN202111147582.2A priority Critical patent/CN113890819A/en
Publication of CN113890819A publication Critical patent/CN113890819A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0677Localisation of faults
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/069Management of faults, events, alarms or notifications using logs of notifications; Post-processing of notifications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/10Active monitoring, e.g. heartbeat, ping or trace-route

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Debugging And Monitoring (AREA)

Abstract

The disclosure relates to a fault handling method, device, system, electronic device and computer readable medium. The method comprises the following steps: sending a communication message to opposite-end equipment based on a preset time period; acquiring return information from opposite-end equipment based on the communication message, wherein the return information comprises first return information and/or second return information; judging whether the opposite terminal equipment has a fault or not based on the return information; and when the opposite terminal equipment has faults, carrying out fault processing according to preset configuration. The fault processing method, the fault processing device, the fault processing system, the electronic equipment and the computer readable medium can timely and efficiently find the problems and can also efficiently process the encountered problems.

Description

Fault processing method, device and system
Technical Field
The disclosure relates to the field of computer information processing, and in particular, to a fault processing method, device, system, electronic device, and computer readable medium.
Background
The log management software is used as a data center to receive network behavior logs sent by various network devices (firewall, audit device, IPS, flow cleaning device and the like), and log information such as network flow or internet behavior and the like of a user at any time can be inquired through the data center, or a user who generates the logs in specific time can be positioned through log time, address and other information.
At present, a plurality of management software are separated from one another in a front-end and back-end mode, a front end is generally responsible for various data display parts, a back end is responsible for data receiving and business logic processing, the front end and the back end interact with each other, the back end returns data to the front end, and the front end displays the data in a mode required by a customer. When a problem occurs on a single side of the front end or the back end of the program, the whole application program cannot be normally used, and data loss may be caused.
When the problem of the front end or the rear end of the program is abnormally stopped, the program cannot normally work and cannot send alarm information, and at the moment, the abnormal behavior of the program needs to be manually found and a manager needs to be contacted for corresponding processing, so that not only is the normal service function influenced, but also the manager cannot be timely reminded, and the data service processing is influenced. Moreover, the mode of manually discovering the exception of the front-end program and the back-end program wastes manpower, affects efficiency, cannot find problems in time, causes loss of service data, and affects software reliability.
Therefore, a new fault handling method, apparatus, system, electronic device, and computer readable medium are needed.
The above information disclosed in this background section is only for enhancement of understanding of the background of the disclosure and therefore it may contain information that does not constitute prior art that is already known to a person of ordinary skill in the art.
Disclosure of Invention
In view of the above, the present disclosure provides a fault handling method, apparatus, system, electronic device and computer readable medium, which can efficiently find problems in time and can also efficiently handle encountered problems.
Additional features and advantages of the disclosure will be set forth in the detailed description which follows, or in part will be obvious from the description, or may be learned by practice of the disclosure.
According to an aspect of the present disclosure, a fault handling method is provided, which includes: sending a communication message to opposite-end equipment based on a preset time period; acquiring return information from opposite-end equipment based on the communication message, wherein the return information comprises first return information and/or second return information; judging whether the opposite terminal equipment has a fault or not based on the return information; and when the opposite terminal equipment has faults, carrying out fault processing according to preset configuration.
In an exemplary embodiment of the present disclosure, sending a communication packet by a peer device includes: and sending a heartbeat message and a log acquisition command to the opposite terminal equipment based on a preset time period.
In an exemplary embodiment of the present disclosure, acquiring return information from an opposite-end device based on the communication packet includes: receiving first return information based on the heartbeat message in the communication message; and/or receiving second return information based on the log acquisition command in the communication message.
In an exemplary embodiment of the present disclosure, determining whether the peer device has a failure based on the return information includes: when the first return information is received within a preset time interval, determining that no fault exists in the opposite terminal equipment; and when the first return information is not received within a preset time interval, determining that the opposite terminal equipment has a fault.
In an exemplary embodiment of the present disclosure, determining whether the peer device has a failure based on the return information includes: extracting the information type of the second return information; when the information type is a normal type, determining that no fault exists in the opposite terminal equipment; and when the information type is an abnormal type, determining that the opposite terminal equipment has a fault.
In an exemplary embodiment of the present disclosure, when there is a failure in the peer device, performing failure processing according to a preset configuration includes: determining the abnormal level and the alarm mode of the opposite terminal equipment; and processing the fault based on the abnormal grade and the alarm mode.
In an exemplary embodiment of the present disclosure, performing fault handling based on the abnormality level and the alarm manner includes: determining a processing policy based on the exception level; and carrying out fault processing based on the processing strategy and the alarm mode.
In an exemplary embodiment of the present disclosure, performing fault processing based on the processing policy and the alarm manner includes: when the opposite terminal equipment has serious errors, restarting the process of the opposite terminal equipment and generating alarm information; and when the opposite terminal equipment is abnormally stopped, calling the opposite terminal equipment process and generating alarm information.
According to an aspect of the present disclosure, there is provided a fault handling apparatus, the apparatus including: the message module is used for sending a communication message to the opposite terminal equipment based on a preset time period; the information module is used for acquiring return information from opposite-end equipment based on the communication message, wherein the return information comprises first return information and/or second return information; the judging module is used for judging whether the opposite terminal equipment has faults or not based on the return information; and the processing module is used for carrying out fault processing according to preset configuration when the opposite terminal equipment has faults.
According to an aspect of the present disclosure, a fault handling system is presented, the system comprising: the local terminal device is used for sending a communication message to the opposite terminal device based on a preset time period; acquiring return information from opposite-end equipment based on the communication message, wherein the return information comprises first return information and/or second return information; judging whether the opposite terminal equipment has a fault or not based on the return information; when the opposite terminal equipment has faults, carrying out fault processing according to preset configuration; the opposite terminal equipment is used for sending a communication message to the local terminal equipment based on a preset time period; acquiring return information from local terminal equipment based on the communication message, wherein the return information comprises first return information and/or second return information; judging whether the local terminal equipment has a fault or not based on the return information; and when the local terminal equipment has faults, carrying out fault processing according to preset configuration.
According to an aspect of the present disclosure, an electronic device is provided, the electronic device including: one or more processors; storage means for storing one or more programs; when executed by one or more processors, cause the one or more processors to implement a method as above.
According to an aspect of the disclosure, a computer-readable medium is proposed, on which a computer program is stored, which program, when being executed by a processor, carries out the method as above.
According to the fault processing method, the fault processing device, the fault processing system, the electronic equipment and the computer readable medium, the communication message is sent to the opposite terminal equipment based on the preset time period; acquiring return information from opposite-end equipment based on the communication message, wherein the return information comprises first return information and/or second return information; judging whether the opposite terminal equipment has a fault or not based on the return information; when the opposite terminal equipment has faults, the faults can be found in time and efficiently in a mode of carrying out fault processing according to preset configuration, and the encountered problems can be further processed efficiently.
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 above and other objects, features and advantages of the present disclosure will become more apparent by describing in detail exemplary embodiments thereof with reference to the attached drawings. The drawings described below are merely some embodiments of the present disclosure, and other drawings may be derived from those drawings by those of ordinary skill in the art without inventive effort.
Fig. 1 is a system diagram illustrating a fault handling method and apparatus according to an exemplary embodiment.
FIG. 2 is a flow diagram illustrating a method of fault handling in accordance with an exemplary embodiment.
Fig. 3 is a flow chart illustrating a method of fault handling according to another exemplary embodiment.
Fig. 4 is a flow chart illustrating a method of fault handling according to another exemplary embodiment.
Fig. 5 is a block diagram illustrating a fault handling apparatus according to an example embodiment.
FIG. 6 is a block diagram illustrating a fault handling system in accordance with another exemplary embodiment.
FIG. 7 is a block diagram illustrating an electronic device in accordance with an example embodiment.
FIG. 8 is a block diagram illustrating a computer-readable medium in accordance with an example embodiment.
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 embodiments 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 same reference numerals denote the same or similar parts in the drawings, and thus, a repetitive description thereof will be omitted.
Furthermore, 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 give a thorough understanding of embodiments of the disclosure. One skilled in the relevant art will recognize, however, that the subject matter of the present disclosure can 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 methods, devices, systems, implementations, or operations have not been shown or described in detail to avoid obscuring aspects of the disclosure.
The block diagrams shown in the figures are functional entities only and do not necessarily correspond to physically separate entities. I.e. 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 means and/or microcontroller means.
The flow charts shown in the drawings are merely illustrative and do not necessarily include all of the contents and operations/steps, nor do they necessarily have to be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the actual execution sequence may be changed according to the actual situation.
It will be understood that, although the terms first, second, third, etc. may be used herein to describe various components, these components should not be limited by these terms. These terms are used to distinguish one element from another. Thus, a first component discussed below may be termed a second component without departing from the teachings of the disclosed concept. As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed items.
It is to be understood by those skilled in the art that the drawings are merely schematic representations of exemplary embodiments, and that the blocks or processes shown in the drawings are not necessarily required to practice the present disclosure and are, therefore, not intended to limit the scope of the present disclosure.
Fig. 1 is a system diagram illustrating a fault handling method and apparatus according to an exemplary embodiment.
As shown in fig. 1, system architecture 10 may include home devices 101, 102, 103, network 104, and peer devices 105, 106. Network 104 is the medium used to provide communication links between home devices 101, 102, 103 and peer devices 105, 106. Network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.
In one embodiment, names of the home devices 101, 102, 103 and the peer devices 105, 106 may be interchanged, the home devices 101, 102, 103 may be referred to as front-end devices, and the peer devices 105, 106 may be referred to as back-end devices; of course, the local devices 101, 102, and 103 may also be referred to as backend devices, and the peer devices 105 and 106 may also be referred to as front-end devices.
The user may use the home devices 101, 102, 103 to interact with the peer devices 105, 106 over the network 104 to receive or send messages, etc. The home devices 101, 102, 103 may have various communication client applications installed thereon, such as a shopping application, a web browser application, a search application, an instant messaging tool, a mailbox client, social platform software, and the like.
The home devices 101, 102, 103 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, and the like.
The peer devices 105, 106 may be servers providing various services, such as a log management platform providing support for shopping websites browsed by users using the home devices 101, 102, 103. The log management platform receives and stores log information such as attacks, viruses, network flow analysis, network behavior audit, NAT and sessions generated by the network equipment, and displays the received logs to users in various forms. More specifically, the log management platform may analyze and perform other processing on the received data such as the product information query request, and feed back the processing result to the home device 101, 102, and 103.
The local terminal device 101 (or 102, 103) may send a communication packet to the peer terminal device 105 (or 106), for example; the local terminal device 101 (or 102, 103) may obtain, for example, return information from the peer terminal device 105 (or 106) based on the communication packet, where the return information includes the first return information and/or the second return information; the local terminal 101 (or 102, 103) may determine whether the peer terminal 105 (or 106) has a failure, for example, based on the return information; the local device 101 (or 102, 103) may perform fault handling according to a preset configuration, for example, when the opposite device 105 (or 106) has a fault.
The opposite end device 105 (or 106) may send a communication packet to the local end device 101 (or 102, 103), for example; the peer device 105 (or 106) may obtain, for example, return information from the local device 101 (or 102, 103) based on the communication packet, where the return information includes the first return information and/or the second return information; the peer device 105 (or 106) may determine whether the local device 101 (or 102, 103) has a failure, for example, based on the return information; the peer device 105 (or 106) may perform fault handling according to a preset configuration, for example, when the local device 101 (or 102, 103) has a fault.
The peer devices 105, 106 may be servers of one entity, and may also be composed of a plurality of servers, for example. It should be noted that the fault handling method provided by the embodiment of the present disclosure may be executed by the local devices 101, 102, and 103 and the peer devices 105 and 106 together, and accordingly, the fault handling apparatus may be disposed in the local devices 101, 102, and 103 and the peer devices 105 and 106.
FIG. 2 is a flow diagram illustrating a method of fault handling in accordance with an exemplary embodiment. The fault handling method 20 comprises at least steps S202 to S208.
As shown in fig. 2, in S202, a communication packet is sent to the peer device.
In one embodiment, the heartbeat message and the log obtaining command may be sent to the peer device based on a preset time period, for example.
In an embodiment, for example, when the local device has a program abnormality, a heartbeat message and a log obtaining command may be sent to the peer device.
In S204, return information from the peer device is obtained based on the communication packet, where the return information includes the first return information and/or the second return information.
In one embodiment, the first return message may be received based on a heartbeat message in the communication message; second return information may also be received based on a log acquisition command in the communication message.
The heartbeat keep-alive is a mode for realizing long-connection keep-alive, and reconnection operation is executed through timeout of a heartbeat packet and other conditions (network switching). The heartbeat generally refers to that a certain end (in most cases, a client) sends a custom instruction to an opposite end at regular intervals to judge whether the two ends survive, and the heartbeat is called a heartbeat instruction because the heartbeat is sent at regular intervals and is similar to the heartbeat.
In S206, it is determined whether the peer device has a failure based on the return information.
In one embodiment, when the first return message is received within a predetermined time interval, it is determined that the peer device has no fault; and when the first return information is not received within a preset time interval, determining that the opposite terminal equipment has a fault.
In one embodiment, the information type of the second return information may be extracted; when the information type is a normal type, determining that no fault exists in the opposite terminal equipment; and when the information type is an abnormal type, determining that the opposite terminal equipment has a fault.
In S208, when the peer device has a fault, the fault is processed according to a preset configuration. For example, determining the abnormal level and the alarm mode of the opposite terminal equipment; and processing the fault based on the abnormal grade and the alarm mode. The front end and the back end mutually check the operation logs and know information such as faults, probably caused reasons, how to process and the like according to the predefined level; if no error code is directly hung, judging whether to alarm or make corresponding action by a heartbeat keep-alive mechanism.
Wherein, the fault processing is carried out based on the abnormal grade and the alarm mode, and comprises the following steps: determining a processing policy based on the exception level; and carrying out fault processing based on the processing strategy and the alarm mode.
Further, the fault processing based on the processing strategy and the alarm mode includes: when the opposite terminal equipment has serious errors, restarting the process of the opposite terminal equipment and generating alarm information; and when the opposite terminal equipment is abnormally stopped, calling the opposite terminal equipment process and generating alarm information.
According to the fault processing method disclosed by the invention, a communication message is sent to opposite-end equipment based on a preset time period; acquiring return information from opposite-end equipment based on the communication message, wherein the return information comprises first return information and/or second return information; judging whether the opposite terminal equipment has a fault or not based on the return information; when the opposite terminal equipment has faults, the faults can be found in time and efficiently in a mode of carrying out fault processing according to preset configuration, and the encountered problems can be further processed efficiently.
It should be clearly understood that this disclosure describes how to make and use particular examples, but the principles of this disclosure are not limited to any details of these examples. Rather, these principles can be applied to many other embodiments based on the teachings of the present disclosure.
Fig. 3 is a flow chart illustrating a method of fault handling according to another exemplary embodiment. The process 30 shown in fig. 3 is a detailed description of the process shown in fig. 2. And sending heartbeat messages between the front-end process and the back-end process through a specified time interval, and checking the running logs of the front-end process and the back-end process. Analyzing keywords for recording error information in the running log, judging the running health condition of the process of the opposite side by predefining error codes, then carrying out different alarming or handling modes according to the severity level, simultaneously obtaining what errors happen to the opposite side at present according to the error reporting error codes of the log, listing the possible reasons according to the configured keywords, and informing an administrator through the configured alarming mode to suggest which operations can be carried out to solve the problem.
As shown in fig. 3, in S302, the preset programs generated based on the method of the present disclosure are respectively run at the front end and the back end.
In S304, the front end and the back end respectively determine whether the alarm function is operated, and when the alarm function is not operated, the subsequent steps are not executed.
In S306, configuration information related to a preset processing rule is acquired. The configuration information is configured through the front end, and the problem levels of different levels correspond to different alarming and handling modes. For example: sound alarm, short message alarm, mail alarm, forced restart + alarm, etc.
In S308, the front end and the back end respectively acquire the log of the other party.
In S310, whether the operation is normal is determined according to the keyword in the log.
In S312, when it is determined that the operation is abnormal, processing is performed according to a predefined configuration. And checking the abnormal type of the opposite side by analyzing the running log, and if the abnormal type is a fatal error or no log is recorded for a period of time, defaulting to be process hang-up, and directly restarting the process of the opposite side. And if the opposite end process exists, the opposite end process is killed and restarted, and if the opposite end process does not exist, the opposite end process is directly called.
In S314, the front end and the back end respectively detect the operating state of the other side based on the heartbeat message.
In S316, it is determined whether the operation is normal according to the communication state. The method comprises the steps that a heartbeat message is sent by two parties, whether an opposite-end process runs normally or not can be detected, the heartbeat message with a normal running state sent by the opposite end can be received in a specified time interval under a normal condition, if the heartbeat message sent by the opposite-end process is not received in the specified time interval, the opposite-end process is considered to be abnormal, whether the opposite-end process exists or not is detected, if the opposite-end process exists, the opposite-end process is killed, the process is restarted, and if the opposite-end process does not exist, the opposite-end process is directly called.
In S318, when it is determined that the operation is abnormal, processing is performed according to a predefined configuration.
In S320, the process ends. The front-end process and the back-end process actively detect the running log of the opposite-end process and mutually send heartbeat messages, so that various serious problems caused by the sudden occurrence of the front-end process and the back-end process can be avoided, the front-end process and the back-end process cannot be recovered in time, and data receiving and service logic processing are influenced. Further improving the reliability of the application.
According to the fault processing method disclosed by the invention, in the software running process, the front end and the back end mutually check the running logs, know what kind of problems occur according to the predefined level, find out the reasons of the possible problems according to the keywords, and inform the administrator of the running state and the reasons causing the problems in a configured alarm mode. The software actively informs an administrator or restarts the abnormal end, so as to avoid the problem that the abnormal problem can not be processed in time and the normal operation of the software is influenced.
Fig. 4 is a flow chart illustrating a method of fault handling according to another exemplary embodiment. The process 40 shown in fig. 4 is a detailed description of the process shown in fig. 2.
As shown in fig. 4, in S402, the local device sends a communication packet to the peer device, and the peer device sends a communication packet to the local device.
In S404, the local device obtains return information from the peer device based on the communication packet, where the return information includes the first return information and/or the second return information. And judging whether the opposite terminal equipment has faults or not based on the return information.
In S406, the peer device obtains return information from the local device based on the communication packet, where the return information includes the first return information and/or the second return information. And judging whether the local terminal equipment has faults or not based on the return information.
In S408, when the opposite device has a fault, the local device performs fault processing according to a preset configuration.
In S410, when the local device has a fault, the opposite device performs fault processing according to a preset configuration.
According to the fault processing method disclosed by the invention, in the software running process, the front end and the back end check the running logs mutually, check whether the predefined abnormal level is met or not in the running logs, and inform an administrator of timely and efficiently processing generated problems in modes of making related processing actions (alarm, mail, short message) and the like according to the predefined level actions.
Those skilled in the art will appreciate that all or part of the steps implementing the above embodiments are implemented as computer programs executed by a CPU. When executed by the CPU, performs the functions defined by the above-described methods provided by the present disclosure. The program may be stored in a computer readable storage medium, which may be a read-only memory, a magnetic or optical disk, or the like.
Furthermore, it should be noted that the above-mentioned figures are only schematic illustrations of the processes involved in the methods according to exemplary embodiments of the present disclosure, 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.
The following are embodiments of the disclosed apparatus that may be used to perform embodiments of the disclosed methods. For details not disclosed in the embodiments of the apparatus of the present disclosure, refer to the embodiments of the method of the present disclosure.
Fig. 5 is a block diagram illustrating a fault handling apparatus according to an example embodiment. As shown in fig. 5, the failure processing apparatus 50 includes: a message module 502, an information module 504, a judgment module 506, and a processing module 508.
The message module 502 is configured to send a communication message to an opposite-end device; the message module 502 is further configured to send a heartbeat message and a log obtaining command to the peer device based on a preset time period; the message module 502 is further configured to send a heartbeat message and a log obtaining command to the peer device when the local device is abnormal in program.
The information module 504 is configured to obtain return information from the peer device based on the communication packet, where the return information includes first return information and/or second return information; the information module 504 is further configured to receive first return information based on the heartbeat message in the communication message; second return information may also be received based on a log acquisition command in the communication message.
The judging module 506 is configured to judge whether the peer device has a fault based on the return information; in one embodiment, when the first return message is received within a predetermined time interval, it is determined that the peer device has no fault; and when the first return information is not received within a preset time interval, determining that the opposite terminal equipment has a fault.
In one embodiment, the information type of the second return information may be extracted; when the information type is a normal type, determining that no fault exists in the opposite terminal equipment; and when the information type is an abnormal type, determining that the opposite terminal equipment has a fault.
The processing module 508 is configured to perform fault processing according to a preset configuration when the peer device has a fault. The processing module 508 is further configured to determine an exception level and an alarm manner of the peer device; and processing the fault based on the abnormal grade and the alarm mode.
FIG. 6 is a block diagram illustrating a fault handling system in accordance with another exemplary embodiment. As shown in fig. 6, the fault handling system 60 includes: a home terminal device 602 and an opposite terminal device 604.
At least one local terminal device 602 is configured to send a communication packet to an opposite terminal device 604; acquiring return information from the opposite-end device 604 based on the communication message, wherein the return information comprises first return information and/or second return information; judging whether the opposite terminal equipment 604 has a fault based on the return information; when the opposite-end device 604 has a fault, performing fault processing according to a preset configuration;
at least one peer device 604 is configured to send a communication packet to the home device 602; acquiring return information from the local terminal device 602 based on the communication packet, where the return information includes first return information and/or second return information; judging whether the local terminal equipment 602 has a fault or not based on the return information; and when the local terminal equipment 602 has a fault, performing fault processing according to a preset configuration.
According to the fault processing device disclosed by the invention, a communication message is sent to opposite-end equipment based on a preset time period; acquiring return information from opposite-end equipment based on the communication message, wherein the return information comprises first return information and/or second return information; judging whether the opposite terminal equipment has a fault or not based on the return information; when the opposite terminal equipment has faults, the faults can be found in time and efficiently in a mode of carrying out fault processing according to preset configuration, and the encountered problems can be further processed efficiently.
FIG. 7 is a block diagram illustrating an electronic device in accordance with an example embodiment.
An electronic device 700 according to this embodiment of the disclosure is described below with reference to fig. 7. The electronic device 700 shown in fig. 7 is only an example and should not bring any limitation to the functions and the scope of use of the embodiments of the present disclosure.
As shown in fig. 7, electronic device 700 is embodied in the form of a general purpose computing device. The components of the electronic device 700 may include, but are not limited to: at least one processing unit 710, at least one memory unit 720, a bus 730 that connects the various system components (including the memory unit 720 and the processing unit 710), a display unit 740, and the like.
Wherein the storage unit stores program code that can be executed by the processing unit 710 to cause the processing unit 710 to perform the steps according to various exemplary embodiments of the present disclosure described in this specification. For example, the processing unit 710 may perform the steps as shown in fig. 2, 3, 4.
The memory unit 720 may include readable media in the form of volatile memory units, such as a random access memory unit (RAM)7201 and/or a cache memory unit 7202, and may further include a read only memory unit (ROM) 7203.
The memory unit 720 may also include a program/utility 7204 having a set (at least one) of program modules 7205, such program modules 7205 including, but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which, or some combination thereof, may comprise an implementation of a network environment.
Bus 730 may be any representation of one or more of several types of bus structures, including a memory unit bus or memory unit controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.
The electronic device 700 may also communicate with one or more external devices 700' (e.g., keyboard, pointing device, bluetooth device, etc.), such that a user can communicate with devices with which the electronic device 700 interacts, and/or any devices (e.g., router, modem, etc.) with which the electronic device 700 can communicate with one or more other computing devices. Such communication may occur via an input/output (I/O) interface 750. Also, the electronic device 700 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) via the network adapter 760. The network adapter 760 may communicate with other modules of the electronic device 700 via the bus 730. It should be appreciated that although not shown in the figures, other hardware and/or software modules may be used in conjunction with the electronic device 700, 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, as shown in fig. 8, the technical solution according to the embodiment of the present disclosure may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (which may be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which may be a personal computer, a server, or a network device, etc.) to execute the above method according to the embodiment of the present disclosure.
The software 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.
The computer readable storage 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 storage 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 storage 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 the present disclosure 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).
The computer readable medium carries one or more programs which, when executed by a device, cause the computer readable medium to perform the functions of: sending a communication message to opposite-end equipment based on a preset time period; acquiring return information from opposite-end equipment based on the communication message, wherein the return information comprises first return information and/or second return information; judging whether the opposite terminal equipment has a fault or not based on the return information; and when the opposite terminal equipment has faults, carrying out fault processing according to preset configuration.
Those skilled in the art will appreciate that the modules described above may be distributed in the apparatus according to the description of the embodiments, or may be modified accordingly in one or more apparatuses unique from the embodiments. The modules of the above embodiments may be combined into one module, or further split into multiple sub-modules.
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 embodiments of the present disclosure may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (which may be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which may be a personal computer, a server, a mobile terminal, or a network device, etc.) to execute the method according to the embodiments of the present disclosure.
Exemplary embodiments of the present disclosure are specifically illustrated and described above. It is to be understood that the present disclosure is not limited to the precise arrangements, instrumentalities, or instrumentalities described herein; on the contrary, the disclosure is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims (10)

1. A method of fault handling, comprising:
sending a communication message to opposite-end equipment;
acquiring return information from opposite-end equipment based on the communication message, wherein the return information comprises first return information and/or second return information;
judging whether the opposite terminal equipment has a fault or not based on the return information;
and when the opposite terminal equipment has faults, carrying out fault processing according to preset configuration.
2. The method of claim 1, wherein sending the communication packet by the peer device comprises:
and sending a heartbeat message and a log acquisition command to the opposite terminal equipment based on a preset time period.
3. The method of claim 1, wherein obtaining the return information from the peer device based on the communication packet comprises:
receiving first return information based on the heartbeat message in the communication message; and/or
And receiving second return information based on the log acquisition command in the communication message.
4. The method of claim 3, wherein determining whether the peer device has a failure based on the return information comprises:
when the first return information is received within a preset time interval, determining that no fault exists in the opposite terminal equipment;
and when the first return information is not received within a preset time interval, determining that the opposite terminal equipment has a fault.
5. The method of claim 3, wherein determining whether the peer device has a failure based on the return information comprises:
extracting the information type of the second return information;
when the information type is a normal type, determining that no fault exists in the opposite terminal equipment;
and when the information type is an abnormal type, determining that the opposite terminal equipment has a fault.
6. The method of claim 1, wherein when the peer device has a failure, performing failure processing according to a preset configuration includes:
determining the abnormal level and the alarm mode of the opposite terminal equipment;
and processing the fault based on the abnormal grade and the alarm mode.
7. The method of claim 6, wherein fault handling based on the anomaly level and the alarm mode comprises:
determining a processing policy based on the exception level;
and carrying out fault processing based on the processing strategy and the alarm mode.
8. The method of claim 7, wherein performing fault handling based on the processing policy and the alarm manner comprises:
when the opposite terminal equipment has serious errors, restarting the process of the opposite terminal equipment and generating alarm information;
and when the opposite terminal equipment is abnormally stopped, calling the opposite terminal equipment process and generating alarm information.
9. A fault handling device, comprising:
the message module is used for sending a communication message to the opposite terminal equipment;
the information module is used for acquiring return information from opposite-end equipment based on the communication message, wherein the return information comprises first return information and/or second return information;
the judging module is used for judging whether the opposite terminal equipment has faults or not based on the return information;
and the processing module is used for carrying out fault processing according to preset configuration when the opposite terminal equipment has faults.
10. A fault handling system, comprising:
at least one local terminal device, configured to send a communication packet to an opposite terminal device; acquiring return information from opposite-end equipment based on the communication message, wherein the return information comprises first return information and/or second return information; judging whether the opposite terminal equipment has a fault or not based on the return information; when the opposite terminal equipment has faults, carrying out fault processing according to preset configuration;
at least one opposite terminal device, which is used for sending communication messages to the local terminal device; acquiring return information from local terminal equipment based on the communication message, wherein the return information comprises first return information and/or second return information; judging whether the local terminal equipment has a fault or not based on the return information; and when the local terminal equipment has faults, carrying out fault processing according to preset configuration.
CN202111147582.2A 2021-09-29 2021-09-29 Fault processing method, device and system Pending CN113890819A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111147582.2A CN113890819A (en) 2021-09-29 2021-09-29 Fault processing method, device and system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111147582.2A CN113890819A (en) 2021-09-29 2021-09-29 Fault processing method, device and system

Publications (1)

Publication Number Publication Date
CN113890819A true CN113890819A (en) 2022-01-04

Family

ID=79007674

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111147582.2A Pending CN113890819A (en) 2021-09-29 2021-09-29 Fault processing method, device and system

Country Status (1)

Country Link
CN (1) CN113890819A (en)

Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102355368A (en) * 2011-10-08 2012-02-15 大连环宇移动科技有限公司 Fault processing method of network equipment and system
CN102546304A (en) * 2012-01-19 2012-07-04 华为技术有限公司 BFD detection method, equipment and system
CN102624584A (en) * 2012-03-01 2012-08-01 中兴通讯股份有限公司 Link detection method and link detection device
JP2014203294A (en) * 2013-04-05 2014-10-27 株式会社日立製作所 Failure handling system and failure handling method
CN106452811A (en) * 2015-08-07 2017-02-22 北京网御星云信息技术有限公司 Fault inspection method and system
CN109361542A (en) * 2018-10-29 2019-02-19 北京奇艺世纪科技有限公司 The fault handling method of client, device, system, terminal and server
CN109495322A (en) * 2018-12-25 2019-03-19 华为技术有限公司 Network failure locating method, relevant device and computer storage medium
CN110971459A (en) * 2019-11-29 2020-04-07 新华三半导体技术有限公司 Session fault detection method and device, terminal equipment and readable storage medium
CN111211916A (en) * 2019-11-29 2020-05-29 中国电信股份有限公司云南分公司 Method for automatically identifying alarm of terminal management platform
CN111371584A (en) * 2018-12-26 2020-07-03 中兴通讯股份有限公司 Equipment fault processing method, management equipment and home gateway equipment
CN111954240A (en) * 2020-07-06 2020-11-17 北京奇保信安科技有限公司 Network fault processing method and device and electronic equipment
CN112286090A (en) * 2020-10-09 2021-01-29 姜茂清 Front-end electronic equipment fault detection and intelligent maintenance application management system

Patent Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102355368A (en) * 2011-10-08 2012-02-15 大连环宇移动科技有限公司 Fault processing method of network equipment and system
CN102546304A (en) * 2012-01-19 2012-07-04 华为技术有限公司 BFD detection method, equipment and system
CN102624584A (en) * 2012-03-01 2012-08-01 中兴通讯股份有限公司 Link detection method and link detection device
JP2014203294A (en) * 2013-04-05 2014-10-27 株式会社日立製作所 Failure handling system and failure handling method
CN106452811A (en) * 2015-08-07 2017-02-22 北京网御星云信息技术有限公司 Fault inspection method and system
CN109361542A (en) * 2018-10-29 2019-02-19 北京奇艺世纪科技有限公司 The fault handling method of client, device, system, terminal and server
CN109495322A (en) * 2018-12-25 2019-03-19 华为技术有限公司 Network failure locating method, relevant device and computer storage medium
CN111371584A (en) * 2018-12-26 2020-07-03 中兴通讯股份有限公司 Equipment fault processing method, management equipment and home gateway equipment
CN110971459A (en) * 2019-11-29 2020-04-07 新华三半导体技术有限公司 Session fault detection method and device, terminal equipment and readable storage medium
CN111211916A (en) * 2019-11-29 2020-05-29 中国电信股份有限公司云南分公司 Method for automatically identifying alarm of terminal management platform
CN111954240A (en) * 2020-07-06 2020-11-17 北京奇保信安科技有限公司 Network fault processing method and device and electronic equipment
CN112286090A (en) * 2020-10-09 2021-01-29 姜茂清 Front-end electronic equipment fault detection and intelligent maintenance application management system

Similar Documents

Publication Publication Date Title
US11789760B2 (en) Alerting, diagnosing, and transmitting computer issues to a technical resource in response to an indication of occurrence by an end user
CN111488572B (en) User behavior analysis log generation method and device, electronic equipment and medium
US20160224400A1 (en) Automatic root cause analysis for distributed business transaction
US11610136B2 (en) Predicting the disaster recovery invocation response time
WO2008083890A1 (en) Method, system and program product for alerting an information technology support organization of a security event
CN113495820B (en) Anomaly information collecting and processing method and device and anomaly monitoring system
CN110324209B (en) Micro-service system monitoring method and device, electronic equipment and computer readable medium
US8332690B1 (en) Method and apparatus for managing failures in a datacenter
US10599505B1 (en) Event handling system with escalation suppression
CN113342619A (en) Log monitoring method and system, electronic device and readable medium
CN111954240A (en) Network fault processing method and device and electronic equipment
CN110896362B (en) Fault detection method and device
JP2011113122A (en) Failure influence analysis device, application system, and failure influence analysis method
US7478095B2 (en) Generation and retrieval of incident reports
CN113138898B (en) Method and device for identifying and early warning business system abnormity and electronic equipment
CN110765090A (en) Log data management method and device, storage medium and electronic equipment
CN112910742A (en) Link state detection method and device
CN113890819A (en) Fault processing method, device and system
US7558770B2 (en) Method and system to detect application non-conformance
CN112260903B (en) Link monitoring method and device
CN114449040A (en) Configuration issuing method and device based on cloud platform
CN111290870B (en) Method and device for detecting abnormality
CN112799957A (en) User behavior based fault handling method, system, device and medium
US20150222505A1 (en) Business transaction resource usage tracking
CN110825599A (en) Information management system monitoring method, device, medium, electronic equipment and system

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication

Application publication date: 20220104