CN109783262A - 故障数据处理方法、装置、服务器及计算机可读存储介质 - Google Patents

Abstract

本公开公开了一种故障数据处理方法、装置、服务器及计算机可读存储介质。其中，上述故障数据处理方法应用于服务器中的BMC，所述故障数据处理方法包括：在侦测到所述CPU被机器自动检查机制触发自检报错时，收集所述CPU对应的寄存器中的记录数据；对所述收集到的记录数据进行故障解析，以获得故障分析结果。通过在BMC感知到服务器内CPU发生的故障时，立即将CPU对应的多个寄存器内记录数据进行收集和分析。从而，确保记录数据中具备参考价值的有效故障信息可以被及时获取到，不受运行的服务器台数的影响，避免有效地故障信息丢失，提高故障分析结果的准确性。

Description

故障数据处理方法、装置、服务器及计算机可读存储介质

技术领域

本公开涉及计算机技术领域，具体而言，涉及故障数据处理方法、装置、服务器及计算机可读存储介质。

背景技术

服务器是用于提供计算服务的设备，于服务器而言，提供高可靠的服务十分重要，因此，用户对服务器的稳定性要求也较高。尽管当前服务器在稳定性方面做了充足的保障，但在长期运行过程中，服务器仍可能再不同运行阶段出现各类错误。服务器虽然具备一定的容错能力，但对于一些灾难性、致命性的故障依然难以自恢复，需要运维人员快速判定出故障根源并及时排除。判定故障根源最有效的方法是基于故障发生时服务器的寄存器中记录的运行数据进行故障判定。然而寄存器内数据容易被覆盖或清空，如果在灾难性、致命性的故障出现后不能及时对寄存器内的运行数据进行收集，则会导致最终得到的数据不够全面，影响故障判定的准确性。

发明内容

本公开的目的在于提供一种故障数据处理方法、装置、服务器及计算机可读存储介质，实现及时收集服务器的寄存器内有效的故障信息，提高故障判定的准确性。

为了实现上述目的，本公开采用的技术方案如下：

本公开第一方面提供了一种故障数据处理方法，应用于服务器中的基板控制器BMC，所述服务器还包括CPU及所述CPU对应的寄存器，所述BMC与所述CPU通信连接，所述故障数据处理方法包括：若侦测到所述服务器中的CPU被机器自动检查机制触发自检报错，则收集所述CPU对应的寄存器中的记录数据；对收集到的所述记录数据进行故障解析，以获得故障分析结果并存储。

本公开第二方面提供了一种故障数据处理装置，应用于服务器中的BMC，所述服务器还包括CPU及所述CPU对应的寄存器，所述BMC与所述CPU通信连接，所述故障数据处理装置包括：收集模块和解析模块。其中，收集模块用于若侦测到所述服务器中的CPU被机器自动检查机制触发自检报错，则收集所述CPU对应的寄存器中的记录数据；解析模块用于对收集到的所述记录数据进行故障解析，以获得故障分析结果并存储。

本公开第三方面提供了一种服务器，所述服务器包括BMC，所述BMC包括：处理器和存储介质，所述存储介质存储有所述处理器可执行的机器可读指令，当服务器运行时，所述BMC的处理器执行所述机器可读指令，以执行时执行前述的故障数据处理方法的步骤。

本公开第四方面提供一种程序产品，例如计算机可读存储介质，包括程序，该程序在被处理器执行时用于执行以上第一方面的方法。

相对现有技术，本公开提供的一种故障数据处理方法，应用于服务器中的BMC。该故障数据处理方法利用各服务器的BMC在侦测到CPU被机器自动检查机制触发自检报错时，立刻收集服务器中CPU对应的多个寄存器中的记录数据。通过对异常发生的及时感知故障的产生，从而确保记录数据中具备参考价值的有效故障信息可以被及时获取到，不受运行的服务器台数的影响，避免有效地故障信息丢失。再对收集到的记录数据进行故障解析，获得故障分析结果。全面、完整的有效故障信息，提高故障分析结果的准确性。

为使本公开的上述目的、特征和优点能更明显易懂，下文特举实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本公开的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本公开的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了相关技术中实现故障数据收集的应用场景示意图。

图2示出了本公开提供的服务器的方框示意图。

