CN109522095A - 云主机异常故障检测恢复系统、方法及云平台 - Google Patents

云主机异常故障检测恢复系统、方法及云平台 Download PDF

Info

Publication number
CN109522095A
CN109522095A CN201811422877.4A CN201811422877A CN109522095A CN 109522095 A CN109522095 A CN 109522095A CN 201811422877 A CN201811422877 A CN 201811422877A CN 109522095 A CN109522095 A CN 109522095A
Authority
CN
China
Prior art keywords
cloud host
fault
uses case
component
label
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.)
Granted
Application number
CN201811422877.4A
Other languages
English (en)
Other versions
CN109522095B (zh
Inventor
许广彬
张建峰
谭瑞忠
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huayun data holding group Co., Ltd
Original Assignee
Wuxi Huayun Data Technology Service Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Wuxi Huayun Data Technology Service Co Ltd filed Critical Wuxi Huayun Data Technology Service Co Ltd
Priority to CN201811422877.4A priority Critical patent/CN109522095B/zh
Publication of CN109522095A publication Critical patent/CN109522095A/zh
Application granted granted Critical
Publication of CN109522095B publication Critical patent/CN109522095B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/301—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is a virtual computing platform, e.g. logically partitioned systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3051—Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45591—Monitoring or debugging support

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Mathematical Physics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本发明公开了云主机异常故障检测恢复系统，包括采集组件，整理组件、内置动作库的数据库、学习组件、交互组件、执行组件及监控组件；采集组件采集状态数据，使用整理组件进行归类标记以形成故障检测用例集与正常用例集；学习组件提取故障检测用例集，训练得到最佳故障检测模型并发送至数据库；交互组件调用执行组件以执行动作库中的动作，通知并使用整理组件进行归类标记以形成故障恢复用例集；监控组件自数据库获取最佳故障检测模型，并与整理组件实时采集的状态数据进行对比，在对比成功后，调用故障检测用例集中的实例，以对云主机进行故障标定。本发明所揭示的云主机异常故障检测恢复系统实现了云主机故障的准确判断及故障恢复。

Description

云主机异常故障检测恢复系统、方法及云平台
技术领域
本发明涉及云计算技术领域，尤其涉及一种云主机异常故障检测恢复系统以及基于该云主机异常故障检测恢复系统的一种云主机异常故障检测恢复方法，以及一种云平台。
背景技术
在基于IaaS平台的云主机场景中，当云主机(其本质上是一种虚拟机)处于超载或者资源紧张时会被物理机的安全机制强制关闭，从而影响到云主机向用户提供正常的响应及服务。通常的，如果云主机被强制关闭所导致的云主机内部操作系统的蓝屏现象及宕机现象是无法被用户所感知的。既使管理员远程登录后台并发现某个或者某些云主机出现故障时，则实际上出现故障的云主机向用户提供响应及服务的状态已经持续了相当长的一段时间了。
为了监控云主机的状态，通常的解决方案是定时地向云主机的内部注入监控程序，以确定云主机是否存活；并在发现云主机不可访问时判定其为故障云主机，并执行重启操作。但是该现有技术只能检测出云主机不可访问，无法判断这种不可访问是因为“超载或者资源紧张”还是因为基于用户的关机行为所导致的。因此如果采用现有技术手段，会导致对云主机执行重启操作的盲目性，并增加了误判几率。
有鉴于此，有必要对现有技术中的云主机发生故障时的检测恢复系统予以改进，以解决上述问题。
发明内容
本发明的目的在公开一种云主机异常故障检测系统、方法及云平台，以实现不仅仅能够检测到云主机是否发生故障，并判断出该故障是否为基于用户操作意愿所呈现的故障，有效防止对云主机所采取不必要或者错误的干预，提高用户体验；同时，实现云主机能够提供更高可用的业务服务支持，尽量减小云主机的操作系统和物理资源脱节对客户业务连续性的影响。
为实现上述第一个发明目的，本发明公开了一种云主机异常故障检测恢复系统，包括：采集组件，整理组件、内置动作库的数据库、学习组件、交互组件、执行组件及监控组件；
采集组件采集状态数据，使用整理组件进行归类标记以形成故障检测用例集与正常用例集；
学习组件提取故障检测用例集，训练得到最佳故障检测模型并发送至数据库；
交互组件调用执行组件以执行动作库中的动作，通知并使用整理组件进行归类标记以形成故障恢复用例集；
监控组件自数据库获取最佳故障检测模型，并与整理组件实时采集的状态数据进行对比，在对比成功后，调用故障检测用例集中的实例，以对云主机进行故障标定。
作为本发明的进一步改进，所述采集组件部署于控制节点或者计算节点中；
所述数据库、学习组件、交互组件、执行组件及监控组件仅部署于控制节点中。
作为本发明的进一步改进，所述状态数据由系统基础数据、系统服务日志及API返回结果共同描述；
所述系统基础数据由CPU资源占用率、内存占用率、网卡流量中的至少一种构成；
所述API返回结果由具体的云主机与计算节点中其他的云主机之间或者控制节点之间所形成的数据；
所述系统服务日志为“/var/log/”目录中的日志文件。
作为本发明的进一步改进，所述使用整理组件进行归类标记以形成故障检测用例集与正常用例集具体为：
整理组件在设定时间段内的系统基础数据及系统服务日志进行转换标签处理，以形成第一类标签；
将相同的设定时间段内的API返回结果进行转换标签处理，当API返回结果符合故障类型时转换为第一类特征码，当API返回结果符合非故障类型时转换为第二类特征码；
将设定时间段与第一类标签及第一类特征码进行关联，以形成故障检测用例集中的一个用例，将设定时间段与第一类标签及第二类特征码进行关联，以形成正常用例集中的一个用例。
作为本发明的进一步改进，所述学习组件训练得到最佳故障检测模型具体为：
所述学习组件提取故障检测用例集并按照设定比例将故障检测用例集中的用例划分为故障检测训练集、故障检测验证集与故障检测测试集，并基于机器学习算法训练得到最佳故障检测模型；
其中，故障检测训练集、故障检测验证集与故障检测测试集的划分比例为：8:1:1。
作为本发明的进一步改进，所述机器学习算法为决策树算法、朴素贝叶斯算法、最小二乘法、支持向量机算法、聚类算法、主成分分析法或者独立成分分析法。
作为本发明的进一步改进，所述交互组件接收自定义故障输入，以对数据库中留存的最佳故障检测模型进行更新；其中，所述最佳故障检测模型的数量仅为一个。
作为本发明的进一步改进，所述故障检测用例集、正常用例集及故障恢复用例集均保存于数据库。
作为本发明的进一步改进，使用整理组件进行归类标记以形成故障恢复用例集具体为：
执行组件执行动作库中的动作，并通知整理组件执行所述动作及时间段，进行归类标记以形成第二类标签，并将所述动作在执行前后所对应的时间段从采集组件获取的API返回结果的变化转换为第三类特征码，并最终通过整理组件将第二类标签、时间段与第三类特征码进行关联，以形成故障恢复用例集中的一个实例。
作为本发明的进一步改进，其特征在于，所述执行组件通过交互组件向数据库发起调用最佳故障检测模型的请求并发送至云主机，以对云主机进行故障恢复。
作为本发明的进一步改进，所述最佳故障检测模型为更新后的最佳故障检测模型。
作为本发明的进一步改进，所述自定义故障输入为向所述交互组件输入未被故障检测用例集所列入的新的故障用例，所述自定义故障输入由管理员和/或用户以本地操作或者异地操作的形式向交互组件进行输入，以对最佳故障检测模型中的用例进行更新，从而得到更新后的最佳故障检测模型。
作为本发明的进一步改进，所述监控组件自数据库中获取当前的最佳故障检测模型，并将第一类标签及第一类特征码作为整体与整理组件实时采集到的云主机的第一类标签及第一类特征码进行同类型对比；
当完全匹配时，将该云主机的状态判定为故障；
当不完全匹配时，将该云主机的状态判定为正常。
作为本发明的进一步改进，当第一类标签及第一类特征码作为整体与整理组件实时采集到的云主机的第一类标签及第一类特征码进行同类型对比且当不完全匹配时，将整理组件实时采集到的云主机的第一类标签及第一类特征码添加至正常用例集。
同时，本申请还公开了一种云主机异常故障检测恢复方法，包括以下步骤：
S1、通过采集组件采集状态数据，使用整理组件进行归类标记以形成故障检测用例集与正常用例集；
S2、通过学习组件提取故障检测用例集，训练得到最佳故障检测模型并发送至数据库；
S3、交互组件调用执行组件以执行动作库中的动作，通知并使用整理组件进行归类标记以形成故障恢复用例集；
S4、通过监控组件自数据库获取最佳故障检测模型，并与整理组件实时采集的状态数据进行对比，在对比成功后，调用故障检测用例集中的实例，以对云主机进行故障标定；
其中，所述采集组件部署于控制节点或者计算节点中；
所述数据库、学习组件、交互组件、执行组件及监控组件仅部署于控制节点中。
最后，本申请还揭示了一种云平台，包括：
至少一个计算节点，所述计算节点中被配置出至少一个云主机，控制节点，
以及如上述第1个至第8个发明创造所述的云主机异常故障检测恢复系统。
与现有技术相比，本发明的有益效果是：
(1)通过本发明所揭示的一种云主机异常故障检测系统，不仅实现了能够对计算节点中的云主机的故障进行准确地判断，防止将基于用户操作意愿所呈现的故障错误地判定为故障，从而极大地降低了对云主机的所采取的错误恢复及不必要的干预；
(2)能够对故障通过学习组件进行自主学习，强化了最佳故障故障检测模型的容错性；
(3)当云主机真正因超载或者资源紧张时会被物理机的安全机制强制关闭时对云主机进行合理的干预与故障恢复，确保云主机能够提供更高可用的业务服务支持的能力，避免云主机的操作系统和物理资源脱节对客户业务连续性的影响，从而显著地提高了用户体验。
附图说明
图1为在实施例一中学习组件训练得到最佳故障检测模型的流程图；
图2为在实施例二中学习组件训练得到最佳故障检测模型的流程图；
图3为本发明一种云主机异常故障检测系统的逻辑架构图；
图4为云主机异常故障检测系统中的数据库配置故障检测用例集、正常用例集与故障恢复用例集的示意图；
图5为实施三中本发明一种云主机异常故障检测恢复方法的流程图。
具体实施方式
下面结合附图所示的各实施方式对本发明进行详细说明，但应当说明的是，这些实施方式并非对本发明的限制，本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代，均属于本发明的保护范围之内。在本申请中，术语“云主机”与术语“HOST”、“VM”(虚拟机)具等同理解。术语“组件”是运行在云平台中具有独立逻辑运行功能的一个单元。术语“实例”(instance)是程序运行所依赖的对象，其可表现为一个数据、一个指令、一种状态、一种表达或者一种集合等等。术语“标定”可被理解为判定或者认定。在本申请中，所谓“第一”、“第二”的描述仅用于同类型但具有不同含义的技术特征的区分。
发明概述
本申请各个实施例所揭示的一种云主机异常故障检测恢复系统用以追求对计算节点20中所开启的云主机21至云主机2i(其中，“i”为大于或者等于1的正整数)在向用户(Client)提供服务的过程中所出现的各种故障进行检测与故障恢复。云主机21至云主机2i本质上一种云服务器，也可以被理解为虚拟机(VM)或者虚拟主机。参图3所示，在发明的实例环境中，计算节点20中形成多个云主机，云主机均受控于控制节点10，并具有相互独立的虚拟IP、虚拟网络、虚拟内存等属性。多个云主机通过底层虚拟化技术通过各种物理资源形成。云主机对用户不可见，管理员1可通过登录云平台对云主机进行管理与配置。同时，本发明中的云平台为IaaS类型的云平台，
IaaS：Infrastructure-as-a-Service(基础设施即服务)提供给用户的服务是对所有计算基础设施的利用，包括处理CPU、内存、存储、网络和其它基本的计算资源，用户能够部署和运行任意软件，包括操作系统和应用程序。用户不管理或控制任何云计算基础设施，但能控制操作系统的选择、存储空间、部署的应用，也有可能获得有限制的网络组件(例如路由器、防火墙、负载均衡器等)的控制。
进一步的，在本申请中，采集组件20采集状态数据，使用整理组件40进行归类标记以形成故障检测用例集51与正常用例集52；学习组件60提取故障检测用例集51，训练得到最佳故障检测模型并发送至数据库50；交互组件70调用执行组件80以执行动作库501中的动作，通知并使用整理组件40进行归类标记以形成故障恢复用例集53；监控组件90自数据库50获取最佳故障检测模型，并与整理组件40实时采集的状态数据进行对比，在对比成功后，调用故障检测用例集51中的实例，以对云主机21进行故障标定。
在本申请中，我们选用云主机21为范例，示范性地阐述与解释本申请的核心要义。本领域的普通技术人员可以合理预测到本发明也可以实现对计算节点20中的其他云主机进行故障检测与恢复。通过本发明能够对异常故障或者故障是基于用户关闭云主机的行为(私有云环境或者混合云环境)所导致的通讯异常还是由于底层物理资源匮乏或者故障所导致的云主机的异常实现准确区分。需要说明的是，前者所表现出来的“故障”是正常的，不需要管理员1对云主机21进行故障恢复或者配置，而后者表现出来的“故障”是异常的，需要管理员1对云主机21进行故障恢复或者配置。
通过本申请所揭示的技术方案，能够有效区分上述两种“故障”，以实现对云主机21所呈现的故障进行合理的判断的技术效果，降低了对云主机21所采取的错误恢复操作的可能性及不必要的干预；同时，通过自主学习以持续地更新最佳故障检测模型，进一步降低了对非异常的故障的误判率，从而提高用户体验，同时确保云主机能够提供更高可用的业务服务支持的能力，避免云主机21的操作系统和物理资源(物理CPU、物理存储装置、物理内存等物理资源)脱节对客户业务连续性造成实质性影响。其中，“脱节”可以被理解为时间上的不同步或者资源上的不对匹配等多种可能性。
实施例一：
请参图3所示出的一种云主机异常故障检测恢复系统，包括：采集组件30，整理组件40、内置动作库501的数据库50、学习组件60、交互组件70、执行组件80及监控组件90。采集组件30采集状态数据，使用整理组件40进行归类标记以形成故障检测用例集与正常用例集。学习组件60提取故障检测用例集，训练得到最佳故障检测模型并发送至数据库50。交互组件70调用执行组件80以执行动作库501中的动作，通知并使用整理组件40进行归类标记以形成故障恢复用例集53。监控组件90自数据库50获取最佳故障检测模型，并与整理组件40实时采集的状态数据进行对比，在对比成功后，调用故障检测用例集中的实例，以对云主机21进行故障标定。
需要说明的是，在本申请所有实施例中，所谓的“对比成功”是指所有需要对比的对比项目(在本申请中，所述对比项目包括下文提及的标签、特征码及时间段)均对比成功后，才将该云主机21标定或者认定为呈故障的云主机，并采用调用最佳故障检测模型的请求并发送至云主机21的方式，以对云主机21进行故障恢复，以尽量减小云主机的操作系统和物理资源因脱节对客户业务连续性所造成的影响。此种脱节既可以是物理资源的提供存在时间差所导致，也可以是因为物理资源的匮乏所导致。
在本实施例中，优选的，该采集组件30部署于计算节点20中。数据库50、学习组件60、交互组件70、执行组件80及监控组件90仅部署于控制节点10中。当然，作为其他可选的实现方案，该采集组件30也可在逻辑上位于控制节点10中。当然，采集组件30部署于计算节点30中，可缩短与具体的被检测的云主机21的访问路径，防止因云主机的操作系统在故障检测等处理时，因网络拥塞或者他原因所导致的无法对云主机21执行故障恢复的缺陷。
本实施例中的状态数据由系统基础数据、系统服务日志及API返回结果共同描述。更具体的，在本实施例中，该系统基础数据由CPU资源占用率、内存占用率、网卡流量中的至少一种参数构成，当然也可以采用两种或者数量更多的参数共同描述。API返回结果由具体的云主机与计算节点20中其他的云主机之间或者控制节点10之间所形成的数据，例如：nova_api：200，neutron_api:204等。
系统服务日志具体为“/var/log/”目录中的日志文件。
该日志文件选自以下一种或者多种类型的日志文件：
/var/log/messages：包含了整个系统的日志文件信息。
/var/log/dmesg：包含内核缓冲信息，用来帮助用户了解系统的启动信息。
/var/log/auth.log：包含用户登录和使用的权限机制等系统授权信息。
/var/log/boot.log：包含系统启动时的日志。
/var/log/daemon.log：包含各种系统后台守护进程日志信息。
/var/log/dpkg.log：包括安装或dpkg命令清除软件包的日志。
/var/log/kern.log：包含内核产生的日志，有助于在定制内核时解决问题。
/var/log/lastlog：记录所有用户的最近信息。
/var/log/maillog/var/log/mail.log：包含来自系统运行电子邮件服务器的日志信息。例如，send mail日志信息就全部送到这个文件中。
/var/log/user.log：记录所有等级用户信息的日志。
/var/log/Xorg.x.log：来自X的日志信息。
/var/log/alternatives.log：更新替代信息都记录在这个文件中。
/var/log/btmp：记录所有失败登录信息。使用last命令可以查看btmp文件。例如，“last-f/var/log/btmp|more”。
/var/log/cups：涉及所有打印信息的日志。
/var/log/anaconda.log：安装Linux时所需的安装信息。
/var/log/yum.log：包含使用yum安装的软件包信息。
/var/log/cron：每当cron进程开始一个工作时，就会将相关信息记录在这个文件中。
/var/log/secure：包含验证和授权方面信息。例如，sshd会将所有信息记录(其中包括失败登录)在这里。
/var/log/wtmp或/var/log/utmp：包含登录信息。使用wtmp可以找出谁正在登陆进入系统，谁使用命令显示这个文件或信息等。
/var/log/faillog：包含用户登录失败信息及错误登录命令。
除了上述Log文件以外，/var/log还基于系统(例如Linux操作系统)的具体应用包含以下一些子目录：
/var/log/httpd/或/var/log/apache2：包含服务器access_log和error_log信息。
/var/log/lighttpd/：包含light HTTPD的access_log和error_log。
/var/log/mail/：这个子目录包含邮件服务器的额外日志。
/var/log/prelink/：包含.so文件被prelink修改的信息。
/var/log/audit/：包含被Linux audit daemon储存的信息。
/var/log/samba/：包含由samba存储的信息。
/var/log/sa/：包含每日由sysstat软件包收集的sar文件。
/var/log/sssd/：用于守护进程安全服务。
当然，该状态数据还可以包含时间段，例如：例如20181009 12:01-20181009 12:02。其代表2018年10月9日GMT12:02至2018年10月9日12:03这一分钟的时间段内该云主机21与其他云主机、控制节点10或者计算节点20之间所发生的其他类型的状态数据。同时该时间段可以被自定义修改，只要整个环境配置保持一致即可。
使用整理组件40进行归类标记以形成故障检测用例集51与正常用例52集具体为：整理组件40在设定时间段内的系统基础数据及系统服务日志进行转换标签处理，以形成第一类标签。将相同的设定时间段内的API返回结果进行转换标签处理，当API返回结果符合故障类型时转换为第一类特征码，当API返回结果符合非故障类型时转换为第二类特征码。将设定时间段与第一类标签及第一类特征码进行关联，以形成故障检测用例集51中的一个用例，将设定时间段与第一类标签及第二类特征码进行关联，以形成正常用例集52中的一个用例。
使用整理组件40进行归类标记以形成故障恢复用例集53具体为：执行组件80执行动作库501中的动作，并通知整理组件40执行所述动作及时间段，进行归类标记以形成第二类标签，并将所述动作在执行前后所对应的时间段从采集组件30获取的API返回结果的变化转换为第三类特征码，并最终通过整理组件40将第二类标签、时间段与第三类特征码进行关联，以形成故障恢复用例集53中的一个实例。执行组件80通过交互组件70向数据库50发起调用最佳故障检测模型的请求并发送至云主机21，以对云主机21进行故障恢复。
其中，在本实施例中，上文所述的“动作”包括云主机21的重启系统服务的动作、该云主机21所依赖的物理机(PM)重启的动作、重置服务配置的动作、网络配置的动作、其他节点的重启或者恢复的动作等其他动作。
参图1与图4所示，学习组件60训练得到最佳故障检测模型具体为：学习组件60提取故障检测用例集51并按照设定比例将故障检测用例集51中的用例划分为故障检测训练集511、故障检测验证集512与故障检测测试集513，并基于机器学习算法训练得到最佳故障检测模型；其中，故障检测训练集511、故障检测验证集512与故障检测测试集513的划分比例为：8:1:1。机器学习算法为决策树算法、朴素贝叶斯算法、最小二乘法、支持向量机算法、聚类算法、主成分分析法或者独立成分分析法，在本实施例中，申请人具体选用朴素贝叶斯算法。在本实施例中，该故障检测用例集51、正常用例集52及故障恢复用例集53均保存于数据库50。
基于朴素贝叶斯算法获得最佳故障检测模型的具体的过程参图1所示，首先，执行步骤S100：使用故障检测训练集511训练模型，该模型即上述“”，并具体为将故障检测训练集511中用例的第一类标签和第一类特征码拆分整理，以得到m个分类模型样本。每个模型样本包含n个第一类标签，例如：((x(1)1,x(1)2,...x(1)n,y1),(x(2)1,x(2)2,...x(2)n,y2),...(x(m)1,x(m)2,...x(m)n,yn)))，对应会有K个类别的第一类特征码,即第一类特征码C1,第一类特征码C2,...,第一类特征码CK。使用这些分类模型样本(下述公式(一)中简 称“样本”)，根据朴素贝叶斯算法计算出不同类别对应的第一类标签出现的概率P(Y＝Ck|X＝X(test))和类别推断公式参式(一)所示：
上述式(一)中，参数Y＝Ck：表示第一类特征码对应的第K个类别；
参数Xj＝Xj (test)：表示样本X(test)的第j维标签；
参数Cresult：表示样本X(test)的分类；
参数argmax：表示参数Ck最大化的类别。
然后，执行步骤S101：使用故障检测训练集511评估模型，并具体为：将故障机检测验证集512中的用例对应的第一类标签代入到类别推断公式，确定推断类别是否包含第一类特征码来验证公式和概率的精准性。
然后，执行步骤S102：根据故障检测训练集511评估结果调整模型，并具体为：分别将不同第一类特征码与其对应的出现概率大于超参数概率(在本实施例中，超参数概率为20％)的第一类标签的集合进行合并作为检测模型，将故障检测测试集513的用例与检测模型比较，确定超参数(出现概率)是否需要调整。当故障检测测试集513中用例的第一类特征码匹配，但是故障检测测试集513中用例的第一类标签集中有不包含则调大超参数概率，重新将对应的第一类标签进行过滤，得到新的检测模型，继续将故障检测测试集513中的用例与检测模型进行比较，直到满足要求，即故障检测测试集513中的匹配的第一类特征码对应的。
最后，执行步骤S103：选择最佳故障检测模型，并具体为：将上一步调整过的检测模型作为最佳检测模型，即将不同第一类特征码与其对应的出现概率大于等于调整过的超参数概率的第一类标签的集合，作为最佳故障检模型。同时，明确这个最佳模型是由不同特征码和对应的第一类标签的一个集合。
交互组件70接收自定义故障输入，以对数据库50中留存的最佳故障检测模型进行更新；其中，最佳故障检测模型的数量仅为一个。该最佳故障检测模型同样保存至数据库50中，且其数量也可以两个或者多个，至少通过上述机器学习算法筛选一个最佳的故障检测模型，以供后期的对发生的真正的故障进行恢复提供科学决策。参图3所示，管理员1可通过交互组件70向数据库50发起查询操作或者修改操作的请求，以实时地查询数据库50中的故障测试用例51和正常用例集52中的实例。当某个时间段内的云平台没有新的异常故障发生时，凡是没有被采集组件30采集并纳入故障测试用例中时，均可通过管理员1根据异常故障发生的时间段，通过交互组件70查询出某个特定的异常故障所对应的用例，并通过交互组件70将该异常故障所对应的用例通过管理员1以手动方式添加至故障测试用例集51中。
当学习组件60感知到有新的异常故障所对应的用例加入到故障测试用例集51中时，可通过上文所揭示的机器学习算法训练得到最佳故障检测模型，并重新写入数据库50中，并优选的，对数据库50中之前保存的最佳故障检测模型进行覆盖，从而在数据库50中仅保留一个最适合当前云平台异常故障检测恢复所依赖的最佳故障检测模型。
更具体的，在本实施例中，自定义故障输入为向所述交互组件70输入未被故障检测用例集51所列入的新的故障用例，所述自定义故障输入由管理员1和/或用户以本地操作或者异地操作的形式向交互组件70进行输入，以对最佳故障检测模型中的用例进行更新，从而得到更新后的最佳故障检测模型。
因此，在实施例中，所述最佳故障检测模型为更新后的最佳故障检测模型，并且所谓的最佳故障检测模型均是一个动态变化的，并在云平台中云主机21的生命周期中，对始终保证该最佳故障检测模型是云主机21进行异常故障检测恢复的过程中最匹配的那个模型，以提高对云主机21所发生的真正需要恢复的故障的恢复效果。
接下来，申请人对如何使用数据库50中所保存到的故障检测用例集51、正常用例集52、故障恢复用例集53以及最佳故障检测模型或者更新后的最佳故障检测模型对云主机21所发生的各种故障执行恢复的过程进行阐述。需要说明的是，云主机21所表征的各种故障并非是真正需要排除或者恢复的故障(理由参前文或者背景技术部分所述)。
在本实施例中，监控组件90自数据库50中获取当前的最佳故障检测模型，并将第一类标签及第一类特征码作为整体与整理组件40实时采集到的云主机21的第一类标签及第一类特征码进行同类型对比；
当完全匹配时，将该云主机21的状态判定为故障；
当不完全匹配时，将该云主机21的状态判定为正常(即使在管理员1看来，这种不完全匹配也是“故障”，但是于此场景中的“故障”是不要恢复或者给予排除的)。
当第一类标签及第一类特征码作为整体与整理组件40实时采集到的云主机21的第一类标签及第一类特征码进行同类型对比且当不完全匹配时，将整理组件40实时采集到的云主机21的第一类标签及第一类特征码添加至正常用例集52。
具体的，申请人对上述所谓“完全匹配”与“不完全匹配”的判断过程在下文中展开阐述。
参图4所示，在本实施例中，故障检测用例集51所包含的一个或者多个用例具第二类特征码及第一类标签，正常用例集52中的一个或者多个用例具第一类特征码及第一类标签，故障恢复用例集53中的一个或者多个用例具第三类特征码、第二类标签及作用时间段。
为方便表述，申请人将初始“第一类标签”重新命名为“A类标签”，将实时采集到的“第一类标签”重新命名为“A1类标签”。将初始“第一类特征码”重新命名为“B类特征码”，将实时采集到的第一类特征码”重新命名为“B1类特征码”，将作用时间段内实时采集到的第一类特征码”重新命名为“B2类特征码”。该“B类特征码”、“B1类特征码”及“B2类特征码”均是被整理组件40认定为存在故障的API返回结果，该“C类特征码”是被整理组件40认定为不存在故障的API返回结果。“Bn类特征码”是当不完全匹配时且故障没有完全恢复成功并通过学习组件60采用机器学习算法对最佳故障检测模型更新后与“B类特征码”匹配成功的当前第一类特征码，其中，下标n为大于或者等于2的正整数。将初始“第二类特征码”重新命名为“C类特征码”。将“第二类标签”重新命名为“D类标签”。将“第三类特征码”重新命名为“E类特征码”。
监控组件90部署在云平台的控制节点10，监控组件90从数据库50获取最佳故障检测模型，监控组件90将最佳的故障异常检测模型中的A类标签和B类特征码与整理组件40中实时采集到的A1类标签和B1类特征码进行对比，该对比具体为：将A类标签与A1类标签进行比对，B类特征码与B1类特征码进行比对，具体参图3中虚线双向箭头所示，并存在以下1)～4)种情形。
1)当A类标签和A1类标签，B类特征码和B1类特征码完全匹配时则判定为命中故障，监控组件90则判定发生异常。监控组件90从数据库50中获取最佳故障恢复模型，将故障异常检查模型中的B类特征码与最佳故障恢复模型的E类特征码进行匹配，并产生下述a)与b)两种情况。
a)若B1类特征码包含在E类特征码中(小于等于)，则判定命中最佳故障恢复模型。监控组件90从数据库50中获取最佳故障恢复模型的D类标签和作用时间段。监控组件90通过D类标签从数据库50中获取D类标签对应的故障恢复动作。通过监控组件90将故障恢复动作发送给执行组件80，由执行组件80远程调用系统命令执行恢复动作(如重启系统服务，重启物理机，重置服务配置，将虚拟机在其他节点恢复等，重启网络等等)，监控组件90从整理组件40中获取对应作用时间段所实时采集到的B2类特征码，将B2类特征码分别与B1类特征码及正常用例集52中的C类特征码按照下述序号ⅰ、ⅱ、ⅲ、ⅳ进行匹配：
i.当B2类特征码与B1类特征码不匹配，并且B2类特征码与C类特征码匹配，表示故障恢复动作成功，云主机21的故障已经解除。监控组件90将A类标签，B类特征码和D类标签作为一组成功恢复用例存储到数据库50的成功记录中。
ii.当B2类特征码与B1类特征码匹配，并且B2类特征码与C类特征码匹配，则表示云主机21的故障恢复动作不成功，并且正常用例集52和故障检测用例集51存在分歧数据，此时，将A类标签、B类特征码、作用时间段、D类标签和C类特征码作为一组不能成功恢复的用例存储到数据库50的异常记录中，供管理员1后期排查故障恢复失败的原因以及分歧数据的手工调整，并具体为：将指定时段类同特征码的数据进行正确归类，并进行重新学习。
iii.当B2类特征码与B1类特征码匹配，并且B2类特征码与C类特征码不匹配，则表示故障恢复动作不成功，将A类标签、B类特征码、作用时间段和D类标签作为一组不能成功恢复的用例存储到数据库50的失败记录中，供管理员1后期排查原因。
iv.当B2类特征码与B1类特征码不匹配，并且B2类特征码与C类特征码不匹配，则表示云主机21的故障没有完全恢复成功，监控组件90继续将B2类特征码匹配与B类特征码进行匹配，重新执行上面的1)中a)和b)的匹配过程(循环执行)，直到Bn类特征码成功匹配该正常用例集52中的C类特征码，才表示故障恢复成功，监控组件90将A类标签、B类特征码、所有的作用时间段和所有的D类标签作为一组自动恢复成功用例存储到数据库50中；否则，即Bn类特征码不匹配C类特征码，则表示故障恢复失败，监控组件90将A类标签、所有的Bn类特征码、所有的作用时间段和所有的D类标签作为一组不能成功恢复的用例存储到数据库50的异常记录中，供管理员后1期排查优化；作为更优选的实施方式，可根据实际情况可采用通过交互组件70增加新的故障恢复动作或者其他方式来解决。
b)若B1类特征码不包含在E类特征码中，则判定未匹配最佳故障恢复模型。监控组件90将A类标签和B1类特征码作为一组不能成功的数据存储到数据库50的异常记录中，供管理员1后期排查优化；作为更优选的实施方式，根据实际情况可采用通过交互组件70增加新的故障恢复动作以解决。
2)当A类标签和A1类标签匹配，B类特征码和B1类特征码不匹配时，则判定当前状态未命中最佳故障检测模型(或者更新后的最佳故障检测模型)，也没有故障产生。监控组件90再将A1类标签和B1类特征码与正常用例集52中的A类标签和C类特征码进行匹配，即将A1类标签与A类标签匹配，B1类特征码与C类特征码匹配，并产生下述c)与d)两种情况。
c)当A1类标签与A类标签完全匹配，B1类特征码与C类特征码完全配置，则表示环境正常，表示没有新的正常用例产生，不执行任何动作。
d)当A1类标签与A类标签不匹配或者B1类特征码与C类特征码不匹配的情况(包含三种情况：1.A1类标签与A类标签不匹配但B1类特征码与C类特征匹配，2.A1标签与A类标签匹配但B类特征码与C类特征码不匹配，3.A1类标签与A类标签不匹配且B类特征码与C类特征均不匹配)，则这三种情况均表示环境正常，但又新的正常用例产生，监控组件90将A1类标签和B1类特征码存储到数据库50的正常用例集52中。
3)当A类标签和A1类标签不匹配，B类特征码和B1类特征码匹配时，则判定当前状态未命中最佳故障检测模型或者更新后的最佳故障检测模型，但实际已经有故障产生。监控组件90将对应时间段、A1类标签和B1类特征码作为新的测试用例放到数据库50的故障检测用例集51中，供学习组件60继续训练学习，学习组件60训练学习后产生新的最佳故障检测模型覆盖原有最佳故障检测模型(具体参上文所述)。监控组件90继续将B1类特征码与E类特征码进行匹配，继续顺序执行进行情形1)中a)和b)同样的流程。
4)当A类标签和A1类标签不匹配，B类特征码和B1类特征码不匹配时，则判定当前状态未命中故障，将A1类标签和B1类特征码与正常用例集52中的A类标签和B类特征码进行匹配，即将A1类标签与A类标签匹配，B1类特征码与B类特征码匹配，并产生下述e)与f)两种情况。
e)当A1类标签与A类标签完全匹配，B1类特征码与C类特征码完全匹配，则表示环境正常，且没有新的正常用例产生。
f)当A1类标签与A类不匹配或者B1类特征码与C类特征码不匹配的情况(包含三种情况：1.A1类标签与A类标签不匹配但B1类特征码与C类特征码匹配，2.A1类标签与A类标签匹配但B类特征码与C类特征码不匹配，3.A1类标签与A类标签不匹配同时B类特征码与C类特征码也不匹配)，则表示无法判定环境情况，监控组件90将A1类标签、B1类特征码和时间段(监控组件90从整理组件40中获取)作为一组无法判定情况的故障检测用例存储到数据库50的异常记录中，供管理员1后期排查优化并可根据时间段实际的环境情况，通过交互平台，将这组无法判定情况的故障检测用例作为新数据调整到正常用例集52中或者调整到故障检测用例集51中。
基于此，实施例一所揭示的一种云主机异常故障检测恢复系统能够对计算节点20中的任意一个或者多个云主机所表征的故障进行科学地判断，具有自动学习并更新最佳故障检测模型的功能，以最终通过执行组件80向云主机远程调用系统命令执行故障恢复动作。
实施例二：
参图2所示，本实施例与实施例一所揭示的一种云主机异常故障检测恢复系统相比，其主要区别在于，在本实施例中，在步骤S103之后还包括步骤S104：对最佳故障检测模型进行更新，并具体为：交互组件70接收自定义故障输入，以对数据库50中留存的最佳故障检测模型进行更新；其中，最佳故障检测模型的数量仅为一个。至少通过上述实施例一所揭示的机器学习算法筛选一个最佳的故障检测模型，以供后期的对发生的真正的故障进行恢复提供科学决策。需要明确的是，在本申请中所指的“最佳故障检测模型”是指某一个状态下的检测模型，并可随整个系统的自主学习或者管理员1的自定义配置进行持续更新，以更好地匹配异常故障的检测。
本实施例与实施例一中相同部分的技术方案，请参实施例一所述，在此不再赘述
实施例三：
参图5所示，本实施例基于实施例一所揭示的一种云主机异常故障检测恢复系统所实现。该云主机异常故障检测恢复方法，包括以下步骤：
步骤S1、通过采集组件30采集状态数据，使用整理组件40进行归类标记以形成故障检测用例集与正常用例集；
步骤S2、通过学习组件60提取故障检测用例集，训练得到最佳故障检测模型并发送至数据库50；
步骤S3、交互组件70调用执行组件80以执行动作库501中的动作，通知并使用整理组件(40)进行归类标记以形成故障恢复用例集；
步骤S4、通过监控组件90自数据库50获取最佳故障检测模型，并与整理组件(40)实时采集的状态数据进行对比，在对比成功后，调用故障检测用例集中的实例，以对云主机进行故障标定；
其中，采集组件30部署于控制节点10或者计算节点20中；
数据库50、学习组件60、交互组件70、执行组件80及监控组件90仅部署于控制节点10中。
本实施例与实施例一和/或实施例二中相同部分的技术方案，请参实施例一和/或实施例二所述，在此不再赘述。
实施例四：
本实施例公开了一种云平台，包括：
至少一个计算节点20，所述计算节点20中被配置出至少一个云主机(即图3中的云主机21至云主机2i，其中，“i”为大于或者等于1的正整数)，控制节点10，以及如实施例一或者实施例二所揭示的云主机异常故障检测恢复系统。该云平台可是IaaS类型的云平台，也可以是的PaaS类型的云平台或者SaaS类型的云平台。
本实施例与实施例一至实施例三中任意一项或者几项的结合所具有的相同部分的技术方案，请参实施例一至实施例三所述，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用以限制本发明的保护范围，凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。

