构建报警平台为减轻zabbix负载压力大及智能收敛信息

这两天我和哥们参与了zabbix相关的开发,微微有点心得,给大家分享下 ~


首先分享下哥们的博客,http://www.furion.info/   里面可是很有干货哈~  他现负责公司的zabbix主要二次开发,集成资产的zabbix和zabbix性能优化!


好了,咱们开始吧 ~


为什么要做告警平台? 到底是为什么? zabbx自己不就能发邮件么? 干嘛需要报警平台支持呢 ?



    公司zabbix所监控的机器早就过万了,对于他们的报警触发,这边是调用smtplib通过exchange的smtp服务来发邮件,经常遇到3-5s之后才发件成功的情况,试想下zabbix发件那么多,又那么频繁,他的系统资源消耗是很多的。


    其实有朋友说了,可以用postfix做扩展mta,这东西在***的时候,和公司的邮件大神交流过,得到的结果是,用postfix做第三扩展mta快是快了,但是增加了自己运维的成本,说白了就是没事找事,找si。 然后你给postfix是快了,但是呢,postfix里面的邮件还是会扔给exchange处理的。 所以这也不是我想要的。


zabbix进行报警告警的方式有那么几种,最常用的其实还是脚本的模式,其实我想要的是http的模式,看了下官方的文档,没有提供这个功能。


看了一段时间的zabbix发信的代码,一头雾水,其实我的想法很简单,不许要zabbix调用脚本,而是通过zabbix的底层代码直接发送http信息。毕竟调用脚本程序,然后在发送http,他的进程消耗肯定不小。  这个路子不通,倒是还有一条路子,那就是遍历下数据库的alerts的信息,然后搞出来发出去。 他的扩展行更好,能组合查询出更有效的信息组合。


mysql> desc alerts;
+-------------+---------------------+------+-----+---------+-------+
| Field       | Type                | Null | Key | Default | Extra |
+-------------+---------------------+------+-----+---------+-------+
| alertid     | bigint(20) unsigned | NO   | PRI | NULL    |       |
| actionid    | bigint(20) unsigned | NO   | MUL | NULL    |       |
| eventid     | bigint(20) unsigned | NO   | MUL | NULL    |       |
| userid      | bigint(20) unsigned | YES  | MUL | NULL    |       |
| clock       | int(11)             | NO   | MUL | 0       |       |
| mediatypeid | bigint(20) unsigned | YES  | MUL | NULL    |       |
| sendto      | varchar(100)        | NO   |     |         |       |
| subject     | varchar(255)        | NO   |     |         |       |
| message     | text                | NO   |     | NULL    |       |
| status      | int(11)             | NO   | MUL | 0       |       |
| retries     | int(11)             | NO   |     | 0       |       |
| error       | varchar(128)        | NO   |     |         |       |
| nextcheck   | int(11)             | NO   |     | 0       |       |
| esc_step    | int(11)             | NO   |     | 0       |       |
| alerttype   | int(11)             | NO   |     | 0       |       |
+-------------+---------------------+------+-----+---------+-------+





把上面的话总结下,一句话,解决zabbix发信的负载问题。


欧了,那咱们就先把这些给理清楚,咱们让速度给提上来,最少不给zabbix一些额外的压力。

原文:http://rfyiamcool.blog.51cto.com/1030776/1408796

软件框架:


接口:

   nginx lua/nginx tornado

队列:

   redis

mq:

   zeromq

数据库:

   mongodb (文档型数据库,最适合做这个干练的事情)

后端daemon:

   python gevent smtplib requests

报警的来源:

  zabbix,nagios,各种形式的报警来源


这里先描述下,运转的一个例子,比较简单的流程:


1. 用户发信息

curl -d "sendmode=mail&[email protected]&sendtitle=服务器死掉了&sendcontent=1.1.1.1" http://xiaorui.cc/recpost


2. 我这边收到信息并插入到redis后,会立马给他return一个状态。


3. 后端起一个daemon专门处理队列,并通过zeromq来分发任务,里面用了0mq的rep/req 和pull push这两个方案。


4.  当本地节点或者是分布式的节点收到msgpack的信息后,会解析要发送的信息,发送,并返回状态。


