CN110515820B - 一种服务器故障维护方法、装置、服务器及存储介质 - Google Patents

Abstract

本申请公开了一种服务器故障维护方法，包括当获取到故障检测指令时，根据所述故障检测指令对当前服务进程进行状态检测，获得所述当前服务进程的执行状态；判断所述当前服务进程的执行状态是否处于正常状态；若否，则启动日志收集进程，并利用所述日志进程收集日志信息；判断所述日志信息中是否存在所述当前服务进程对应的core文件；若是，则关闭所述当前服务进程，并重启服务器；该服务器故障维护方法可以对服务进程崩溃或服务请求卡死等服务器故障进行有效处理，避免客户业务中断，提高了用户体验。本申请还公开了一种服务器故障维护装置、服务器及计算机可读存储介质，均具有上述有益效果。

Description

一种服务器故障维护方法、装置、服务器及存储介质

技术领域

本申请涉及服务器技术领域，特别涉及一种服务器故障维护方法，还涉及一种服务器故障维护装置、服务器以及计算机可读存储介质。

背景技术

服务器是用于提供计算服务的设备，具备承担服务并且保障服务的能力，可提供高可靠的服务，具有较高的服务性能。

在服务器中开启服务进程，对各类服务请求进行处理的过程中，一旦出现服务请求卡死或服务进程崩溃的情况，将会产生core文件(由应用程序接收到***信号后因为崩溃而产生的文件，其中记录了程序崩溃的原因、调用堆栈和崩溃时内存及变量值等信息)。然而，由于core文件中信息量较大，产生的时间较长，一般在半小时以上，在此过程中，服务器将无法提供正常的服务，即无法正常的处理客户的业务请求，使得客户业务无法进行，严重影响客户业务，降低了客户体验。

因此，如何对服务进程崩溃或服务请求卡死等服务器故障进行有效处理，避免客户业务中断，以提高用户体验是本领域技术人员亟待解决的问题。

发明内容

本申请的目的是提供一种日服务器故障维护方法，该服务器故障维护方法可以对服务进程崩溃或服务请求卡死等服务器故障进行有效处理，避免客户业务中断，提高了用户体验；本申请的另一目的是提供一种服务器故障维护装置、服务器以及计算机可读存储介质，也具有上述有益效果。

为解决上述技术问题，本申请提供了一种服务器故障维护方法，所述服务器故障维护方法包括：

当获取到故障检测指令时，根据所述故障检测指令对当前服务进程进行状态检测，获得所述当前服务进程的执行状态；

判断所述当前服务进程的执行状态是否处于正常状态；

若否，则启动日志收集进程，并利用所述日志进程收集日志信息；

判断所述日志信息中是否存在所述当前服务进程对应的core文件；

若是，则关闭所述当前服务进程，并重启服务器。

优选的，获取所述故障检测指令，包括：

按照预设时间间隔响应所述故障检测指令。

优选的，所述根据所述故障检测指令对当前服务进程进行状态检测，包括：

根据showmount-e命令对所述当前服务进程进行状态检测。

优选的，所述根据所述故障检测指令对当前服务进程进行状态检测，获得所述当前服务进程的执行状态，包括：

根据所述故障检测指令采集所述当前服务进程中服务请求数量和服务请求处理数量的变化状态；

根据所述变化状态确定所述当前服务进程的执行状态。

优选的，所述利用所述日志进程收集日志信息之前，还包括：

按照预设规则调节所述日志收集进程的日志级别。

优选的，所述利用所述日志进程收集日志信息之后，还包括：

获取所述当前服务进程的当前执行状态；

判断所述当前执行状态是否处于所述正常状态；

若是，则执行所述判断所述日志信息中是否存在所述当前服务进程对应的core文件的步骤。

优选的，所述服务器故障维护方法还包括：

当所述日志信息中不存在所述core文件时，重启服务器。

为解决上述技术问题，本申请还提供了一种服务器故障维护装置，所述服务器故障维护装置包括：

状态检测模块，用于当获取到故障检测指令时，根据所述故障检测指令对当前服务进程进行状态检测，获得所述当前服务进程的执行状态；