图3示出了本公开提供的故障数据处理方法的步骤流程图。

图4为图3中步骤S101的子步骤流程图。

图5示出了本公开提供另一种的故障数据处理方法的步骤流程图。

图6示出了本公开提供的故障数据处理装置的结构示意图。

图标：100-服务器；101-CPU；102-引脚监控模块；103-寄存器；200-BMC；201-通信接口；202-存储器；203-处理器；300-故障数据处理装置；310-监测模块；320-判断模块；330-收集模块；340-解析模块。

具体实施方式

下面将结合本公开中附图，对本公开中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本公开的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本公开的实施例的详细描述并非旨在限制要求保护的本公开的范围，而是仅仅表示本公开的选定实施例。基于本公开的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本公开保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本公开的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

在服务器投入运行前，虽然都会在稳定性方面做了充足的保障，但依然不能避免在长期运行过程中出现各类错误。为了应对长期运行过程中服务器出现的故障，并在能自恢复的情况下，及时矫正出现故障，避免诱发致命性、灾难性的故障，通常服务器会提供一种机器自动检查机制(Machine Check Architecture，MCA)，通过MCA机制及时发现服务器出现的故障，并进行相应处理。需要说明的是，由于服务器在运行过程中出现任何故障时，均会将相关的故障信息写入服务器中的寄存器(例如，MCA寄存器和其他相关的CSR寄存器)作为其记录数据，上述MCA机制则是利用寄存器内的记录数据执行自检，并在发现故障时生成中断指令或异常指令，以便于服务器的系统软件在收到中断指令或异常指令后，对其进行响应，进行相应的自修复、告警或其他策略等动作。从而，保证在发生crash等错误前，服务器可以有机会做一些容错处理。

当然，被写入寄存器内的记录数据，不仅可以帮助服务器对可自行恢复的故障进行处理，还可以在出现不可恢复的故障时为运维工作提供有效的参考信息，以便于快速定位故障根源，及时解决故障，降低故障带来的损失。然而，寄存器存在不稳定的问题，其内存储的记录数据长时间不收集则会被覆盖。另外，服务器在完成对可自恢复的故障的处理后会进行重启，重启后寄存器记录的数据均会被清空，从而导致收集到的数据不够全面。因此，可以及时将各故障发生时写入相关寄存器的记录数据保存下来就对于运维工作来说就异常重要了。

相关技术中，如图1所示，采用管理服务器与多台业务服务器通信连接。利用管理服务器逐一检测业务服务器的运行状态，以便在检测到任意业务服务器出现异常时，对出现异常的业务服务器内寄存器的记录数据进行收集。具体地，管理服务器会间隔轮询与每一台业务服务器之间的网络状态，当出现与一业务服务器之间网络ping不通时，则判定该业务服务器出现异常。接着，管理服务器向出现异常的业务服务器的BMC发送用于指示收集MCA寄存器内的记录数据的IPMI命令。接收到的IPMI命令的BMC将IPMI命令解析为PECI命令，并将解析得到的PECI命令发送至对应中央处理器(CPU)，以便对MCA寄存器内的记录数据进行收集，并反馈至管理服务器。最终，由管理服务器完成故障解析，以便为运维工作提供指导信息。

然而，采用管理服务器监督并触发寄存器内记录数据收集的方式存在以下弊端：

一方面，容易出现误判。由于判断是否收集寄存器内记录数据的条件是出现网络不通，然而，大部分情况下网络不通可能是由正常关机或者网线松动等原因造成。因此，一出现网络不通则触发记录数据收集，将导致大量无意义数据的收集。

另一方面，延时大。特别是管理服务器同时管理着数以万计的业务服务器时，两次访问同一业务服务器之间的时间间隔大。同时，管理服务器发现业务服务器故障后，需要通过网络带外发送IPMI命令到故障的业务服务器的BMC，从管理服务器发送IPMI指令与BMC真正执行寄存器内记录数据的收集之间的时间开销较大。需要说明的是，对于部分业务服务器而言，由部分故障触发的自检报错，在自检报错被恢复后会执行系统重启，重启完成后寄存器内记录数据也会被清空。此时，过大的时延就会导致具备参考价值的寄存器数据无法被收集到。

