http://www.infoq.com/cn/articles/alibaba-core-business-monitoring-platform-sunfire

在2016年雙11全球購物狂歡節中，天貓全天交易額1207億元，前30分鐘每秒交易峰值17.5萬筆，每秒支付峰值12萬筆。承載這些秒級數據背后的監控產品是如何實現的呢？接下來本文將從阿里監控體系、監控產品、監控技術架構及實現分別進行詳細講述。

阿里有眾多監控產品，且各產品分工明確，百花齊放。整個阿里監控體系如下圖：

集團層面的監控，以平臺為主，全部為阿里自主研發（除引入了第三方基調、博睿等外部檢測系統，用于各地CDN用戶體驗監控），這些監控平臺覆蓋了阿里集團80%的監控需求。

此外，每個事業群均根據自身特性自主研發了多套監控系統，以滿足自身特定業務場景的監控需求，如廣告的GoldenEye、菜鳥的棱鏡、阿里云的天基、螞蟻的金融云（基于XFlush）、中間件的EagleEye等，這些監控系統均有各自的使用場景。

阿里的監控規模早已達到了千萬量級的監控項，PB級的監控數據，億級的報警通知，基于數據挖掘、機器學習等技術的智能化監控將會越來越重要

阿里全球運行指揮中心（GOC）基于歷史監控數據，通過異常檢測、異常標注、挖掘訓練、機器學習、故障模擬等方式，進行業務故障的自動化定位，并賦能監控中心7*24小時專業監控值班人員，使阿里集團具備第一時間發現業務指標異常，并快速進行應急響應、故障恢復的能力，將故障對線上業務的影響降到最低。

接下來將詳細講述本文的主角，承載阿里核心業務監控的SunFire監控平臺。

SunFire簡介

SunFire是一整套海量日志實時分析解決方案，以日志、REST 接口、Shell 腳本等作為數據采集來源，提供設備、應用、業務等各種視角的監控能力，從而幫您快速發現問題、定位問題、分析問題、解決問題，為線上系統可用率提供有效保障。

SunFire利用文件傳輸、流式計算、分布式文件存儲、數據可視化、數據建模等技術，提供實時、智能、可定制、多視角、全方位的監控體系。其主要優勢有：

• 全方位實時監控：提供設備、應用、業務等各種視角的監控能力，關鍵指標秒級、普通指標分鐘級，高可靠、高時效、低延遲。
• 靈活的報警規則：可根據業務特征、時間段、重要程度等維度設置報警規則，實現不誤報、不漏報。
• 管理簡單：分鐘級萬臺設備的監控部署能力，故障自動恢復，集群可伸縮
• 自定義便捷配置：豐富的自定義產品配置功能，便捷、高效的完成產品配置、報警配置。
• 可視化：豐富的可視化 Dashboard，幫助您定制個性化的監控大盤。
• 低資源占用：在完成大量監控數據可靠傳輸的同時，保證對宿主機的 CPU、內存等資源極低占用率。

Sunfire技術架構如下：

(點擊放大圖像)

主要模塊實現及功能

針對架構圖中的各個組件，其中最關鍵的為采集（Agent）、計算（Map、Reduce）組件，接下來將對這兩個組件進行詳細介紹。

1. 采集

Agent負責所有監控數據的原始采集，它以 Agent 形式部署在應用系統上，負責原始日志的采集、系統命令的執行。日志原始數據的采集，按周期查詢日志的服務，且日志查詢要低耗、智能。Agent上不執行計算邏輯。主要具有以下特點：

低耗

采集日志，不可避免要考慮日志壓縮的問題，通常做日志壓縮則意味著它必須做兩件事情：一是磁盤日志文件的內容要讀到應用程序態；二是要執行壓縮算法。

這兩個過程就是CPU消耗的來源。但是它必須做壓縮，因為日志需要從多個機房傳輸到集中的機房。跨機房傳輸占用的帶寬不容小覷，必須壓縮才能維持運轉。所以低耗的第一個要素，就是避免跨機房傳輸。SunFire達到此目標的方式是運行時組件自包含在機房內部，需要全量數據時才從各機房查詢合并。

