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

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

首先分享下哥们的博客，http://www.furion.info/ 里面可是很有干货哈~ 他现负责公司的zabbix主要开发。

好了，咱们开始吧 ~

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

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

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

把上面的话总结下，一句话，解决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报警接口 ~