状态判定模块，用于判断所述当前服务进程的执行状态是否处于正常状态；

日志收集模块，用于当所述当前服务进程的执行状态不处于所述正常状态时，启动日志收集进程，并利用所述日志进程收集日志信息；

文件判断模块，用于判断所述日志信息中是否存在所述当前服务进程对应的core文件；

进程关闭模块，用于当所述日志信息中存在所述core文件时，关闭所述当前服务进程，并重启服务器。

为解决上述技术问题，本申请还提供了一种服务器，所述服务器包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现上述任意一种服务器故障维护方法的步骤。

为解决上述技术问题，本申请还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意一种服务器故障维护方法的步骤。

本申请所提供的一种服务器故障维护方法，包括当获取到故障检测指令时，根据所述故障检测指令对当前服务进程进行状态检测，获得所述当前服务进程的执行状态；判断所述当前服务进程的执行状态是否处于正常状态；若否，则启动日志收集进程，并利用所述日志进程收集日志信息；判断所述日志信息中是否存在所述当前服务进程对应的core文件；若是，则关闭所述当前服务进程，并重启服务器。

可见，本申请所提供的服务器故障维护方法，在服务器运行过程中，对服务器中的当前服务进程进行有效检测，当发现当前服务进程处于异常状态时，立即启动日志收集进程以获取该服务进程对应的日志信息，进而通过判断日志信息中是否有core文件生成以确定服务器是否处于卡死或崩溃状态，进一步，一旦发现有core文件生成，则立即杀死当前服务进程，并重启服务器，有效避免了由于core文件生成时间过长导致的客户业务中断的情况，进而保障了用户体验。

本申请所提供的一种服务器故障维护装置、服务器以及计算机可读存储介质，均具有上述有益效果，在此不再赘述。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请所提供的一种服务器故障维护方法的流程示意图；

图2为本申请所提供的另一种服务器故障维护方法的流程示意图；

图3为本申请所提供的又一种服务器故障维护方法的流程示意图；

图4为本申请所提供的一种服务器故障维护装置的结构示意图；

图5为本申请所提供的一种服务器的结构示意图。

具体实施方式

本申请的核心是提供一种服务器故障维护方法，该服务器故障维护方法可以对服务进程崩溃或服务请求卡死等服务器故障进行有效处理，避免客户业务中断，提高了用户体验；本申请的另一核心是提供一种服务器故障维护装置、服务器以及计算机可读存储介质，也具有上述有益效果。

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

目前，在基于服务器的业务处理流程中，由于服务请求卡死无法自动恢复，服务进程崩溃后产生core文件所占用的时间过长，在此过程中，服务器将无法提供正常的服务，即无法正常的处理客户的业务请求，使得客户业务无法进行，严重影响客户业务，降低了客户体验。

因此，为解决上述问题，本申请提供了一种服务器故障维护方法，该服务器故障维护方法在服务器运行过程中，对服务器中的当前服务进程进行有效检测，当发现当前服务进程处于异常状态时，立即启动日志收集进程以获取该服务进程对应的日志信息，进而通过判断日志信息中是否有core文件生成以确定服务器是否处于卡死或崩溃状态，进一步，一旦发现有core文件生成，则立即杀死当前服务进程，并重启服务器，有效避免了由于core文件生成时间过长导致的客户业务中断的情况，进而保障了用户体验。

请参考图1，图1为本申请所提供的一种服务器故障维护方法的流程示意图，该服务器故障维护方法可以包括：

S101：当获取到故障检测指令时，根据故障检测指令对当前服务进程进行状态检测，获得当前服务进程的执行状态；

本步骤旨在实现服务进程检测，以获得服务器中当前服务进程的执行状态，其中，当前服务进程即为服务器中当前正在运行的服务进程。具体的，当服务器获取到故障检测指令时，进入故障检测流程，以根据该故障检测指令对服务器中的当前服务进程进行状态检测，获取其执行状态。其中，当前服务进程的执行状态包括正常状态和异常状态，可以理解的是，异常状态代表服务器故障，因此，当执行状态为异常状态时方可进入后续故障维护流程。

