一种监控系统的告警方法及系统与流程

本发明涉及计算机技术领域，特别地涉及一种监控系统的告警方法及系统。

背景技术：

目前大部分公司、企业存在不同层级服务的监控系统，例如运维监控系统，服务监控系统，h5监控系统等。但仍然存在诸多问题。一方面，发生事故时，不同层级的监控系统都会报警，报警方式通常为单点报警方式，即发生了故障后即报警。当报警信息之间的关联需要工作人员依靠业务水准进行梳理、才能确定影响业务或服务的关键问题。在另一方面，现有的监控系统仅仅是在故障发生时发出报警信息，在没有解决时持续报警，没有对故障的处理给出有效的监管措施。

技术实现要素：

针对现有技术中存在的技术问题，本发明提出了一种监控系统的告警方法及系统，能够在系统发生故障时及时报警并对报警故障的解决提供监管措施。

为了解决上述技术问题，根据本发明的一个方面，本发明提供了一种监控系统的告警方法，其中包括：

根据报警规则分析监控指标数据，响应于监控指标数据满足报警规则生成第一报警数据，所述第一报警数据至少包括故障级别、层级服务标识和监控指标数据；

分析报警数据，在报警数据满足报警条件时，按照报警数据的故障级别及其影响的服务，选择所述服务的特定人员或人群作为报警对象进行报警；以及

在报警后的预置时间段内仍有相同的新增报警数据时升级报警对象。

为了解决上述技术问题，根据本发明的另一个方面，本发明提供了一种监控系统的告警系统，包括报警数据单元、报警分析单元和报警通知单元，其中，所述报警数据单元经配置以根据报警规则分析监控指标数据以生成相应故障级别的第一报警数据，所述第一报警数据至少包括故障级别、层级服务标识和监控指标数据；所述报警分析单元经配置以根据报警条件分报警数据，在报警数据满足报警条件时生成报警通知；所述报警通知单元经配置响应于报警通知，根据报警数据的故障级别及其影响的服务，选择所述服务的相关人员作为报警对象进行报警，并在报警后的预置时间内仍有新增报警数据生成时，升级报警对象。

本发明采用面向服务、业务的流式报警，既减少了报警数量，也为服务人员明确确定了受影响服务及故障点。在报警的方式处理上采用自动确定处理策略模式，结合现有通讯工具，设置不同的报警策略，包括处理人员的指定、处理时限的要求及未处理的进一步措施等，通过所述监管措施加快了报警处理，提高了故障处理效率，并且适用场景范围广。

附图说明

下面，将结合附图对本发明的优选实施方式进行进一步详细的说明，其中：

图1是根据本发明的一个实施例的监控系统的告警方法流程图；

图2是根据本发明的一个实施例的企业服务层级监控模块分布示意图；

图3是根据本发明的一个实施例的报警数据示意图；

图4a-4c是根据本发明的一个实施例的报警处理流程图；

图5是根据本发明的一个实施例的在工作群中贴出的报警信息示意图；

图6是根据本发明的一个实施例的监控系统的告警系统原理框图；

图7是根据本发明的一个实施例的报警规范示意图；以及

图8是根据本发明另一实施例的告警系统的原理框图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在以下的详细描述中，可以参看作为本申请一部分用来说明本申请的特定实施例的各个说明书附图。在附图中，相似的附图标记在不同图式中描述大体上类似的组件。本申请的各个特定实施例在以下进行了足够详细的描述，使得具备本领域相关知识和技术的普通技术人员能够实施本申请的技术方案。应当理解，还可以利用其它实施例或者对本申请的实施例进行结构、逻辑或者电性的改变。

如图1所示，为根据本发明一个实施例的监控系统的告警方法流程图。在所述实施例中，所述方法包括以下步骤：

