基于事件驱动的自动化运维平台

原创有赞技术有赞coder

点击关注“有赞coder”

获取更多技术干货哦～

作者：李森

部门：技术中台/PaaS平台

一、前言

随着公司规模的增长，业务越来越复杂，运维的场景越来越多，对运维自动化的要求也越来越高。事物的发展不是孤立的，运维也不例外，运维的发展过程大致可以分为：手动运维->自动运维-> DevOps ->智能运维。我们希望在已有的 OPS 运维平台的基础上再向前迈进一步，构建基于事件驱动的自动化运维平台。

发展图：

本文将介绍基于事件驱动的自动化运维平台（Whale）的系统设计、实践以及未来的展望。

二、整体设计

系统运行分为两大阶段：编排期和运行时

编排期：

平台研发负责将各种平台功能封装成原子任务接入到系统中
用户根据业务场景，组合已有的原子任务（或者自定义开发），构建对应的处理流程
用户将需要监听的事件接入事件中心
用户在规则匹配模块配置事件与任务关联（基于规则匹配关联）
用户根据事件内容组装任务参数

运行时：

当对应的运维对象发生状态变更时，产生相应的事件进入事件中心
规则引擎接收到事件之后，根据事件类型和内容，生成规则匹配结果
接着触发对应的 Workflow 去处理
原子操作最终会触发运维对象的状态变更，然后再进行对应的操作，直到达到目标状态
向管理员反馈任务处理结果

系统流程：

2.1 事件中心

事件中心作为整个平台事件的入口，主要的职责是：

承担对外事件的标准化接口，校验事件合法性
提供用户配置事件的能力
ES存储，支持用户对所有接收事件的检索

使用预定义的事件类型，可以标准化事件，更好从全局视角了解事件接入情况。ES的使用让事件中心的存储和索引更加强大，便于用户可能需要的问题排查以及事件重现。

2.2 规则匹配

规则匹配模块是事件驱动的大脑，是事件到任务的决策单元。整体分为3个模块：规则特征匹配、任务参数组装、任务触发限流。

2.2.1 规则特征匹配

规则特征匹配是通过对事件本身内容进行匹配，对用户使用DSL配置的匹配规则予以放行，反之会被丢弃。目前特征支持常用关系如：等于、不等于、大于、小于、正则匹配等。用户配置的特征组成一个特征管道，事件需要经过特征管道来判断匹配结果。比如：我们想根据某个事件的某个指标的大小来决定是否触发任务，这个阈值的设置，可以增加一个特征规则；或者我们的任务只针对生产环境的资源，可以增加一个环境特征规则。

2.2.2 参数组装

为了让事件内容与任务解耦，所以抽象了参数组装层。让事件和任务都具有流动性，同时一个事件也可以触发多个任务。任务参数组装需要用户使用 DSL 来配置一个任务参数模板，系统会根据事件内容以及参数模板渲染出执行这个任务所需要的全部参数。

例如事件消息为：
{
  "event_type": "opsst2_stone",
  "detail": "{"msg": ["test1", "test2", "test3"], "code": "1"}"
}
则转发参数可以为：
{
  "messages": "{{.detail.msg}}}",  #指定引用事件detail字段的msg字段
  "default1": "ok",  #指定固定的默认值
  "default2": [1,2,3]
}

2.2.3 任务限流

事件具有重复性，但是任务理论上不应该被重复创建。为了避免这种情况，对下游的任务执行引擎进行保护，此模块实现了一个基于缓存的令牌桶限流器。每个规则都可以配置一个限流策略：

指定限流标识 key
单位时间可触发任务数量

限流标识 key 同样需要 DSL 来创建模板，根据事件内容渲染出真正的 key 。如：

{{.detail.app}}_{{.detail.host}}

2.3 执行引擎

执行引擎作是一个“真正干活”的模块。根据已有的一些运维系统的痛点，我们需要的是一个有状态的、可编程的、支持 Workflow 、带容错、可扩展的分布式任务编排框架。目前有很多成熟的开源任务编排框架，对比了一些开源软件后我们选择了 StackStorm 。基于 StackStorm 提供任务编排 DSL ，用户可以通过编写 Yaml 轻松对原子任务进行组合，像搭积木一样完成数据自己的任务流。