CN110430071A - 业务节点故障自愈方法、装置、计算机设备及存储介质 - Google Patents

业务节点故障自愈方法、装置、计算机设备及存储介质 Download PDF

Info

Publication number
CN110430071A
CN110430071A CN201910657262.8A CN201910657262A CN110430071A CN 110430071 A CN110430071 A CN 110430071A CN 201910657262 A CN201910657262 A CN 201910657262A CN 110430071 A CN110430071 A CN 110430071A
Authority
CN
China
Prior art keywords
self
healing
service node
data
node
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.)
Pending
Application number
CN201910657262.8A
Other languages
English (en)
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.)
Information Center of Yunnan Power Grid Co Ltd
Original Assignee
Information Center of Yunnan Power Grid 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 Information Center of Yunnan Power Grid Co Ltd filed Critical Information Center of Yunnan Power Grid Co Ltd
Priority to CN201910657262.8A priority Critical patent/CN110430071A/zh
Publication of CN110430071A publication Critical patent/CN110430071A/zh
Pending legal-status Critical Current

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/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/0681—Configuration of triggering conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/16—Threshold monitoring
    • 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
    • H04L41/0636—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 based on a decision tree 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/0677—Localisation of faults

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明涉及业务节点故障自愈方法、装置、计算机设备及存储介质，该方法包括获取业务节点、负载均衡设备及业务分发的监控数据，以形成待分析数据；根据待分析数据进行智能分析，判断是否存在故障问题；若是，则获取故障问题所对应的故障点，发送对应的告警信息；对故障点进行自愈修复，以得到修复结果；确认修复结果。本发明通过对业务节点、***以及数据库进行多方面的检测，当出现故障问题时自动调用对应的自愈脚本，远程执行自愈脚本以自愈修复该故障问题，根据修复结果生成故障分析树模型，后续节点可根据该故障分析树模型进行自我学习修复，实现实时检测业务节点的健康状态，对发生故障的业务节点进行自愈修复，以确保用户请求能够快速响应。

Description

