ZABBIX集成OneAlert实现高级告警压缩

前言

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

备注：OneAlert目前正在支持更多告警方式，例如：钉钉、webhook、QQ、APP等等

OneAlert集成

---

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

安装OneAlert Agent

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

• 配置->添加应用->点击ZABBX图标，如下图：

1. 创建应用 KEY

2. 选择操作系统

 

3. 安装Agent

Linux Centos 6:

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

# AppKey=90fd6c9a-b031-7afc-08c9-1df98690ec1a Plugin=zabbix 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:

 

1 2 3

# 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 使用命令

 

1 2 3

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

Linux Centos 7 使用命令

 

1 2 3

# 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便能支持配置与接收告警通知。

总结

 

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