业务框架之个性化监控方案

一.前言

       每个系统都需要监控,而每个监控需求都有不同,我这边的的方案是结合了当前部门及公司的特性去思考设计的,至于为什么说是方案,而不是一个组件,因为个性化监控,要解决的问题其实不是一个组件就可以完全解决的,它需要多个组件合力完成.但为了但一篇文章足够简单,同时也能给读者带来一定的思考及学习价值,所以这里焦点在方案上,但作者其实已经实现的本篇中的想法,会持续的补充文档,涉及到具体的点,都会在本文中提供地址链接.

二.面临的问题

业务问题:

      当然所有的方案肯定是要基于实际需求,如果没有实际需求,就是玩技术,而不是解决具体问题,见下:

本人在项目中有碰到以下问题点

1.上游系统会不定时的产生异常数据,需要马上或一定时间内发现

2.当前系统使用的部署架构也算比较复杂,查看问题,需要去多个监控系统分析与监控

3.单个项目的业务产生的有效数据量保持在6T左右(随着公司业务变化,还会持续增长),业务数据分析统计种类多,量大,特别涉及到实时数据查看对人工的耗时及系统的压力都会比较大

4.使用项目的用户群,普通用户,产品,开发,运维,都希望有不同角度看待或分析问题

现有技术复用问题:

    技术的复用非常重要,不能每次都是去颠覆,利用现有的技术积累就可以控制成本,所以要理解现有的技术资源是必须掌握的

1.公司级(涉及到公司的组件不会在这里说出名字,只会标出方向)

       数据库监控系统,线上物理监控系统,云监控系统,面向非业务的异常,响应等等的监控系统,这些系统都是在业务层之外的,它们是解决是所有系统都需要用到的,可以帮助我们更好的分析和定位问题,我们可以用它们来做内聚好的监控大盘

2.部门级(这些技术都会为个性化监控带来助力的)

数据层的分库分表的封装    数据层的封装可以解决对于海量数据的查找(API的简单及解决没有索引也可以查询的方案是有效的帮助指标的获取)

自定义查询对象,   有了面对对象查询,可以在规则引擎中尽可能的控制入参及安全(暴露SQL是比较危险的,同时将规则从非结构化转成结构化,需要一个查询对象做壳)

流式框架计算的阻塞组件( 可以在异步中的同步中安全并充分利用分布式硬件环境,快速统计所需要的资源)

三.根据现有的问题及资源去设计

做技术设计,一定要在某一个粗的维度看问题,我称之为产品的角度来看,可以抽象成 

1.指标:  配置成具体的元素(数据库查询的值,HTTP或外部API所获取的值)

2.触发规则:   只想在海量的数据中关注需要的东西,但需要能够可配置

3.个性化显示:   不同角色都有自己不同想要看的

4.报警:      快速响应,邮件,短信,又或监控大盘上数据字体颜色变换等等

有了以上的粗维度,我们在整体上就有了一些全局感,然后再以技术的角度,可以抽象成

1.存储(不管是什么数据,一切都要存放在指定地方及标准化它,才是可以解析的)

选型 键值型 NOSQL(redis)  理由 :本公司最成熟的NOSQL,同时它的数据类型比较丰富

存放具体指标 -> hash (redis 数据类型)

存放具体指标对应的历史记录,内容存KEY-> list(redis 数据类型)

2.规则(借助灵活的规则配置,非结构化的规则引擎是具备了所有规则的天然抽象组件,可以直接拿到使用)

选型 规则引擎drools  理由:免费的同时又与JAVA结合的好的,除了drools,好像没有啥了

自定义的数据库查询(DB的查询配置 这里还涉及到对查询对象的封装,及透明的解决如何查询大表)

自定义的HTTP或其它远程API的定制(基于HTTP或基于特定远程协议的request请求配置)

触发规则

报警规则

3.模板(前端展现及邮件或短信等等报警,都需要可定制,模板引擎就是一个现成的抽象组件,也能直接拿来使用)

选型 模板引擎freemarker  理由:结合现有前端已经使用了的spring boot 并且支持freemaker,同时有官方中文文档

可以定制业务监控大盘(此类,用户,产品,领导都比较关心)

可以定制每日监控或每小时监控(此类 运维和开发比较关心)

可以定制报警的内容(此类 大部分角色都比较关心)

短信模板

邮件模板

四.根据3个技术维度结合的去解决监控问题方法

那么基于以上的三大维度去实现,就可以结合现有的技术并持续迭代解决现有的问题

方式1:

A同学配置了一个某维度失败的数量,通过标准化好的存放在redis上,然后规则引擎将数据解析并返回特定标准对象,供一个专门处理每日统计的任务通过模板引擎去定制显示达到每日监控数据维度

方式2:

B同学写了一个数据质量程序,根据标准化好的API必须会存放在redis上面,然后数据质量展现程序会从redis取出来,通过规则引擎的计算(配置有合规性,一致性的),不满足的再通过模板引擎去展现问题数据

方式3:

C同学通过配置现有的监控系统的一个 HTTP请求,通过规则引擎抽象的对象获取需要的前置数据,从而得到请求的返回数据,再通过标准化好的API存放在redis上,在页面上的模板引擎对应的页面,形成个性化监控的大盘页

前面前言也说了,本人已经实现,所以附上一些的实际效果图供读者更好的理解

规则定义分为规则组与具体规则:

具体规则定义

模板定义

统计邮件

五.相关地址(持续更新)

此文档偏向于方案类,但作者出于出品一定得接地气基础上,会在此贴出以上所有技术点的博客地址

将SQL查询封装成对象查询

规则引擎drools封装
模板引擎freemarker封装:已实现,待补充文档

监控维度存储的标准化API封装:已实现,待补充文档

vipshop_ebs/朱杰

2018-02-14