基于时序数据的微内核预警引擎架构设计
一个完整的监控生态体系包括“监、析、控”三个环节，预警平台作为偏“析”的一环，既要对监控数据做规则分析，又要为控制系统生成预警日志，起着承上启下的作用。监控平台收集的数据，是典型的随着时间变化的时间序列数据（以下简称“时序数据”），如何针对时序数据设计灵活可控的预警引擎，是预警平台的首要任务。本文根据笔者的实践体会，探讨一下基于时序数据的微内核预警引擎架构设计，希望能给感兴趣的同行带来些许共鸣。
随着移动互联网、工业互联网、物联网、边缘计算的兴起及发展，时序数据最近两年呈爆发式增长，根据DB-Engines公布的权威数据，可以发现在各种类型数据库发展趋势中，时序数据库的发展势头异常强劲。
最近两年数据库发展趋势
而在时序数据库TOP 10排名中，半开源的InfluxDB作为新一代时序数据库标杆，综合得分遥遥领先，因此在需要存储时序数据的应用场景中，InfluxDB无疑是首选。
时间序列数据库综合得分排名
特来电云平台监控系统亦基于InfluxDB存储监控数据，尽管InfluxDB生态有Kapacitor作为预警系统，但综合考虑到灵活可控、功能可扩展、与业务灵活结合等需求特点，我们最终选择了自主设计微内核的预警引擎，主要由以下三部曲组成：
一、 抓数据
任何一个数据处理系统，都源起于数据，因此预警系统首先要提供支持可扩展的数据源管理，用于从时序数据库、关系数据库、NO-SQL数据库、WebAPI等抓取数据。一般可通过数据中心、数据源类型、数据源连接地址、数据库名称、端口、用户名、密码等属性描述一个数据源实体。预警引擎启动时，需要动态加载配置好的数据源。
二、 判规则
预警引擎本质上是一个规则引擎，需要具有高度的描述性与抽象性。几乎全部的预警引擎，都是独创一套表达式规范，以期通过各种表达式组合，完成对预警规则的描述。笔者认为表达式是封闭的，有门槛的，尤其需要综合使用多个表达式进行预警描述时，很难掌握也很难理解。那对开发人员来讲，什么是最容易掌握的呢？答案是SQL、SQL、SQL。
笔者认为一个典型的基于SQL的规则引擎，具有如下的结构：
|
有了数据源，SELECT DATA FROM TABLE就很容易实现，WHERE FILTER就是本节要阐述的校验规则，THEN ACTION就是后一节要讲的动作。
每一条时序数据曲线，都是对一个Tag的描述，因此依据Tag的数量以及数据的有无，可以将校验规则进行如下分类：
如果预警引擎能提供上面校验规则的默认实现，就可以满足90%以上的场景，同时再提供可扩展机制，针对个性化场景支持扩展开发，动态加载不同校验规则插件，基本上就能涵盖所有的业务需求。
由于不同的SQL写法，返回的数据结果可能不同，需要用一个统一的内存模型来表示结果集，而DataTable无疑是一个绝佳的选择，因此实现校验规则的很多工作是在做数据转换，有了统一的数据模型后，利用DataTable的一些内置方法进行规则判断就易如反掌了。
针对无监控数据的情况进行校验规则判断是一个难点，因为监控数据的上报很容易受监控系统自身波动、网络波动等干扰，如果依赖单一校验规则，很容易产生误判，因此针对无监控数据的情况，要采用多校验规则依赖判断方式，这些依赖规则依旧是SQL，并且作为主校验规则的参数注入到规则判断中，从而可以灵活解决误判问题，提高准确率。
三、 做动作
预警触发后，需要执行的动作主要分为两类：通知、命令。
通知方式有邮件、短信、微信、钉钉等，随着系统规模的增长，当有故障发生时，很容易产生预警风暴：短时间内收到大量的预警消息，因此需要对预警规则划分重要级别、设置收敛区间、发送时间段，同时结合根因分析，保证运维人员收到有效的预警消息。
命令是指对控制系统下发运维指令，做一些常规的运维操作，比如重启进程、回收应用程序池、抓取Dump、转储日志等，及时止损，防止系统进一步恶化。
动作这块需要考虑的一个因素是通知的用户，即要求预警规则对应的接收人，既可以设置静态的默认接收人，也可以动态计算，比如根据预警实际发生时所在的机器、进程等信息计算出具体的接收人，从而做到定义一条预警规则，根据实际情况灵活发给不同接收人的效果。
四、 总结
基于时序数据的微内核预警引擎，需要提供可扩展及动态加载功能，基于SQL实现规则解析，驱动监控数据从抓取、判断到动作流畅运转。
五、特来电云计算与大数据微信公众号
1.微信公众号名称：特来电云计算与大数据
2.二维码：
