A method and system for processing abnormal service stop

Abstract

The present invention discloses a method and system for processing abnormal service stop, the method comprising: monitoring equipment regularly monitors and collects server index information through a monitoring program; judging whether index information collection abnormality occurs according to preset rules; sending an alarm message to an alarm platform in the case of abnormal index information collection; the alarm platform determines whether the server is started; if the server is in the startup state and the service is inaccessible, calling a command matching the server type to restart the server service; in the case of service restart failure, determining the cumulative restart times; in the case of the cumulative restart times not reaching the preset times, adding the server restart task to the queue, and restarting the service again after an interval of a first preset time length until the service restart is successful or the cumulative restart times reach the preset times. The present application provides the solution, which can restore the server service in time and ensure the normal collection of service indicators.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method and system for processing abnormal service suspension. Background Art

[0002] A server is a type of computer that runs faster, has a higher load, and is more expensive than an ordinary computer. A server provides computing or application services to other clients in the network, such as PCs, smart phones, and other terminals. Server management software (SMS) can control the operation of the server, manage and upgrade software at different levels such as hardware, operating system, and application software, and manage system resources, performance maintenance, and monitoring configuration. Currently, the server status can be obtained in the computer room through the server management software, and the faulty server can be located.

[0003] In the actual application process, windows_exporter and linux_exporter terminated abnormally due to performance problems on the server, resulting in the inability to collect server indicators normally. When problems occurred in subsequent services, the cause of the problem could not be located due to lack of data support. Summary of the invention

[0004] The embodiments of the present application provide a method and system for processing abnormal service suspension to solve the problem in the prior art that server indicators cannot be collected in a timely manner.

[0005] In order to solve the above problem, an embodiment of the present application provides a method for processing abnormal service stop, which is applied to a system including an alarm platform and a monitoring device, wherein the method includes:

[0006] The monitoring device regularly monitors and collects server indicator information through a monitoring program;

[0007] Determine whether an abnormality in indicator information collection occurs according to preset rules;

[0008] When an abnormality occurs in the collection of the indicator information, an alarm message is sent to the alarm platform;

[0009] The alarm platform determines whether the server is started;

[0010] If the server is in the startup state and the service is inaccessible, calling a command matching the server type to restart the service of the server;

[0011] In case of a service restart failure, determine the cumulative restart count;

[0012] When the cumulative restart times do not reach the preset times, the server restart task is added to the queue, and the service is restarted again after a first preset time interval until the service restart is successful or the cumulative restart times reach the preset times.

[0013] Optionally, the step of the monitoring device periodically monitoring and collecting server indicator information through a monitoring program includes:

[0014] The monitoring device periodically monitors and collects indicator information provided by windows_exporter or linux_exporter through Prometheus.

[0015] Optionally, if the server is in a startup state and the service is inaccessible, the step of calling a command matching the server type to restart the service of the server includes:

[0016] If the server is in a startup state and the service is inaccessible, determining the time interval from the last time the server service was inaccessible;

[0017] Determining whether the time interval is greater than a second preset time length;

[0018] If it is longer than the second preset time, an email notification service exception is sent and a command matching the server type is called to restart the service of the server;

[0019] If it is less than or equal to the second preset duration, a manual process is initiated to handle the inaccessibility of the service, and a command matching the server type is called to restart the service of the server.

[0020] Optionally, the step of determining whether an indicator information collection anomaly occurs according to a preset rule includes:

[0021] Get server indicator information at a preset frequency;

[0022] When the server indicator information acquired within the third preset time period all indicates that the server health status is abnormal, it is determined that an indicator information collection abnormality occurs.

[0023] Optionally, after the step of the alarm platform determining whether the server is started, the method further comprises:

[0024] If the server is in a downtime state, determining the IP address of the server;

[0025] Determining contact information based on the IP address;

[0026] Notifying the contact that the server is down;

[0027] In case the contact is not successfully contacted, the alternative contact is notified that the server is down.

[0028] Optionally, before the step of the alarm platform determining whether the server is started, the method further includes:

