告警聚合发送的方法、系统、计算机设备及存储介质

技术领域

本申请涉及金融科技及互联网技术领域，尤其涉及一种告警聚合发送的方法、系统、计算机设备及存储介质。

背景技术

告警发送环节作为整个监控告警系统的最后一环，承担着将最终的监控异常数据发送出去的任务。但当前的主流告警系统往往功能比较呆板，倾向于只要存在异常数据就会向用户发送告警通知，导致用户可能会在短时间内频繁接收大量重复告警信息，造成信息冗余，给用户带来不必要的干扰。特别是在金融科技，例如银行、保险等领域，各种业务系统繁多，如果按照现有技术对业务系统进行监控和告警，则会产生大量的冗余消息或信息，给业务方带来极大干扰和困扰。

发明内容

本申请的主要目的在于提供一种告警聚合发送的方法、系统、计算机设备及存储介质，可以解决现有技术中的监控系统告警发送信息冗余的技术问题。

为实现上述目的，本申请第一方面提供一种告警聚合发送的方法，应用于告警聚合发送系统，该方法包括：

接入至少一个场景节点的监控数据；

查询每组目标监控数据的分类分级信息和告警配置数据；

根据同一个目标场景节点的告警配置数据及已有监控数据，判断当前目标场景节点是否触发告警事件，其中，已有监控数据包括当前获取的目标监控数据和从当前时刻至上一次业务监测告警时刻之间的历史目标监控数据；

若触发告警事件，则基于聚合周期和聚合规则，根据同一个业务系统中触发告警事件的目标场景节点的已有监控数据，进行数据聚合；

根据得到的聚合数据向相应用户发送告警。

为实现上述目的，本申请第二方面提供一种告警聚合发送系统，该告警聚合发送系统包括：分类分级系统和聚合发送子系统；

聚合发送子系统，用于接入至少一个场景节点的监控数据，并向分类分级系统发送查询指令；

分类分级系统，用于根据查询指令查询每组目标监控数据的分类分级信息和告警配置数据，并向聚合发送子系统返回查询结果；

聚合发送子系统，用于根据同一个目标场景节点的告警配置数据及已有监控数据，判断当前目标场景节点是否触发告警事件，其中，已有监控数据包括当前获取的目标监控数据和从当前时刻至上一次业务监测告警时刻之间的历史目标监控数据；若触发告警事件，则基于聚合周期和聚合规则，根据同一个业务系统中触发告警事件的目标场景节点的已有监控数据，进行数据聚合；根据得到的聚合数据向相应用户发送告警。

为实现上述目的，本申请第三方面提供一种计算机可读存储介质，存储有计算机程序，计算机程序被处理器执行时，使得处理器执行以下步骤：

接入至少一个场景节点的监控数据；

查询每组目标监控数据的分类分级信息和告警配置数据；

根据同一个目标场景节点的告警配置数据及已有监控数据，判断当前目标场景节点是否触发告警事件，其中，已有监控数据包括当前获取的目标监控数据和从当前时刻至上一次业务监测告警时刻之间的历史目标监控数据；

若触发告警事件，则基于聚合周期和聚合规则，根据同一个业务系统中触发告警事件的目标场景节点的已有监控数据，进行数据聚合；

根据得到的聚合数据向相应用户发送告警。

为实现上述目的，本申请第四方面提供一种计算机设备，包括存储器和处理器，存储器存储有计算机程序，计算机程序被处理器执行时，使得处理器执行以下步骤：

接入至少一个场景节点的监控数据；

查询每组目标监控数据的分类分级信息和告警配置数据；

根据同一个目标场景节点的告警配置数据及已有监控数据，判断当前目标场景节点是否触发告警事件，其中，已有监控数据包括当前获取的目标监控数据和从当前时刻至上一次业务监测告警时刻之间的历史目标监控数据；

若触发告警事件，则基于聚合周期和聚合规则，根据同一个业务系统中触发告警事件的目标场景节点的已有监控数据，进行数据聚合；

根据得到的聚合数据向相应用户发送告警。

采用本申请实施例，具有如下有益效果：

本申请通过接入场景节点的监控数据，对目标监控数据进行告警触发判断，并根据聚合周期和聚合规则对触发告警事件的目标场景节点的监控数据进行数据聚合，根据聚合数据向用户发送告警。本申请通过数据聚合，既保证了用户可以及时获取到对业务系统的告警，又可以减少消息冗余，降低对用户的频繁干扰；另外，构建了不同场景节点的监控数据的分类分级，对监控数据进行清晰划分，便于快速、准确查找并定位到业务系统的问题，以及管理各个业务系统各个场景节点的告警工作，可接入任意业务系统，适用范围广。特别是对于金融科技领域，各种银行系统、保险系统、金融APP层出不穷，均可以由告警聚合发送系统进行统一告警管理，高效便捷。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

其中：

图1为本申请实施例中告警聚合发送方法的应用环境图；

图2为本申请实施例中告警聚合发送方法的流程图；

图3为本申请实施例中告警聚合发送系统的结构框图；

图4为本申请实施例中计算机设备的结构框图。

具体实施方式

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

