一种软件应用服务故障预测及故障自愈的方法及系统

摘要

本发明涉及一种软件应用服务故障预测及故障自愈的方法及系统，其中的方法包括：监控系统对业务系统进行监控；当触发报警时，所述监控系统发送报警到报警控制节点；所述报警控制节点根据预设逻辑进行响应。本发明通过监控系统提前感知到业务系统可能出现的问题，在没有人工干预的情况下，对于即将出现问题的服务进行及时报警及响应，来达到减少因为一个业务问题而引起全部服务的雪崩效应，出现无法对外提供服务的情况。

说明书

技术领域

本发明涉及系统故障处理领域，具体涉及一种软件应用服务故障预测及故障自愈的方法及系统。

背景技术

传统应用服务运维工作，都是在应用服务出现故障之后，人工介入处理对应的故障，这个时候业务已经受到了影响，如果后台没有做熔断机制和服务降级，这样情况下会导致服务出现雪崩效应彻底不可用，给业务上带来非常严重的影响！

具体来说，应用服务出现故障后，对应负责人收到报警之后，由运维工程师和对应的开发工程师一同上线，根据日志和服务出现问题的状况决定怎么处理这样的问题！在处理过程中会出现因为因为对应的工程师无法上线处理或者对业务了解不够全面而无法及时的处理问题，导致应用服务的恢复时间过长，服务长时间无法访问的情况。

以上现有的技术手段是事后反应机制，是在应用服务已经出现无法正常提供服务，然后再去处理，这样已经对用户的使用产生了影响！而且还可能因为处理人员无法及时上线处理而导致更长时间的服务无法正常使用的情况。

发明内容

针对上述技术问题，本发明提供一种软件应用服务故障预测及故障自愈的方法及系统。

本发明解决上述技术问题的技术方案如下：

一种软件应用服务故障预测及故障自愈的方法，包括：

监控系统对业务系统进行监控；

当触发报警时，所述监控系统发送报警到报警控制节点；

所述报警控制节点根据预设逻辑进行响应。

在上述技术方案的基础上，本发明还可以做如下改进。

进一步，所述监控系统对业务系统进行监控，具体包括：

将通过filebeat收集到的应用日志传入logstach，由logstach经过预处理之后，再通过Kafka传给ElasticSearch，通过elasticalert对自定义的关键错误字符进行监控。

进一步，所述监控系统对业务系统进行监控，具体包括：

通过skywalking全链路监控系统对业务的内部调用链路进行监控。

进一步，所述监控系统对业务系统进行监控，具体包括：

对通过zabbix模拟用户访问对应的业务进行监控。

进一步，所述监控系统的数量为三路，所述报警控制节点根据预设逻辑进行响应，具体包括：

如果在同一时间段内仅一个监控系统出现报警，则发送报警给对应负责人员，并记录报警；

如果在同一时间段内有两个监控系统出现报警，则发送报警给对应负责人员，检查对应应用系统的负载情况，如果是压力比较大，则自动扩容应用节点；

如果在同一时间段内三个监控系统均出现报警，则发送报警给对应负责人员，自动扩容应用节点之后，自动把所述应用节点从负载均衡摘除、重启，检测服务正常之后，再上线所述应用节点。

为实现上述发明目的，本发明还提供一种软件应用服务故障预测及故障自愈的系统，包括：

监控系统，用于对业务系统进行监控，还用于当触发报警时，发送报警到报警控制节点；

所述报警控制节点，用于根据预设逻辑进行响应。

进一步，所述监控系统，具体用于：

将通过filebeat收集到的应用日志传入logstach，由logstach经过预处理之后，再通过Kafka传给ElasticSearch，通过elasticalert对自定义的关键错误字符进行监控。

进一步，所述监控系统，具体用于：

通过skywalking全链路监控系统对业务的内部调用链路进行监控。

进一步，所述监控系统，具体用于：

对通过zabbix模拟用户访问对应的业务进行监控。

进一步，所述监控系统的数量为三路，所述报警控制节点，具体用于：

如果在同一时间段内仅一个监控系统出现报警，则发送报警给对应负责人员，并记录报警；

如果在同一时间段内有两个监控系统出现报警，则发送报警给对应负责人员，检查对应应用系统的负载情况，如果是压力比较大，则自动扩容应用节点；

如果在同一时间段内三个监控系统均出现报警，则发送报警给对应负责人员，自动扩容应用节点之后，自动把所述应用节点从负载均衡摘除、重启，检测服务正常之后，再上线所述应用节点。

本发明的有益效果是：

通过监控系统提前感知到业务系统可能出现的问题，在没有人工干预的情况下，对于即将出现问题的服务进行及时报警及响应，来达到减少因为一个业务问题而引起全部服务的雪崩效应，出现无法对外提供服务的情况。

附图说明

图1为本发明实施例提供的一种软件应用服务故障预测及故障自愈的方法的流程图；

图2为本发明实施例提供的另一种软件应用服务故障预测及故障自愈的方法的流程图。

具体实施方式

以下结合附图对本发明的原理和特征进行描述，所举实例只用于解释本发明，并非用于限定本发明的范围。

伴随业务的发展，线上的业务应用越来越多，频繁上线发布，访问量激增。随时都可能出现应用崩掉的可能，而这种可能可以通过日志和监控系统结合来提前感知，并且把这种可能扼杀于摇篮之中，即使有部分应用因为某种原因导致其无法正常提供服务，也会被该发明提前感知，下线然后重启，以达到影响范围最小化的目的。通过本专利的以上方法来达到业务稳定，减少应用业务故障，提升用户业务应用的可用率。