此外，上述故障检测指令的获取方式并不唯一，可以由技术人员按照需求从服务器前端输入，也可以基于预设的响应指令自动触发，如定时指令等，对此，本申请不做具体限定。另外，故障检测指令的具体类型同样不影响本技术方案的实施。

优选的，上述根据故障检测指令对当前服务进程进行状态检测，可以包括：根据showmount-e命令对当前服务进程进行状态检测。

本申请实施例提供了一种具体类型的故障状态检测指令，即showmount-e命令。具体的，showmount命令是对应于NFS(Network File System，网络文件***)服务器的查询命令，用于查询NFS服务器的相关信息。

需要说明的是，本申请所提供的技术方案并不受服务器类型的限制，即适用于各种类型的服务器，如上所述，在本申请实施例中，采用的是NFS服务器，其对应的服务进程可以为ganesha服务，对应的故障状态检测指令可以为showmount-e命令，而如果应用于其他类型的服务器，则检测其对应的服务进程以及采用对应的故障检测指令即可。

优选的，上述根据故障检测指令对当前服务进程进行状态检测，获得当前服务进程的执行状态，可以包括：根据故障检测指令采集当前服务进程中服务请求数量和服务请求处理数量的变化状态；根据变化状态确定当前服务进程的执行状态。

本申请实施例提供了一种较为具体的服务进程执行状态的获取方法，具体的，在获取到故障检测指令后，可根据该指令对当前服务器进程中的服务请求数量(服务器中获取到的服务请求的总数量)以及服务请求处理数量(服务器中已经处理的服务请求的总数量)进行采集，通过分析二者数量的变化状态，即可确定是否有服务请求处于卡死状态，以及哪些服务请求处于卡死状态，基于此，即可进一步确定当前服务进程的执行状态。

S102：判断当前服务进程的执行状态是否处于正常状态；若否，则执行S103；

本步骤旨在实现对当前服务进程的状态判断，具体为判断当前服务进程的执行状态是否处于正常状态，如果处于正常状态，则说明服务器无故障，无需做其他处理，继续正常的业务流程即可，如果处于异常状态，则说明服务器发生故障，需要进入后续的故障维护流程。

S103：启动日志收集进程，并利用日志进程收集日志信息；

本步骤旨在实现日志信息的收集，该日志信息主要用于实现故障判定，如具体的故障类型、故障位置等。具体的，当确定当前服务进程处于异常状态时，即可立即启动日志收集进程，进而利用日志收集进程收集当前服务进程在运行过程中产生的各类日志信息。当然，对于该日志信息的具体内容，本申请不做限定，例如，对于NFS服务器，其对应的日志信息可以为当前存储集群状态信息、ganesha日志信息等。

S104：判断日志信息中是否存在当前服务进程对应的core文件；若是，则执行S105，若否，则执行S106；

S105：关闭当前服务进程，并重启服务器；

本步骤旨在确定日志信息中是否有core文件生成，具体的，由于core文件由应用程序接收到***信号后因为崩溃而产生的文件，因此，一旦确定有core文件生成，则说明服务器已经崩溃，且终止了正常的业务流程。然而，由于core文件中的信息量较大，其生成过程所占用的时间过长，为避免由于业务中断降低用户体验，此时直接杀死当前服务进程，即关闭当前服务进程，避免core文件继续生成；进一步，重启服务器，并开启一个新的服务进程即可，相当于初始化至原始状态，重新进行业务处理。其中，core文件的存在与否直接在日志信息中的core文件目录下查询确认即可。

S106：重启服务器。

具体而言，对于日志信息中没有core文件生成的情况，说明服务器并非为崩溃故障，此时，重启服务器以重启当前服务进程，继续原来的业务处理即可，而对于具体的故障处理，由技术人员根据日志信息进行分析即可，不会中断正常业务的进行。例如，对于NFS服务器中的ganesha服务进程，可基于“systemctl restart ganesha”命令实现重启。

