近些年信息化數(shù)字化的浪潮下，企業(yè)的IT資產(chǎn)和線上業(yè)務(wù)的規(guī)模迅速增長，而為了維護其穩(wěn)定性和服務(wù)質(zhì)量，所需耗費的成本、精力也在逐年攀升。

在此背景下，告警治理根本目標就是能夠?qū)崿F(xiàn)快速響應(yīng)和解決故障，減少故障發(fā)生率和業(yè)務(wù)影響范圍，而這一環(huán)節(jié)中，不可避免地會遇到諸如以下的典型問題：

• 告警散落不標準：在相互隔離的多個監(jiān)控系統(tǒng)中，散落著沒有統(tǒng)一的格式內(nèi)容規(guī)范的各類告警，缺少集中式的管理工具，且告警信息不全面，可讀性低。
• 告警噪音多：各監(jiān)控系統(tǒng)，人工設(shè)置固定閾值的標準不一、同一故障可能引發(fā)不同系統(tǒng)告警，導(dǎo)致大量的誤報、漏報、重復(fù)告警，也引起定位問題困難，或責(zé)任人明確。
• 缺乏工具聯(lián)動：告警處理人工干預(yù)過多，自動處理少，告警流轉(zhuǎn)效率低，過程缺少追蹤，處理經(jīng)驗沉淀難。
• 缺乏全局視圖：無法直觀了解應(yīng)用系統(tǒng)&對象模型的告警整體情況和關(guān)聯(lián)影響范圍。

……

“工欲善其事，必先利其器。”

企業(yè)要實現(xiàn)運轉(zhuǎn)良好的告警管理流程，就需要利用好告警管理工具，從而能夠更快更低成本的達成目標。接下來我們就以嘉為鯨眼告警中心為例，從告警管理流程出發(fā)進行“順藤摸瓜”，對過程中的“告警集中匯聚”、“告警信息豐富”、“告警收斂降噪”三個重要典型場景進行拆解分析，分享企業(yè)實現(xiàn)良好告警管理流程的經(jīng)驗。

01. 告警集中匯聚：讓信息不再是一盤散沙

通常情況下很難有大而全的監(jiān)控系統(tǒng)能夠同時囊括服務(wù)器、網(wǎng)絡(luò)、數(shù)據(jù)庫中間件、存儲、應(yīng)用系統(tǒng)、日志、機房動環(huán)等多種IT資產(chǎn)/業(yè)務(wù)系統(tǒng)的監(jiān)控訴求。因此，大部分企業(yè)都會建設(shè)多套監(jiān)控系統(tǒng)以應(yīng)對不同的業(yè)務(wù)需求。但這樣的煙囪式架構(gòu)，存在重復(fù)建設(shè)、數(shù)據(jù)難互通、維護成本高等問題。

解決問題的第一步，就是將這些分散在不同監(jiān)控系統(tǒng)中的全量告警匯聚起來，經(jīng)過流程流轉(zhuǎn)，對外發(fā)送統(tǒng)一、明確、及時的告警信息，使得事件得到快速有效的處理。實現(xiàn)集中匯聚告警，需要解決如下要點：

• 多種靈活匯集方式，統(tǒng)一管理告警

嘉為鯨眼告警中心，支持常規(guī)固定格式的REST API推送，還支持通過接口調(diào)用獲取、數(shù)據(jù)庫拉取、kafka對接、SNMP Trap推送、socket連接等多種方式，能有效滿足各類對接需求，使分散在各個監(jiān)控系統(tǒng)中的告警能夠有效匯聚起來，統(tǒng)一管理。

• 低門檻在線拓展能力，保障持續(xù)發(fā)展

企業(yè)在業(yè)務(wù)發(fā)展的同時，也伴隨著新的系統(tǒng)的引入和建設(shè)，告警系統(tǒng)需要具備拓展性，以應(yīng)對未來的業(yè)務(wù)需求。

嘉為鯨眼告警中心，在持續(xù)積累對常見監(jiān)控系統(tǒng)開箱即用對接能力的同時，開放了以python腳本形式的開發(fā)獨立插件的能力，用戶可以在不影響線上系統(tǒng)穩(wěn)定的情況下，便捷的對接更多的第三方告警源（即監(jiān)控系統(tǒng)），企業(yè)運維人員只需要簡單的腳本開發(fā)基礎(chǔ)，即可具備持續(xù)拓展能力，逐步轉(zhuǎn)型運維開發(fā)。