Claims (16)

1.云主机异常故障检测恢复系统，其特征在于，包括：采集组件(30)，整理组件(40)、内置动作库(501)的数据库(50)、学习组件(60)、交互组件(70)、执行组件(80)及监控组件(90)；
采集组件(30)采集状态数据，使用整理组件(40)进行归类标记以形成故障检测用例集与正常用例集；
学习组件(60)提取故障检测用例集，训练得到最佳故障检测模型并发送至数据库(50)；
交互组件(70)调用执行组件(80)以执行动作库(501)中的动作，通知并使用整理组件(40)进行归类标记以形成故障恢复用例集；
监控组件(90)自数据库(50)获取最佳故障检测模型，并与整理组件(40)实时采集的状态数据进行对比，在对比成功后，调用故障检测用例集中的实例，以对云主机进行故障标定。
2.根据权利要求1所述的云主机异常故障检测恢复系统，其特征在于，所述采集组件(30)部署于控制节点(10)或者计算节点(20)中；
所述数据库(50)、学习组件(60)、交互组件(70)、执行组件(80)及监控组件(90)仅部署于控制节点(10)中。
3.根据权利要求1所述的云主机异常故障检测恢复系统，其特征在于，所述状态数据由系统基础数据、系统服务日志及API返回结果共同描述；
所述系统基础数据由CPU资源占用率、内存占用率、网卡流量中的至少一种构成；
所述API返回结果由具体的云主机与计算节点(20)中其他的云主机之间或者控制节点(10)之间所形成的数据；
所述系统服务日志为“/var/log/”目录中的日志文件。
4.根据权利要求3所述的云主机异常故障检测恢复系统，其特征在于，所述使用整理组件(40)进行归类标记以形成故障检测用例集与正常用例集具体为：
整理组件(40)在设定时间段内的系统基础数据及系统服务日志进行转换标签处理，以形成第一类标签；
将相同的设定时间段内的API返回结果进行转换标签处理，当API返回结果符合故障类型时转换为第一类特征码，当API返回结果符合非故障类型时转换为第二类特征码；
将设定时间段与第一类标签及第一类特征码进行关联，以形成故障检测用例集中的一个用例，将设定时间段与第一类标签及第二类特征码进行关联，以形成正常用例集中的一个用例。
5.根据权利要求3所述的云主机异常故障检测恢复系统，其特征在于，所述学习组件(60)训练得到最佳故障检测模型具体为：
所述学习组件(60)提取故障检测用例集并按照设定比例将故障检测用例集中的用例划分为故障检测训练集、故障检测验证集与故障检测测试集，并基于机器学习算法训练得到最佳故障检测模型；
其中，故障检测训练集、故障检测验证集与故障检测测试集的划分比例为：8:1:1。
6.根据权利要求5所述的云主机异常故障检测恢复系统，其特征在于，所述机器学习算法为决策树算法、朴素贝叶斯算法、最小二乘法、支持向量机算法、聚类算法、主成分分析法或者独立成分分析法。
7.根据权利要求1所述的云主机异常故障检测恢复系统，其特征在于，所述交互组件(70)接收自定义故障输入，以对数据库(50)中留存的最佳故障检测模型进行更新；其中，所述最佳故障检测模型的数量仅为一个。
8.根据权利要求1所述的云主机异常故障检测恢复系统，其特征在于，所述故障检测用例集、正常用例集及故障恢复用例集均保存于数据库(50)。
9.根据权利要求1或者8所述的云主机异常故障检测恢复系统，其特征在于，使用整理组件(40)进行归类标记以形成故障恢复用例集具体为：
执行组件(80)执行动作库(501)中的动作，并通知整理组件(40)执行所述动作及时间段，进行归类标记以形成第二类标签，并将所述动作在执行前后所对应的时间段从采集组件(30)获取的API返回结果的变化转换为第三类特征码，并最终通过整理组件(40)将第二类标签、时间段与第三类特征码进行关联，以形成故障恢复用例集中的一个实例。
10.根据权利要求1至4中任一项所述的云主机异常故障检测恢复系统，其特征在于，所述执行组件(80)通过交互组件(70)向数据库(50)发起调用最佳故障检测模型的请求并发送至云主机，以对云主机进行故障恢复。
11.根据权利要求10所述的云主机异常故障检测恢复系统，其特征在于，所述最佳故障检测模型为更新后的最佳故障检测模型。
12.根据权利要求7所述的云主机异常故障检测恢复系统，其特征在于，所述自定义故障输入为向所述交互组件(70)输入未被故障检测用例集所列入的新的故障用例，所述自定义故障输入由管理员和/或用户以本地操作或者异地操作的形式向交互组件(70)进行输入，以对最佳故障检测模型中的用例进行更新，从而得到更新后的最佳故障检测模型。
13.根据权利要求1所述的云主机异常故障检测恢复系统，其特征在于，所述监控组件(90)自数据库(50)中获取当前的最佳故障检测模型，并将第一类标签及第一类特征码作为整体与整理组件(40)实时采集到的云主机的第一类标签及第一类特征码进行同类型对比；
当完全匹配时，将该云主机的状态判定为故障；
当不完全匹配时，将该云主机的状态判定为正常。
14.根据权利要求13所述的云主机异常故障检测恢复系统，其特征在于，当第一类标签及第一类特征码作为整体与整理组件(40)实时采集到的云主机的第一类标签及第一类特征码进行同类型对比且当不完全匹配时，将整理组件(40)实时采集到的云主机的第一类标签及第一类特征码添加至正常用例集。
15.一种云主机异常故障检测恢复方法，其特征在于，包括以下步骤：
S1、通过采集组件(30)采集状态数据，使用整理组件(40)进行归类标记以形成故障检测用例集与正常用例集；
S2、通过学习组件(60)提取故障检测用例集，训练得到最佳故障检测模型并发送至数据库(50)；
S3、交互组件(70)调用执行组件(80)以执行动作库(501)中的动作，通知并使用整理组件(40)进行归类标记以形成故障恢复用例集；
S4、通过监控组件(90)自数据库(50)获取最佳故障检测模型，并与整理组件(40)实时采集的状态数据进行对比，在对比成功后，调用故障检测用例集中的实例，以对云主机进行故障标定；
其中，所述采集组件(30)部署于控制节点(10)或者计算节点(20)中；
所述数据库(50)、学习组件(60)、交互组件(70)、执行组件(80)及监控组件(90)仅部署于控制节点(10)中。
16.一种云平台，其特征在于，包括：
至少一个计算节点(20)，所述计算节点(20)中被配置出至少一个云主机，控制节点(10)，
以及如权利要求1至8中任一项所述的云主机异常故障检测恢复系统。
CN201811422877.4A 2018-11-27 2018-11-27 云主机异常故障检测恢复系统、方法及云平台 Active CN109522095B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201811422877.4A CN109522095B (zh) 2018-11-27 2018-11-27 云主机异常故障检测恢复系统、方法及云平台

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811422877.4A CN109522095B (zh) 2018-11-27 2018-11-27 云主机异常故障检测恢复系统、方法及云平台