图1为一个实施例中告警聚合发送的方法的应用环境图。参照图1，该告警聚合发送的方法应用于告警聚合发送系统。该告警聚合发送系统包括终端110和服务器120。终端110和服务器120通过网络连接，终端110具体可以是台式终端或移动终端，移动终端具体可以是手机、平板电脑、笔记本电脑等中的至少一种。服务器120可以用独立的服务器或者是多个服务器组成的服务器集群来实现。终端110用于向服务器120发送各种用户指令以自定义告警聚合发送系统的各项配置等数据，服务器120用于接入至少一个场景节点的监控数据；查询每组目标监控数据的分类分级信息和告警配置数据；根据同一个目标场景节点的告警配置数据及已有监控数据，判断当前目标场景节点是否触发告警事件，其中，已有监控数据包括当前获取的目标监控数据和从当前时刻至上一次业务监测告警时刻之间的历史目标监控数据；若触发告警事件，则基于聚合周期和聚合规则，根据同一个业务系统中触发告警事件的目标场景节点的已有监控数据，进行数据聚合；根据得到的聚合数据向相应用户发送告警。

如图2所示，在一个实施例中，提供了一种告警聚合发送的方法。该告警聚合发送的方法具体包括如下步骤：

S100：接入至少一个场景节点的监控数据。

具体地，告警聚合发送的方法应用于告警聚合发送系统，或者，告警聚合发送的方法应用于告警聚合发送系统的聚合发送子系统。

告警聚合发送系统可以接入至少一个业务系统的至少一个场景节点。其中，每个业务系统包括至少一个场景节点。告警聚合系统会接收到接入的每个场景节点的监控数据，并根据这些监控数据确定何时发送告警以及确定告警内容。

S200：查询每组目标监控数据的分类分级信息和告警配置数据。

具体地，目标监控数据为接收到的监控数据，根据目标监控数据所属场景节点，可以匹配或查询到目标监控数据所属分类分级。分类分级信息用于指示目标监控数据的归属和来源。

分类分级信息例如包括监控数据所属业务单元、所属领域、所属业务系统(或APP等)的系统标识(或App ID等)、告警级别等其中的至少一种。

在一个具体实施例中，按照不同层级将同一个业务系统划分了多个分类和子分类，每个分类或子分类挂载有相应的场景节点。例如，以金融科技领域为例，将一个金融业务系统划分为了业务层、客户端、应用层和基础层等多个顶层分类。

业务层包括：网络金融、信用卡等多个子分类，其中，网络金融包括至少一个交易场景，每个交易场景为一个场景节点。

客户端包括：PC端和APP端等多个子分类，PC端和APP端均包括多个网页链接(URL)，每个网页链接为一个场景节点。

应用层包括：网关中间件、应用容器、消息中间件、存储中间件、数据库等多个子分类。其中，网关中间件包括nginx(SLB)、ESA、ESB等多个场景节点；消息中间件包括ISC、ROCKET-MQ、KAFKA等多个场景节点；存储中间件包括REDIS、MongoDB等多个场景节点；数据库包括ORACLE、MYSQL等多个场景节点。

基础层包括：物理服务器、交换机、路由器、防火墙等多个子分类。其中，物理服务器包括dock、VPM等多个场景节点。

当然，上述仅仅是一种示例性举例，具体的分类分级根据实际应用场景配置，本申请对此不做限制。

告警配置数据包括了告警规则。每个场景节点都有对应的告警配置数据，告警配置数据可以是默认配置，也可以是用户自定义配置，本申请对此不做限制。

构建了告警的分类分级体系，方便将监控数据进行清晰划分，更加易于查找及管理。

S300：根据同一个目标场景节点的告警配置数据及已有监控数据，判断当前目标场景节点是否触发告警事件，其中，已有监控数据包括当前获取的目标监控数据和从当前时刻至上一次业务监测告警时刻之间的历史目标监控数据。

具体地，目标场景节点为其中一个接入的场景节点。由于告警是聚合发送的，并非只要有异常就会不间断告警。因此，在未满足告警条件的情况下，监控数据会先存储起来，等累积到满足告警条件时才会触发告警事件。

基于此，对于同一个目标场景节点，会根据其告警配置数据和已有监控数据判断当前该目标场景节点是否触发告警事件。其中，同一个目标场景节点相邻两次触发告警是存在一定时间间隔的，具体的时间间隔根据实际应用场景配置，本申请对此不做限制。且，触发一次告警事件后，该目标场景节点、用于下一次告警事件判断的监控数据会重新从最新的监控数据中获取。即，不同次触发告警事件所使用的监控数据是不同的。

因此，当前判断是否触发告警事件的已有监控数据是从上一次业务监测告警时刻之后至当前时刻之间收集的。

每组监控数据可以存储于redis等存储单元中，本申请对此不做限制。另外，对于已触发告警事件所使用的监控数据可以定期清除，以减少内存占用。

