Jetty模块本身用于暴露接口对外提供规则、事件、数据源管理。和 Flink 版本一样,我们遇到了一个问题就是如何在所有的 Akka 集群上更新告警规则。
后面我们的实现策略和 Flink 的版本一样,规则在 Cassandra 上更新完毕后,会以特定的更新消息写入 Kafka 中。这个时期,所有的告警规则配置,使用用户,告警数据源的配置,都保存在 Cassandra 中。因为 Partition Key 的创建不大合理,也给我们在做检索,分页等操作时,尤其是告警事件的筛选,带来了极大的麻烦。这也直接导致我们在 3.0 版本里面将所有的配置数据存于 MySQL,告警事件改为使用金字塔存储。
基于计算引擎,我们抽象出三大逻辑模块,告警计算和管理模块、告警策略管理模块、推送行为管理模块。
- 计算引擎,也就是前面说的 Runtime 模块那层、它只关心什么规则,基于数据算出一个 true/false 的布尔值表示是否告警,同时返回计算的指标集。
- 事件生成引擎,它基于前面的计算结果,还有指标的元数据等组合生成实际的告警事件。2.0 版本只有三种:普通、警告、严重。
- 推送行为模块,其实就是配置支持哪些通知用户的方式,在 2.0 里面只有发邮件、执行 Shell,3.0 之后支持 Web Hook 和短信。
- 策略模块,就是关联某个规则应该用那些现存的通知配置。
2.0 版本的告警系统主要是 CEP 计算引擎模块,所以在部署上,他是集成在各个业务系统上的。
2.0 的时候,告警系统只产生三类事件,普通事件、警告事件、严重事件。我们调研之后发现,其实用户在意的不是这类事件,而是这三类事件相互转换之后产生的事件。
于是我们重新定义了告警事件。
所以我们将告警引擎产生的事件分为两大类:HealthStatusEvent、HealthRuleVolatation 事件。
前者就是图上的三个圈,也就是前面的正常、警告、严重。(做鼠标指点状)应用状态从“普通”到“严重”会产生“开启严重”事件。应用状态从“警告”到“普通”会产生“关闭警告”事件,应用状态持续在“警告”或者“严重”会产生持续类事件。我们对于告警的触发配置转为这种状态转换的事件。
有了前面的设计之后,我们遇到了第一个问题,如何在现行的 Akka 应用上设计一个告警事件状态机。我们想了很多方式,后面我们发现,自己完全想岔了。
之前开发的 Engine 模块结合 Runtime 模块完全可以解决这个问题,我们只需要按照之前定义的 8 个事件转换状态定义 8条 SQL,配置三个子 RuntimeContext 即可解决这个问题。比如开启警告事件,它的 SQL 定义如上。也就是之前一个告警事件如果为空或者为NORMAL事件,当前这条事件为警告事件,则生成开启告警事件。
感谢博主,收获很多,个人觉得整个架构重点在关注数据流式处理和存储,为什么不考虑用类似influxdb等时序数据库引擎实现呢?
雨帆大佬,这篇文章写的是非常好啦。小弟还有些不懂的地方,可以求个认识么?邮箱是QQ也是微信。