Facebook Canopy 初探

原創聲明：本文系作者原創，謝絕個人、媒體、公眾號或網站未經授權轉載，違者追究其法律責任。

Google Dapper

首先簡單回顧一下 Google 的 Dapper，2010 年 Google 發布 Dapper 的論文系統闡述了在複雜的、大規模分散式集群環境下如何進行系統的跟蹤以及問題的分析與定位。通過產生一個全局唯一的 traceId 以及用 span、annotation 核心數據模型把相關調用組成一個完整的調用樹。關於 Dapper 如何做低消耗、應用級透明等細節，可以參考 Dapper 的論文。這裡主要是簡單回顧一下其核心思想，因為後續出現的分散式跟蹤產品包括本文要分析的 Facebook 的 Canopy 都有受其啟發。此文是基於2017年 Facebook 發布的 Canopy 論文，分析其如何進行分散式跟蹤以及問題分析定位。

Span在 Dapper 跟蹤樹種短暫的關聯關係

圖片出自 Google Dapper[1]

背景介紹

TMM

在 Canpoy 產品前，Facebook 有一個產品叫 TMM(The Mystery Machine)，在其 2014 年的論文中有具體描述，簡單看一下其架構如下：

將 trace 數據存儲到 Hive、Scribe 中，然後通過 Hadoop 去跑 job 去分析計算其 trace 模型。從 1.3M 條 trace 數據中分析計算出相關模型需要 2 個小時，分析還是依賴離線計算能力上，實時性沒有那麼強。

Canopy

在互聯網分散式環境下，每一個系統在其特定場景下都有其特殊性，各自的模型都有其不同點，無法繼承如 RPC 場景、Event Loop、瀏覽器頁面載入、Mobile App 等，如果為某些場景定製化，會面臨這些場景的迭代開發時間長。

另一方面一些性能分析工具不能跨系統進行分析，需要掌握每一種場景下應該使用什麼樣的分析工具以及相關數據之間的映射關係。每一種工具都有其開發周期，部署時間較長。基於此 Facebook 設計開發 Canopy 的出發點很明確主要是進行單個或跨系統間性能問題的定位，對一些問題分析的推測進行快速驗證。

Canopy 於 2015 年開始在生產環境投入使用，每天產生和處理 13 億數據量，整個產品是作為替換 TMM 在進行演進。

示 例

首先通過一個分析診斷問題的示例來看一下 Canopy 是如何去定位問題的。在此之前，先簡單說下 Facebook 頁面顯示的一些技術點。Facebook 顯示的一個完整的頁面是有很多由不同團隊開發的 page pieces 組成。Facebook 的核心框架會將它們進行合併在 web servers 和用戶的瀏覽器端運行。為了優化用戶體驗，會用到一種 Early Flush 技術。Early-Flush 是服務端的一種優化技術手段，實現預測客戶端需要的資源，批量發送給客戶端。

問題描述，Facebook.com 在顯示某個頁面的初始化平均響應時間增加了300ms，如 a) 圖顯示：

圖片出自 Facebook Canopy[2]

通過頁面載入延時看到其延時增加 300ms，但沒法定位到具體的某部分導致其增加，在此基礎上進行進一步的拆解分析，如 b) 圖顯示：

圖片出自 Facebook Canopy[2]

從圖分析服務後端的 server 以及網路相關延時都沒有發生變化，但瀏覽器執行時間以及資源 (css，js 等) 的獲取時間增加了。很自然接下來去分析資源載入這塊的問題如 c) 圖所示：

圖片出自Facebook Canopy[2]

頁面初始化顯示需要的資源發現 css 的資源下降了 5%，同時發現 Early-Flush 圖有一次 miss，導致 css 額外載入了 10KB 的數據，如 d) 圖所示：

圖片出自 Facebook Canopy[2]

通過這些 metrics 已經知道問題所在（Early-Flush 沒有命中），但還不知道具體是哪一部分導致，所以進行進一步的拆解，按 page pieces 進行分組，找到 root cause 是 UserInput 部分導致資源的載入如 e) 圖所示：

圖片出自 Facebook Canopy[2]

分析 UserInput 因增加的新的功能有變動，需要一些新的資源，但 Early-Flush 組件並不知道其發生了變更，從而沒有達到的優化的效果，通過調整 Early-Flush 相關配置，性能問題從而解決。這是一個很常見的因相關配置沒有進行修改而導致性能問題的 case，但往往這種問題很難發現定位到。

圖片出自 Facebook Canopy[2]

挑 戰

從上面的示例中可以看出，後面需要很豐富、詳細的 trace 以及 metrics 數據進行分析、拆解。挑戰主要體現在如下幾個方面：

Trace數據的模型

直接操作海量的基本的性能數據是非常笨重的，擴展上也不太可能。工程師和使用的工具都必須理解底層的事件數據與各組件高層次(High level)的數據之間的映射關係。但如果建立一個高層次的固化的模型又會帶來問題：已經存在的組件，已經未來新的組件，以及三方的組件的如何支持進來。如果用多種執行模型,性能數據粒度以及質量存在大幅度變化，性能數據多樣化，無法統一。因此 trace 模型的如何管理非常關鍵。在 Dapper 中 Span 來表示樹形層次關係，在模型方面 Dapper 用 Span 來表示樹形層次