再一方面，管理服务器若是自身出现故障，不仅会导致之前收集的数据丢失，还会造成业务服务器的寄存器内的记录数据无法被收集。

因此，本公开提供了一种故障数据处理方法、装置、服务器及计算机可读存储介质，用于改善上述问题。

请参考图2，图2示出了本公开提供的一种服务器100。本公开提供的故障数据处理方法、装置、服务器及计算机可读存储介质，基于服务器100的MCA机制可以及时检测出发生的故障的原理，通过改进使服务器100的BMC200可感知到MCA机制检测出的故障，并在感知到故障时立即触发进行寄存器103内记录数据的收集。确保寄存器103内有效的故障数据得到及时的收集。即使大量服务器100并行运行时，也不影响寄存器103内记录数据的及时收集。

如图2所示，上述服务器100包括至少一个CPU101、引脚监控模块102、寄存器103及BMC200。上述BMC200分别与每一个CPU101通信连接，具体地，BMC200可以是通过PECI通道与CPU101通信连接。上述BMC200还可以与引脚监控模块102通信连接，例如，BMC200可以通过I2C通道与引脚监控模块102通信连接。上述CPU101与引脚监控模块102电性连接。作为一种实施方式，上述CPU101可以是英特尔第六代微处理器。上述引脚监控模块102可以接收并存储与其连接的其他模块的输出信息。可选地，可以采用服务器100中的CPLD逻辑电路模块作为引脚监控模块102。当然，引脚监控模块102还可以是其他具备接收及存储功能的电路模块。

上述寄存器103用于记录服务器100中对应的电路模块(例如，CPU101、内存)运行过程中的状态信息或指令信息等。可选地，上述寄存器103中包括CPU101相关的MCA寄存器、内存相关的MCA寄存器、PCIe等IIO外设相关的MCA寄存器及其他CSR寄存器等。需要说明的是，寄存器103可以按照其功能不同分为多组寄存器组，可以理解的，每一寄存器组包括至少一个寄存器。每一CPU101具有多组对应的存储器组。

可选地，上述BMC200包括存储器202、通信接口201、处理器203，处理器203用于执行存储器202中存储的可执行模块，例如计算机程序。

其中，存储器202可能包含高速随机存取存储器(RAM：Random Access Memory)，也可能还包括非不稳定的存储器(non-volatile memory)。

通过至少一个通信接口201(可以是有线或者无线)实现该BMC200与其他电路模块(例如，CPU、CPLD)之间的通信连接。

其中，存储器202用于存储程序，例如图6所示的故障数据处理装置300、启用各类线程的程序段。该故障数据处理装置300包括至少一个可以软件或固件(firmware)的形式存储于所述存储器202中。所述处理器203在接收到执行指令后，执行所述程序以实现本公开上述实施例揭示的故障数据处理方法。

处理器203可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器203中的硬件的集成逻辑电路或者软件形式的指令完成。

请参照图3，图3示出了本公开提供的故障数据处理方法，应用于服务器100中的BMC200。上述故障数据处理方法可以包括以下步骤：

步骤S101，若侦测到CPU101被机器自动检查机制触发自检报错，则收集CPU101对应的多个寄存器103中的记录数据。

在本实施例中，在服务器中的BMC200侦测到该服务器中出现至少一个CPU101被运行的MCA机制触发自检报错时，主动收集每一CPU101对应的多个寄存器103中的记录数据。需要说明的是，运行着MCA机制的CPU101在检测到任意故障出现时，均会触发自检报错，与此同时，该CPU101的MCA寄存器及部分相关的CSR寄存器中也会被写入相关的故障信息，也就是，相关的故障信息将作为该寄存器103内的记录数据被暂存。因此，BMC200只要侦测到自检报错被触发，便立即启动对每一CPU101对应的多个寄存器103内的记录数据的收集，有效的压缩了故障产生到对应的故障信息被收集到之间的时间间隔，可确保收集到的记录数据中包括有效的故障信息，避免有效的故障信息丢失。

可以理解地，上述对应的多个寄存器103可以是预先选定的较为重要的MCA寄存器和CSR寄存器。当然，在其他实施例中，上述对应的多个寄存器103也可以是CPU101所对应的所有的寄存器103。

可选地，如图4所示，上述收集CPU101对应的多个寄存器103中的记录数据可以包括以下子步骤：