• 個性化定義，清晰展示不同告警

通常情況下，來自不同監(jiān)控系統(tǒng)的告警信息并不完全一致，在告警信息存在較大差異時，清晰明了的告警內(nèi)容分級分類展示，能夠有效提高運維人員處理告警信息的效率。

嘉為鯨眼告警中心，支持用戶通過插件文件定義第三方系統(tǒng)的字段與告警中心標準字段的映射、清洗規(guī)則，并且支持針對每個告警源設(shè)定數(shù)量不限的拓展字段，以應(yīng)對個性化需求。

其中針對告警等級，除了常規(guī)的等級映射之外，用戶還可自定義拓展更多等級，設(shè)定每個等級需要的顯示名，標識顏色等。

• 快速同步告警狀態(tài)，避免重復(fù)操作

告警系統(tǒng)除了接入觸發(fā)的新告警，也需要支持在監(jiān)控系統(tǒng)檢測到告警恢復(fù)，或監(jiān)控系統(tǒng)自行關(guān)閉告警、由于監(jiān)控策略關(guān)閉而關(guān)閉告警后，對此類終態(tài)告警進行同步對接，以免在多個系統(tǒng)發(fā)生重復(fù)操作。

嘉為鯨眼告警中心，支持在恢復(fù)或關(guān)閉的告警接入時，按照相同的告警事件ID，找到觸發(fā)的有效告警，自動完成告警狀態(tài)的變更，還可以按需補充告警恢復(fù)/關(guān)閉時間、關(guān)閉原因等信息。對關(guān)閉和恢復(fù)做區(qū)分，能進一步明確狀態(tài)，避免用戶誤解。

• 確定告警事件唯一性，精準定位來源

對于告警系統(tǒng)來說，僅對每一條入庫告警賦予唯一的告警ID，是不足以做好去重和對應(yīng)恢復(fù)/關(guān)閉的，需要另外的特性ID來共同確定告警事件的唯一性。如果交由告警源來提供事件的特性ID字段，實際落地會遇到很多系統(tǒng)無法提供的問題；而如果通過告警事件的屬性字段如“告警對象、告警內(nèi)容”自動判斷告警的唯一性，適用性廣，落地方便，但不夠靈活。

嘉為鯨眼告警中心，采用“預(yù)定義+可擴展”的方式，默認規(guī)則是通過“告警源、告警對象、告警等級、告警指標”組合生成唯一的告警事件ID，同時也支持用戶自行配置唯一性判斷的字段，確保告警事件唯一性，精準定位告警來源并進行有效處理。

02. 告警信息豐富：探本求源精準定位問題

為什么需要對告警信息進行豐富呢？

在匯聚不同監(jiān)控系統(tǒng)的告警過程中，運維人員通常會發(fā)現(xiàn)不同監(jiān)控系統(tǒng)、不同類型的告警信息差別很大。有些監(jiān)控系統(tǒng)的告警，信息充足且規(guī)范，除了完整的告警指標、等級以及告警對象的實例名等，還附帶有告警主體所在業(yè)務(wù)拓撲信息；而另外一些系統(tǒng)的告警信息比較簡陋，只有諸如：一個ip地址、磁盤空間使用率過高等信息。即使通過告警源插件文件做了對告警標準字段的清洗、映射，仍無法有效解決信息偏差較大的問題。如下所示：

而告警豐富功能，可以通過界面化配置，通過和CMDB（配置管理數(shù)據(jù)庫）的關(guān)聯(lián)，高效消費用戶維護在CMDB中的實例配置信息，關(guān)聯(lián)關(guān)系等；還可以對告警信息完成輕量化的二次清洗，免除頻繁修改插件文件的工作量，便捷地實現(xiàn)告警事件內(nèi)容、格式的統(tǒng)一。告警豐富在提升告警可讀性的同時，能夠提供告警治理的抓手，便于完成后續(xù)更靈活的告警篩選和更簡便的策略配置，有效提升分析和處理故障的效率。以嘉為鯨眼告警中心為例，以下是兩種告警豐富功能的落地實踐分享：