網上搜索zero-copy，會知道文件傳輸其實是可以不經過用戶態的，可以在Linux的核心態用類似DMA的思想，實現極低CPU占用的文件傳輸。SunFire的Agent當然不能放過這個利好，對它的充分利用是Agent低耗的根本原因。以前這部分傳輸代碼是用c語言編寫的sendfile邏輯，集成到Java工程里，后來被直接改造為了Java實現。

最后，在下方的計算平臺中會提到，要求Agent的日志查詢服務具備“按周期查詢日志”的能力。這是目前Agent工程里最大的難題，我們都用過RAF（RandomAccessFile），你給它一個游標，指定offset，再給它一個長度，指定讀取的文件size，它可以很低耗的扒出文件里的這部分內容。然而問題在于：周期≠offset。從周期轉換為offset是一個痛苦的過程。

在流式計算里一般不會遇到這個問題，因為在流式架構里，Agent是水龍頭，主動權掌握在Agent手里，它可以從0開始push文件內容，push到哪里就做一個標記，下次從標記繼續往后push，不斷重復。這個標記就是offset，所以流式不會有任何問題。

而計算平臺周期任務驅動架構里，pull的方式就無法提供offset，只能提供Term（周期，比如2015-11-11 00:00分）。Agent解決此問題的方式算是簡單粗暴，那就是二分查找法。而且日志還有一個天然優勢，它是連續性的。所以按照對二分查找法稍加優化，就能達到“越猜越準”的效果（因為區間在縮小，區間越小，它里面的日志分布就越平均）。

于是，Agent代碼里的LogFinder組件撐起了這個職責，利用上述兩個利好，實現了一個把CPU控制在5%以下的算法，目前能夠維持運轉。其中CPU的消耗不用多說，肯定是來自于猜的過程，因為每一次猜測，都意味著要從日志的某個offset拉出一小段內容來核實，會導致文件內容進入用戶態并解析。這部分算法依然有很大的提升空間。

日志滾動

做過Agent的同學肯定都被日志滾動困擾過，各種各樣的滾動姿勢都需要支持。SunFire的pull方式當然也會遇到這個問題，于是我們簡單粗暴的窮舉出了某次pull可能會遇到的所有場景，比如：

• 正常猜到了offset

• 整個日志都猜不到offset

• 上次猜到了offset，但是下次再來的時候發現不對勁（比如滾動了）

這段邏輯代碼窮舉的分支之多，在一開始誰都沒有想到。不過仔細分析了很多次，發現每個分支都必不可少。

查詢接口

Agent提供的查詢服務分為first query和ordinary query兩種。做這個區分的原因是：一個周期的查詢請求只有第一次需要猜offset，之后只需要順序下移即可。而且計算組件里有大量的和Agent查詢接口互相配合的邏輯，比如一個周期拉到什么位置上算是確定結束？一次ordinary query得到的日志里如果末尾是截斷的（只有一半）該如何處理…… 這些邏輯雖然縝密，但十分繁瑣，甚至讓人望而卻步。但現狀如此，這些實現邏輯保障了SunFire的高一致性，不用擔心數據不全、報警不準，隨便怎么重啟計算組件，隨便怎么重啟Agent。但這些優勢的背后，是值得深思的代碼復雜度。

路徑掃描

為了讓用戶配置簡單便捷，SunFire提供給用戶選擇日志的方式不是手寫，而是像windows的文件夾一樣可以瀏覽線上系統的日志目錄和文件，讓他雙擊一個心儀的文件來完成配置。但這種便捷帶來的問題就是路徑里若有變量就會出問題。所以Agent做了一個簡單的dir掃描功能。Agent能從應用目錄往下掃描，找到同深度文件夾下“合適”的目標日志。

2. 計算

由Map、Reduce組成計算平臺，負責所有采集內容的加工計算，具備故障自動恢復能力及彈性伸縮能力。計算平臺一直以來都是發展最快、改造最多的領域，因為它是很多需求的直接生產者，也是性能壓力的直接承擔者。因此，在經過多年的反思后，最終走向了一條插件化、周期驅動、自協調、異步化的道路。主要具有以下幾個特點：

純異步