Publications (2)

Publication Number Publication Date
CN109522095A true CN109522095A (zh) 2019-03-26
CN109522095B CN109522095B (zh) 2020-04-10

Family

ID=65794544

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811422877.4A Active CN109522095B (zh) 2018-11-27 2018-11-27 云主机异常故障检测恢复系统、方法及云平台

Country Status (1)

Country Link
CN (1) CN109522095B (zh)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110515365A (zh) * 2019-07-29 2019-11-29 电子科技大学 一种基于过程挖掘的工控系统异常行为分析方法
CN110716818A (zh) * 2019-09-30 2020-01-21 腾讯科技（深圳）有限公司 一种异常处理方法、装置、硬件保护设备及存储介质
CN111176591A (zh) * 2020-01-03 2020-05-19 深信服科技股份有限公司 基于cups系统的打印审计方法、装置、设备及介质
CN111475320A (zh) * 2020-03-31 2020-07-31 苏州浪潮智能科技有限公司 一种计算平台的高可用性检测方法、计算平台及存储介质
WO2021009547A1 (en) * 2019-07-17 2021-01-21 Ng Sin Yan Kitty Systems and methods for optimizing continuity of operations
CN112583611A (zh) * 2019-09-27 2021-03-30 北京金山云网络技术有限公司 一种获取故障信息的方法、装置、电子设备及介质
CN112749053A (zh) * 2020-12-14 2021-05-04 北京同有飞骥科技股份有限公司 一种基于云平台的智能故障监听及智能修复管理系统
WO2021109048A1 (zh) * 2019-12-05 2021-06-10 深圳先进技术研究院 一种容器云平台异常检测方法、系统及电子设备
CN113811829A (zh) * 2019-04-11 2021-12-17 斯凯孚公司 使用在线机器学习检测和预测机器故障

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101060444A (zh) * 2007-05-23 2007-10-24 西安交大捷普网络科技有限公司 基于贝叶斯统计模型的网络异常检测方法
CN102394774A (zh) * 2011-10-31 2012-03-28 广东电子工业研究院有限公司 云计算操作系统的控制器服务状态监控和故障恢复方法
CN104090951A (zh) * 2014-07-04 2014-10-08 李阳 一种异常数据的处理方法
CN104657250A (zh) * 2014-12-16 2015-05-27 无锡华云数据技术服务有限公司 一种对云主机进行性能监控的监控方法
CN106775929A (zh) * 2016-11-25 2017-05-31 中国科学院信息工程研究所 一种虚拟化平台安全监控方法及系统
CN106790186A (zh) * 2016-12-30 2017-05-31 中国人民解放军信息工程大学 基于多源异常事件关联分析的多步攻击检测方法
JP2017111486A (ja) * 2015-12-14 2017-06-22 富士通株式会社 予兆検知プログラム、装置、及び方法
CN107491375A (zh) * 2017-08-18 2017-12-19 国网山东省电力公司信息通信公司 一种云计算环境下的设备检测及故障预警系统及方法
CN107579858A (zh) * 2017-09-28 2018-01-12 厦门集微科技有限公司 云主机的告警方法及装置、通信系统
CN108833131A (zh) * 2018-04-25 2018-11-16 北京百度网讯科技有限公司 分布式数据库云服务的系统、方法、设备和计算机存储介质

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101060444A (zh) * 2007-05-23 2007-10-24 西安交大捷普网络科技有限公司 基于贝叶斯统计模型的网络异常检测方法
CN102394774A (zh) * 2011-10-31 2012-03-28 广东电子工业研究院有限公司 云计算操作系统的控制器服务状态监控和故障恢复方法
CN104090951A (zh) * 2014-07-04 2014-10-08 李阳 一种异常数据的处理方法
CN104657250A (zh) * 2014-12-16 2015-05-27 无锡华云数据技术服务有限公司 一种对云主机进行性能监控的监控方法
JP2017111486A (ja) * 2015-12-14 2017-06-22 富士通株式会社 予兆検知プログラム、装置、及び方法
CN106775929A (zh) * 2016-11-25 2017-05-31 中国科学院信息工程研究所 一种虚拟化平台安全监控方法及系统
CN106790186A (zh) * 2016-12-30 2017-05-31 中国人民解放军信息工程大学 基于多源异常事件关联分析的多步攻击检测方法
CN107491375A (zh) * 2017-08-18 2017-12-19 国网山东省电力公司信息通信公司 一种云计算环境下的设备检测及故障预警系统及方法
CN107579858A (zh) * 2017-09-28 2018-01-12 厦门集微科技有限公司 云主机的告警方法及装置、通信系统
CN108833131A (zh) * 2018-04-25 2018-11-16 北京百度网讯科技有限公司 分布式数据库云服务的系统、方法、设备和计算机存储介质

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
幸生: "《人民检察院文件检验工作细则释义》", 30 April 2015, 中国检察出版社 *
黄婕: "基于云计算的故障检测方法研究与实现", 《中国优秀硕士学位论文全文数据库 信息科技辑》 *

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113811829A (zh) * 2019-04-11 2021-12-17 斯凯孚公司 使用在线机器学习检测和预测机器故障
WO2021009547A1 (en) * 2019-07-17 2021-01-21 Ng Sin Yan Kitty Systems and methods for optimizing continuity of operations
CN110515365A (zh) * 2019-07-29 2019-11-29 电子科技大学 一种基于过程挖掘的工控系统异常行为分析方法
CN110515365B (zh) * 2019-07-29 2021-07-06 电子科技大学 一种基于过程挖掘的工控系统异常行为分析方法
CN112583611A (zh) * 2019-09-27 2021-03-30 北京金山云网络技术有限公司 一种获取故障信息的方法、装置、电子设备及介质
CN110716818B (zh) * 2019-09-30 2022-02-11 腾讯科技（深圳）有限公司 一种异常处理方法、装置、硬件保护设备及存储介质
CN110716818A (zh) * 2019-09-30 2020-01-21 腾讯科技（深圳）有限公司 一种异常处理方法、装置、硬件保护设备及存储介质
WO2021109048A1 (zh) * 2019-12-05 2021-06-10 深圳先进技术研究院 一种容器云平台异常检测方法、系统及电子设备
CN111176591A (zh) * 2020-01-03 2020-05-19 深信服科技股份有限公司 基于cups系统的打印审计方法、装置、设备及介质
CN111176591B (zh) * 2020-01-03 2024-05-24 深信服科技股份有限公司 基于cups系统的打印审计方法、装置、设备及介质
CN111475320A (zh) * 2020-03-31 2020-07-31 苏州浪潮智能科技有限公司 一种计算平台的高可用性检测方法、计算平台及存储介质
CN111475320B (zh) * 2020-03-31 2022-08-19 苏州浪潮智能科技有限公司 一种计算平台的高可用性检测方法、计算平台及存储介质
CN112749053A (zh) * 2020-12-14 2021-05-04 北京同有飞骥科技股份有限公司 一种基于云平台的智能故障监听及智能修复管理系统