本申请实施例所提供的服务器故障维护方法，在服务器运行过程中，对服务器中的当前服务进程进行有效检测，当发现当前服务进程处于异常状态时，立即启动日志收集进程以获取该服务进程对应的日志信息，进而通过判断日志信息中是否有core文件生成以确定服务器是否处于卡死或崩溃状态，进一步，一旦发现有core文件生成，则立即杀死当前服务进程，并重启服务器，有效避免了由于core文件生成时间过长导致的客户业务中断的情况，进而保障了用户体验。

在上述各实施例的基础上，本申请实施实例提供了一种较为具体的服务器故障维护方法，请参考图2，图2为本申请所提供的另一种服务器故障维护方法的流程示意图，该服务器故障维护方法可以包括：

S201：按照预设时间间隔响应故障检测指令；

S202：根据故障检测指令对当前服务进程进行状态检测，获得当前服务进程的执行状态；

S203：判断当前服务进程的执行状态是否处于正常状态；若否，则执行S204，若是，则返回S201；

S204：启动日志收集进程，并利用日志进程收集日志信息；

S205：判断日志信息中是否存在当前服务进程对应的core文件；若是，则执行S206，若否，则执行S207；

S206：关闭当前服务进程，并重启服务器；

S207：重启服务器。

针对故障检测指令，本申请实施例提供了一种较为具体的获取方式，即定时响应。具体而言，由于服务器一般是长时间运行的，而人工输入故障检测检测指令根本无法保障服务器一直处于被检测状态，进而也无法保障服务器的正常运行。因此，可以预设定时指令，以按照预设的时间间隔自动响应故障检测指令，达到24小时不断检测的目的，弥补人力巡检不能实时检测的不足，进而保障服务器中的当前服务进程一直处于被检测的状态，有效保证服务器的正常运行。

其中，定时命令可基于crontab命令实现，具体的，crontab命令主要用于设置周期性被执行的指令，该命令从标准输入设备读取指令，并将其存放于“crontab”文件中，以供后续读取和执行。当然，也可以通过直接设定等待时间进入循环检测。此外，需要说明的是，对于上述预设时间间隔的具体取值，由技术人员根据实际情况进行设定即可，本申请对此不做限定。

关于上述步骤S202至S207的具体实施过程可参照前述实施例的内容，在此不再进行赘述。

可见，本申请实施例通过设置定时指令，以实现服务器的定时检测，保障了服务器可以一直处于被检测的状态，有效保证了服务器的正常运行，进一步保证了客户业务的正常运行。

在上述各实施例的基础上，本申请实施实例提供了另一种较为具体的服务器故障维护方法，请参考图2，图2为本申请所提供的又一种服务器故障维护方法的流程示意图，该服务器故障维护方法可以包括：

S301：按照预设时间间隔响应故障检测指令；

S302：根据故障检测指令对当前服务进程进行状态检测，获得当前服务进程的执行状态；

S303：判断当前服务进程的执行状态是否处于正常状态；若否，则执行S304，若是，则返回S301；

S304：启动日志收集进程，按照预设规则调节日志收集进程的日志级别，并利用调节后的日志进程收集日志信息；

S305：获取当前服务进程的当前执行状态，判断当前执行状态是否处于正常状态，若否，则执行S306，若是，则返回S301；

S306：判断日志信息中是否存在当前服务进程对应的core文件；若是，则执行S307，若否，则执行S308；

S307：关闭当前服务进程，并重启服务器；

S308：重启服务器。

本申请实施例以NFS服务器中ganesha服务进程的故障检测为例，进行技术方案的介绍。具体的，通过设定定时程序脚本24小时循环检测服务器集群ganesha服务的状态，如果服务正常，则输出检测结果，等待到达设定的时间间隔后再次检查；如果检测到服务异常，则启动故障信息收集(日志收集进程)及恢复程序，先动态调整ganesha服务日志级别，以收集更为具体详细的日志信息，包括指定时间段内的日志信息、集群状态等信息，再动态恢复日志级别；进一步，再次检查确认ganesha服务状态是否异常，若异常，则启动故障恢复程序，关闭ganesha服务，若正常则等待进入下次巡检程序。

