OneAlert实现高级告警压缩,成功规避告警风暴


#1

前言


去年发表了一篇《Zabbix集成OneAlert来实现短信、邮件、微信、电话告警》的技术文章。它帮助我们非常的轻松的支持了各种告警通知方式,但是存在一个严重的问题,我们经常接到各种相类似或者相关联告警,短信太多,难免会出现漏看情况,告警通知几乎变成垃圾短信。为此OneAlert提供了一个适配方案:【高级告警压缩】
备注:OneAlert目前正在支持更多告警方式,例如:钉钉、webhook、QQ、APP等等

OneAlert集成


首先需要安装OneAlert Agent,有两种安装方式:通用安装型、一键安装型;OneAlert工程师告知目前只有一键安装型才支持告警压缩,并且压缩比率较高,最高能够达到98%(^_^不是所有压缩都能到这么高)

安装OneAlert Agent

先登录OneAlert后台地址:http://c.110monitor.com/ucid/login.jsp

>1. 创建应用 KEY



>2. 选择操作系统

>3. 安装Agent

Linux Centos 6:

# AppKey=90fd6c9a-b031-7afc-08c9-1df98690ec1a Plugin=<a href="http://www.ttlsa.com/monitor/zabbix/" title="zabbix"target="_blank">zabbix</a> sh -c "$(curl -L https://raw.githubusercontent.com/oneapm/onealert-agent-installer/master/onealert-zabbix-install-centos6.sh)"
………..
initialize onealert done.
start add zabbix plugin.
Host [http://localhost/zabbix]: http://10.0.0.2 /zabbix //这里输入你的zabbix地址
Zabbix Admin User: admin // zabbix用户
Zabbix Admin Password: // 密码
Select user type for new Zabbix user - [1] Super Admin, [2] Admin.
The user accesses monitoring data to enable this OneAlert integration [1]: 2 //选用户类型,我选择2
onealert-config.zabbix: INFO: Logging in to http://10.0.0.2/zabbix
onealert-config.zabbix: INFO: Creating OneAlert usergroup
onealert-config.zabbix: INFO: OneAlert usergroup created: OneAlert Service with id 19
onealert-config.zabbix: INFO: Creating OneAlert user
onealert-config.zabbix: INFO: OneAlert user created: onealert with id 9. Please note that this user is of type ADMIN.
onealert-config: INFO: Writing configuration.
onealert-config: INFO: All done.
add zabbix plugin is done.
start run onealert agent...
onealert start/running, process 2165

Linux Centos 7:

# AppKey=90fd6c9a-b031-7afc-08c9-1df98690ec1a Plugin=zabbix sh -c "$(curl -L https://raw.githubusercontent.com/oneapm/onealert-agent-installer/master/onealert-zabbix-install-centos7.sh)"
…….省略….
…….请参考Centos7…….

备注:以上Appkey请替换成你的

以上步骤做了如下工作:

  • 安装OneAlert Agent,定期调用Zabbix API获取事件,并回传到OneAlert平台. So,你不需要配置Action
  • 创建OneAlert用户:OneAlert
  • 创建OneAlert组:OneAlert
  • 启动onealert

>4. 启停OneAlert Agent

Linux Centos 6 使用命令

# initctl start onealert
# initctl stop onealert
# initctl restart onealert

Linux Centos 7 使用命令

# service onealert start
# service onealert stop
# service onealert restart

配置分派策略

Agent安装完毕之后,OneAlert平台可以接收到Zabbix所有触发器事件. 接下来配置分派策略,告知OneAlert应该将什么级别、类型的告警分配给谁!

  • 配置->分派策略->新增策略

    如上图配置,只要是来自zabbix-onealert应用的通知都会分配给用户“OPS”

配置通知策略

OneAlert已经能成功将一个告警分配给一个用户,但是如何通知到用户呢?规则是什么?[通知策略]!

  • 配置à通知策略à添加à选择时间、告警级别、告警类型、通知时间、方式à保存
    我的通知策略:
  • 告警发生时、确认、解决立即通过APP或者微信通知
  • 延迟10分钟发短信通知
  • 延迟30分钟直接彪电话

重要告警电话比短信靠谱的多!有时候晚上也接到电话,为避免接到一些不必要的电话,请大家严格设定。

告警压缩


告警合并

什么是告警合并?

告警合并是将相同、类似、可能相关的事件能够自动合并关联起来,整个过程是自动化的。思路是:

  • 时间序列合并,如同一个告警信息,每个几分钟发生一次,就会合并,直到告警恢复/关闭掉。
  • 机器学习合并,包括实时计算和离线计算,算法方面参考了相似度、决策树、分类等算法。以相似度来说:首先采集告警的多维度信息,包括时间、主机、服务、分组hostgroups、应用applications、标签tags等基本维度信息,计算不同告警之间相似度,如果达到阈值,如告警A和告警B有70%相似就关联起来。目前没有一种算法是最合适的,以相似度为例因为根据业务不同,各维度的权重,阈值灵敏度有些差异。例如某些应用的机器名规范化很高,如portal_mysql_master,portal_mysql_slave1,portal_mysql_slave2之类的,机器名权重可以高一些。机器学习领域是未来的重要发展方向,目前OneAlert还在摸索中。

告警合并演示

关闭主机:dd-pre-01的Nginx,触发了2个告警。OneAlert后台如下:一个父告警里面包含两个子告警。


继续关闭主机:dd-test-01的Nginx,触发2个告警。OneAlert后台如下:当前主机的两个告警与dd-pre-01告警合并到同一个父告警ID:5183816

假想一下,如果没有启用告警合并功能,那么下图将变成成百上千条告警,运维人员/相关RD很可能会漏看甚至干脆不看告警。

通知合并

通知合并是什么?

告警合并后的相同父告警的事件,会进行合并通知。例如服务器宕机引发大量进程告警,通知模块并不会同时发送,只会发送一部分,剩余的会合并通知。

如下图,前几个告警会发送,后续的会合并起来一起发送一个汇总通知。


通知合并演示

制造多次告警之后,收到OneAlert通知合并短信,内容蛮简洁的

虽然目前官方暂未公布合并通知的具体规则,但是我们可以参考以下例子:

某个集群有100台nginx,配置了nginx进程的监控项,如果此时100台nginx全部异常退出。那么首先会发送5(或者其他数值)条具体的告警通知,然后接下来的95台机器的告警会合并成一条短信发送给用户,通知类似上图(已合并95条通知)。

OneAlert APP


OneAlert提供了一个简便、轻量级的APP给我们使用,目前支持:任务处理(待处理、处理中、已解决)、分派策略、通知策略、成员信息查看、集成论坛交流。一个APP便能支持配置与接收告警通知。

有兴趣使用APP的同学扫描以下二维码下载

总结


告警压缩包含告警合并、通知合并,告警合并将相似、关联、相同的告警合并到一个父告警,比起以往的海量告警,告警合并极大的提高了告警可读性、准确性。通知合并减少了不必要的通知,能让我们最快的定位有意义告警。But,通知合并内容较少,是否适合使用,还需要看大家各自的业务环境。

nagios结合OneAlert实现报警

本文转自运维生存时间:ZABBIX集成OneAlert实现高级告警压缩


#2

赞~(≧▽≦)/~