一、概要 由於監控業務發展的較快，各種告警很多，並且告警記錄不能查詢，則需要一個平臺來解決告警展示、查詢等問題，「統一告警平臺」應運而生。以下簡稱AMC(Alert Messages Center)。 AMC提供介面調用和前臺配置，支持Rtx、簡訊、微信、郵件四種告警通道，支持模塊信息自動補全、告警 ...
一、概要
由於監控業務發展的較快，各種告警很多，並且告警記錄不能查詢，則需要一個平臺來解決告警展示、查詢等問題，「統一告警平臺」應運而生。以下簡稱AMC(Alert Messages Center)。
AMC提供介面調用和前臺配置，支持Rtx、簡訊、微信、郵件四種告警通道，支持模塊信息自動補全、告警收斂、歷史記錄查詢/展示等功能，告警接收人和告警機器可關聯CMDB獲取相關信息，也可獨立配置，同時支持臨時屏蔽功能。
二、接入說明
1、登記項目
若某項目需要發送告警，則可以考慮接入AMC。
該項目的開發同學，先在AMC前端頁面登記項目信息，然後在自己項目代碼里調用告警介面，發送告警即可。
登記項目信息需提供：
- 項目名稱，必須欄位：包含 a）全局唯一的英文欄位，b）拉風的中文名稱
- 項目申請人，只是登記一下，不做其他用途
- 選擇一個三級業務信息，必須欄位
- 告警開關，基於本項目的告警開關，可在故障時控制本項目的告警消息是否發送出來
- 告警接收人，支持發送業務樹負責人/機器負責人/自定義/介面指定
- 告警收斂周期，預設為 60 秒，在一個周期內，重覆告警則以第一條為準，其他會被過濾，可在介面設置不收斂/過濾。
- 告警收斂規則
- 告警方式：rtx，sms，wechat，e-mail，至少選一種
登記後會獲得一個全局唯一的項目key，appKey，作為告警介面的一個必需參數
2、告警類型
一個項目中一般會有多種不算類型的告警（不同的異常情況），本模塊採用「首次告警登記」的方式，即不用特意先登記有哪幾種異常。
在某個項目的開發過程中，當遇到一種的異常情況，為這種異常指定一個（本項目內）唯一的字元串，稱為「告警類型」，因此有全局唯一的欄位：appKey + 告警類型。
但，一個項目邏輯很簡單（比如一個腳本），不需區分異常類型，或是項目剛剛啟動，暫時只有一種異常，則發送告警時不需指定「告警類型」，本模塊使用 default 作為預設值。
以下簡稱「告警類型」，一種告警類型中預設包含有「項目」key，即全局唯一的「告警類型」。
比如「基礎監控」中的 cpu、記憶體，都是該系統下的一種告警類型。
3、機器維度
每條告警消息，也應有一個的機器信息，基於機器信息，我們可以做：
- 該機器在 CMDB 中是否打開了告警。這是一個總開關，優先順序最高
- 使用該機器在 CMDB 的業務信息，可以確定該機器是線上機器、或是非線上機器，不同的機器角色，有不同的收斂規則
三、告警介面設計
1、redis 隊列
包含兩種隊列：
- 待處理隊列，暫定8個隊列， in_list_{01} ... in_list_{08}，由「告警介面」按 「告警類型 」做一致性 hash 寫入，再由後端進程進行處理
- 已處理隊列，暫定一個隊列，his_msg_list，後端進程處理後寫入該隊列，再由 logstash 每分鐘取出，寫入 elasticsearch
2、任務數據
「告警介面」寫入的數據，為「任務數據」。
任務數據需要序列化：使用 msgpack api 把任務信息序列化成二進位，再把二進位寫入redis。
序列化的各欄位順序（php、偽代碼）：
msgpack_pack( array( 'appKey' => $app_key, // 字元串 'content' => $content, // 字元串 'alarmType' => $alarm_type, // 字元串 'isFadeOut' => $is_fadeout, // 數值 1、0 'timestamp' => $timestamp, // 時間戳 'alarmIp' => $uip, //無符號整形ip，告警的機器 ip 'remoteIp' => $remoteIp, // 無符號整形ip，調用介面的對端 ip 'otherUser' => $other_users, // 用戶id列表，多個id使用英文分號分隔 ) );
3、消息數據
後端程式處理一個任務，生產一個「消息數據」
格式為 json，為了讓 logstash 直接寫入 elasticsearch
一條數據包含如下欄位，各欄位含義請見以下 mysql create table 語句中的註釋：
app_id，數值，項目 id app_key，字元串，項目key app_name, 字元串，項目標識（英文名） alarm_id，數值，告警類型 id alarm_type，字元串，告警類型 ip（點分表示法），字元串，ip content，字元串，告警內容 occur_time，字元串，YYYY-MM-DD hh:mm:ss，故障時間戳 result_code，數值，處理結果狀態碼 result，字元串，處理結果說明 send_time，字元串，YYYY-MM-DD hh:mm:ss, 消息發送的時間戳 send_by，字元串，消息發送的渠道 send_to，字元串，消息發送給了誰
四、告警後臺設計
1、生產者
根據 redis 隊列配置線程數量，每個線程操作一個 redis 隊列加上「告警類型」的一致性 hash 可保證記憶體中的二級以下數據不用加鎖，極大優化程式處理速度。
定時從 CMDB 獲取最新 ip/業務樹/機房等信息，定時從 AMC 資料庫中 load 配置信息，降低資料庫壓力並且通過隊列傳遞減少阻塞。
根據記憶體數據來解析判斷是否需要告警，需要則推送給「消費者」
定時恢復告警記錄的「異常/正常」狀態
2、消費者
多線程操作，實時從「生產者」獲取告警消息推送給用戶，並寫進資料庫和 redis，提供 logstash 調用
五、臨時屏蔽設計
1、增加臨時屏蔽
- 根據不同需求提供一定時間的屏蔽告警功能，屏蔽時間開始即生效關閉告警，屏蔽時間結束則繼續開啟告警。每次屏蔽均會生成一條屏蔽記錄，每條屏蔽記錄均記錄下操作人和屏蔽原因，方便審計
- NOTE: 臨時屏蔽功能上線期間會同時將永久關閉告警功能，對某條記錄的屏蔽最長是10天，因為amc的告警一般是rtx/mail持續7天，其他的持續1天，則屏蔽10天足夠。對CMDB的告警開關是否去掉需要調查一番。
- WARNING: 屏蔽開始時間必須大於等於當前時間的下一分鐘，結束時間至少在開始時間1分鐘後，不能大於開始時間10天
- IMPORTANT: 由於AMC對開關的獲取是每分鐘才獲取一次，並不是實時獲取開關，則屏蔽開始/結束時間是會提前1分鐘將開關關閉/開啟，這樣能儘量保證開關在AMC中是接近準確值的
2、屏蔽類型
- amc有三級指標，項目->類型->ip，則提供
- 按項目屏蔽
- 按項目下的類型屏蔽
- 按項目下的類型下的ip屏蔽
- amc是結合機器進行告警的，則提供
- 按機器IP屏蔽，則屏蔽該ip，不會對應ip1-ip5
- 按業務樹屏蔽該業務下所有的機器（可區分線上機/測試機，使用中/非使用中），包括ip1~ip5
- 按機房屏蔽該機房下所有的機器（可區分線上機/測試機，使用中/非使用中），包括ip1~ip5
3、取消屏蔽「恢復告警」
由於關閉永久開關，則需要提供介面取消屏蔽，重新開啟開關。
- 提供根據屏蔽記錄來取消的介面
- 提供更細維度的取消介面
- 由於取消永久開關並且實時更新業務樹/機房下的ip，所以遇到這四種屏蔽則只能根據原記錄mask id取消
- 如果是批量ip/appId/alarmId/statusId的取消則可以修改mask表中的生效的value，剔除需要取消的值即可