數據的分析

在數據量大的情況下提供從多特徵角度進行切分、分組、過濾、組合及匯總 trace 數據

滿足通用以及個性化需求

對於一些常用場景的一般的用法支持的情況下，具備支持個性化需求的能力來滿足不同場景的需求。

設 計

這部分主要看 Canopy 是如何設計去滿足以及迎接這些挑戰。

Pipeline

通過管道機制，從系統生成的跟蹤數據中提取性能數據。在管道的每一個階段，給用戶的提供定製能力，並且各個組件之間的關注點是隔離的，這樣可以進行彼此的演進而不互相影響。

Canopy 的 trace 數據的收集的思路和 Dapper 類似，也是基於一些通用的組件進行 instrument，產生一個 traceId，然後在各個組件中進行傳遞，產生相關的事件，Canopy Event 會在後續介紹。

圖片出自 Facebook Canopy[2]

產生的事件會已上報進行收集處理，以下是其主要處理流程

圖片出自 Facebook Canopy[2]

④ 事件中帶有執行過程中的相關性能數據以及依賴(因果)關係數據

⑤ 收到數據在內存中進行聚合

⑥ 落地存儲

⑦ 如果一個請求的所有事件收齊，然後就排隊處理，在 Canopy 中所有和跟蹤相關數據都已事件方式上報，需要確保一次完整的鏈路數據已經收齊

⑧ 把 trace event 事件映射成 trace model，因為 trace 事件中包含了相關數據能以此進行模型的重構

⑨ 執行 feature 表達式,從已經模型化的 trace中抽取計算需要的特徵數據，從這塊可以支持一些定製化的需求

⑩ 表達式中通過dataset配置綁定自己感興趣的過濾掉自己不需要的 trace，以及數據的輸出配置

? 自己查詢 dataset，或查看視圖和 Dashboard

? 除了可以自定義 dataset，也提供了共享的（通用）dataset，一些通用的high-level特性進行查詢視圖以及 Dashboard，以及一些工具用下鑽分析。

以上介紹了 Canopy 的主體流程，通過 Canopy 的 events 把所有 trace 數據進行上報存儲，在 Instrumentation API 層都是基於 events 攜帶需要的 trace 信息，而沒有特定的數據模型進行封裝，而在數據收集後可以進行很靈活的模型重建以及數據的抽取。

下面來看起各個相關點的設計。

Instrumentation APIs

主要職責

產生 traceId,並負責傳遞

記錄請求相關的結構層次（e.g. 何時何地，線程和組件因果關係，網路通信）

收集有用的性能數據

解耦設計

特定的 Instrumentation 任務應該訪問有限的 API，這樣降低接入門檻減少出錯，產生一些不正常的 trace 數據

訪問這些有限的 API (封裝好相關邏輯)，產生的數據相比自己去構建數據更健壯

從多個角度捕獲性能相關的數據，而不會破壞已經存在的邏輯。這樣可以很好的支持自定義需求的設計以及與第三方包的集成

Trace Event

Trace Event

Trace Event

Canopy中的 event 結構信息：

圖片出自 Facebook Canopy[2]

Event type 可擴展，會根據 type 來做不同的處理，sequenceNumber 和 timestamp 主要用於將同一個進程或線程中的 event 排序，EventId(RandomId) 用於關聯其他有關係的 event。會在發送方記錄 eventid，traceId 和 eventid 都會透傳給接收方，在接收方會記錄發送者的 eventid。

Modeled Traces

根據 event 來構建 Modeled Trace，性能數據 High-Level 表現形式，隱藏了底層日誌事件的不一致性。

類型

Execution units:執行線程

Blocks:execution unit中計算段(Segments of computation within an execution unit)

Points:一個Block中即時發生的events

Edge:points間的因果關係

可以表示進程間或機器間的因果關係也可用於表示同一進程中的execution units或blocks。非常適合以下模式

長時間運行的執行單元間的流，雙向通訊，應用級別block依賴

Trace Datasets

Trace 數據衍生出來的數據集，囊括了很多Traces數據的信息

性能分析的主要入口點（面向工程師）

Feature(trace中一個元素的label或聚合值或一些結構關係) 通過抽取函數(抽取函數是無狀態的且一條trace記錄執行一次)產生

Trace Dataset 表現形式

基於這些豐富或自定義的 trace 數據集來支持一般以及個性化需求。

小 結

本文介紹了 Facebook Canopy 在面對海量 trace 數據以及各種環境下，如何去設計端到端的性能分析產品。縱觀下來，其設計特點是解耦的設計，trace 事件數據沒有綁定到固定的數據模型中，數據處理環節支持靈活的 feature 抽取，形成不同的 trace dataset 數據集來達到不通場景的需求。

參考

[1]Dapper, a Large-Scale Distributed Systems Tracing Infrastructure

[2]Canopy: An End-to-End Performance Tracing and Analysis System

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！