CN115934453A - 一种故障排查方法、装置及存储介质 - Google Patents

Abstract

本申请公开了一种故障排查方法、装置及存储介质。方法包括：响应于针对指定服务器集群的温度告警日志，确定温度告警日志所指示的目标部件以及目标服务器；其中，目标部件为目标服务器中出现温度告警的服务器部件；获取目标部件的第一类传感器信息、可疑部件的第二类传感器信息以及目标服务器所属部署单元的温度信息；基于第一类传感器信息、第二类传感器信息以及温度信息，确定针对温度告警日志的故障排查结果。本申请提供了一套程序化的故障排查方案，基于该方案可以规避个人感性判断的干扰，减少漏判和误判的出现，从而能够实现准确的故障排查。人工介入的减少，整个故障排查流程的自动化，可以提高故障排查效率、节省人力成本开销。

Description

一种故障排查方法、装置及存储介质

技术领域

本申请涉及互联网通信技术领域，尤其涉及一种故障排查方法、装置及存储介质。

背景技术

服务器部件出现异常，往往会影响服务器对于相关业务功能的支持实现。相关技术中，通常由工作人员结合各类日志和业务系统的相关功能实现情况来进行确定出现异常的服务器部件，以及针对出现异常的服务器部件进行故障排查。该过程对于个人感性判断的依赖度较高且缺乏程序化的故障排查逻辑。这样往往由于过分依赖人工出现效率低下、信息遗漏等问题，从而不能提供及时且准确的故障排查方案。

发明内容

为了解决现有技术应用在故障排查时，不能提供及时且准确的故障排查方案等问题，本申请提供了一种故障排查方法、装置及存储介质：

根据本申请的第一方面，提供了一种故障排查方法，所述方法包括：

响应于针对指定服务器集群的温度告警日志，确定所述温度告警日志所指示的目标部件以及目标服务器；其中，所述目标部件为所述目标服务器中出现温度告警的服务器部件，所述目标服务器为所述指定服务器集群中的任一服务器；

获取所述目标部件的第一类传感器信息以及可疑部件的第二类传感器信息；其中，所述可疑部件为所述目标服务器中与引发所述目标部件出现温度告警具有疑似关联关系的服务器部件；

获取所述目标服务器所属部署单元的温度信息；

基于所述第一类传感器信息、所述第二类传感器信息以及所述温度信息，确定针对所述温度告警日志的故障排查结果。

根据本申请的第二方面，提供了一种故障排查装置，所述装置包括：

第一确定模块：用于响应于针对指定服务器集群的温度告警日志，确定所述温度告警日志所指示的目标部件以及目标服务器；其中，所述目标部件为所述目标服务器中出现温度告警的服务器部件，所述目标服务器为所述指定服务器集群中的任一服务器；

第一获取模块：用于获取所述目标部件的第一类传感器信息以及可疑部件的第二类传感器信息；其中，所述可疑部件为所述目标服务器中与引发所述目标部件出现温度告警具有疑似关联关系的服务器部件；

第二获取模块：用于获取所述目标服务器所属部署单元的温度信息；

第二确定模块：用于基于所述第一类传感器信息、所述第二类传感器信息以及所述温度信息，确定针对所述温度告警日志的故障排查结果。

根据本申请的第三方面，提供了一种电子设备，所述电子设备包括处理器和存储器，所述存储器中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由所述处理器加载并执行以实现如第一方面所述的故障排查方法。

根据本申请的第四方面，提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由处理器加载并执行以实现如第一方面所述的故障排查方法。

根据本申请的第五方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行如第一方面所述的故障排查方法。

本申请提供的一种故障排查方法、装置及存储介质，具有如下技术效果：

本申请通过确定温度告警日志所指示的目标部件以及目标服务器，然后获取目标部件的第一类传感器信息、可疑部件的第二类传感器信息以及目标服务器所属部署单元的温度信息，从而基于获取到的信息确定针对该温度告警日志的故障排查结果。其中，目标部件为目标服务器中出现温度告警的服务器部件，可疑部件为目标服务器中与引发目标部件出现温度告警具有疑似关联关系的服务器部件。本申请提供了一套程序化的故障排查方案，基于该方案可以规避个人感性判断的干扰，减少漏判和误判的出现，从而能够实现准确的故障排查。人工介入的减少，整个故障排查流程的自动化，可以提高故障排查效率、节省人力成本开销。

附图说明

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

图1是本申请实施例提供的一种应用环境的示意图；

图2是本申请实施例提供的一种故障排查方法的流程示意图；

图3是本申请实施例提供的确定针对温度告警日志的故障排查结果的一种流程示意图；

图4是本申请实施例提供的关于误报次数的处理过程的一种流程示意图；

图5是本申请实施例提供的温度监控日志的示意图；

图6也是本申请实施例提供的一种故障排查方法的流程示意图；

图7是本申请实施例提供的带外管理系统的示意图；

图8是本申请实施例提供的服务器故障处理系统的硬件替换流程示意图；

图9也是本申请实施例提供的一种故障排查方法的流程示意图；

图10是本申请实施例提供的一种故障排查装置的组成框图；

图11是本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

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

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

BMC(Baseboard Management Controller)：基板管理控制器。

