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

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

背景技术：

目前大部分公司、企业存在不同层级服务的监控系统，例如运维监控系统，服务监控系统，h5监控系统等。一方面，发生事故时，不同层级的监控系统都会报警，工作人员很难从众多的监控报警信息中及时、快速地定位故障。并且由于监控的指标项非常多，收集的日志冗余，需要工作人员有较高的业务水准才能从众多的数据中发现影响业务的关键问题，即使工作人员的业务水准很高，也很难快速、及时地发现关键问题。在另一方面，目前不同层级的监控系统处于割裂工作状态，而对于多维度整体的业务服务，目前没有一种查看其长期状态的方式，无法为评价所述服务提供简洁、清晰地依据。

技术实现要素：

针对现有技术中存在的技术问题，本发明提出了一种监控系统及方法，能够适合不同监控场景，快速定位故障，并提供对应的报警及处理方式。

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

在服务的多个层级模块布置层级监控模块，基于服务采集该层级模块的监控数据，所述监控数据至少包括层级服务标识和监控内容；

按照监控指标获取对应的监控数据并得到对应的监控指标数据；

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

分析报警数据，响应于报警数据满足报警条件，根据报警策略报警。

为了解决上述技术问题，根据本发明的一个方面，本发明提供了一种监控系统，包括层级监控模块、数据处理模块、报警数据模块和报警模块，其中，所述层级监控模块经配置以布置在服务的多个层级模块，基于服务采集该层级模块的监控数据，所述监控数据至少包括层级服务标识和监控内容；所述数据处理模块经配置以按照监控指标获取对应的监控数据并得到对应监控指标数据；所述报警数据模块经配置以响应于所述监控指标数据满足报警规则生成报警数据，所述报警数据至少包括故障级别、层级服务标识和监控指标数据；所述报警模块经配置以分析报警数据，响应于报警数据满足报警条件，根据报警策略报警。

本发明可适用于多种监控场景，在层级模块具有处理能力时，可以仅进行报警处理，当层级模块不具有处理能力时可提供数据处理功能，并且可以外接多种不同的报警源，适用范围广、系统搭建方便。本发明基于服务采集数据将现有的单点报警模式变成面向服务/业务的流报警模式，能够快速定位故障点，并且可以快速量化对当前故障对服务/业务的影响。本发明在报警的处理方式上，由现有的研发自主处理模式变成自动确定处理策略模式，通过结合现有通讯工具，设置不同的报警策略，可以快速处理报警事件。

附图说明

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

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

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

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

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

图5是根据本发明的一个实施例的报警工作群的通知示意图；

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

图7是根据本发明的一个实施例的层级监控模块原理框图；

图8是根据本发明的一个实施例的报警数据模块原理框图；

图9是根据本发明的一个实施例的报警模块原理框图；以及

图10是根据本发明的另一个实施例的监控系统原理框图。

具体实施方式

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

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

图1为根据本发明一个实施例的监控方法流程图，其中所述方法包括：

步骤s10，在服务的多个层级模块布置层级监控模块，基于服务采集该层级模块的监控数据，所述监控数据至少包括层级服务标识和监控内容。其中，在一个企业中，其提供的服务，也可以称为业务，按照服务/业务数据流向，可分为客户端、接入层、服务层。其中，服务层又包括服务入口和内部服务，在本实施例中，根据这些层次，分别设置监控模块，在本发明中称为层级监控模块。如图2所示，为一个实施例的企业服务层级监控模块分布示意图。客户端其中，在一个实施例中，客户端监控模块m1设置在该服务的客户端中，其中，安装有客户端的终端可以是ios终端，也可以是android终端，另外，客户端也可以是h5页面。接入层监控模块m2可设置在接入层设备中，例如slb(负载均衡器，serverloadbalancer)、vtm(virtualtrafficmanager，虚拟流量管理器)、kong(基于nginx的apigateway)等等。服务层监控模块包括入口监控模块m3和内部服务监控模块m4。其基于nginx(web服务器/反向代理服务器、电子邮件代理服务器等服务器)和php及go语言的服务模块进行监控。所述层级监控模块按照监控指标在对应层级模块的预置位置埋点，并设置上报数据时的数据格式，其中，设置了在数据中填加该埋点数据的来源服务标识，根据所述层级模块的不同，标识对应的层级服务标识。其中，根据不同的服务、层级、监控目的灵活设置多种监控指标，例如：入口流量、网关(例如kong、vtm)非200比例、业务层(nginx、go、sidecar)非200、域名不可访问和sidecar限流熔断、平均延迟时间等等。根据这些监控指标确定所需要采集的数据，从而在相应的层级埋点以采集对应的数据。

步骤s11，获取层级监控模块采集的监控数据。在一个实施例中，层级监控模块采集到监控数据后即上报给服务端，服务端将层级监控模块上报的监控数据存储在时间序列数据库中，并在一个或多个样本特征标签中分别记录所述监控数据的层级服务标识和监控内容。在需要获取监控数据时，通过预留的监控接口采用pull模式从时间序列库拉取各个层级监控模块的监控指标数据。在另一个实施例中，层级监控模块在采集到监控数据时，并不上报可是要自己处理得到监控指标数据再上报。

步骤s12，按照监控指标处理相应的监控数据并得到对应的监控指标数据。此步骤可以在层级监控模块完成，也可以由服务端完成。根据设置的监控指标对相应的监控数据进行统计、合并或计算等操作而得到对应的监控指标数据。例如：对于“非200比例”这一监控指标，对网关kong的监控数据统计、计算，得到该比例为8％，则“非200比例”这一监控指标数据内容包括：层级服务标识：kong，内容(或值)为8％，另外还可以包括计算使用的监控指标数据的存储链接。在一个实施例中，所述监控指标可分为服务通用指标和层级服务特定指标。例如，将非200错误比例和平均延迟时间设置为通用指标，根据各个层级服务设置包括符合各自特点的监控指标。当该步骤在层级监控模块完成时，层级监控模块上报所述监控指标数据，服务端将其以指标样本的形式存储到时间序列库中。在样本的特征标签中记载不同类别的数据，如服务名称、所在层级、监测内容等等。

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

