告警引擎设计

引擎架构

    从需求的角度来看告警主要解决数据采集、数据解析、告警计算、数据存储。

• Kafka队列负责指标传输，指标已经存储为解析好的指标，把它定义为整个告警引擎的生产者
• 消费者有两个
• 一部分直接存储到OpenTSDB
• 另一部分进入告警引擎进行实时消费
  因此可以看出，告警类型可以分为两种：历史警告、活动警告。一种用于对历史指标的校验，另外一种偏向实时。
• 告警引擎是一个分布式的消费系统，其中分布式和HA是设计的重点。
• 每一个worker负责具体的规则检查，触发报警操作(Operator)，并将告警信息传递给外部API

分布式

• 扩展性
  由于前端生产者大量产生数据，有可能导致报警系统生产者过剩问题，消费引擎必须是可扩展的分布式系统
• 一致性
  由于分布式运行，导致worker在获取历史参考值时未能计算其它worker中的数据，导致告警临界值产生异常，因此必须要保持一个分布式锁来进行临界值一致性保障
  • 分布式锁
    用于解决对同一个topic（指标下）的并发一致问题
• 原子性
  保障对历史参考值的获取/更新是一个原子性操作，避免引起并发读取的不一致性
• 高可用
  系统必须保证worker部分宕机的情况下仍然处于工作状态，通过多个worker分布在不同的服务器下可以解决该问题
• 缓存
  由于告警基于滑动窗口进行计算，对历史数据的频繁查找会引起大量的系统开销，必须使用缓存
• 缓存策略
  如何进行秒级别的告警，基于滑动窗口的历史参考值该如何存储

Controller

• 任务
• 读取规则
• 获取参考值
• 获取消费数据
• 根据操作符进行对比，从缓存中获取并更新数据
• 触发告警操作
• 心跳监测
• 监测Controller是否正常运行，并提供心跳检查接口

接下来我们看一下工作流程：

• Controller收到一条数据
• Controller根据规则创建相应Worker
• Controller加载告警规则，如果没有，则向规则引擎发起请求，规则引擎负责规则的读取、更新、发布和通知
• Controller根据则向参考值引擎发起校验（读取并更新）请求，参考值引擎负责从存储读取、缓存
• Controller向操作引擎发送告警信息，操作引擎执行相应的操作

其中主要组件包括：

• Controller：负责校验的主体部分，主控制（Controller）
• Rule Engine：负责新建规则、读取规则、更新规则、发布规则和规则变更通知。规则引擎自身负责缓存策略。
• Ref Engine：参照值引擎负责解决参照值的读取（从TSDB中），缓存策略，一致性保障，分布式锁和参照值更新问题
• Operator Engine: 负责接收操作命令，执行相应操作
• Worker：负责按照规则进行规则检查

一个Controller中运行多个Worker

核心设计

• Ref Engine缓存策略
  非常复杂，需要根据具体缓存的结构以及应用场景进行设计
• Ref Engine原子锁
  有两种方案：
• 分布式锁组件（例如zookeeper）
• （分布式）数据库锁，例如redis
• 监控规则设计
  支持的形式相关，例如：时间窗口支持、历史参照值、滑动时间依赖等等
• 监控算法设计
  根据规则进行判断
• Controller状态监控
  假设可以进行心跳消息传递，正常处理后反馈结果

Another option Reference - https://www.ibm.com/developerworks/community/blogs/c914709e-8097-4537-92ef-8982fc416138/entry/大数据监控告警系统的实现?lang=es
Nagios