不同场景节点的监控数据会按照时序进入存储系统，由于需要判定异常总次数或连续异常次数、告警间隔等信息，需要将指示异常的监控数据缓存于存储系统中，每当有新的异常监控数据进入便与该场景节点的历史异常监控数据进行比较，用于判定是否达到告警标准而触发告警。这些用于做告警判断的各项临时缓存数据可以统一存储于redis中等，本申请对此不作限制。

本实施例提供了历史目标监控数据的查询，可明确回溯查询指定时间区段的历史目标监控数据，帮助使用方更加快速、准确定位、回归历史问题。

S400：若触发告警事件，则基于聚合周期和聚合规则，根据同一个业务系统中触发告警事件的目标场景节点的已有监控数据，进行数据聚合。

具体地，聚合周期用于指示同一个业务系统的所有场景节点的监控数据每间隔多长时间聚合一次。聚合规则是指如何聚合同一个业务系统所有场景节点的监控数据，得到聚合数据。

业务方为了避免频繁的收到邮件打扰，采用聚合周期来将触发告警事件的目标监控数据进行聚合。例如，业务方把聚合周期设置为10分钟(600秒)，则告警通知邮件会按照每10分钟发送一封邮件的方式告知业务方这10分钟内发生的告警次数。

每个业务系统对应一套聚合规则和聚合周期。可以实现聚合多样化以及自定义。

同一个业务系统对应多个场景节点，目标场景节点包括至少一个，对于同一个业务系统，可能有多个不同的目标场景节点。因此，可以对同一个业务系统的多个不同的目标场景节点的已有监控数据，进行数据聚合，得到聚合数据。这样既可以一次性打包向用户发送告警信息，也可以有效减少告警频次，减少对用户的打扰。

另外，可以根据同一个业务系统中的各个目标场景节点的分类分级进行数据聚合，因此，同一个业务系统可以得到的至少一组聚合数据。

相较于下主流告警系统往往在聚合多样化等方面上存在一定的不足之处，如Nagios系统，缺乏聚合能力，倾向于发送大量的通知导致信息冗余及带来不必要的干扰；如Zabbix系统，可能对于大规模监控系统中的信息整合和处理比较困难。本实施例根据配置的聚合规则和聚合周期进行数据聚合，间隔一定时长后发送业务系统告警，可以有效减少信息冗余和重复信息对用户的干扰和困扰。

本实施例聚合了同类别的监控数据，供使用方在查看告警异常时能够方便的进行横向对比，同时缩减了不必要的多条单独告警信息，避免了对使用方的打扰，提升了使用效率。

S500：根据得到的聚合数据向相应用户发送告警。

具体地，同一个业务系统得到至少一组聚合数据，可以在同一个告警中发送给用户，也可以分别在不同的告警中发送给用户，本申请对此不做限制。

向用户发送的告警信息中包含了完整告警链路信息，完整链路信息指整个完整告警的归属信息(所属分类或子分类或所属场景节点、所属领域、所属业务想等等)，及整个过程中发生了什么。

另外，向用户发送告警可以是按配置通过邮件、短信、电话及系统消息等任意一种或多种方式向用户发送告警，发送的告警信息中携带了根据聚合数据生成的告警内容。

如果以邮件形式发送，则还可以根据邮件模板编写待发送的告警信息，告警接收组例如为[业务告警_快捷-支付-对公]。

本实施例通过接入场景节点的监控数据，对目标监控数据进行告警触发判断，并根据聚合周期和聚合规则对触发告警事件的目标场景节点的监控数据进行数据聚合，根据聚合数据向用户发送告警。本实施例通过数据聚合，既保证了用户可以及时获取到对业务系统的告警，又可以减少消息冗余，降低对用户的频繁干扰；另外，构建了不同场景节点的监控数据的分类分级，对监控数据进行清晰划分，便于快速、准确查找并定位到业务系统的问题，以及管理各个业务系统各个场景节点的告警工作，可接入任意业务系统，适用范围广。特别是对于金融科技领域，各种银行系统、保险系统、金融APP层出不穷，均可以由告警聚合发送系统进行统一告警管理，高效便捷。

在一个实施例中，步骤S300中根据同一个目标场景节点的告警配置数据及已有监控数据，判断当前目标场景节点是否触发告警事件，包括：

根据同一个目标场景节点的告警配置数据，判断当前目标场景节点是否处于禁止发送告警时间段；

若当前目标场景节点不处于禁止发送告警时间段，则获取当前时刻距离上一次业务监测告警时刻的时间间隔，若时间间隔不超过间隔阈值，则判定当前目标场景节点不可触发告警事件；

若时间间隔超过间隔阈值，则判定当前目标场景节点触发告警事件；或者，若时间间隔超过间隔阈值，则根据目标场景节点的已有监控数据判断异常总次数是否超过次数阈值，若连续异常总次数超过次数阈值，则判定当前目标场景节点触发告警事件。

具体地，禁止发送告警时间段是指在禁止发送告警时间段一个场景节点即使触发了告警事件也不允许发送告警信息给用户，以免打扰用户。

禁止发送告警时间段具体根据实际应用场景由用户配置，本申请对此不做限制。

