唯品會Microscope——大規模分散式系統的跟蹤、監控、告警平臺
阿新 • • 發佈：2018-12-25
最近的工作是在唯品會做監控平臺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已經完成了初步的框架和輪廓開發，還沒有經歷過海量資料的衝擊，很多問題還需要在實踐中進行檢驗，我們會持續完善，並最終開源。將它打造成名副其實的大規模分散式系統的跟蹤、監控、告警平臺。
對於鏈路監控這塊，業界的論文當屬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已經完成了初步的框架和輪廓開發，還沒有經歷過海量資料的衝擊，很多問題還需要在實踐中進行檢驗，我們會持續完善，並最終開源。將它打造成名副其實的大規模分散式系統的跟蹤、監控、告警平臺。