SDR(Sensor Data Record)：传感器数据记录。

SNMPTRAP(Simple Network Management Protocol TRAP)：基于简单网络管理协议陷阱格式。

IPMI(Intelligent Platform Management Interface)：智能平台管理接口。

请参阅图1，图1是本申请实施例提供的一种应用环境的示意图，该应用环境中可以包括指定服务器集群10和服务端20。指定服务器集群10和服务端20可以通过有线或无线通信方式进行直接或间接地连接。服务端20响应于针对指定服务器集群的温度告警日志，确定温度告警日志所指示的目标部件以及目标服务器，然后获取目标部件的第一类传感器信息、可疑部件的第二类传感器信息以及目标服务器所属部署单元的温度信息，再基于获取到的信息确定针对该温度告警日志的故障排查结果，从而实现针对指定服务器集群10的故障排查。可以理解，指定服务器集群10是受到服务端20监控的服务器集群。需要说明的是，图1仅仅是一种示例。

服务端10可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)以及大数据和人工智能平台等基础云计算服务的云服务器。其中服务器可以包括有网络通信单元、处理器和存储器等等。服务端可以为对应的客户端提供后台服务。

本申请实施例提供的故障排查方法可以基于云技术实现，云技术(Cloudtechnology)是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。

其中，云计算(cloud computing)是一种计算模式，它将计算任务分布在大量计算机构成的资源池上，使各种应用系统能够根据需要获取计算力、存储空间和信息服务。提供资源的网络被称为“云”。“云”中的资源在使用者看来是可以无限扩展的，并且可以随时获取，按需使用，随时扩展，按使用付费。作为云计算的基础能力提供商，会建立云计算资源池(简称云平台，一般称为IaaS(Infrastructure as a Service，基础设施即服务)平台，在资源池中部署多种类型的虚拟资源，供外部客户选择使用。云计算资源池中主要包括：计算设备(为虚拟化机器，包含操作系统)、存储设备、网络设备。按照逻辑功能划分,在IaaS(Infrastructure as a Service，基础设施即服务)层上可以部署PaaS(Platform as aService,平台即服务)层，PaaS层之上再部署SaaS(Software as a Service,软件即服务)层，也可以直接将SaaS部署在IaaS上。PaaS为软件运行的平台，如数据库、web容器等。SaaS为各式各样的业务软件，如web门户网站、短信群发器等。一般来说，SaaS和PaaS相对于IaaS是上层。

在实际应用中，指定服务器集群10可以由多个物理服务器构成，这些物理服务器可以位于不同的部署单元。部署单元可以是机架、机房等。示例性的，指定服务器集群包括服务器集群a-c，每个服务器集群包括多个物理服务器。服务器集群a位于部署单元a，服务器集群b位于部署单元b以及服务器集群c位于部署单元c。服务端20可以包括带外管理系统、服务器硬件故障诊断系统、服务器故障处理系统以及线上诊断系统。

以下介绍本申请一种故障排查方法的具体实施例，图2是本申请实施例提供的一种故障排查方法的流程示意图，本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。具体的如图2所示，所述方法可以包括：

S201：响应于针对指定服务器集群的温度告警日志，确定所述温度告警日志所指示的目标部件以及目标服务器；其中，所述目标部件为所述目标服务器中出现温度告警的服务器部件，所述目标服务器为所述指定服务器集群中的任一服务器；

在本申请实施例中，服务端接收到针对指定服务器集群的温度告警日志，服务端确定温度告警日志所指示的目标部件以及目标服务器。温度告警日志说明指定服务器集群中某服务器中的某服务器部件出现了温度告警，也即某服务器部件的实时温度高于其对应的温度阈值。温度告警日志是服务器维度的日志信息，温度告警日志中除了出现温度告警的服务器部件的实时信息，还包括同一服务器中其他服务器部件的实时信息。服务端基于温度告警日志确定出现温度告警的目标部件，以及该目标部件所属的目标服务器。

服务器中的服务器部件可以包括CPU(中央处理器)、风扇组件、进风口组件、出风口组件、内存、RAID卡(磁盘阵列)、PCH(集成南桥)等。相应的，每个服务器部件所对应的温度阈值也是不同的。对于同一服务器部件，也可以设置不同的温度指标，以及与之对应的温度阈值。

可以理解，对指定服务器集群中服务器的服务器部件的温度监控是实时的，这些实时信息可以基于服务器维度生成对应的温度监控日志(可参见图5)，可以对温度监控日志进行存储以供参考。而将其中存在实时温度高于对应的温度阈值的温度监控日志作为温度告警日志，温度告警日志可以视作触发故障排查的数据源。温度告警日志的设置，可以为故障排查提供有效的依据，可以缩小进行故障排查的数据范围。

在一示例性的实施方式中，在所述确定所述温度告警日志所指示的目标部件以及所述目标服务器之前，所述方法还包括：接收所述温度告警日志；其中，所述温度告警日志为基于简单网络管理协议陷阱格式(SNMPTRAP)的日志；

相应的，所述确定所述温度告警日志所指示的目标部件以及所述目标服务器，包括下述步骤：1)解析所述温度告警报文得到指示服务器标识的第一字段和指示部件温度告警的第二字段；2.1)基于所述第一字段确定所述目标服务器；2.2)将所述第二字段与指示部件温度告警的参考字段集合进行匹配，以及当所述参考字段集合中存在与所述第二字段相匹配的参考字段时，基于所述参考字段所指示的部件确定所述目标部件。