5.  zeromq master端收到状态后,入库。



报警平台难道只有这些么?  当然不,其实报警平台最主要的核心是智能的分析和报警收敛,告警关联。


有很多重复性和有规律的邮件,短信,咱们可以统一发件,而不是每次都发。 因为收件人时常会懒得看邮件,因为太多了,烦了。那咱们有必要做一次统计方案。报警收敛,主要是体现在信息的整合,比如nginx1、nginx2、nginx3...  都开始狂爆502的网关错误,如果对方的接口加了支持调优的参数,我这边会延迟报警,然后把信息整合后再发送。例子是这样的,以后结果就是,每个人收到的短信和邮件都是精华。  


原文:http://rfyiamcool.blog.51cto.com/1030776/1408796


       再说下告警的关联,比如mongod数据大的时候很吃内存,引起了两个报警触发,一个是mongodb内存大了,还有一个是系统的内存比率大了。这个时候,可以做一些判断。 当然这些规则需要后期整理写入的。 我在后端的逻辑里面预留了这段代码的嵌入,以后可以做成一条条的匹配。

      当然报警的智能收敛不是这么好搞的,毕竟他延迟了告警做相关的匹配。但个人认为利还是大于弊端的。


平台后期可以做大量的数据统计。

   因为每次告警都是通过该平台接口来发邮件和发短信,我这边根据库里面的信息,做出那个哪台服务器,哪个业务,哪个时间段,哪种报警类型等等的统计。根据这些可以做定期的报表。


下面是我这十几天做的项目demo,现在已经接入了zabbix的接口,等再测试一段时间后,就替换zabbix报警接口 ~

wKiom1NsNV3hPXexAALNDKGgOUc187.jpg


运维平台可以很好的兼容手机端浏览器的样式,可以很好的在手机端舒展 !

通过二维码可直接访问。

wKiom1NsNX2CifqiAAoxK7qI8ig897.png


这里是给开发和运维人员提供的报警的接口文档,提供了多个接口形式,字段除了必须那三个字段外,其余的可随意定义。


wKioL1NsNa2hiPI_AAHNbsyHVT0044.png



这是发送邮件的历史信息查看,可以通过各种选项配合正则来查询各种信息。


wKioL1NsNfqz4L56AAKQzeqpQCI583.png


这里是可以清空队列和选择性的***队列信息。


wKioL1NsNkKiaUUrAAKf83UjEKw479.png

这是短信的历史记录接口,方便的各种查询。


wKioL1NsNoyTvKypAALDfJWzLJ0574.png


这是大屏幕监控,现在做的有点粗糙,对于各种报警的级别还没有做细化,这报警平台页面后期可放在公司墙上的大屏幕,实时查看各种动向,对于重要的业务,会有声音的提醒。简单点的有 叮叮的声音,如果你的声音够磁性,可自己录音。 比如,xxx的nginx挂了,你妹的赶紧处理呀。



wKiom1NsNvLBtroPAAZxRJEnp3c354.png

邮件的样式模板:

wKioL1OH7UDjJVRCAAIovxRDQ2w612.jpg


wKiom1OH8zfzmrYGAAM46TjC6pY646.jpg


一个简单的调试页面:


wKiom1NsO8CCK1X-AARfbD2PLV8910.jpg


数据的分析以后造成这个样子,这是我以前做的一个报警分析的东西 ~

002312670.jpg



挂在公司的电视上,做大屏幕 !

wKiom1Nu7RGRmM7NAAuqcMl5IqE117.jpg


这样咱们一抬头就很方便看到zabbix报警信息~


wKiom1Nu7RLx1Ua_AAq4HFldQ8g266.jpg



还没有写完,待续~~~条件过滤的实现,可以方便的定义,你要过滤的条件,比如相同的报警内容不能在30秒内重复发,包括内容的正则的匹配!wKiom1OUKDSigLqAAAI5d4uL3Uo119.jpg

本文出自 “峰云,就她了。” 博客,谢绝转载!

你可能感兴趣的:(性能,zabbix,zabbix,zabbix,二次开发,http报警,zabbix负载)