zabbix之报警发送填坑

一般zabbix告警主要能够经过三种方式

1. 自带的直接调用消息接口服务
2. 执行自定义脚本发送消息
3. 经过send remote commend 的方式经过执行脚本发送

2和3的本质都只经过zabbix的action去调用执行服务器上的脚原本发送，报警信息经过在执行脚本后带参数传进去。
这个流程很容易跑通， 也很是的简单可靠。 可是，规模稍大报警量一多，问题立马就显现出来了。

* 报警阻塞，发送效率低下
    * 这种状况下， 报警是根据用户一个个用户发送。 也就是说， 若是这个报警有十个收件人，那要分到触发十次发送脚原本实现发送。
    * 而且这个发送仍是线性的不是多线程的， 要等上一个发送完了， 再接着发送下一个。报警稍微多一点或者收件人稍微多一点， 这个报警的延迟就很大了。

* 风暴控制 
    * 网络抖动是个大坑， 经过proxy的能够经过依赖来实现必定的风暴控制， 可是直接经过服务器监控的就很难作了

    * 一旦风暴， 很难退出。 若是sever到某个直连的idc 间网络一抖动， 触发大量报警，只能等action 执行完

* action 维护麻烦， 这种模式下， 报警匹配发送给谁有 action来决定，有多少种组合就会有多少个action， 会致使 action的数量不少维护起来至关麻烦
* 报警配置维度单一： 例如 业务dba 仅只想接受业务相关报警， 不想接受机器层面的报警， 看似简单的需求配置起来会很麻烦甚至难以实现
* 报警信息单一： 好比要给报警内容里加上一个负责人，方便escalation后直接联系直接负责人都挺麻烦。

为了解决以上问题， 我设计了smail 1.0来解决

smail 有规则解析和风暴控制两个模块组成

规则引擎：
    *  规则引擎直接定了一个规则语法， 主要实现支持从 设备名字和触发器名字两个维度来匹配报警， 对于符合匹配规则的报警则发给对应规则的收件人， 匹配规则支持正则：
    * 匹配规则支持正则表达式
    * 判断故障级别， 根据级别确认发送短信微信仍是邮件

风暴控制：

    * 风暴控制经过报警发送数量计数，对单位时间内发送数量超过必定数量则触发风暴控制， 中止发送报警。

效果：

1. 极大的简化了报警配置， 仅配置了两个action。 规则引擎直接使用yaml 配置文件和正则配置方法， 对于 python栈的维护人来很是顺手。
2. 发送效率提升，对于一个报警， 不管发送人数多少， 都只须要触发执行一次脚本。
3. 报警的可追溯，日志详细的记录了报警的发送状况
4. 同时，对报警也加入了更多的信息， 更加方便接受者判断

这时报警邮件就变成了这个样子

但是依旧存在的问题：

1.  发送效率依旧不高， 经过 os.fork  action 依旧要等执行完后再执行下一个未能实现异步。
2.  经过简单计数的风暴控制机制基本没用

2.0 版：
主要以解决发送效果为目标。 主要是引入异步任务队列来实现发送的异步，分离action 触发脚本加快 action的执行速度。

实际动手过程当中发现， 若是要引入mp或者 celery这样的 task queue会新增两个damon，这样反而增长了复杂度。

后面直接使用了下图这样的简单粗暴的方法来实现

triggers action 执行的脚本直接插入的zabbix mysql （单独建了一张表）；而后经过crontab定时读取（一分钟）mysql获取报警。
风暴控制经过判断这一分钟里的报警同类的条数来判断

效果：

1. 极大的提升了action的执行效率， 实际应用过程当中， 即便出现报警风暴， 发送依旧没有什么问题。
2. 由于action的执行效率的提升， 风暴控制有了必定的效果。

TODO：

1. 报警信息跟cmdb里的信息关系， 实现无配置或者少许配置
2. 更有效的风暴控制方式