監控系統作為IT運維之眼，在運維管理工作中發揮著重要的作用。而監控報警作為監控系統的主要輸出，在生產故障早期預警、故障定位分析和故障恢復驗證等多個運維場景中提供了技術工具的支撐。

G行上一代監控報警系統使用國外的商業套件，報警采集和報警處理受限于商業套件的單機單線程處理能力，而報警存儲采用的是單機版的內存數據庫。

存在以下問題

•  當出現告警風暴時，采集器可能丟數據，而數據庫也會發生阻塞，導致告警處理效率低下，報警延遲時間達到分鐘級；
•  告警處理邏輯只能支持比較簡單的處理，對于復雜的高并發高頻率的處理，是無法應付的。

解決方案

為解決上述問題，G行新一代監控報警系統基于開源組件進行自主研發，既能滿足海量報警消息的高并發處理及規則靈活配置的要求，又能滿足報警全生命周期的運維管理需求，最終實現監控報警的高效處理。

下文將從報警信息的生命周期管理出發，介紹一下G行新一代監控報警系統規劃與建設。

一、監控報警系統簡介

報警消息的管理我們遵從閉環管理機制，其生命周期可以從產生到恢復的全過程分為報警產生和接入、報警預處理、報警存儲、報警通知和報警恢復后關閉等多個環節。

1、報警生命周期管理

主要目標是為了實現：

•  全面管理、敏捷接入
•  降低延遲、及時通報
•  推薦根因、協助定位
•  跟蹤解決、恢復驗證

2、監控報警系統核心功能

圍繞報警的生命周期管理，監控報警系統的功能框架應包含的主要功能如下：

•  報警接入和預處理：對各種不同來源和協議的報警的原始數據解析為統一的報警記錄；
•  報警豐富：在報警處理過程中根據cmdb等配置信息庫的管理信息，對原始報警的內容進行信息補充和完善的功能；
•  報警維護期：應對日常變更、切換演練以及故障臨時處置等場景下，提前屏蔽相關報警避免無效報警產生干擾；
•  報警壓縮：對于重復發生的報警信息，只記錄報警的首次發生時間、末次發生時間和發生次數，減少報警的記錄數，避免對用戶查看和處理報警造成干擾。報警壓縮的規則一般是由多個報警消息的屬性值組成壓縮因子，可根據不同的報警源和報警內容提前預置壓縮因子的組合規則。常見的壓縮因子包括：IP地址、報警對象、報警類別、報警策略、報警實例等；
•  報警恢復：為了能夠真實反映生產系統運行的故障和恢復的狀態，除了常見的故障外，還有恢復報警的處理和關聯機制。在已報警在監控對象恢復正常運行狀態以后，需要監控工具能夠及時準確的識別恢復的狀態并產生恢復報警到監控報警平臺。報警平臺支持自動進行關聯恢復，即自動找到對應的故障報警，然后進行關聯，并將原報警設置為恢復狀態。關聯的算法可以靈活進行設置，需確保恢復報警的產生時間晚于故障報警；
•  報警定級：報警的定級分為兩個階段，一是默認級別，即根據每個報警原始的嚴重程度定義，二是報警管理系統平臺對多個獨立的報警進行關聯分析，重新定義新的報警級別；
•  根因分析：隨著監控策略的覆蓋度和監控顆粒度的不斷提升，在發生一個生產故障時會從關聯的各個組件、各個層面產生大量報警，因此需要從眾多報警中自動化找出根因的報警，成為報警處理重要目標；
•  報警通知：對于某些重大報警，需要通知給相關的運維人員，采取相應的措施。

二、監控報警系統的關鍵特性

監控報警系統在整個監控體系的作用是接收企業內各類專業監控工具產生的報警消息，其功能定位是報警MOM（Managerof Manager），通過本其定位以及前面的功能說明可以看出，監控報警系統有以下關鍵特性：

•  報警接入范圍很廣：

作為企業級的報警管理中心，是對企業的所有報警作統一的監控管理，報警接入的范圍和監控工具覆蓋的范圍是一致的，從底層的基礎設施、物理服務器、網絡設備、存儲設備、操作系統、云平臺等，到中間件組件、數據庫、WebServer和大數據組件等等，再到上層的業務和應用，如交易、應用等。

•  必須應對報警風暴：

當設備有異常情況出現時，設備可能產生大量的報警，有時會達到每秒幾萬條，而形成報警風暴，當報警接入范圍很廣時，報警風暴可能隨時時不時發生，報警管理中心必須自身必須能應對這種情況，對報警數據進行有效處理。

•  報警處理邏輯復雜：

