一、概要
由於監控業務發展的較快，各種告警很多，並且告警記錄不能查詢，則需要一個平台來解決告警展示、查詢等問題，「統一告警平台」應運而生。以下簡稱AMC(Alert Messages Center)。
AMC提供接口調用和前台配置，支持Rtx、短信、微信、郵件四種告警通道，支持模塊信息自動補全、告警收斂、歷史記錄查詢/展示等功能，告警接收人和告警機器可關聯CMDB獲取相關信息，也可獨立配置，同時支持臨時屏蔽功能。
二、接入說明
若某項目需要發送告警，則可以考慮接入AMC。
該項目的開發同學，先在AMC前端頁面登記項目信息，然後在自己項目代碼裡調用告警接口，發送告警即可。
登記項目信息需提供：
登記後會獲得一個全局唯一的項目key，appKey，作為告警接口的一個必需參數
一個項目中一般會有多種不算類型的告警（不同的異常情況），本模塊采用「首次告警登記」的方式，即不用特意先登記有哪幾種異常。
在某個項目的開發過程中，當遇到一種的異常情況，為這種異常指定一個（本項目內）唯一的字符串，稱為「告警類型」，因此有全局唯一的字段：appKey + 告警類型。
但，一個項目邏輯很簡單（比如一個腳本），不需區分異常類型，或是項目剛剛啟動，暫時只有一種異常，則發送告警時不需指定「告警類型」，本模塊使用 default 作為默認值。
以下簡稱「告警類型」，一種告警類型中默認包含有「項目」key，即全局唯一的「告警類型」。
比如「基礎監控」中的 cpu、內存，都是該系統下的一種告警類型。
每條告警消息，也應有一個的機器信息，基於機器信息，我們可以做：
三、告警接口設計
1、redis 隊列
包含兩種隊列：
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、增加臨時屏蔽
2、屏蔽類型
3、取消屏蔽「恢復告警」
由於關閉永久開關，則需要提供接口取消屏蔽，重新開啟開關。
http://xxxxxx/Linuxjc/1181647.html TechArticle