其中，对于ganesha服务的状态检测程序，具体的，可以在程序中首先判断ganesha服务进程是否处于启动状态，若是，则通过ganesha服务的shoumount–e命令检查服务是否卡死，同时通过ganesha服务的时延统计功能检查请求数量与请求处理数量的变化，以确定哪些请求存在卡死状态，进而获得ganesha服务的执行状态。

其中，对于故障信息收集程序，具体的，当基于ganesha服务的状态检测流程确定ganesha服务处于正常状态时，则输出检测服务正常的日志信息。反之，当ganesha服务异常时，首先，动态调整ganesha服务的日志级别，以便收集更加详细的日志信息，待一定时间段后再动态关闭；其次，再次通过ganesha服务的状态检测流程确认ganesha服务是否故障，如果ganesha服务的异常状态已经恢复，则继续按正常流程不间断巡检；如果仍然处于异常状态，则收集所有日志信息到指定目录进行保存并输出。

其中，对于故障恢复程序，具体的，基于日志信息，先判断此时ganesha服务是否是因为崩溃而故障，即查询core文件目录下是否有该ganesha进程的core文件产生，若没有产生core文件，则可通过“systemctl restart ganesha”命令重启ganesha服务，若正在产生core文件，由于core文件很大，其产生时间可能在半个小时以上，因此不必等待生产完成，直接杀掉ganesha服务进程即可，然后再重启ganesha服务，完成故障恢复。

可见，本申请实施例所提供的服务器故障维护方法，在服务器运行过程中，对服务器中的当前服务进程进行有效检测，当发现当前服务进程处于异常状态时，立即启动日志收集进程以获取该服务进程对应的日志信息，进而通过判断日志信息中是否有core文件生成以确定服务器是否处于卡死或崩溃状态，进一步，一旦发现有core文件生成，则立即杀死当前服务进程，并重启服务器，有效避免了由于core文件生成时间过长导致的客户业务中断的情况，进而保障了用户体验。

为解决上述问题，请参考图4，图4为本申请所提供的一种服务器故障维护装置的结构示意图，该服务器故障维护装置可包括：

状态检测模块100，用于当获取到故障检测指令时，根据故障检测指令对当前服务进程进行状态检测，获得当前服务进程的执行状态；

状态判定模块200，用于判断当前服务进程的执行状态是否处于正常状态；

日志收集模块300，用于当当前服务进程的执行状态不处于正常状态时，启动日志收集进程，并利用日志进程收集日志信息；

文件判断模块400，用于判断日志信息中是否存在当前服务进程对应的core文件；

进程关闭模块500，用于当日志信息中存在core文件时，关闭当前服务进程，并重启服务器。

可见，本申请实施例所提供的服务器故障维护装置，在服务器运行过程中，对服务器中的当前服务进程进行有效检测，当发现当前服务进程处于异常状态时，立即启动日志收集进程以获取该服务进程对应的日志信息，进而通过判断日志信息中是否有core文件生成以确定服务器是否处于卡死或崩溃状态，进一步，一旦发现有core文件生成，则立即杀死当前服务进程，并重启服务器，有效避免了由于core文件生成时间过长导致的客户业务中断的情况，进而保障了用户体验。

作为一种优选实施例，该服务器故障维护装置还可以包括指令获取模块，用于按照预设时间间隔响应故障检测指令。

作为一种优选实施例，上述状态检测模块100可具体用于根据showmount-e命令对当前服务进程进行状态检测，获得当前服务进程的执行状态。

作为一种优选实施例，上述状态检测模块100可具体用于根据故障检测指令采集当前服务进程中服务请求数量和服务请求处理数量的变化状态；根据变化状态确定当前服务进程的执行状态。

作为一种优选实施例，该服务器故障维护装置还可以包括日志级别调节模块，用于在利用日志进程收集日志信息之前，按照预设规则调节日志收集进程的日志级别。

作为一种优选实施例，该服务器故障维护装置还可以包括二次状态判断模块，用于获取当前服务进程的当前执行状态；判断当前执行状态是否处于正常状态；若是，则执行文件判断模块400。

作为一种优选实施例，该服务器故障维护装置还可以包括服务器重启模块，用于当日志信息中不存在core文件时，重启服务器。

对于本申请提供的装置的介绍请参照上述方法实施例，本申请在此不做赘述。