報警處理分為流處理和批處理，所謂流處理，是指一條報警接入之后過來之后，需要實時經過很多個邏輯處理單元之后才能入庫，而在每個邏輯處理單元里面，都會頻繁地操作告警數據庫，和原有的報警上下文進行關聯分析。無論是告警本身的處理，還是告警數據庫，都存在巨大的性能壓力。所謂批處理，是指定時地對報警庫里面的數據做二次處理，報警處理中心有大量的批處理規則來處理各類不同的報警數據，同樣會對報警處理機和數據庫造成巨大的壓力。

•  處理邏輯靈活配置可擴展：

由于報警接入范圍很廣，報警類型和報文格式復雜多樣，每一類報警的解析不一樣，每一類報警的處理邏輯也不一樣。而且，隨著時間的推移和業務的變化，報警類型會增加，原來的報警處理邏輯也需要隨著運維場景的變化持續改進會變化，因此報警處理規則所以，不可能將報警處理邏輯寫死，而必須做到靈活定義和可擴展高度可配。

上面的四個特性中，前三個合起來產生一個問題，那就是報警管理系統中心高性能的問題。

第四個特性是報警管理系統規則靈活配置的問題，那如何解決高性能和高可配的問題呢？

三、監控報警系統的關鍵技術實現設計

G行新一代上一代監控報警系統使用國外的商業套件，報警采集和報警處理都是采用的單機單線程處理，而報警存儲采用的是單機版的內存數據庫。

存在的問題是為解決告警風暴、高頻報警的問題，而我們：

當出現告警風暴時，采集器可能丟數據，而數據庫也會發生阻塞，導致告警處理效率低下，報警延遲時間達到分鐘級。

告警處理邏輯只能支持比較簡單的處理，對于復雜的高并發高頻率的處理，是無法應付的。

為解決上述問題，G行新一代監控報警系統基于開源組件進行自主研發，從報警采集、處理和入庫三大關鍵環節入手，解決報警高性能和規則高可配的問題的。

其中主要的關鍵設計包括報警采集器的設計、分布式服務框架的引入和分布式數據庫的選型和適配處理引擎和后面的幾點對上。結合需求和技術約束，監控報警的整體框架為：

1、以Akka并行框架為基礎解決報警采集高性能問題

由于報警接入范圍很廣，采集器需要接收各種數據報文，當產生報警風暴時，必須要并行接收和預處理各種報警，才能使報警得到及時處理；采集器以Akka并行框架為基礎實現。

Akka是Java虛擬機平臺上構建的高并發、分布式和容錯應用的工具包和運行時。Akka用Scala語言編寫，同時提供了Scala和Java的開發接口。Akka處理并發的方法基于Actor模型，Actor之間通信的唯一機制就是消息傳遞。

其最大優勢是消息發送者與已經發送的消息解耦，允許異步通信同時又滿足消息傳遞模式的控制結構。以Akka為基礎的報警采集器架構如下：

各層次作用說明如下：

•  數據采集Actor：原始數據采集，或者主動采集，或者被動接收，不同類型的數據有一個Actor采集，對于主動采集的Actor，采用輪詢的方式，定時采集數據；
•  原始數據分發Actor：所有采集到的原始數據都會發送到原始數據分發Actor，由它來分發到數據分析Actor，同時，這個Actor可以對原始數據做整體調度控制；
•  數據分析Actor：這是一組Actor，采集器主要業務處理和資源消耗的組件，可靈活配置Actor的并發個數;
•  持久化數據分發Actor：所有需要持久化的數據都發送到這個Actor，它對需要持久化的數據分發到持久化Actor，同時對持久化數據做整體的控制，比如數據庫有問題或網絡有問題，導致持久化無法進行或很慢，可以控制實現背壓；
•  數據持久化Actor：這是一組Actor，對數據進行持久化，Actor個數可以配置，采集器的IO主要消耗者。

2、  以Apache Dubbo分布式框架為基礎解決報警處理高性能問題

新一代監控報警系統，以ApacheDubbo分布式框架為基礎搭建分布式處理集群，集群的每一個節點都并行處理報警，當未來報警規模擴大時，集群的節點可以水平擴充，當集群的處理能力有冗余時，宕掉一個或多個節點不影響報警處理。

Apache Dubbo是一款高性能、輕量級的開源JavaRPC框架，它提供了三大核心能力：面向接口的遠程方法調用，智能容錯和負載均衡，以及服務的自動注冊和發現。為了保證集群本身的高可用，還可以搭建備集群，主備集群之間的數據可以實時同步。

在報警處理集群中，實現了兩個Dubbo服務：

•  數據處理服務：提供了數據的增、刪、改、查接口，用于采集器(EPP)調用和其它應用調用，采集器用來發送數據給報警處理集群進一步處理，如告警壓縮、告警恢復等，其它應用用來查詢和操作告警，如刪除、接管等；
•  數據同步服務：集群數據同步服務，提供數據的定時備份接口和增量備份接口，用于從主集群同步數據多備集群，備集群可以是多個。

Dubbo服務的調用關系如下圖所示：