原來的SunFire計算系統里，線程池繁復，從一個線程池處理完還會丟到下一個線程池里；為了避免并發bug，加鎖也很多。這其中最大的問題有兩個：CPU密集型的邏輯和I/O密集型混合。

對于第一點，只要發生混合，無論你怎么調整線程池參數，都會導致各式各樣的問題。線程調的多，會導致某些時刻多線程搶占CPU，load飆高；線程調的少，會導致某些時刻所有線程都進入阻塞等待，堆積如山的活兒沒人干。

對于第二點，最典型的例子就是日志包合并。比如一臺Map上的一個日志計算任務，它要收集10個Agent的日志，那肯定是并發去收集的，10個日志包陸續（同時）到達，到達之后各自解析，解析完了data要進行merge。這個merge過程如果涉及到互斥區（比如嵌套Map的填充），就必須加鎖，否則bug滿天飛。

但其實我們重新編排一下任務就能杜絕所有的鎖。比如上面的例子，我們能否讓這個日志計算任務的10個Agent的子任務，全部在同一個線程里做？這當然是可行的，只要回答兩個問題就行：

• 如果串行，那10個I/O動作（拉日志包）怎么辦？串行不就浪費cpu浪費時間嗎？
• 把它們都放到一個線程里，那我怎么發揮多核機器的性能？

第一個問題，答案就是異步I/O。只要肯花時間，所有的I/O都可以用NIO來實現，無鎖，事件監聽，不會涉及阻塞等待。即使串行也不會浪費CPU。第二個問題，就是一個大局觀問題了。現實中我們面臨的場景往往是用戶配置了100個產品，每個產品都會拆解為子任務發送到每臺Map，而一臺Map只有4個核。所以，你讓一個核負責25個任務已經足夠榨干機器性能了，沒必要追求更細粒度子任務并發。因此，計算平臺付出了很大的精力，做了協程框架。

我們用Akka作為協程框架，有了協程框架后再也不用關注線程池調度等問題了，于是我們可以輕松的設計協程角色，實現CPU密集型和I/O密集型的分離、或者為了無鎖而做任務編排。接下來，盡量用NIO覆蓋所有的I/O場景，杜絕I/O密集型邏輯，讓所有的協程都是純跑CPU。按照這種方式，計算平臺已經基本能夠榨干機器的性能。

周期驅動

所謂周期驅動型任務調度，說白了就是Map/Reduce。Brain被選舉出來之后，定時撈出用戶的配置，轉換為計算作業模型，生成一個周期（比如某分鐘的）的任務, 我們稱之為拓撲(Topology), 拓撲也很形象的表現出Map/Reduce多層計算結構的特征。所有任務所需的信息，都保存在topology對象中，包括計算插件、輸入輸出插件邏輯、Map有幾個、每個Map負責哪些輸入等等。這些信息雖然很多，但其實來源可以簡單理解為兩個：一是用戶的配置；二是運維元數據。拓撲被安裝到一臺Reduce機器（A）上。

A上的Reduce任務判斷當前集群里有多少臺Map機器，就產生多少個任務（每個任務被平均分配一批Agent），這些任務被安裝到每臺機器上Map。被安裝的Map任務其實就是一個協程，它負責了一批Agent，于是它就將每個Agent的拉取任務再安裝為一個協程。至此，安裝過程結束。Agent拉取任務協程（也稱之為input輸入協程，因為它是數據輸入源）在周期到點后，開始執行，拉取日志，解析日志，將結果交予Map協程；Map協程在得到了所有Agent的輸入結果并merge完成后，將merge結果回報到Reduce協程（這是一個遠程協程消息，跨機器）；Reduce協程得到了所有Map協程的匯報結果后，數據到齊，寫入到Hbase存儲，結束。

上述過程非常簡單，不高不大也不上，但經過多年大促的考驗，其實非常的務實。能解決問題的架構，就是好的架構，能簡單，為何要把事情做得復雜呢？