在一个具体实施例中，根据获取的告警配置数据，判断当前是否已开启告警开关，如果已开启告警开关，则判断当前目标场景节点是否处于禁止发送告警时间段。其中，禁止发送告警时间段包括节假日、静默时间段、屏蔽计划内的时间段等禁止子时间段中的至少一个。如果当前目标场景节点不处于禁止发送告警时间段中任意一个禁止子时间段(例如，不处于节假日，且，不处于静默时间段，且，不在屏蔽计划内的时间段)，则获取当前时刻距离上一次告警的时间间隔，如果时间间隔不超过间隔阈值，则判定当前目标场景节点不可触发告警事件。如果当前目标场景节点处于禁止发送告警时间段中任意一个或多个禁止子时间段，则判定当前目标场景节点不可触发告警事件。

其中，静默时间段是指可配置的每天不发送告警的时间区间，比如00:00–07:00之内不发送告警。

屏蔽计划内的时间段是指：业务方自行配置的在具体时间段内不再发送告警，通常是业务方在该时间段内(比如2023-09-22 18:00至2023-09-22 19:00)进行发版升级，出现异常情况在预期之内。

告警间隔：间隔多长时间的异常会被认定为触发告警事件的一项配置。例如配置该时间为3分钟，那么0分钟触发了告警事件，则0-3分钟内的异常就均不被认定为触发告警事件，从第三分钟开始再发生的异常则会被认定为触发告警事件。

如果时间间隔超过间隔阈值，则判定当前目标场景节点触发告警事件。

或者，

如果时间间隔超过间隔阈值，则进一步根据目标场景节点的已有监控数据统计异常总次数，如果异常总次数超过次数阈值，则判定当前目标场景节点触发告警事件。

其中，针对同一个业务系统可以设置一个统管全系统的告警开关，和/或，为每个分类或子分类各设置一个告警开关，和/或，为每个场景节点设置一个告警开关等等，本申请对此不做限制。

告警开关打开的情况下，才有可能触发告警事件；如果告警开关未打开，则对应的业务系统或分类或子分类或场景节点不能触发告警事件。

已有监控数据包括从不同时刻获取或收集的多组监控数据，每组监控数据包括至少一种异常，对同一个目标场景节点的已有监控数据中的所有异常进行统计，即得到异常总次数。异常总次数可以是每种目标异常的异常总次数，也可以是每种异常的异常总次数，然后取最大异常总次数与次数阈值进行比较。或者，异常总次数还可以是所有类型的异常的异常总次数。

异常总次数还可以是连续多少次的异常会被认定为触发告警事件。真实场景中由于网络抖动等因素异常会间歇性发生，为了规避此种情况下产生的误报，通常会设置为一个合理的连续异常总次数来界定告警的真实发生。比如如设置连续次数为3则表示在时序上该场景连续发生了3次异常事件，认定为触发告警事件。

本实施例通过告警时间段、告警时间间隔以及异常总次数等多个方面综合来准确判断当前目标场景节点是否可以触发告警事件，进而避免误报，以及频繁告警对用户的干扰。

在一个实施例中，步骤S400基于聚合周期和聚合规则，根据同一个业务系统中触发告警事件的目标场景节点的已有监控数据，进行数据聚合，包括以下至少一种：

对同一个业务系统中、所有顶层分类对应的第一监控数据进行第一目标指标聚合，得到第一目标指标数据，其中，第一监控数据包括：同一个业务系统中、所有顶层分类、所有场景节点中触发告警事件的目标场景节点的已有监控数据，

对同一个业务系统中、同一个顶层分类对应的第二监控数据进行第二目标指标聚合，得到第二目标指标数据，其中，第二监控数据包括：同一个业务系统中、同一个顶层分类、所有场景节点中触发告警事件的目标场景节点的已有监控数据，

对同一个业务系统中、同一个子分类对应的第三监控数据进行第三目标指标聚合，得到第三目标指标数据，其中，第三监控数据包括：同一个业务系统中、同一个子分类、所有场景节点中触发告警事件的目标场景节点的已有监控数据，

分别获取同一个业务系统中、各个触发告警事件的目标场景节点的统计数据，其中，统计数据包括业务监测告警时刻和业务监测告警次数；

步骤S500中根据得到的聚合数据向相应用户发送告警，包括：

将目标指标数据和/或统计数据作为聚合数据，根据聚合数据向相应用户发送告警，其中，目标指标数据包括第一目标指标数据、第二目标指标数据和第三目标指标数据中的至少一种。

具体地，同一个业务系统的分类分级中包括至少一个顶层分类和至少一个子分类，顶层分类是最大的分类，子分类是存在父分类的小分类。在同一层级的顶层分类或子分类不具有父子关系。每个顶层分类挂载有至少一个子分类，子分类可以挂载更细分的子分类，即，上一层级的分类或子分类为下一层级的分类或子分类的父分类。

本申请的方案可以对接至少一个业务系统，因此，需要按照业务系统对已有监控数据进行聚合。

本实施例提供了多种聚合规则的聚合方式，如果是以业务系统为单位，对于同一个业务系统，对该业务系统一段时间内所有触发告警事件的目标场景节点的已有监控数据(第一监控数据)进行数据聚合，更具体地，对所有触发告警事件的目标场景节点的已有监控数据进行第一目标指标聚合，得到第一目标指标数据。其中，第一目标指标数据包括至少一组第一目标指标。