为解决上述问题，请参考图5，图5为本申请所提供的一种服务器的结构示意图，该服务器可包括：

存储器10，用于存储计算机程序；

处理器20，用于执行计算机程序时实现如下步骤：

当获取到故障检测指令时，根据故障检测指令对当前服务进程进行状态检测，获得当前服务进程的执行状态；判断当前服务进程的执行状态是否处于正常状态；若否，则启动日志收集进程，并利用日志进程收集日志信息；判断日志信息中是否存在当前服务进程对应的core文件；若是，则关闭当前服务进程，并重启服务器。

对于本申请提供的服务器的介绍请参照上述方法实施例，本申请在此不做赘述。

为解决上述问题，本申请还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时可实现如下骤：

当获取到故障检测指令时，根据故障检测指令对当前服务进程进行状态检测，获得当前服务进程的执行状态；判断当前服务进程的执行状态是否处于正常状态；若否，则启动日志收集进程，并利用日志进程收集日志信息；判断日志信息中是否存在当前服务进程对应的core文件；若是，则关闭当前服务进程，并重启服务器。

该计算机可读存储介质可以包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

对于本申请提供的计算机可读存储介质的介绍请参照上述方法实施例，本申请在此不做赘述。

说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

以上对本申请所提供的服务器故障维护方法、装置、服务器以及计算机可读存储介质进行了详细介绍。本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围要素。

Claims (9)

1.一种服务器故障维护方法，其特征在于，包括：

当获取到故障检测指令时，根据所述故障检测指令采集当前服务进程中服务请求数量和服务请求处理数量的变化状态；

根据所述变化状态确定所述当前服务进程的执行状态；

判断所述当前服务进程的执行状态是否处于正常状态；

若否，则启动日志收集进程，并利用所述日志收集进程收集日志信息；

判断所述日志信息中是否存在所述当前服务进程对应的core文件；

若是，则关闭所述当前服务进程，并重启服务器；

若否，则重启服务器。

2.如权利要求1所述的服务器故障维护方法，其特征在于，获取所述故障检测指令，包括：

按照预设时间间隔响应所述故障检测指令。

3.如权利要求1所述的服务器故障维护方法，其特征在于，所述根据所述故障检测指令对当前服务进程进行状态检测，包括：

根据showmount-e命令对所述当前服务进程进行状态检测。

4.如权利要求1至3任意一项所述的服务器故障维护方法，其特征在于，所述利用日志进程收集日志信息之前，还包括：

按照预设规则调节所述日志收集进程的日志级别。

5.如权利要求4所述的服务器故障维护方法，其特征在于，所述利用所述日志进程收集日志信息之后，还包括：

获取所述当前服务进程的当前执行状态；

判断所述当前执行状态是否处于所述正常状态；

若否，则执行所述判断所述日志信息中是否存在所述当前服务进程对应的core文件的步骤。

6.如权利要求5所述的服务器故障维护方法，其特征在于，还包括：

当所述日志信息中不存在所述core文件时，重启服务器；

当所述日志信息中存在所述core文件时，关闭所述当前服务进程，并重启服务器。

7.一种服务器故障维护装置，其特征在于，包括：

状态检测模块，用于当获取到故障检测指令时，根据所述故障检测指令采集当前服务进程中服务请求数量和服务请求处理数量的变化状态，并根据所述变化状态确定所述当前服务进程的执行状态；

状态判定模块，用于判断所述当前服务进程的执行状态是否处于正常状态；

日志收集模块，用于当所述当前服务进程的执行状态不处于所述正常状态时，启动日志收集进程，并利用所述日志收集进程收集日志信息；

文件判断模块，用于判断所述日志信息中是否存在所述当前服务进程对应的core文件；

进程关闭模块，用于当所述日志信息中存在所述core文件时，关闭所述当前服务进程，并重启服务器，当所述日志信息中不存在所述core文件时，重启所述服务器。

8.一种服务器，其特征在于，还包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如权利要求1至6任意一项所述的服务器故障维护方法的步骤。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至6任意一项所述的服务器故障维护方法的步骤。

Images