CN108289034B - 一种故障发现方法和装置 - Google Patents
一种故障发现方法和装置 Download PDFInfo
- Publication number
- CN108289034B CN108289034B CN201710474280.3A CN201710474280A CN108289034B CN 108289034 B CN108289034 B CN 108289034B CN 201710474280 A CN201710474280 A CN 201710474280A CN 108289034 B CN108289034 B CN 108289034B
- Authority
- CN
- China
- Prior art keywords
- host
- fault
- node
- fail
- configuration file
- 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.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0677—Localisation of faults
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Debugging And Monitoring (AREA)
Abstract
本申请提供一种故障发现方法和装置,该方法包括:获取从节点对应的主机上部署的服务组件的服务名称和组件名称;从主节点上配置的多个配置文件中确定包括所述服务名称和所述组件名称的目标配置文件;将所述目标配置文件中包括的故障类型发送给所述从节点,以使所述从节点根据所述故障类型对应的故障发现策略,对对应的主机进行故障发现。通过本申请的技术方案,可以自动发现主机的故障,能够高效便捷地发现主机的故障,实现大数据集群中主机故障的自动发现,能够解决大数据集群中监控运维复杂度高、故障发现难度大等问题。
Description
技术领域
本申请涉及通信技术领域,尤其涉及一种故障发现方法和装置。
背景技术
大数据又称为巨量资料,具有如下特征:数据体量大,如超过10TB规模的数据量,通常是大型数据集;数据类别大,数据来自多种数据源,种类和格式丰富,如结构化数据、半结构化数据和非结构化数据等;数据处理速度快,在数据量庞大的情况下,能够做到数据实时处理;数据真实性高,随着社交数据、企业内容、交易、应用数据的兴起,需要有效信息确保数据的真实性和安全性。
随着大数据时代的到来,大数据在给用户带来方便的同时,也对运维管理提出了新的挑战。例如,为了实现大数据的相关功能,需要在大数据集群中部署大量主机,如何高效、便捷地发现这些主机的故障,就成为运维管理的难题。
发明内容
本申请提供一种故障发现方法,应用于大数据集群的主节点,所述大数据集群还包括从节点,所述从节点部署在大数据集群中的主机上,该方法包括:
获取所述从节点对应的主机上部署的服务组件的服务名称和组件名称;
从所述主节点上配置的多个配置文件中确定包括所述服务名称和所述组件名称的目标配置文件;
将所述目标配置文件中包括的故障类型发送给所述从节点,以使所述从节点根据所述故障类型对应的故障发现策略,对对应的主机进行故障发现。
本申请提供一种故障发现装置,应用于大数据集群的主节点,所述大数据集群还包括从节点,所述从节点部署在大数据集群中的主机上,该装置包括:
获取模块,用于获取所述从节点对应的主机上部署的服务组件的服务名称和组件名称,并从所述主节点上配置的多个配置文件中确定包括所述服务名称和所述组件名称的目标配置文件;
发送模块,用于将所述目标配置文件中包括的故障类型发送给所述从节点,以使所述从节点根据所述故障类型对应的故障发现策略,对对应的主机进行故障发现。
基于上述技术方案,本申请实施例中,可以自动发现主机的故障,能够高效、便捷地发现主机的故障,从而实现大数据集群中主机故障的自动发现,能够解决大数据集群中监控运维复杂度高、故障发现难度大等问题。
附图说明
为了更加清楚地说明本申请实施例或者现有技术中的技术方案,下面将对本申请实施例或者现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请中记载的一些实施例,对于本领域普通技术人员来讲,还可以根据本申请实施例的这些附图获得其他的附图。
图1是本申请一种实施方式中的应用场景示意图;
图2是本申请一种实施方式中的故障发现方法的流程图;
图3是本申请一种实施方式中的故障发现装置的结构图;
图4是本申请一种实施方式中的主节点的硬件结构图。
具体实施方式
在本申请实施例使用的术语仅仅是出于描述特定实施例的目的,而非限制本申请。本申请和权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其它含义。还应当理解,本文中使用的术语“和/或”是指包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本申请实施例可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本申请范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,此外,所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
本申请实施例中提出了一种故障发现方法,该方法可以应用于大数据集群(也可以称为大数据系统),该大数据集群可以包括多个用于处理大数据业务的主机。其中,每个主机会部署服务组件,并通过服务组件处理大数据业务。
参见图1所示,为本申请实施例的应用场景示意图,大数据集群包括主机11、主机12和主机13,实际应用中的主机数量会更多。此外,每个主机可以部署用于处理大数据业务的服务组件,不同主机的服务组件可以相同或者不同。
例如,主机11部署HDFS(Hadoop Distributed File System,Hadoop分布式文件系统)服务的NameNode(名字节点)组件,基于此NameNode组件,主机11可以实现如下大数据业务:管理数据块映射,处理客户端的读写请求,配置副本策略,管理HDFS名称空间等。又例如,主机12部署HDFS服务的DataNode(数据节点)组件,基于此DataNode组件,主机12可以实现如下大数据业务:存储客户端的数据块,执行数据块读写操作,定期向NameNode发送心跳信息。
当然,上述过程只是给出了服务组件的几个示例,实际应用中并不局限于此,如主机可以部署MapReduce(映射归约)服务的拆分组件、排序组件、组合组件等,部署YARN(YetAnother Resource Negotiator,另一种资源协调者)服务的资源管理器组件、应用程序管理组件等,对此服务组件不做限制。
本申请实施例中,在大数据集群的每个主机上可以部署从节点,主节点也可以部署在任意一个主机上,或者主节点也可以单独部署。此外,主节点和从节点之间通过心跳机制进行通信,以使从节点对主机进行故障发现与故障恢复。
本申请实施例中,主节点可以配置多个配置文件,且每个配置文件均可以包括但不限于以下内容之一或者任意组合:标识(id)、文件名称(name)、描述信息(label)、集群名称(cluster_name)、服务名称(service_name)、组件名称(component_name)、故障类型(source)、告警方式(output)等。
其中,标识(id)可以是配置文件的唯一标识,例如,主节点可以包括2个配置文件,第一个配置文件的标识为1,且后续可以将该配置文件称为配置文件1,第二个配置文件的标识为2,且后续可以将该配置文件称为配置文件2。
其中,文件名称(name)是配置文件的名称,可以根据实际需要选择。不同配置文件的名称可以相同,也可以不同,而且,配置文件的名称可以是中文,也可以是英文,还可以是其它类型的语言,对此名称的语言不做限制。例如,配置文件1的名称是Failure-finding_A,配置文件1的名称是Failure-finding_B。
其中,描述信息(label)是配置文件的简要说明,可以阐述配置文件的功能、配置文件的生成时间、配置文件的有效期等内容,对此描述信息不做限制。
其中,集群名称(cluster_name)是大数据集群的名称,例如,针对主机11、主机12和主机13组成的这个大数据集群,其集群名称可以是“crs”。
其中,服务名称(service_name)是用于处理大数据业务的服务组件对应的服务名称,如HDFS服务、MapReduce服务、YARN服务等。后续以配置文件1的服务名称是HDFS服务,配置文件2的服务名称是HDFS服务为例。
其中,组件名称(component_name)是用于处理大数据业务的服务组件对应的组件名称,如NameNode组件、DataNode组件、拆分组件、排序组件、组合组件、资源管理器组件、应用程序管理组件等。后续以配置文件1的组件名称是NameNode组件,配置文件2的组件名称是DataNode组件为例。
其中,故障类型(source)可以包括但不限于以下之一或者任意组合:端口类型(PORT)、网络类型(WEB)、性能指标类型(METRICS)、自定义类型(CUSTOM)。进一步的,端口类型表示检测主机的端口是否存在故障,如端口是否DOWN等;网络类型表示检测主机的网络是否存在故障,如是否联网、网络是否可达等;性能指标类型表示检测主机的性能指标是否存在故障,如CPU使用率是否达到阈值,内存使用率是否达到阈值等;自定义类型是允许用户自由定制的故障类型,即用户可以根据实际需要选择需要检测的故障类型。
其中,告警方式(output)可以包括但不限于以下之一或者任意组合:WEB、EMAIL、SNMP(Simple Network Management Protocol,简单网络管理协议)等。
在一个例子中,上述配置文件可以是json(JavaScript Object Notation,JavaScript对象标记语言)格式的文件,也可以是其它格式,对此不做限制。
在一个例子中,主节点可以提供Restful API(Representational StateTransfer Application Programming Interface,表述性状态转移应用程序编程接口),允许第三方在主节点创建配置文件、修改主节点配置文件、删除主节点配置文件。
基于上述应用场景,如图2所示,为本申请实施例的故障发现方法流程图。
步骤201,主节点获取从节点对应的主机上部署的服务组件的服务名称和组件名称。
在一个例子中,从节点可以获取从节点所在主机上部署的服务组件的服务名称和组件名称,并主动将该服务名称和该组件名称发送给主节点,这样,主节点可以获取到该服务名称和该组件名称。在另一个例子中,当主节点需要对主机进行故障发现时,则可以向该主机对应的从节点(也就是说,该从节点位于该主机上)发送请求消息,该请求消息用于请求服务名称和组件名称。而从节点在接收到该请求消息之后,就可以将主机上部署的服务组件的服务名称和组件名称发送给主节点,这样,主节点可以获取到该服务名称和该组件名称。
由于主机11部署HDFS服务的NameNode组件,因此,主机11处理的大数据业务对应的服务名称是HDFS服务,组件名称是NameNode组件,部署在主机11的从节点可以将主机11的服务名称(如HDFS服务)、组件名称(如NameNode组件)发送给主节点,主节点获取到主机11的服务名称是HDFS服务,组件名称是NameNode组件。由于主机12部署HDFS服务的DataNode组件,因此,主机12处理的大数据业务的服务名称是HDFS服务,组件名称是DataNode组件,部署在主机12的从节点可以将主机12的服务名称(如HDFS服务)、组件名称(如DataNode组件)发送给主节点,主节点获取到主机12的服务名称是HDFS服务,组件名称是DataNode组件。
步骤202,主节点从主节点上配置的多个配置文件中确定包括该服务名称和该组件名称的目标配置文件。
在一个例子中,主节点可以通过主机对应的该服务名称、该组件名称查询主节点本地配置的多个配置文件,并从这多个配置文件中确定出包括该服务名称、该组件名称的目标配置文件。
例如,主节点通过主机11对应的HDFS服务、NameNode组件查询本地包括的多个配置文件,可以确定包括HDFS服务、NameNode组件的配置文件1,即配置文件1是目标配置文件。主节点通过主机12对应的HDFS服务、DataNode组件查询本地包括的多个配置文件,可以确定包括HDFS服务、DataNode组件的配置文件2,即配置文件2是目标配置文件。
步骤203,主节点将该目标配置文件中包括的故障类型发送给从节点,以使从节点根据故障类型对应的故障发现策略,对对应的主机进行故障发现。
步骤204,从节点接收主节点发送的目标配置文件包括的故障类型。
例如,主节点可以将配置文件1包括的故障类型发送给主机11对应的从节点,并由该从节点接收配置文件1包括的故障类型。
又例如,主节点可以将配置文件2包括的故障类型发送给主机12对应的从节点,并由该从节点接收配置文件2包括的故障类型。
针对步骤203和步骤204,主节点可以生成故障探查计划1,该故障探查计划1可以携带配置文件1中的故障类型。主节点将故障探查计划1发送给主机11对应的从节点,该从节点在接收到故障探查计划1后,可以从故障探查计划1中解析出该故障类型。其中,故障探查计划1除了携带故障类型,还可以携带配置文件1中的其它内容,如标识、文件名称、描述信息、集群名称、服务名称、组件名称、告警方式等,对此故障探查计划1的内容不做限制。同理,主节点还可以生成故障探查计划2,该故障探查计划2可以携带配置文件2中的故障类型,主节点将故障探查计划2发送给主机12对应的从节点,该从节点在接收到故障探查计划2后,可以从故障探查计划2中解析出该故障类型。
在一个例子中,主节点可以周期性发送故障探查计划1/故障探查计划2,如每10秒发送一次故障探查计划1/故障探查计划2,对此发送周期不做限制。
步骤205,从节点查询与该故障类型对应的故障发现策略。
步骤206,从节点根据该故障发现策略对主机进行故障发现。
在一个例子中,主机11对应的从节点可以配置故障类型与故障发现策略的对应关系,如端口类型与故障发现策略1的对应关系,性能指标类型与故障发现策略2的对应关系。假设从节点获取到的故障类型是端口类型,则可以查询出与端口类型对应的故障发现策略1,并根据故障发现策略1对主机11进行故障发现,即检测主机11的端口是否存在故障,如主机11的端口是否DOWN。
在另一个例子中,主机12对应的从节点可以配置故障类型与故障发现策略的对应关系,如端口类型与故障发现策略1的对应关系,性能指标类型与故障发现策略3(与上述的故障发现策略2不同)的对应关系。假设从节点获取到的故障类型是性能指标类型,则可以查询出与性能指标类型对应的故障发现策略3,并根据故障发现策略3对主机12进行故障发现,即检测主机12的性能指标是否存在故障,如CPU使用率是否达到阈值,内存使用率是否达到阈值等。
在一个例子中,对于故障发现策略1的内容不做限制,只要从节点根据故障发现策略1能够对主机11进行故障发现、从节点根据故障发现策略1能够对主机12进行故障发现即可。例如,故障发现策略1包括用于检测主机端口是否存在故障的配置信息、检测流程等,基于这些内容就可以检测主机的端口是否存在故障。此外,对于故障发现策略2、故障发现策略3的内容也不做限制,只要能够根据这些故障发现策略对主机进行故障发现即可,在此不再赘述。
在上述过程中,已经详细介绍了故障发现的处理流程,进一步的,从节点根据故障发现策略进行故障发现之后,还可以涉及如下的故障恢复步骤:
步骤A、从节点在发现主机已经发生故障时的处理过程。
在一个例子中,从节点根据该故障发现策略对主机进行故障发现之后,若发现主机已经发生故障,则确定该故障对应的故障特征和故障类型。然后,从节点可以向主节点发送故障消息,该故障消息用于通知主机发生故障,且该故障消息可以携带该故障特征和该故障类型。
上述故障特征可以包括但不限于以下内容之一或者任意组合:硬件特征、系统特征、服务组件特征、运行日志特征。其中,硬件特征可以是:主机的CPU特征(如CPU使用率)、内存特征(如内存使用率)、磁盘特征(如磁盘占用率)等,对此硬件特征不做限制。系统特征可以是:操作系统类型(如Windows、Linux等)、操作系统版本等,对此系统特征不做限制。服务组件特征可以是:与服务组件有关的特征,如服务组件的端口是否开启、服务组件是否处于运行状态、服务组件的网络状态是否异常、服务组件是否能够处理请求等,对此服务组件特征不做限制。运行日志特征可以是:从运行日志中提取出的特征,如主机运行时间、主机运行的程序、主机的网络行为等,对此运行日志特征不做限制。当然,上述过程只是给出了故障特征的几个示例,对此故障特征也不做限制,所有与故障有关的特征均在本申请的保护范围之内。
例如,假设从节点根据“端口类型”对应的故障发现策略1对主机11进行故障发现时,发现主机11已经发生故障,则确定该故障对应的故障类型是“端口类型”,并根据主机11的当前状态获取该故障对应的故障特征,如主机11当前的CPU特征、内存特征、磁盘特征,主机11的操作系统类型和操作系统版本,与服务组件有关的特征,主机11的运行日志中的运行日志特征等。
又例如,假设从节点根据“性能指标类型”对应的故障发现策略3对主机12进行故障发现时,发现主机12已经发生故障,则确定该故障对应的故障类型是“性能指标类型”,并根据主机12的当前状态获取该故障对应的故障特征。
步骤B、主节点在发现主机已经发生故障时的处理过程。针对主节点发现主机已经发生故障时的处理过程,可以采用如下三种方式中的一种方式处理。
方式一、主节点在接收到从节点发送的故障消息后,根据目标配置文件包括的告警方式发送告警消息,该告警消息可以携带该目标配置文件包括的服务名称和组件名称、该主机的信息(如主机的IP地址、主机的标识等)。当然,该告警消息携带的内容并不局限于上述内容,如告警消息还可以携带目标配置文件包括的标识、文件名称、描述信息、集群名称等内容,对此不做限制。
其中,配置文件包括的告警方式可以是WEB、EMAIL、SNMP中的一种或多种,因此主节点可以通过目标配置文件包括的告警方式发送告警消息。
例如,主节点将配置文件1包括的故障类型发送给主机11对应的从节点后,若接收到从节点发送的故障消息,则根据配置文件1包括的告警方式发送告警消息,其中携带配置文件1包括的服务名称和组件名称、主机11的信息。
在一个例子中,主节点在接收到从节点发送的故障消息后,还可以在WEB页面展现目标配置文件包括的服务名称、组件名称、以及主机的信息等内容。
方式二、主节点在接收到从节点发送的故障消息后,从该故障消息中解析出故障特征和故障类型。然后,主节点通过该故障特征和该故障类型查询特征库,若所述特征库中存在与该故障特征和该故障类型匹配的故障恢复策略,则主节点将该故障恢复策略发送给从节点;若所述特征库中不存在与该故障特征和该故障类型匹配的故障恢复策略,则提示用户对所述主机的故障进行恢复。
在一个例子中,主节点可以建立特征库,该特征库用于记录故障特征、故障类型、故障恢复策略的对应关系,这个故障恢复策略可以理解为:当该故障类型的故障具有该故障特征时,则可以采用该故障恢复策略来恢复故障。如特征库可以记录故障特征A、故障类型A、故障恢复策略A的对应关系,故障特征B、故障类型B、故障恢复策略B的对应关系,以此类推。这样,当故障类型A的故障具有故障特征A时,则可以采用故障恢复策略A来恢复故障。
例如,主节点在从故障消息中解析出故障特征A和故障类型A之后,由于特征库中存在与该故障特征A和该故障类型A匹配的故障恢复策略A,因此,主节点将故障恢复策略A发送给从节点。又例如,主节点在从故障消息中解析出故障特征C和故障类型C后,由于特征库中不存在与该故障特征C和该故障类型C匹配的故障恢复策略,因此,主节点提示用户对主机的故障进行恢复。
进一步的,在用户对主机的故障进行恢复之后,主节点还可以获取用户对主机进行故障恢复时使用的故障恢复策略,并在特征库中记录该故障特征、该故障类型和获取的故障恢复策略的对应关系,从而不断更新特征库的内容。
例如,由于特征库中不存在与故障特征C和故障类型C匹配的故障恢复策略,因此,主节点提示用户对主机的故障进行恢复,假设用户采用故障恢复策略C对主机的故障进行恢复,在恢复完成后,从节点可以将故障恢复策略C发送给主节点。主节点在获取到用户对主机进行故障恢复时使用的故障恢复策略C后,在特征库中记录故障特征C、故障类型C和故障恢复策略C的对应关系。
方式三、主节点在接收到故障消息后,采用方式一和方式二进行处理。
针对方式二和方式三,若特征库中存在与故障特征和故障类型匹配的故障恢复策略,主节点将该故障恢复策略发送给从节点后,还可以执行如下步骤:
步骤C、从节点接收到故障恢复策略时的故障恢复处理过程。
在一个例子中,从节点可以接收主节点发送的故障恢复策略,并根据故障恢复策略对主机当前的故障进行故障恢复。其中,当主机发生故障时,从节点可以将所述故障对应的故障类型和故障特征发送给主节点,且主节点向该从节点返回的这个故障恢复策略,是针对该故障特征和该故障类型的故障恢复策略,因此,这个故障恢复策略能够对与该故障特征和该故障类型匹配的故障进行恢复,也就是说,这个故障恢复策略能够对主机当前的故障进行故障恢复。
在一个例子中,对于故障恢复策略的内容不做限制,只要从节点能够根据故障恢复策略进行故障恢复即可。例如,故障恢复策略可以包括用于进行故障恢复的配置信息、恢复流程、恢复工具(如删除文件、更改配置、释放资源、重新挂载、重启)等,基于这些内容就可以对故障进行恢复,在此不再赘述。
基于上述技术方案,本申请实施例中,可以自动发现主机的故障,能够高效、便捷地发现主机的故障,从而实现大数据集群中主机故障的自动发现,能够解决大数据集群中监控运维复杂度高、故障发现难度大等问题。
此外,还可以自动恢复主机的故障,能够高效、便捷地恢复主机的故障,从而实现大数据集群中主机故障的自动恢复,能够解决大数据集群中监控运维复杂度高、故障恢复难度大等问题,从而提高主机的恢复效率。
基于与上述方法同样的申请构思,本申请实施例中还提出一种故障发现装置,该装置可以应用于大数据集群的主节点,所述大数据集群还包括从节点,所述从节点部署在大数据集群中的主机上,参见图3所示,为所述装置的结构图,所述装置包括:
获取模块301,用于获取所述从节点对应的主机上部署的服务组件的服务名称和组件名称,并从所述主节点上配置的多个配置文件中确定包括所述服务名称和所述组件名称的目标配置文件;
发送模块302,用于将所述目标配置文件中包括的故障类型发送给所述从节点,以使所述从节点根据所述故障类型对应的故障发现策略,对对应的主机进行故障发现。
在一个例子中,所述故障发现装置还包括(在图中未体现):
接收模块,用于接收所述从节点发送的故障消息,所述故障消息用于通知所述主机发生故障。
在一个例子中,所述发送模块302,还用于根据所述目标配置文件包括的告警方式发送告警消息,其中,所述告警消息携带所述目标配置文件包括的服务名称和组件名称、以及所述主机的信息。
在一个例子中,所述故障消息携带故障特征和故障类型;所述发送模块302,还用于当特征库中存在与所述故障特征和故障类型匹配的故障恢复策略时,则将所述故障恢复策略发送给所述从节点,以使所述从节点根据所述故障恢复策略对所述主机进行故障恢复;其中,所述特征库用于记录故障特征、故障类型、故障恢复策略的对应关系。
在一个例子中,所述故障发现装置还包括(在图中未体现):记录模块,用于当特征库中不存在与所述故障特征和故障类型匹配的故障恢复策略时,则获取用户对所述主机进行故障恢复时使用的故障恢复策略,并在所述特征库中记录所述故障特征、所述故障类型和获取的故障恢复策略的对应关系。
本申请实施例提供的主节点,从硬件层面而言,其硬件架构示意图具体可以参见图4所示。包括:机器可读存储介质和处理器,其中:
机器可读存储介质:存储指令代码。
处理器:与机器可读存储介质通信,读取和执行机器可读存储介质中存储的所述指令代码,实现本申请上述示例公开的故障发现操作。
这里,机器可读存储介质可以是任何电子、磁性、光学或其它物理存储装置,可以包含或存储信息,如可执行指令、数据,等等。例如,机器可读存储介质可以是:RAM(RadomAccess Memory,随机存取存储器)、易失存储器、非易失性存储器、闪存、存储驱动器(如硬盘驱动器)、固态硬盘、任何类型的存储盘(如光盘、dvd等),或者类似的存储介质,或者它们的组合。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机,计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
为了描述的方便,描述以上装置时以功能分为各种单元分别描述。当然,在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可以由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其它可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其它可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
而且,这些计算机程序指令也可以存储在能引导计算机或其它可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或者多个流程和/或方框图一个方框或者多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其它可编程数据处理设备上,使得在计算机或者其它可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其它可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。
Claims (10)
1.一种故障发现方法,其特征在于,应用于大数据集群的主节点,所述大数据集群还包括从节点,所述从节点部署在大数据集群中的主机上,该方法还包括:
获取所述从节点对应的主机上部署的服务组件的服务名称和组件名称;
从所述主节点上配置的多个配置文件中确定包括所述服务名称和所述组件名称的目标配置文件;
将所述目标配置文件中包括的故障类型发送给所述从节点,以使所述从节点根据所述故障类型对应的故障发现策略,对对应的主机进行故障发现。
2.根据权利要求1所述的方法,其特征在于,所述方法还包括:
接收所述从节点发送的故障消息,所述故障消息用于通知所述主机发生故障。
3.根据权利要求2所述的方法,其特征在于,该方法还包括:
根据所述目标配置文件包括的告警方式发送告警消息,其中,所述告警消息携带所述目标配置文件包括的服务名称和组件名称,所述告警消息还携带所述主机的信息。
4.根据权利要求2所述的方法,其特征在于,所述故障消息携带故障特征和故障类型,该方法还包括:
若特征库中存在与所述故障特征和故障类型匹配的故障恢复策略,则将所述故障恢复策略发送给所述从节点,以使所述从节点根据所述故障恢复策略对所述主机进行故障恢复;其中,所述特征库用于记录故障特征、故障类型、故障恢复策略的对应关系。
5.根据权利要求4所述的方法,其特征在于,所述方法还包括:
若特征库中不存在与所述故障特征和故障类型匹配的故障恢复策略,则获取用户对所述主机进行故障恢复时使用的故障恢复策略,并在所述特征库中记录所述故障特征、所述故障类型和获取的故障恢复策略的对应关系。
6.一种故障发现装置,其特征在于,应用于大数据集群的主节点,所述大数据集群还包括从节点,所述从节点部署在大数据集群中的主机上,该装置还包括:
获取模块,用于获取所述从节点对应的主机上部署的服务组件的服务名称和组件名称,并从所述主节点上配置的多个配置文件中确定包括所述服务名称和所述组件名称的目标配置文件;
发送模块,用于将所述目标配置文件中包括的故障类型发送给所述从节点,以使所述从节点根据所述故障类型对应的故障发现策略,对对应的主机进行故障发现。
7.根据权利要求6所述的装置,其特征在于,还包括:接收模块,用于接收所述从节点发送的故障消息,所述故障消息用于通知所述主机发生故障。
8.根据权利要求7所述的装置,其特征在于,所述发送模块,还用于根据所述目标配置文件包括的告警方式发送告警消息,其中,所述告警消息携带所述目标配置文件包括的服务名称和组件名称,所述告警消息还携带所述主机的信息。
9.根据权利要求7所述的装置,其特征在于,所述故障消息携带故障特征和故障类型;所述发送模块,还用于当特征库中存在与所述故障特征和故障类型匹配的故障恢复策略时,则将所述故障恢复策略发送给所述从节点,以使所述从节点根据所述故障恢复策略对所述主机进行故障恢复;其中,所述特征库用于记录故障特征、故障类型、故障恢复策略的对应关系。
10.根据权利要求9所述的装置,其特征在于,还包括:记录模块,用于当特征库中不存在与所述故障特征和故障类型匹配的故障恢复策略时,则获取用户对所述主机进行故障恢复时使用的故障恢复策略,并在所述特征库中记录所述故障特征、所述故障类型和获取的故障恢复策略的对应关系。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710474280.3A CN108289034B (zh) | 2017-06-21 | 2017-06-21 | 一种故障发现方法和装置 |
PCT/CN2018/091997 WO2018233630A1 (zh) | 2017-06-21 | 2018-06-20 | 故障发现 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710474280.3A CN108289034B (zh) | 2017-06-21 | 2017-06-21 | 一种故障发现方法和装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN108289034A CN108289034A (zh) | 2018-07-17 |
CN108289034B true CN108289034B (zh) | 2019-04-09 |
Family
ID=62831422
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201710474280.3A Active CN108289034B (zh) | 2017-06-21 | 2017-06-21 | 一种故障发现方法和装置 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN108289034B (zh) |
WO (1) | WO2018233630A1 (zh) |
Families Citing this family (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111158962B (zh) * | 2018-11-07 | 2023-10-13 | 中移信息技术有限公司 | 一种异地容灾方法、装置、系统、电子设备及存储介质 |
CN112804072B (zh) * | 2019-11-14 | 2023-05-16 | 深信服科技股份有限公司 | 一种故障信息收集方法、装置、目标电子设备及存储介质 |
CN110880990B (zh) * | 2019-11-29 | 2022-08-23 | 绿盟科技集团股份有限公司 | 一种大数据集群组件的配置核查方法、装置及计算设备 |
CN113055203B (zh) * | 2019-12-26 | 2023-04-18 | 中国移动通信集团重庆有限公司 | Sdn控制平面的异常恢复方法及装置 |
CN111258851B (zh) * | 2020-01-14 | 2024-03-01 | 广州虎牙科技有限公司 | 一种集群的告警方法、装置、设置及存储介质 |
CN111459749B (zh) * | 2020-03-18 | 2024-08-16 | 平安科技(深圳)有限公司 | 基于Prometheus的私有云监控方法、装置、计算机设备及存储介质 |
CN111831511A (zh) * | 2020-07-15 | 2020-10-27 | 北京思特奇信息技术股份有限公司 | 一种云服务的业务主机的检测处理方法、装置及介质 |
CN113760634A (zh) * | 2020-09-04 | 2021-12-07 | 北京沃东天骏信息技术有限公司 | 一种数据处理方法和装置 |
CN114389940A (zh) * | 2020-10-20 | 2022-04-22 | 华为技术有限公司 | 故障恢复预案确定方法、装置及系统、计算机存储介质 |
CN113407374A (zh) * | 2021-06-22 | 2021-09-17 | 未鲲(上海)科技服务有限公司 | 故障处理方法、装置、故障处理设备及存储介质 |
CN115134212B (zh) * | 2022-06-29 | 2024-04-19 | 中国工商银行股份有限公司 | 策略推送方法、装置、计算机设备和存储介质 |
Family Cites Families (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101593135A (zh) * | 2008-05-29 | 2009-12-02 | 国际商业机器公司 | 在分布式集成环境中集中处理业务流程故障的装置和方法 |
CN102882909B (zh) * | 2011-07-15 | 2015-05-06 | 易云捷讯科技(北京)有限公司 | 云计算服务监控系统及方法 |
US9172608B2 (en) * | 2012-02-07 | 2015-10-27 | Cloudera, Inc. | Centralized configuration and monitoring of a distributed computing cluster |
CN102916830B (zh) * | 2012-09-11 | 2013-12-11 | 北京航空航天大学 | 一种资源服务优化配置容错管理实现系统 |
CN103368771A (zh) * | 2013-06-24 | 2013-10-23 | 华为技术有限公司 | 一种多节点服务器系统的故障现场信息的收集方法及装置 |
CN103778031B (zh) * | 2014-01-15 | 2017-01-18 | 华中科技大学 | 一种云环境下的分布式系统多级故障容错方法 |
CN103812699A (zh) * | 2014-02-17 | 2014-05-21 | 无锡华云数据技术服务有限公司 | 基于云计算的监控管理系统 |
CN105515812A (zh) * | 2014-10-15 | 2016-04-20 | 中兴通讯股份有限公司 | 资源的故障处理方法及装置 |
CN105630647A (zh) * | 2014-11-28 | 2016-06-01 | 中兴通讯股份有限公司 | 一种设备检测方法及检测设备 |
CN105337765B (zh) * | 2015-10-10 | 2018-10-12 | 上海新炬网络信息技术股份有限公司 | 一种分布式hadoop集群故障自动诊断修复系统 |
CN106844132A (zh) * | 2015-12-03 | 2017-06-13 | 北京国双科技有限公司 | 集群服务器的故障修复方法和装置 |
CN106130778A (zh) * | 2016-07-18 | 2016-11-16 | 浪潮电子信息产业股份有限公司 | 一种处理集群故障的方法及一种管理节点 |
CN106341281A (zh) * | 2016-11-10 | 2017-01-18 | 福州智永信息科技有限公司 | linux服务器分布式故障检测和恢复方法 |
CN106789398A (zh) * | 2016-11-25 | 2017-05-31 | 中国传媒大学 | 一种媒体大数据hadoop集群监控的方法 |
-
2017
- 2017-06-21 CN CN201710474280.3A patent/CN108289034B/zh active Active
-
2018
- 2018-06-20 WO PCT/CN2018/091997 patent/WO2018233630A1/zh active Application Filing
Also Published As
Publication number | Publication date |
---|---|
CN108289034A (zh) | 2018-07-17 |
WO2018233630A1 (zh) | 2018-12-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN108289034B (zh) | 一种故障发现方法和装置 | |
US10560465B2 (en) | Real time anomaly detection for data streams | |
US10817195B2 (en) | Key-value based message oriented middleware | |
US9330161B2 (en) | Creating global aggregated namespaces for storage management | |
JP6396984B2 (ja) | デバイスにわたって未読メッセージ総数を提供すること | |
US10491453B2 (en) | Correlating computing network events | |
US10331947B2 (en) | Automatic detection on string and column delimiters in tabular data files | |
US10972586B2 (en) | Reusable message flow between applications of a message broker integrated systems environment | |
TW201543243A (zh) | 在服務導向架構中的監控能力 | |
US20170024396A1 (en) | Determining application deployment recommendations | |
US20170318129A1 (en) | Generation and distribution of named, definable, serialized tokens | |
CN113495797B (zh) | 一种消息队列及消费者动态创建方法及系统 | |
US20150088825A1 (en) | Virtual machine storage replication schemes | |
US20170149631A1 (en) | Avoiding web request failures before they occur by component analysis | |
US10187264B1 (en) | Gateway path variable detection for metric collection | |
US20180131605A1 (en) | Floating internet protocol for private networks | |
US10129330B2 (en) | Attachment of cloud services to big data services | |
JP2019504415A (ja) | データ格納サービス処理方法及び装置 | |
US10826965B2 (en) | Network monitoring to identify network issues | |
US20150106899A1 (en) | System and method for cross-cloud identity matching | |
JP6364727B2 (ja) | 情報処理システム、分散処理方法、及び、プログラム | |
CN105144073A (zh) | 可移除存储设备身份和配置信息 | |
US11204961B1 (en) | Apparatuses, methods, and computer program products for dynamic generation and traversal of object dependency data structures | |
KR101630088B1 (ko) | 가상머신의 라이프사이클 모니터링 방법 및 그 장치 | |
US11140183B2 (en) | Determining criticality of identified enterprise assets using network session information |
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 | ||
GR01 | Patent grant | ||
GR01 | Patent grant |