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

報警分發系統：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的感覺。不過嘛，優秀的程序員都是從寫爛代碼開始的~~~

不知道自己代碼爛
知道自己代碼爛，不知道為何爛
知道自己代碼爛，知道怎么寫好
代碼已經能寫好，不知道怎么寫更高性能的代碼
代碼能寫好，也能寫高并發，并且高可用，無狀態。
那么，我就算是成為一個合格的程序員了。
加油！