處理節點的內部邏輯架構為：

3、處理邏輯APP化解決高可配問題

由于報警處理邏輯復雜多變，所以報警處理集群的每一個處理節點都設計成一個報警處理APP容器，一個報警處理APP是指一個邏輯功能部件，用來處理某一類業務，比如進維護期、事件豐富、事件通知等等，APP容器具有以下特點：

•  報警處理APP采用熱拔插方式。當APP數量很大導致，容器資源不夠時，可以通過水平擴張集群節點解決；
•  報警處理APP的開發可以用系統提供的腳本開發，也可以用scala或java開發，對于腳本開發的APP，容器采用Antlr進行語法分析，翻譯成Java代碼，然后用Java動態編譯技術編譯成字節碼運行，以提高處理速度；
•  優雅停啟：當更新一個APP時，它正在處理的數據會處理完畢才自動停止，需要馬上處理的數據由新的APP處理，即新老APP可能有一個重疊的時間在同時運行。

報警處理APP有以下類型：

•  流APP：在每一個處理節點上都運行的APP，處理實時報警，如果一個報警符合此APP的條件，則運行此APP邏輯；
•  調度型批APP：由報警處理集群的調度引擎將這類APP分布在不同的節點上運行，每個APP只有一個實例，定時從報警庫中取一批特定的報警進行處理。
•  訂閱型批APP：由報警處理集群的調度引擎將這類APP分布在不同的節點上運行，每APP只有一個實例，從流APP或調度型批APP訂閱數據，進行統一集中處理；
•  廣播型批APP：在每一個節點都運行的批處理APP，事件來源為某個調度型APP分配的數據，起到分布式處理的作用；
•  Restful APP：動態生成Restful接口的APP，以便訪問APP的內部數據。

4、 Apache Ignite分布式存儲解決存儲高性能問題

由于報警數據量大報警會不時產生風暴、每一條告警處理過程中會大量的讀寫報警庫，所以需要一個分布式內存數據庫作為報警庫。

因為常見以往的如MySQL、Oracle磁盤型關系數據庫，在這樣高頻度訪問和復雜邏輯處理下，無法滿足監控報警系統高并發讀寫的需求，而采用單機版的內存數據庫，在報警風暴的時候，同樣會產生報警庫癱瘓的問題。

在G行新一代報警系統開發和建設時，采用分布式內存數據庫ApacheIgnite存儲告警，可以將訪問和邏輯處理分離并且在多節點內存中進行并行處理，所以性能完全能滿足實際需求。

報警處理引擎對Ignite的使用如下：

•  持久化數據(SQL方式存取)：活動告警、歷史告警、通知歸檔、配置數據；
•  緩存數據(key-value方式存取)：定時從其它應用查詢資源數據，如用于豐富的MO、用于事件預處理的Lookup數據；
•  內存分區(5個節點，每個節點總內存128G)：活動庫16G，資源8G，歷史庫：52G，通知庫：16G；
•  事務方式：告警處理幾乎沒有需要ACID強一致性保證，并且告警庫訪問頻繁，為提高性能，配置為ATOMIC方式，即保證單個數據操作的一致性，當遇到更新沖突時，重復執行此更新操作直至成功。

5、實現效果

G行現已在生產環境實際部署了自主研發的報警處理系統，進行功能和性能驗證。關鍵運行指標經測試如下：

•  活動庫報警數量：最高可達千萬級報警數據，是原有商業套件存儲能力的200倍；
•  歷史庫數量：最高可歸檔存儲億級數據；
•  寫入TPS：存1000萬平均速度，11653條/s，是原有商業套件的10倍；
•  報警處理延遲：100毫秒以內，性能提升30-50倍以上；
•  擴展性：每增加1臺服務器，寫入速度提升：2000條/s。

通過此次新一代監控報警系統的部署，G行的監控管理平臺實現全部組件的開源和自主可控，大幅度提升了報警處理的效率，減少了報警處理延遲時間。

四、未來展望

通過自研監控報警系統，提升了平臺整體報警的處理能力和管理規則的可定制化能力，為后續提升報警智能分析能力打下了數據和處理能力層面的技術基礎。

未來，優化和改進的方向包括：

•  報警接入方面：基于微服務的理念，提供企業級的監控報警接入服務。技術上提供webhook等事件集成接口，更加簡便、友好的接收應用程序內部推送的各類報警信息，并且提升報警接口的管理能力；
•  報警處理能力方面：需要加強報警分析能力，尤其是大規模報警的情況下報警根因的定向和定位能力，提升運用AI算法解決報警壓縮和收斂的能力；
•  報警展示和關聯：提升報警與性能數據、配置數據的關聯能力，在閱讀報警時能夠同步了解到故障點KPI快照、指標趨勢分析、變更切換操作等相關的運維數據信息，提升故障處置效率，縮短故障影響的時間。