CN110716842A - 集群故障检测方法和装置 - Google Patents
集群故障检测方法和装置 Download PDFInfo
- Publication number
- CN110716842A CN110716842A CN201910953290.4A CN201910953290A CN110716842A CN 110716842 A CN110716842 A CN 110716842A CN 201910953290 A CN201910953290 A CN 201910953290A CN 110716842 A CN110716842 A CN 110716842A
- Authority
- CN
- China
- Prior art keywords
- cluster
- service
- node
- abnormal
- upstream
- 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
Links
- 238000001514 detection method Methods 0.000 title claims abstract description 102
- 238000011144 upstream manufacturing Methods 0.000 claims abstract description 175
- 230000002159 abnormal effect Effects 0.000 claims abstract description 170
- 238000000034 method Methods 0.000 claims abstract description 34
- 238000012544 monitoring process Methods 0.000 claims description 50
- 230000008439 repair process Effects 0.000 claims description 22
- 238000004458 analytical method Methods 0.000 claims description 21
- 230000005856 abnormality Effects 0.000 claims description 20
- 230000001419 dependent effect Effects 0.000 claims description 6
- 238000004891 communication Methods 0.000 claims description 3
- 238000007689 inspection Methods 0.000 abstract description 74
- 238000005516 engineering process Methods 0.000 abstract description 2
- 238000010586 diagram Methods 0.000 description 11
- 238000007726 management method Methods 0.000 description 10
- 230000006870 function Effects 0.000 description 7
- 238000012545 processing Methods 0.000 description 6
- 241001024304 Mino Species 0.000 description 4
- 230000008569 process Effects 0.000 description 4
- 238000013515 script Methods 0.000 description 3
- 230000003111 delayed effect Effects 0.000 description 2
- 230000036541 health Effects 0.000 description 2
- 238000013024 troubleshooting Methods 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004140 cleaning Methods 0.000 description 1
- 238000013480 data collection Methods 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 238000011895 specific detection Methods 0.000 description 1
- 230000004083 survival effect Effects 0.000 description 1
Images
Classifications
-
- 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/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3055—Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3089—Monitoring arrangements determined by the means or processing involved in sensing the monitored data, e.g. interfaces, connectors, sensors, probes, agents
Abstract
本公开是关于一种集群故障检测方法和装置。涉及计算机互联网技术，解决了人工巡检和部署专用代理巡检无法在集群规模较大及多集群场景中满足复杂巡检需求的问题。该方法包括：在集群内节点中检测服务异常的服务异常节点；当检测到所述服务异常节点时，获取与所述服务异常节点所属集群存在第一依赖关系的至少一个上游服务集群；检测各个所述上游服务集群的服务状态信息，所述服务状态信息指示所述上游服务器集群服务正常或服务异常。本公开提供的技术方案适用于大规模集群巡检场景，实现了对服务复杂度高的网络环境下的高效、准确的巡检。
Description
技术领域
本公开涉及计算机互联网技术，尤其涉及一种集群检测方法和装置。
背景技术
一般的巡检方式只能获取到节点服务的运行状态，然后通过其他方式展示，由于只有服务级别的巡检，一旦发现问题，需要查看服务日志或者相关监控，由人工排查定位故障；在涉及到多集群的情况下，还需要在若干系统上来回切换以排查问题。随着服务的复杂度不断升高，集群中的服务器甚至增加到达了上万台的规模，巡检难度随之增高。
可通过部署多个代理巡检执行模块作为节点巡检的渠道，形成分布式的巡检系统进行自动巡检。中心模块将巡检任务分配给多个代理巡检执行模块，每个代理巡检执行模块连接有若干节点，代理巡检执行模块将巡检任务发送至其连接的节点中执行巡检。
但在集群规模较大及多集群场景中，通过部署专用的节点巡检渠道实现过于复杂，成本过高。在这样的场景下，人工巡检的工作量更是过大，导致故障无法被及时发现，故障排除严重滞后，网络性能受损，极大的影响了用户体验。
发明内容
为克服相关技术中存在的问题，本公开提供一种集群故障检测方法和装置。
根据本公开实施例的第一方面，提供一种集群故障检测方法，包括：
在集群内节点中检测服务异常的服务异常节点；
当检测到所述服务异常节点时，获取与所述服务异常节点所属集群存在第一依赖关系的至少一个上游服务集群；
检测各个所述上游服务集群的服务状态信息，所述服务状态信息指示所述上游服务器集群服务正常或服务异常。
进一步的，所述在集群内节点中检测服务异常的服务异常节点，包括：
获取集群索引，所述集群索引指示所述集群内部拓扑结构，所述集群内部拓扑结构包括：集群内的全部节点和各节点间的连接关系；
通过监测系统获取所述集群内各个节点的工作状态信息，所述监测系统至少包括以下平台中的任一或任意多个：
集群主节点、分布式布置与监控系统、机器报障系统、机器状态检测设备、分布式版本控制系统、关键指标监控系统，
其中，所述集群主节点提供其所属集群内各节点的服务状态信息，所述机器报障系统提供节点的报修信息，所述机器状态检测设备提供节点的连通性信息和/或硬件性能信息，所述分布式版本控制系统提供节点的服役情况信息，所述关键指标监控系统提供节点级和集群级的关键指标；
根据所述工作状态信息，确定所述服务异常节点。
进一步的，所述根据所述工作状态信息，确定所述服务异常节点，包括以下至少一项：
根据所述集群内各节点的服务状态信息，将服务状态异常的节点确定为所述服务异常节点；
根据所述集群内各节点的服役情况信息，将退役节点确定为所述服务异常节点；
根据所述集群内各节点的报修信息，将处于报修中的节点确定为所述服务异常节点；
根据所述集群内的各节点的连通性信息，将发生连通异常的节点确定为所述服务异常节点；
根据所述集群内的各节点的硬件性能信息，将发生硬件异常的节点确定为所述服务异常节点。
进一步的，该方法还包括：
获取各集群所述提供的服务之间的第二依赖关系，所述第二依赖关系包括以下至少一项：下游服务调用上游服务、所述下游服务以所述上游服务的输出作为输入；
将提供所述下游服务的集群确定为下游服务集群，将提供所述上游服务的集群确定为上游服务集群；
基于所述下游服务集群和所述上游服务集群所提供的服务之间的第二依赖关系，确定所述下游服务集群和所述上游服务集群之间的第一依赖关系。
进一步的，所述获取与所述服务异常节点所属集群存在第一依赖关系的至少一个上游服务集群，包括：
获取所述第一依赖关系；
根据所述第一依赖关系确定所述服务异常节点所属集群作为下游服务集群时对应的至少一个上游服务集群。
进一步的，所述服务状态信息包含集群级关键指标的检测结果，所述检测各个所述上游服务集群的服务状态信息，包括：
获取各个所述上游服务集群的预置的集群级关键指标的检测结果；
根据所述集群级关键指标的检测结果，确定各个所述上游服务集群服务正常或服务异常。
进一步，该方法还包括：
在存在至少一个服务异常的上游服务集群的情况下，确定所述上游服务集群的服务异常构成了所述服务异常节点发生服务异常的原因。
进一步的，该方法还包括：
获取存在第一依赖关系的多个集群的集群级关键指标的检测结果；
根据所述检测结果，发现存在服务异常的上游服务集群；
将所述上游服务集群服务异常的信息发送给所述上游服务集群的下游服务集群。
根据本公开实施例的第二方面，提供一种集群故障检测装置，包括：
节点异常检测模块，用于在集群内节点中检测服务异常的服务异常节点；
上游服务确定模块，用于当检测到所述服务异常节点时，获取与所述服务异常节点所属集群存在第一依赖关系的至少一个上游服务集群；
上游服务检测模块，用于检测各个所述上游服务集群的服务状态信息，所述服务状态信息指示所述上游服务器集群服务正常或服务异常。
进一步的，所述节点异常检测模块包括：
集群内部结构分析子模块，用于获取集群索引，所述集群索引指示所述集群内部拓扑结构，所述集群内部拓扑结构包括：集群内的全部节点和各节点间的连接关系；
信息收集子模块，用于通过监测系统获取所述集群内各个节点的工作状态信息，所述监测系统至少包括以下平台中的任一或任意多个：
集群主节点、分布式布置与监控系统、机器报障系统、机器状态检测设备、分布式版本控制系统、关键指标监控系统，
其中，所述集群主节点提供其所属集群内各节点的服务状态信息，所述机器报障系统提供节点的报修信息，所述机器状态检测设备提供节点的连通性信息和/或硬件性能信息，所述分布式版本控制系统提供节点的服役情况信息，所述关键指标监控系统提供节点级和集群级的关键指标；
服务异常节点确定子模块，用于根据所述工作状态信息，确定所述服务异常节点。
进一步的，该装置还包括：
服务依赖关系解析模块，用于获取各集群所述提供的服务之间的第二依赖关系，所述第二依赖关系包括以下至少一项：下游服务调用上游服务、所述下游服务以所述上游服务的输出作为输入；
集群确定模块，用于将提供所述下游服务的集群确定为下游服务集群，将提供所述上游服务的集群确定为上游服务集群；
集群依赖关系解析模块，用于基于所述下游服务集群和所述上游服务集群所提供的服务之间的第二依赖关系，确定所述下游服务集群和所述上游服务集群之间的第一依赖关系。
进一步的，所述上游服务确定模块包括：
集群关系解析模块，用于获取所述第一依赖关系；
上游集群确定模块，用于根据所述第一依赖关系确定所述服务异常节点所属集群作为下游服务集群时对应的至少一个上游服务集群。
进一步的，所述服务状态信息包含集群级关键指标的检测结果，所述上游服务检测模块包括：
指标获取子模块，用于获取各个所述上游服务集群的预置的集群级关键指标的检测结果；
上游服务分析子模块，用于根据所述集群级关键指标的检测结果，确定各个所述上游服务集群服务正常或服务异常。
进一步的，该装置还包括：
异常原因分析模块，用于在存在至少一个服务异常的上游服务集群的情况下，确定所述上游服务集群的服务异常构成了所述服务异常节点发生服务异常的原因。
进一步的，该装置还包括：
依赖集群指标获取模块，用于获取存在依赖关系的多个集群的集群级关键指标的检测结果；
异常集群发现模块，用于根据所述检测结果，发现存在服务异常的上游服务集群；
异常预警模块，用于通知所述上游服务集群的下游服务集群所述上游服务集群服务异常。
根据本公开实施例的第三方面，提供一种计算机装置，包括：
处理器；
用于存储处理器可执行指令的存储器；
其中，所述处理器被配置为：
在集群内节点中检测服务异常的服务异常节点；
当检测到所述服务异常节点时，获取与所述服务异常节点所属集群存在第一依赖关系的至少一个上游服务集群；
检测各个所述上游服务集群的服务状态信息，所述服务状态信息指示所述上游服务器集群服务正常或服务异常。
根据本公开实施例的第四方面，提供一种非临时性计算机可读存储介质，当所述存储介质中的指令由移动终端的处理器执行时，使得移动终端能够执行一种集群故障检测方法，所述方法包括：
在集群内节点中检测服务异常的服务异常节点；
当检测到所述服务异常节点时，获取与所述服务异常节点所属集群存在第一依赖关系的至少一个上游服务集群；
检测各个所述上游服务集群的服务状态信息，所述服务状态信息指示所述上游服务器集群服务正常或服务异常。
本公开的实施例提供的技术方案可以包括以下有益效果：在集群内节点中检测服务异常的服务异常节点，在检测到服务异常节点时，进一步的获取与所述服务异常节点所属集群存在第一依赖关系的至少一个上游服务集群，并检测各个所述上游服务集群的服务状态信息，所述服务状态信息指示所述上游服务器集群服务正常或服务异常。通过在集群内和集群间自动巡检进行服务状态分析，解决了人工巡检和部署专用代理巡检无法在集群规模较大及多集群场景中满足复杂巡检需求的问题，实现了对服务复杂度高的网络环境下的高效、准确的巡检。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。
图1是根据一示例性实施例示出的一种集群故障检测方法的流程图。
图2是根据一示例性实施例示出的一种集群故障检测方法的流程图。
图3是根据一示例性实施例示出的一种集群故障检测方法的流程图。
图4是根据一示例性实施例示出的一种集群故障检测方法的流程图。
图5是根据一示例性实施例示出的一种集群故障检测方法的流程图。
图6是根据一示例性实施例示出的一种集群故障检测方法的流程图。
图7是根据一示例性实施例示出的一种集群故障检测装置的框图。
图8是图7中节点异常检测模块701的一种示例性结构框图。
图9是图7中上游服务确定模块702的一种示例性结构框图。
图10是图7中上游服务检测模块703的一种示例性结构框图。
图11是根据一示例性实施例示出的一种装置的框图(服务器的一般结构)。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。
一般的巡检方式只能获取到节点服务的运行状态，然后通过其他方式展示，由于只有服务级别的巡检，一旦发现问题，需要查看服务日志或者相关监控，由人工排查定位故障；在涉及到多集群的情况下，还需要在若干系统上来回切换以排查问题。随着服务的复杂度不断升高，集群中的服务器甚至增加到达了上万台的规模，巡检难度随之增高。
巡检分为低级、中级、高级三种方式：
低级：通过人工的方式，登录机器，检查机器和服务的信息指标是否异常；登录服务的WEB页面，检查服务信息。此种方式适用于小规模服务器集群，巡检时间成本伴随集群规模的增大而不断增加。
中级：通过半自动/自动脚本检查机器/服务常规指标，效率有一定提升，但随着服务类型增加，服务的复杂度也断上升，此种巡检方式适用于产品复杂度低的服务。虽然通过自动化解决了一部分人工效率的问题，但产品复杂度提高后问题排查难度会不断增加。
高级：通过企业化的服务管理软件进行巡检管理。此种方式费用高昂，并且系统无法进行个性化变更，对接企业内部系统比较困难。
在执行可通过部署多个代理巡检执行模块作为节点巡检的渠道，形成分布式的巡检系统进行自动巡检。中心模块将巡检任务分配给多个代理巡检执行模块，每个代理巡检执行模块连接有若干节点，代理巡检执行模块将巡检任务发送至其连接的节点中执行巡检。
但在集群规模较大及多集群场景中，通过部署专用的节点巡检渠道实现过于复杂，成本过高。在这样的场景下，人工巡检的工作量更是过大，导致故障无法被及时发现，故障排除严重滞后，网络性能受损，极大的影响了用户体验。
为了解决上述问题，本公开的实施例提供了一种集群故障检测方法和装置，在集群内进行巡检发现服务异常节点后，进一步的获取与所述服务异常节点所属集群存在依赖关系的至少一个上游服务集群，并检测各个所述上游服务集群的服务状态。通过在集群内和集群间自动巡检进行服务状态分析，解决了人工巡检和部署专用代理巡检无法在集群规模较大及多集群场景中满足复杂巡检需求的问题，实现了对服务复杂度高的网络环境下的高效、准确的巡检。
本公开的一示例性实施例提供了一种集群故障检测方法，使用该方法完成巡检的流程如图1所示，包括：
步骤101、在集群内节点中检测服务异常的服务异常节点。
本步骤中，在各集群内分别进行集群内服务异常的服务异常节点检测。
通过监测系统获取集群内各节点的工作状态信息，不需要登录节点即可获取，避免了登录节点(尤其是免密登录)操作的安全性和稳定性较差的问题。监测系统持续对多集群中的全部节点进行监测，其获取的数据是全面实时的。通过监测系统获取节点的工作状态信息，能够实现批量获取，提升了巡检的效率，降低了大规模集群和多集群场景下巡检的复杂度。
步骤102、当检测到所述服务异常节点时，获取与所述服务异常节点所属集群存在第一依赖关系的至少一个上游服务集群。
本步骤中，在发现集群内存在服务异常节点时，除所述工作状态信息中包含的可能导致该服务异常节点发生服务异常的原因之外，进一步的，还可在集群层面上，依据集群所提供的服务间的第二依赖关系，获取集群间的第一依赖关系，为后续进行进一步检测提供基础。
具体的，首先获取所述第一依赖关系，然后根据所述第一依赖关系确定所述服务异常节点所属集群作为下游服务集群时对应的至少一个上游服务集群。
步骤103、检测各个所述上游服务集群的服务状态信息。
本步骤中，在检测到服务异常节点后，对其归属的集群对应的一个或多个上游服务集群，也进行服务状态信息的检测，所述服务状态信息指示所述上游服务器集群服务正常或服务异常。获取各个所述上游服务集群的预置的集群级关键指标的检测结果，然后根据所述集群级关键指标的检测结果，确定各个所述上游服务集群服务正常或服务异常。
可预置一系列集群级关键指标和各关键指标对应的告警阈值，在关键指标达到所述告警阈值时判定集群存在服务异常。由于下游服务集群的业务依赖于上游服务集群，因此在上游服务集群存在异常的情况下，该异常很可能是下游服务集群中节点出现服务异常的原因。通过检测各个所述上游服务集群的服务状态信息，能够全面发现造成故障等服务异常情况出现的原因，准确定位故障位置，有利于后续高效的排除故障，保障服务。
在检测各个上游服务集群的服务状态，并发现存在至少一个服务异常的上游服务集群的情况下，确定所述上游服务集群的服务异常构成了所述服务异常节点发生服务异常的原因。
进一步的，可将该上游服务集群的服务异常通知该上游服务集群的管理平台和/或服务异常节点归属集群的管理平台。
本公开实施例中，可将巡检功能布置于任意节点上，由节点进行集群故障检测。对于一个集群来说，该布置有巡检功能的节点可以是集群内的节点，也可以是集群外的节点。
本公开实施例提供的技术方案，大幅降低了巡检的时间、人力等成本，并且基于服务上下游之间的关系，提高问题排查速度。作为具体检测标准的集群级关键指标可根据需求配置，可完全对接企业内部系统进行个性化定制。
本公开的一示例性实施例还提供了一种集群故障检测方法，通过监测系统获取集群内各节点的工作状态信息，完成对大规模集群和多集群中节点工作状态的监测，具体流程如图2所示，包括：
步骤201、获取集群索引。
所述集群索引指示所述集群内部拓扑结构，所述集群内部拓扑结构包括：集群内的全部节点和各节点间的连接关系。
本步骤中，可从分布式布置与监控系统获取集群索引，例如通过python yaml/config的方式解析minos配置，得到集群的主节点(例如master节点)；或，通过爬虫的方式抓取docs文档(docs文档为集群的索引文档)获取master节点的地址信息(地址信息包含IP地址和端口)。
在确定集群的主节点后，由于有些集群为了保证高可用性配置有2个主节点，此时，可首先判断两个主节点中哪一个是活跃的主节点，例如通过解析主节点上的Jave管理扩展模块(jmx)获取主节点信息并据此来判断该主节点是否是活跃(active)的主节点。在确定活跃的主节点后，自该主节点获取其所属集群中所有异常和正常的节点，得到集群内部拓扑结构，可通过字典的形式描述拓扑结构，其中包含多个条目：服务-集群名-节点名。
在集群内拓扑结构发生变化时，可重新确定主节点并由主节点获取集群内部拓扑结构。
本步骤中，可获取一个集群的索引，也可获取多个集群的集群索引。
步骤202、通过监测系统获取所述集群内各个节点的工作状态信息。
本步骤中，由监测系统获取各节点的工作状态信息，无需登录各节点，避免了由于ssh异常导致无法登录的问题，且不存在服务器之间免密登录带来的安全隐患。
所述监测系统包含多个平台，通过这些平台，收集至少一个集群的各节点工作状态信息。监测系统的成员可根据网络情况增加或删减。
所述监测系统至少包括以下平台中的任一或任意多个：
集群主节点、分布式布置与监控系统、机器报障系统、机器状态检测设备、分布式版本控制系统、关键指标监控系统，
其中，所述集群主节点提供其所属集群内各节点的服务状态信息，具体的，提供集群内节点服务状态正常或服务状态正常的信息。
所述机器报障系统提供节点的报修信息。可依临时指令获取，也可预置如周期性获取的时间规则，后续依规则获取。由于机器报修是一个长事务，整个报修过程包含“已报修、待诊断、已确诊、维修完成、归档”这5种中间状态，并且各中间状态均会持续一段时间。在机器报障系统，记录有各节点的报修信息，详细记录了各节点所处的中间状态。通过连接机器报障系统，即可获取报障系统接口数据，对报障系统接口数据解析和清洗后，可得到包含多个“键值(key)－报修信息(value)”的键值对的报修信息，key是机器名，value是所处的中间状态。
所述机器状态检测设备提供节点的连通性信息和/或硬件性能信息。所述机器状态检测设备可集成于中控机和/或集群内任意服务器上，进行连通性检测和机器硬件检测。
在进行连通性检测时，通过脚本并发检测各节点ping通信结果及22端口(ssh服务使用)存活情况。若其中任意一个结果不符合预期(即为非正常值)，则标记为相应节点连通性异常。
在进行硬件检测时，如通过中控机进行，则对所有节点使用并发脚本采集机器dmesg信息，统一上报到执行巡检的节点的数据收集接口中。如通过集群内配置有硬件检测代理的服务器进行，则通过post机器名的方式获取节点的异常信息，具体的，可在代理机器上部署程序封装访问机器的管理卡，在获取机器硬件信息时，只需要对接口post节点的机器名，如下举例所示：
http://url/api/v2/host/<hostname>
相应的返回值为：
[{"description":"内存故障","detail":"DIMM B2","hostname":"主机名",}]。
所述分布式版本控制系统提供节点的服役情况信息。由于集群内节点的JAVA管理扩展(jmx)接口在集群服务器下线后并不会更新，而会显示成dead状态，因此需要比对如Git等分布式版本控制系统中的集群配置(例如minos配置，minos配置在集群中节点上下线后会立即更新)，因此，通过解析minos配置即可获取节点的服役情况信息，检测节点为服役中或退役。
所述关键指标监控系统提供节点级和集群级的关键指标。本公开中，可根据实际应用需求，配置节点级和集群级的关键指标，可配置多个关键指标，还可配置各关键指标对应的阈值条件，在一关键指标的值达到相应的阈值条件时，判定该关键指标异常。
在完成信息收集后，通过进一步处理，即可获取各个节点的工作状态信息。具体的，可通过机器管理系统提供的接口，清洗出包含节点的机器名在内的工作状态信息。
本公开实施例中，可将巡检功能布置于任意节点上，由节点进行集群故障检测。对于一个集群来说，该布置有巡检功能的节点可以是集群内的节点，也可以是集群外的节点。
具有巡检功能的节点，可进行对一个集群或多个集群的巡检以发现集群内故障。通过包含多种平台的监测系统获取节点的工作状态信息。对于不同的集群或服务，可使用多进程进行并发巡检，每个进程执行对一个服务/集群的巡检。
步骤203、根据所述工作状态信息，确定所述服务异常节点。
本步骤中，根据从监测系统各平台获取的工作状态信息，分析确定是否存在服务异常节点。
本公开的一示例性实施例还提供了一种集群故障检测方法，使用该方法根据各节点的工作状态信息确定服务异常节点具体包括如下方式：
1、获取所述集群内各节点的服务状态信息，根据所述服务状态信息，将服务状态异常的节点确定为所述服务异常节点。
2、获取所述集群内各节点的服役情况信息，根据所述服役情况信息，将退役节点确定为所述服务异常节点。
3、获取所述集群内各节点的报修信息，根据所述报修信息，将处于报修中的节点确定为所述服务异常节点。
4、获取所述集群内的各节点的连通性信息，根据所述连通性信息，将发生连通异常的节点确定为所述服务异常节点。优选的，在节点发生连通性异常时，可直接指示相关节点进行重启操作。
5、获取所述集群内的各节点的硬件性能信息，根据所述硬件性能信息，将发生硬件异常的节点确定为所述服务异常节点。优选的，在节点发生硬件异常时，可直接对相关节点进行报修处理。
需要说明是，上述1至5所提供的5种确定服务异常节点的方式之间并无严格的时序关系，且可根据一种方式确定一个服务异常节点，也可根据多种方式共同确定一个服务异常节点。
对于确定的服务异常节点，可构建一个集合，每个服务异常节点对应集合中的一个条目，以下为一种条目数据结构的举例：
服务－集群名－节点名－机型－操作系统版本－连通情况信息－硬件异常信息。
优选的，可将所有服务异常节点的集合持久化到MySQL表中，后续使用SQL即可实现对历史数据的回溯分析。
本公开实施例中，可将巡检功能布置于任意节点上，由节点进行集群故障检测。对于一个集群来说，该布置有巡检功能的节点可以是集群内的节点，也可以是集群外的节点。
本公开的一示例性实施例还提供了一种集群故障检测方法，发现提供不同服务的集群间的依赖关系，为后续进行更为准确的故障原因分析和故障定位提供依据，具体流程如图3所示，包括：
步骤301、获取各集群所述提供的服务之间的第二依赖关系。
本公开实施例中，所述第二依赖关系包括以下至少一项：下游服务调用上游服务、所述下游服务以所述上游服务的输出作为输入。
本步骤中，由分布式布置与监控系统(如minos配置中)解析出各服务之间的上下游关系，得到服务之间的第二依赖关系。例如，OPENTSDB服务依赖于HBASE，HBASE又依赖于HDFS。
在服务间第二依赖关系发生变化(如上下游关系变化、增加或减少服务集群)的情况下，能够及时发现变化，根据监测系统提供的信息，及时更新依赖关系。
步骤302、将提供所述下游服务的集群确定为下游服务集群，将提供所述上游服务的集群确定为上游服务集群。
步骤303、基于所述下游服务集群和所述上游服务集群所提供的服务之间的第二依赖关系，确定所述下游服务集群和所述上游服务集群之间的第一依赖关系。
本步骤中，进一步的，根据服务与支撑该服务的集群的对应关系，获得集群间的第一依赖关系。
本公开的一示例性实施例还提供了一种集群故障检测方法，在发现服务异常节点后，检测各个上游服务集群的服务状态的流程如图4所示，包括：
步骤401、获取各个上游服务集群的预置的集群级关键指标的检测结果。
本公开中，可根据实际应用需求，配置节点级和集群级的关键指标，可配置多个关键指标，还可配置各关键指标对应的阈值条件，在一关键指标的值达到相应的阈值条件时，判定该关键指标异常。
在发现服务异常节点后，即可进一步的根据第一依赖关系，获取该服务异常节点归属集群的上游服务集群的集群级关键指标的检测结果。集群级关键指标可为集群提供的服务的健康度，例如丢包率、文件写入成功率等。
集群级关键指标和节点级关键指标可配置于关键指标监控系统中，由关键指标监控系统完成关键指标的采集，并提供给巡检系统。
步骤402、根据所述集群级关键指标的检测结果，确定各个所述上游服务集群的服务状态为服务正常或服务异常。
本步骤中，将获取的检测结果与集群级关键指标的阈值条件进行比对，以判定服务状态为服务正常或服务异常。例如对于提供分布式文件系统(HDFS)的上游服务集群，在文件写入成功率低于95％这一阈值条件时，即判定该上游服务集群服务异常；否则，判定该上游服务集群服务正常。
本公开的一示例性实施例还提供了一种集群故障检测方法，对于服务正常节点，还可进行检测，以确定是否存在故障隐患，具体流程如图5所示，包括：
步骤501、获取所述集群内除所述服务异常节点外的服务正常节点的节点级关键指标的检测结果。
可根据步骤202中自集群主节点服务状态信息确定服务正常节点，具体的，可以服务正常的节点作为服务正常节点。也可以根据步骤202中获取的工作状态信息中的任一或任意多项为依据，确定服务正常节点。
本步骤中，获取服务正常节点的节点级关键指标，检测服务正常节点是否存在其他隐患。具体的，向关键指标监控系统的rest接口发送请求，在请求中可包括所请求的节点级关键指标的计量标准(metric)、终端(endpoint)和标签(tag)等，获取节点级的关键指标，关键指标的数值可为周期为一天的平均值和max/min值。节点极关键指标可以是节点的服务表现指标，也可以是硬件指标。
步骤502、根据所述检测结果，分析所述服务正常节点的故障可能性。
本步骤中，根据服务正常节点的节点级关键指标对应的阈值条件，判定该节点级关键指标是否异常。并在存在一个或多个节点级关键指标异常的情况下，判定相应的服务正常节点存在故障可能性。
也可构建服务正常节点的集合，使用以下条目数据结构，记录服务正常节点的信息并持久化保存：
服务－集群名－节点名－机型－操作系统版本－连通情况信息－硬件异常信息。
本公开的一示例性实施例还提供了一种集群故障检测方法，可对多个存在依赖关系的集群进行分析，检测上游服务集群的服务状态，为发现存在故障的集群提供基础，具体流程如图6所示，包括：
步骤601、获取存在第一依赖关系的多个集群的集群级关键指标的检测结果。
本步骤中，可自关键指标监控系统获取存在第一依赖关系的多个集群的集群级关键指标，在集群服务级别上检测集群是否存在异常。
根据步骤302形成的集群间第一依赖关系，确定多个存在依赖关系的集群。具体的，向关键指标监控系统的rest接口发送请求，进行对存在第一依赖关系的多个集群的集群级关键指标的获取。
步骤602、根据所述检测结果，发现存在服务异常的上游服务集群。
集群级关键指标和对应的阈值条件可根据实际应用需求配置，可根据集群提供的服务的特征来设置关键指标。例如对提供HDFS的集群，设置文件写入成功率为一个集群级关键指标，阈值条件为达到95％判定为正常。或，可模拟用户角度，为服务进行打分评价，以服务的评分作为关键性指标，设置一个分数作为阈值条件，例如对服务的健康度在0－100分的范围内打分，以低于99分为阈值条件，在低于99分时判定服务异常。
步骤603、将所述上游服务集群服务异常的信息发送给所述上游服务集群的下游服务集群。
如存在第一依赖关系的下游服务集群A和上游服务集群B，获取A依赖的B的集群级关键指标的检测结果，在B异常的情况下，判定有可能造成A的异常。据此，可将B及A的管理平台推送通知消息，B和A可根据该通知启动对集群内部的巡检。
本公开的实施例中，对于服务异常节点、服务正常节点、集群服务正常、集群服务异常的判定结果，均可持久化保存，如保存至MySQL、键值数据库(KV)存储或关系型数据库存储中，后续可对历史数据进行回溯分析，例如找到历史中报修最多的节点机型、找到集群级关键指标最不稳定的集群等等。
具体的，可读取持久化的服务异常节点和服务正常节点两类数据，分别对各类数据聚合排序后生成服务级别的巡检报表。根据服务异常节点的数据生成异常数据巡检报表，根据服务正常节点的数据生成正常数据巡检报表。由于对服务正常节点巡检涉及到的节点数据量非常大，可根据步骤502的结果进行进一步划分，在正常数据巡检报表中只展示存在故障可能性的服务正常节点的信息。
优选的，将上述报表推送至涉及的集群的管理平台，并且对于服务异常节点提供批量报修接口供批量报修操作使用。
本公开的一示例性实施例还提供了一种集群故障检测装置，其结构如图7所示，包括：
节点异常检测模块701，用于在集群内节点中检测服务异常的服务异常节点；
上游服务确定模块702，用于当检测到所述服务异常节点时，获取与所述服务异常节点所属集群存在第一依赖关系的至少一个上游服务集群；
上游服务检测模块703，用于检测各个所述上游服务集群的服务状态信息，所述服务状态信息指示所述上游服务器集群服务正常或服务异常。
优选的，所述节点异常检测模块701的结构如图8所示，包括：
集群内部结构分析子模块7011，用于获取集群索引，所述集群索引指示所述集群内部拓扑结构，所述集群内部拓扑结构包括：集群内的全部节点和各节点间的连接关系；
信息收集子模块7012，用于通过监测系统获取所述集群内各个节点的工作状态信息，所述监测系统至少包括以下平台中的任一或任意多个：
集群主节点、分布式布置与监控系统、机器报障系统、机器状态检测设备、分布式版本控制系统、关键指标监控系统，
其中，所述集群主节点提供其所属集群内各节点的服务状态信息，所述机器报障系统提供节点的报修信息，所述机器状态检测设备提供节点的连通性信息和/或硬件性能信息，所述分布式版本控制系统提供节点的服役情况信息，所述关键指标监控系统提供节点级和集群级的关键指标；
服务异常节点确定子模块7013，用于根据所述工作状态信息，确定所述服务异常节点。
优选的，该装置还包括：
服务依赖关系解析模块704，用于获取各集群所述提供的服务之间的第二依赖关系，所述第二依赖关系包括以下至少一项：下游服务调用上游服务、所述下游服务以所述上游服务的输出作为输入；
集群确定模块705，用于将提供所述下游服务的集群确定为下游服务集群，将提供所述上游服务的集群确定为上游服务集群；
集群依赖关系解析模块706，用于基于所述下游服务集群和所述上游服务集群所提供的服务之间的第二依赖关系，确定所述下游服务集群和所述上游服务集群之间的第一依赖关系。
优选的，所述上游服务确定模块702的结构如图9所示，包括：
集群关系解析模块7021，用于获取所述第一依赖关系；
上游集群确定模块7022，用于根据所述第一依赖关系确定所述服务异常节点所属集群作为下游服务集群时对应的至少一个上游服务集群。
优选的，所述服务状态信息包含集群级关键指标的检测结果，所述上游服务检测模块703的结构如图10所示，包括：
指标获取子模块7031，用于获取各个所述上游服务集群的预置的集群级关键指标的检测结果；
上游服务分析子模块7032，用于根据所述集群级关键指标的检测结果，确定各个所述上游服务集群服务正常或服务异常。
优选的，该装置还包括：
异常原因分析模块707，用于在存在至少一个服务异常的上游服务集群的情况下，确定所述上游服务集群的服务异常构成了所述服务异常节点发生服务异常的原因。
优选的，该装置还包括：
依赖集群指标获取模块708，用于获取存在依赖关系的多个集群的集群级关键指标的检测结果；
异常集群发现模块709，用于根据所述检测结果，发现存在服务异常的上游服务集群；
异常预警模块710，用于通知所述上游服务集群的下游服务集群所述上游服务集群服务异常。
关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。
本公开的一示例性实施例还提供了一种计算机装置，包括：
处理器；
用于存储处理器可执行指令的存储器；
其中，所述处理器被配置为：
在集群内节点中检测服务异常的服务异常节点；
当检测到所述服务异常节点时，获取与所述服务异常节点所属集群存在第一依赖关系的至少一个上游服务集群；
检测各个所述上游服务集群的服务状态信息，所述服务状态信息指示所述上游服务器集群服务正常或服务异常。
本公开的一示例性实施例还提供了一种非临时性计算机可读存储介质，当所述存储介质中的指令由移动终端的处理器执行时，使得移动终端能够执行一种集群故障检测方法，所述方法包括：
在集群内节点中检测服务异常的服务异常节点；
当检测到所述服务异常节点时，获取与所述服务异常节点所属集群存在第一依赖关系的至少一个上游服务集群；
检测各个所述上游服务集群的服务状态信息，所述服务状态信息指示所述上游服务器集群服务正常或服务异常。
图11是根据一示例性实施例示出的一种用于集群故障检测的装置1100的框图。例如，装置1100可以被提供为一服务器。参照图11，装置1100包括处理组件1122，其进一步包括一个或多个处理器，以及由存储器1132所代表的存储器资源，用于存储可由处理组件1122的执行的指令，例如应用程序。存储器1132中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件1122被配置为执行指令，以执行上述方法。
装置1100还可以包括一个电源组件1126被配置为执行装置1100的电源管理，一个有线或无线网络接口1150被配置为将装置1100连接到网络，和一个输入输出(I/O)接口1158。装置1100可以操作基于存储在存储器1132的操作系统，例如Windows ServerTM，MacOS XTM，UnixTM,LinuxTM，FreeBSDTM或类似。
本公开的实施例提供了一种集群故障检测方法和装置，在集群内节点中检测服务异常的服务异常节点，在检测到服务异常节点时，进一步的获取与所述服务异常节点所属集群存在第一依赖关系的至少一个上游服务集群，并检测各个所述上游服务集群的服务状态信息，所述服务状态信息指示所述上游服务器集群服务正常或服务异常。通过在集群内和集群间自动巡检进行服务状态分析，解决了人工巡检和部署专用代理巡检无法在集群规模较大及多集群场景中满足复杂巡检需求的问题，实现了对服务复杂度高的网络环境下的高效、准确的巡检。
在配置完成后，进行集群故障检测的巡检系统完全自动化，无需人工干预，且巡检效率提升，提升了巡检效率，减少了巡检消耗的时间。可由任何节点服务器执行，无需配置专门的巡检代理，降低了巡检的配置要求，提高了方案的扩展性和易用性。
在巡检时，会检测收集服务上下游的全部实时数据，可靠性高，由于信息完全透明，对于明显异常的节点，在进行服务异常排查时可快速、准确定位，找到异常原因。
对于服务正常节点，会检测其是否有发生故障的可能性，并可据此进行预警，进一步提升了服务可靠性。
持久化了集群故障检测过程中的收集和生成的数据，供后续分析回溯使用。
对不同集群，可采取多线程的方式，每个线程执行一个集群的巡检，可对多个集群进行同步巡检，收集上下游服务集群的信息。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由下面的权利要求指出。
应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。
Claims (17)
1.一种集群故障检测方法，其特征在于，包括：
在集群内节点中检测服务异常的服务异常节点；
当检测到所述服务异常节点时，获取与所述服务异常节点所属集群存在第一依赖关系的至少一个上游服务集群；
检测各个所述上游服务集群的服务状态信息，所述服务状态信息指示所述上游服务器集群服务正常或服务异常。
2.根据权利要求1所述的方法，其特征在于，所述在集群内节点中检测服务异常的服务异常节点，包括：
获取集群索引，所述集群索引指示所述集群内部拓扑结构，所述集群内部拓扑结构包括：集群内的全部节点和各节点间的连接关系；
通过监测系统获取所述集群内各个节点的工作状态信息，所述监测系统至少包括以下平台中的任一或任意多个：
集群主节点、分布式布置与监控系统、机器报障系统、机器状态检测设备、分布式版本控制系统、关键指标监控系统，
其中，所述集群主节点提供其所属集群内各节点的服务状态信息，所述机器报障系统提供节点的报修信息，所述机器状态检测设备提供节点的连通性信息和/或硬件性能信息，所述分布式版本控制系统提供节点的服役情况信息，所述关键指标监控系统提供节点级和集群级的关键指标；
根据所述工作状态信息，确定所述服务异常节点。
3.根据权利要求2所述的方法，其特征在于，所述根据所述工作状态信息，确定所述服务异常节点，包括以下至少一项：
根据所述集群内各节点的服务状态信息，将服务状态异常的节点确定为所述服务异常节点；
根据所述集群内各节点的服役情况信息，将退役节点确定为所述服务异常节点；
根据所述集群内各节点的报修信息，将处于报修中的节点确定为所述服务异常节点；
根据所述集群内的各节点的连通性信息，将发生连通异常的节点确定为所述服务异常节点；
根据所述集群内的各节点的硬件性能信息，将发生硬件异常的节点确定为所述服务异常节点。
4.根据权利要求1所述的方法，其特征在于，该方法还包括：
获取各集群所述提供的服务之间的第二依赖关系，所述第二依赖关系包括以下至少一项：下游服务调用上游服务、所述下游服务以所述上游服务的输出作为输入；
将提供所述下游服务的集群确定为下游服务集群，将提供所述上游服务的集群确定为上游服务集群；
基于所述下游服务集群和所述上游服务集群所提供的服务之间的第二依赖关系，确定所述下游服务集群和所述上游服务集群之间的第一依赖关系。
5.根据权利要求4所述的方法，其特征在于，所述获取与所述服务异常节点所属集群存在第一依赖关系的至少一个上游服务集群，包括：
获取所述第一依赖关系；
根据所述第一依赖关系确定所述服务异常节点所属集群作为下游服务集群时对应的至少一个上游服务集群。
6.根据权利要求5所述的方法，其特征在于，所述服务状态信息包含集群级关键指标的检测结果，所述检测各个所述上游服务集群的服务状态信息，包括：
获取各个所述上游服务集群的预置的集群级关键指标的检测结果；
根据所述集群级关键指标的检测结果，确定各个所述上游服务集群服务正常或服务异常。
7.根据权利要求6所述的方法，其特征在于，该方法还包括：
在存在至少一个服务异常的上游服务集群的情况下，确定所述上游服务集群的服务异常构成了所述服务异常节点发生服务异常的原因。
8.根据权利要求4所述的集群故障检测方法，其特征在于，该方法还包括：
获取存在第一依赖关系的多个集群的集群级关键指标的检测结果；
根据所述检测结果，发现存在服务异常的上游服务集群；
将所述上游服务集群服务异常的信息发送给所述上游服务集群的下游服务集群。
9.一种集群故障检测装置，其特征在于，包括：
节点异常检测模块，用于在集群内节点中检测服务异常的服务异常节点；
上游服务确定模块，用于当检测到所述服务异常节点时，获取与所述服务异常节点所属集群存在第一依赖关系的至少一个上游服务集群；
上游服务检测模块，用于检测各个所述上游服务集群的服务状态信息，所述服务状态信息指示所述上游服务器集群服务正常或服务异常。
10.根据权利要求9所述的装置，其特征在于，所述节点异常检测模块包括：
集群内部结构分析子模块，用于获取集群索引，所述集群索引指示所述集群内部拓扑结构，所述集群内部拓扑结构包括：集群内的全部节点和各节点间的连接关系；
信息收集子模块，用于通过监测系统获取所述集群内各个节点的工作状态信息，所述监测系统至少包括以下平台中的任一或任意多个：
集群主节点、分布式布置与监控系统、机器报障系统、机器状态检测设备、分布式版本控制系统、关键指标监控系统，
其中，所述集群主节点提供其所属集群内各节点的服务状态信息，所述机器报障系统提供节点的报修信息，所述机器状态检测设备提供节点的连通性信息和/或硬件性能信息，所述分布式版本控制系统提供节点的服役情况信息，所述关键指标监控系统提供节点级和集群级的关键指标；
服务异常节点确定子模块，用于根据所述工作状态信息，确定所述服务异常节点。
11.根据权利要求9所述的装置，其特征在于，该装置还包括：
服务依赖关系解析模块，用于获取各集群所述提供的服务之间的第二依赖关系，所述第二依赖关系包括以下至少一项：下游服务调用上游服务、所述下游服务以所述上游服务的输出作为输入；
集群确定模块，用于将提供所述下游服务的集群确定为下游服务集群，将提供所述上游服务的集群确定为上游服务集群；
集群依赖关系解析模块，用于基于所述下游服务集群和所述上游服务集群所提供的服务之间的第二依赖关系，确定所述下游服务集群和所述上游服务集群之间的第一依赖关系。
12.根据权利要求11所述的装置，其特征在于，所述上游服务确定模块包括：
集群关系解析模块，用于获取所述第一依赖关系；
上游集群确定模块，用于根据所述第一依赖关系确定所述服务异常节点所属集群作为下游服务集群时对应的至少一个上游服务集群。
13.根据权利要求12所述的装置，其特征在于，所述服务状态信息包含集群级关键指标的检测结果，所述上游服务检测模块包括：
指标获取子模块，用于获取各个所述上游服务集群的预置的集群级关键指标的检测结果；
上游服务分析子模块，用于根据所述集群级关键指标的检测结果，确定各个所述上游服务集群服务正常或服务异常。
14.根据权利要求9所述的装置，其特征在于，该装置还包括：
异常原因分析模块，用于在存在至少一个服务异常的上游服务集群的情况下，确定所述上游服务集群的服务异常构成了所述服务异常节点发生服务异常的原因。
15.根据权利要求11所述的装置，其特征在于，该装置还包括：
依赖集群指标获取模块，用于获取存在依赖关系的多个集群的集群级关键指标的检测结果；
异常集群发现模块，用于根据所述检测结果，发现存在服务异常的上游服务集群；
异常预警模块，用于通知所述上游服务集群的下游服务集群所述上游服务集群服务异常。
16.一种计算机装置，其特征在于，包括：
处理器；
用于存储处理器可执行指令的存储器；
其中，所述处理器被配置为：
在集群内节点中检测服务异常的服务异常节点；
当检测到所述服务异常节点时，获取与所述服务异常节点所属集群存在第一依赖关系的至少一个上游服务集群；
检测各个所述上游服务集群的服务状态信息，所述服务状态信息指示所述上游服务器集群服务正常或服务异常。
17.一种非临时性计算机可读存储介质，当所述存储介质中的指令由移动终端的处理器执行时，使得移动终端能够执行一种集群故障检测方法，所述方法包括：
在集群内节点中检测服务异常的服务异常节点；
当检测到所述服务异常节点时，获取与所述服务异常节点所属集群存在第一依赖关系的至少一个上游服务集群；
检测各个所述上游服务集群的服务状态信息，所述服务状态信息指示所述上游服务器集群服务正常或服务异常。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910953290.4A CN110716842B (zh) | 2019-10-09 | 2019-10-09 | 集群故障检测方法和装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910953290.4A CN110716842B (zh) | 2019-10-09 | 2019-10-09 | 集群故障检测方法和装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110716842A true CN110716842A (zh) | 2020-01-21 |
| CN110716842B CN110716842B (zh) | 2023-11-21 |
Family
ID=69212337
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910953290.4A Active CN110716842B (zh) | 2019-10-09 | 2019-10-09 | 集群故障检测方法和装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110716842B (zh) |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111488289A (zh) * | 2020-04-26 | 2020-08-04 | 支付宝实验室(新加坡)有限公司 | 一种故障定位方法、装置和设备 |
| CN112035721A (zh) * | 2020-07-22 | 2020-12-04 | 大箴(杭州)科技有限公司 | 一种爬虫集群监控方法、装置、存储介质及计算机设备 |
| CN112363895A (zh) * | 2020-08-14 | 2021-02-12 | 北京达佳互联信息技术有限公司 | 一种系统故障的定位方法、装置及电子设备 |
| CN112838962A (zh) * | 2020-12-31 | 2021-05-25 | 中国银联股份有限公司 | 一种大数据集群的性能瓶颈检测方法及装置 |
| CN114566148A (zh) * | 2022-04-02 | 2022-05-31 | 北京百度网讯科技有限公司 | 集群语音识别服务及其检测方法、装置及电子设备 |
| CN115514625A (zh) * | 2022-09-23 | 2022-12-23 | 深信服科技股份有限公司 | 数据库集群管理方法、装置及系统 |
| WO2023273637A1 (zh) * | 2021-06-30 | 2023-01-05 | 华为技术有限公司 | 一种故障检测方法及装置 |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105553766A (zh) * | 2015-12-12 | 2016-05-04 | 天津南大通用数据技术股份有限公司 | 异常节点动态追踪集群节点状态的监测方法 |
| WO2016192604A1 (zh) * | 2015-06-05 | 2016-12-08 | 阿里巴巴集团控股有限公司 | 一种全局任务节点依赖关系可视化方法、装置和系统 |
| CN107729210A (zh) * | 2017-09-29 | 2018-02-23 | 百度在线网络技术（北京）有限公司 | 分布式服务集群的异常诊断方法和装置 |
| CN108429778A (zh) * | 2017-02-15 | 2018-08-21 | 北京京东尚科信息技术有限公司 | 一种选择下游业务系统集群的方法和装置 |
| CN109359094A (zh) * | 2018-08-03 | 2019-02-19 | 挖财网络技术有限公司 | 一种分布式系统日志全链路追踪方法及装置 |
| KR20190096706A (ko) * | 2018-02-09 | 2019-08-20 | 주식회사 케이티 | 서비스 연관성 추적을 통한 시스템 이상 징후 모니터링 방법 및 시스템 |
-
2019
- 2019-10-09 CN CN201910953290.4A patent/CN110716842B/zh active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2016192604A1 (zh) * | 2015-06-05 | 2016-12-08 | 阿里巴巴集团控股有限公司 | 一种全局任务节点依赖关系可视化方法、装置和系统 |
| CN105553766A (zh) * | 2015-12-12 | 2016-05-04 | 天津南大通用数据技术股份有限公司 | 异常节点动态追踪集群节点状态的监测方法 |
| CN108429778A (zh) * | 2017-02-15 | 2018-08-21 | 北京京东尚科信息技术有限公司 | 一种选择下游业务系统集群的方法和装置 |
| CN107729210A (zh) * | 2017-09-29 | 2018-02-23 | 百度在线网络技术（北京）有限公司 | 分布式服务集群的异常诊断方法和装置 |
| KR20190096706A (ko) * | 2018-02-09 | 2019-08-20 | 주식회사 케이티 | 서비스 연관성 추적을 통한 시스템 이상 징후 모니터링 방법 및 시스템 |
| CN109359094A (zh) * | 2018-08-03 | 2019-02-19 | 挖财网络技术有限公司 | 一种分布式系统日志全链路追踪方法及装置 |
Non-Patent Citations (2)
| Title |
|---|
| KHOLOUD ALSHAMMARI等: "An efficient approach for detecting nodes failures in wireless sensor network based on clustering", 《2017 INTERNATIONAL SYMPOSIUM ON NETWORKS, COMPUTERS AND COMMUNICATIONS (ISNCC)》 * |
| 刘智亮: "面向流数据处理的动态自适应检查点机制研究", 《中国优秀硕士学位论文全文数据库 信息科技辑 2017年第09期》 * |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111488289A (zh) * | 2020-04-26 | 2020-08-04 | 支付宝实验室(新加坡)有限公司 | 一种故障定位方法、装置和设备 |
| CN111488289B (zh) * | 2020-04-26 | 2024-01-23 | 支付宝实验室(新加坡)有限公司 | 一种故障定位方法、装置和设备 |
| CN112035721A (zh) * | 2020-07-22 | 2020-12-04 | 大箴(杭州)科技有限公司 | 一种爬虫集群监控方法、装置、存储介质及计算机设备 |
| CN112363895A (zh) * | 2020-08-14 | 2021-02-12 | 北京达佳互联信息技术有限公司 | 一种系统故障的定位方法、装置及电子设备 |
| CN112363895B (zh) * | 2020-08-14 | 2024-02-23 | 北京达佳互联信息技术有限公司 | 一种系统故障的定位方法、装置及电子设备 |
| CN112838962A (zh) * | 2020-12-31 | 2021-05-25 | 中国银联股份有限公司 | 一种大数据集群的性能瓶颈检测方法及装置 |
| WO2023273637A1 (zh) * | 2021-06-30 | 2023-01-05 | 华为技术有限公司 | 一种故障检测方法及装置 |
| CN114566148A (zh) * | 2022-04-02 | 2022-05-31 | 北京百度网讯科技有限公司 | 集群语音识别服务及其检测方法、装置及电子设备 |
| CN115514625A (zh) * | 2022-09-23 | 2022-12-23 | 深信服科技股份有限公司 | 数据库集群管理方法、装置及系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110716842B (zh) | 2023-11-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110716842B (zh) | 集群故障检测方法和装置 | |
| US11442803B2 (en) | Detecting and analyzing performance anomalies of client-server based applications | |
| US11500757B2 (en) | Method and system for automatic real-time causality analysis of end user impacting system anomalies using causality rules and topological understanding of the system to effectively filter relevant monitoring data | |
| EP3745272B1 (en) | An application performance analyzer and corresponding method | |
| US9817709B2 (en) | Systems and methods for automatic replacement and repair of communications network devices | |
| Nováczki | An improved anomaly detection and diagnosis framework for mobile network operators | |
| CN107124289B (zh) | 网络日志时间对齐方法、装置及主机 | |
| US20200021511A1 (en) | Performance analysis for transport networks using frequent log sequence discovery | |
| CN109240891A (zh) | 一种sr整机柜服务器的监控方法及装置 | |
| CN114356499A (zh) | Kubernetes集群告警根因分析方法及装置 | |
| CN112529223A (zh) | 一种设备故障报修方法、装置、服务器及储存介质 | |
| CN116016123A (zh) | 故障处理方法、装置、设备及介质 | |
| CN111371570B (zh) | 一种nfv网络的故障检测方法及装置 | |
| CN113472577A (zh) | 一种集群巡检方法、装置及系统 | |
| CN112291302B (zh) | 物联网设备行为数据分析方法与处理系统 | |
| CN114885014A (zh) | 一种外场设备状态的监测方法、装置、设备及介质 | |
| CN111988172B (zh) | 一种网络信息管理平台、装置及安全管理方法 | |
| CN113852984A (zh) | 一种无线终端接入监控系统、方法、电子设备及可读存储装置 | |
| Arefin et al. | Cloudinsight: Shedding light on the cloud | |
| CN112527594A (zh) | 一种硬盘巡检方法、装置及系统 | |
| CN114095394B (zh) | 网络节点故障检测方法、装置、电子设备及存储介质 | |
| CN113037550B (zh) | 一种服务故障监控方法、系统及计算机可读存储介质 | |
| CN116484373B (zh) | 异常进程查杀方法、系统、装置、计算机设备及存储介质 | |
| CN110309045B (zh) | 用于确定服务器未来状态的方法、装置、介质及计算设备 | |
| CN111176916B (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 |