報警分發系統的實現和總結

報警分發系統：https://github.com/smartxff/dingding_exporter
既然是上篇博客的實現結果，就以上篇的需求爲主體結構來進行實現過程的說明和總結

1. 報警輸入標記

　　控制本身的東西，永遠比控制本身簡單。報警消息發送過來時，只會告訴我那個實例有問題，有什麼問題，至於這個實例屬於誰，它並不關心。因此發送過來的告警所在的實例屬於誰這件事，就得我本身程序實現了。畢竟控制本身簡單嘛。

2. 獲取報警

　　報警的獲取來源是prometheus的alertmanager。它會發送給我一個固定格式的json，而後我能夠從這個json中獲取，報警信息。至於其餘非prometheus的告警，我怎麼獲取呢？只要他發送個人消息知足這個json的部分字段，我就能夠處理他的報警。因此此部分是以固定格式的請求body來實現複用。

3. 獲取報警與接收人對應關係

　　由於咱們prometheus主要的監控來自於docker上跑的服務的url，咱們會進行探活，而每一個docker的項目的源代碼都來自於gitlab。因此報警和接收人的關係就來自於gitlab了。畢竟每一個項目都是由建立者和修改着構造的。可是一個gitlab項目不只能夠屬於某我的，也能夠屬於某個組，我確定不可能給一個組的人都發送報警。我確定會被打死。咱們提交代碼時都會commit。可是這個commit屬於提交代碼時的本地環境。本地環境和線上環境可能不一樣步，好比你gitlab中叫張三，你本地叫sanzhang，那麼commit裏面保存的就是sanzhang。因此從commit中獲取接收人信息就pass。雖然commit裏面的信息不是gitlab上的，可是push代碼這個event，事件自己是屬於線上自己的。因此咱們的報警總會發送給最後一次提交代碼的人。簡直至關完美呀。咱們prometheus除了監控docker裏面的項目，還監控了一些手動加上的監控項，好比某個外網url之類的。咱們只能經過讀取本地對應關係表中的數據，來查找對應關係。此處試用yaml格式存儲這些數據。而後沒找到對應關係的報警會發送到咱們運維所在釘釘羣中，咱們收到後能夠選擇手動添加對應關係，和咱們本身處理報警。此處算是實現了需求分析。

4. 根據標記和對應關係發送報警

　　用戶基本上就使用兩種接受信息的方式，一種是短信，一種是郵件。郵件仍是比較好實現的。釘釘羣的機器人接口使用特別方便，因此測試階段以及咱們運維接受報警主要使用釘釘羣。郵件實現的比較簡單，整體內容固定，只有內容和發送對象不一樣。釘釘由於咱們本身使用，我實現的功能就更多一點。首先有一個默認的釘釘接口，主要接受沒有匹配的接收人的告警。而後能夠經過配置文件自定義哪一個實例的告訴發送到那個釘釘羣。

其餘實現

　　有些告警信息一時半會兒處理不了，可是prometheus咱們設置的同一個報警10，若是未處理10分鐘發送一次。因此此處我加入了告警過濾的功能，固然也是以配置文件的形式實現。
　　釘釘羣接口每分鐘只能向它發送20次消息，超過這個數，此接口就會失效，必須手動生成新的webhook。因此我打算在釘釘發送消息這上面作一個限制，每分鐘最多隻能發送20個消息。目前還沒實現，不過具體的思路已經有了。建立一個長度爲20的chan，沒收到一個發送釘釘告警的請求，就起一個goroutine，從chan中獲取一個值，而後發出一個釘釘告警消息，sleep 1分鐘後在往chan中發送一個值。就算一秒鐘發送20個請求，chan裏面的值爲空，下一個請求，就會一直等待chan中的有值。只有超過一分鐘後，其中一個gorutine給chan發送一個值。下一次請求才可執行。此處有點濫用chan的感受。不過嘛，優秀的程序員都是從寫爛代碼開始的~~~

不知道本身代碼爛
知道本身代碼爛，不知道爲什麼爛
知道本身代碼爛，知道怎麼寫好
代碼已經能寫好，不知道怎麼寫更高性能的代碼
代碼能寫好，也能寫高併發，而且高可用，無狀態。
那麼，我就算是成爲一個合格的程序員了。
加油！