[0029] Determine whether the manual processing of this server abnormal alarm event has timed out;

[0030] If it has timed out, determine whether to ignore this server abnormality alarm reminder;

[0031] If not, notify the superior person in charge that the server is down;

[0032] In case of failure to successfully contact the superior person in charge, the alternate person in charge is notified that the server has crashed.

[0033] The embodiment of the present application also provides a system for processing abnormal service stop, wherein the system includes an alarm platform and a monitoring device;

[0034] The monitoring device comprises:

[0035] The monitoring module is used to monitor and collect server indicator information regularly through the monitoring program;

[0036] A judgment module is used to judge whether an abnormality in the collection of indicator information occurs according to preset rules;

[0037] A sending module, used for sending an alarm message to the alarm platform when an abnormality occurs in the collection of the indicator information;

[0038] The alarm platform includes:

[0039] A first determination module, used to determine whether the server is started;

[0040] A calling module, configured to call a command matching the server type to restart the service of the server if the server is in a startup state and the service is inaccessible;

[0041] A second determination module is used to determine the cumulative restart times when the service restart fails;

[0042] The exception handling module is used to add the server restart task to the queue when the cumulative restart times do not reach the preset times, and restart the service again after a first preset time interval until the service restart is successful or the cumulative restart times reach the preset times.

[0043] Optionally, the monitoring module is specifically used for:

[0044] Use Prometheus to regularly monitor and collect indicator information provided by windows_exporter or linux_exporter.

[0045] Optionally, the calling module includes:

[0046] A time interval determination submodule, for determining, if the server is in a startup state and the service is inaccessible, a time interval from the last time the server service was inaccessible;

[0047] A duration comparison submodule, used to determine whether the time interval is greater than a second preset duration;

[0048] An email notification submodule, for, if the time duration is greater than a second preset time duration, notifying the service of an abnormality via email and invoking a command matching the server type to restart the service of the server;

[0049] The manual notification submodule is used to notify the human to handle the service inaccessibility problem if the time is less than or equal to the second preset time, and call the command matching the server type to restart the service of the server.

[0050] Optionally, the judging module is specifically used for:

[0051] Get server indicator information at a preset frequency;

[0052] When the server indicator information acquired within the third preset time period all indicates that the server health status is abnormal, it is determined that an indicator information collection abnormality occurs.

[0053] Compared with the prior art, the technical effects that can be achieved by the embodiments of the present application include:

[0054] The solution for handling abnormal service stop provided by the embodiment of the present application is that the monitoring device regularly monitors and collects server indicator information through the monitoring program; determines whether an abnormality in indicator information collection occurs according to preset rules; in the case of an abnormality in indicator information collection, sends an alarm message to the alarm platform; the alarm platform determines whether the server is started; if the server is in the startup state and the service is inaccessible, calls a command matching the server type to restart the server service; in the case of service restart failure, determines the cumulative number of restarts; in the case that the cumulative number of restarts does not reach the preset number, adds the server restart task to the queue, and restarts the service again after an interval of the first preset time until the service restart is successful or the cumulative number of restarts reaches the preset number. The solution for handling abnormal service stop provided by the embodiment of the present application is that when an exporter terminates abnormally, the server service can be restored in time through the automatic recovery strategy of the alarm platform to ensure the normal collection of service indicators. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] Figure 1 is a flowchart showing the steps of a method for handling abnormal service stop according to an embodiment of the present application;

[0056] Figure 2 It is a system structure block diagram showing an embodiment of the present application for processing abnormal service suspension. DETAILED DESCRIPTION

[0057] In order to make the technical problems, technical solutions and advantages to be solved by the present invention more clear, a detailed description will be given below with reference to the accompanying drawings and specific embodiments.

[0058] The following, in conjunction with the accompanying drawings, describes in detail the solution for handling abnormal service suspension provided by the embodiment of the present application through specific embodiments and their application scenarios.

[0059] As attached Figure 1 As shown, the method for processing abnormal service stop in the embodiment of the present application includes the following steps:

[0060] Step 101: The monitoring device regularly monitors and collects server indicator information through a monitoring program.

