近些年信息化數字化的浪潮下，企業的IT資產和線上業務的規模迅速增長，而為了維護其穩定性和服務質量，所需耗費的成本、精力也在逐年攀升。

在此背景下，告警治理根本目標就是能夠實現快速響應和解決故障，減少故障發生率和業務影響范圍，而這一環節中，不可避免地會遇到諸如以下的典型問題：

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

……

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

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

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

通常情況下很難有大而全的監控系統能夠同時囊括服務器、網絡、數據庫中間件、存儲、應用系統、日志、機房動環等多種IT資產/業務系統的監控訴求。因此，大部分企業都會建設多套監控系統以應對不同的業務需求。但這樣的煙囪式架構，存在重復建設、數據難互通、維護成本高等問題。

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

• 多種靈活匯集方式，統一管理告警

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

• 低門檻在線拓展能力，保障持續發展

企業在業務發展的同時，也伴隨著新的系統的引入和建設，告警系統需要具備拓展性，以應對未來的業務需求。

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

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

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

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

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

• 快速同步告警狀態，避免重復操作

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

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

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

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

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

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

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

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

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

1. CMDB豐富

上文我們提到，當第三方監控系統的告警信息比較簡陋，并不包含用戶分析和處理告警事件所需的全部信息時，用戶還需要根據告警中的IP地址等信息，在CMDB中手動查詢需要的內容，兩相對照才可完成進一步的處理。

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

下圖為典型示例，當主機發生告警時，將主機的各項配置信息顯示在告警內。

當然，配置告警字段和CMDB實例屬性信息的映射規則，生效的前提是告警可以找到唯一的實例。對于沒有和CMDB關聯的第三方監控系統，可以通過配置CMDB關聯規則來實現：根據告警字段和CMDB則能夠根據告警內容中正則提取的IP地址和CMDB中的內網IP屬性值進行比對，以準確找到唯一對應的實例，從而實現后續的字段信息豐富。

實際效果如下所示：

2. 常規豐富

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

1）字符替換

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

2）字符提取

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

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

3）字段調整

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

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

4）自定義應用范圍

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

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

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

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

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

另外經常忽略低等級告警信息，就不能及時發現故障前兆，而當致命故障發生時，處理難度會更大，也對業務服務和終端用戶造成更大范圍的影響。

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

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

1. 常見“無效告警”：

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

2. 對應的制定告警降噪的方案：

1）時間屏蔽

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

2）告警去重

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

收斂同時累加活動告警的“告警計數”，并將被收斂的告警和對應的活動告警進行關聯。

3）關聯聚合

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

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

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

4）告警防抖

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

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

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

5）依賴告警收斂

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

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

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

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

7）智能聚類告警

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

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

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

2. 抑制快速恢復告警

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

1）告警事件合并

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

2）拓撲關系收斂

通過調用CMDB拓撲（組件實例間的關聯關系）、APM應用拓撲（服務調用依賴關系，如前端應用調用后臺服務、進程等），根據完善的拓撲關系，自動生成依賴收斂規則，極大減輕手工維護依賴關系的工作量。