业务节点故障自愈方法、装置、计算机设备及存储介质
技术领域
本发明涉及电力通信网自愈方法，更具体地说是指业务节点故障自愈方法、装置、计算机设备及存储介质。
背景技术
目前CSGII***使用负载均衡设备使用的是主备冷备的方式，即每个***消耗2台负载均衡设备，而其中有一台备机使用的是冷备的方式，备机的负载能力长期闲置，由于当前负载均衡健康检查仅仅能够针对服务器层面，不能对业务层面进行检查，经常出现服务器运行正常，但是服务器上提供业务的程序异常，负载均衡设备还是会将业务请求分配到该服务器上导致访问失败。员工经常访问不了自己的财务平台，严重影响到了日常报销等工作的开展。
目前对业务节点的故障只能人工检查排除故障，无法做到自动检测及自动自愈，导致故障修复时间长，且很难准确地发现业务节点故障的具体问题，进而使得故障修复成功率低。
因此，有必要设计一种新的方法，实现实时检测业务节点的健康状态，对发生故障的业务节点进行自愈修复，以确保用户请求能够快速响应。
发明内容
本发明的目的在于克服现有技术的缺陷，提供业务节点故障自愈方法、装置、计算机设备及存储介质。
为实现上述目的，本发明采用以下技术方案：业务节点故障自愈方法，包括：
获取业务节点、负载均衡设备以及业务分发的监控数据，以形成待分析数据；
根据所述待分析数据进行智能分析，判断是否存在故障问题；
若是，则获取故障问题所对应的故障点，并发送对应的告警信息；
对故障点进行自愈修复，以得到修复结果；
确认所述修复结果。
其进一步技术方案为：所述获取业务节点、负载均衡设备以及业务分发的监控数据，以形成待分析数据之前，还包括：
通过模拟用户登录的方式对每个***相关业务节点进行探测，判断所述业务节点是否能登录；
若否，则当前业务节点出现异常；
若是，则根据预设的业务检测规则检查业务节点的业务规则是否合格；
若否，则当前业务节点出现异常；
若是，则当前业务节点不出现异常。
其进一步技术方案为：所述待分析数据包括线程锁死情况、当前的线程数量、繁忙线程数量、会话数量、侦听器连接池中请求处理的连接数量、内存溢出情况以及永生代使用情况。
其进一步技术方案为：所述根据所述待分析数据进行智能分析，判断是否存在故障问题，包括：
判断所述待分析数据内是否出现线程死锁；
若是，则存在故障问题，并将线程死锁所对应的节点作为故障点；
若否，则判断待分析数据内的当前的线程数量是否超过线程阈值；
若是，则存在故障问题，并将线程数量超过线程阈值所对应的节点作为故障点；
若否，则判断待分析数据内的繁忙线程数量是否超过繁忙线程阈值；
若是，则存在故障问题，并将繁忙线程数量超过繁忙线程阈值所对应的节点作为故障点；
若否，则判断待分析数据内的会话数量是否超过会话阈值；
若是，则存在故障问题，并将会话数量超过会话阈值所对应的节点作为故障点；
若否，则判断待分析数据内的侦听器连接池中请求处理的连接数量是否超过连接池允许的最大数量；
若是，则存在故障问题，并将侦听器连接池中请求处理的连接数量超过连接池允许的最大数量所对应的节点作为故障点；
若否，则判断待分析数据内的内存溢出情况是否超过堆栈使用阈值；
若是，则存在故障问题，并将内存溢出情况超过堆栈使用阈值所对应的节点作为故障点；
若否，则判断待分析数据内的永生代使用情况是否为出现有大型类长期占用永生代内存；
若是，则存在故障问题，并将出现有大型类长期占用永生代内存的永生代使用情况所对应的节点作为故障点；
若否，则无故障问题。
其进一步技术方案为：所述对故障点进行自愈修复，以得到修复结果，包括：
分析所述故障点的根因，以得到故障根因；
根据故障根因调取预设配置脚本进行自愈修复处理，以得到修复结果。
其进一步技术方案为：所述根据故障根因调取预设配置脚本进行自愈修复处理，以得到修复结果，包括：
根据故障根因从数据库中获得相关的机器部署信息和自愈方案，以得到自愈信息；
根据自愈信息生成自愈清单以及自愈册；
根据自愈清单的远程连接凭证使用SSH通道连接到远程主机，并执行自愈册指定的脚本，并发送远程脚本，以使得远程主机被动执行远程脚本，以得到修复结果。
其进一步技术方案为：所述确认所述修复结果之后，还包括：
根据所述修复结果建议故障分析树模型，以进行业务节点故障的自我学习故障处理操作。
本发明还提供了业务节点故障自愈装置，包括：
数据获取单元，用于获取业务节点、负载均衡设备以及业务分发的监控数据，以形成待分析数据；
分析单元，用于根据所述待分析数据进行智能分析，判断是否存在故障问题；
告警发送单元，用于若是，则获取故障问题所对应的故障点，并发送对应的告警信息；
自愈修复单元，用于对故障点进行自愈修复，以得到修复结果；
结果确认单元，用于确认所述修复结果。
本发明还提供了一种计算机设备，所述计算机设备包括存储器及处理器，所述存储器上存储有计算机程序，所述处理器执行所述计算机程序时实现上述的方法。
本发明还提供了一种存储介质，所述存储介质存储有计算机程序，所述计算机程序被处理器执行时可实现上述的方法。
本发明与现有技术相比的有益效果是：本发明通过对业务节点、***以及数据库进行多方面的检测，当出现故障问题时，自动调用对应的自愈脚本，并可远程执行该自愈脚本以自愈修复该故障问题，且根据修复结果生成故障分析树模型，后续节点可根据该故障分析树模型进行自我学习修复故障，实现实时检测业务节点的健康状态，对发生故障的业务节点进行自愈修复，以确保用户请求能够快速响应。
下面结合附图和具体实施例对本发明作进一步描述。
附图说明
为了更清楚地说明本发明实施例技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本发明实施例提供的业务节点故障自愈方法的流程示意图；
图2为本发明实施例提供的业务节点故障自愈方法的子流程示意图；
图3为本发明实施例提供的业务节点故障自愈方法的子流程示意图；
图4为本发明实施例提供的业务节点故障自愈方法的子流程示意图；
图5为本发明另一实施例提供的业务节点故障自愈方法的流程示意图；
图6为本发明实施例提供的业务节点故障自愈装置300的示意性框图；
图7为本发明另一实施例提供的业务节点故障自愈装置300的示意性框图；
图8为本发明实施例提供的计算机设备的示意性框图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。
还应当理解，在此本发明说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本发明。如在本发明说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。
还应当进一步理解，在本发明说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。
请参阅图1，图1为本发明实施例提供的业务节点故障自愈方法的示意性流程图。该业务节点故障自愈方法应用于服务器中。
图1是本发明实施例提供的业务节点故障自愈方法的流程示意图。如图2所示，该方法包括以下步骤S110至S150。
S110、获取业务节点、负载均衡设备以及业务分发的监控数据，以形成待分析数据。
在本实施例中，待分析数据是对中间件、数据库、***进行检测所获得的数据。
具体地，上述的待分析数据包括线程锁死情况、当前的线程数量、繁忙线程数量、会话数量、侦听器连接池中请求处理的连接数量、内存溢出情况以及永生代使用情况。
对于负载均衡设备的检测，包括：负载均衡设备维护列表对接，可以获取到当前接入的负载均衡设备；负载均衡设备信息对接，可以获取到当前负载均衡设备管理的服务器信；负载均衡设备控制踢出对接，可以将某台服务器通过对接提出队列，并返回结果；负载均衡设备控制加入对接，可以将某台服务器通过对接加入队列，并返回结果。
对于业务分发而言，针对不同***的服务模块进行细粒度的业务级检测和业务请求分发，并且可以做到跨设备在负载均衡资源池中进行分发。通过业务节点检测模块得到异常节点，控制负载均衡***不再将请求分发至异常节点。
S120、根据所述待分析数据进行智能分析，判断是否存在故障问题。
在本实施例中，故障问题是指导致用户请求无法快速响应的问题。
在一实施例中，请参阅图2，上述的步骤S120可包括步骤S121～S1215。
S121、判断所述待分析数据内是否出现线程死锁。
具体地，监控线程死锁以便于及时发现死锁线程。
S122、若是，则存在故障问题，并将线程死锁所对应的节点作为故障点；
S123、若否，则判断待分析数据内的当前的线程数量是否超过线程阈值。
比较当前线程数与最大线程数，设置峰值，达到峰值时告警。
S124、若是，则存在故障问题，并将线程数量超过线程阈值所对应的节点作为故障点；
S125、若否，则判断待分析数据内的繁忙线程数量是否超过繁忙线程阈值。
比较繁忙线程数与繁忙线程阈值，设置繁忙线程阈值，达到繁忙线程阈值。时告警
S126、若是，则存在故障问题，并将繁忙线程数量超过繁忙线程阈值所对应的节点作为故障点；
S127、若否，则判断待分析数据内的会话数量是否超过会话阈值。
比较会话数与最大会话数，并设置会话阈值达到会话阈值时告警。
S128、若是，则存在故障问题，并将会话数量超过会话阈值所对应的节点作为故障点；
S129、若否，则判断待分析数据内的侦听器连接池中请求处理的连接数量是否超过连接池允许的最大数量。
对比http连接池允许的最大数与侦听器线程池中请求处理的连接数，判断是否达到设置的峰值，超过峰值时告警。
S1210、若是，则存在故障问题，并将侦听器连接池中请求处理的连接数量超过连接池允许的最大数量所对应的节点作为故障点；
S1211、若否，则判断待分析数据内的内存溢出情况是否超过堆栈使用阈值。
Jvm堆使用大小超过设置值。
S1212、若是，则存在故障问题，并将内存溢出情况超过堆栈使用阈值所对应的节点作为故障点；
S1213、若否，则判断待分析数据内的永生代使用情况是否为出现有大型类长期占用永生代内存；
S1214、若是，则存在故障问题，并将出现有大型类长期占用永生代内存的永生代使用情况所对应的节点作为故障点；
S1215、若否，则无故障问题。
不同的故障点存在的不同的故障问题所采用的自愈脚本均不同，因此，需要先确定故障点以及故障问题。
针对故障问题匹配相关问题模型即问题分析树进行运维操作，包括中间件及部分数据库相关故障处理操作，业务检测发现业务故障后启动自动诊断算法，调用故障处理模型进行自动故障修复达到节点及业务自愈效果，以实现智能化故障自愈的效果。
具体地，对于线程锁死情况可调用中创中间件接口进行监控，当前的线程数量可调用jmx接口进行获取，繁忙线程数量可调用jmx接口进行获取，会话数量可调用jmx接口进行监控；侦听器连接池中请求处理的连接数量可检查中间件以输出结果，内存溢出情况可调用jmx接口进行监控；永生代使用情况可调用jmx接口进行监控；
S130、若是，则获取故障问题所对应的故障点，并发送对应的告警信息。
在本实施例中，告警信息的发送可实现手动阈值告警的管理、人工智能自动告警的实现、告警处理流程等功能，通过告警来触发自愈流程。
当然，于其他实施例，除了上述的故障问题的自愈方案外，还可以设置其他故障问题的自愈方案，具体地依据实际情况而定。
S140、对故障点进行自愈修复，以得到修复结果。
在一实施例中，请参阅图3，上述的步骤S140可包括步骤S141～S142。
S141、分析所述故障点的根因，以得到故障根因。
在本实施例中，故障根因是指导致故障点发生的原因。实现告警的根因分析，有利于更好地给出自愈方案。
S142、根据故障根因调取预设配置脚本进行自愈修复处理，以得到修复结果。
在本实施例中，修复结果是指利用预设的脚本进行修复故障后的结果。
在一实施例中，请参阅图4，上述的步骤S142可包括步骤S1421～S1423。
S1421、根据故障根因从数据库中获得相关的机器部署信息和自愈方案，以得到自愈信息；
S1422、根据自愈信息生成自愈清单以及自愈册；
S1423、根据自愈清单的远程连接凭证使用SSH通道连接到远程主机，并执行自愈册指定的脚本，并发送远程脚本，以使得远程主机被动执行远程脚本，以得到修复结果。
接收分析服务的自愈请求，根据请求从数据库中获得相关的机器部署信息如IP地址、远程管理用户凭证等和自愈方案即自愈脚本等并根据上述信息生成为自愈清单和自愈册；反馈执行的结果；并根据自愈清单的远程连接凭证，使用SSH(安全外壳协议，SecureShell)通道连接到远程主机，并执行自愈册指定的脚本；反馈执行的结果；远程主机被动执行远程脚本，脚本可调用中创中间件的JMX服务，或执行OS***调用，并上报执行结果，以得到修复结果。
S150、确认所述修复结果。
需要对修复结果进行确认，以确保自愈修复的成功率。
上述的自愈修改过程使用了Ansible框架，Ansible是一款基于Python开发的开源的自动化运维管理工具，可以用来自动化部署应用、配置、编排task(持续交付、无宕机更新等)。Ansible只需要在一台普通的服务器上运行即可，不需要在被管控的服务器上安装客户端。因为它是基于SSH的，Linux服务器离不开SSH，所以不需要为配置工作添加额外的支持。它能够大大简化Linux管理员的自动化配置管理与流程控制方式。它利用推送方式对客户***加以配置，这样所有工作都可在主服务器端完成。基于Python语言实现，其巧妙地通过SSH进行管理节点，被管理端无需收集数值指标数据、执行自愈脚本Agent，使用起来非常方便。
S160、根据所述修复结果建议故障分析树模型，以进行业务节点故障的自我学习故障处理操作。
业务级负载均衡检测到问题节点后可以对问题进行分析，根据分析结果调用预建立的问题处理脚本等自动化运维工具操作修复。同时建立故障分析树模型，在后续项目中对故障分析树进行完善，最终达到自我学习故障处理标准化流程化的目标。
若否，则返回所述步骤S110。
上述的业务节点故障自愈方法，通过对业务节点、***以及数据库进行多方面的检测，当出现故障问题时，自动调用对应的自愈脚本，并可远程执行该自愈脚本以自愈修复该故障问题，且根据修复结果生成故障分析树模型，后续节点可根据该故障分析树模型进行自我学习修复故障，实现实时检测业务节点的健康状态，对发生故障的业务节点进行自愈修复，以确保用户请求能够快速响应。
图5是本发明另一实施例提供的一种业务节点故障自愈方法的流程示意图。如图5所示，本实施例的业务节点故障自愈方法包括步骤S210-S300。其中步骤S250-S300与上述实施例中的步骤S110-S160类似，在此不再赘述。下面详细说明本实施例中所增加的步骤S210-S240。
S210、通过模拟用户登录的方式对每个***相关业务节点进行探测，判断所述业务节点是否能登录；
S220、若否，则当前业务节点出现异常；
S230、若是，则根据预设的业务检测规则检查业务节点的业务规则是否合格；
若否，则进入S220；
S240、若是，则当前业务节点不出现异常，并进入S260。
应用级负载均衡层使用模拟用户登录的方式对每个节点进行探测，实现对4A的穿透同时保证数据包二次跳转控制。如果无法登录则认为节点异常，控制业务请求发送。实现检测任务维护及检测结果、检测应用有节点规则配置、规则检测及结果、单步检测及结果、检测应用列表、端口检测、结果展示等；应用状态有节点状态的预警、状态展示、提醒等。
图6是本发明实施例提供的一种业务节点故障自愈装置300的示意性框图。如图6所示，对应于以上业务节点故障自愈方法，本发明还提供一种业务节点故障自愈装置300。该业务节点故障自愈装置300包括用于执行上述业务节点故障自愈方法的单元，该装置可以被配置于服务器中。
具体地，请参阅图6，该业务节点故障自愈装置300包括：
数据获取单元303，用于获取业务节点、负载均衡设备以及业务分发的监控数据，以形成待分析数据；
分析单元304，用于根据所述待分析数据进行智能分析，判断是否存在故障问题；
告警发送单元305，用于若是，则获取故障问题所对应的故障点，并发送对应的告警信息；
自愈修复单元306，用于对故障点进行自愈修复，以得到修复结果；
结果确认单元307，用于确认所述修复结果。
在一实施例中，所述装置还包括：
模型建立单元308，用于根据所述修复结果建议故障分析树模型，以进行业务节点故障的自我学习故障处理操作。
在一实施例中，所述分析单元304包括：
第一判断子单元，用于判断所述待分析数据内是否出现线程死锁；若是，则存在故障问题，并将线程死锁所对应的节点作为故障点；
第二判断子单元，用于若否，则判断待分析数据内的当前的线程数量是否超过线程阈值；若是，则存在故障问题，并将线程数量超过线程阈值所对应的节点作为故障点；
第三判断子单元，用于若否，则判断待分析数据内的繁忙线程数量是否超过繁忙线程阈值；若是，则存在故障问题，并将繁忙线程数量超过繁忙线程阈值所对应的节点作为故障点；
第四判断子单元，用于若否，则判断待分析数据内的会话数量是否超过会话阈值；若是，则存在故障问题，并将会话数量超过会话阈值所对应的节点作为故障点；
第五判断子单元，用于若否，则判断待分析数据内的侦听器连接池中请求处理的连接数量是否超过连接池允许的最大数量；若是，则存在故障问题，并将侦听器连接池中请求处理的连接数量超过连接池允许的最大数量所对应的节点作为故障点；
第六判断子单元，用于若否，则判断待分析数据内的内存溢出情况是否超过堆栈使用阈值；若是，则存在故障问题，并将内存溢出情况超过堆栈使用阈值所对应的节点作为故障点；
第七判断子单元，用于若否，则判断待分析数据内的永生代使用情况是否为出现有大型类长期占用永生代内存；若是，则存在故障问题，并将出现有大型类长期占用永生代内存的永生代使用情况所对应的节点作为故障点；若否，则无故障问题。
在一实施例中，所述自愈修复单元306包括：
根因分析子单元，用于分析所述故障点的根因，以得到故障根因；
处理子单元，用于根据故障根因调取预设配置脚本进行自愈修复处理，以得到修复结果。
在一实施例中，所述处理子单元包括：
自愈信息获取模块，用于根据故障根因从数据库中获得相关的机器部署信息和自愈方案，以得到自愈信息；
生成模块，用于根据自愈信息生成自愈清单以及自愈册；
执行模块，用于根据自愈清单的远程连接凭证使用SSH通道连接到远程主机，并执行自愈册指定的脚本，并发送远程脚本，以使得远程主机被动执行远程脚本，以得到修复结果。
图7是本发明另一实施例提供的一种业务节点故障自愈装置300的示意性框图。如图7所示，本实施例的业务节点故障自愈装置300是上述实施例的基础上增加了探测单元301以及合格判断单元302。
探测单元301，用于通过模拟用户登录的方式对每个***相关业务节点进行探测，判断所述业务节点是否能登录；若否，则当前业务节点出现异常；
合格判断单元302，用于若是，则根据预设的业务检测规则检查业务节点的业务规则是否合格；若否，则当前业务节点出现异常；若是，则当前业务节点不出现异常。
需要说明的是，所属领域的技术人员可以清楚地了解到，上述业务节点故障自愈装置300和各单元的具体实现过程，可以参考前述方法实施例中的相应描述，为了描述的方便和简洁，在此不再赘述。
上述业务节点故障自愈装置300可以实现为一种计算机程序的形式，该计算机程序可以在如图8所示的计算机设备上运行。
请参阅图8，图8是本申请实施例提供的一种计算机设备的示意性框图。该计算机设备500可以是服务器。
参阅图8，该计算机设备500包括通过***总线501连接的处理器502、存储器和网络接口505，其中，存储器可以包括非易失性存储介质503和内存储器504。
该非易失性存储介质503可存储操作***5031和计算机程序5032。该计算机程序5032包括程序指令，该程序指令被执行时，可使得处理器502执行一种业务节点故障自愈方法。
该处理器502用于提供计算和控制能力，以支撑整个计算机设备500的运行。
该内存储器504为非易失性存储介质503中的计算机程序5032的运行提供环境，该计算机程序5032被处理器502执行时，可使得处理器502执行一种业务节点故障自愈方法。
该网络接口505用于与其它设备进行网络通信。本领域技术人员可以理解，图8中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备500的限定，具体的计算机设备500可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
其中，所述处理器502用于运行存储在存储器中的计算机程序5032，以实现如下步骤：
获取业务节点、负载均衡设备以及业务分发的监控数据，以形成待分析数据；
根据所述待分析数据进行智能分析，判断是否存在故障问题；
若是，则获取故障问题所对应的故障点，并发送对应的告警信息；
对故障点进行自愈修复，以得到修复结果；
确认所述修复结果。
其中，所述待分析数据包括线程锁死情况、当前的线程数量、繁忙线程数量、会话数量、侦听器连接池中请求处理的连接数量、内存溢出情况以及永生代使用情况。
在一实施例中，处理器502在实现所述获取业务节点、负载均衡设备以及业务分发的监控数据，以形成待分析数据步骤之前，还实现如下步骤：
通过模拟用户登录的方式对每个***相关业务节点进行探测，判断所述业务节点是否能登录；
若否，则当前业务节点出现异常；
若是，则根据预设的业务检测规则检查业务节点的业务规则是否合格；
若否，则当前业务节点出现异常；
若是，则当前业务节点不出现异常。
在一实施例中，处理器502在实现所述根据所述待分析数据进行智能分析，判断是否存在故障问题步骤时，具体实现如下步骤：
判断所述待分析数据内是否出现线程死锁；
若是，则存在故障问题，并将线程死锁所对应的节点作为故障点；
若否，则判断待分析数据内的当前的线程数量是否超过线程阈值；
若是，则存在故障问题，并将线程数量超过线程阈值所对应的节点作为故障点；
若否，则判断待分析数据内的繁忙线程数量是否超过繁忙线程阈值；
若是，则存在故障问题，并将繁忙线程数量超过繁忙线程阈值所对应的节点作为故障点；
若否，则判断待分析数据内的会话数量是否超过会话阈值；
若是，则存在故障问题，并将会话数量超过会话阈值所对应的节点作为故障点；
若否，则判断待分析数据内的侦听器连接池中请求处理的连接数量是否超过连接池允许的最大数量；
若是，则存在故障问题，并将侦听器连接池中请求处理的连接数量超过连接池允许的最大数量所对应的节点作为故障点；
若否，则判断待分析数据内的内存溢出情况是否超过堆栈使用阈值；
若是，则存在故障问题，并将内存溢出情况超过堆栈使用阈值所对应的节点作为故障点；
若否，则判断待分析数据内的永生代使用情况是否为出现有大型类长期占用永生代内存；
若是，则存在故障问题，并将出现有大型类长期占用永生代内存的永生代使用情况所对应的节点作为故障点；
若否，则无故障问题。
在一实施例中，处理器502在实现所述对故障点进行自愈修复，以得到修复结果步骤时，具体实现如下步骤：
分析所述故障点的根因，以得到故障根因；
根据故障根因调取预设配置脚本进行自愈修复处理，以得到修复结果。
在一实施例中，处理器502在实现所述根据故障根因调取预设配置脚本进行自愈修复处理，以得到修复结果步骤时，具体实现如下步骤：
根据故障根因从数据库中获得相关的机器部署信息和自愈方案，以得到自愈信息；
根据自愈信息生成自愈清单以及自愈册；
根据自愈清单的远程连接凭证使用SSH通道连接到远程主机，并执行自愈册指定的脚本，并发送远程脚本，以使得远程主机被动执行远程脚本，以得到修复结果。
在一实施例中，处理器502在实现所述确认所述修复结果步骤之后，还实现如下步骤：
根据所述修复结果建议故障分析树模型，以进行业务节点故障的自我学习故障处理操作。
应当理解，在本申请实施例中，处理器502可以是中央处理单元(CentralProcessing Unit，CPU)，该处理器502还可以是其他通用处理器、数字信号处理器(DigitalSignal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。其中，通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
本领域普通技术人员可以理解的是实现上述实施例的方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成。该计算机程序包括程序指令，计算机程序可存储于一存储介质中，该存储介质为计算机可读存储介质。该程序指令被该计算机***中的至少一个处理器执行，以实现上述方法的实施例的流程步骤。
因此，本发明还提供一种存储介质。该存储介质可以为计算机可读存储介质。该存储介质存储有计算机程序，其中该计算机程序被处理器执行时使处理器执行如下步骤：
获取业务节点、负载均衡设备以及业务分发的监控数据，以形成待分析数据；
根据所述待分析数据进行智能分析，判断是否存在故障问题；
若是，则获取故障问题所对应的故障点，并发送对应的告警信息；
对故障点进行自愈修复，以得到修复结果；
确认所述修复结果。
其中，所述待分析数据包括线程锁死情况、当前的线程数量、繁忙线程数量、会话数量、侦听器连接池中请求处理的连接数量、内存溢出情况以及永生代使用情况。
在一实施例中，所述处理器在执行所述计算机程序而实现所述获取业务节点、负载均衡设备以及业务分发的监控数据，以形成待分析数据步骤之前，还实现如下步骤：
通过模拟用户登录的方式对每个***相关业务节点进行探测，判断所述业务节点是否能登录；
若否，则当前业务节点出现异常；
若是，则根据预设的业务检测规则检查业务节点的业务规则是否合格；
若否，则当前业务节点出现异常；
若是，则当前业务节点不出现异常。
在一实施例中，所述处理器在执行所述计算机程序而实现所述根据所述待分析数据进行智能分析，判断是否存在故障问题步骤时，具体实现如下步骤：
判断所述待分析数据内是否出现线程死锁；
若是，则存在故障问题，并将线程死锁所对应的节点作为故障点；
若否，则判断待分析数据内的当前的线程数量是否超过线程阈值；
若是，则存在故障问题，并将线程数量超过线程阈值所对应的节点作为故障点；
若否，则判断待分析数据内的繁忙线程数量是否超过繁忙线程阈值；
若是，则存在故障问题，并将繁忙线程数量超过繁忙线程阈值所对应的节点作为故障点；
若否，则判断待分析数据内的会话数量是否超过会话阈值；
若是，则存在故障问题，并将会话数量超过会话阈值所对应的节点作为故障点；
若否，则判断待分析数据内的侦听器连接池中请求处理的连接数量是否超过连接池允许的最大数量；
若是，则存在故障问题，并将侦听器连接池中请求处理的连接数量超过连接池允许的最大数量所对应的节点作为故障点；
若否，则判断待分析数据内的内存溢出情况是否超过堆栈使用阈值；
若是，则存在故障问题，并将内存溢出情况超过堆栈使用阈值所对应的节点作为故障点；
若否，则判断待分析数据内的永生代使用情况是否为出现有大型类长期占用永生代内存；
若是，则存在故障问题，并将出现有大型类长期占用永生代内存的永生代使用情况所对应的节点作为故障点；
若否，则无故障问题。
在一实施例中，所述处理器在执行所述计算机程序而实现所述对故障点进行自愈修复，以得到修复结果步骤时，具体实现如下步骤：
分析所述故障点的根因，以得到故障根因；
根据故障根因调取预设配置脚本进行自愈修复处理，以得到修复结果。
在一实施例中，所述处理器在执行所述计算机程序而实现所述根据故障根因调取预设配置脚本进行自愈修复处理，以得到修复结果步骤时，具体实现如下步骤：
根据故障根因从数据库中获得相关的机器部署信息和自愈方案，以得到自愈信息；
根据自愈信息生成自愈清单以及自愈册；
根据自愈清单的远程连接凭证使用SSH通道连接到远程主机，并执行自愈册指定的脚本，并发送远程脚本，以使得远程主机被动执行远程脚本，以得到修复结果。
在一实施例中，所述处理器在执行所述计算机程序而实现所述确认所述修复结果步骤之后，还实现如下步骤：
根据所述修复结果建议故障分析树模型，以进行业务节点故障的自我学习故障处理操作。
所述存储介质可以是U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的计算机可读存储介质。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
在本发明所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的。例如，各个单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。
本发明实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减。本发明实施例装置中的单元可以根据实际需要进行合并、划分和删减。另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。
该集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，终端，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (10)

1.业务节点故障自愈方法，其特征在于，包括：
获取业务节点、负载均衡设备以及业务分发的监控数据，以形成待分析数据；
根据所述待分析数据进行智能分析，判断是否存在故障问题；
若是，则获取故障问题所对应的故障点，并发送对应的告警信息；
对故障点进行自愈修复，以得到修复结果；
确认所述修复结果。
2.根据权利要求1所述的业务节点故障自愈方法，其特征在于，所述获取业务节点、负载均衡设备以及业务分发的监控数据，以形成待分析数据之前，还包括：
通过模拟用户登录的方式对每个***相关业务节点进行探测，判断所述业务节点是否能登录；
若否，则当前业务节点出现异常；
若是，则根据预设的业务检测规则检查业务节点的业务规则是否合格；
若否，则当前业务节点出现异常；
若是，则当前业务节点不出现异常。
3.根据权利要求1所述的业务节点故障自愈方法，其特征在于，所述待分析数据包括线程锁死情况、当前的线程数量、繁忙线程数量、会话数量、侦听器连接池中请求处理的连接数量、内存溢出情况以及永生代使用情况。
4.根据权利要求3所述的业务节点故障自愈方法，其特征在于，所述根据所述待分析数据进行智能分析，判断是否存在故障问题，包括：
判断所述待分析数据内是否出现线程死锁；
若是，则存在故障问题，并将线程死锁所对应的节点作为故障点；
若否，则判断待分析数据内的当前的线程数量是否超过线程阈值；
若是，则存在故障问题，并将线程数量超过线程阈值所对应的节点作为故障点；
若否，则判断待分析数据内的繁忙线程数量是否超过繁忙线程阈值；
若是，则存在故障问题，并将繁忙线程数量超过繁忙线程阈值所对应的节点作为故障点；
若否，则判断待分析数据内的会话数量是否超过会话阈值；
若是，则存在故障问题，并将会话数量超过会话阈值所对应的节点作为故障点；
若否，则判断待分析数据内的侦听器连接池中请求处理的连接数量是否超过连接池允许的最大数量；
若是，则存在故障问题，并将侦听器连接池中请求处理的连接数量超过连接池允许的最大数量所对应的节点作为故障点；
若否，则判断待分析数据内的内存溢出情况是否超过堆栈使用阈值；
若是，则存在故障问题，并将内存溢出情况超过堆栈使用阈值所对应的节点作为故障点；
若否，则判断待分析数据内的永生代使用情况是否为出现有大型类长期占用永生代内存；
若是，则存在故障问题，并将出现有大型类长期占用永生代内存的永生代使用情况所对应的节点作为故障点；
若否，则无故障问题。
5.根据权利要求4所述的业务节点故障自愈方法，其特征在于，所述对故障点进行自愈修复，以得到修复结果，包括：
分析所述故障点的根因，以得到故障根因；
根据故障根因调取预设配置脚本进行自愈修复处理，以得到修复结果。
6.根据权利要求5所述的业务节点故障自愈方法，其特征在于，所述根据故障根因调取预设配置脚本进行自愈修复处理，以得到修复结果，包括：
根据故障根因从数据库中获得相关的机器部署信息和自愈方案，以得到自愈信息；
根据自愈信息生成自愈清单以及自愈册；
根据自愈清单的远程连接凭证使用SSH通道连接到远程主机，并执行自愈册指定的脚本，并发送远程脚本，以使得远程主机被动执行远程脚本，以得到修复结果。
7.根据权利要求1所述的业务节点故障自愈方法，其特征在于，所述确认所述修复结果之后，还包括：
根据所述修复结果建议故障分析树模型，以进行业务节点故障的自我学习故障处理操作。
8.业务节点故障自愈装置，其特征在于，包括：
数据获取单元，用于获取业务节点、负载均衡设备以及业务分发的监控数据，以形成待分析数据；
分析单元，用于根据所述待分析数据进行智能分析，判断是否存在故障问题；
告警发送单元，用于若是，则获取故障问题所对应的故障点，并发送对应的告警信息；
自愈修复单元，用于对故障点进行自愈修复，以得到修复结果；
结果确认单元，用于确认所述修复结果。
9.一种计算机设备，其特征在于，所述计算机设备包括存储器及处理器，所述存储器上存储有计算机程序，所述处理器执行所述计算机程序时实现如权利要求1至7中任一项所述的方法。
10.一种存储介质，其特征在于，所述存储介质存储有计算机程序，所述计算机程序被处理器执行时可实现如权利要求1至7中任一项所述的方法。
CN201910657262.8A 2019-07-19 2019-07-19 业务节点故障自愈方法、装置、计算机设备及存储介质 Pending CN110430071A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910657262.8A CN110430071A (zh) 2019-07-19 2019-07-19 业务节点故障自愈方法、装置、计算机设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910657262.8A CN110430071A (zh) 2019-07-19 2019-07-19 业务节点故障自愈方法、装置、计算机设备及存储介质

Publications (1)

Publication Number Publication Date
CN110430071A true CN110430071A (zh) 2019-11-08

Family

ID=68411345

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910657262.8A Pending CN110430071A (zh) 2019-07-19 2019-07-19 业务节点故障自愈方法、装置、计算机设备及存储介质

Country Status (1)

Country Link
CN (1) CN110430071A (zh)

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111064597A (zh) * 2019-11-12 2020-04-24 刘璐豪 一种基于Pass平台的中间件节点自愈***的自愈方法
CN111181767A (zh) * 2019-12-10 2020-05-19 中国航空工业集团公司成都飞机设计研究所 一种面向复杂***的监控和故障自愈***及其方法
CN111176879A (zh) * 2019-12-31 2020-05-19 中国建设银行股份有限公司 设备的故障修复方法及装置
CN111404759A (zh) * 2020-04-17 2020-07-10 腾讯科技（深圳）有限公司 服务检测方法、规则配置方法、相关设备及介质
CN111796959A (zh) * 2020-06-30 2020-10-20 中国工商银行股份有限公司 宿主机容器自愈方法、装置及***
CN111835702A (zh) * 2020-01-20 2020-10-27 北京嘀嘀无限科技发展有限公司 登录方法、装置、设备及计算机可读存储介质
CN111858176A (zh) * 2020-07-22 2020-10-30 欧冶云商股份有限公司 一种远程监控故障自愈***和方法
CN111880977A (zh) * 2020-07-16 2020-11-03 北京天维信通科技有限公司 故障自愈方法和装置、设备及存储介质
CN112214409A (zh) * 2020-10-13 2021-01-12 中国工商银行股份有限公司 一种用于测试环境下的运维方法及装置
CN112217691A (zh) * 2020-02-19 2021-01-12 杜义平 基于云平台的网络诊断处理方法及装置
CN112328372A (zh) * 2020-11-27 2021-02-05 新华智云科技有限公司 一种kubernetes节点自愈方法和***
CN112350862A (zh) * 2020-10-30 2021-02-09 广州市汇聚支付电子科技有限公司 一种监控报警及故障自愈***
CN112905352A (zh) * 2021-01-29 2021-06-04 北京深演智能科技股份有限公司 节点死锁处理的方法和装置
WO2021169064A1 (zh) * 2020-02-25 2021-09-02 网宿科技股份有限公司 一种基于边缘网络的异常处理方法及装置
CN113392862A (zh) * 2020-03-12 2021-09-14 ***通信集团山东有限公司 感知数据的自愈管控方法、装置、计算机设备和存储介质
CN113590370A (zh) * 2021-08-06 2021-11-02 北京百度网讯科技有限公司 一种故障处理方法、装置、设备及存储介质
WO2023056831A1 (zh) * 2021-10-09 2023-04-13 中兴通讯股份有限公司 故障修复方法、装置、电子设备及存储介质

Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103298013A (zh) * 2013-06-24 2013-09-11 京信通信***（中国）有限公司 一种进行业务恢复的方法及装置
CN104699759A (zh) * 2015-02-10 2015-06-10 上海新炬网络信息技术有限公司 一种数据库自动化运行维护方法
CN106921508A (zh) * 2015-12-25 2017-07-04 中兴通讯股份有限公司 虚拟化网元故障自愈方法及装置
CN107729205A (zh) * 2017-08-22 2018-02-23 国家电网公司 用于业务***的故障处理方法和装置
CN108521339A (zh) * 2018-03-13 2018-09-11 广州西麦科技股份有限公司 一种基于集群日志的反馈式节点故障处理方法及***
CN108540308A (zh) * 2018-03-02 2018-09-14 中国银行股份有限公司 一种基于SCOM的windows应用平台故障自愈***及方法
CN108809729A (zh) * 2018-06-25 2018-11-13 郑州云海信息技术有限公司 一种分布式***中ctdb服务的故障处理方法及装置
CN109088773A (zh) * 2018-08-24 2018-12-25 广州视源电子科技股份有限公司 故障自愈方法、装置、服务器及存储介质
CN109167676A (zh) * 2018-07-24 2019-01-08 郑州云海信息技术有限公司 一种高性能集群故障的诊断方法及***
CN109286529A (zh) * 2018-10-31 2019-01-29 武汉烽火信息集成技术有限公司 一种恢复RabbitMQ网络分区的方法及***
CN109308252A (zh) * 2017-07-27 2019-02-05 ***通信集团浙江有限公司 一种故障定位处理方法及装置
CN109597398A (zh) * 2018-11-28 2019-04-09 广东万和新电气股份有限公司 家用电器的故障自动处理方法、装置、设备与存储介质
CN109766217A (zh) * 2018-12-20 2019-05-17 北京梧桐车联科技有限责任公司 一种车机***故障修复方法及装置

Patent Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103298013A (zh) * 2013-06-24 2013-09-11 京信通信***（中国）有限公司 一种进行业务恢复的方法及装置
CN104699759A (zh) * 2015-02-10 2015-06-10 上海新炬网络信息技术有限公司 一种数据库自动化运行维护方法
CN106921508A (zh) * 2015-12-25 2017-07-04 中兴通讯股份有限公司 虚拟化网元故障自愈方法及装置
CN109308252A (zh) * 2017-07-27 2019-02-05 ***通信集团浙江有限公司 一种故障定位处理方法及装置
CN107729205A (zh) * 2017-08-22 2018-02-23 国家电网公司 用于业务***的故障处理方法和装置
CN108540308A (zh) * 2018-03-02 2018-09-14 中国银行股份有限公司 一种基于SCOM的windows应用平台故障自愈***及方法
CN108521339A (zh) * 2018-03-13 2018-09-11 广州西麦科技股份有限公司 一种基于集群日志的反馈式节点故障处理方法及***
CN108809729A (zh) * 2018-06-25 2018-11-13 郑州云海信息技术有限公司 一种分布式***中ctdb服务的故障处理方法及装置
CN109167676A (zh) * 2018-07-24 2019-01-08 郑州云海信息技术有限公司 一种高性能集群故障的诊断方法及***
CN109088773A (zh) * 2018-08-24 2018-12-25 广州视源电子科技股份有限公司 故障自愈方法、装置、服务器及存储介质
CN109286529A (zh) * 2018-10-31 2019-01-29 武汉烽火信息集成技术有限公司 一种恢复RabbitMQ网络分区的方法及***
CN109597398A (zh) * 2018-11-28 2019-04-09 广东万和新电气股份有限公司 家用电器的故障自动处理方法、装置、设备与存储介质
CN109766217A (zh) * 2018-12-20 2019-05-17 北京梧桐车联科技有限责任公司 一种车机***故障修复方法及装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
程雪松: "基于Zabbix的医院自动化运维监控平台的设计与应用", 《福建电脑》 *

Cited By (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111064597A (zh) * 2019-11-12 2020-04-24 刘璐豪 一种基于Pass平台的中间件节点自愈***的自愈方法
CN111181767A (zh) * 2019-12-10 2020-05-19 中国航空工业集团公司成都飞机设计研究所 一种面向复杂***的监控和故障自愈***及其方法
CN111176879A (zh) * 2019-12-31 2020-05-19 中国建设银行股份有限公司 设备的故障修复方法及装置
CN111835702A (zh) * 2020-01-20 2020-10-27 北京嘀嘀无限科技发展有限公司 登录方法、装置、设备及计算机可读存储介质
CN111835702B (zh) * 2020-01-20 2023-10-31 北京嘀嘀无限科技发展有限公司 登录方法、装置、设备及计算机可读存储介质
CN112217691A (zh) * 2020-02-19 2021-01-12 杜义平 基于云平台的网络诊断处理方法及装置
CN112217692A (zh) * 2020-02-19 2021-01-12 杜义平 网络***、网络诊断处理方法及装置
WO2021169064A1 (zh) * 2020-02-25 2021-09-02 网宿科技股份有限公司 一种基于边缘网络的异常处理方法及装置
CN113392862B (zh) * 2020-03-12 2022-12-09 ***通信集团山东有限公司 感知数据的自愈管控方法、装置、计算机设备和存储介质
CN113392862A (zh) * 2020-03-12 2021-09-14 ***通信集团山东有限公司 感知数据的自愈管控方法、装置、计算机设备和存储介质
CN111404759A (zh) * 2020-04-17 2020-07-10 腾讯科技（深圳）有限公司 服务检测方法、规则配置方法、相关设备及介质
CN111796959A (zh) * 2020-06-30 2020-10-20 中国工商银行股份有限公司 宿主机容器自愈方法、装置及***
CN111796959B (zh) * 2020-06-30 2023-08-08 中国工商银行股份有限公司 宿主机容器自愈方法、装置及***
CN111880977A (zh) * 2020-07-16 2020-11-03 北京天维信通科技有限公司 故障自愈方法和装置、设备及存储介质
CN111880977B (zh) * 2020-07-16 2022-02-08 北京天维信通科技有限公司 故障自愈方法和装置、设备及存储介质
CN111858176A (zh) * 2020-07-22 2020-10-30 欧冶云商股份有限公司 一种远程监控故障自愈***和方法
CN112214409B (zh) * 2020-10-13 2023-11-24 中国工商银行股份有限公司 一种用于测试环境下的运维方法及装置
CN112214409A (zh) * 2020-10-13 2021-01-12 中国工商银行股份有限公司 一种用于测试环境下的运维方法及装置
CN112350862A (zh) * 2020-10-30 2021-02-09 广州市汇聚支付电子科技有限公司 一种监控报警及故障自愈***
CN112328372A (zh) * 2020-11-27 2021-02-05 新华智云科技有限公司 一种kubernetes节点自愈方法和***
CN112905352A (zh) * 2021-01-29 2021-06-04 北京深演智能科技股份有限公司 节点死锁处理的方法和装置
CN113590370B (zh) * 2021-08-06 2022-06-21 北京百度网讯科技有限公司 一种故障处理方法、装置、设备及存储介质
WO2023011160A1 (zh) * 2021-08-06 2023-02-09 北京百度网讯科技有限公司 一种故障处理方法、装置、设备及存储介质
CN113590370A (zh) * 2021-08-06 2021-11-02 北京百度网讯科技有限公司 一种故障处理方法、装置、设备及存储介质
WO2023056831A1 (zh) * 2021-10-09 2023-04-13 中兴通讯股份有限公司 故障修复方法、装置、电子设备及存储介质

Similar Documents

Publication Publication Date Title
CN110430071A (zh) 业务节点故障自愈方法、装置、计算机设备及存储介质
US11868237B2 (en) Intelligent services for application dependency discovery, reporting, and management tool
CN107544839B (zh) 虚拟机迁移***、方法及装置
CN103607297B (zh) 一种计算机集群***的故障处理方法
CN109586952B (zh) 服务器扩容方法、装置
CN103810076B (zh) 数据复制的监控方法及装置
CN107659431A (zh) 接口处理方法、装置、存储介质和处理器
CN106789306B (zh) 通信设备软件故障检测收集恢复方法和***
CN102571498B (zh) 故障注入控制方法和装置
CN104243232B (zh) 虚拟网故障探测和定位方法
CN111897671A (zh) 故障恢复方法、计算机设备及存储介质
CN106161090A (zh) 一种分区集群***的监测方法及装置
CN106130778A (zh) 一种处理集群故障的方法及一种管理节点
CN104125085A (zh) 一种基于esb的数据管控方法及装置
CN105893211A (zh) 一种监控的方法及***
CN108769170A (zh) 一种集群网络故障自检***及方法
CN110365537A (zh) 中间件业务故障处理方法及***
CN109412902A (zh) 一种电力调度数据网***的智能监测方法、存储设备、终端和***
CN109901969A (zh) 一种集中监控管理平台的设计方法及装置
CN114422386B (zh) 一种微服务网关的监测方法及装置
CN103870349B (zh) 用于数据处理***的配置管理装置及方法
CN102571438B (zh) 远程监护***及其自动网络诊断方法
CN110474821A (zh) 节点故障检测方法及装置
CN103188113A (zh) 一种通信设备的故障处理方法
CN113032218B (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
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20191108