出现温度告警的服务器部件所属服务器的BMC，基于该服务器中服务器部件的实时信息，将温度告警日志上报至服务端。温度告警日志是基于简单网络管理协议，由管理器(代理)上报的陷阱报文，用于表明设备发生故障的主动通知。

温度告警日志是服务器维度的日志信息，由于不同服务器可能存在机型、提供厂商等的差异，而温度告警日志源于原始日志，因此即便温度告警日志是SNMPTRAP这种格式的日志，不同机型、不同提供厂商也会导致温度告警日志存在差异。

服务端对温度告警日志进行解析的过程可以看作一个得到标准输出的过程。该过程中，可以借助预设映射表，对温度告警日志中因不同机型、不同提供厂商引导设置的个性化字段作标准化处理。比如，指示厂商A的温度告警日志中，对于温度的单位采用华氏温标，经标准化处理转换为摄氏温标。指示机型B的温度告警日志中，将指示服务器标识的字段置后，经标准化处理该字段前置。经标准化处理，可以提高定位相关字段的效率。

经解析得到得到指示服务器标识的第一字段和指示部件温度告警的第二字段，从而基于第一字段确定目标服务器以及基于第二字段确定目标部件。具体的，可以将第二字段与指示部件温度告警的参考字段集合进行匹配；当参考字段集合中存在与第二字段相匹配的参考字段时，基于参考字段所指示的部件确定目标部件。参考字段集合可以包括指示CPU的字段、指示进风口组件的字段、指示出风口组件的字段、指示内存的字段等。若第二字段与其中指示内存的字段的匹配，那么基于该指示内存的字段可以确定作为目标部件的内存。

在实际应用中，由服务端中的带外管理系统接收温度告警日志并进行日志解析和字段匹配。参见图6、7，由带外管理系统的接入层来实现对现网原始SNMPTRAP日志的接收。指定服务器集群可以有上百万台服务器，其中每个服务器集群每天都会产生大量的日志信息，为了实现对指定服务器集群中所有服务器产生的SNMPTRAP日志进行接收，可以为各个服务器集群部署相应的接入层设备，以便对大量的原始日志进行接收和初步处理。由带外管理系统的解析层来实现对原始SNMPTRAP日志的解析以提高后续对其中数据进行应用的效率。由带外管理系统的告警匹配层来实现对部件温度告警数据的匹配，经过接入层的接收和解析层的解析后，已经具备了对原始SNMPTRAP日志中数据作进一步处理条件，由此可以得知哪台机器发生了什么类型的故障。

在一示例性的实施方式中，在所述确定所述温度告警日志所指示的目标部件以及所述目标服务器之后，所述方法还包括下述步骤：1)基于日志接收时间和预设时间间隔确定指令下发时间；其中，所述日志接收时间指示接收到所述温度告警日志的时间；2.1)在所述指令下发时间，发送用于获取所述第一类传感器信息和所述第二类传感器信息的第一指令至传感器信息管理模块；其中，所述传感器信息管理模块用于管理针对所述目标服务器中服务器部件进行监控所获取的传感器信息；2.2)在所述指令下发时间，发送用于获取所述温度信息的第二指令至所述所属部署单元对应的温度管理系统。

通过预设时间间隔，在获取相关传感器信息和温度信息和当前所在的日志接收时间之间形成了一个缓冲时间，利用该缓冲时间可以使得所需要获得的相关传感器信息和温度信息收敛，使得所需要获得的相关传感器信息和温度信息能作为较准确的表征数据。这样可以为后续进行故障排查提供更准确有效的参考数据，从而保证故障排查的准确性。

示例性的，若日志接收时间为17:00，预设时间间隔为5分钟，那么指令下发时间为17:05。在该指定下发时间，向传感器信息管理模块发送用于获取第一类传感器信息和第二类传感器信息的第一指令，以及将温度管理系统发送用于获取温度信息的第二指令。其中，有关第一类传感器信息、第二类传感器信息以及温度信息的内容，将在下述步骤S202和S203中进行介绍。在实际应用中，参见图6，传感器信息管理模块可以是目标服务器的BMC。第一指令和第二指令的形式可以是IPMI命令。当然，预设时间间隔可以根据需要灵活设置。

进一步的，可以在指令下发时间，获取监控日志(比如温度监控日志)，可以是目标服务器的监控日志，也可以是目标服务器所属部署单元中所有服务器的监控日志。通过监控日志可以提高后续进行故障排查的排查范围，以避免因信息遗漏影响故障排查结果的准确度。

S202：获取所述目标部件的第一类传感器信息以及可疑部件的第二类传感器信息；其中，所述可疑部件为所述目标服务器中与引发所述目标部件出现温度告警具有疑似关联关系的服务器部件；

