從宏觀到微觀——天機與鷹眼聯手

鄭昀 建立於2015/6/23 最後更新於2015/6/25

關鍵詞： Google Dapper、窩窩Tracing、鷹眼、天機、性能、調用鏈分析、散點圖、瀑布圖

---

本文檔適用人員：技術人員

提綱：

1. Google Dapper是怎麼作的
2. 天機裏如何從宏觀看到微觀

---

0x00，Google Dapper的交互方式

    Google 的 Dapper 是淘寶鷹眼、點評CAT、京東Hydra、eBay CAL、Twitter Zipkin、窩窩Tracing的鼻祖。不少年前，Google 說，大部分用戶都是經過這麼個控制檯來使用 Dapper 的，典型流程以下圖所示：

圖1 dapper

 

1. 用戶輸入他感興趣的服務和時間窗口，選擇相應跟蹤模式(這裏是 span 名稱)，以及他最關心的某個度量參數(這裏是服務延遲)。
2. 頁面上會展現一個指定服務的全部分佈式執行過程的性能摘要，用戶可能會對這些執行過程根據須要進行排序，而後選擇其中一個看詳情。
3. 一旦用戶選定了某個執行過程後，將會有一個關於該執行過程的圖形化描述展示出來，用戶能夠點擊選擇本身關心的那個過程。
4. 系統根據用戶在1中選擇的度量參數，以及3中選擇的具體過程，顯示一個直方圖。在這裏顯示的是有關 getdocs 的延遲分佈的直方圖，用戶能夠點擊右側的 example，選擇具體的一個執行過程進行查看。
5. 顯示關於該執行過程的具體信息，上方是一個時間軸，下方用戶能夠進行展開或摺疊，查看該執行過程各個組成部分的開銷，其中綠色表明處理時間，藍色表明花在網絡上的時間（注：即咱們說的調用鏈瀑布圖）。

 

    這就是 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 散點圖

從上圖能夠看出，sortGoods 接口方法其實大多數響應時間在 500毫秒如下，最大響應時間也不超過 1.5秒。咱們選中響應時間最大的那個點，點擊一下。

 

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-

 

輔助閱讀：

#研發解決方案介紹#Tracing（鷹眼）

#研發解決方案介紹#基於StatsD+Graphite的智能監控解決方案

 

延伸閱讀：

窩窩研發哲學