Also Published As

Publication number Publication date
CN109522095B (zh) 2020-04-10

Similar Documents

Publication Publication Date Title
CN109522095A (zh) 云主机异常故障检测恢复系统、方法及云平台
Chen et al. Towards intelligent incident management: why we need it and how we make it
US10445738B1 (en) Detecting a transaction volume anomaly
US8346931B2 (en) Conditional computer runtime control of an information technology environment based on pairing constructs
US10997063B1 (en) System testing from production transactions
CN103853595B (zh) 用于替换虚拟机盘的方法和系统
CN106130809B (zh) 一种基于日志分析的IaaS云平台网络故障定位方法及系统
US7165189B1 (en) Distributed test framework for clustered systems
US20170161059A1 (en) Management of multiple application programming interface versions for development environments
US8751283B2 (en) Defining and using templates in configuring information technology environments
US9558459B2 (en) Dynamic selection of actions in an information technology environment
US8763006B2 (en) Dynamic generation of processes in computing environments
US8428983B2 (en) Facilitating availability of information technology resources based on pattern system environments
US20090172470A1 (en) Managing processing of a computing environment during failures of the environment
US20080140817A1 (en) System and method for performance problem localization
US20090171730A1 (en) Non-disruptively changing scope of computer business applications based on detected changes in topology
US20090172669A1 (en) Use of redundancy groups in runtime computer management of business applications
US20220027257A1 (en) Automated Methods and Systems for Managing Problem Instances of Applications in a Distributed Computing Facility
US10817267B2 (en) State machine representation of a development environment deployment process
US8578337B2 (en) Method and system for quality assurance subscription service
US20090171703A1 (en) Use of multi-level state assessment in computer business environments
CN106201552A (zh) 一种软件升级方法、客户端、服务器及系统
CN102436376A (zh) 用于分布式应用确认的模型检查
WO2007104044A2 (en) Systems and methods for managing business issues
CN102609789A (zh) 图书馆信息监控与异常预测系统

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
CP01 Change in the name or title of a patent holder

Address after: 214000, science and software park, Binhu District, Jiangsu, Wuxi 6

Patentee after: Huayun data holding group Co., Ltd

Address before: 214000, science and software park, Binhu District, Jiangsu, Wuxi 6

Patentee before: WUXI CHINAC DATA TECHNICAL SERVICE Co.,Ltd.

CP01 Change in the name or title of a patent holder