在本申请实施例中，服务端获取目标部件的第一类传感器信息以及可疑部件的第二类传感器信息。目标部件出现温度告警的原因，可能是自身问题引起的，可能是其他服务器部件的问题引起的，可能是环境温度过高引起的，可能是温度告警日志中目标部件的实时温度是失准数据(比如对目标部件进行温度检测的部件有故障)引起的，可能是温度阈值设置过小引起的等等。可疑部件则对应上述“其他服务器部件的问题”，它是目标服务器中与引发目标部件出现温度告警具有疑似关联关系的服务器部件。

第一类传感器信息是利用相关传感器对目标部件进行检测获得的SDR，第二类传感器信息是利用相关传感器对可疑部件进行检测获得的SDR。由于相关传感器对目标部件信息检测的检测项可能不止一个，第一类传感器信息可以抽取所有SDR中指示温度类检测项的SDR。第二类传感器信息同理。

温度告警日志中除了出现温度告警的服务器部件的实时信息，还包括同一服务器中其他服务器部件的实时信息。温度告警日志，或者说温度监控日志中的服务器部件的实时信息也可以来自相关传感器的SDR。这里获取第一类传感器信息和第二类传感器信息，可以理解为，从温度告警日志中获取第一类传感器信息和第二类传感器信息。先对温度告警日志进行解析，再基于解析得到的指示传感器(Sensor)的字段来确定。此时，第一类传感器信息可以既作为触发普通的温度监控日志转换为温度告警日志的数据源的全部或部分，也可以作为后续进行故障排查的参考数据。结合前述步骤S201中提及的“第一指令”，第一类传感器信息、第二类传感器信息和温度告警日志则指向不同的时间点。

S203：获取所述目标服务器所属部署单元的温度信息；

在本申请实施例中，服务端获取目标服务器所属部署单元的温度信息。这里的所属部署单元可以对应前述步骤S202中提及的“环境温度过高”。该温度信息可以是从所属部署单元对应的温度管理系统获取的，由温度管理系统对所属部署单元进行温度监控。示例性的，参见图6，所属部署单元可以是机房，温度管理系统可以是机房温度告警系统。当机房的实时温度(或者时间窗口的温度统计值)高于其对应的温度阈值时，机房温度告警系统可以发出机房温度告警信号。可以根据机架上各机器的进风口温度以及机房机架上的温度传感器值做一个机房环境温度的综合判断，确认当前机房的环境温度是否在合理范围内。当然，机房温度告警系统所服务的机房可以不只一个。

温度信息的获取时间可以是前述步骤S201中提及的“日志接收时间”，也可以是前述步骤S201中提及的“指令下发时间”。

S204：基于所述第一类传感器信息、所述第二类传感器信息以及所述温度信息，确定针对所述温度告警日志的故障排查结果。

在本申请实施例中，服务端基于第一类传感器信息、第二类传感器信息以及温度信息，确定针对温度告警日志的故障排查结果。通过第一类传感器信息、第二类传感器信息和温度信息，可以在一定程度上确定目标部件出现温度告警的原因是自身问题引起的，还是其他服务器部件的问题引起的，还是环境温度过高引起的，还是由其他问题引起的。

结合前述步骤S202和S203中对于相关传感器信息和温度信息的获取时间，可以分为两种情况：1)在“日志接收时间”获取第一类传感器信息、第二类传感器信息以及温度信息，然后在此基础上进行故障排查；若故障排查的效果不好，再获取一定缓冲时间之后的“第一类传感器信息、第二类传感器信息以及温度信息”继续排查故障；2)在“指定下发时间”获取第一类传感器信息、第二类传感器信息以及温度信息，然后在此基础上进行故障排查。

下面将对这里的情况2)进行介绍：

参见图3，所述基于所述第一类传感器信息、所述第二类传感器信息以及所述温度信息，确定针对所述温度告警日志的故障排查结果，包括：

S301：基于所述第一类传感器信息和第一预设数量阈值的对比结果，确定针对所述温度告警日志的验证结果；

S302：当所述验证结果指示所述目标部件出现温度告警时，基于所述第二类传感器信息和第二预设数量阈值的对比结果，以及所述温度信息和第三预设数量阈值的对比结果，确定是否存在引发所述目标部件出现温度告警的可疑故障原因；

S303：当存在可疑故障原因时，获取针对所述可疑故障原因进行排查处理得到的第一类故障排查结果；

S304：当不存在可疑故障原因时，获取针对所述目标部件进行排查处理得到的第二类故障排查结果。

这里的第一类传感器信息、第二类传感器信息以及温度信息都是一定缓冲时间之后获取到的。通过第一类传感器信息和第一预设数量阈值的对比结果，可以得到针对温度告警日志的验证结果。若第一类传感器信息指示的温度值高于第一预设数量阈值，说明在一定缓冲时间之后目标部件仍然出现了温度告警，之前目标部件出现温度告警的原因是温度抖动或者误报引起的概率较低，因此需要进一步排查故障。

基于第二类传感器信息和第二预设数量阈值的对比结果，可以确定可疑部件是否出现故障。具体可以通过第二类传感器信息指示的数值与第二预设数量阈值进行对比得到。基于温度信息和第三预设数量阈值的对比结果，可以确定环境温度是否异常。具体可以通过温度信息指示的数值与第三预设数量阈值进行对比得到。而可疑部件出现故障和/或环境温度异常可以作为可疑故障原因。

