基于StackStorm的ChatOPS方案-监控报警的自愈

奇技指南

故障自愈作为运维领域的热门话题之一，各个公司都会投入大量的人力来开发不同的组件，如何正确、有序的调用不同组件以及避免相同功能组件的开发，是一件亟待解决的问题。

本文将介绍由360运维团队基于StackStorm实现的监控报警自愈方案。

本文来自公众号“360云计算”

 背景介绍 

01

目标   

基于报警事件，进行收敛和自愈处理。

• 收敛：合并报警，减少报警数量。

• 自愈：根据预先设定好的规则库进行根因分析，命中后对报警进行自处理。

愿景    

打造企业级云服务的医疗中心、自愈中心。

整体架构图：

  StackStorm介绍 

02

StackStorm是一个基于事件流的自动执行开源项目。它可以基于现有的流程、平台工作流、API、和其他一切可执行的应用环境。让这些外部系统产生的事件，有序的、可编排的集合到一起，作为一个完整的事件流去执行，从而解决一些高频次的场景。

这些执行流程中的每个动作称为一个action(原子)，不同项目中的action可以共享。

官方描述支持的场景：

• 故障排查：捕获Nagoios、zabbix等监控系统报警，然后组合排查action。

• 自动执行：比如自动解决OpenStack compute node的硬件故障，自动编排和发送邮件等。

• CI/CD：结合jenkins、aws等，进行持续部署、持续集成。

官方提供的StackStorm架构图：

StackStorm组件介绍   

• Sensors: 监听和接收外部系统的事件，当一个从外部系统过来的事件出现并被接受, trigger被触发执行；

• Trigger: 是外部事件的具体表现，简单理解为就是事件触发器，衔接sensor和rule；

• Rule: 映射着所有trigger到action的规则(或者到workflow的对应关系)，记录着criteria匹配的规则，映射trigger实例到action的input，简单理解就是规则匹配配置记录；

• Action: 是st2的具体执行动作和步骤，可以使用脚本、调用API或者其他任何自定义的action。如ssh、API call、OpenStack、Docker、salt、puppe、jenkins等的调用；

• Workflow: 多个action的集合，这些action被有序的、按照预先定义好的规则先后执行；

• Pack: st2的内容单元集合，简单理解为一个项目就是一个pack；

官方开放的pack"应用商店"截图：

StackStorm流程说明   

sensor通过pull\push 方式接受外部系统的(事件流)数据，通过trigger触发器将数据注射到st2体内，并通过rule模块接收，同时rule模块记录着基于事件的匹配规则，当数据进来的时候根据匹配规则进行匹配，如果命中的话执行action的集合workflow，并按照workflow预先定义好的流程去执行。

pack的结构   

workflow的结构   

Sensor：yaml配置文件+Py脚本文件组成

yaml配置文件示例：

py脚本文件示例：

Rule示例：

Workflow示例图：

关于StackStorm的更多示例这里不做详细解释，有兴趣的可以参考官方文档。

  应用实例 

03

workflow结构   

workflow流程   

st2 web平台记录的结果示例   

总 结

04

目前我们基于这套流程已经完成了团队内70~80%的通用运维场景，大部分日常报警都已经满足了可自愈的状态，此服务大大节省了运维人员的精力、提高了工作效率，并最大限度的降低了服务故障的时间。

通常每个Server端的服务都有自己的问题排查流程和技巧，结合这些流程、丰富运维场景（troubleshooting流程、止损动作），并最终结合到我们的StackStorm自愈平台上，一个无需人肉干预、可自愈的云服务打造完成。

未来：结合业务拓扑图、调用链关系去完善和丰富平台，同时基于监控、日志数据等结合AI算法做到故障预警、预知，可以先于故障提前发现问题。最大限度的减少业务中断带来的损失。

“最新活动”

面对复杂的业务逻辑和海量用户的并发访问，如何构建高性能、稳定的后端服务系统，是很多技术从业人员都需要解决的一个问题。

本期活动我们邀请多位一线技术专家从大数据计算、微服务架构、实时监控等方面探讨高性能Web服务端实现之路。

识别二维码或点击阅读原文立即报名

界世的你当不

只做你的肩膀

无

 360官方技术公众号 

技术干货|一手资讯|精彩活动

空·

点击“阅读原文”立即报名