专栏首页老安的博客一个优雅的报警处理系统范例

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

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

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

报警遇到的痛点

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

背景现状

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

在公有云场景下,报警需要按照物理位置或者应用类型发给不同的运维同学、运营同学和管理层。在私有云场景下,报警也需要推送给相应的客户。当前,我们主要采用微信为主,短信为辅的报警方式。

使用微信的优缺点

使用微信的优点

   基本免费;

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

   微信客户端和服务器端交互方便。

使用微信的缺点

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

为此特意增加了对微信服务器接口的监控,发现接口有问题之后会发短信报警;

   客户端需要保持联网,没有送达报告:

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

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

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

实施方案

架构概览

报警分类

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

ELK日志报警:用户在微信端可以查看

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

报警确认:当用户点击确认按钮之后,对应的人会收到确认信息。

报警处理结果反馈

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

报警收敛

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

报警升级

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

微信 vs 短信 两个平台

所有微信接口做了加密处理,防止非授权用户访问和关注公众号。短信平台主要用来发送灾难级别的报警、微信API接口的报警,系统本身可用度的报警。

总结     系统使用的成果

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

    研发历程

本系统开发历时半年左右,基本上随着云极星创的发展而发展壮大起来,初期的想法是因为各家短信发送平台随着国家打击电信诈骗的政策影响,变得越来越不好用,所以诞生了使用普及率非常高的微信来替代短信的想法。

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

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

    未来发展

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

(备注:文中截图来自于预发布环境下的运维测试)

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

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

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 批量更新zabbix中的主机名

    用户1057912
  • 怎么样做好日志类的报警监控

       2、对应技术栈涉及比较广的系统,,一个问题会引发不同主机上面不同系统同时产生日志。举例:openstack 的nova在保存快照时出错,会引起nova-a...

    用户1057912
  • 用python api管理vcenter

    用户1057912
  • Fundebug支持配置实时报警

    为了防止报警过于频繁,在项目设置的“报警规则”页面,我们对报警间隔做了限制,默认一个项目 30 分钟内最多报警一次。当然,时间可以调节,最少能调整到 15 分钟...

    Fundebug
  • 一个可扩展的报警系统Quick-Alarm

    一个可扩展的报警系统Quick-Alarm 背景 日常的系统中,报警是不可缺少的一环,目前报警方式很多,最常见的有直接打日志,微信报警,短信报警,邮件报警等;而...

    一灰灰blog
  • 报警系统QuickAlarm之报警规则解析

    前面两篇分别说了报警执行器和报警规则的定义及用户扩展加载,接下来就是比较核心的一块了,如何将报警规则和报警执行器关联起来,即当发生报警时,应该call哪一个报警...

    一灰灰blog
  • 平安/智慧城市一键报警反恐综合解决方案

    近年来,国际恐怖活动猖獗,中国境内恐怖活动亦进入高发期。东突恐怖势力在国内不断制造暴恐事件。从地域上来看,暴恐事件由之前大多发生在新疆地区,有向内地...

    MEEYI美一
  • 马蜂窝大交通业务监控报警系统架构设计与实现

    部门的业务线越来越多,任何一个线上运行的应用,都可能因为各种各样的原因出现问题:比如业务层面,订单量比上周减少了,流量突然下降了;技术层面的问题,系统出现 ER...

    Spark学习技巧
  • 磁盘空间报警自愈的设计小结

    前段时间集中处理了一批磁盘空间报警类问题,让人有些恼火,因为报警了,不处理还不行,处理的话一方面是碎片的时间,处理步骤八九不离十,二来是非工作时间处理,我非常不...

    jeanron100
  • 报警系统QuickAlarm之频率统计及接口封装

    前面将报警规则的制定加载解析,以及报警执行器的定义加载和扩展进行了讲解,基本上核心的内容已经完结,接下来剩下内容就比较简单了 报警频率的统计 报警线程池 对外封...

    一灰灰blog

扫码关注云+社区

领取腾讯云代金券