一个优雅的报警处理系统范例

一个优雅的报警处理系统范例

做运维的同学都知道，运维一定离不开Zabbix、Nagios之类的监控软件。目前，类似的软件在监控和数据采集方面已经做到了极致，但是在报警处理上并没有很完美的解决方案，比如，经常出现高质量报警湮没在海量报警之中等情况。

本文不探讨监控系统的配置优化，只探讨监控系统按照它的逻辑发出报警之后我们该做点什么。

报警遇到的痛点

报警风暴，高质量报警湮没在海量报警之中；出现报警后没人认领，需要在在工作的IM群中沟通；运维人员进行运维操作必定会引起某些报警，会给不知道真相的同学带来困惑；海量报警恢复之后，运维人员很难在第一时间知道还剩下哪些报警没有恢复；MySQL出现了慢查询报警，DBA还需要登录数据库去查看；有些报警优先级不高，明明可以白天处理的，却在晚上第一时间发出来；同一个报警会反复报出来。

背景现状

云极星创作为综合性云服务提供者，既要做公有云的监控，也要负责私有云的监控。我们的研发团队已经建立了比较完善的OpenStack监控体系，并且使用了多种监控工具；因为云极星创的运维团队和客户分布在全国各地，所以该监控体系的物理位置也是分散。

基本免费；

图文并茂、字节数限制较为宽裕；

可用度依赖腾讯的服务器：

客户端需要保持联网，没有送达报告：

因此系统提供汇总表功能（详见后文）。

优秀报警处理系统的三要素

在合适的时间发给合适的人；尽可能的提供更多的信息，使得接警人员在不开电脑情况下第一时间能大概知道哪里出了问题；减少围绕报警的人员沟通成本。

实施方案

架构概览

报警分类

普通报警：根据排班表发送给值班的运维同学，低级别的报警会延时发给对应的应用开发。

收到报警：确认、反馈和汇总

报警处理结果反馈

汇总表：提供批量确认功能

报警收敛

基于关键字、主机名、Tag的复合报警收敛

报警升级

如果报警在一定时间没被确认也没有自动回复，会有一个报警升级动作

总结      系统使用的成果

云极星创之前使用的报警方案是邮件加短信的方式，在报警触发之后，运维交流群会有大量围绕报警的沟通，并且经常发生报警风暴，将短信发送平台堵塞，在本系统投入使用之后，基本上所有的沟通都在系统内进行。随着丰富的报警附加信息，减少了二线运维工程师在处理故障时候开机登录系统的次数。

研发历程

第一个版本就是原封不动的推送Zabbix报警信息，随着公有云规模的不断扩大，报警不断增多，另外私有云客户也在不断的增加，需要接受报警的人员也越来越分散，围绕报警的沟通成本越来越高。

因此本系统的功能点都是围绕着我们运维同学在处理报警时候遇到的痛点进行开发而成。经过半年的发展，在我们内部已经将运维报警做成了运营的报警。

未来发展

报警系统和工单系统以及CMDB做关联；快速实现故障根因定位；告警排行分析报表；

（备注：文中截图来自于预发布环境下的运维测试）

重点在最后，代码已经托管到github

https://github.com/superbigsea/zabbix-wechat

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。