[0061] The method for processing abnormal service suspension provided in the embodiment of the present application can be applied to a system including an alarm platform and a monitoring device.

[0062] An optional way for the monitoring device to periodically monitor and collect the server indicator information through the monitoring program may be: the monitoring device periodically monitors and collects the indicator information provided by windows_exporter or linux_exporter through Prometheus.

[0063] Prometheus is an open source service monitoring system and time series database, which provides a common data model and a quick data collection, storage and query interface. Each monitored host can provide an interface for outputting monitoring data through a dedicated exporter program. Collecting the indicator information provided by windows_exporter means collecting the indicator information from the interface for outputting monitoring data provided by the exporter program dedicated to the windows system server; collecting the indicator information provided by linux_exporter means collecting the indicator information from the interface for outputting monitoring data provided by the exporter program dedicated to the linux system server.

[0064] The time interval between two adjacent monitorings can be flexibly set by those skilled in the art, and is not specifically limited in the embodiments of the present application.

[0065] Server metrics include but are not limited to: requests per second (QPS), transactions per second (TPS), average response time (RT), load (Load), page views (PV), unique visitors (UV) and bandwidth, etc.

[0066] Step 102: Determine whether an indicator information collection anomaly occurs according to preset rules.

[0067] An optional method of determining whether an indicator information collection anomaly occurs according to a preset rule may be:

[0068] The server indicator information is obtained at a preset frequency; when the server indicator information obtained within a third preset time period all indicates that the server health status is abnormal, it is determined that an indicator information collection abnormality has occurred.

[0069] The health status information can be obtained through the health check interface, wherein the specific values ​​of the preset frequency and the third preset duration can be flexibly set by those skilled in the art, and are not specifically limited in the embodiments of the present application. For example, the preset frequency is set to 30 seconds, 40 seconds or 25 seconds, and the third preset duration can be set to 3 minutes, 2 minutes or 5 minutes, etc.

[0070] If part of the server indicator information obtained within the third preset time period indicates that the server monitoring status is normal, it is determined that no indicator information collection abnormality has occurred, and the server monitoring status monitoring continues.

[0071] Step 103: When an abnormality occurs in the indicator information collection, an alarm message is sent to the alarm platform.

[0072] Among them, the alarm platform is not a service of the machine (such as a server) itself. It is used to match whether to trigger an alarm. If an alarm is triggered, the process on the machine is restarted through remote instructions. The process is used to collect indicator information. The process is an external service and can be started by powering on or by remote instructions. It does not belong to the machine itself. The alarm platform obtains the command for restoring the service through predefined rules, and triggers the restart of the service of the abnormal server to ensure the normal collection of monitoring indicators. The specific operation process is as follows.

[0073] Step 104: The alarm platform determines whether the server is started.

[0074] In the specific implementation process, the Ping solution can be used to determine whether the server is started. If the server is in the started state and the service is inaccessible (ie, the server is not down and the service is inaccessible), step 105 is executed. Otherwise, the process shown in the following preferred embodiment is executed.

[0075] In a preferred embodiment, after the alarm platform determines whether the server is started, if the server is in a downtime state, the IP address of the server is determined; the contact information is determined based on the IP address; the contact is notified that the server is down; and if the contact is not successfully contacted, the alternative contact is notified that the server is down.

[0076] If the contact does not answer the call, it can be regarded as a failure to contact the contact. The alternative contact is a pre-set backup contact. This preferred embodiment can promptly notify the contact to perform server maintenance when a server downtime is detected, which can shorten the server downtime and enable the service indicated by the server to be restored as soon as possible.

[0077] In an optional embodiment, before the alarm platform determines whether the server is started, it can also determine whether it is manually processed; if not, execute step 104 and subsequent steps; if so, determine whether the manual processing of this server abnormality alarm event has timed out, and if not, end this process. If it has timed out, determine whether to ignore this server abnormality alarm reminder. If ignored, the process ends. If not ignored, the reminder is allowed, and the superior person in charge is notified that the server has been down. If the superior person in charge answers this reminder, the process ends. If the superior person in charge does not answer (that is, if the superior person in charge is not successfully contacted), the alternate person in charge is notified that the server has been down and the process ends.

