作者:李森
部门:技术中台/PaaS平台
随着公司规模的增长,业务越来越复杂,运维的场景越来越多,对运维自动化的要求也越来越高。事物的发展不是孤立的,运维也不例外,运维的发展过程大致可以分为:手动运维->自动运维-> DevOps ->智能运维。我们希望在已有的 OPS 运维平台的基础上再向前迈进一步,构建基于事件驱动的自动化运维平台。
发展图:
本文将介绍基于事件驱动的自动化运维平台(Whale)的系统设计、实践以及未来的展望。
系统运行分为两大阶段:编排期和运行时
编排期:
运行时:
系统流程:
事件中心作为整个平台事件的入口,主要的职责是:
使用预定义的事件类型,可以标准化事件,更好从全局视角了解事件接入情况。ES的使用让事件中心的存储和索引更加强大,便于用户可能需要的问题排查以及事件重现。
规则匹配模块是事件驱动的大脑,是事件到任务的决策单元。整体分为3个模块:规则特征匹配、任务参数组装、任务触发限流。
规则特征匹配是通过对事件本身内容进行匹配,对用户使用DSL配置的匹配规则予以放行,反之会被丢弃。目前特征支持常用关系如:等于、不等于、大于、小于、正则匹配等。用户配置的特征组成一个特征管道,事件需要经过特征管道来判断匹配结果。比如:我们想根据某个事件的某个指标的大小来决定是否触发任务,这个阈值的设置,可以增加一个特征规则;或者我们的任务只针对生产环境的资源,可以增加一个环境特征规则。
为了让事件内容与任务解耦,所以抽象了参数组装层。让事件和任务都具有流动性,同时一个事件也可以触发多个任务。任务参数组装需要用户使用 DSL 来配置一个任务参数模板,系统会根据事件内容以及参数模板渲染出执行这个任务所需要的全部参数。
例如事件消息为:
{
"event_type": "opsst2_stone",
"detail": "{"msg": ["test1", "test2", "test3"], "code": "1"}"
}
则转发参数可以为:
{
"messages": "{{.detail.msg}}}", #指定引用事件detail字段的msg字段
"default1": "ok", #指定固定的默认值
"default2": [1,2,3]
}
事件具有重复性,但是任务理论上不应该被重复创建。为了避免这种情况,对下游的任务执行引擎进行保护,此模块实现了一个基于缓存的令牌桶限流器。每个规则都可以配置一个限流策略:
限流标识 key 同样需要 DSL 来创建模板,根据事件内容渲染出真正的 key 。如:
{{.detail.app}}_{{.detail.host}}
执行引擎作是一个“真正干活”的模块。根据已有的一些运维系统的痛点,我们需要的是一个有状态的、可编程的、支持 Workflow 、带容错、可扩展的分布式任务编排框架。目前有很多成熟的开源任务编排框架,对比了一些开源软件后我们选择了 StackStorm 。基于 StackStorm 提供任务编排 DSL ,用户可以通过编写 Yaml 轻松对原子任务进行组合,像搭积木一样完成数据自己的任务流。
在此基础上,为了更好管理多个集群(根据业务的优先级隔离出单独集群),满足跨机房高可用、用户无感知升级等需求,我们实现了一个多集群的Proxy做流量隔离控制。
任务管理模块可以对任务执行状态进行管理
为了应对原子任务日常迭代发布,我们抽象出共享 Pack 的概念(若干个 Pack 组合体,Pack的体现形式类似一个 Git Repo),发布过程中会把这若干个 Pack 构建成一个 Docker 镜像,替换老的 Worker 节点的镜像。
我们对底层的 StackStorm 集群进行了屏蔽,用户不需要感知我们下层集群的情况。有了这一层的存在,后续可以很方便对集群的滚动升级、维护、甚至替换其他开源方案。
不仅如此,这里我们还可以在用户无感知的情况下对不同的业务路由不同的集群,实现业务层面的集群级别的隔离。
利用事件驱动的自动化运维平台,与监控同学合作实现两个小场景的告警自动处理:
处理流程:
集成企业微信: