基于机器学习的波动监控系统

 最初建立这套系统的目的：

1. 每天要看N多业务指标，只恨一双眼睛不够用，经常有些关键业务指标没有及时发现。波动拐点已经过了几天了，才发现下降或上升了。
2. 接口波动监控全覆盖，无需设定预设阈值。现在有1500左右的接口，使用预设静态阈值的方式，维护和管理阈值的得花多少心思。在AI再崛起的时刻，咱们在监控方面也搞点稍微有点科技含量的、能提高工作效率的事情。

因此有一个最低的原则——最大限度的减少人工干预的程度，除了

采集模块——设定采集任务；

监控模块——设定监控分组；

       其它都是通过业务流和维护模块自己保证数据在各模块间正常的流转。同时 采集任务和监控任务也支持后台数据库快速配置。

 

       我们的目标不单完成了，而且还可以通过全覆盖的监控，让我们：

1. 大大小小的不稳定问题全部都暴露出来了。不在像以前一些问题，没有用户反馈，不知道，更没人处理的情况。现在监控敏感度设定的比较低，待优化后，可以逐渐提高监控敏感度。
2. 对系统有一个整体上的数据上的认知，而不是之前感官上的认知，因此有了——数据报告这个模块。

 

 

框架结构

 

模块介绍：

       数据采集：从各种数据源，批量采集监控数据。目前支持mysql、es

       数据特征学习：

数据建模：将每天已30分钟为一段，分成48端。基于每一段进行数据特征学习，产生一个知识点。每个知识点包括：样本数据的集中趋势、离散趋势数据。

举例：下面是11/12日到27日  某接口在各时段平均10分钟的访问量，如果我们针对这一个指标只设定一个静态阈值，那显然是无法体现出来这种数据随着时段变化而变化的特征的。

      

       监控决策与告警通知：

              那最新的采集的数据与知识点做离散度对比，根据以下信息，决定是否发出告警，以及告警登记：

1. 知识样本数据的离散程度
2. 新数据相对于知识样本数据的离散程度
3. 监控任务设定的敏感度
4. 知识点无效、超级稳定等极端情况。

              附件是告警通知示例

 

       维护模块：

              新发现的到数据，什么时候开始知识学习？怎么补全历史数据进行知识学习？

              识别无效的历史监控数据？怎么清理出去？

 

       告警响应模块：（暂未实现）

              当前告警是否存在已设定的响应处理程序，存在，则激发响应程序。

              举例：假设我们已经识别出来坏人假冒客服的特征，告警响应模块收到该告警后，去执行添加封停动作。

 

       数据报表：

              通过全覆盖的监控，让我们对系统有一个整体上的数据上的认知，而不是之前感官上的认知。

              例如：“接口数据波动报告” 对最近各模块接口从访问量、错误量、超时量做汇总报告。

                            通过每周的对比，可以看到系统稳定性趋势。

                            思考一下，它为什么会存在大幅波动？是否可以优化？

                            如果信息量太大，可以先从接口超时入手。

             

              业务方面每周出关键业务指标长期（3月）趋势图，以免视野缩小，在短期走势（2周）内感觉不到长期趋势的变化。