一种基于元数据驱动的业务监控告警系统及其方法与流程

1.本发明涉及一种监控告警系统，具体涉及一种基于元数据驱动的业务监控告警系统及其方法。


背景技术：

2.市场上有很多成熟的产品能够统一简单的对程序运行环境的各种资源信息(cpu，内存，网络等)进行监控告警，但在常规的业务系统中，通常需要对业务系统的具体业务场景进行监控告警，这些场景包括但不限于：
3.1、周期定时任务：希望能够知道任务的执行状况，包括状态等信息。
4.2、工作流：希望能够在可能发生超时完成的情况下进行预警。
5.3、一次性事件：希望能够根据严重程度，数量，状态等进行告警。
6.4、数据表：希望能够根据数据量等进行告警，提前扩容。
7.5、客户数量：希望能够监控每日新增客户量，并告警。
8.要从平台的角度统一地解决上述场景，面临着以下困难：
9.1、不同的监控对象，模型结构不同。
10.2、不同的监控对象产生的日志，结构不同。
11.3、不同的业务场景，所需要的监控类型不同。
12.而在上述各种场景下，通常会分别实现监控告警，偏向于定制开发和静态模型。这往往会带来较多的维护和扩展成本。


技术实现要素：

13.针对现有技术存在的问题，本发明提供一种基于元数据驱动的业务监控告警系统及其方法，元数据驱动制定了对接流程和规范，按照此协议对接开发比较规范，可以在监控数据来之前做部分校验，具有极强的规范性。
14.本发明的技术方案是：一种基于元数据驱动的业务监控告警系统，包括客户端和监控告警中心服务端；
15.所述客户端配备有客户端软件开发包，所述客户端软件开发包内封装有加载和上报监控元数据的应用接口、上报监控对象的应用接口以及上报监控日志埋点的应用接口；客户端能够向监控告警中心服务端上报监控元数据，监控对象和监控日志这3种数据对象；
16.所述监控告警中心服务端分三层：
17.第一层为http接口层和用户接口层；所述http接口层用于接收客户端上报数据，所述用户接口层用于展示监控数据报表、告警规则管理、告警推送渠道和告警记录报表；
18.第二层为功能模块层；用于监控元数据的管理、监控对象的管理、监控日志的提取和存储、告警规则的存储和匹配、告警的触发计算和存储以及监控数据的查询统计；
19.第三层为存储层；采用适合在线事务处理的关系型数据库mysql和文档型存储库elasticsearch以及key-value的缓存数据库redis。
20.进一步的，所述客户端向监控告警中心服务端上报数据的上报方式为http或者kafka方式。
21.本发明还提供一种基于元数据驱动的业务监控告警方法，客户端在开发阶段按照元数据模型的规则定制自身接入监控告警中心服务端的内容，并且在监控对象和监控日志产生的地方埋点调用相关接口上报；
22.具体步骤如下：
23.步骤一、客户端上报监控元数据和监控对象到监控告警中心服务端；
24.步骤二、监控告警中心服务端消费监控元数据和监控对象；
25.步骤三、监控告警中心服务端存储监控元数据和监控对象到mysql；
26.步骤四、监控告警管理人员通过用户界面配置告警规则；
27.步骤五、告警规则请求发到监控告警中心服务端；
28.步骤六、监控告警中心服务端保存告警规则；
29.步骤七、客户端产生监控日志后上报到监控告警中心服务端；
30.步骤八、监控告警中心服务端消费监控日志；
31.步骤九、监控告警中心服务端产生监控数据并存储到elasticsearch；
32.步骤十、监控告警中心服务端产生告警记录并通过通知渠道发出。
33.进一步的，所述元数据模型包括以下部分：基本信息，指标元数据，告警元数据和报表元数据；
34.(1)基本信息：元数据的基本信息，用于标识和描述该元数据；包括监控来源、监控主键、监控名称和元数据版本；
35.所述元数据版本用于控制元数据的更新，只接受更新版本元数据；
36.(2)指标元数据：定义了如何从监控日志中提取数据和如何存储数据；包括指标字段、指标名称、是否主键、字段类型、字段路径和枚举元数据；
37.(3)告警元数据：定义了告警需要的数据和如何触发告警；包括告警类型和告警消息模板；
38.所述告警消息模板定义用于告警消息的模板，支持内置变量和自定义变量；
39.(4)报表元数据：定义了监控报表展示的内容；包括报表名称、聚合策略、聚合指标字段、序列指标字段、聚合维度、事件时间指标字段和报表详情展示字段。
40.进一步的，所述告警类型为状态告警元数据时：
41.指标字段：指标元数据中指标变量，用于指定提取状态并告警的字段；
42.枚举元数据：指标变量的枚举列表。
43.进一步的，所述告警类型为超时告警元数据时：
44.窗口类型：事件型-一个任务从前一个状态到后一个状态时间过长或者说在规定时间内没有达到另一个状态；时间型-一个任务在某个时间检查点没有达到某个状态；
45.状态指标字段：所述指标元数据中指标变量，用于指定提取状态的字段；
46.事件时间指标字段：表示该事件发生时间的类型为时间戳的时间指标字段，用于窗口类型为时间型时有多个状态事件的情况下，取最后一个事件状态；
47.事件型日期指标字段：格式为日期所属的业务日期指标字段，用于窗口类型为时间型时定位一个批次所属的业务日期；
48.事件型的开始状态枚举：开始状态值枚举，用于窗口类型为事件型时开始状态，符合则触发超时告警的检查；
49.事件型的结束状态枚举：结束状态值枚举，用于窗口类型为事件型时结束状态，不符合则触发告警；
50.事件型的超时时间：用于窗口类型为事件型时时间检查点的计算；
51.时间型的结束状态枚举：结束状态值枚举，用于窗口类型为时间型时结束状态，不符合则触发告警，时间的结束状态枚举＝所有状态枚举＝事件的开始状态枚举+事件的结束状态枚举；
52.时间型的检查周期：用于窗口类型为时间型时时间检查周期；
53.检查次数：检查次数，大于1则多次检查；
54.持续告警的间隔：多次检查时的间隔，大于1时有效。
55.进一步的，所述告警类型为数量告警元数据时：
56.状态指标字段：根据状态进行过滤，结束之后才有数量统计或者结束之后的数量统计才准确；
57.状态指标枚举：有效的状态值枚举；
58.事件时间指标字段：表示该事件发生时间的类型为时间戳的时间指标字段，用于窗口类型为时间型时有多个状态事件的情况下，取最后一个事件状态；
59.数据量指标定义：采用表达式的形式，用于定义一个复合指标和阈值的上下界。
60.本发明的有益效果是：
61.1、规范性强：元数据驱动制定了对接流程和规范，按照此协议对接开发比较规范，可以在监控数据来之前做部分校验。
62.2、通用性强：基于jsonpath表达式和scriptengine支持的表达式动态解析和执行，可以应对各种数据结构和场景。
63.3、扩展性强：该模型轮廓已定，可以根据需要扩展新型的告警元数据，可快速支持一种新告警。
64.4、配置简单：监控告警偏技术性，太多技术性配置会导致用户界面使用者难以上手，而元数据驱动分离了大部分“开发/程序员才懂的配置”，使得“运维配置简单化”。
附图说明
65.图1为基于元数据驱动的业务监控告警系统的应用框架；
66.图2为基于元数据驱动的业务监控告警系统的交互架构。
具体实施方式
67.下面结合附图对本发明做进一步的说明。
68.本系统主要提出一种元数据驱动方案和相关的一套抽象模型，并集成现有存储技术组件，脚本引擎等，用于应对不同场景、不同结构监控对象和不同结构监控日志。
69.特有名词
70.java：一种编程语言。
71.js/javascript：一种脚本语言。
72.http：超文本传输协议。
73.mysql：一种免费的跨平台的关系型数据库系统。
74.kafka：一种消息队列。
75.redis：一种基于内存的键值对缓存数据库。
76.elasticsearch：一种文档型的数据存储系统。
77.json：一种数据表示协议，一种数据结构。
78.jsonpath：一种通过路径表达式对json结构数据进行读写的接口。
79.scriptengine：用于执行脚本或者脚本表达式的脚本引擎，比如java语言中有提供nashornscriptengine(一种js脚本引擎)。
80.如图1所示为基于元数据驱动的业务监控告警系统的应用框架，整体上从左往右以上报方式为界分为3部分：左边为客户端，右边为监控告警中心服务端。
81.1、上报方式为http(超文本传输协议)和kafka(一种消息队列)等方式。
82.2、客户端向监控告警中心服务端上报监控元数据，监控对象(主体)和监控日志这3种数据对象。
83.3、监控告警中心服务端从上到下分为3层：
84.3-1)第一层为http接口层和用户接口层，http接口层接收上报数据。用户接口层用于展示监控数据报表，告警规则管理和告警推送渠道，告警记录报表。
85.3-2)第二层为功能模块层。主要是：监控元数据的管理，监控对象的管理，监控日志的提取和存储，告警规则的存储和匹配，告警的触发计算和存储，监控数据的查询统计。
86.3-3)第三层为存储层。采用适合在线事务处理的关系型数据库mysql和文档型存储库elasticsearch，以及key-value(键值对)的缓存数据库redis。
87.如图2所示为基于元数据驱动的业务监控告警系统的交互架构，开发阶段：客户端在开发阶段需要按照元数据模型的规则定制自身接入监控告警中心服务端的内容，并且在监控对象和监控日志产生的地方埋点调用相关接口上报。
88.1、客户端上报监控元数据和监控对象到服务端。
89.2、监控服务端消费监控元数据和监控对象。
90.3、监控服务端存储监控元数据和监控对象到mysql。
91.4、监控告警管理人员通过用户界面配置告警规则。
92.5、告警规则请求发到服务端。
93.6、服务端保存告警规则。
94.7、客户端产生监控日志(复杂结构的json格式的数据)后上报到服务端。
95.8、服务端消费监控日志(复杂结构的json格式的数据)。
96.9、服务端产生监控数据(经过提取处理后的结构数据)并存储到elasticsearch。
97.10、服务端产生告警记录并通过通知渠道(企业微信，钉钉，短信等)发出。
98.元数据模型
99.整个元数据代表一类监控的接入，包括以下部分：基本信息，指标元数据，告警元数据，报表元数据等。
100.(1)基本信息：元数据的基本信息，主要是用于标识和描述该元数据。
101.监控来源：通常是一个系统或者子系统名称。
102.监控主键：通常代表一个场景，代表一类监控对象和监控数据。
103.监控名称：监控主键对应的用于展示的名称。
104.元数据版本：用于控制元数据的更新，只接受更新版本元数据，防止新版本被旧版本覆盖。
105.(2)指标元数据：主要定义了如何从监控日志中提取数据和如何存储数据。该提取数据作为一个后续可用的指标。
106.指标字段：在该元数据中唯一的指标变量。
107.指标名称：指标字段对应的用于展示的名称。
108.是否主键：是否用作整个数据的主键(多个变量联合主键)。
109.字段类型：支持的数据类型，包括短字符串(建议128字节以内，不强制),长字符串(通常在128字节以上，不强制),数值整型,数值浮点型,日期型(格式”年-月-日”),日期时间型(格式”年-月-日时:分:秒”),时间戳型(毫秒级)。
110.字段路径：该指标在监控日志中的取数路径，需要遵循jsonpath路径表达式。
111.枚举元数据：该指标值的枚举(值和描述)列表，针对可枚举的指标。
112.(3)告警元数据：定义了告警需要的数据和如何触发告警。
113.该模型是一个抽象模型，可以随意扩展，根据告警类型可以分为多种具体模型，比如状态告警元数据，超时告警元数据，数量告警元数据。
114.告警类型：状态，超时，数量等，可扩展。
115.告警消息模板：定义用于告警消息的模板，支持内置变量和自定义变量(指标元数据中的指标字段)，比如“监控来源【${监控来源}】监控主键【${监控主键}】监控对象【${监控对象主键}】【${监控对象名称}】触发告警【${告警名称}】状态【${状态}】”。
116.3-1)状态告警元数据
117.指标字段：上述指标元数据中指标变量，用于指定提取状态并告警的字段。
118.枚举元数据：该指标变量的枚举(值和描述)列表，指标元数据中对应枚举值列表，但这里的枚举值可能少于前者，这里的枚举值标识可以用于状态告警的状态，比如，通常成功的状态不用来告警。
119.3-2)超时告警元数据
120.窗口类型：事件型-一个任务从前一个状态到后一个状态时间过长或者说在规定时间内没有达到另一个状态，时间型-一个任务在某个时间检查点没有达到某个状态。
121.状态指标字段：上述指标元数据中指标变量，用于指定提取状态的字段。
122.事件时间指标字段：表示该事件发生时间的类型为时间戳的时间指标字段，用于窗口类型为时间型时有多个状态事件的情况下，取最后一个事件状态。
123.事件型日期指标字段：格式为日期所属的业务日期指标字段，用于窗口类型为时间型时定位一个批次所属的业务日期。
124.事件型的开始状态枚举：开始状态值枚举，用于窗口类型为事件型时开始状态(符合则触发超时告警的检查)。
125.事件型的结束状态枚举：结束状态值枚举，用于窗口类型为事件型时结束状态(不符合则触发告警)。
126.事件型的超时时间：用于窗口类型为事件型时时间检查点的计算。
127.时间型的结束状态枚举：结束状态值枚举，用于窗口类型为时间型时结束状态(不符合则触发告警)，一般情况下，基于时间的检查状态较多，是全部枚举值，时间的结束状态枚举＝所有状态枚举＝事件的开始状态枚举+事件的结束状态枚举。
128.时间型的检查周期，用于窗口类型为时间型时时间检查周期。
129.检查次数：检查次数，大于1则多次检查。
130.持续告警的间隔：多次检查时的间隔，大于1时有效。
131.3-3)数量告警元数据
132.状态指标字段：一般根据状态进行过滤，通常结束之后才有数量统计或者结束之后的数量统计才准确。
133.状态指标枚举：有效的状态值枚举，一般是结束状态。
134.事件时间指标字段：表示该事件发生时间的类型为时间戳的时间指标字段，用于窗口类型为时间型时有多个状态事件的情况下，取最后一个事件状态。
135.数据量指标定义：采用表达式的形式，用于定义一个复合指标，和阈值的上下界。比如:成功率——“本次成功数量/全部数量”，成功率增长量——“本次成功数量/全部数量-上次成功数量/全部数量”。
136.(4)报表元数据：主要定义了监控报表展示的内容。
137.报表名称：比如状态统计报表，数量统计报表。
138.聚合策略：状态统计报表一般为计数，数量统计报表一般为累加。
139.聚合指标字段：字段直接聚合(比如累加)等操作的字段。
140.序列指标字段：根据字段值进行分桶聚合(比如分组计数)的字段。
141.聚合维度：用于横(x)轴，比如某个日期字段，所属的业务日期指标字段。
142.事件时间指标字段：上述时间戳类型的事件发生时间字段，用于多条数据去重策略。
143.报表详情展示字段：定义了报表的详细数据列表需要展示的字段，字段名称，是否可排序，是否可筛选，是否可链接和链接模板参数等。
144.从应用架构和交互架构上，可以看出，监控中心需要实现以下功能模块：
145.1、协议和规范：按照上述元数据模型定义一套元数据模型结构，再按照上述流程制定一套对接规范，客户端按此规范对接。
146.2、客户端软件开发包：提供方便客户端接入的客户端软件开发包，软件包应该封装(1)相关加载和上报监控元数据的应用接口，(2)上报监控对象的应用接口，(3)上报监控日志埋点的应用接口。
147.3、存储支撑：能够支持结构化数据和动态结构数据的存储，参考官方文档安装mysql和elasticsearch，redis等存储组件。并在服务端相关场景使用这些存储。
148.4、解析和计算：
149.(1)采用jsonpath从监控日志中提取监控数据；
150.(2)采用脚本引擎scriptengine执行表达式；
151.(3)采用“${变量名}”的格式填充告警消息模板，生成告警消息。
152.5、定时计算：在服务端中实现延迟队列或者定时调度触发超时告警的检查。
153.6、用户界面：实现基于监控元数据的监控统计报表和告警规则配置的用户界面
等。
154.以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。