如果是以顶层分类为单元，对于同一个业务系统、同一个顶层分类，对于在该顶层分类一段时间内所有触发告警事件的目标场景节点的已有监控数据进行数据聚合，更具体地，对同一个顶层分类对应的、所有触发告警事件的目标场景节点的已有监控数据(即，第二监控数据)进行第二目标指标聚合，得到第二目标指标数据。其中，第二目标指标数据包括至少一组第二目标指标。

如果以子分类为单元，对于同一个业务系统、同一个子分类，对在该子分类一段时间内所有触发告警事件的目标场景节点的已有监控数据(即，第三监控数据)进行数据聚合，更具体地，对同一个子分类对应的、所有触发告警事件的目标场景节点的已有监控数据(即，第三监控数据)进行第三目标指标聚合，得到第三目标指标数据。其中，第三目标指标数据包括至少一组第三目标指标。

上述第一目标指标数据、第二目标指标数据、第三目标指标数据所包含的目标指标可以相同，也可以不同，还可以部分相同。另外，通过数据聚合需要得到哪些目标指标可以根据实际应用场景配置，本申请对此不做限制。

目标指标例如可以包括但不限于总数、成功量、失败量、耗时、成功率、失败率、消息最大延迟时间、消息堆积量等等，本申请对此不做限制。

本实施例还可以对同一个业务系统中、同一个触发告警事件的目标场景节点的已有监控数据进行数据统计，得到该目标场景节点的统计数据。以此类推，得到每个触发告警事件的目标场景节点的统计数据。每个统计数据包括对应目标场景节点的业务监测告警时刻和业务监测告警次数。

其中，业务监测告警时刻和业务监测告警次数都是基于业务系统提供的监控数据得到的，即，是业务系统监测的原始数据，非告警聚合发送系统监测得到的。

业务监测告警时刻是指业务系统监测到的发生异常时进行告警的时刻，业务监测告警次数是对告警次数进行统计得到的。

将得到的指标数据和/或统计数据作为聚合数据，根据聚合数据向相应用户发送至少一个告警，不同告警中包含的指标数据和统计数据不完全相同。

以邮件形式发送为例，邮件内容可以包括但不限于：

示例1：邮件内容包括：[应用层]告警信息列表，[应用层]告警信息列表包括：异常时间、分类分级、汇总信息(根据聚合数据和/或统计数据编写)和告警详情(根据聚合数据和/或统计数据编写)。

例如，异常时间为：2023-09-22 09:06:00

分类分级为：应用层/消息中间件/RMQ/CONSUMER/bcits-sc-hub-customerRelation_consumerGroup,[servername:na mesvr]

汇总信息包括：当前聚合收敛告警周期(600秒)内共计发生3次告警：(2023-09-2208:57:00,2023-09-22 09:00:00,2023-09-22 09:06:00)

告警详情：当前指标latency(消息堆积量)的值(5)，当前比阈值0.0高。

示例2：邮件内容包括：[业务层]告警信息列表，[业务层]告警信息列表包括：异常时间、分类分级、汇总信息(根据聚合数据和/或统计数据编写)和告警详情(根据聚合数据和/或统计数据编写)。

例如，异常时间为：2023-09-22 10:44:00

分类分级为：业务层/借信融合/多花多赚/base05_dhdz-klb|多花多赚-借记卡列表

汇总信息包括：当前聚合收敛告警周期(300秒)内共计发生1次告警：(2023-09-2210:44:00)

告警详情：当前指标pv(总数)的值(2)，当前低于前20次均值(11)的20.0％or当前比阈值1.0低

交易损失：自首次异常(2023-09-22 10:44:00)开始，交易(pv)损失为：13。

示例3：邮件内容包括：[应用层]告警信息列表，[应用层]告警信息列表包括：异常时间、分类分级、汇总信息(根据聚合数据和/或统计数据编写)和告警详情(根据聚合数据和/或统计数据编写)。

例如，异常时间为：2023-09-22 12:10:00

分类分级：应用层/消息中间件/ISC、Q_S879778_B92558_10001,[producer_ip:****,producer_name:***]

汇总信息：当前聚合收敛告警周期(600秒)内共计发生1次告警：(2023-09-2212:10:00)

告警详情：当前指标msg_delay_total(消息最大延迟时间(秒))的值(1106)，预测值[0,0]，连续2次高于前15次的均值and当前高于前3次拟合值(866)的110.0％and连续2次高于阈值300.0。

本实施例通过多种不同的聚合规则或聚合方式对同一个业务系统中触发告警事件的目标场景节点的监控数据进行数据聚合，得到指标数据和/或统计数据，并根据指标数据和/或统计数据向用户发送告警，实现了告警数据的聚合发送，解决了告警分散发布带给用户的干扰问题。

在一个实施例中，在步骤S500中根据得到的聚合数据向相应用户发送告警之前，该方法还包括：

根据获取的画图所需数据绘制指标图表；

步骤S500中根据得到的聚合数据向相应用户发送告警，包括：