在存在可疑故障原因时，需要基于可疑部件和/或环境温度进行排查，从而得到第一类故障排查结果。比如，替换相关可疑部件，再查看目标部件是否不再出现温度告警；将环境温度调整至正常值区间，再查看目标部件是否不再出现温度告警。在不存在可疑故障原因时，需要基于目标部件进行排查，从而得到第二类故障排查结果。比如，将旧的目标部件替换为新的目标部件，再查看新的目标部件是否出现温度告警。

上述实施例提供了一套程序化的故障排查方案，基于统一化的逻辑进行分析定位，可以有效提高故障排查的效率。可以将上述“确定针对温度告警日志的验证结果”-“确定可疑故障原因”-“排查处理”作为一逻辑主线，在此基础上灵活的引入逻辑支线，从而保证了逻辑主线的可扩展性和适应性。

1)这里将介绍一条逻辑支线：

如图4所示，在所述基于所述第一类传感器信息和第一预设数量阈值的对比结果，确定针对所述温度告警日志的验证结果之后，所述方法还包括：

S401：当所述验证结果指示所述目标部件未出现温度告警时，更新指示所述目标服务器的误报次数；

S402：确定所述第一类传感器信息对应的监控时间，以及所述监控时间所属的监控周期；

S403：当所述监控周期内对应的指示所述目标服务器的误报次数大于第四预设数量阈值时，触发将所述第二类传感器信息和所述第二预设数量阈值进行对比以及将所述温度信息和所述第三预设数量阈值进行对比的步骤。

若第一类传感器信息指示的温度值不高于第一预设数量阈值，说明在一定缓冲时间之后目标部件不再出现温度告警，之前目标部件出现温度告警的原因可能是温度抖动或者误报引起的。但是若监控周期内常出现这类误差，也说明需要进一步排查故障。对误差的容忍控制在一定次数内，兼顾指定服务器集群的安全以及进行故障排查的合理资源利用。

若监控周期为一天，第四预设数量阈值为2，当一天内指向目标服务器的误报或温度抖动次数小于等于2次时，可以只对此进行记录，然后结束故障排查流程。而当一天内指向目标服务器的误报或温度抖动次数大于2次(即3次及以上)时，则需要进一步故障排查，可以参见图9中的“节点3”——》“节点4”。

2)这里将对步骤S302作进一步解释：

在一示例性的实施方式中，所述可疑部件可以包括进风口组件和风扇组件，相应的，所述第二类传感器信息包括所述进风口组件的温度值和所述风扇组件的转速值，所述第二预设数量阈值包括所述进风口组件的温度阈值和所述风扇组件的转速阈值。那么步骤S302可以存在下述确定出可疑故障原因的逻辑：

A)当所述温度值小于等于所述温度阈值时，判断所述转速值是否小于所述转速阈值；若小于，将所述风扇组件出现故障作为引发所述目标部件出现温度告警的第一类可疑故障原因；

参见图9中的“节点4”——》“节点6”——》“节点7”，温度值小于等于温度阈值，可以说明进风口温度正常，那么进风口组件出现故障的概率较低。在进风口温度正常的情况下，很可能是目标服务器的散热问题导致目标部件出现温度告警，因而继续比对提供散热功能的风扇组件的相关参数是否正常。转速值小于转速阈值，可以说明风扇组件出现故障的概率较高。那么可以将风扇组件出现故障作为引发目标部件出现温度告警的第一类可疑故障原因。

B)当所述温度值大于所述温度阈值时，基于所述温度信息和第三预设数量阈值的对比结果确定环境温度是否正常；若正常，判断所述转速值是否小于所述转速阈值；若小于，将所述风扇组件出现故障作为引发所述目标部件出现温度告警的第一类可疑故障原因；

参见图9中的“节点4”——》“节点5”——》“节点6”——》“节点7”，温度值大于温度阈值，可以说明进风口温度异常，而引起进风口温度异常的原因常是环温，因而需要确认环温是否正常。当环温正常时，说明提供散热功能的风扇组件的相关参数可能异常，那么对其进行比对。转速值小于转速阈值，可以说明风扇组件出现故障的概率较高。那么可以将风扇组件出现故障作为引发目标部件出现温度告警的第一类可疑故障原因。

需要说明的是，A)和B)中对于“转速值小于转速阈值，可以说明风扇组件出现故障的概率较高”，还可以引入出现故障的风扇个数作为判断指标。比如，风扇组件包括6个风扇，若只有1个风扇的转速值低于转速阈值，那么考虑到N+1冗余(也就是说理论上1个风扇的转速值低于转速阈值不影响风扇组件的散热)，因此不认为风扇组件出现故障。

C)当所述温度值大于所述温度阈值时，基于所述温度信息和第三预设数量阈值的对比结果确定环境温度是否正常；若不正常，将环境温度异常作为引发所述目标部件出现温度告警的第二类可疑故障原因。

参见图9中的“节点4”——》“节点5”，温度值大于温度阈值，可以说明进风口温度异常，而引起进风口温度异常的原因常是环温，因而需要确认环温是否正常。当环温异常时，可以将环境温度异常作为引发目标部件出现温度告警的第二类可疑故障原因。

上述确定出可疑故障原因的逻辑中，将针对进风口组件的温度值、风扇组件的转速值以及温度信息的比对作了融合，为可疑故障原因的确定提供了更充分的逻辑佐证，保证了以此为基础进行排查处理的针对性。