這種架構里，有一個非常重要的特性：任務是按周期隔離的。也就是說，同一個配置，它的2015-11-11 00:00分的任務和2015-11-11 00:01分的任務，是兩個任務，沒有任何關系，各自驅動，各自執行。理想情況下，我們可以做出結論：一旦某個周期的任務結束了，它得到的數據必然是準確的（只要每個Agent都正常響應了）。所以采用了這種架構之后，SunFire很少再遇到數據不準的問題，當出現業務故障的時候我們都可以斷定監控數據是準確的，甚至秒級都可以斷定是準確的，因為秒級也就是5秒為周期的任務，和分鐘級沒有本質區別，只是周期范圍不同而已。能獲得這個能力當然也要歸功于Agent的“按周期查詢日志”的能力。

任務重試

在上節描述的Brain->Reduce->Map的任務安裝流程里，我們對每一個上游賦予一個職責：監督下游。當機器發生重啟或宕機，會丟失一大批協程角色。每一種角色的丟失，都需要重試恢復。監督主要通過監聽Terminated事件實現，Terminated事件會在下游掛掉(不論是該協程掛掉還是所在的機器掛掉或是斷網等)的時候發送給上游。由于拓撲是提前生成好且具備完備的描述信息，因此每個角色都可以根據拓撲的信息來重新生成下游任務完成重試。

• 若Brain丟失，則Brain會再次選主, Brain讀取最后生成到的任務周期, 再繼續生成任務。

• 若Reduce丟失，每個任務在Brain上都有一個TopologySupervisor角色, 來監聽Reduce協程的Terminated事件來執行重試動作。

• 若Map丟失，Reduce本身也監聽了所有Map的Terminated事件來執行重試動作。

• 為確保萬無一失，若Reduce沒有在規定時間內返回完成事件給Brain，Brain同樣會根據一定規則重試這個任務。

過程依然非常簡單，而且從理論上是可證的，無論怎么重啟宕機，都可以確保數據不丟，只不過可能會稍有延遲（因為部分任務要重新做）。

輸入共享：在用戶實際使用SunFire的過程中，常常會有這樣的情況：用戶配了幾個不同的配置，其計算邏輯可能是不同的，比如有的是單純計算行數，有的計算平均值，有的需要正則匹配出日志中的內容，但這幾個配置可能都用的同一份日志，那么一定希望幾個配置共享同一份拉取的日志內容。否則重復拉取日志會造成極大的資源消耗。那么我們就必須實現輸入共享，輸入共享的實現比較復雜，主要依賴兩點：

• 其一是依賴安裝流，因為拓撲是提前安裝的，因此在安裝到真正開始拉取日志的這段時間內，我們希望能夠通過拓撲信息判斷出需要共享的輸入源，構建出輸入源和對應Map的映射關系。

• 其二是依賴Map節點和Agent之間的一致性哈希，保證Brain在生成任務時，同一個機器上的日志，永遠是分配相同的一個Map節點去拉取的（除非它對應的Map掛了）。

站在Map節點的視角來看：在各個任務的Reduce拿著拓撲來注冊的時候，我拿出輸入源（對日志監控來說通常可以用一個IP地址和一個日志路徑來描述）和Map之間的關系，暫存下來，每當一個新的Reduce來注冊Map，我都判斷這個Map所需的輸入源是否存在了，如果有，那就給這個輸入源增加一個上游，等到這個輸入源的周期到了，那就觸發拉取，不再共享了。

其他組件

存儲：負責所有計算結果的持久化存儲，可以無限伸縮，且查詢歷史數據保持和查詢實時數據相同的低延遲。Sunfire原始數據存儲使用的是阿里集團的Hbase產品（HBase ：Hadoop Database，是一個高可靠性、高性能、面向列、可伸縮的分布式存儲系統），用戶配置存儲使用的是MongoDb。

展示：負責提供用戶交互，讓用戶通過簡潔的建模過程來打造個性化的監控產品。基于插件化、組件化的構建方式，用戶可以快速增加新類型的監控產品。

自我管控：即OPS-Agent、Ops-web組件，負責海量Agent的自動化安裝監測，并且承擔了整個監控平臺各個角色的狀態檢測、一鍵安裝、故障恢復、容量監測等職責。

轉載于:https://www.cnblogs.com/davidwang456/articles/9121106.html

總結

以上是生活随笔為你收集整理的谈阿里核心业务监控平台SunFire的技术架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。