銀行監控報警系統性能提高50倍，用的全是開源組件

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

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

存在如下問題

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

•  告警處理邏輯只能支持比較簡單的處理，對於複雜的高併發高頻率的處理，是沒法應付的。

解決方案

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

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

1、監控報警系統簡介

報警消息的管理咱們聽從閉環管理機制，其生命週期能夠從產生到恢復的全過程分爲報警產生和接入、報警預處理、報警存儲、報警通知和報警恢復後關閉等多個環節。

一、報警生命週期管理

主要目標是爲了實現：

•  全面管理、敏捷接入

•  下降延遲、及時通報

•  推薦根因、協助定位

•  跟蹤解決、恢復驗證

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

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

•  報警接入和預處理：對各類不一樣來源和協議的報警的原始數據解析爲統一的報警記錄；

•  報警豐富：在報警處理過程當中根據cmdb等配置信息庫的管理信息，對原始報警的內容進行信息補充和完善的功能；

•  報警維護期：應對平常變動、切換演練以及故障臨時處置等場景下，提早屏蔽相關報警避免無效報警產生干擾；

•  報警壓縮：對於重複發生的報警信息，只記錄報警的首次發生時間、末次發生時間和發生次數，減小報警的記錄數，避免對用戶查看和處理報警形成干擾。報警壓縮的規則通常是由多個報警消息的屬性值組成壓縮因子，可根據不一樣的報警源和報警內容提早預置壓縮因子的組合規則。常見的壓縮因子包括：IP地址、報警對象、報警類別、報警策略、報警實例等；

•  報警恢復：爲了可以真實反映生產系統運行的故障和恢復的狀態，除了常見的故障外，還有恢復報警的處理和關聯機制。在已報警在監控對象恢復正常運行狀態之後，須要監控工具可以及時準確的識別恢復的狀態併產生恢復報警到監控報警平臺。報警平臺支持自動進行關聯恢復，即自動找到對應的故障報警，而後進行關聯，並將原報警設置爲恢復狀態。關聯的算法能夠靈活進行設置，需確保恢復報警的產生時間晚於故障報警；

•  報警定級：報警的定級分爲兩個階段，一是默認級別，即根據每一個報警原始的嚴重程度定義，二是報警管理系統平臺對多個獨立的報警進行關聯分析，從新定義新的報警級別；

•  根因分析：隨着監控策略的覆蓋度和監控顆粒度的不斷提高，在發生一個生產故障時會從關聯的各個組件、各個層面產生大量報警，所以須要從衆多報警中自動化找出根因的報警，成爲報警處理重要目標；

•  報警通知：對於某些重大報警，須要通知給相關的運維人員，採起相應的措施。

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

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

•  報警接入範圍很廣：

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

•  必須應對報警風暴：

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

•  報警處理邏輯複雜：

報警處理分爲流處理和批處理，所謂流處理，是指一條報警接入以後過來以後，須要實時通過不少個邏輯處理單元以後才能入庫，而在每一個邏輯處理單元裏面，都會頻繁地操做告警數據庫，和原有的報警上下文進行關聯分析。不管是告警自己的處理，仍是告警數據庫，都存在巨大的性能壓力。所謂批處理，是指定時地對報警庫裏面的數據作二次處理，報警處理中心有大量的批處理規則來處理各種不一樣的報警數據，一樣會對報警處理機和數據庫形成巨大的壓力。

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

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

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

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

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

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

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

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

告警處理邏輯只能支持比較簡單的處理，對於複雜的高併發高頻率的處理，是沒法應付的。

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

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

一、以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主要消耗者。

二、  以Apache Dubbo分佈式框架爲基礎解決報警處理高性能問題

新一代監控報警系統，以ApacheDubbo分佈式框架爲基礎搭建分佈式處理集羣，集羣的每個節點都並行處理報警，當將來報警規模擴大時，集羣的節點能夠水平擴充，當集羣的處理能力有冗餘時，宕掉一個或多個節點不影響報警處理。

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

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

•  數據處理服務：提供了數據的增、刪、改、查接口，用於採集器(EPP)調用和其它應用調用，採集器用來發送數據給報警處理集羣進一步處理，如告警壓縮、告警恢復等，其它應用用來查詢和操做告警，如刪除、接管等；

•  數據同步服務：集羣數據同步服務，提供數據的定時備份接口和增量備份接口，用於從主集羣同步數據多備集羣，備集羣能夠是多個。

Dubbo服務的調用關係以下圖所示：

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

三、處理邏輯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的內部數據。

四、 Apache Ignite分佈式存儲解決存儲高性能問題

因爲報警數據量大報警會不時產生風暴、每一條告警處理過程當中會大量的讀寫報警庫，因此須要一個分佈式內存數據庫做爲報警庫。

由於常見以往的如MySQL、Oracle磁盤型關係數據庫，在這樣高頻度訪問和複雜邏輯處理下，沒法知足監控報警系統高併發讀寫的需求，而採用單機版的內存數據庫，在報警風暴的時候，一樣會產生報警庫癱瘓的問題。

在G行新一代報警系統開發和建設時，採用分佈式內存數據庫ApacheIgnite存儲告警，能夠將訪問和邏輯處理分離而且在多節點內存中進行並行處理，因此性能徹底能知足實際需求。

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

•  持久化數據(SQL方式存取)：活動告警、歷史告警、通知歸檔、配置數據；

•  緩存數據(key-value方式存取)：定時從其它應用查詢資源數據，如用於豐富的MO、用於事件預處理的Lookup數據；

•  內存分區(5個節點，每一個節點總內存128G)：活動庫16G，資源8G，歷史庫：52G，通知庫：16G；

•  事務方式：告警處理幾乎沒有須要ACID強一致性保證，而且告警庫訪問頻繁，爲提升性能，配置爲ATOMIC方式，即保證單個數據操做的一致性，當遇到更新衝突時，重複執行此更新操做直至成功。

五、實現效果

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

•  活動庫報警數量：最高可達千萬級報警數據，是原有商業套件存儲能力的200倍；

•  歷史庫數量：最高可歸檔存儲億級數據；

•  寫入TPS：存1000萬平均速度，11653條/s，是原有商業套件的10倍；

•  報警處理延遲：100毫秒之內，性能提高30-50倍以上；

•  擴展性：每增長1臺服務器，寫入速度提高：2000條/s。

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

4、將來展望

經過自研監控報警系統，提高了平臺總體報警的處理能力和管理規則的可定製化能力，爲後續提高報警智能分析能力打下了數據和處理能力層面的技術基礎。

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

•  報警接入方面：基於微服務的理念，提供企業級的監控報警接入服務。技術上提供webhook等事件集成接口，更加簡便、友好的接收應用程序內部推送的各種報警信息，而且提高報警接口的管理能力；

•  報警處理能力方面：須要增強報警分析能力，尤爲是大規模報警的狀況下報警根因的定向和定位能力，提高運用AI算法解決報警壓縮和收斂的能力；

•  報警展現和關聯：提高報警與性能數據、配置數據的關聯能力，在閱讀報警時可以同步瞭解到故障點KPI快照、指標趨勢分析、變動切換操做等相關的運維數據信息，提高故障處置效率，縮短故障影響的時間。 

【編輯推薦】

1. 設備監控是保證物聯網安全的關鍵

2. 完善的前端異常監控解決方案

3. AI隱形衣：穿上這件連帽衫，監控算法對你「視而不見」

4. Linux運維之，關閉終端，程序後臺運行，我有5種方法你呢？

5. 部署Prometheus監控平臺，應該考慮6個因素，缺一不可

【責任編輯：龐桂玉 TEL：（010）68476606】