最近的工作是在唯品會做監控平臺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已經完成了初步的框架和輪廓開發，還沒有經歷過海量數據的衝擊，很多問題還需要在實踐中進行檢驗，我們會持續完善，並最終開源。將它打造成名副其實的大規模分佈式系統的跟蹤、監控、告警平臺。