进一步的，在所述获取针对所述可疑故障原因进行排查处理得到的第一类故障排查结果之前，所述方法还包括下述步骤：首先，生成针对所述第一类可疑故障原因对应的工单信息；然后，将所述工单信息发送给运维节点，以使所述运维节点根据所述工单信息获取目标备件以及利用所述目标备件对所述风扇组件进行故障排查处理。

在存在第一类可疑故障原因时，需要基于作为可疑部件的风扇组件进行排查，从而得到第一类故障排查结果。比如，替换风扇组件，再查看目标部件是否不再出现温度告警。工单信息描述了需要对风扇组件或者风扇组件中某几个风扇进行替换的内容。运维节点接收到工单信息，然后获取用于新的风扇组件或者新的几个风扇作为目标备件，从而将目标备件替换进目标服务器中取代原来的相关部件。

在实际应用中，可以由服务端的服务器故障处理系统来生成、发送工单信息。参见图6、8，其中硬件替换工单创建指示：明确是哪个部件需要替换后就会创建相应的部件替换工单。整机操作授权指示：不管替换该部件是否需要涉及停机，都是需要跟业务申请操作权限。现场处理工单&备件出库工单指示：当通过业务授权后会生成一个现场处理工单和一个备件出库工单，一个是给现场工程师的操作授权，另外一个可用于快速申请到备件。运维工程师替换指示：机房现场的工作人员对该部件进行替换操作。结单验收指示：针对不同的故障类型会有不同的检测逻辑，主要是机器可用性和部件数量等，通过则直接结束，不通过则打回重修。

参见图9中的“节点8”——》“节点11”——》“节点12”，当验证结果指示目标部件出现温度告警，且一定缓冲时间之后没有接收到指示其他部件的温度告警日志时，判定出现温度告警的部件数量为1，那么需要基于目标部件进行排查，比如将旧的目标部件替换为新的目标部件，再查看新的目标部件是否出现温度告警。参见图9中的“节点8”——》“节点10”，当验证结果指示目标部件出现温度告警，且一定缓冲时间之后接收到了指示其他部件的温度告警日志时，判定出现温度告警的部件数量大于1。这里涉及的部件替换，可以参考上述有关“工单信息”的内容，不再赘述。

此外，参见图9中的“节点8”——》“节点10”，当所述第一类故障排查结果指示不存在所述第一类可疑故障原因时，生成软件故障排查指令；然后，将所述软件故障排查指令发送给研发节点，以使所述研发节点基于所述软件故障排查指令对所述指定服务器集群进行软件维度的故障排查处理。

替换风扇组件之后，查看到目标部件仍然出现了温度告警，说明可以将第一类可疑故障原因从“目标部件出现温度告警的原因”中排除。综合从硬件层面进行故障排查的逻辑，可以考虑从软件层面进行故障排查。服务端生成、发送软件故障排查指令，以触发研发节点对指定服务器集群进行软件维度的故障排查处理。

在实际应用中，前述步骤S202-S204的执行主体可以是服务端中的服务器硬件故障诊断系统。参见图9，其中1)节点1：一方面实时采集目标服务器的相关SDR，SDR主要用于进风口温度和风扇转速判断。一方面在一定缓冲时间之后接收其他SNMPTRAP日志以及机房温度信息；2)节点2：在一定缓冲时间之后由节点1自动流转自此；3)节点1、节点11和节点13可以适用同一套处理逻辑，通过调用服务器故障处理系统进行部件替换。节点7主要指风扇替换，节点11主要指目标部件替换，节点13主要指主板替换；4)节点9和节点12可以适用同一套处理逻辑，触发目标服务器的相关SDR的采集，基于相关SDR确定目标部件的实时温度是否恢复正常，如果恢复则直接结束流程，不恢复则节点9到节点8、节点12到节点13；5)节点10：由于这个时候已经排除环温和散热的影响，如果出现温度告警的部件数量大于1则应属于是疑难问题，那么到节点10的线上诊断流程。该流程用到线上诊断系统，该系统的主要功能是将疑难问题通过工单的方式快速触达服务器研发，在提高诊断效率的同时也丰富了研发的案例库，能尽量从设计端规避该疑难问题的出现或者提高疑难问题的自动化诊断效率。当服务器研发返回的结果是需要替换部件，则节点会流转到节点11。如果不涉及硬件替换，只是更新FW(FirmWare，固件)或其他排查测试，则结束该主流程，后续其他流程跟进。本申请提供的故障排查方案针对部件温度告警诊断效率提升，整体平均诊断时间从24小时缩短到1小时左右，其中平均时间涉及诊断替换等过程。在扩大监控范围的情况下还可以节省专有人力。由被动响应变成了主动监控，减少了业务投诉。另外，本申请提供的故障排查方案也可以通过实时采集的SDR进行温度告警。