步骤s1，根据报警规则分析监控指标数据，响应于监控指标数据满足报警规则生成第一报警数据。本步骤中第一报警数据是服务端根据监控指标数据得到的，本发明也可以直接接收来自层级监控模块的层级报警数据和其他报警源的报警数据，本发明将这些报警数据综合在一起进行处理，为了区分不同来源的报警数据，将通过步骤s1生成的、由服务端得到的报警数据称为第一报警数据，将其他报警源发送的报警数据发送来的数据称为第二报警数据，层级监控模块发送来报警数据称为层级报警数据。在本发明以下的说明中，如没有特别说明，报警数据可以是这三种报警数据的任何一种。由于对其处理方式相同，因而在进行报警处理时不需刻意区分。

在一个企业中，其提供的服务，也可以称为业务，按照服务/业务数据流向，可分为客户端、接入层、服务层。其中，服务层又包括服务入口和内部服务，在本实施例中，根据这些层次，分别设置监控模块，在本发明中称为层级监控模块。如图2所示，为一个实施例的企业服务层级监控模块分布示意图。客户端其中，在一个实施例中，客户端监控模块m1设置在该服务的客户端中，其中，安装有客户端的终端可以是ios终端，也可以是android终端，另外，客户端也可以是h5页面。接入层监控模块m2可设置在接入层设备中，例如slb(负载均衡器，serverloadbalancer)、vtm(virtualtrafficmanager，虚拟流量管理器)、kong(基于nginx的apigateway)等等。服务层监控模块包括入口监控模块m3和内部服务监控模块m4。其基于nginx(web服务器/反向代理服务器、电子邮件代理服务器等服务器)和php及go语言的服务模块进行监控按照监控指标。所述层级监控模块在对应层级模块的预置位置埋点，并设置上报数据时的数据格式，其中，设置了在数据中填加该埋点数据的来源服务标识，根据所述层级模块的不同，标识对应的层级服务标识。服务层监控模块可以直接上报监控数据，也可以上报按照监控指标根据监控数据得到的监控指标数据，此时，还可以在层级监控模块设置层级报警规则，层级监控模块根据层级报警规则生成层级报警数据而上报。

本发明中的报警数据至少包括故障级别、层级服务标识和监控指标数据。对于其他报警源的第二报警数据，其中的服务标识为报警源标识。其中，所述报警规则从服务特点、预期效果等出发，包括了各种需要报警的规则，当所述监控指标数据满足报警规则时则生成报警数据，并在报警数据中注明服务标识、主题(如报警规则名称或内容)以及更为详细内容，如涉及到的监控指标数据、监控数据链接等。如图3所示，为两条报警数据，在该标题中包括了服务标识：midu，报警规则名称：请求非200比例5％，在详细信息中，记载了该报警数据所在的当前服务：其中的一个的当前服务是midu-backend-midu-admin-gateway，具体报警内容是intruvertqps请求非200比例超过5％，并给出了具体值为100％。在本实施例中，根据报警数据中的服务层级明确确定了受影响的业务一个是网关，一个是对外服务api。在一个实施例中，在得到多个报警数据时，会按照报警数据的层级服务标识，根据服务之间的调用关系，将具有服务调用关系的报警数据关联在一起生成报警链路。并记录服务调用链路。为了能在每一个报警数据中得到报警链路情况，在得到报警链路时在报警数据中记录所述报警数据服务调用链路信息。用户可点击链路上的任何一个来查询具体的报警信息。当用户点击报警数据来查询时，响应于查询指令，从时间序列数据库中获取所述报警数据的特征标签内容，其中记载了详细的数据，如监控指标名称、故障级别、当前指标值、监控数据的链接等等。

步骤s2，取一报警数据进行分析。

步骤s3，判断是否满足报警条件。如果满足，则在步骤s4，选择所述服务的特定人员或人群作为报警对象进行报警并计时，再执行步骤s5。如果不满足，返回步骤s2，重新分析另一报警数据。