将目标指标数据和统计数据作为聚合数据，根据聚合数据和指标图表生成告警信息，并向相应用户发送告警信息。

具体地，现有的监控告警系统如Zabbix系统等，告警通常是基于文本的，缺乏直观的可视化界面。基于此，本实施例提供直观可视化的指标图表供用户查看。指标图表用于从所包含的指标的角度和层面来展示对应业务系统的运行状态。

画图所需数据为两类：历史数据及预测数据。画图原则为在异常发生时刻的过往30分钟的指标数据变化。其中历史数据由告警聚合发送系统将业务方接入的场景节点的监控数据做统计，得到用于图表生成的图表指标，并将图表指标写入数据库。预测数据由离线预测系统根据告警聚合发送系统写入数据库的数据进行大数据模型运算得到的一个指定时间内点的预测值。

对于同一个业务系统，在分类维度、子分类维度、场景节点维度都可以绘制指标图表。具体根据图表指标进行指标图表绘制。指标图表中可以包含图表指标以及指标预测值之间的对比效果。

例如，指标图表用于展示：消息堆积量与消息堆积量对比值(或者预测值或阈值)之间的对比效果；成功量与成功量对比值之间的对比效果；失败量与失败量对比值之间的对比效果；耗时与耗时对比值之间的对比效果；成功率与成功率对比值之间的对比效果；失败率与失败率对比值之间的对比效果；消息最大延迟时间与消息最大延迟时间对比值之间的对比效果，等等。

绘制了明确的告警时间节点实时动态异常数据，方便使用方在第一时间查看异常时刻的数据变化，极大帮助了使用方第一时间查找、定位问题。

在一个实施例中，步骤S200中查询每组目标监控数据的分类分级信息和告警配置数据，包括：

筛选出监控数据中具有潜在告警风险的目标监控数据；

查询每个目标监控数据对应的分类分级信息和告警配置数据，并为不存在告警配置数据的目标监控数据创建默认配置；

其中，告警配置数据为已有的告警配置数据或创建的默认配置数据。

具体地，可以使用Spark SQL根据告警标识筛选或过滤出监控数据中具有潜在告警风险的目标监控数据，其中，一个目标监控数据即为一个潜在告警风险项。

告警标识为业务系统对监控数据标识的。例如，告警标识为1表示存在潜在告警风险，告警标识为0表示不需要关注。

通过将所有的潜在风险项(异常)提取出来，并按照一系列的告警匹配规则进行筛选过滤，如果满足条件则进行数据聚合，并发送告警给业务方。

告警聚合发送系统预先构建了每个业务系统的分类分级以及设置了告警配置，根据目标监控数据所属场景节点的场景节点标识，可以在对应的分类分级中查询到该目标监控数据的分类分级信息以及告警配置数据。

另外，业务方将自己的场景接入告警聚合发送系统后(通常很多)，可能不愿意花额外时间对每一个单独的场景节点进行告警配置。为了方便业务方，对于没有告警配置数据的场景节点，告警聚合发送系统会将对应的默认配置数据写入至该场景节点对应的分类分级中，在进行触发告警事件判定时采用默认配置数据对应的规则对该场景节点进行判定，后续业务方如果对默认配置不满意，可自行编辑告警配置数据来取代默认配置数据。

本实施例只对具有潜在告警风险的目标监控数据进行是否触发告警判定，对于本身不具有潜在风险的非目标监控数据则进行过滤，可以减少无用功和计算开销，提高告警判定效率。另外，对于不存在告警配置数据的场景节点可以灵活使用默认配置数据，减少了对用户的依赖，实现更自动化的告警判定和聚合告警。

在一个实施例中，该方法还包括：

根据目标用户的配置编辑指令，编辑配置编辑指令所指示的场景节点的告警配置数据。

本实施例提升了配置的灵活性，支持自顶向下细致到场景节点的告警配置，完整支撑使用方对不同类型、不同场景告警的差异化需求。

在一个实施例中，步骤S100中接入至少一个场景节点的监控数据，包括：

使用消息队列接入并获取业务系统中至少一个场景节点的监控数据。

具体地，消息队列可以是kafka消息队列、ROCKET-MQ消息队列等任意消息队列，本申请对此不做限制。

本实施例采用流式信息的处理方式，使用消息队列接入业务系统的监控数据，监控数据以消息流形式被告警聚合发送系统接收。即，监控数据为流式数据。消息队列具有广泛的适用性和兼容性，使用消息队列可以兼容各种平台和系统，获取各个业务系统的监控数据，不受系统之间数据调用的局限。

更具体地，消息流的源头为各大上游业务系统，上游业务系统按约定的消息格式通过消息队列将监控数据提供给告警聚合发送系统。只要满足格式上的要求，本实施例可以支持任何行业的软件应用以例如kafka的消息队列形式接入告警聚合发送系统。业务系统例如包括但不限于：业务场景在线告警系统、应用日志在线告警系统、中间件在线告警系统等等。

