唯品會Microscope——大規模分布式系統的跟蹤、監控、告警平臺 - 馬宏的世界 - 博客頻道 - CSDN.NET
http://blog.csdn.net/alex19881006/article/details/24381109

最近的工作是在唯品會做監控平臺Microscope。我們的目標是：大規模分布式系統的跟蹤、監控、告警平臺。

對于鏈路監控這塊，業界的論文當屬Google Dapper這篇，它詳細的闡述了如何對請求調用鏈進行跟蹤，提出了理論模型，然后它沒有具體的代碼實現。Twitter 的Zipkin則是根據這篇論文用Scala語言將其實現，并且開源。

Scala在Twitter大規模的使用，包括Twitter的的RPC框架也都是用Scala實現的，我們這邊還是以Java為主，所以我們就考慮在參考Zipkin的基礎上，自己實現跟蹤模塊。

國內的很多互聯網公司也是基本上按照Dapper的論文模型來實現鏈路監控：淘寶的鷹眼，新浪微博的watchman，京東的hydra。一脈相承。

eBay則是用了一套叫做Transaction的概念來實現鏈路監控，大眾點評網的CAT的開發者就來自eBay，所以兩者高度相似。

鏈路監控的核心是：用一個全局的 ID 將分布式請求串接起來，在JVM內部通過ThreadLocal傳遞，在跨JVM調用的時候，通過中間件（http header, framework）將全局ID傳遞出去，這樣就可以將分布式調用串聯起來。

模型有了，剩下的工作就是如何獲取數據了。

淘寶有眾多的中間件，先天優勢，在中間件中埋點就可以了。新浪微博采用的方式比較前衛（個人感覺），用的是字節碼增強技術來埋點，類似Btrace的做法。

埋點需要與中間件耦合，字節碼需要在運行時重寫類文件，本質上其實都需要對現有的代碼做修改，只不過角度不一樣，我們最終的目標其實都是一樣的：對應用程序透明即可。所以兩種方案各有千秋，合適就行。

論文中提到過采樣的問題，考慮到數據量很大的時候，全量跟蹤會導致很大的壓力，采樣便應用而生。淘寶用的是hash采樣，京東用的是固定時間段內固定跟蹤數量的采樣，Dapper使用的是自適應采樣。我們的采樣，要不要做，暫時沒想好，全量先。

跟蹤鏈路的數據，只是監控平臺數據來源的冰山一角。

我們在研究中發現Twitter還有一個開源項目叫做Ostrich，用于定義監控指標（count, gauge, histogram, timer）。簡單來說，我們想知道用戶的在線數量，想知道系統的線程數量，。。。

任何一切想要量化的Metrics，都需要被記錄下來。

不過同樣的問題是，這個項目也是Scala寫的，不過好詳細是Java的開源世界中已經有了一個很著名的Metrics軟件包。eBay的CAL系統就集成了這個軟件包，用于獲取監控指標。

除了metrics,對于開發人員來說，異常信息也是他們特別關注的，因此異常的堆棧調用鏈也需要收入到監控數據來源項。

從Twitter的可視化平臺展示的一些demo來看，GC logs也被Twitter的開發人員作為數據來源的一項，存儲到后端，進而使得開發人員能夠看到 GC的詳細信息。

我們認為，從大的方向上面說，數據來源可以總結為：

1、請求調用鏈
2、系統、業務 metrics（CPU, IO, memory，disk, http, servlet, db, cache, jvm...）
3、異常堆棧
4、GC log

數據有了，下一步就是怎么把客戶端的數據傳輸到服務器端，進行分析、存儲、展示了。

客戶端數據的存儲方案1：日志存儲

Log4j現在推出了一個Log4j 2的版本，最大的變化就是用disruptor 的ring buffer做異步處理，異步寫日志。從性能測試來看，在吞吐量和延遲方面都有很大提升，這個應該是淘寶的方案，淘寶應該是用disruptor實現了一個類似這樣的日志組件。

客戶端數據的存儲方案2：內存存儲

eBay和點評的都是用Java并發庫中的LBQ來做存儲的，隊列做存儲的好處很明顯，就是讀寫很方便，性能也高。但是當客戶端產生的數據量快速上升時，隊列的容量就存在問題。

我們目前的方案是：基于disruptor做一個內存隊列。當然，這僅僅是當前的方案，如果將來隊列無法支持，那么log4j2 將是我們的備選方案。

存儲之后，就是開啟獨立的線程異步發送到后端，走TCP。

目前flume作為分布式日志的收集框架，在唯品會已經大規模的使用，有專門的團隊在維護flume。在將來我們可能考慮讓flume來傳輸監控數據。

數據走到后端處理流程之前，要用消息中間件，比如Kafka/MetaQ做一個緩沖。

Kafka作為消息中間件，為后面的數據處理提供了很好地緩沖區，服務器端也可以非常從容的采用Poll模式來處理數據。

后端的數據處理，我們采用的是SEDA架構，多階段事件驅動架構，用disruptor做線程之間的數據交換。將整個處理流程抽象為：驗證、分析、告警、存儲。

目前Storm作為分布式流式處理框架，在公司內部已經得到很好地應用，后期我們會把整個計算邏輯放在storm上面進行。

驗證，主要是對一些不符合規范的數據進行過濾，已達到我們能夠處理的標準。
分析：主要是對調用鏈進行統計，分析調用來源，調用依賴
告警：對可能存在問題的調用鏈，通過告警引擎發送給訂閱的開發人員、運維人員
存儲：將數據全量存儲到TSDB(Hbase)。

Hbase作為一個天然的分布式存儲平臺，為我們解決了很多問題，Open TSDB則是在Hbase的基礎上設計了一套適合存儲監控數據的schema。我們將OpenTSdb的設計理念融入到我們的存儲平臺，使得它能夠全量存儲所有的監控數據。

查詢UI。

查詢UI，我們參考Twitter 的可視化平臺，將整個頁面劃分為五個區域。
Home 區域：展示每個域的宏觀信息，狀態
Viz 區域：metrics報表，dashboard
Alert 區域： 告警平臺
Exception 區域：異常的堆棧信息
Trace 區域：分布式調用鏈路

目前，Microscope已經完成了初步的框架和輪廓開發，還沒有經歷過海量數據的沖擊，很多問題還需要在實踐中進行檢驗，我們會持續完善，并最終開源。將它打造成名副其實的大規模分布式系統的跟蹤、監控、告警平臺。