[0078] Step 105: If the server is in the startup state and the service is inaccessible, call a command matching the server type to restart the server service.

[0079] Server types may include: Windows and Linux. Different types of servers have different corresponding commands for restarting server services. Windows restarts services through WinRM commands, and Linux restarts services through SHH instructions.

[0080] A method of optionally calling a command matching the server type to restart the service of the server may include the following sub-steps:

[0081] Sub-step 1: If the server is in the startup state and the service is inaccessible, determine the time interval since the last time the server service was inaccessible;

[0082] Sub-step 2: Determine whether the time interval is greater than a second preset time length;

[0083] The specific value of the second preset time length can be flexibly set by those skilled in the art, and is not specifically limited in the embodiments of the present application. For example, the second preset time length is set to 1 hour, 50 minutes, or 1.5 hours.

[0084] Sub-step 3: If the time is longer than the second preset time, an email notification service exception is sent and a command matching the server type is called to restart the server service;

[0085] Sub-step 4: If it is less than or equal to the second preset time, notify the human to handle the service inaccessibility problem, and call the command matching the server type to restart the server service.

[0086] If the service is unavailable too many times in a short period of time, it means that there is a hidden danger in the server or service, so manual confirmation is required to execute sub-step 4. It should be noted that while executing sub-step 4, an automatic recovery strategy for the service is also required.

[0087] Step 106: In case the service restart fails, determine the cumulative restart times.

[0088] If the service restart fails, the cumulative restart count will be increased by 1. If the service restart is successful, the relevant stakeholders can be notified by email that the automatic restart of the service is successful, and the process of handling abnormal service suspension is completed.

[0089] Step 107: When the cumulative restart times do not reach the preset times, the server restart task is added to the queue, and the service is restarted again after a first preset time interval until the service restart is successful or the cumulative restart times reach the preset times.

[0090] The specific values ​​of the preset number of times and the first preset duration can be flexibly set by technical personnel in this field, and there is no specific restriction on this in the embodiment of the present application. For example: the preset number of times is set to 5, 4 or 6, and the first preset duration is set to 1 minute, 1.5 minutes or 70 seconds, etc.

[0091] If the cumulative restart times reach the preset number and the service still fails to start successfully, a manual process will be notified.

[0092] The method for handling abnormal service stop provided by the embodiment of the present application is that the monitoring device regularly monitors and collects server indicator information through the monitoring program; determines whether an abnormality in indicator information collection occurs according to preset rules; in the case of an abnormality in indicator information collection, sends an alarm message to the alarm platform; the alarm platform determines whether the server is started; if the server is in the startup state and the service is inaccessible, calls a command matching the server type to restart the server service; in the case of service restart failure, determines the cumulative number of restarts; in the case that the cumulative number of restarts does not reach the preset number, adds the server restart task to the queue, and restarts the service again after an interval of the first preset time until the service restart is successful or the cumulative number of restarts reaches the preset number. The method for handling abnormal service stop provided by the embodiment of the present application is that when an exporter terminates abnormally, the server service can be restored in time through the automatic recovery strategy of the alarm platform to ensure the normal collection of service indicators.

[0093] Figure 2 A structural block diagram of a system for processing abnormal service suspension in order to implement an embodiment of the present application.

[0094] The system for processing abnormal service stop provided in the embodiment of the present application includes: an alarm platform 201 and a monitoring device 202;

[0095] The monitoring device 202 includes:

[0096] Monitoring module 2021, used to monitor and collect server indicator information regularly through a monitoring program;

[0097] A judgment module 2022 is used to judge whether an abnormality in the collection of indicator information occurs according to a preset rule;

[0098] A sending module 2023 is used to send an alarm message to an alarm platform when an abnormality occurs in the indicator information collection;

[0099] The alarm platform 201 includes:

[0100] The first determination module 2011 is used to determine whether the server is started;

[0101] A calling module 2012 is used to call a command matching the server type to restart the service of the server if the server is in a startup state and the service is inaccessible;

