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

故障自愈作为运维领域的热门话题之一，各个公司都会投入大量的人力来开发不同的组件，如何正确、有序的调用不同组件以及避免相同功能组件的开发，是一件亟待解决的问题。StackStrom 是一个基于事件流并自动执行的系统框架，基于此，可以让外部系统产生的事件，有序的、可编排的集合到一起，作为一个完整的事件流去执行，从而解决一些高频次的运维难题。

1 背景介绍

目标

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

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

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

愿景

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

整体架构图：

2 StackStorm 介绍

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 的更多示例这里不做详细解释，有兴趣的可以参考官方文档。

3 应用实例

workflow 结构

workflow 流程

st2 web 平台记录的结果示例

4 总结

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

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

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

本文转载自公众号 360 云计算（ID：hulktalk）。

原文链接：

https://mp.weixin.qq.com/s/mbO4vxImvgE1qNqGFcx0QA