摘要：報(bào)警阻塞，發(fā)送效率低下這種情況下，報(bào)警是根據(jù)用戶一個(gè)個(gè)用戶發(fā)送。效果極大的簡化了報(bào)警配置，僅配置了兩個(gè)。發(fā)送效率提高，對(duì)于一個(gè)報(bào)警，無論發(fā)送人數(shù)多少，都只需要觸發(fā)執(zhí)行一次腳本。

通常zabbix告警主要可以通過三種方式

1. 自帶的直接調(diào)用消息接口服務(wù)
2. 執(zhí)行自定義腳本發(fā)送消息
3. 通過send remote commend 的方式通過執(zhí)行腳本發(fā)送

2和3的本質(zhì)都只通過zabbix的action去調(diào)用執(zhí)行服務(wù)器上的腳本來發(fā)送，報(bào)警信息通過在執(zhí)行腳本后帶參數(shù)傳進(jìn)去。
這個(gè)流程很容易跑通， 也非常的簡單可靠。 但是，規(guī)模稍大報(bào)警量一多，問題立馬就顯現(xiàn)出來了。

* 報(bào)警阻塞，發(fā)送效率低下
    * 這種情況下， 報(bào)警是根據(jù)用戶一個(gè)個(gè)用戶發(fā)送。 也就是說， 如果這個(gè)報(bào)警有十個(gè)收件人，那要分到觸發(fā)十次發(fā)送腳本來實(shí)現(xiàn)發(fā)送。
    * 并且這個(gè)發(fā)送還是線性的不是多線程的， 要等上一個(gè)發(fā)送完了， 再接著發(fā)送下一個(gè)。報(bào)警稍微多一點(diǎn)或者收件人稍微多一點(diǎn)， 這個(gè)報(bào)警的延遲就很大了。

* 風(fēng)暴控制 
    * 網(wǎng)絡(luò)抖動(dòng)是個(gè)大坑， 通過proxy的可以通過依賴來實(shí)現(xiàn)一定的風(fēng)暴控制， 但是直接通過服務(wù)器監(jiān)控的就很難做了

    * 一旦風(fēng)暴， 很難退出。 如果sever到某個(gè)直連的idc 間網(wǎng)絡(luò)一抖動(dòng)， 觸發(fā)大量報(bào)警，只能等action 執(zhí)行完

* action 維護(hù)麻煩， 這種模式下， 報(bào)警匹配發(fā)送給誰有 action來決定，有多少種組合就會(huì)有多少個(gè)action， 會(huì)導(dǎo)致 action的數(shù)量很多維護(hù)起來相當(dāng)麻煩
* 報(bào)警配置維度單一： 例如 業(yè)務(wù)dba 僅只想接受業(yè)務(wù)相關(guān)報(bào)警， 不想接受機(jī)器層面的報(bào)警， 看似簡單的需求配置起來會(huì)很麻煩甚至難以實(shí)現(xiàn)
* 報(bào)警信息單一： 比如要給報(bào)警內(nèi)容里加上一個(gè)負(fù)責(zé)人，方便escalation后直接聯(lián)系直接負(fù)責(zé)人都挺麻煩。

為了解決以上問題， 我設(shè)計(jì)了smail 1.0來解決

smail 有規(guī)則解析和風(fēng)暴控制兩個(gè)模塊組成

規(guī)則引擎：
    *  規(guī)則引擎直接定了一個(gè)規(guī)則語法， 主要實(shí)現(xiàn)支持從 設(shè)備名字和觸發(fā)器名字兩個(gè)維度來匹配報(bào)警， 對(duì)于符合匹配規(guī)則的報(bào)警則發(fā)給對(duì)應(yīng)規(guī)則的收件人， 匹配規(guī)則支持正則：
    * 匹配規(guī)則支持正則表達(dá)式
    * 判斷故障級(jí)別， 根據(jù)級(jí)別確認(rèn)發(fā)送短信微信還是郵件

風(fēng)暴控制：

    * 風(fēng)暴控制通過報(bào)警發(fā)送數(shù)量計(jì)數(shù)，對(duì)單位時(shí)間內(nèi)發(fā)送數(shù)量超過一定數(shù)量則觸發(fā)風(fēng)暴控制， 停止發(fā)送報(bào)警。

效果：

1. 極大的簡化了報(bào)警配置， 僅配置了兩個(gè)action。 規(guī)則引擎直接使用yaml 配置文件和正則配置方法， 對(duì)于 python棧的維護(hù)人來非常順手。
2. 發(fā)送效率提高，對(duì)于一個(gè)報(bào)警， 無論發(fā)送人數(shù)多少， 都只需要觸發(fā)執(zhí)行一次腳本。
3. 報(bào)警的可追溯，日志詳細(xì)的記錄了報(bào)警的發(fā)送情況
4. 同時(shí)，對(duì)報(bào)警也加入了更多的信息， 更加方便接受者判斷

這時(shí)報(bào)警郵件就變成了這個(gè)樣子

可是依舊存在的問題：

1.  發(fā)送效率依舊不高， 通過 os.fork  action 依舊要等執(zhí)行完后再執(zhí)行下一個(gè)未能實(shí)現(xiàn)異步。
2.  通過簡單計(jì)數(shù)的風(fēng)暴控制機(jī)制基本沒用

2.0 版：
主要以解決發(fā)送效果為目標(biāo)。 主要是引入異步任務(wù)隊(duì)列來實(shí)現(xiàn)發(fā)送的異步，分離action 觸發(fā)腳本加快 action的執(zhí)行速度。

實(shí)際動(dòng)手過程中發(fā)現(xiàn)， 如果要引入mp或者 celery這樣的 task queue會(huì)新增兩個(gè)damon，這樣反而增加了復(fù)雜度。

后面直接使用了下圖這樣的簡單粗暴的方法來實(shí)現(xiàn)

triggers action 執(zhí)行的腳本直接插入的zabbix mysql （多帶帶建了一張表）；然后通過crontab定時(shí)讀取（一分鐘）mysql獲取報(bào)警。
風(fēng)暴控制通過判斷這一分鐘里的報(bào)警同類的條數(shù)來判斷

效果：

1. 極大的提高了action的執(zhí)行效率， 實(shí)際應(yīng)用過程中， 即使出現(xiàn)報(bào)警風(fēng)暴， 發(fā)送依舊沒有什么問題。
2. 因?yàn)閍ction的執(zhí)行效率的提高， 風(fēng)暴控制有了一定的效果。

TODO：

1. 報(bào)警信息跟cmdb里的信息關(guān)系， 實(shí)現(xiàn)無配置或者少量配置
2. 更有效的風(fēng)暴控制方式