億級高併發系統的監控與報警

什麼是系統監控

對於功能簡單，用戶量較少的軟件系統，大部分公司不須要額外的監控系統來保證公司業務的正常運行。而當公司發展到必定程度，系統愈來愈多元化，單一系統也愈來愈複雜，面對的用戶數量愈來愈多。爲了能實時保證系統的正常與穩定和對外業務的實時監控，大部分互聯網公司都會根據本身的系統架構和業務級別來設計並開發一套監控系統，例如阿里巴巴的＂鷹眼＂系統。

 

個巡 - 個推系統監控

隨着個推業務的不斷擴展，用戶量不斷的增長，個推急需一套完整的監控系統來實時保證系統和業務的正常運轉。系統層面上，個推必須保證上億用戶在同時接入時的系統穩定和正常，業務層面上，個推須要經過實時數據來反應天天的業務增加和降低，個巡就是在這時孕育而生了。

 

系統難點與設計

多元化的數據

基於推送業務，個推擴展出許多獨立運行的系統，並且每一個系統的監控數據也不同。爲了保證系統的穩定和可擴展性，咱們將全部數據來源分紅了兩類：一類爲基於JMX的可配置型數據，另外一類爲獨立封裝的接入型數據，基於兩種數據的特性，JMX數據設計爲去主動收集，獨立封裝數據設計爲被動接收。

龐大的節點分佈

面對大量的用戶，個推須要佈置許多節點在不一樣的地域以保證業務的實時性。面對大量的節點，併發型的數據收集和接收設計是惟一方案，而且基於不一樣的數據來源咱們也須要封裝不一樣類型的線程和線程池，但大量多線程併發的帶來的另外一難點就是，共享資源的設計與分配，原子操做的保證與回滾，以及數據收集的準確性。基於此難點，代碼結構上採用Producer-Consumer模式，以及進程與線程的設計思路。

複雜的業務邏輯

監控系統的另外一功能就是能實時反應出公司業務的發展趨勢並及時報警，爲了保證個推的每一項決策都能反應在用戶量與業務量上，咱們的監控系統收集了大量的系統接入以及不一樣種類請求的數據。基於這些數據，許多分析策略和報警策略須要寫入程序，所以使得業務邏輯異常複雜，動態的加載不一樣策越，Strategy 設計模式成爲不二選擇．

實時性的需求

監控系統的一大特性就是可以及時對異常數據進行報警，以及對大量數據的秒級收集，分類，分析和展現。所以，內存數據庫(couchbase)和數據搜索引擎(elasticsearch)成爲保證系統實時性的關鍵性中間鍵。

系統層面上，集成了包括Database, couchbase, elasticsearch, flume, kafka等一系列外部工具。

代碼層面上經過試用不一樣的設計模式來幫助整套系統可以更好的兼容不一樣的數據，保證系統的穩定運行和數據的準確抓取和展現。

 

個巡的特色

異常日誌報警

當系統有異常日誌時， 會實時同步到個巡的ES。個巡一旦監控到有異常日誌時，就會立刻發告警信息給相應人員。這樣咱們會實時收到系統異常的問題，爲及時處理線上的問題提供了必要條件。

 

週期性的比較

對於某些監控點，天天都應該有一個固定的趨勢，以下圖所示。咱們經過前7天的數據更新這個趨勢，當線上數據不符合這個趨勢的時候，就發告警信息。

 

自監控

個巡是用來監控線上系統的，而個巡也是線上系統的一部分，那麼個巡怎麼作到本身監控本身呢？咱們使用自動修改閥值的方式作到自監控。當修改閥值後，個巡會發送告警郵件，而後10分鐘後再把閥值改爲原來的樣子，而後咱們會收到恢復正常的郵件，而且整個過程是自動。因此當咱們收不到自告警的郵件時，個巡自己就有問題了。

開發總結

相信不少項目都會遇到以上所提到的四種問題。實時上不少系統在開發的緊張過程當中也難以從全局去審視和總結一些問題或經驗，在這裏咱們僅提供其中一個視角去分析一個龐大的系統：當數據來源多元化的時候，開發人員務必保證在全部數據進入系統業務邏輯前的統一性，也就是常見的數據封裝，這樣才能保證在多變的需求環境下系統核心模塊的穩定性；龐大的數據節點所帶來的主要問題則爲數據流的穩定性，所以在數據流傳入和接受之間加入一層(也就是此係統的Producer-Consumer)來保證數據流的穩定性和可控性變得異常重要。複雜的業務邏輯是軟件開發中最多見的問題，不少經典書籍都專門討論過。但實際開發中，也別是開發週期較緊迫的時候，很難有一套具體且通行的解決方案，在個巡的開發中，咱們也只能根據需求和業務邏輯來制訂Strategy代碼框架，實時性經常會由於數據量的增大而受到印象，在個巡的開發中咱們採用的原則是數據分開存儲，而後在根據不一樣的數據應用採用不一樣的數據庫。