一种告警通知管理系统及告警通知管理方法与流程

1.本技术涉及网络管理技术领域，尤其涉及一种告警通知管理系统及告警通知管理方法。


背景技术：

2.随着信息化水平的提升和信息化建设的推进，大型运营系统的综合稳定性越来越被关注。为了保证给用户提供有效的服务，要求运营系统能及时掌握系统中的系统模块、终端、关键设备的运行状态。因此应运而生各种监控系统。
3.这些监控系统按照各自的逻辑和规则，对系统运行状态进行评估。当某个环节出现问题时，向系统维护人员发送告警通知，以使系统维护人员能够及时得知故障来源和故障原因，以便维护人员能够采取有效的措施及时消除故障。
4.目前大部分的告警通知产品都是和其底层的告警系统紧密结合的，通常都是适配当前告警系统的，不能够兼容不同告警系统的通知信息，并且目前的大部分告警通知产品不能够兼顾通用性和业务独特性。


技术实现要素：

5.本技术提供了一种告警通知管理系统及告警通知管理方法，用于解决目前的目前大部分的告警通知产品都是和其底层的告警系统紧密结合的，通常都是适配当前告警系统的，不能够兼容不同告警系统的通知信息，并且目前的大部分告警通知产品不能够兼顾通用性和业务独特性的问题。
6.第一方面，本技术实施例提供一种告警通知管理系统，包括：
7.告警通知接入节点，用于从外部系统接入告警通知，其中，接入的所述告警通知至少存在两种格式的告警通知；
8.规则节点，用于从所述告警通知接入节点获取接入的所述告警通知，以及按照预设规则将接入的所述告警通知转换为预设格式的告警通知，其中，所述预设规则为从规则引擎调用的规则；
9.配置节点，用于配置告警发送信息，其中，所述告警发送信息至少包括告警接收人；
10.内容组装节点，用于组装转换格式后的所述告警通知和所述告警发送信息，得到组装通知；
11.告警通知上报节点，用于将所述组装通知上报至所述告警接收。
12.第二方面，本技术实施例提供一种告警通知管理方法，包括：
13.从外部系统接入告警通知，其中，接入的所述告警通知至少存在两种格式的告警通知；
14.按照预设规则将接入的所述告警通知转换为预设格式的告警通知，其中，所述预设规则为从规则引擎调用的规则；
15.配置告警发送信息，其中，所述告警发送信息至少包括告警接收人；
16.组装转换格式后的所述告警通知和所述告警发送信息，得到组装通知；
17.将所述组装通知上报至所述告警接收人。
18.本技术提供一种告警通知管理系统及告警通知管理方法，通过告警通知接入节点，从外部系统接入告警通知，其中，接入的告警通知至少存在两种格式。规则节点从告警通知接入节点获取接入的告警通知，以及按照预设规则将接入的告警通知转换为预设格式的告警通知，其中预设规则为从规则引擎调用的。配置节点配置告警发送信息，告警发送信息至少包括告警接收人。内容组装节点将转换格式后的告警通知和告警发送信息进行组装，得到组装通知。最后告警通知上报节点将组装通知上报至告警接收人。本技术提供的告警通知管理系统及告警通知管理方法，将通知管理过程抽象为流水线，将整个过程划分为若干关键节点，并依据依赖关系对各个节点进行组装，不仅能够兼容不同告警系统的通知信息，还能够同时兼顾通用性和业务独特性。
附图说明
19.为了更清楚地说明本技术的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
20.图1示例性示出了根据一些实施例的一种告警通知管理系统示意图；
21.图2示例性示出了根据一些实施例的又一种告警通知管理系统示意图；
22.图3示例性示出了根据一些实施例的通知管理平台示意图；
23.图4示例性示出了根据一些实施例的告警通知管理方法示意图。
具体实施方式
24.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有付出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。
25.实施例1：
26.参见图1，图1为本技术实施例提供的一种告警通知管理系统示意图。图1中，告警通知管理系统至少包括：告警通知接入节点11、规则节点12、配置节点13、内容组装节点14以及告警通知上报节点15。本技术实施例中的告警通知管理系统还可以包括其他节点或者模块，对此本技术不作限制。
27.告警通知接入节点11，用于从外部系统接入告警通知，其中，接入的所述告警通知至少存在两种格式的告警通知。本技术的系统还可以是设置在通知管理平台上，告警通知接入节点11则是平台提供的通知接入接口，在通知接入接口处设置有通知定义模型。该通知定义模型对接入节点要求的数据格式进行定义，凡是符合通知定义模型的数据都可以作为告警通知接入。也就是说，任何通知信息都可以在遵循平台数据模型结构的基础上接入进来，不仅限于告警通知。
28.另外平台内置了现有告警接入接口和转换器，例如prometheus、falcon，snmptrap
重要事件、libvirt重要事件、vmware事件和警报、syslog重要日志、性能告警、设备和应用的通断告警以及其他产品生成的告警(包括云数据库、云防火墙等生成的告警)。本系统对各个告警源提供统一的告警转发接口，各告警源调用该告警转发接口接入告警通知。
29.规则节点12，用于从所述告警通知接入节点11获取接入的所述告警通知，以及按照预设规则将接入的所述告警通知转换为预设格式的告警通知，其中，所述预设规则为从规则引擎调用的规则。例如上述列出的从各个告警源接入的告警通知，会存在至少两种格式的告警通知，为了统筹不同系统，不同种类的告警通知，统筹通知方式，首先将这些不同格式的告警通知按照预设规则转换为预设格式的告警通知，以便于后续的组装处理。
30.需要说明的是，预设格式为事先设置的告警通知格式，具体的格式本技术不作限制。
31.本技术实施例中的预设规则为从规则引擎调用的规则，运营人员可以通过规则引擎实时修改预设规则，以适用不同的使用场景，从而实现兼容不同告警系统的告警通知的同时，允许插入自定义逻辑，最终实现兼顾通用性和业务独特性的目的。
32.在一些实施例中，规则节点12接收到告警通知，将接入的告警通知转换为预设格式的告警通知，并换发给告警来源消息队列。转发失败的告警通知由规则节点12暂存，入待发送事件表。
33.在一些实施例中，规则节点12接收到告警通知之后，首先需要判断该告警通知是否有效，确定告警通知生效时候，按照预设规则将告警通知转换为预设格式的告警通知。如果确定告警通知失效时，则忽略该告警通知。
34.判断告警通知是否生效具体为根据预设规则和告警通知的具体信息进行判断。具体地，本发明实施例中的告警通知的具体信息可包含以下七部分内容：告警节点名称(alarmnodename)、告警信息标题(alarmtitle)、告警等级(alarmlevel)、告警标识(alarmid)、告警发生时间(alarmoccurtime)、告警原因描述(alarmdescription)、告警修复建议(alarmrestoredevice)。告警通知可以以标签的形式携带上述告警信息。其中，告警等级分为五个等级：警告告警(waring)、次要告警(minor)、重要告警(major)、严重告警(critical)、致命告警(fatal)。示例的，预设规则可以是如果当前告警通知属于警告告警，则当前告警通知为无效告警，则不需要按照预设规则将告警通知转换为预设格式的告警通知，可以直接忽略当前告警通知。预设规则还可以规定次要告警(minor)、重要告警(major)、严重告警(critical)、致命告警(fatal)为生效告警通知，如果告警通知属于这些类型的告警通知，则需要按照预设规则将告警通知转换为预设格式的告警通知。
35.在一些实施例中，可以设置告警通知的有效时间段，即如果告警通知在预设时间段为重复的告警通知，则忽略该告警通知。告警通知均携带有告警发生时间信息，规则节点12在接收到告警通知后，判断历史接收的告警通知是否与当前告警通知为重复的告警通知。如果历史接收的告警通知与当前告警通知为重复的告警通知为重复的告警通知，则忽略当前告警通知。如果历史接收的告警通知与当前告警通知不为重复的告警通知，则需要按照预设规则将当前告警通知转换为预设格式的告警通知。
36.预设时间段为事先设置的时间。例如，预设时间段为20s，即如果在20s内收到了重复的告警通知，则可以忽略当前重复的告警通知。如果收到的重复告警通知间隔时间超过了20s，不论当前告警通知与历史告警通知是否为重复的告警通知，都不忽略当前告警通
知。这样可以控制告警通知的发送频率，延时发送告警通知，避免告警通知雪崩现象出现。
37.本技术还可以设置告警通知缓存器，规则节点接收到告警通知之后，都将告警通知保存在告警通知缓存器中。在继续接收告警通知时，可以在告警通知缓存器中查找是否保存过重复的告警通知。如果保存过重复的告警通知，则忽略当前告警通知。需要说明的是，重复的告警通知具体可以是类别重复的告警通知，或者来源相同的告警通知，本技术对此不作限制。
38.在一些实施例中，还可以根据告警标签将在预设时间段相似的告警通知聚类为一组告警通知。需要说明的是，相似告警通知，可以是告警等级相同的告警通知，也可以是相同实际业务的告警通知，本技术对此不作限制。
39.预设规则可以是压制规则，压制规则数据定义如下：
40.filter(过滤属性)，用于配置哪些告警通知生效的规则。group(分组标签配置)，用于标识按照哪些标签分组，即相似告警通知按照标签聚类成一组告警通知。allowsendtime(告警通知允许时间)，用于规定告警通知允许的起止时间。sendinterval(通知间隔)，用于标识每间隔该时间长度发送一次告警通知，如果存在多条告警通知，则按照数组定义时间间隔发送告警通知，直至最有一次作为固定时间间隔。expand(扩展属性)，用于扩展告警通知属性，如果不配置，则根据规则条件，返回true或false来决定整个流水线走向。
41.配置节点13，用于配置告警发送信息，其中，所述告警发送信息至少包括告警接收人。配置告警发送信息则利用通知规则。通知规则的数据格式定义如下：type(通知类型)，用于设置告警通知的通知类型，通知类型可以为邮件、短信等；receivers(告警接收人)，可以通过设置接收人名称来指定告警接收人；title(告警通知标题)；content(通知内容)。需要说明的是，配置节点配置告警发送信息的依据可以来源于告警通知携带的信息，因此规则节点在获取接入的告警通知，可以将告警通知发送至配置节点。例如可以根据告警通知的类型发送给相应的告警接收人，由相应的告警接收人对告警通知进行处理。依据也可以由运营人员设置，例如可以在某时间段设置固定的告警接收人。
42.内容组装节点14，用于组装转换格式后的所述告警通知和所述告警发送信息，得到组装通知。
43.告警通知上报节点15，用于将所述组装通知上报至所述告警接收人。
44.以下阐述节点数据结构(无特殊说明，节点数据结构均采用jason格式说明)：
45.name(节点名称)，节点在流水线中的唯一标识；business(业务类型)，节点的按照业务类型可以分为receive(接入节点)、rule(规则节点)、send(发送节点)、content(内容组装节点)等；type(节点类型)，节点类型可以分为webhook(活动节点)和local(固定节点)。本技术中，所有节点可以设置为多个，均可以串行或者并行配置多步，这样可以提升告警通知的处理效率。规则节点和发送节点为固定节点，该属性为必填项，如果存在多条规则，多条规则之间的关系为且关系。
46.在一些实施例中，所述告警通知上报节点包括主上报节点和从上报节点；所述主上报节点，用于正常工作时将所述组装通知上报至所述告警接收人；所述从上报节点，用于在所述主上报节点故障时，将所述组装通知上报至所述告警接收人。这样可以避免主上报节点故障时，告警上报失败的情况发生。
47.在一些实施例中，为了提高告警信息上报的效率，本发明实施例对告警上报节点进行分组。具体地，可根据业务类型将告警信息的类型相同的告警上报节点设置在同一个分组内，也可将物理链路距离不大于设定阈值的告警上报节点设置在同一个分组内。其中，一个分组包含一个主告警上报节点、从告警上报节点和至少一个告警上报节点。如果根据业务类型将告警信息的类型相同的告警上报节点设置在同一个分组内，则可根据实际的业务需求获取所关注业务的告警信息，例如，可从语音业务类型的分组中提取出语音告警信息。
48.在一些实施例中，组装转换格式后的所述告警通知和所述告警发送信息，具体为：从模板引擎调用组装模板，以及根据所述组装模板组装转换格式后的所述告警通知和所述告警发送信息。
49.在一些实施例中，本技术的告警通知管理系统还可以包括数据管理上下文引擎，数据管理上下文引擎存储有告警信息，运营人员可以通过数据管理上下文引擎查看历史告警通知和告警通知统计分析报表。
50.需要说明的是，本技术的所有外部接口均采用http(hypertext transfer protocol，超文本传输协议)协议，基于restful接口执行，所有参数均采用json格式，以requestbody(用于接收前端传递给后端的json字符串中的数据)形式传入，采用post(用于将数据发送到服务器来创建/更新资源)方法。平台在处理外部接口时，如果发生超时、异常，均按照失败处理，即直接结束。入参格式：alertinfo(告警详细信息)，为json对象；expanddata(全局扩展数据)，为json对象。返回要求：nextstep(下一步节点)，end(结束)；appenddata(追加到全局数据容器的内容)。全局数据为一个map容器，用于做全局数据交换。
51.本实施例提供一种告警通知管理系统，通过告警通知接入节点，从外部系统接入告警通知，其中，接入的告警通知至少存在两种格式。规则节点从告警通知接入节点获取接入的告警通知，以及按照预设规则将接入的告警通知转换为预设格式的告警通知，其中预设规则为从规则引擎调用的。配置节点配置告警发送信息，告警发送信息至少包括告警接收人。内容组装节点将转换格式后的告警通知和告警发送信息进行组装，得到组装通知。最后告警通知上报节点将组装通知上报至告警接收人。本技术提供的告警通知管理系统及告警通知管理方法，将通知管理过程抽象为流水线，将整个过程划分为若干关键节点，并依据依赖关系对各个节点进行组装，不仅能够兼容不同告警系统的通知信息，还能够同时兼顾通用性和业务独特性。
52.实施例2：
53.参见图2，图2为本技术实施例提供的又一种告警通知管理系统示意图。实施例2与实施例1属于同一发明构思的告警通知管理系统，因此实施例2的实施可以参见实施例1的实施，重复之处不再赘述。实施例2与实施例1的不同之处在于，内容组装节点可以调用模版引擎的模版，对通知进行组装，这样可以进一步实现逻辑层面的自定义。
54.实施例3：
55.参见图3，图3为本技术实施例提供的一种告警通知管理平台示意图。实施例3可以基于实施例1的告警通知管理系统构建，也可以基于实施例2的告警通知管理系统构建。下面以基于实施例2的告警通知管理系统构建的告警通知管理平台，对该平台进行阐述。本实
施例的告警通知管理平台通过管理界面对告警管理系统进行管理。
56.通过管理界面，运营人员可以对系统进行问题追踪、分析报表、手工抑制、运维备案等操作。例如，运营人员可以通过管理界面更改规则引擎中的规则，从而使得规则节点采用的规则为动态规则。运营人员还可以通过管理界面更改模板引擎中的模板，从而使得可以根据实际使用情况更改模板引擎中的组装模板。最后每一节点产生的相关数据可以存储至数据管理上下文引擎中，以供运营人员对整个系统进行追踪。
57.本技术还提供一种告警通知管理方法，如图4的告警通知管理方法的流程示意图，该方法包括以下步骤：
58.步骤s101，从外部系统接入告警通知，其中，接入的所述告警通知至少存在两种格式的告警通知；
59.步骤s102，按照预设规则将接入的所述告警通知转换为预设格式的告警通知，其中，所述预设规则为从规则引擎调用的规则；
60.步骤s103，配置告警发送信息，其中，所述告警发送信息至少包括告警接收人；
61.步骤s104，组装转换格式后的所述告警通知和所述告警发送信息，得到组装通知；
62.步骤s105，将所述组装通知上报至所述告警接收人。
63.在一些实施例中，组装转换格式后的所述告警通知和所述告警发送信息，具体为：
64.从模板引擎调用组装模板，以及根据所述组装模板组装转换格式后的所述告警通知和所述告警发送信息。
65.在一些实施例中，按照预设规则将接入的所述告警通知转换为预设格式的告警通知，具体为：在所述告警通知生效时，按照所述预设规则将所述告警通知转换为预设格式的告警通知。
66.本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
67.尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。
68.尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。