子步骤S1011，判断是否已收集与本次自检报错对应的记录数据。

本实施例中，上述自检报错对应的记录数据可以是存储于寄存器103中且与该自检报错相关的故障信息。可以理解的，在CPU101发现故障后，故障未被处理期间，反复触发的多次自检报错所针对的故障可以被认定为同一故障，有效的故障信息也是相同的。此时，若对每次自检报错均进行记录数据收集，既无意义，又增加服务器100负载。因此，为了避免重复执行对具有相同参考价值的记录数据进行收集，在BMC200正式启动对寄存器103内数据进行收集之前，需要进行一次判定，判定是否已收集过与本次自检报错对应的记录数据(即，与本次自检报错相关的故障信息)。当然，如果该故障被成功处理，那么服务器100会在故障被处理后进行重启。重启后，寄存器103内的记录数据被清空，以便接受并存储新的记录数据。此时，服务器100重启后由CPU101再次触发的自检报错和服务器100重启前由CPU101触发的自检报错各自所针对的故障则可以认定为两个故障，其各自对应的故障信息也可认定为不同故障的故障信息。可以理解的，上述两个故障并不限定为两个不同类型的故障，也可以是相同类型的故障。

作为一种实施方式，利用服务器100重启前后对故障数量的认定原理，BMC200判断是否已收集与本次自检报错对应的记录数据的方式可以是：获取指定变量的赋值信息，若其赋值信息为第一信息，则判定未收集与本次自检报错对应的记录数据。若其赋值信息为第二信息，则判断已收集与本次自检报错对应的记录数据。

需要说明的是，指定变量可以是从服务器100内预先选定一个变量，该指定变量的赋值信息可变更。具体地，指定变量的赋值信息在服务器100出现系统重启之后第一次出现CPU101的自检报错时，被变更为第一信息，另外，指定变量的赋值信息在BMC200执行完毕一次对记录数据的收集时，会被变更为第二信息。

下面，给出一个实例，以对上述判断是否已收集与本次自检报错对应的记录数据的过程进行详细说明。预先从服务器100中选定了一个全局变量hava_mca_data作为指定变量，上述hava_mca_data的赋值信息可以是第一信息fales和第二信息true之间的任意一个。具体地，由服务器100内的一个线程rest_work_thread实时侦查服务器100是否发生重启，在rest_work_thread侦测到出现重启之后，若服务器100内的CPU101第一次出现自检报错，则将hava_mca_data赋值为第一信息，即hava_mca_data＝fales；在服务器100确定BMC200执行完一轮记录数据收集后，则将hava_mca_data赋值为第二信息，即hava_mca_data＝true。

进一步地，BMC200在侦测到任意CPU101中触发了自检报错，查询hava_mca_data的赋值信息，如果hava_mca_data＝fales，则流程进入子步骤S1012，如果hava_mca_data＝true，则结束流程。

子步骤S1012，当未收集与本次自检报错对应的记录数据时，生成数据收集指令。

在本实施例中，可以是直接生成数据收集指令，上述数据收集指令可以是PECI命令。相较于相关技术，得到PECI命令的方式无需通过对从外部接收到的命令(例如，IPMI命令)进行解析，直接在BMC200发现CPU101出现自检报错后生成，可有效的降低时延。

子步骤S1013，将数据收集指令发送至所述CPU101，以便获取到记录数据。

在本实施例中，可以是BMC200通过PECI通道，将生成的PECI命令发送至每一与BMC200通信的CPU101，从而获取每一个CPU101对应的多个寄存器103内的记录数据。需要说明的是，在多个CPU101配合工作的服务器100中，可能存在一CPU101出现故障，而其他CPU101会优先感知到并触发自检报错。也就是，存在CPU101触发的自检报错对应故障的根源在于其他CPU101的情况。例如，一CPU101访问一发生故障的其他CPU101时，由于发生故障的其他CPU101不能及时响应访问请求，那么该CPU101也会由于发送的访问请求超时延而触发自检报错。此时，仅收集自检报错的CPU101对应的多个寄存器103内的记录数据显然是无法准确的确定出故障根源的，因此，无论是侦测到哪一台CPU101内触发了自检报错，均需对每一台CPU101对应的多个寄存器103内的记录数据进行收集，确保收集到的记录数据够全面，也更具有参考价值。