1. CMDB豐富

上文我們提到，當(dāng)?shù)谌奖O(jiān)控系統(tǒng)的告警信息比較簡陋，并不包含用戶分析和處理告警事件所需的全部信息時，用戶還需要根據(jù)告警中的IP地址等信息，在CMDB中手動查詢需要的內(nèi)容，兩相對照才可完成進一步的處理。

通過CMDB豐富，可以直接將告警對應(yīng)的主體各項配置信息（實例的屬性信息）自動添加到告警中，讓用戶一目了然的看到所有需要的信息。

下圖為典型示例，當(dāng)主機發(fā)生告警時，將主機的各項配置信息顯示在告警內(nèi)。

當(dāng)然，配置告警字段和CMDB實例屬性信息的映射規(guī)則，生效的前提是告警可以找到唯一的實例。對于沒有和CMDB關(guān)聯(lián)的第三方監(jiān)控系統(tǒng)，可以通過配置CMDB關(guān)聯(lián)規(guī)則來實現(xiàn)：根據(jù)告警字段和CMDB則能夠根據(jù)告警內(nèi)容中正則提取的IP地址和CMDB中的內(nèi)網(wǎng)IP屬性值進行比對，以準確找到唯一對應(yīng)的實例，從而實現(xiàn)后續(xù)的字段信息豐富。

實際效果如下所示：

2. 常規(guī)豐富

通過字符替換、字符提取、字段調(diào)整等方式，以頁面配置的方式，對告警信息進行標準化清洗，同時運維人員可以自定義上述方案的生效規(guī)則和應(yīng)用范圍，從而快速實現(xiàn)對需要處理的部分告警信息的豐富。

1）字符替換

當(dāng)相同事務(wù)在不同系統(tǒng)間名稱不同時，如有些系統(tǒng)是中文：主機、數(shù)據(jù)庫，有些是英文：host、DB、database；還有些是名稱不規(guī)范，如mysql、MYSQL等。可以通過字符替換功能，對每個告警源的告警配置翻譯替換規(guī)則，便于運維人員理解。

2）字符提取

有些系統(tǒng)的告警將指標當(dāng)前的具體值寫入一個獨立的拓展字段內(nèi)，而另一些系統(tǒng)的告警，只能從告警內(nèi)容字段中找到指標具體值，如zabbix的告警，告警內(nèi)容的尾部the value is 之后就是監(jiān)控指標的當(dāng)前值。

通過字符提取功能，靈活運用正則表達式，將指標的當(dāng)前值從告警內(nèi)容中拆分出來，進一步實現(xiàn)指標規(guī)范，讓所有系統(tǒng)的告警，都將指標具體值單獨顯示為一個字段。

3）字段調(diào)整

類似的，對于一些監(jiān)控系統(tǒng)定義了很多拓展字段，而用戶使用過程中，想要將這些字段合并為一個，更便于去查看，也可以通過字段的調(diào)整功能實現(xiàn)。

例如某系統(tǒng)的告警，將主機所在位置，分城市、機房、機柜三個字段顯示，通過字段調(diào)整，將三個字段合并為機器位置這一個字段。

4）自定義應(yīng)用范圍

大多數(shù)情況下，我們需要的只是上述提到的方案對某一部分的告警生效。那么可以通過配置策略匹配規(guī)則，制定方案應(yīng)用范圍：按告警字段進行篩選，如“告警內(nèi)容”包含某個信息，或者“告警對象”匹配某個正則表達式等，讓符合條件的告警執(zhí)行設(shè)定的方案。

03. 告警收斂降噪：去蕪存菁，剔除“無效告警”

實現(xiàn)告警集中和信息豐富之后，自然而然就遇到了另一個亟待解決的問題——告警噪音過多。一線團隊可能每天都會收到幾千封告警通知，但精力范圍內(nèi)可處理的數(shù)量卻遠遠不及。疲于應(yīng)對的同時，無法從汪洋大海一般的告警中甄別出真正重要的內(nèi)容。

部分團隊無奈之下，可能會采取一種簡單粗暴的方式，即通過告警等級來區(qū)分，優(yōu)先處理最高等級的告警（實際上也只能夠勉強處理最高等級告警）。