步骤s5，判断在计时时间到是否仍有相同的新增报警数据，如果有，则在步骤s6升级报警对象，如果没有，说明本次报警处理完成，结束对该次报警的处理。

在一个实施例中，报警条件包括满足故障级别及报警链路长度。例如，当报警数据的故障级别为灾难级别即可满足报警条件。如果报警数据的故障级别低于灾难级别，则在报警链路的级数达到预定数量时即可满足报警条件。在满足报警条件时，根据故障级别及其影响的服务，选择所述服务的相关人员作为报警对象进行报警。其中，资产管理数据库中配置有资产、业务、服务、应用及多级负责工作人员，通过该配置表可以确定不同级别、不同服务的人员。对报警处理的一个实施例如图4a-4c所示。

步骤s41，获取一个新增报警数据。在一个实施例中，每当产生一个报警数据时，均需要按照图4a-4c的流程判断是否需要报警及如何处理。

步骤s42，判断当前生成的报警数据的故障级别是否为最高的灾难级别，如果为灾难级别，需要立即处理。则执行步骤s43。如果不是破灾难级别，如不同级别的风险级别，则执行步骤s421，详见图4b。

步骤s43，获取该层级服务的特定指定人员，通过通讯终端向所述特定工作人员发送紧急通知。通常在企业内部会有资产管理数据库，其中配置有对相应资产、业务、服务、应用的多级负责工作人员，通常查询资产管理数据库的工作人员配置表，可以得到某个服务的灾难级故障的处理人员及其通知方式，如电话号码。通过通讯终端向所述特定工作人员发送紧急通知，例如通过语音告知该特定人员报警的主题、详细内容及处理时限。而后计时根据所述处理时限计时。

步骤s44，在计时时间到判断该次报警是否已处理。如果没有，则执行步骤s441，详见图4c。如果已经处理执行步骤s45。

步骤s45，计时并监测新增报警数据。

步骤s46，判断在5分钟内是否有相同的新增报警数据，如果有，说明该问题的处理没有成功，此时需要升级处理人员，则执行步骤s47。如果在5分钟内没有相同的新增报警数据，说明该报警中的故障已经消除，则结束此报警处理流程。

步骤s47，获取该层级服务的多名指定人员，通过即时通讯应用建立工作群组并计时。在即时通讯应用的工作群中贴出报警信息，包括故障主题、影响的服务名称、发生时间、报警数据详细信息的链接、处理负责人及处理时限等。其中一个实施例如图5所示。

步骤s48，在计时时间到判断是否已处理，如果已处理，则转到步骤s45。如果没有处理，则在步骤s49，向该群中拉中高级处理人员已升级所述工作群组，再返回步骤s48。

参见图4b。此流程承接步骤s42中，当报警数据的故障级别不是最高的灾难级别时的处理流程，简要描述如下：

步骤s421，判断是否达到预置的报警链路级数。如2、4、5级等，可根据故障级别及具体服务类别设置不同的级数。如果达到了，则执行步骤s422，否则重复步骤s421。

步骤s422，从资产管理数据库获取该服务指定的处理人员。

步骤s423，利用即时通讯应用建立一级工作群组，并计时，如3分钟。

步骤s424，在计时时间到时判断该报警故障是否已处理，如果已处理，则转到步骤s426，否则在步骤s425，向该群中拉中高级处理人员已升级所述工作群组，再返回步骤s424。

步骤s426，计时并监测新增报警数据。

步骤s427判断在5分钟内是否有相同的新增报警数据，如果有，说明该问题的处理没有成功，此时需要升级处理人员，则执行步骤s425。如果在5分钟内没有相同的新增报警数据，说明该报警中的故障已经消除，则结束此报警处理流程。

参见图4c，此流程承接步骤s44中判断通讯终端报警没有处理的流程。

简要描述如下：

步骤s441，获取该层级服务的多名指定人员。

步骤s442，通过即时通讯应用建立一级工作群组并计时。