[0102] The second determination module 2013 is used to determine the cumulative restart times when the service restart fails;

[0103] The exception handling module 2014 is used to add the server restart task to the queue if the cumulative restart times do not reach the preset times, and restart the service again after a first preset time interval until the service restart is successful or the cumulative restart times reach the preset times.

[0104] Optionally, the monitoring module is specifically used for:

[0105] Use Prometheus to regularly monitor and collect indicator information provided by windows_exporter or linux_exporter.

[0106] Optionally, the calling module includes:

[0107] A time interval determination submodule, for determining, if the server is in a startup state and the service is inaccessible, a time interval from the last time the server service was inaccessible;

[0108] A duration comparison submodule, used to determine whether the time interval is greater than a second preset duration;

[0109] An email notification submodule, for, if the time duration is greater than a second preset time duration, notifying the service of an abnormality via email and invoking a command matching the server type to restart the service of the server;

[0110] The manual notification submodule is used to notify the human to handle the service inaccessibility problem if the time is less than or equal to the second preset time, and call the command matching the server type to restart the service of the server.

[0111] Optionally, the judging module is specifically used for:

[0112] Get server indicator information at a preset frequency;

[0113] When the server indicator information acquired within the third preset time period all indicates that the server health status is abnormal, it is determined that an indicator information collection abnormality occurs.

[0114] Optionally, the alarm platform further includes:

[0115] An address determination submodule, for determining the IP address of the server if the server is in a downtime state after the alarm platform determines whether the server is started;

[0116] A contact determination submodule, used to determine contact information based on the IP address;

[0117] A notification submodule, used to notify the contact that the server has crashed;

[0118] The alternative contact notification submodule is used to notify the alternative contact that the server has crashed when the contact is not successfully contacted.

[0119] Optionally, the alarm platform further includes:

[0120] A timeout judgment submodule is used to judge whether the manual processing of the server abnormality alarm event has timed out before the alarm platform determines whether the server is started;

[0121] The timeout processing submodule is used to determine whether to ignore the server abnormality alarm reminder if the timeout has occurred; if not, to notify the superior person in charge that the server has crashed; if the superior person in charge cannot be successfully contacted, to notify the alternative person in charge that the server has crashed.

[0122] The embodiments of the present application provide Figure 2 The system for handling abnormal service stop shown can achieve Figure 1 To avoid repetition, the various processes implemented by the method embodiment are not described here.

[0123] The system for handling abnormal service stop provided by the embodiment of the present application is that the monitoring device regularly monitors and collects server indicator information through the monitoring program; determines whether an abnormality in indicator information collection occurs according to preset rules; in the case of an abnormality in indicator information collection, sends an alarm message to the alarm platform; the alarm platform determines whether the server is started; if the server is in the startup state and the service is inaccessible, calls a command matching the server type to restart the server service; in the case of service restart failure, determines the cumulative number of restarts; in the case that the cumulative number of restarts does not reach the preset number, adds the server restart task to the queue, and restarts the service again after an interval of the first preset time until the service restart is successful or the cumulative number of restarts reaches the preset number. The solution for handling abnormal service stop provided by the embodiment of the present application is that when an exporter terminates abnormally, the server service can be restored in time through the automatic recovery strategy of the alarm platform to ensure the normal collection of service indicators.

[0124] An embodiment of the present invention further provides an electronic device, including a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus.

[0125] Memory, used to store computer programs;

[0126] The processor is used to implement the method steps performed by the health device or the alarm platform in the above method embodiment when executing the program stored in the memory.

[0127] The communication bus mentioned in the above terminal can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus.

[0128] The communication interface is used for communication between the above terminal and other devices.

[0129] The memory may include a random access memory (RAM) or a non-volatile memory, such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the aforementioned processor.