图1为本发明实施例提供的一种软件应用服务故障预测及故障自愈的方法的流程图，如图1所示，该方法包括：

110、监控系统对业务系统进行监控；

可选地，在该实施例中，步骤110具体包括：

1101、将通过filebeat收集到的应用日志传入logstach，由logstach经过预处理之后，再通过Kafka传给ElasticSearch，通过elasticalert对自定义的关键错误字符进行监控；

1102、通过skywalking全链路监控系统对业务的内部调用链路进行监控；

1103、对通过zabbix模拟用户访问对应的业务进行监控。

120、当触发报警时，所述监控系统发送报警到报警控制节点；

具体的，当监控系统执行步骤1101时，比如Nginx的4xx&5xx，在3分钟内出现5次关键错误字符发送报警到报警控制节点。

当监控系统执行步骤1102时，如果业务内部调用的链路大于1秒并且持续3分钟，则把对应的报警发送给报警控制节点。

当监控系统执行步骤1103时，如果访问时间大于平时业务访问响应时间2倍，同时持续3分钟，发送报警到报警控制节点。

130、所述报警控制节点根据预设逻辑进行响应。

具体的，该步骤中，由报警控制节点通过预设的算法来决定该节点是否需要下线重启等进一步的操作。

如图2所示，基于上述过程中的三路监控系统，步骤130具体包括：

1301、如果在同一时间段内仅一个监控系统出现报警，则发送报警给对应负责人员，并记录报警；

1302、如果在同一时间段内有两个监控系统出现报警，则发送报警给对应负责人员，检查对应应用系统的负载情况，如果是压力比较大，则自动扩容应用节点；

步骤1302中，在自动扩容应用节点的同时，还可以发送报警，并提示对应负责人是否需要程序人工干预重启对应应用。

1303、如果在同一时间段内三个监控系统均出现报警，则发送报警给对应负责人员，自动扩容应用节点之后，自动把所述应用节点从负载均衡摘除、重启，检测服务正常之后，再上线所述应用节点。

传统应用运维，都是基于事后处理机制，也就是说在应用已经挂掉，已影响到了用户正常使用的情况下再处理。这样的处理方式会给公司的发展和用户的体验上带来很大的伤害，甚至可能会让公司损失很多用户。

本发明的目的是通过收集应用服务日志结合对应的业务监控系统，提前感知到业务系统可能出现的问题，在没有人工干预的情况下，对于即将出现问题的服务进行自动扩容，离线重启，自动校验，自动上线，来达到减少因为一个业务问题而引起全部服务的雪崩效应，出现无法对外提供服务的情况。

其中预测方法包含，通过自己开发的报警和报警处理控制节点，接收来自日志告警，skywalking，zabbix等报警系统的告警，然后根据预设条件做处理对应的报警。其中利用ELK日志收集系统来收集对应应用服务的前端代理日志和后端服务日志，对这些日志进行存储，分析；根据预设的报警机制为触发条件，当满足触发条件的时候，发送报警到控制节点。通过全链路监控系统skywalking来监控业务之间链路访问时长，如果超出预设时常则发送报警到控制节点，通过zabbix对业务进行模拟用户访问，通过应用响应速度和访问代码来来判断应用是否是处于健康状体，如果超出阈值，把对应报警信息发送到控制节点。

本专利在应用程序刚刚出现异常的情况下就对应用进行干扰，就像我们的身体刚刚出现感冒的征兆时候就开始预防，这样就能尽量避免感冒的发生，我们提前对应用进行干扰，处理之后，可以避免因为一个应用节点挂掉之后，引起雪崩效应，导致应用整体挂掉的情况产生。这样可以大大提高应用的可用性，提高用户的体验满意度。减少因为应用挂掉而损失用户的情况。

本发明实施例提供一种软件应用服务故障预测及故障自愈的系统，包括：

监控系统，用于对业务系统进行监控，还用于当触发报警时，发送报警到报警控制节点；

所述报警控制节点，用于根据预设逻辑进行响应。

可选地，在该实施例中，所述监控系统，具体用于：

将通过filebeat收集到的应用日志传入logstach，由logstach经过预处理之后，再通过Kafka传给ElasticSearch，通过elasticalert对自定义的关键错误字符进行监控。

可选地，在该实施例中，所述监控系统，具体用于：

通过skywalking全链路监控系统对业务的内部调用链路进行监控。

可选地，在该实施例中，所述监控系统，具体用于：

对通过zabbix模拟用户访问对应的业务进行监控。

可选地，在该实施例中，所述监控系统的数量为三路，所述报警控制节点，具体用于：

如果在同一时间段内仅一个监控系统出现报警，则发送报警给对应负责人员，并记录报警；

如果在同一时间段内有两个监控系统出现报警，则发送报警给对应负责人员，检查对应应用系统的负载情况，如果是压力比较大，则自动扩容应用节点；

如果在同一时间段内三个监控系统均出现报警，则发送报警给对应负责人员，自动扩容应用节点之后，自动把所述应用节点从负载均衡摘除、重启，检测服务正常之后，再上线所述应用节点。

读者应理解，在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述系统实施例中的模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本发明实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。