例如，单条消息格式:{"interface_name":{"busi_scene":"po16_fastPayB"},"date_time":"1695352620","detail_info":[{"indicator":"pv","indicator_name":"总数","flag":0,"error_msg":[],"predict_model":"model_1","value":1,"url":"","predict_value":[0,5]}]}

为了传输的高效性，消息内容中均为最简格式，完整的信息会在消息进入系统后，可以经由分类分级系统对该条消息进行完整的信息查询并后续加工。

参考图2，本申请还提供了一种告警聚合发送系统，其特征在于，该告警聚合发送系统包括：聚合发送子系统10和分类分级系统20；

聚合发送子系统10，用于接入至少一个场景节点的监控数据，并向分类分级系统20发送查询指令；

分类分级系统20，用于根据查询指令查询每组目标监控数据的分类分级信息和告警配置数据，并向聚合发送子系统10返回查询结果；

聚合发送子系统10，用于根据同一个目标场景节点的告警配置数据及已有监控数据，判断当前目标场景节点是否触发告警事件，其中，已有监控数据包括当前获取的目标监控数据和从当前时刻至上一次业务监测告警时刻之间的历史目标监控数据；若触发告警事件，则基于聚合周期和聚合规则，根据所有触发告警事件的目标场景节点的已有监控数据进行数据聚合；根据得到的聚合数据向相应用户发送告警。

具体地，分类分级系统20具体是一个树状结构下：支持自定义层级及任何层级下可挂载任意数量节点的一个系统。

预先构建分类分级系统20，其中，分类分级系统20包括至少一个层级，每个层级包括至少一个分类，且，上一层级的分类或子分类为其下一层级的子分类的父类；每个分类或子分类挂载有至少一个场景节点。

分类分级系统20是一套为了实现告警高效信息流转的子系统，具体的分类分级数据和告警配置数据则是由业务方自由创建并存储于数据库中。分类分级系统20为聚合发送子系统10提供了信息查询支撑，也可以用于与业务方进行交互。

另外，如果监控数据以流式数据接入，则聚合发送子系统10为消息流的消费者。

聚合发送子系统10，负责采集、清洗、过滤、判定、聚合等完整操作。

聚合发送子系统10具体可以通过接口调用方式调用分类分级系统20根据场景节点名称查询任意场景节点的监控数据的分类分级信息和告警配置数据。

在一个具体的场景中，当一组监控数据进入聚合发送子系统10后，会调用查询接口向分类分级系统20查询其所对应的分类分级信息、告警级别等等一系列信息，根据告警级别可以查找到匹配的告警配置数据。

例如:一条名为po16_fastPayB的场景节点的监控数据流入至聚合发送子系统10，经分类分级API查询，该场景节点的分类分级信息为：[业务层/网联/快捷支付/支付/对公]。该场景对应的告警级别为[1(INFO)]。

本实施例通过接入场景节点的监控数据，对目标监控数据进行告警触发判断，并根据聚合周期和聚合规则对触发告警事件的目标场景节点的监控数据进行数据聚合，根据聚合数据向用户发送告警。本实施例通过数据聚合，既保证了用户可以及时获取到对业务系统的告警，又可以减少消息冗余，降低对用户的频繁干扰；另外，构建了不同场景节点的监控数据的分类分级，对监控数据进行清晰划分，便于快速、准确查找并定位到业务系统的问题，以及管理各个业务系统各个场景节点的告警工作，可接入任意业务系统，适用范围广。特别是对于金融科技领域，各种银行系统、保险系统、金融APP层出不穷，均可以由告警聚合发送系统进行统一告警管理，高效便捷。

在一个实施例中，分类分级系统20，用于根据用户的自定义操作，创建不同层级的分类及子分类，并在分类或子分类上挂载配置相应的场景节点；

和/或，

分类分级系统20，还用于根据用户的配置编辑指令，对所指示的目标场景节点的告警配置数据进行编辑。

具体地，现有技术的监控告警系统如Prometheus系统，缺乏便捷灵活的配置能力，需要自定义开发来扩展其功能。本实施例的告警聚合发送系统可以灵活接收用户自定义和编辑操作，具有便捷灵活的配置功能，满足不同用户需求。

其中，分类分级系统20可以有人机交互界面，用户可以通过人机交互界面向分类分级系统20下发配置编辑指令。

用户通过分类分级系统20可以配置各种告警规则例如触发告警事件的判定规则、发送告警的用户的联系方式、各种阈值等等。

本实施例提升了配置的灵活性，支持自顶向下细致到场景节点的告警配置，完整支撑使用方对不同类型、不同场景告警的差异化需求。

在一个实施例中，聚合发送子系统10，具体用于：

根据同一个目标场景节点的告警配置数据，判断当前目标场景节点是否处于禁止发送告警时间段；

若当前目标场景节点不处于禁止发送告警时间段，则获取当前时刻距离上一次业务监测告警时刻的时间间隔，若时间间隔不超过间隔阈值，则判定当前目标场景节点不可触发告警事件；

若时间间隔超过间隔阈值，则判定当前目标场景节点触发告警事件；或者，若时间间隔超过间隔阈值，则根据目标场景节点的已有监控数据判断异常总次数是否超过次数阈值，若异常总次数超过次数阈值，则判定当前目标场景节点触发告警事件。