由以上本申请实施例提供的技术方案可见，本申请实施例中通过确定温度告警日志所指示的目标部件以及目标服务器，然后获取目标部件的第一类传感器信息、可疑部件的第二类传感器信息以及目标服务器所属部署单元的温度信息，从而基于获取到的信息确定针对该温度告警日志的故障排查结果。其中，目标部件为目标服务器中出现温度告警的服务器部件，可疑部件为目标服务器中与引发目标部件出现温度告警具有疑似关联关系的服务器部件。本申请提供了一套程序化的故障排查方案，基于该方案可以规避个人感性判断的干扰，减少漏判和误判的出现，从而能够实现准确的故障排查。人工介入的减少，整个故障排查流程的自动化，且具备并发处理能力，可以提高故障排查效率、节省人力成本开销。

本申请实施例还提供了一种故障排查装置，如图10所示，所述故障排查装置1000包括：

第一确定模块1001：用于响应于针对指定服务器集群的温度告警日志，确定所述温度告警日志所指示的目标部件以及目标服务器；其中，所述目标部件为所述目标服务器中出现温度告警的服务器部件，所述目标服务器为所述指定服务器集群中的任一服务器；

第一获取模块1002：用于获取所述目标部件的第一类传感器信息以及可疑部件的第二类传感器信息；其中，所述可疑部件为所述目标服务器中与引发所述目标部件出现温度告警具有疑似关联关系的服务器部件；

第二获取模块1003：用于获取所述目标服务器所属部署单元的温度信息；

第二确定模块1004：用于基于所述第一类传感器信息、所述第二类传感器信息以及所述温度信息，确定针对所述温度告警日志的故障排查结果。

需要说明的，所述装置实施例中的装置与方法实施例基于同样的发明构思。

本申请实施例提供了一种电子设备，该电子设备包括处理器和存储器，该存储器中存储有至少一条指令或至少一段程序，该至少一条指令或该至少一段程序由该处理器加载并执行以实现如上述方法实施例所提供的故障排查方法。