[0130] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0131] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0132] The above is a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A method for handling abnormal service stop, applied to a system including an alarm platform and a monitoring device, characterized in that: The method comprises: The monitoring device regularly monitors and collects server indicator information through a monitoring program; Determine whether an abnormality in indicator information collection occurs according to preset rules; When an abnormality occurs in the collection of the indicator information, an alarm message is sent to the alarm platform; The alarm platform determines whether the server is started; If the server is in the startup state and the service is inaccessible, calling a command matching the server type to restart the service of the server; In case of a service restart failure, determine the cumulative restart count; When the cumulative restart times do not reach the preset times, the server restart task is added to the queue, and the service is restarted again after a first preset time interval until the service restart is successful or the cumulative restart times reach the preset times.

2. The method according to claim 1, characterized in that The step of the monitoring device regularly monitoring and collecting server indicator information through a monitoring program includes: The monitoring device periodically monitors and collects indicator information provided by windows_exporter or linux_exporter through Prometheus.

3. The method according to claim 1, characterized in that: If the server is in a startup state and the service is inaccessible, the step of calling a command matching the server type to restart the service of the server comprises: If the server is in a startup state and the service is inaccessible, determining the time interval from the last time the server service was inaccessible; Determining whether the time interval is greater than a second preset time length; If it is longer than the second preset time, an email notification service exception is sent and a command matching the server type is called to restart the service of the server; If it is less than or equal to the second preset time length, notify manual processing of the service inaccessibility problem, and call a command matching the server type to restart the service of the server.

4. The method according to claim 1, characterized in that The steps of determining whether an abnormality in indicator information collection occurs according to preset rules include: Get server indicator information at a preset frequency; When the server indicator information acquired within the third preset time period all indicates that the server health status is abnormal, it is determined that an indicator information collection abnormality occurs.

5. The method according to claim 1, characterized in that After the step of the alarm platform determining whether the server is started, the method further includes: If the server is in a downtime state, determining the IP address of the server; Determining contact information based on the IP address; Notifying the contact that the server is down; In case the contact is not successfully contacted, the alternative contact is notified that the server is down.

6. The method according to claim 1, characterized in that Before the step of the alarm platform determining whether the server is started, the method further includes: Determine whether the manual processing of this server abnormal alarm event has timed out; If it has timed out, determine whether to ignore this server abnormality alarm reminder; If not, notify the superior person in charge that the server is down; In case of failure to successfully contact the superior person in charge, the alternate person in charge is notified that the server has crashed.

7. A system for processing abnormal service stop, characterized in that: The system includes an alarm platform and monitoring equipment; The monitoring device comprises: The monitoring module is used to monitor and collect server indicator information regularly through the monitoring program; A judgment module is used to judge whether an abnormality in the collection of indicator information occurs according to preset rules; A sending module, used for sending an alarm message to the alarm platform when an abnormality occurs in the collection of the indicator information; The alarm platform includes: A first determination module, used to determine whether the server is started; A calling module, configured to call a command matching the server type to restart the service of the server if the server is in a startup state and the service is inaccessible; A second determination module is used to determine the cumulative restart times when the service restart fails; The exception handling module is used to add the server restart task to the queue when the cumulative restart times do not reach the preset times, and restart the service again after a first preset time interval until the service restart is successful or the cumulative restart times reach the preset times.

8. The system according to claim 7, characterized in that The monitoring module is specifically used for: Use Prometheus to regularly monitor and collect indicator information provided by windows_exporter or linux_exporter.

9. The system according to claim 7, characterized in that The calling module includes: A time interval determination submodule, for determining, if the server is in a startup state and the service is inaccessible, a time interval from the last time the server service was inaccessible; A duration comparison submodule, used to determine whether the time interval is greater than a second preset duration; An email notification submodule, for, if the time duration is greater than a second preset time duration, notifying the service of an abnormality via email and invoking a command matching the server type to restart the service of the server; The manual notification submodule is used to notify the human to handle the service inaccessibility problem if the time is less than or equal to the second preset time, and call the command matching the server type to restart the service of the server.

10. The system according to claim 7, characterized in that The judgment module is specifically used for: Get server indicator information at a preset frequency; When the server indicator information acquired within the third preset time period all indicates that the server health status is abnormal, it is determined that an indicator information collection abnormality occurs.

Images