在一个实施例中，聚合发送子系统10，具体用于执行以下至少一个操作：

对同一个业务系统中、所有顶层分类对应的第一监控数据进行第一目标指标聚合，得到第一目标指标数据，其中，第一监控数据包括：同一个业务系统中、所有顶层分类、所有场景节点中触发告警事件的目标场景节点的已有监控数据，

对同一个业务系统中、同一个顶层分类对应的第二监控数据进行第二目标指标聚合，得到第二目标指标数据，其中，第二监控数据包括：同一个业务系统中、同一个顶层分类、所有场景节点中触发告警事件的目标场景节点的已有监控数据，

对同一个业务系统中、同一个子分类对应的第三监控数据进行第三目标指标聚合，得到第三目标指标数据，其中，第三监控数据包括：同一个业务系统中、同一个子分类、所有场景节点中触发告警事件的目标场景节点的已有监控数据，

分别获取同一个业务系统中、各个触发告警事件的目标场景节点的统计数据，其中，统计数据包括业务监测告警时刻和业务监测告警次数；

聚合发送子系统10，具体用于：将目标指标数据和/或统计数据作为聚合数据，根据聚合数据向相应用户发送告警，其中，目标指标数据包括第一目标指标数据、第二目标指标数据和第三目标指标数据中的至少一种。

在一个实施例中，聚合发送子系统10，还用于：根据获取的画图所需数据绘制指标图表；

聚合发送子系统10，具体用于：将目标指标数据和统计数据作为聚合数据，根据聚合数据和指标图表生成告警信息，并向相应用户发送告警信息。

在一个实施例中，聚合发送子系统10，具体用于：

筛选出监控数据中具有潜在告警风险的目标监控数据；

查询每个目标监控数据对应的分类分级信息和告警配置数据，并为不存在告警配置数据的目标监控数据创建默认配置；

其中，告警配置数据为已有的告警配置数据或创建的默认配置数据。

在一个实施例中，聚合发送子系统10，具体用于：使用消息队列接入并获取业务系统中至少一个场景节点的监控数据。

本申请为了解决传统的监控系统告警发送能力相对薄弱的问题，告警收敛聚合发送系统聚焦告警发送，提供模块化接入能力，采用流式信息的处理方式，最大化发挥整个监控系统价值。

本申请构建了告警的分类、分级体系，将告警内容进行清晰划分，更加易于查找及管理。

本申请提升了配置的灵活性，支持自顶向下细致到节点的告警配置，完整支撑使用方对不同类型、不同场景告警的差异化需求。

本申请提供了历史告警的查询，可明确回溯查询指定时间区段的历史记录，帮助使用方更加快速、准确定位、回归历史问题。

本申请聚合了同类别的告警内容，供使用方在查看告警异常时能够方便的进行横向对比，同时缩减了不必要的多条单独告警信息，避免了对使用方的打扰，提升了使用效率。

本申请绘制了明确的告警时间节点实时动态异常数据，方便使用方在第一时间查看异常时刻的数据变化，极大帮助了使用方第一时间查找、定位问题。

图4示出了一个实施例中计算机设备的内部结构图。该计算机设备具体可以是终端，也可以是服务器。如图4所示，该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，存储器包括非易失性存储介质和内存储器。该计算机设备的非易失性存储介质存储有操作系统，还可存储有计算机程序，该计算机程序被处理器执行时，可使得处理器实现上述方法实施例中的各个步骤。该内存储器中也可储存有计算机程序，该计算机程序被处理器执行时，可使得处理器执行上述方法实施例中的各个步骤。本领域技术人员可以理解，图4中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提出了一种计算机设备，包括存储器和处理器，存储器存储有计算机程序，计算机程序被处理器执行时，使得处理器执行以下步骤：

接入至少一个场景节点的监控数据；

查询每组目标监控数据的分类分级信息和告警配置数据；

根据同一个目标场景节点的告警配置数据及已有监控数据，判断当前目标场景节点是否触发告警事件，其中，已有监控数据包括当前获取的目标监控数据和从当前时刻至上一次业务监测告警时刻之间的历史目标监控数据；

若触发告警事件，则基于聚合周期和聚合规则，根据同一个业务系统中触发告警事件的目标场景节点的已有监控数据，进行数据聚合；

根据得到的聚合数据向相应用户发送告警。

在一个实施例中，提出了一种计算机可读存储介质，存储有计算机程序，计算机程序被处理器执行时，使得处理器执行以下步骤：

接入至少一个场景节点的监控数据；

查询每组目标监控数据的分类分级信息和告警配置数据；

根据同一个目标场景节点的告警配置数据及已有监控数据，判断当前目标场景节点是否触发告警事件，其中，已有监控数据包括当前获取的目标监控数据和从当前时刻至上一次业务监测告警时刻之间的历史目标监控数据；

若触发告警事件，则基于聚合周期和聚合规则，根据同一个业务系统中触发告警事件的目标场景节点的已有监控数据，进行数据聚合；

根据得到的聚合数据向相应用户发送告警。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，的程序可存储于一非易失性计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。