进一步地，图11示出了一种用于实现本申请实施例所提供的故障排查方法的电子设备的硬件结构示意图，所述电子设备可以参与构成或包含本申请实施例所提供的故障排查装置。如图11所示，电子设备110可以包括一个或多个(图中采用1102a、1102b，……，1102n来示出)处理器1102(处理器1102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器1104、以及用于通信功能的传输装置1106。除此以外，还可以包括：显示器、输入/输出接口(I/O接口)、通用串行总线(USB)端口(可以作为I/O接口的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解，图11所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，电子设备110还可包括比图11中所示更多或者更少的组件，或者具有与图11所示不同的配置。

应当注意到的是上述一个或多个处理器1102和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外，数据处理电路可为单个独立的处理模块，或全部或部分的结合到电子设备110(或移动设备)中的其他元件中的任意一个内。如本申请实施例中所涉及到的，该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。

存储器1104可用于存储应用软件的软件程序以及模块，如本申请实施例中所述的故障排查方法对应的程序指令/数据存储装置，处理器1102通过运行存储在存储器114内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的一种故障排查方法。存储器1104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器1104可进一步包括相对于处理器1102远程设置的存储器，这些远程存储器可以通过网络连接至电子设备110。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置1106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括电子设备110的通信供应商提供的无线网络。在一个实例中，传输装置1106包括一个网络适配器(NetworkInterfaceController，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实施例中，传输装置1106可以为射频(RadioFrequency，RF)模块，其用于通过无线方式与互联网进行通讯。

显示器可以例如触摸屏式的液晶显示器(LCD)，该液晶显示器可使得用户能够与电子设备110(或移动设备)的用户界面进行交互。

本申请的实施例还提供了一种计算机可读存储介质，所述存储介质可设置于电子设备之中以保存用于实现方法实施例中一种故障排查方法相关的至少一条指令或至少一段程序，该至少一条指令或该至少一段程序由该处理器加载并执行以实现上述方法实施例提供的故障排查方法。

可选地，在本实施例中，上述存储介质可以位于计算机网络的多个网络服务器中的至少一个网络服务器。可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

需要说明的是：上述本申请实施例先后顺序仅仅为了描述，不代表实施例的优劣。且上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置和电子设备实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本申请的较佳实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种故障排查方法，其特征在于，所述方法包括：

响应于针对指定服务器集群的温度告警日志，确定所述温度告警日志所指示的目标部件以及目标服务器；其中，所述目标部件为所述目标服务器中出现温度告警的服务器部件，所述目标服务器为所述指定服务器集群中的任一服务器；

获取所述目标部件的第一类传感器信息以及可疑部件的第二类传感器信息；其中，所述可疑部件为所述目标服务器中与引发所述目标部件出现温度告警具有疑似关联关系的服务器部件；

获取所述目标服务器所属部署单元的温度信息；

基于所述第一类传感器信息、所述第二类传感器信息以及所述温度信息，确定针对所述温度告警日志的故障排查结果。

2.根据权利要求1所述的方法，其特征在于，在所述确定所述温度告警日志所指示的目标部件以及所述目标服务器之后，所述方法还包括：

基于日志接收时间和预设时间间隔确定指令下发时间；其中，所述日志接收时间指示接收到所述温度告警日志的时间；

在所述指令下发时间，发送用于获取所述第一类传感器信息和所述第二类传感器信息的第一指令至传感器信息管理模块；其中，所述传感器信息管理模块用于管理针对所述目标服务器中服务器部件进行监控所获取的传感器信息；

在所述指令下发时间，发送用于获取所述温度信息的第二指令至所述所属部署单元对应的温度管理系统。

3.根据权利要求1或2任一项所述的方法，其特征在于：

在所述确定所述温度告警日志所指示的目标部件以及所述目标服务器之前，所述方法还包括：

接收所述温度告警日志；其中，所述温度告警日志为基于简单网络管理协议陷阱格式的日志；

所述确定所述温度告警日志所指示的目标部件以及所述目标服务器，包括：

解析所述温度告警报文得到指示服务器标识的第一字段和指示部件温度告警的第二字段；

基于所述第一字段确定所述目标服务器；

将所述第二字段与指示部件温度告警的参考字段集合进行匹配，以及当所述参考字段集合中存在与所述第二字段相匹配的参考字段时，基于所述参考字段所指示的部件确定所述目标部件。

4.根据权利要求2所述的方法，其特征在于，所述基于所述第一类传感器信息、所述第二类传感器信息以及所述温度信息，确定针对所述温度告警日志的故障排查结果，包括：

基于所述第一类传感器信息和第一预设数量阈值的对比结果，确定针对所述温度告警日志的验证结果；

当所述验证结果指示所述目标部件出现温度告警时，基于所述第二类传感器信息和第二预设数量阈值的对比结果，以及所述温度信息和第三预设数量阈值的对比结果，确定是否存在引发所述目标部件出现温度告警的可疑故障原因；

当存在可疑故障原因时，获取针对所述可疑故障原因进行排查处理得到的第一类故障排查结果；

当不存在可疑故障原因时，获取针对所述目标部件进行排查处理得到的第二类故障排查结果。

5.根据权利要求4项所述的方法，其特征在于，在所述基于所述第一类传感器信息和第一预设数量阈值的对比结果，确定针对所述温度告警日志的验证结果之后，所述方法还包括：

当所述验证结果指示所述目标部件未出现温度告警时，更新指示所述目标服务器的误报次数；

确定所述第一类传感器信息对应的监控时间，以及所述监控时间所属的监控周期；

当所述监控周期内对应的指示所述目标服务器的误报次数大于第四预设数量阈值时，触发将所述第二类传感器信息和所述第二预设数量阈值进行对比以及将所述温度信息和所述第三预设数量阈值进行对比的步骤。

6.根据权利要求4所述的方法，其特征在于，所述可疑部件包括进风口组件和风扇组件，所述第二类传感器信息包括所述进风口组件的温度值和所述风扇组件的转速值，所述第二预设数量阈值包括所述进风口组件的温度阈值和所述风扇组件的转速阈值；

所述基于所述第二类传感器信息和第二预设数量阈值的对比结果，以及所述温度信息和第三预设数量阈值的对比结果，确定是否存在引发所述目标部件出现温度告警的可疑故障原因，包括：

当所述温度值小于等于所述温度阈值时，判断所述转速值是否小于所述转速阈值；若小于，将所述风扇组件出现故障作为引发所述目标部件出现温度告警的第一类可疑故障原因；

当所述温度值大于所述温度阈值时，基于所述温度信息和第三预设数量阈值的对比结果确定环境温度是否正常；若正常，判断所述转速值是否小于所述转速阈值；若小于，将所述风扇组件出现故障作为引发所述目标部件出现温度告警的第一类可疑故障原因；

当所述温度值大于所述温度阈值时，基于所述温度信息和第三预设数量阈值的对比结果确定环境温度是否正常；若不正常，将环境温度异常作为引发所述目标部件出现温度告警的第二类可疑故障原因。

7.根据权利要求6所述的方法，其特征在于，在所述获取针对所述可疑故障原因进行排查处理得到的第一类故障排查结果之前，所述方法还包括：

生成针对所述第一类可疑故障原因对应的工单信息；

将所述工单信息发送给运维节点，以使所述运维节点根据所述工单信息获取目标备件以及利用所述目标备件对所述风扇组件进行故障排查处理。

8.根据权利要求7所述的方法，其特征在于，所述方法还包括：

当所述第一类故障排查结果指示不存在所述第一类可疑故障原因时，生成软件故障排查指令；

将所述软件故障排查指令发送给研发节点，以使所述研发节点基于所述软件故障排查指令对所述指定服务器集群进行软件维度的故障排查处理。

9.一种故障排查装置，其特征在于，所述装置包括：

第一确定模块：用于响应于针对指定服务器集群的温度告警日志，确定所述温度告警日志所指示的目标部件以及目标服务器；其中，所述目标部件为所述目标服务器中出现温度告警的服务器部件，所述目标服务器为所述指定服务器集群中的任一服务器；

第一获取模块：用于获取所述目标部件的第一类传感器信息以及可疑部件的第二类传感器信息；其中，所述可疑部件为所述目标服务器中与引发所述目标部件出现温度告警具有疑似关联关系的服务器部件；

第二获取模块：用于获取所述目标服务器所属部署单元的温度信息；

第二确定模块：用于基于所述第一类传感器信息、所述第二类传感器信息以及所述温度信息，确定针对所述温度告警日志的故障排查结果。

10.一种计算机可读存储介质，所述存储介质中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由处理器加载并执行以实现如权利要求1-8任一所述的故障排查方法。

Images