步骤s443，在计时时间到判断是否已处理，如果已处理，则转到步骤s445。如果没有处理，则在步骤s444，向该群中拉中高级处理人员已升级所述工作群组，再返回步骤s443。

步骤s445，计时并监测新增报警数据。

步骤s446，判断在5分钟内是否有相同的新增报警数据，如果有，说明该问题的处理没有成功，此时需要升级处理人员，则执行步骤s444。如果在在5分钟内没有相同的新增报警数据，说明该报警中的故障已经消除，则结束此报警处理流程。

本发明将现有的单点报警方式改为面向服务、业务的流式报警。既减少了报警数量，也为服务人员明确确定了受影响服务及故障点。在报警的方式处理上，由现有的研发自主处理模式变成自动确定处理策略模式，通过结合现有通讯工具，设置不同的报警策略，包括处理人员的指定、处理时限的要求及未处理的进一步措施等，例如，严重问题3分钟在即时通讯应用中拉群通告、5分钟升级、10分钟到技术中心负责人，因而本发明对报警的处理更快。

图6是根据本发明一个实施例的监控系统的告警系统原理框图，其中，所述告警系统包括：报警数据单元1、报警分析单元2和报警通知单元3，其中，所述报警数据单元1和以根据报警规则分析监控指标数据以生成相应故障级别的第一报警数据，所述第一报警数据至少包括故障级别、层级服务标识和监控指标数据。所述报警分析单元2用以根据报警条件分报警数据，在报警数据满足报警条件时生成报警通知。例如报警数据的故障级别为灾难级别时满足报警条件；在所述报警数据的故障级别低于灾难级别时，在聚合同一服务不同层级的报警数据以得到报警链路时满足报警条件。所述报警通知单元3接收到报警通知时，根据报警数据的故障级别及其影响的服务，从资产数据库中选择所述服务的相关人员作为报警对象进行报警，报警时通过通讯终端或即时通讯应用报警。在报警后的预置时间内仍有新增报警数据生成时，升级报警对象。在本发明中，系统中配置有报警策略，如图7所示，其包括不同故障级别的报警处理人员配置、时限、升级报警对象配置及处理流程等。所述报警通知单元3可按照图4a-4c的流程进行报警处理。为了监控报警过程中发出的报警是否已被解除，需设置一个时间段来确定是否还有相同的报警数据产生，这是因为如果报警中的故障没有解决，则会持续报警，因而通过监测在一个合理的时间段内是否有新增相同的报警数据则可以确定本次报警的故障是否已被解决。可依据服务类型、具体的故障确定判断其是否解决的时间段。因而，所述告警系统设置有计时单元4，在报警后计时，在到达计时周期时发送计时信息给所述报警通知单元，供其判断是否还有新增报警数据。

图8是根据本发明另一实施例的告警系统的原理框图，与图6所示实施例相比，本实施例中的告警系统包括数据接口5，其与层级监控模块m1-m4或其他报警源a1-a2相连接，以接收层级监控模块发送的层级报警数据和/或其他报警源发送的第二报警数据。因而，在本实施例，本系统不但可以对本系统产生的报警数据报警处理，也可以对来自层级监控模块和其他报警源的报警数据进行整合，按照相同的报警略策报警，因而报警规范更加统一。通过整合不同的报警来源的报警，将系统的各种服务关联起来，系统整体更加有序、也更容易定位故障。

为了更加清楚地阐述本发明的相关内容，本发明还包括申请日为2020年7月3日，申请号为202010636597.4、发明名称为“一种监控系统及方法”的专利申请的所有内容，以及申请日为2020年7月3日，申请号为202010635157.7、发明名称为“一种监控系统及方法”的专利申请的所有内容。

上述实施例仅供说明本发明之用，而并非是对本发明的限制，有关技术领域的普通技术人员，在不脱离本发明范围的情况下，还可以做出各种变化和变型，因此，所有等同的技术方案也应属于本发明公开的范畴。