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