圖1 dapper
圖2 商品中心的調用和被調用情況Step 2.關注接口響應時長工程接口的響應時長被我們細分為不同區間：
圖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的智能監控解決方案延伸閱讀：窩窩研發哲學新聞熱點
疑難解答
