鄭昀 創建於2015/6/23 最后更新於2015/6/25
關鍵詞：
Google Dapper、窩窩Tracing、鷹眼、天機、性能、調用鏈分析、散點圖、瀑布圖
本文檔適用人員：技術人員
提綱：
- Google Dapper是怎么做的
- 天機里如何從宏觀看到微觀
0x00，Google Dapper的交互方式
Google 的 Dapper 是淘寶鷹眼、點評CAT、京東Hydra、eBay CAL、Twitter Zipkin、窩窩Tracing的鼻祖。很多年前，Google 說，大部分用戶都是通過這么個控制台來使用 Dapper 的，典型流程如下圖所示：
圖1 dapper
- 用戶輸入他感興趣的服務和時間窗口，選擇相應跟蹤模式(這里是 span 名稱)，以及他最關心的某個度量參數(這里是服務延遲)。
- 頁面上會展示一個指定服務的所有分布式執行過程的性能摘要，用戶可能會對這些執行過程根據需要進行排序，然后選擇其中一個看詳情。
- 一旦用戶選定了某個執行過程后，將會有一個關於該執行過程的圖形化描述展現出來，用戶可以點擊選擇自己關心的那個過程。
- 系統根據用戶在1中選擇的度量參數，以及3中選擇的具體過程，顯示一個直方圖。在這里顯示的是有關 getdocs 的延遲分布的直方圖，用戶可以點擊右側的 example，選擇具體的一個執行過程進行查看。
- 顯示關於該執行過程的具體信息，上方是一個時間軸，下方用戶可以進行展開或折疊，查看該執行過程各個組成部分的開銷，其中綠色代表處理時間，藍色代表花在網絡上的時間（注：即我們說的調用鏈瀑布圖）。
這就是 Google 從宏觀一路看到微觀的操作模式。即，服務（對應於一個或一串集群）的度量指標是宏觀，真實的調用鏈是微觀，在圖形界面上即可從宏觀殺入微觀。
0x01，天機系統里如何從宏觀看到微觀
窩窩也致力於從某個工程的度量指標開始看起，選擇自己關心的時段，最終一路點擊后，找到可疑的調用鏈，看到它的瀑布圖。下面逐個步驟講解一下。
Step 1.找到感興趣的工程
由於所有的 Java 工程都接入了 Dubbo，所以有了服務的注冊與發現，也因此天機系統自然而然知道某個工程有多少個節點提供服務。
所以，我們可以在天機的服務調用監控里找到感興趣的工程。
選擇好時間段，我們可以看到這個工程的所有節點調用和被調用情況，如下圖所示：
圖2 商品中心的調用和被調用情況
Step 2.關注接口響應時長
工程接口的響應時長被我們細分為不同區間：
- 0～200毫秒
- 200～500毫秒
- 500～1秒
- 1～5秒
- 5～10秒
那么，我們優先關注響應時長在 1～5秒 之間的接口，如下圖所示：
圖3 工程接口被調用時的響應時長統計
Step 3.看 時間-次數 曲線
點擊對應的"圖表"鏈接，我們進入服務調用統計圖表頁面。我們隨后選擇"1-5s"Tab頁，如下圖所示，可以看到商品中心 183 節點在6月24日里，接口響應時間在 1秒～5秒 之間的情況：
圖4 調用統計圖表
看到這里，我們只是知道某個時間點，商品中心有點不正常，但還不知道是哪一個接口不正常。
Step 4.看 時間-次數 曲線
點擊上圖中的那個紅點，從而進入 10點30～10點35 之間接口響應時間在 1秒～5秒 之間的分接口曲線圖：
圖5 分接口曲線圖
這樣，我們發現，原來全是 sortGoods 這個方法引發的。
但這還不夠。我們還是不知道為什么慢。
Step 5.看散點圖
點上圖中的那個藍點，進入 10點30 左右的真實調用散點圖，圖上的每一個點都代表一個真實的調用：
圖6 散點圖
Step 6.看瀑布圖
點響應時間最大的那個點，進入 10點30 左右、sortGoods 方法響應時間為 1.347 秒的真實調用鏈的瀑布圖：
圖7 瀑布圖
每一層調用，都可以看到具體參數，如 HostIP、RequestIP、輸入參數、SQL語句（假如訪問了DB的話）、對緩存是GET還是SET，如果有異常拋出，還能看到堆棧信息。
假如是對 memcached 批量獲取，還可以看到具體的 keys 數組，如下圖所示：
圖8 keys也可以展示
最終，我們找到了 sortGoods 這次調用花了1秒多的原因：
圖9 有一個 update 接口操作花了 540 毫秒
那么接下來分析這個方法的代碼即可。
如上所示，經過劉奎等同學的努力，天機與鷹眼聯手，在沒有部門經理、研發經理、工程師的幫助下，我自己就能通過天機系統從宏觀看到微觀，並最終明確某個性能瓶頸的 Root Cause（當然還不夠接觸本質）。
這還不夠。
還有其他的調用路徑分析和調用去向分析場景。以后再講。
-EOF-
輔助閱讀：
延伸閱讀：
歡迎訂閱我的微信訂閱號『老兵筆記』，請掃描二維碼關注：