然而這種方式實際上存在著極大的隱患：在各個監(jiān)控工具上，對于不同的監(jiān)控對象、監(jiān)控指標設(shè)置的閾值標準，不一定具備實際的業(yè)務(wù)含義，必然存在大量的誤報、漏報。

另外經(jīng)常忽略低等級告警信息，就不能及時發(fā)現(xiàn)故障前兆，而當(dāng)致命故障發(fā)生時，處理難度會更大，也對業(yè)務(wù)服務(wù)和終端用戶造成更大范圍的影響。

只有通過合理高效的告警降噪能力，才能夠幫助運維人員在有限的時間范圍內(nèi)快速、智能地篩選、定位出真正需要關(guān)注或人工處理的告警，以點帶面，大幅降低故障影響范圍，更好的感知到當(dāng)前需要處理的告警全貌，維護業(yè)務(wù)的穩(wěn)定。

而完成告警降噪，首先需要定義哪些屬于理應(yīng)被壓縮的“無效告警”，然后針對各類告警制定相對應(yīng)的解決方案，最終快速實現(xiàn)高效的告警降噪。

1. 常見“無效告警”：

• 維護期告警：在應(yīng)用發(fā)布/遷移/切換、環(huán)境維護、例行重啟、災(zāi)備演練等變更維護期間，所產(chǎn)生大量無需關(guān)注的告警。
• 重復(fù)告警：監(jiān)控系統(tǒng)在故障未解決的情況下持續(xù)檢測，持續(xù)發(fā)送的告警。
• 相同維度告警：多個監(jiān)控系統(tǒng)監(jiān)控覆蓋面有重疊，對同一個IT設(shè)備的相同問題，來自不同監(jiān)控系統(tǒng)，多條具備相同維度屬性的告警，如同一個對象相同指標的告警、或者具備相同的業(yè)務(wù)、集群、模塊、關(guān)聯(lián)信息等屬性的不同對象的告警。
• 相同負責(zé)人告警：隸屬于同一個人負責(zé)的，短時間內(nèi)集中爆發(fā)的告警。
• 抖動類告警：CPU使用率、網(wǎng)卡流量等指標偶發(fā)高于閾值的告警。
• 快速恢復(fù)告警：產(chǎn)生后較短時間（如2分鐘內(nèi)）內(nèi)自動恢復(fù)的告警。
• 依賴相關(guān)告警：依賴關(guān)系引發(fā)的告警，如數(shù)據(jù)庫運行于主機，或設(shè)備通過交換機聯(lián)通網(wǎng)絡(luò)等，由于被依賴設(shè)備產(chǎn)生故障而導(dǎo)致由依賴關(guān)系的的告警。

2. 對應(yīng)的制定告警降噪的方案：

1）時間屏蔽

由于系統(tǒng)變更、跑批等維護期間，很少會采取同時停止監(jiān)控的方式，所以因系統(tǒng)、設(shè)備的異常態(tài)而必然引發(fā)的告警，可以通過告警屏蔽，實現(xiàn)對指定時間窗口內(nèi)可預(yù)知的無效告警進行收斂——不會分派通知，也不出現(xiàn)在需要處理的告警列表中。

2）告警去重

嘉為鯨眼告警中心采取自動去重策略。當(dāng)一條告警還處于處理中未結(jié)束的狀態(tài)（下文中稱此類告警為“活動告警”），后續(xù)接入的重復(fù)告警，會被自動收斂掉。此處的重復(fù)告警的定義，取決于在接入告警環(huán)節(jié)告警事件的唯一性方案。相同告警事件ID的告警，被視為重復(fù)告警。

收斂同時累加活動告警的“告警計數(shù)”，并將被收斂的告警和對應(yīng)的活動告警進行關(guān)聯(lián)。

3）關(guān)聯(lián)聚合

將某個時間窗口內(nèi)，指定的一個或多個告警字段完全相同的多條告警聚合，讓這些相同維度或者相同負責(zé)人的告警，只分派通知一次，減少對運維人員的打擾，又可以便捷的查看所有聚合的告警。

例如配置將主機產(chǎn)生的告警，在設(shè)定的10分鐘時間窗口內(nèi)，有著相同的“告警指標、CMDB業(yè)務(wù)、主要維護人”的多條告警收斂為一條。

