引擎架构

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

  • 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