进一步地，在CPU101接收到PECI命令后，会依据PECI命令将对应的多个寄存器103内的记录数据反馈至BMC200，由BMC200将收集到的记录数据存储于服务器100中的指定存储区域，便于审计及故障解析。例如，BMC200可以将接收到的记录数据以时间戳命名的形式保存在预先在服务器100内选定的一SD卡中。在BMC200完成对寄存器103内的记录数据的收集和存储后，流程进入步骤S102。

步骤S102，对收集到的记录数据进行故障解析，以获得故障分析结果。

在本实施例中，BMC200在完成一轮对记录数据的收集后，触发对收集到的记录数据的解析。例如，在接收完各CPU101反馈的记录数据并存储完毕后，可以通知BMC_PECI_Decode_MCA_Thread线程当前的记录数据已收集完毕，可以执行故障解析。从而，使收集和解析两个过程分离，避免解析线程的运行不会对收集线程的运行造成影响。

可选地，服务器100内的寄存器103会按照功能分为不同的寄存器组。上述对记录数据进行故障解析可以是：

依次对来自每一寄存器组的记录数据进行解析，获取每一寄存器组对应的错误报告信息。作为一种实施方式，可以先对获得的解析数据按照其对应的寄存器组进行分类，依次对每一类带解析数据进行解析，以获得每一寄存器组对应的错误报告信息。可选地，上述错误报告信息可以包括体现出该错误的记录数据在原寄存器中对应的原始记录值、体现出该错误的记录数据被BMC200收集到的时间和被解析出来的时间、解析出的错误发生原因、该错误对服务器100的危害等级等。作为一种实施方式，可以通过在服务器100投入使用前采用XDP工具进行频繁的故障注错后标记的训练方式使BMC200可以准确的解析出错误发生原因，还可以配合在服务器100投入使用后遇到真实报错后查看解析结果是否符合预期，并在不符合预期的情况下进行绞错，提高解析结果的准确性。

对得到的错误报告信息进行综合解析，以获得所述故障分析结果。可选地，对得到的错误报告信息进行综合解析的方式可以采用“由远及近”的原则。即当从来自不同寄存器组的记录数据中解析出相同的错误，可以通过“由远及近”的原则推定故障的根源所属。上述“远和近”可以是依据寄存器组所服务的电路模块与CPU101之间的关联程度判断。例如，CPU101与内存之间进行数据交互时，中间需要通过至少一个中转电路模块进行数据的中转，因此，相比于中转电路模块，内存与CPU101之间的关联远；相比于内存，中转电路模块与CPU101之间的关联近。当从内存相关MCA寄存器组、中转电路模块相关MCA寄存器组和CPU101相关MCA寄存器组收集到的记录数据均解析出同一错误，则作为与CPU101关联最远的内存将被判定为本次故障的根源；当仅仅是从CPU101相关MCA寄存器组收集到的记录数据被解析出的错误，则该错误的根源在于CPU101；当从中转电路模块相关MCA寄存器组和CPU101相关MCA寄存器组收集到的记录数据均解析出同一错误，则该中转电路模块将被判定为本次故障的根源。

在本实施例中，故障分析结果包括故障定位信息及匹配的解决策略。进一步地，在判断出故障的根源后，还需要得到具体的故障定位信息。例如，根源在于内存的故障其对应的故障定位信息可以是具体到内存槽位dimm上的Rank错误；根源在于IIO的故障对应的故障定位信息可以具体到哪台PCIe设备以及对应的哪个slot丝印号。上述匹配的解决策略可以是预先设定的与每一类故障定位信息匹配的策略。