步骤s14，分析报警数据，响应于报警数据满足报警条件，根据报警策略报警。本步骤中报警数据可以是服务端根据监控指标数据得到的，也可以是直接从层级监控模块接收的层级报警数据，本发明将这些报警数据综合在一起进行处理，因而即可以根据服务端得到的报警数据报警，也可以根据与其连接的层级报警数据进行报警，进一步地，还可以对连接的其他报警源的报警数据进行报警，从而将多种报警方式聚合在一起报警。在一个实施例中，报警条件包括满足故障级别及报警链路长度。例如，当报警数据的故障级别为灾难级别即可满足报警条件。如果报警数据的故障级别低于灾难级别，则在报警链路的级数达到预定数量时即可满足报警条件。在满足报警条件时，根据故障级别及其影响的服务，选择所述服务的相关人员作为报警对象进行报警。其中一个实施例如图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、报警数据模块3和报警模块4，在本实施例中，还可以连接其他的报警源a1、a2。其中，所述层级监控模块1经配置以布置在服务的多个层级模块，基于服务采集该层级模块的监控数据，所述监控数据至少包括层级服务标识和监控内容。在一个实施例中，如图7所示。所述层级监控模块1包括：埋点采集单元11和数据上报单元12。其中，所述埋点采集单元1按照监控指标在应层级模块的预置位置以埋点的方式采集数据。服务端根据监控指标的需要，确定需要采集的数据及采集的位置，从而在相应的层级模块中埋点。数据上报单元12按照服务端配置以数据格式上报数据，其中，所述格式至少包括在数据中设置服务标记。在一些实施例中，数据上报单元12将埋点采集单元11采集到的监控数据直接上报。而在另一些实施例中，所述层级监控模块1还包括层级数据处理单元13和层级报警数据单元14。层级数据处理单元13以按照层级监控指标数据，根据埋点数据生成监控指标数据；所述数据上报单元12按照预置格式上报所述监控指标数据。层级报警数据单元14按照层级报警规则生成层级报警数据；所述数据上报单元12按照预置格式上报所述层级报警数据。在本实施例中，层级监控模块1将监控指标数据、监控数据上报存储到时间序列数据库5中。

报警数据模块3通过监控接口2以pull模式从时间序列数据库5中获取所需要的监控指标数据，并按照报警规则分析所述监控指标数据。响应于所述监控指标数据满足报警规则生成报警数据，所述报警数据至少包括故障级别、层级服务标识和监控指标数据。在一个实施例中，如图8所示，所述报警数据模块3包括报警数据生成单元31和报警链路单元32，其中，所述报警数据生成单元31根据报警规则生成报警数据；所述报警链路单元32根据报警数据的服务层级，按照服务调用关系建立报警链路。其中，所述报警链路单元32处理的报警数据包括来自于报警数据生成单元31，也可以来自于层级报警数据单元14及其他报警源a1-a2。所有的报警数据可存储在时间序列数据库5。例如，在监控接口接收到来自于层级报警数据单元14及其他报警源a1-a2的报警数据时，将其存储到时间序列数据库5中，同时通知报警数据模块3和报警模块4。

报警模块4接收到报警数据后分析报警数据，响应于报警数据满足报警条件，根据报警策略报警。具体地，如图9所示。所述报警模块4包括报警单元41和报警通知单元42。其中，所述报警单元41在报警数据满足报警条件时生成报警通知。所述的报警条件例如为如故障级别、报警链路长度。在报警数据的故障级别为灾难级别即可满足报警条件；或者报警数据的故障级别低于灾难级别，则在报警链路的级数达到预定数量时即可满足报警条件。所述报警通知单元42在收到报警通知时，根据报警策略报警。其中，所述的报警策略包括与故障级别对应的报警发出时限、通知工具和工作人员配置中的一者或多者。所述通知工具包括通讯终端和即时通讯应用。如图4a-图4c所示。在报警的故障在规定的时限内没有被处理或处理成功时，逐级升级工作群组，因而，报警模块4还包括计时单元43，用于在所述报警通知单元42向工作人员发出报警后计时；以及所述报警通知单元响应发出通知的预置时间内仍有相同的新增报警数据，升级报警策略。

如图10所示，为本发明另一个实施例的监控系统原理框图。与图6中的实施例相比，本发明中的层级监控模块仅上报监控数据，因而在所述系统中还包括数据处理模块6，用于按照预定的监控指标处理上报的监控数据以得到监控指标数据。在层级监控模块不具有处理能力时，本发明可提供数据处理的功能。

本发明可适用于多种监控场景，层级具有处理能力时，可以仅进行报警处理，当层级模块不具有处理能力时可提供数据处理功能，并且可以外接多种不同的报警源，适用范围广、系统搭建方便。本本基于服务采集数据，并建立了基于服务调用关系的报警链路，将现有的单点报警模式变成面向服务/业务的流报警模式，能够快速定位故障点，并且可以快速量化对当前故障对服务/业务的影响。

本发明中设置的监控指标侧重于评估服务的可用性，如不可用、少量问题、大量问题和正常状态，设置通用服务指标和层级服务指标，因而设置的监控指标及报警规则不再纷繁复杂。并且本发明中的监控数据、监控指标数据、报警数据均以指标(metric)的形式保存在内置的时间序列数据库当中，通过强大的数据模型，方便了监控过程中数据的统计、调用、查看等。

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

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