一、背景
一套監控系統檢測和告警是密不可分的，檢測用來發現異常，告警用來將問題信息發送給相應的人。vivo監控系統1.0時代各個監控系統分別維護一套計算、存儲、檢測、告警收斂邏輯，這種架構下對底層數據融合非常不利，也就無法實現監控系統更廣泛場景的應用，所以需要進行整體規劃，重新對整個監控系統架構進行調整，在這樣的背景下統一監控的目標被確立。
以前監控被劃分為基礎監控、通用監控、調用鏈、日志監控、撥測監控等幾大系統，統一監控的目標是將各個監控指標數據進行統一計算、統一存儲、統一檢測、統一告警、統一展示。這里不作贅述，后面會出一期vivo監控系統演進的文章進一步說明。
上面我們說了監控統一的大背景。以前各個監控系統會各自進行告警收斂、消息組裝等工作，為了減少冗余，需要將收斂等工作由一個服務統一做處理，與此同時告警中心平臺也到了更新迭代的階段，這樣就需要建設一個對內部各業務統一提供告警收斂、消息組裝、告警發送的告警平臺，有了這個構想，我們準備將各系統告警收斂能力與告警發送能力下沉，將統一告警服務做成一個與各監控服務解偶的通用服務。
二、現狀分析
對于1.0時代的監控系統來說，如圖1所示各個監控系統要先進行告警收斂，然后分別和老的告警中心進行對接，才能將告警消息發送出來。每一套系統都要多帶帶進行維護一套規則，有很多重復功能建設，而實際這些功能具有高度通用性，完全可以建立合理模型對異常檢測服務生成的異常進行統一處理，從而生成問題，然后進行統一的消息組裝，最后發送告警消息。
?(圖1?老監控系統告警流程圖）
在監控系統中一個異常從被檢測出來到最終發出告警有幾個重要概念：
異常
在一個檢測窗口(窗口大小可以自定義)，一個或幾個指標值達到檢測規則定義的異常閾值，就產生一個異常。如圖2所示，檢測規則定義當指標值在一個檢測窗口為6的檢測周期內，有3個數據點超過閾值就認為有異常，我們簡稱這個檢測規則為6-3，如圖所示第一個檢測窗口內(藍色虛線筐內)只有6和7兩個點的指標值超過閾值(95)，不滿足6-3的條件，所以第一個檢測窗口沒有異常。在第二個檢測窗口內(綠色虛線框內)有6、7、8三個點的指標值超過閾值(95)，所以第二個窗口就是一個異常。
問題
一個連續的周期內產生的所有同類異常的集合，我們稱之為問題。如圖2所示，第二個檢測窗口就是一個異常，同時這個異常也會對應有一個問題A，如果第三個檢測窗口也是一個異常，那么這個異常對應的問題也是A，所以問題和異常是一對多的關系。
告警
當一個問題通過告警系統將消息以短信、電話、郵件等方式告知給用戶時，我們稱之為一條告警。
恢復
當問題對應的異常不滿足檢測規則定義的異常條件時，就認為所有異常都恢復了，同時問題也認為恢復了，恢復也會發送相應的恢復通知。
?(圖2?時序數據異常檢測原理圖）
三、衡量指標
一個系統我們如何衡量它的好壞，如何提升它，如何管理它？管理學大師彼得·德魯克曾說“你如果無法度量它，就無法管理它(If you can’t measure it, you can’t manage it)”。從這里可以看出，如果想全面管理提升一個系統，就需要先對它的各項性能指標有一個衡量，知道它的薄弱點在哪里，找到病癥所在才能對癥下藥。
?（圖3?運維指標時間節點關系圖）
圖3是監控系統運營指標和對應時間節點關系圖，主要體現了MTTD、MTTA、MTTF、MTTR、MTBF等指標與時間節點的對應關系，這些指標對于提升系統性能，幫助運維團隊及早發現問題有很高的參考價值。業界有很多云告警平臺也很注重這些指標，下面我們著重介紹一下MTTA、MTTR這兩個和告警平臺關系緊密的指標：
MTTA(Mean time to acknowledge,平均應答時間)：
（圖4 MTTA計算公式）
t[i] -- 監控系統運行期間第i個服務出現問題后運維團隊或者研發人員響應問題的時間；
- r[i] -- 監控系統運行期間第i個服務出現問題的總次數。
平均應答時間是運維團隊或者研發團隊響應所有問題所花費的平均時間。MTTA度量標準用于衡量運維團隊或研發團隊的響應能力和警報系統的效率。通過跟蹤和最小化MTTA，項目管理團隊可以優化流程，提高問題解決效率，保障服務可用性，提升用戶滿意度[1]。
MTTR(Mean Time To Repair,平均維修時間)：
（圖5 MTTR計算公式[2]）
t[ri] -- 監控系統運行期間第i個服務出現r次告警后服務恢復正常狀態的總時間
- r[i] -- 監控系統運行期間第i個服務出現告警的總次數
平均修復時間（MTTR）是修復系統并將其恢復到正常功能所需的平均時間。運維或研發人員開始處理異常，MTTR便開始計算，并且一直進行到被中斷的服務完全恢復（包括所需的任何測試時間）為止。在IT服務管理行業中，MTTR中的R并不總是表示維修。它也可以表示恢復，響應或解決。盡管這些指標都對應MTTR，但是它們都有各自的含義，因此，要弄清楚要使用哪個MTTR，有助于我們更好的分析理解問題。讓我們簡要地看一下它們各自的含義：
1）平均恢復時間(Mean time to recovery)是從系統告警中恢復所需的平均時間。這涵蓋了從服務異常導致告警到恢復正常的整個過程。MTTR是衡量整個恢復過程速度的指標。
2）平均響應時間(Mean time to respond)表示從出現第一個告警開始到系統從故障中恢復到正常狀態所需的平均時間，不包括告警系統中的任何延遲。該MTTR通常用于網絡安全中，以衡量團隊緩解系統攻擊的效率。
3）平均解決時間(Mean time to resolve)表示完全解決系統故障所花費的平均時間，包括檢測故障、診斷問題以及確保故障不再發生來解決問題所需的時間。此 MTTR 指標主要用于衡量不可預見事件的解決過程，而不是服務請求。
提升 MTTA 的核心是找對人、找到人[3]，只有在最短的時間內找對能處理問題的人才能有效提升MTTR。通常在生產實踐過程中我們會遇到“告警泛濫”的問題，大量的告警出現時需要運維人員或者開發同學去解決，對于應激敏感的同學來說很容易出現“狼來了”的現象，只要收到告警就會很緊張，同時當大量的告警信息頻發騷擾我們運維人員，會引發告警疲勞，體現為不重要的事件太多，最根本的問題較少，頻繁處理普通事件，重要的信息淹沒在汪洋大海中。[4]
（圖6 告警泛濫問題圖[5]）
四、功能設計
通過上面兩個重要指標的分析，我們總結出要從告警數量、告警收斂、告警升級等方面著手，減少告警發送的數量，提升告警準確性，最終提升解決問題的效率，降低問題恢復時長。下面我們從系統和功能層面說明如何降低告警量，把真正有價值的告警信息發送到用戶手中。本文也將重點圍繞告警消息收斂進行講解。
從圖1中可以看出各個監控系統中都有很多重復的功能模塊，所以針對這些功能模塊我們可以將其抽離出來，如圖7所示將告警收斂、告警屏蔽、告警升級等能力統一建設在統一告警服務中。這種架構下統一告警服務與檢測相關服務完全解耦，在能力上具有一定的通用性。例如其它有告警或消息收斂需求的業務團隊想接入統一告警，統一告警要能滿足消息收斂發送的需求，同時也要滿足消息直接發送的需求。統一告警會提供靈活可配置的消息發送方式，提供簡單、多樣的功能滿足各類需求。
（圖7 統一告警系統結構圖）
4.1 告警收斂
對于告警平臺每天會產生數以萬計的告警，這些告警對于運維或開發人員都需要去分析、甄別優先級、并處理故障。數以萬計的告警如果不加收斂每條異常都發送告警，勢必會增大運維人員的工作壓力，當然也不是所有的告警都需要并且有必要發送給運維人員進行處理。所以我們需要對告警通過多種手段進行收斂，下面我們從四個方面介紹一下如何進行告警收斂。
首次告警等待
當一個異常產生之后我們不會立即去做告警，而是通過等待一段時間才會去做告警發送，一般這個時間可以通過系統自定義，這個值如果太大就會影響告警延遲，太小不能提升告警合并效果。例如首次告警等待時間為5s，當一個服務下節點1出現A指標異常，5s內節點2也出現了A指標異常，那么發送告警時節點1和節點2會被合并到一起發送告警通知。
告警間隔
問題在沒有恢復前，系統會根據告警間隔的配置每隔一段時間發送一條告警信息，告警間隔用來控制告警發送的頻率。
異常收斂維度
異常收斂維度用來將同個維度下的異常合并在一起。例如同個節點路徑A下，通過同一個檢測規則產生的異常，會在告警發送的時候根據配置的異常收斂維度合并在一起。
消息合并維度
當多個異常收斂成一個問題，在發送告警的時候會涉及到消息合并，消息合并維度就是用來指定哪些維度可以合并。可能這樣理解有些晦澀，我們可以通過圖8看一下從異常到消息的轉換過程。
假如一個異常有兩個維度名字和性別，當這兩個異常經過統一告警，我們會根據配置的收斂策略進行合并，從圖中我們可以看到性別被定義為異常收斂維度，通常異常收斂維度的選擇一定是兩個或兩個以上具有相同的屬性的異常，這樣在消息合并后只取相同屬性的同一個值，對應到示例圖，我們會將${sex}占位符替換成男。而名字是被定義為告警合并維度，就表示所有異常中名字是都要展示在消息文本中，所以在消息合并的時候我們會將${name}占位符對應的信息一一拼接在消息文本中。
（圖8 消息文本替換示意圖?）
4.2 告警認領
當出現告警后如果有人認領了該告警，那么后續相同告警只會發送給告警認領人。告警認領主要是為了解決告警有人跟進后，減少將告警發給其他人員，也能從一定程度上解決告警被重復處理的問題。被認領的告警可以取消認領。
4.3 告警屏蔽
對于同一個問題，可以設置告警屏蔽，后續如果有該問題對應的告警產生，那么將不會被發送出去。告警屏蔽能減少故障在定位解決過程中，或者服務在發版變更過程中造成的告警，能有效減少無效告警對運維人員造成的困擾，屏蔽可以設置為周期性的，也可以設置為屏蔽某一時段，當然也可以取消屏蔽。
4.4 告警回調
當告警規則配置了回調，那么當產生告警，就會調用回調接口，使服務或業務恢復正常。告警回調的目的是當某個服務有告警產生，希望系統能夠通過一些自動化的配置，使服務恢復到正常狀態，縮短故障恢復的時間，也能夠緊急情況下第一時間快速恢復服務。
4.5 誤告標注
對于一個問題，用戶可以通過誤告標注備注該異常是否為誤告警。誤告標注的主要目的是通過標注讓系統開發人員知道異常檢測過程中，哪寫點還需要提升優化，提高告警的準確性，為用戶提供真實有效的告警提供保障。
4.6 告警升級
當告警發生一定時間仍沒有恢復，那么系統就會根據配置自動進行告警升級處理，然后將告警升級信息通過配置發送給對應的人員。告警升級一定程度上是為了縮短MTTA，當告警長時間未恢復，可以認為故障沒有及時得到響應，這時就需要更高級別的人員介入處理。
如圖9所示，每天告警系統會發送大量的告警，當然這些告警會分別發送給不同服務的告警接收人。告警并不是越多越好，而是應該第一時間準確反映出服務的異常情況，所以如何提升有效告警，提高告警準確性，減少告警量至關重要。通過以上系統設計和功能設計能夠有效減少重復告警發送。
（圖9 主機監控告警次數圖）
五、架構設計
上面我們從系統和功能層名講解了如何針對老架構下存在的各種問題進行解決，那么對于這個構想我們應該用一套什么架構來實現。
下面我們看下如何設計這套架構。統一告警作為整個監控最后一環，既要滿足告警發送能力也要滿足業務服務發送通知的需求，所以統一告警的各種能力要具有通用性。統一告警服務要做到與其它服務低耦合，尤其是與已有監控系統做到解偶，這樣才能真正把通用能力釋放出來。服務要能做到根據業務場景的不同適配不同的業務邏輯，比如有的業務需要做告警收斂，有的業務不需要，那么服務要提供靈活的接入方式以適用業務需要。
如圖10所示，統一告警核心邏輯由收斂服務實現，收斂服務可以消費kafka中的異常，也可以通過RestFul接口接收推送過來的異常，異常會先經過異常處理生成一個問題，然后將問題和異常存入MySql庫，經過告警收斂模塊問題會被推送到Redis延時隊列中，延時隊列會用來控制消息出隊時間，消息從隊列取出之后會進行文本組裝等操作，最后會通過配置發送出去。
（圖10 統一告警架構圖）
配置管理服務用來管理應用、事件、告警等配置信息，元數據同步服務用來從其它服務同步告警收斂所需的元數據。
六、核心實現
統一告警的核心是告警收斂，收斂的目的就是減少發送重復的告警消息，避免因為大量的告警對于告警接收人造成告警麻痹。
前文已經說到使用延時隊列做告警收斂，延時隊列在電商和支付項目中使用較多，比如商品下單后10分鐘未支付就要自動取消訂單。在告警系統中使用延時隊列主要目的是，在一定的時間內盡可能多的將同一個問題對應的異常合并在一起，減少告警發送的數量。舉個例，如果一個服務A有三個節點，當發生異常時，一般情況下每個節點的異常都會生成一條告警發送出去，但是經過告警收斂時候我們可以將三個節點的告警合并，由一條告警做通知。
延時隊列有很多種方式實現，這里我們選擇了Redis實現延時隊列，選用 Redis 延時隊列主要的原因就是其支持高性能的 score 排序，同時 Redis 的持久化特性，保證了消息的消費和存貯問題。
如圖11所示，一個問題通過一系列校驗去重之后放入redis延時隊列，隊列中到期時間最小的問題會被排到最前面，同時有一個監聽任務不斷查看隊列中是否有過期的任務，如果有過期的任務會被取出，取出的消息會經過消息組裝等操作最終形成一條消息文本，然后根據配置通過不同的通道發送出去。
（圖11 延時任務執行原理圖[6]）
七、未來展望
基于統一告警服務定位來看，告警服務要能簡單、高效、準確的告訴運維或者開發人員，哪里有故障需要去處理。所以對于后續服務的建設，應該考慮如何進一步減少人為的配置，增強告警智能化收斂的能力，同時還要增強根因定位的能力，以上通過AI的加持能夠很好的解決此類問題。目前各大廠商都在向著AIOps探索前進，并且已經有一些產品投入使用，但是AIOps何時大規模落地，就目前來看還需要一段時間。相較于AI的使用，當前最緊迫的就是讓統一告警串聯起上下游服務，從而打通數據，為數據流轉鋪平道路，增強服務的自動化程度，并且支持從更高維度實現告警發送，為故障的發現和解決提供更準確的信息。
八、參考資料
[1]What are MTTR, MTBF, MTTF, and MTTA? A guide to Incident Management metrics
[2]平均修復時間[Z].
?作者：vivo互聯網服務器團隊-Chen Ningning
