稳定性报告(report)平台思考

背景

首先说一些日常工作场景：

1. 你的群里是否经常会发送一些巡检报告，比如qps峰值统计，cpu利用率，机器使用数量统计等等
2. 你的领导是否需要你每周发送一次公司业务层级的运行报告，包括上周有没有故障，上周所有业务的qps峰值是多少，周期内的一些业务变更或者运营活动等。

所以你可能会看到类似这样的一些图：

初步思考

基于上述的背景，我们常规的实现方式有以下几种：

1. 日常的巡检报告，我们可能会用一个脚本定期的获取数据，然后发送到企业微信机器人、邮箱、钉钉等
2. 周、月巡检报告运营报告这些，我们可能需要手动创建一个md文件，写上一些数据，截上一些监控图，加上一部分解读和批注，最终发到群里给大家看。

那么基于上述的实现方式，我们是否可以进一步的去考虑自动化或者说是平台化。比如是否可以设想一下：

1. 把日常的报告、通知发送集中起来管理(目前可能是一个人一个脚本，不知道跑在哪个机器的定时任务上)
2. 是否可以模板化，比如定制一些模板，然后拿着这个模板去渲染真实的数据，最终发送出来
3. 还可以增加定时任务，比如针对这个模板，我想要定期发送，这样就更简单的托管起来我们分部在各个机器上的定时脚本了

功能期望

针对上述的思考，我们团队做了一些建设，目前一期建设想要产出一个稳定性运营平台，这个平台目前的任务主要有以下几个：

1. 接管我们当前的日常报告的功能(目前的报告都是自动化脚本实现，定期发送qps数据，带宽数据，网关数据等)
2. 提供自定义模板功能，能快速定义想要的数据模板
3. 可以实现监控图的发送(目前更多的是grafana的图片)
4. 接管我们当前每周的稳定性运营报告的工作，可自动渲染数据，可自定义标注，最终发送终版报告给到用户
5. 历史数据的存储，目前监控平台会存储全量数据，这个平台只是想要存储一些特定数据或者叫做过滤后有效的数据
6. 实现定期发送的功能，可配置定时任务

平台设计

首先这个平台分成了三个大的部分：前端、后端接口、定时任务端

这里主要讲解一下非前端部分，首先功能模块分了几个大块：

仪表盘模块
模板模块
变量注册模块
报告模块
数据存储模块
定时任务模块

仪表盘模块

这一块主要是总览展示的功能模块，包括整个平台有多少模板，有多少报告等。
这一快的功能放到二期了，一起暂时没做，不过有一个初版的样子可以看看。

模板模块

模板模块和变量注册模块是相辅相成的。模板目前主要划分了几种类型：

模板类型	说明
基础模板	基础模板主要提供接入能力，比如我定义好了域名QPS统计的能力，那么你只需要提供你的域名，我就可以帮你完成统计动作
开放模板/周期模板	这类模板就相对自由，你可以自定义模板内容，变量，最终定义定时任务来定时的渲染该模板，然后选择发送等

模板定义主要的原理就是：创建一个markdown主体内容，然后写上一些变量，最终这些变量都会被真实的值所替换。所以创建模板需要你重要的能力就是：会写markdown。

创建模板大致长这样：

变量注册模块

变量注册主要是定义你在模板中设置的变量，比如这个变量的获取方式是什么样子的，获取的数据字段是哪个。
对比变量的说明，主要划分了几种：内置变量、模板变量、图片变量
针对这三种变量有一个简单的说明：

变量类型	变量说明	提供信息
内置变量	所有模板都可以使用的，可以理解为公共变量	提供获取地址
模板变量	属于模板特有的	提供获取地址
图片变量	专门下载grafana图片的	提供grafana地址

比如我举个例子：

我在模板中定义了一个变量`DATE`，那么我在变量注册的时候需要提供这些信息：
变量获取地址：https://abc.com/var/date
变量获取字段：data
等到真正渲染模板动作执行的时候，就会去请求这个地址，拿到返回数据中data字段的值来具体的替换我的`DATE`数据，来达到渲染的目标。

我在模板中定义了一个变量`QPS__TREND_IMG`，这个主要是一个图片变量，获取的数据就是一个域名在某段时间的qps趋势图，那他提供的信息就是:
grafana地址：http://grafana.c.com/****
grafana的key：这个当然你可以放到服务端配置中去，也可以自定义，随意
等到真正渲染模板动作执行的时候，就会去请求这个下载这个grafana图片，然后上传到你自己的存储，比如阿里云的oss，华为云的obs，最终提供一个图片地址然后替换这个变量，达到渲染的目标。

报告模块

对于报告模块来讲，就是我们最终要发送和呈现的产物，那么我们可以从几个维度来讲解一下：报告如何产生、报告产生的来源、报告的状态

报告如何产生

报告产生的唯一入口就是通过模板，我们可以在模板处选择对应的模板，然后创建报告，创建报告需要几个信息需要填写：

1. 模板名称(选哪个就用哪个)
2. 报告名称
3. 时间范围(所有数据都依赖于时间范围，有了时间范围我们才能产生数据，然后渲染报告)

报告产生的来源

关于报告的来源，平台的规划主要有两个，第一个是手动生成的报告,第二个是定时任务产生的报告

报告的状态

针对报告，我们需要有几种状态：未渲染、渲染中、待标注、已发布(NotRendered、RenderedIng、ToBeLabeled、Published)

数据存储模块

对于数据存储模块，我们前面定义的是历史数据的存储，目前监控平台会存储全量数据，这个平台只是想要存储一些特定数据或者叫做过滤后有效的数据。

举个例子，当前我们平台存储的数据有哪些：

1.qps峰值数据(我们监控存的是5s一个点的qps数据，不过该平台会每小时取一次时间段内的峰值qps作为存储)
2.snat峰值数据(对于nat网关，我们也是采用类似的方式，存储过去一小时的峰值数据)
3.带宽峰值数据
4.弹性机器峰值数据(目前k8s集群的机器是弹性的，所以会存储每一小时的峰值数据)

当我们有了这些数据，我们能做的就比较多了，比如：

1. 我们基础的监控数据在获取大范围时间内的数据，都是对峰值等数据做了聚合，所以会低于真实峰值，有了每小时的峰值数据，能准确的描绘业务峰值。
2. 当我们需要周报、月报、年报的时候，我们都可以对这些峰值数据做一些处理和分析
3. 从一定角度上讲，我们可以分析峰值的走势，来辅助业务做一些判断，比如业务的峰值时间越来越晚，是不是说明用户睡的越来越晚呢？

定时任务模块

定时任务，毋庸置疑，他承担着控制我们报告的发送时间和频率。比如我在平台可以针对模板创建一个定时任务：什么时间、哪个模板、发送到哪里。

目前我们使用的定时任务是对接开源的分布式定时任务框架xxl-job，二开了一些定时任务接口给到平台使用。

那么需要了解的主要可能有几点：

1.定时任务的发送地方：目前支持发送到企业微信应用、企业微信机器人
2.定时任务的发送频率：主要取决你定时任务表达式的书写

最后说一句

对于这个平台来说，其实整体功能不难，不过个人感觉能接管不少分散的服务和脚本，也使得趋于统一化。
不过弊端也有，说实话当前的功能还比较单一，后续拓展有，但是还没有想好，所以对于单一的功能平台化，就是有点太卷了。