這也可以視為一種更靈活的去重策略，能有效解決內(nèi)置自動去重策略所未涉及的一些場景，如：來自同一個監(jiān)控系統(tǒng)的不同類型/不同負責(zé)人告警，告警事件唯一性方案有區(qū)別，需要靈活的設(shè)定；用戶希望超過一定時間段后，再此生成一條新的活動告警，而非全部抑制等。

4）告警防抖

某些監(jiān)控系統(tǒng)不具備防抖檢測機制，經(jīng)常出現(xiàn)一些指標值突升突降，引發(fā)很多迅速恢復(fù)的告警，這使得運維人員收到大量告警后來不及查看又恢復(fù)了。

在實際的業(yè)務(wù)場景中，雖然這些指標設(shè)定的閾值是合理的，超過閾值需要告警，但用戶希望僅當(dāng)指標值連續(xù)幾個檢測周期，持續(xù)高于閾值再發(fā)出告警通知。

那么對于這些抖動類指標（如CPU使用率、網(wǎng)卡流量、內(nèi)存使用率、磁盤IO等）產(chǎn)生的告警，可以設(shè)定一些防抖的規(guī)則。如5分鐘內(nèi)產(chǎn)生3次告警，第3次才會成為有效告警進行分派通知，未達標的偶發(fā)告警即被抑制。

5）依賴告警收斂

對于有依賴關(guān)系影響而導(dǎo)致的關(guān)聯(lián)告警事件，如組件安裝/運行于主機、各設(shè)備通過交換機連通網(wǎng)絡(luò)、主機磁盤掛載了存儲提供的存儲盤、虛擬機運行于宿主機或宿主機集群上等，通過配置依賴關(guān)聯(lián)規(guī)則，按照告警之間的依賴關(guān)系，將依賴告警進行收斂。

根據(jù)目前的落地實踐，通過以上五種降噪方案的配置，企業(yè)一般能夠有效收斂60%~80%的告警量。

6）智能化降噪未來展望：

當(dāng)然，在后續(xù)產(chǎn)品能力建設(shè)過程中，還需要考慮如何進一步提升降噪效果，減輕人工配置的工作量同時增強告警智能化降噪的能力。對此我們也可以展望未來的一些建設(shè)發(fā)展方向：

7）智能聚類告警

通過AI人工智能技術(shù)，如NLP算法（自然語言處理Natural Language Processing）、DBSCAN聚類算法，對告警信息進行文本分類聚類、模式發(fā)現(xiàn)，從海量告警中自動化地去學(xué)習(xí)告警之間的關(guān)聯(lián)或相似關(guān)系，然后對相似、相關(guān)的告警進行收斂。

通過有監(jiān)督的機器學(xué)習(xí)能力，結(jié)合人工標記誤告或錯誤收斂的告警，在最小化用戶配置成本的同時，逐步提高智能聚類告警的準確性和可靠性。

對DBSCAN聚類效果演示感興趣的讀者可以在相關(guān)網(wǎng)站深入探索，此處不作進一步展示。

2. 抑制快速恢復(fù)告警

對于一些會在產(chǎn)生告警后幾分鐘又迅速恢復(fù)的告警，不需要立刻分派通知的，可以在緩存一段時間后（可以設(shè)置最大延遲時間如5分鐘，從而保證告警時效性），這段時間內(nèi)未恢復(fù)的告警，再作為有效告警，通知相關(guān)人員處理。

1）告警事件合并

通過一些用戶自定義的合并規(guī)則，將一個時間窗口內(nèi)，多條有關(guān)聯(lián)的告警合并到一起，衍生一條新的告警事件，可以生成一些組合的告警信息，在告警通知信息中，體現(xiàn)合并告警的原因和影響范圍，讓運維人員更有針對性去排查故障。

2）拓撲關(guān)系收斂

通過調(diào)用CMDB拓撲（組件實例間的關(guān)聯(lián)關(guān)系）、APM應(yīng)用拓撲（服務(wù)調(diào)用依賴關(guān)系，如前端應(yīng)用調(diào)用后臺服務(wù)、進程等），根據(jù)完善的拓撲關(guān)系，自動生成依賴收斂規(guī)則，極大減輕手工維護依賴關(guān)系的工作量。