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

系統難點與設計

多元化的數據
基於推送業務，個推擴展出許多獨立運行的系統，而且每個系統的監控數據也不一樣。為了保證系統的穩定和可擴展性，我們將所有數據來源分成了兩類：一類為基於JMX的可配置型數據，另一類為獨立封裝的接入型數據，基於兩種數據的特性，JMX數據設計為去主動收集，獨立封裝數據設計為被動接收。

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

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

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

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

個巡的特點

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

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

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

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

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