需要说明的是，在对记录数据进行收集时，如果采用仅对预先选定的CPU101中部分较为重要的MCA寄存器和CSR寄存器执行记录数据收集的方式，那么针对特定故障，还需要一些不属于预先选定的其他寄存器内的记录数据配合分析。此时，若基于触发自检报错后收集到的记录数据判定出的故障为特定故障，则再一次触发BMC200从与特定故障相关且不属于预先选定的其他寄存器中进行数据收集。也就是，将服务器100内的寄存器103分为两类，第一类必须进行记录数据收集的寄存器(即预先选定的CPU101中部分较为重要的MCA寄存器和CSR寄存器，通常此类寄存器内的数据会在执行步骤S101时，被收集到。第二类为根据实际需求确实是否需要重启收集进程进行记录数据收集的寄存器。第二类寄存器中的记录数据可以是在步骤S102判定出故障的根源后，依据实际需求，选择进行收集。

可选地，在获得故障分析结果后，可以将分析结果报送用户，便于为后期的运维工作提供具有参考价值的信息。例如，可以是将故障分析结果写入服务器100的日志信息中，以便展示。通过上述过程，可以向运维人员提供直观的具有参考价值的数据，运维人员无需直接面向晦涩的原始数据进行分析，可有效缩短故障诊断时间，加快故障恢复工作的效率，减少故障带来的损失。还可以将故障分析结果存储于本地，方便运维人员随时查询。实现了分析结果的分布式存储，相较于相关技术中对分析结果集中存储而言，可靠性也更佳。

进一步地，如图5所示，本公开还提供了一种故障数据处理方法，该故障数据处理方法在步骤S101之前还可以包括以下步骤：

步骤S201，按照预设的时间间隔监测每个CPU101中指定引脚的状态信息。

需要说明的是，上述指定引脚的状态信息在对应CPU101触发自检报错时出现变更。可以理解的，CPU101包括多个输出引脚，输出引脚作为CPU101的硬件输出口，其向外输出的状态信息受CPU101运行影响。上述指定引脚则属于CPU101的多个输出引脚，其中，指定引脚向外输出的状态信息会受到自检报错影响。例如，指定引脚可以是CPU101的MSMI引脚和CATTER引脚中的至少一种。MSMI引脚和CATTER引脚在CPU101正常运行时均输出高电平，一旦CPU101触发自检报错，则MSMI引脚和CATTER引脚均为输出低电平。可以理解的，物理上MSMI引脚和CATTER引脚均与引脚监控模块102连接。在错误发生时，根据当前的(BasicInput Output System，BIOS)基本输入输出系统内预先配置数据确定由MSMI引脚或CATTER引脚中哪一个引脚对外界进行提醒。作为一种实施方式，MSMI引脚或CATTER引脚针对自检报错输出低电平的形式可以依据判定出的错误严重程度的类别而不同，例如，严重级别的错误，引脚持续输出低电平；轻微级别的错误，引脚输出多个连续的时钟信号。

在本实施例中，BMC200通过实时监督每个CPU101的指定引脚的状态信息判断CPU101是否被触发了自检报错。可以理解的，采用这种硬件通知的方式其时效性和有效性都比较高。

作为一种实施方式，上述监督每个CPU101的指定引脚的状态信息可以借助引脚监控模块102的配合实现。具体地，将每一CPU101的指定引脚与引脚监控模块102电性连接。引脚监控模块102可以感知到与其连接的指定引脚的电平状态，并记录监测到的指定引脚的电平状态。进一步地，BMC200通过按照时间间隔引脚监控模块102内记录的指定引脚的电平状态，确定检测到的指定引脚的状态信息。

接上例，指定引脚为CATTER引脚，引脚监控模块102为CPLD逻辑电路模块，CPLD逻辑电路模块的0x32寄存器中设置一自检报错对应的比特(bit)位。该bit位在被置位时，代表CPLD逻辑电路模块内记录情况为：被监测的CATTER引脚中存在电平状态为低电平的引脚。该bit位在未被置位时，代表CPLD逻辑电路模块内记录情况为：被监测的CATTER引脚均为电平状态为高电平的引脚。BMC200通过I2C通道按照预设的时间间隔轮询该0x32寄存器内自检报错对应的bit位是否被置位，从而确定检测到的指定引脚的状态信息。

步骤S202，依据状态信息判定所述CPU101是否被触发自检报错。

在本实施例中，若检查到电平状态与预定的标准状态不同，则判定所述CPU101被触发所述自检报错。上述预定的标准状态可以是CPU101正常工作、未出现自检报错的情况下对应的指定引脚的电平状态。

接上例，由于CPU101正常工作、未出现自检报错时，连接CPLD逻辑电路模块的CATTER引脚均为高电平，因此，预定的标准状态可以是被监测的CATTER引脚的电平状态均为高电平。在BMC200查询到的0x32寄存器内自检报错对应的bit位没有被置位，则表示得到的检查到电平状态与预定的标准状态相同，此时CPU101没有被触发自检报错。在BMC200查询到的0x32寄存器内自检报错对应的bit位被置位，则表示得到的检查到电平状态与预定的标准状态不相同，此时CPU101被触发自检报错。

在判定所述CPU101被触发所述自检报错时，流程进入步骤S101。

请参考图6，为本公开所提供的故障数据处理装置300的功能模块示意图。需要说明的是，本实施例所提供的故障数据处理装置300，其基本原理及产生的技术效果与前述方法实施例相同，为简要描述，本实施例中未提及部分，可参考前述方法实施例中的相应内容。所述故障数据处理装置300包括监测模块310、判断模块320、收集模块330及解析模块340。

可以理解，上述监测模块310、判断模块320、收集模块330及解析模块340可以为存储于BMC200的存储器202的软件功能模块及计算机程序，并且可以被BMC200的处理器203执行。

上述监测模块310，用于按照预设的时间间隔监测每个所述CPU101中指定引脚的状态信息。

可以理解，该监测模块310可以执行上述步骤S201。需要说明的是，上述指定引脚的状态信息在所述自检报错被触发时出现变更。具体地，监测模块310可以是按照所述时间间隔检查所述引脚监控模块102内记录的所述指定引脚的电平状态。

上述判断模块320，用于依据所述状态信息判定所述CPU101是否被触发所述自检报错。

可以理解，该判断模块320可以执行上述步骤S202。具体地，判断模块320在检查到的电平状态与预定的标准状态不同时，判定所述CPU101被触发自检报错。

上述收集模块330，用于若侦测到服务器中的CPU101被机器自动检查机制触发自检报错，则收集所述至少一个CPU101对应的多个寄存器103中的记录数据。

可以理解，该收集模块330可以执行上述步骤S101及步骤S101对应的子步骤。

具体地，收集模块330可以用于判断是否已收集与本次自检报错对应的记录数据，当未收集与本次自检报错对应的记录数据时，生成数据收集指令；将所述数据收集指令发送至所述CPU101，以便获取到所述记录数据。可选地，上述收集模块330执行判断的方式可以是获取指定变量的赋值信息，若所述赋值信息为第一信息，则判定未收集与本次自检报错对应的记录数据，若所述赋值信息为第二信息，则判断已收集与本次自检报错对应的记录数据。

需要说明的是，上述指定变量在系统重启之后第一次出现所述自检报错时，对应的所述赋值信息为所述第一信息；所述指定变量在所述BMC200执行完一次对所述记录数据的收集后，对应的所述赋值信息为所述第二信息。

上述解析模块340，用于对收集到的记录数据进行故障解析，以获得故障分析结果。

可以理解，该解析模块340可以执行上述步骤S102。优选地，解析模块340执行步骤S102的方式为：依次对来自每一所述寄存器组的所述记录数据进行解析，获取每一所述寄存器组对应的错误报告信息；对得到的所述错误报告信息进行综合解析，以获得所述故障分析结果，其中，所述故障分析结果包括故障定位信息及匹配的解决策略。

本公开还揭示了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器203执行时实现本公开前述实施例揭示的方法。

综上所述，本公开提供的一种故障数据处理方法、装置、服务器及计算机可读存储介质。其中，上述故障数据处理方法应用于服务器中的BMC，所述故障数据处理方法包括：若BMC侦测到所述服务器的CPU被机器自动检查机制触发自检报错时，收集所述CPU对应的寄存器中的记录数据；BMC依次对接收到的记录数据进行故障解析，并存储获得的故障分析结果。通过BMC及时有效的感知到服务器内CPU发生的故障，并快速有效的对对应的多个寄存器内记录数据进行收集和分析，确保记录数据中具备参考价值的有效故障信息可以被及时获取到，不受运行的服务器台数的影响，避免有效地故障信息丢失。提高故障分析结果的准确性。

本领域内的技术人员应明白，本公开可提供为方法、装置、设备或计算机程序产品。因此，本公开可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本公开可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本公开是参照根据本公开的方法、装置、设备和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在本公开所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置和方法实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本公开的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本公开各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅为本公开的可选实施例而已，并不用于限制本公开，对于本领域的技术人员来说，本公开可以有各种更改和变化。凡在本公开的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本公开的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

Claims (10)

1.一种故障数据处理方法，其特征在于，应用于服务器中的BMC，所述服务器还包括CPU及所述CPU对应的寄存器，所述BMC与所述CPU通信连接，所述故障数据处理方法包括：

若侦测到所述服务器中的CPU被机器自动检查机制触发自检报错，则收集所述CPU对应的寄存器中的记录数据；

对收集到的所述记录数据进行故障解析，以获得故障分析结果并存储。

2.如权利要求1所述的故障数据处理方法，其特征在于，所述故障数据处理方法还包括：

按照预设的时间间隔监测每个所述CPU中指定引脚的状态信息；

依据所述状态信息判定所述CPU是否被触发所述自检报错；

其中，所述指定引脚的状态信息在所述自检报错被触发时出现变更。

3.如权利要求2所述的故障数据处理方法，其特征在于，所述服务器还包括引脚监控模块，所述引脚监控模块分别与每一所述指定引脚电性连接；所述引脚监控模块与所述BMC通信连接，所述引脚监控模块用于记录监测到的所述指定引脚的电平状态；

按照预设的时间间隔监测每个所述CPU中指定引脚的状态信息的步骤包括：按照所述时间间隔检查所述引脚监控模块内记录的所述指定引脚的电平状态；

依据所述状态信息判定所述CPU是否被触发所述自检报错的步骤包括：若检查到所述电平状态与预定的标准状态不同，则判定所述CPU被触发所述自检报错。

4.如权利要求1所述的故障数据处理方法，其特征在于，所述CPU对应的寄存器按照功能分为不同的寄存器组，对收集到的所述记录数据进行故障解析的步骤包括：

依次对来自每一所述寄存器组的所述记录数据进行解析，获取每一所述寄存器组对应的错误报告信息；

对得到的所述错误报告信息进行综合解析，以获得所述故障分析结果，其中，所述故障分析结果包括故障定位信息及匹配的解决策略。

5.如权利要求1所述的故障数据处理方法，其特征在于，所述收集所述CPU对应的寄存器中的记录数据的步骤包括：

判断是否已收集与本次自检报错对应的记录数据；

当未收集与本次自检报错对应的记录数据时，生成数据收集指令；

将所述数据收集指令发送至所述CPU，以便获取到所述记录数据。

6.如权利要求5所述的故障数据处理方法，其特征在于，所述判断是否已收集与本次自检报错对应的记录数据的步骤包括：

获取指定变量的赋值信息；

若所述赋值信息为第一信息，则判定未收集与本次自检报错对应的记录数据；

若所述赋值信息为第二信息，则判断已收集与本次自检报错对应的记录数据；

其中，所述指定变量在系统重启之后第一次出现所述自检报错时，对应的所述赋值信息为所述第一信息；所述指定变量在所述BMC执行完一次对所述记录数据的收集后，对应的所述赋值信息为所述第二信息。

7.一种故障数据处理装置，其特征在于，应用于服务器中的BMC，所述服务器还包括CPU及所述CPU对应的寄存器，所述BMC与所述CPU通信连接，所述故障数据处理装置包括：

收集模块，用于若侦测到所述服务器中的CPU被机器自动检查机制触发自检报错，则收集所述CPU对应的寄存器中的记录数据；

解析模块，用于对收集到的所述记录数据进行故障解析，以获得故障分析结果并存储。

8.如权利要求7所述的故障数据处理装置，其特征在于，所述故障数据处理装置还包括：

监测模块，用于按照预设的时间间隔监测每个所述CPU中指定引脚的状态信息；

判断模块，用于依据所述状态信息判定所述CPU是否被触发所述自检报错；

其中，所述指定引脚的状态信息在所述自检报错被触发时出现变更。

9.一种服务器，其特征在于，所述服务器包括BMC，所述BMC包括：处理器和存储介质，所述存储介质存储有所述处理器可执行的机器可读指令，当所述服务器运行时，所述BMC的处理器执行所述机器可读指令，以执行时执行如权利要求1-6任一所述的故障数据处理方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现如权利要求1-6中任一项所述的方法。