本文旨在幫助讀者了解什么是全鏈路追蹤以及如何使用工具來分析鏈路中性能瓶頸，
??火焰圖是什么？
火焰圖（Flame Graph）是由 Linux 性能優化大師 Brendan Gregg 發明的用于分析性能瓶頸的可視化圖表，它以一個全域的視野來看待時間分布，從頂部往底部列出所有可能導致性能瓶頸 Span，
下面以觀測云的火焰圖為例，陳述其繪制邏輯：
縱軸（Y軸）代表呼叫 Span 的層級深度，用于表示程式執行片段之間的呼叫關系，上面的 Span 是下面 Span 的父 Span，（資料上，可以通過子 Span 的 parent_id 等于父 Span 的 span_id 關聯起來）
橫軸（X軸）代表單個 Trace 下 Span 的持續時間，一個格子的寬度越大，說明該 Span 從開始到結束的持續時間越長，只要有“平頂”，則表示該函式可能存在性能問題，就可能是造成性能瓶頸的原因，
????為什么要用火焰圖？
通常，我們可以通過查詢日志、使用Shell等協助定位問題例外原因；再細致一點，會用到Jmap、Jstack分析堆疊跟蹤等，但若需要分析至堆疊、呼叫鏈的階段，說明很可能已經是Performance的問題了，但上述方法，或將產生海量文本無法直觀分析，或缺乏匯聚型資料難以綜合評判，降低了我們排查問題的效率，
因此，為了降低人工二次分析難度、提高性能資料的易懂性，火焰圖便被廣泛用于分析性能瓶頸問題，它納入了執行緒堆疊的呼叫鏈和出現頻率兩個維度，從而可以非常方便地看到頂層的哪個函式占據的寬度最大，即性能資源都消耗在了哪里；進而，能夠直觀地定位程式的性能瓶頸，以進行相應地優化，
觀測云的火焰圖除了展示函式呼叫的基本性能資訊之外，還在同一個可視化圖表中關聯了多維度資料，便于用戶綜合評判性能瓶頸的原因所在；同時，充滿細節與溫度的人性化互動設計，提升了使用體驗及作業效率，
??????如何巧用觀測云火焰圖分析鏈路性能？
3.1 火焰圖
火焰圖左側圖示區：
同一種顏色的 Span 對應同一個服務：可直觀感知當前 Trace 所涉及到哪些服務請求，（小提示：服務的顏色會繼承到鏈路查看器等其他分析頁面）
每一個Span 塊默認顯示：當前 Span 的資源或操作、持續時間、以及是否存在錯誤；懸浮還可展示其整體耗時占比，
對于多執行緒或者異步任務：同層級或下屬子Span執行時間可能會出現重疊，圖中通過連線的形式來關聯父子 Span 之間的關系，
右側服務串列：
顯示當前 Trace 內發生請求呼叫，所涉及到的服務名稱和顏色、該服務執行時間占總執行時間的百分比，（注意：服務名稱顯示為 None 的情況，則表示當前 trace 未找到 parent_id = 0 的頂層 Span）
3.2 Span 串列
上圖全收起狀態，以服務視角：
顯示服務型別、名稱和顏色，以及當前服務下是否存在 status = error 的 Span；還依次顯示當前服務下面的 Span 數量、持續時間的平均值、執行時間總和，以及當前服務的執行時間占總執行時間的百分比，
下圖服務行展開狀態，以 Span 視角：
顯示資源名稱、對應服務顏色及當前 span 是否存在 status = error ；還依次顯示當前 Span 持續時間、執行時間數值及占總執行時間的百分比，
3.3 服務呼叫關系
觀測云還可以顯示當前 Trace 下服務之間的呼叫關系拓撲：
支持按資源名稱模糊匹配，定位某個資源的上下游服務呼叫關系，
服務 hover 后，顯示當前服務下的 Span 數量、服務執行時間及占比，
????????如何開啟觀測云通過火焰圖分析鏈路性能？
4.1 注冊與安裝
建議通過電腦端，進入【 觀測云 】（https://console.guance.com）平臺進行實操，并參考觀測云學堂【 巧用“火焰圖”快速分析鏈路性能 】（https://www.guance.com/learning/articles/flame_graph01） 的操作指引，
4.2 實際鏈路資料分析舉例
第一步：登錄觀測云作業空間，查看應用性能監測模塊的服務串列，從服務頁面已經可以看出 browser服務的 P90 回應時間較長，
第二步：點擊 browser服務名稱，查看該服務的概覽分析視圖，可以看出影響當前服務回應時間的最關鍵的資源是 query_data這個介面，因為這個介面是觀測云的一個資料查詢介面，所以接下來我們看下這個介面在查詢程序當中，到底是因為什么導致耗時較長，
第三步：點擊資源名稱，跳轉到查看器，通過點擊 持續時間 倒序查看回應時間的最大值，
第四步：點擊 Span 資料，查看分析當前 Span 在整個鏈路里面的執行性能和其他相關資訊，
第五步：點擊右上角 [全屏] 模式按鈕，放大查看火焰圖相關資訊，
結合整體鏈路查看，可以看出 browser服務在整個鏈路中的執行時間占比高達 96.26%，從 Span 串列也可以得出此結論，
根據火焰圖的占比和對應的鏈路詳情資訊，我們可以總和得出 browser的這個 query_data Span在整個執行程序中可以看到 resource_ttfb（資源加載請求回應時間）耗時 400 多毫秒， resource_first_byte（資源加載首包時間）耗時 1.46 秒，
再結合查看 province的地理位置定位是 Singapore（新加坡），而我們的站點部署在杭州節點，則可以得出是因為地理位置問題導致資料傳輸的時間變長從而影響了整個的耗時，
相關閱讀：
【 The Flame Graph --Brendan Gregg 】（https://queue.acm.org/detail.cfm?id=2927301）
【 如何讀懂火焰圖？--阮一峰的網路日志 】（https://www.ruanyifeng.com/blog/2017/09/flame-graph.html）
【 關于 Traces 、Span 等鏈路相關概念的介紹 --OpenTracing 】（https://wu-sheng.gitbooks.io/opentracing-io/content/pages/spec.html）
【 巧用“火焰圖”快速分析鏈路性能 】（https://www.guance.com/learning/articles/flame_graph01）
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/523950.html
標籤：其他
上一篇：Workflow，要不要了解一下
下一篇：游戲開發中的狀態機模式原理與應用