分散式追蹤系統，最佳核心設計實踐

So, you want to trace your distributed system?
Key design insights from years of practical experience

Raja R. Sambasivan⋆, Rodrigo Fonseca†, Ilari Shafer‡, Gregory R. Ganger⋆
⋆Carnegie Mellon University, †Brown University, ‡Microso

CMU-PDL-14-102
April 2014

Parallel Data Laboratory
Carnegie Mellon University
Pittsburgh, PA 15213-3890

摘要

端對端追蹤系統獲取單個分散式系統元件內部、元件之間，因果活動的工作流程。隨著分散式系統規模和複雜性的不斷增加，這樣的追蹤系統逐漸成為諸如診斷和資源記錄等管理任務的重要工具。鑑於我們過去的構建和使用的端對端基礎設施，本文提煉了核心設計維度，來闡述追蹤功能的重要用例。倘若沒有徹底明白基礎系統的維度和取捨，貿然開發追蹤基礎系統，開發出來的系統很難達到預期的目標。除了搞清設計的維度，針對各種追蹤用例，本文給出了良好的設計選擇，並將其與早期的追蹤基礎系統進行比較，早期實現的短板在那裡。同樣，本文還闡述了完整的分散式系統設計路上仍面臨的諸多挑戰。

致謝：We thank the members and companies of the PDL Consortium(including Actio, APC, EMC, Emulex, Facebook, Fusionio, Google, Hewlett-Packard Labs, Hitachi, Huawei Technologies, Intel, Microso Research, NEC Laboratories, NetApp, Oracle, Panasas, Riverbed,Samsung, Seagate, STEC, Symantec, VMWare, and Western Digital) for their interest, insights, feedback, and support. is research was sponsored in part by two Google research awards, NSF grant #CNS-1117567and by Intel via the Intel Science and Technology Center for Cloud Computing (ISTC-CC). While at Carnegie Mellon, Ilari Shafer was supported in part by a National Science Foundation Graduate Research Fellowship.

關鍵字：雲端計算、分散式系統、設計、端對端追蹤

1 引言

現代分散式服務是巨大的、複雜的，日益依賴其它類似的複雜分散式服務。比如，許多谷歌服務使用各種內部服務，例如，廣告服務和拼寫檢查服務；並且部署atop基礎服務，例如BigTable，橫跨數以百計的節點，構建諸如谷歌檔案系統（GFS）和Chubby鎖服務等其它atop服務。即使簡單的網路應用也會涉及很多層級，其中一些層級是可擴充套件和分散式的。管理和開發任務，例如效能除錯、容量計劃、問題診斷，在這樣的開發環境中，一直很困難的，甚至非常困難，傳統的機器為中心的監控和追蹤機制成效有限。特別是，它們不能提供一個連貫的工作檢視，來反映分散式服務節點及其依賴關係。

為了解決此類問題，近期通過研究，開發了新的工具和方法，這套工作流為中心追蹤技術，我們通稱為“端對端追蹤系統”[2,5, 9,11,19,20,23,25,37,38, 40, 43,44,45, 47, 48,53]。端對端追蹤系統獲取單個分散式系統元件內部、元件之間，因果相關活動的詳細工作流程。比如，一個基於分散式服務請求，每個追蹤會顯示服務元件內部，元件之間處理某個請求的工作流程，詳見圖一。

如單一程式除錯工具應用於單一程式應用，端對端追蹤系統獲得分散式服務請求處理詳細資訊，此資訊對開發和管理是無價的。截止目前，端對端追蹤系統被證明效用是非常高的，採用連續樣本測試，顯示此係統使用許多重要的用例，包括異常測試，穩定狀態正確性以及效能問題診斷，效能分析，資源使用分配。正是如此，有了越來越多的工業級實現，包括谷歌Dapper，Cloudera的Htrace，推特的Zipkin，以及其它。展望未來，端對端追蹤系統很有可能成為雲環境基礎底層元件，為資料中心內部，資料中心間提供一個全域性檢視。

圖一：端對端追蹤

此追蹤顯示了單個分散式系統以及其它可能依賴的分散式服務選項，其元件內部、元件之間，因果活動的工作流程。單個蹤跡可能包含工作流的結構，比如工作執行的因果順序，併發數目，分支合併點，系統效能，資源使用情況。不過，即便是這樣一個子集也需要收集不同的用例。在本例中，蹤跡展示了結構和內部追蹤節點延遲，兩個請求提交至一個假定的應用伺服器，並由一個共享表和一個共享分散式檔案系統進行支援。頂層訪問所需的資料儲存在表的快取中，而底層請求所需的資料必須併發地取自兩個儲存節點。追蹤點作為簡單的標記，顯示工作流所經過的軟體元件位置。

不幸的是，儘管對端對端追蹤系統的興趣日益強烈，但指導設計者構建這一新基礎系統的資料確實寥寥。其中最大的問題是，現有的資料將端對端追蹤系統看做是一種泛化“全能的”解決方案，可以處理許許多多可能的用例，比如穩定態問題診斷或資源屬性。不過依據我們過去設計的兩個最著名的追蹤基礎系統 (Stardust [40，47], and X-Trace [19，20]) 以及構建在此基礎上的工具， Dapper [43]證明設計這樣泛化的系統是沒有根據的。比如，最初構建和使用的Spectroscope [40],作為一種端對端追蹤工具，自動定位資源效能變化， 結果卻令人異常沮喪。設計初衷，希望診斷工具能複用一個追蹤基礎系統，該基礎系統早期設計用於資源屬性任務，但這種“全能”的理念在應對高負載時侷限明顯。經歷初次失敗後，我們才意識到針對資源屬性任務的追蹤系統設計，不應展示需要回收的關鍵路徑，甚至同步點，一些不謙容降低開銷的抽樣，甚至限制了診斷的使用性。依據這些經驗修訂了原版的追蹤基礎系統，這些都有助於本文諸多觀點的闡述。

追蹤系統的基本概念是明確的，分散式服務程式碼的某些部分，在執行時工具產生的資料，接著這些針對某個請求而來自不同程式碼部分的資料，被合併產生一個全域性的跟蹤。不過，以我們的經驗，從四個重要的設計維度說明不同用例的追蹤結果使用性：什麼樣的因果聯絡應該被保留下來，如何對此因果聯絡進行追蹤，如何減少抽樣開銷，如何進行視覺化端對端追蹤。沒有這些知識維度和權衡取捨，設計追蹤基礎系統最後旺旺事與願違。當然物極必反，精細的觀察很難支援所有可能的用例。實際上，以前從未就這些維度加以甄別，很好的理解消化，以至於很多追蹤系統實現未能很好的滿足它們的潛在需求。

本文作為追蹤基礎系統的設計者指南，依據我們的經驗和過去十幾年的端對端追蹤系統研究，總結了端對端追蹤系統核心設計維度，並介紹了每個選項的利弊。除了上述描述的維度，我們建議針對每個核心追蹤用例，採用特定的設計點，並判斷現有的追蹤系統實現那些滿足此條件，或者不滿足那些條件。我們認為這是首篇介紹，如何甄別這些設計維度，如何取捨，這些如何深入影響一個追蹤基礎系統的可用性。

本文采用如下的組織方式。第二部分討論端對端追蹤系統用例和基礎剖析。第三至六部分描述設計維度和它們的開銷。第七部分應用這些知識，針對某些用例，選擇何種設計，以及分析現有的端對端追蹤基礎系統對某些用例的適用性。第八部分端對端追蹤系統潛在的挑戰和機遇。

2 背景

本小節闡述了端對端追蹤系統相關的背景，2.1小節描述了其核心用例，小節2.2列出了三種常見的端對端追蹤系統常用方法，小節2.3描述了本文提倡的架構方式。

2.1 用例

表一總結了端對端追蹤系統的核心用例，列出了適用它們的追蹤系統實現。注意，有些列出的基礎系統原本構想的用例比本表中的更加寬泛。比如，我們原本構想，原始的Stardust適用於資源屬性和診斷。類似的谷歌的Dapper被證明作用比原先想的少，因為它不能用於檢測特定的異常。而這種“構思適用”和“現實適用”之間的錯配，本文希望能最小化。

表一：端對端追蹤系統主要用途

本表列出了端對端核心用例和適用於它們的追蹤系統實現。某些實現適用於多個用例。新版的Stardust和X-Trace加‡以區分。幾乎所有的追蹤系統實現都能用來建模或者總結負載，即便這些模型基於不同需求設計。

異常診斷：診斷相關用例涉及問題的甄別和除錯，此類罕見的工作流（位於99.9百分位）不同於其它工作流。此類問題和正確性或效能有關，正確性比如元件的時間過期或者失敗， 效能比如一個執行很慢的函式或者過度地等待一個很慢的執行緒。或者工作流之間巨大的差異在於其結構，延遲，資源利用；對於結構，比如執行的因果順序，併發量，分拆合併點。Magpie[5]可以甄別正確性以及效能相關異常，而Pinpoint[11]異常檢測元件重點作用於正確性問題。

穩定性問題診斷：這是另一個診斷相關用例，涉及多數工作流的甄別和除錯問題。此類問題佔據一些重要指標50或者75百分位。此類問題的或許出現在工作流的結構、延遲、或者資源利用，總體上說與效能相關，比如，儲存節點配置的改變，一組請求此類節點，結果加大了響應時間。Pip[37],Stardust‡,X-Trace兩個版本，Dapper，以及Pinpoint都是很好的穩定問題診斷工具。

分散式效能分析：分散式效能分析的目的是診斷執行緩慢的元件或函式。一個函式執行的時間開銷不同，或許是跟它的呼叫方式有關，圖表分析器針對每個特定的呼叫棧，維護一個單獨的二進位制檔案，因此無需儲存全部的工作流結構。Whodunit[9]基於此目的設計，可以用來繪製整個工作負載。Dapper和ETE視覺化地展示單個工作流。

資源屬性：設計本用例回答這個問題：誰應該為分散式系統元件底層棧中執行的一小塊程式碼負責？這個涉及試圖完成此工作的分散式系統某個元件，以及發起的某個客戶端或者請求。Quanto和Stardust適合此類資源屬性診斷。前者，在分散式嵌入系統中，將每個裝置能耗使用同諸如感性或路由等高層次的活動聯絡起來，而後者，將每個元件資源使用，比如CPU時間或磁碟時間，同分布式儲存系統或資料中的客戶端聯絡在一起。注意基於資源屬性的追蹤系統特別適合記賬和計費，特別是許多客戶端共享分散式服務的情形，比如亞馬遜的EC2雲服務。

工作負載建模：這種泛泛的用例採用端對端追蹤，建立工作負載概要，用於後續的分析或者推斷。比如Magpie,聚集這些追蹤結果來甄別獨一無二的工作流集合，作為整個工作負載的典型代表。Stardust用來建立佇列模型，回答“假如…會怎樣？”問題。比如假如將一個分散式系統元件CPU替換成一個更快的，工作負載的效能會如何呢？幾乎所有的追蹤系統都能可以視為一個有用的工作負載模型，不過模型的具體型別由當初的設計決定。

2.2 端對端追蹤方式

大多數端對端追蹤基礎系統採用以下三種方式的一種來甄別因果關係活動：後設資料傳播，規則，或者黑盒推測。本文追蹤基礎系統設計採用方式一，相對於其它兩種方式，後設資料傳播更易擴充套件，追蹤亦更加精確。當然，我們的許多分析同樣也適用於其它方式。

後設資料傳播方式：和安全系統相似，端對端追蹤設計為分散式系統的一部分，效果最佳。許多實現設計成白箱系統，這樣組建可以被修改以產生後設資料，比如ID，用來描繪因果關係活動。所有基於後設資料傳播的實現用來甄別功能點或者追蹤點的執行因果聯絡，組合為日誌訊息，記錄系統特定時間特定的點。為了執行時的開銷降至最低，比如響應時間短，吞吐量小，因此，追蹤系統可以“一直線上”，此範疇的許多追蹤基礎系統抽樣僅收集小量的追蹤點或者工作流。

基於規則的方式：少量的實現，比如ETE、Magpie，它們不傳播後設資料，但要求開發者寫一個臨時的聯合規則，來確定定製化寫入的日誌訊息中，各變數的因果關係。基於規則的方式不相容抽樣，只有所有日誌都收集齊了，才能決定存在怎樣的因果關係。因此，此方式擴充套件性不及後設資料傳播方式。

黑盒推測方式：幾個端對端追蹤實現[2,6,25,28,38,44,45,53]不涉及追蹤系統的改造。而是依據關聯的變數或者已存在的日誌時序，或者簡化假設，來推測因果關係。儘管無需修改軟體就可以獲得端對端追蹤，聽起來確實不錯，不過此類方式不能恰當的抽提因果關聯，特別是非同步，比如快取，事件驅動系統，併發，聚類，或者特定程式碼的設計模式，比如儲存編碼，所有這些在分散式系統中都司空見慣。

2.3 端對端追蹤剖析

圖二剖析了大多數基於後設資料傳播的端對端追蹤基礎系統。軟體元件用來甄別分散式系統中那些已完成的工作，選擇性的保留因果聯絡，降低開銷，有選擇地持久化儲存這些追蹤資料，建立蹤跡，並將其呈現給開發者。整個過程包括追蹤點，因果追蹤機制，抽樣機制，儲存元件，追蹤構造程式碼和展示層。

開發這樣的基礎系統需要回答兩個關於設計理念的問題，來闡明基礎系統基礎功能。首先是，什麼樣的因果關係應該被儲存下來？儲存完整的開銷會非常大，並且儲存錯誤的會獲得那些無用的追蹤。針對前面小節甄別的用例，小節3描述了這些用例的那些因果關係應該被保留下來。

圖二：端對端追蹤系統剖析。典型的後設資料傳播追蹤基礎系統的各元件。

第二個設計理念：什麼樣的模型應該用來展示這種關係？領域模型僅能表示少有的幾種因果關係型別，儲存和檢索卻會更加有效；而昂貴的模型則會作出相反的折中。最流行的最特別的模型，為有向無環樹，有效地表達序列化、併發，或者遞迴呼叫/應答模式，比如在RPCs中的觀察。分叉和併發由分支表示，採用原版X-Trace [20],Dapper [43],和Whodunit [9]。 Dapper還對呼叫/應答模式做了優化，即採用儲存規則來方便檢索。而Pinpoint[11]利用路徑，有效地表示同步行為和事件驅動處理。

儘管很有用，樹卻不能用來表示擁有多個父節點的節點，在這些案例中，單個分散式系統事件，依賴好幾個前面的事件。比如聯結或處理依賴好幾個輸入。那儲存這些聯結對任務診斷就非常重要了，Stardust以及X-Trace修正版，採用通用的有向無環圖替代有向無環樹。原版Stardust同樣採用有向無環圖，建立原始工作提交者和聚類活動。Pip擁有DAGs一樣強大的力量，通過任務中的任意訊息來表述。

現在我們簡單地闡述基礎系統的基本元件，因果跟蹤機制在工作流中傳播後設資料，儲存我們想要的因果關係。這對端對端追蹤系統來說最重要了，以及核心設計決策見小節4.

單個追蹤節點顯示單個工作流訪問的程式碼庫的位置。執行一個追蹤點就會建立一個追蹤點記錄，所包含的資訊與執行追蹤點相關，相關的後設資料，以及任何開發者想獲取的附加資料，你如當前呼叫棧。而追蹤點通常嵌入進通用的庫中，比如RPC庫，並由開發者加入分散式系統重要的部分中。儘管許多關於在哪個位置新增追蹤點的設計決策，和日誌系統相似，但追蹤點還能甄別工作流結構，參看小節4.2，比如這樣結構的追蹤點可以用來追蹤分叉和合並。或者，二進位制重寫或者插入技術，比如面向切面程式設計，亦可以自動將追蹤點加入函式邊界，或者諸如分叉以及合併的地方。

許多追蹤基礎系統採用抽樣技術限制執行時以及儲存開銷。連貫的抽樣常常被用到，即要麼所有的，要麼沒有任何工作流追蹤點被抽樣。比如，採用連貫抽樣來持久化，比如穩定的儲存，所有工作流追蹤點記錄的百分之一都不到， Stardust [40]和Dapper [43] 為執行時開銷百分之一不到。選擇儲存什麼樣的因果關係，決定了應該選擇何種抽樣技術。小節5描述了不同的抽樣技術和利弊。

儲存元件持久化了追蹤點記錄，而追蹤構建程式碼合併追蹤點記錄，這些關聯的後設資料用來構建追蹤因果關係活動。這些元件是可選的，因為追蹤記錄無需持久化，倘若能夠線上分析。比如，對某些分析來說，這些足以傳播因果關係活動的重要資料，在執行的追蹤點讀取這些資料。

有幾個不錯的工程選項，比如Dapper，可以最大化程度減少持久化追蹤點記錄帶來的效能耗損。首先，在各控制元件處，抽樣追蹤點應非同步進行記錄，比如離開分散式系統的關鍵路徑。可以將記錄拷貝到一個，記憶體迴圈快取中，或者在快取滿時將至丟棄，然而啟用一個獨立的執行緒將快取中的追蹤點，寫入本地磁碟或者一個表中儲存。最後採用MapReduce構建追蹤。Stardus和Dapper建議儲存兩週的追蹤資料進行事後分析。

端對端追蹤基礎系統最後一個環節是展示層，負責將構建的追蹤資料展示給使用者，這對診斷相關的任務來說很重要。各種追蹤資料檢視化處理、利弊權衡在小節6進行討論。

3 理應儲存什麼樣的因果關係呢？

儲存因果關係活動是端對端追蹤的終極目標，理想的追蹤基礎系統應儲存所有真實的或必需的因果關係，甚至只儲存這些。比如，儲存工作流的單個服務請求及其背後的活動，讀後寫記憶體訪問，快取，檔案，註冊器，資料追蹤，請求內部因果關係，比如資源競爭，組合狀態等。

然而，瞭解活動之間真實的因果聯絡是困難的，正因如此，追蹤基礎系統藉助Lamport的發生前（happens-before）關係(→),假定a和b為兩個事件，a→b，那麼a或許會影響到b，因此b或許因果依賴於a。不過發生前關係僅是一種近似的真實因果關係：不加甄別，且不完整。很難做到完整，是因為很難知曉所有的影響管道，有些管道在系統之外。而不加甄別，是因為捕獲到了非因果關係，所帶來的影響未必是真的。

追蹤基礎系統對這種不加甄別做出了限制，利用系統知識和環境，捕獲僅為總髮生前圖的切面，這些部分很有可能包含必需的因果關係。首先，多數追蹤基礎系統對事件中的影響界限做出了假設。比如，假定一個記憶體保護模型，追蹤基礎系統或許會排除發生前邊緣（ happens-before edge），此類邊緣介於不同程式，甚至基於不同單個執行緒的事件系統。（小節4機制中的偽假設邊緣已被移除）
其次，或許要求開發者顯式地在分散式系統軟體中新增追蹤點，這些看似重要的點可以用追蹤追蹤點之間的因果聯絡 [11,19,20,37, 40, 43, 47]。

不同的切面用於不同的用例，但儲存所有切面開銷過大，即使最有效的軟體漏洞追蹤機制也會致使效能降低兩到八倍。正因如此，追蹤基礎系統僅儲存那些最有用的切面，來判斷輸出是怎麼執行的。接下來的小節我們來闡述各切面適用於各種用例。

3.1 請求內切面

一旦開發一個追蹤基礎系統，開發者必須一個發生前圖切面，定義這個分散式系統服務的工作流請求。發起請求的工作在執行前，應將客戶端的請求響應作為工作流的一部分。然而，隱式的工作，比如遺留在寫回快取中的資料，最終必須寫回到磁碟中，同樣也應成為發起請求的工作流部分，或者作為請求的一部分，保證請求工作執行，比如命令快取清空。通過觀察形成了兩個基本的請求間切面：發起者資訊儲存切面、觸發器資訊儲存切面，它們持有不同的資訊，應用於不同的用例中。首先，我們甄別了這些切面，它們之間的不同，試著理解為何原版的Stardust並不適用於診斷用。

小節3.1.1 和 小節3.1.2 描述涉及發起者資訊儲存切面、觸發器資訊儲存切面種種利弊。小節3.1.3列出了儲存這兩個請求間切面的優勢，而小節3.1.4討論繪製併發行為的益處，這些併發行為來自順序執行和儲存於單個追蹤的分叉合併。表格二顯示端對端追蹤系統的最有用的請求間切面。

3.1.1 發起者資訊儲存切面

儲存本切面，意味著端對端追蹤點，展示原始請求提交者和系統每個控制元件工作處理的因果關係。這對於資源屬性非常有用，因為使用模型要求端對端追蹤系統底層控制元件所做工作應與客戶端、工作負載，或者原始請求的發起者相關聯。Quanto [18],
Whodunit [9],以及原版的Stardust [47]儲存此類因果切面。圖三左邊兩個圖解，為分散式儲存系統的兩個寫請求的發起儲存追蹤。請求一將資料寫入系統快取中，並立即作出迴應。稍後，請求二進入系統，必須廢除快取中請求一的資料。為了儲存發起者因果關係，追蹤基礎系統儲存廢棄請求一的那部分，而不是請求二。而請求二追蹤僅展示延遲廢棄。注意追蹤基礎系統，請求二為一個後臺清理執行緒，而非客戶端請求引發的廢棄命令。

3.1.2 觸發器資訊儲存切面

圖三中，發起者儲存請求一的蹤跡，視覺化處理後，並不那麼直觀，且難以理解，這是因為傳送客戶端響應之後，請求工作才算完成。同樣，屬於此請求的延遲工作在請求二的關鍵路徑中得以執行（比如在迴應之後，追蹤點得到執行）。相反，觸發器因果關係確保一個請求追蹤顯示，所有執行的工作，而後才可以發出客戶端響應，包括另一個客戶端的延遲工作，它在本次關鍵路徑中得以執行。圖三右邊兩個蹤跡，顯示了發起者儲存例子中相同的請求，不過儲存的是觸發器因果關係。鑑於這些蹤跡，檢視化處理後，易於理解，最後以客戶端響應結束，並且顯示請求關鍵路徑所有的工作，儲存觸發器因果關係用來做任務診斷，通常涉及“為何請求如此地慢？”問題的答案。

實際上，從儲存發起者因果關係到儲存觸發器因果關係，或許這是我們對原版Stardust所做的最重要的改變，這樣做特別適合任務診斷。許多其它追蹤系統實現也隱式地儲存了這個因果關係切面[11,19,37, 43]。

表格二：內在流切面儲存各種預期的應用場景。觸發器和發起者儲存切面雖然不同，卻有相同必須的工作，因此均可以用來效能分析（profiling）。針對工作負載模型的因果關係選擇取決於工作負載的那些方面應該用來建模。

圖三：兩個儲存系統寫請求的追蹤體系，用來儲存因果關係的不同切面。請求一將資料放入一個寫回快取中，並立即返回客戶端。稍後，請求二進入系統中，必須執行命令，廢棄快取中請求一的資料。延遲工作，即高亮綠點標記的部分，或許屬於請求一，只要儲存發起者因果關係；也或許屬於請求二，只要儲存觸發器因果關係。左邊蹤跡顯示，執行追蹤點間的一分鐘延遲。而函式被呼叫執行所帶來的延遲，則不會顯示，比如Whodunit。

3.1.3 儲存這兩種切面是否可以獲得一切呢？

以上推薦的切面尤為重要，應該儲存起來用於各種用例，而不是單單儲存其中的一種。事實上，同時儲存發起者因果關係和觸發器因果關係，有助於更深入地理解分散式系統，這可能是儲存其中任何一個所無法比擬的。比如，診斷，儲存發起者因果關係的同時，再加上觸發器因果關係，追蹤基礎系統就可以回答諸如“誰應該負責廢棄我的客戶端快取資料？” 或者 更通用的問題，“那些客戶端可能會更多地干預其它客戶端呢？”

 3.1.4 儲存工作流結構（併發，fork，join）

對於發起者儲存因果關係和觸發器儲存因果關係，儲存工作流結構-併發行為，分叉和合並，為可選項。對於某些用例，這些是也沒有必要，比如資源屬性或者效能分析。而對診斷任務，這些卻是很有用的。儲存了併發和分叉，可以幫助開發者診斷並行過量或不足的問題。另外，儲存合併可以幫助開發者診斷同步點過度地等待，且容易鑑定出關鍵路徑。

原版X-Trace採用樹形結構建模因果關係，因此無法儲存合併。原版Stardust採用DAG，但並沒有檢測合併。為了更利於任務診斷，修正版的X-Trace採用DAGs，以及顯式地包含檢測合併API。

3.2請求間切面儲存

除了請求內部的關聯關係，請求之間或許存在很多型別的因果關係。本小節描述兩種最常見的切面。

競爭性儲存切面：請求之間資源爭奪，比如共享變數的訪問。諸多請求持有一個資源鎖，並等待獲取這個鎖，儲存這些因果關係有助於解釋，意料之外的效能減速，或超時，僅有Whodunit儲存本切面。

讀後寫儲存切面：讀取其它請求寫入的資料，比如快取或者檔案，此讀取請求或許會受到上下文的因果關係影響。舉個例子，由某個檔案上下文決定的工作，比如，一個map-reduce工作，其執行請求或許取決於檔案原始的寫者。儲存讀後寫依賴關係有助於解釋此類請求行為。

4 如何追蹤因果關聯關係？

所有端對端追蹤基礎系統必須探尋一種機制，即追蹤請求內部以及請求間的因果關係切面，這些很可能與預期的用例有關。為了避免捕獲膚淺的因果關聯關係，比如一些並非我們所希望的切面，或錯誤的因果關聯關係，追蹤基礎系統“執行緒”後設資料伴隨單個工作流，並採用相同或關聯的後設資料[9,11,19,20,37, 40, 43, 47, 48]，建立專案間的發生前關聯關係。小節4.1描述不同的後設資料型別和它們之間的權衡利弊。

總之，後設資料儲存線上程區域性變數中得以傳播，當單個執行緒執行因果關聯工作，並程式設計邏輯，傳播後設資料穿越常用的庫邊界，比如執行緒間，快取間，或控制元件間。我們認為，系統的設計應該具備這樣的功能，即通過執行流和訊息，合理傳播通用的後設資料，因為這是所有追蹤基礎系統的核心。

儘管下面討論的任何方式均可以通過建立發生前關聯關係，來儲存併發，還是需要額外的檢測來捕獲分叉以及合併。諸如結構性追蹤點會在小節4.2中進行討論。當然，追蹤基礎系統採用的因果關聯關係模型，必須能充分地表示併發、分叉、合併。

4.1 各後設資料型別的優劣

每種工作流後設資料既可以是靜態，也可以是動態的。動態後設資料有額外的固定寬度或可變寬度。決定採用何種後設資料時，有三個重要議題需要考慮。首先是大小，較大的後設資料必然導致較大的訊息，比如RPC，或者制約了有效載荷大小。其次是丟失、無法獲取的資料脆度或者彈性。最後，該方法是否無需構建追蹤，可實時獲得全部的追蹤資訊，或者其它分析所需的資料。

比較這三種方式，相比可變寬度方式，固定寬度的方式限制後設資料的大小。固定寬度方式對資料的獲取性或丟失敏感，不一樣的只是方式和程度的問題。動態、可變寬度的方式，對資料丟失有極大的彈性，不過以犧牲後設資料的大小為代價。另外，動態、可變寬度的方式通常是避免構造追蹤所必須的。表三總結了各種後設資料傳播方式的優劣。接下來，將會更詳細地描述這些方式。

靜態、固定寬度後設資料：擁有此方式，單個後設資料值，比如隨機選擇的工作流ID，用來鑑別所有因果關聯活動。追蹤系統實現採用此方法，需要顯式地構建蹤跡，採用相同後設資料，對不同追蹤點的日記進行合併。一旦開始做，就必須依賴儲存於追蹤點日誌中的線索，建立發生前關聯關係。比如，為了使單執行緒中的因果關聯活動變得有序，必須依賴外部的時鐘。網路訊息必須經客戶端發出後，才會被伺服器端接收，正因如此，追蹤基礎系統依賴同步時鐘，或許就可以建立客戶端和伺服器端工作的發生前因果關聯關係，即使用網路對這兩臺機器上的追蹤點進行收發。而為了鑑定控制元件內部的併發工作，追蹤實現採用此方式，通過執行緒ID，建立發生前因果關聯關係。Pip [37], Pinpoint [11], 和Quanto [18]採用靜態、固定寬度的後設資料。

該方法很是脆弱，可能會不恰當地序列化，丟失外部線索，比如，追蹤點日誌丟失；或者無法獲取，比如開發者無法修改分散式系統程式碼庫的任意區域。舉個例子，執行緒ID丟失或者不可用，導致無法恰當地鑑定控制元件內的併發活動。

動態、固定寬度後設資料：用本方法，除了工作流ID，簡單邏輯時鐘，比如單個64位的值，用來嵌入到後設資料中，幫助追蹤基礎系統編碼發生前關聯關係，無需依賴外部線索。單個邏輯時間戳用來限制後設資料大小。而向量時鐘（Vector clocks）不適用於固定寬度的後設資料，因為向量時鐘要求後設資料的寬度和整個分散式系統執行緒數目一致。在每個追蹤點中，一個新的隨機邏輯時鐘值會被選中，而後將新、舊邏輯時鐘存入相應的追蹤日誌中，來建立一個發生前關聯關係。每個追蹤點的自增計數器，同樣被用來實現邏輯時鐘，但作為序列化的併發訪問顯然是不夠的。兩個版本的X-Trace [19,20]採用動態、固定寬度後設資料。而Dapper [43]以及兩個版本的Stardust [40, 47]採用混合的方式，即動、靜態，固定寬度後設資料方式。例如，Stardust [40, 47]依賴外部時鐘有序化控制元件內部活動，同時採用邏輯時鐘有序化元件間訪問。

同樣，動態、固定寬度方式是脆弱的，一旦追蹤點日誌的某部分丟失，就很難有序化這些日誌。比如，某個追蹤點日誌丟失，本方法便無法序列化這兩個追蹤片段，它們擁有完全不同的邏輯時鐘值，因此不存在顯式的發生前因果關聯關係。而混合式方法，很少頻繁地改變後設資料的值，因此相較於那些追蹤點後設資料不停變化的方式，收到的影響小很多。還有一種減低脆性，卻耗空間的方式。

表三：各後設資料型別的優劣。靜態、動態、固定寬度方式為固定大小，比如，最小為一個或兩個65位元值，但很脆弱，不能實時地使用這些追蹤資料。而動態可變寬度方法，引入線段樹（interval-tree）時鐘獲得彈性，可以實時地獲取追蹤資料，不過這樣產生的後設資料量很大。比如，後設資料的大小與請求內併發量，以及執行函式的數目成比例。而組合方式是一個很好的平衡（inflection point），比起純粹的靜態或動態方法，它的不那麼脆弱，而且大小為一個常量，比如最小值為兩個64位元值。

動態、可變寬度後設資料：擁有此方法，賦值給因果關聯關係活動的後設資料大小是可變的。這樣做，後設資料包含線段樹時鐘，而非簡單的邏輯時鐘。和向量時鐘相似，線段樹時鐘減低了脆性，任何兩個時間戳之間的比較，可以確定它們是併發，還是一前一後。與向量時鐘不同的是，線段樹時鐘按執行緒數目成比例增加或減少。而可變寬度的向量時鐘無法縮減，因此它的寬度需和工作流中最大的執行緒數目成比例。同時，向量時鐘需要一個全域性獨一無二，廣為人知的執行緒ID。截止目前，沒有一個追蹤基礎系統採用向量時鐘或線段樹時鐘。

倘若追蹤基礎系統希望迅速地獲取全部的蹤跡，或者其它需要將因果關聯活動聚集在一起的資料，而且無需顯式地構建蹤跡，這就必須使用動態、可變寬度的後設資料。 比如，採用動態、可變寬度的後設資料追蹤基礎系統，會攜帶後設資料中已執行的追蹤點日記，一旦工作流結束，日記就可以拿來使用。Whodunit [9]是目前唯一一種後設資料中攜帶追蹤點日記（比如函式名）的追蹤系統實現。為了減少後設資料的規模，啟發式程式設計用來減少傳播追蹤點日記數量，不過這樣蹤跡真實性也打折扣。

4.2 如何儲存分叉（fork）、合併（join）？

對於上面討論的靜態、動態，固定寬度的後設資料傳播方式，分叉以及合併可以通過一對多和多對一追蹤點進行儲存。對靜態方式，此追蹤點必須包含這樣的線索，能夠鑑別出特定的分叉活動，或是等待活動，比如執行緒ID。對動態、固定寬度的方法，一對多追蹤點應該包含當前邏輯時鐘值，並且初始化的邏輯時鐘值為後來的每個分叉後代所用。而合併追蹤點需包含當前邏輯時鐘值，以及所有事件的邏輯時鐘值，這些必須在工作處理之前就做好。動態、可變寬度方法，倘若包含線段樹時鐘，便可推測分叉以及合併。

Mann等人採用另一種方式，即比較海量蹤跡，自動地確定分叉點、以及合併點。

5 何種抽樣才能降低開銷？

抽樣決定追蹤基礎系統持久化那些追蹤點日記。端對端追蹤基礎系統最核心的技術問題就是減小執行時以及儲存開銷 [9,
19, 40, 43, 47]。舉個例子，即使Dapper非同步地將追蹤點日記穩定地儲存起來，譬如分散式系統關鍵路徑，一個網路搜尋工作負載持久化所有追蹤點，它依舊佔用1.5%的吞吐量，16%響應時間開銷。 而抽樣捕獲0.01%的追蹤點資訊，響應時間降至0.20%，吞吐量降至0.06%。即使追蹤點日記無需持久化，線上分析，抽樣依舊可以減少特定分析資料結構的大小。

這裡有三個不同的基本選項，來決定抽取什麼樣的追蹤點：基於頭一致性的抽樣，基於尾的一致性抽樣，或者整體抽樣。一致性抽樣方法，確保工作流執行的所有全部追蹤點，要麼全部被抽樣，要麼都沒有；在蹤跡構建時，必須使用此方法，此蹤跡用來展示因果關聯活動。另外，基於頭的抽樣倘若用來儲存發起者因果關係，會導致高昂的開銷。圖四展示了不同抽樣規則之間的利弊，用它們儲存不同的因果關係切面。接下來我們會進一步描述抽樣規則。

基於頭一致性的抽樣方式：使用此方式，在整個工作流的起始，比如請求進入系統時，建立一個隨機抽樣決策；後設資料沿著工作流傳播，表明是否在收集追蹤點。工作流隨機抽樣百分比由設定的工作流抽樣百分比決定。和儲存觸發器因果關聯的追蹤基礎系統結合後，工作流抽象百分比和追蹤點抽樣百分比持平。因為簡單，基於頭一致性抽樣方法應用於很多現有的追蹤基礎系統 [19, 40, 43]。

圖四：採用不同抽樣規則、儲存不同因果關係切面的抽樣追蹤點。本例中，四個圖樣中最右邊的工作流引發廢棄命令，作為程式的一部分，聚集其它快取塊中的延遲工作。基於頭的抽樣在工作流起始階段是否抽取。正是如此，儲存發起者因果關係時，採用基於頭的抽樣方法，那麼聚集有延遲工作（本例中工作流強制執行廢棄命令）的工作流執行的所有追蹤點，倘若有任何一個聚集集由抽樣工作流插入系統中，就必須被抽樣。對於每一個聚集，個體追蹤點被抽樣的概率就會增加，高昂的儲存和執行時開銷。而基於尾部抽樣方法，遵從抽樣決策，一旦工作流結束，追蹤點被抽樣的概率並不會因為聚集而大幅膨脹。不過，它所需要的追蹤點日誌，在延遲工作聚集前，該工作流需將延遲工作快取起來。同樣，整體抽樣也不存在抽樣膨脹，無需一致性地捕獲工作流追蹤點日記。但是採用整體抽樣，用來構建蹤跡或必要分析的資料，必須以後設資料的方式傳播，並儲存在追蹤點日記中。最右邊圖樣顯示，基於頭的抽樣方法，以極低的開銷儲存觸發器因果關係，這是因為延遲工作一直歸屬於聚集器。正因如此，僅有針對聚集器的抽樣決策才起作用，是否對執行的追蹤點進行抽樣。

基於頭一致性抽樣方式，在追蹤基礎系統儲存發起者因果關係時，並不能降低執行時、儲存開銷。這是因為有效的追蹤點抽樣百分比，多數時候高出工作流抽樣百分比很多。為了理解這一點，不妨回想一下儲存發起者因果關係，延遲工作屬於原始的發起者。因此，一旦延遲工作被另外一個請求，或者後臺活動聚集，聚集器執行的追蹤點必須抽樣，這樣抽樣的工作流得以將任意一個聚集集插入系統中。在許多系統中，此程式幾乎會抽樣到底層系統所有的追蹤點。比如，倘若基於頭的抽樣方法，僅對0.1%的工作流，進行追蹤點抽樣。聚集前單個追蹤點抽樣概率也是0.1%。然而聚集32個專案後，概率上升至3.2%；經過過兩個這樣級別的聚集後，追蹤點抽樣百分比上升至65%。圖四左邊圖樣展示了單個級別聚集的膨脹過程。所有追蹤點有效抽樣百分比取決於幾個引數：工作流抽樣百分比、聚集級別數目，聚集級別之間的追蹤點數目。

開發修正版Stardust [40]時，我們瞭解到基於頭一致性的抽樣方法和發起者因果關係不相容。基於頭的抽樣方法作為第一個特徵放入原版Stardust，早期Stardust沒有抽樣，也不儲存發起者因果關係。那時，關於因果關係切面，或者這些切面如何與不同的抽樣技術互動，我們都一無所知。因此，當我們將可抽樣的Stardust應用於我們的分散式測試系統Ursa Minor [1]時，令人困惑的是追蹤的開銷沒有降下去。當然，最重要的原因是，Ursa Minor包含一個快取，此快取靠近系統入口，一次聚集32專案。假如抽樣的比例為10%，意味著聚集後，已執行追蹤點有97%被抽樣。

基於尾的一致性抽樣方法：本方法和前者相似，只是工作流抽樣決策發生在工作流的末尾，而非伊始。延遲抽樣決策可以得到更智慧的樣本-舉個例子，追蹤基礎系統可以檢測工作流屬性，比如響應時間，並且只收集異常的那些屬性。生成抽樣決策之前，每個工作流的追蹤點日誌必須快取起來。併發執行的工作流有很多，每個請求都能執行很多追蹤點，攜帶有延遲工作的工作流依舊會在系統中停留很長一段時間，不過這些收集的臨時資料並不是一直有效的。

基於尾的抽樣方法避免了追蹤點抽樣百分比過度膨脹，因為它無需提前提交抽樣決策。正是如此，可以用來儲存發起者因果關係活動，並且保持較低的執行時、儲存開銷。對於攜帶聚集工作的工作流，基於尾的抽樣方法，確保攜帶有已聚集工作的工作流，所執行的所有追蹤點要麼全部被抽樣，要麼完全沒有被抽樣。要完成這個，需要維護一個對映，聚集器的工作流ID以及已聚集工作的工作流ID。圖四最左邊第二個圖樣，儲存發起者因果關聯活動時，採用基於尾抽樣方法，追蹤點日記必須快取起來。因此對記憶體的要求比較大，所有很多追蹤基礎系統並不會用它。

而一些追蹤基礎系統採用組合規則，這些系統名義上採用了基於頭一致性抽樣方法，其實它們也在每個節點的迴圈緩衝中存入最近執行過的追蹤點日記。迴圈緩衝常被調整用來確保，一個請求追蹤點日記不會被廢棄，只要其執行的時間沒有超過50或者75百分位。此技術可以幫助追蹤基礎系統追蹤收集，馬上出現異常的然而並沒有抽樣的工作流，比如失敗或者開始執行不久後出現的錯誤。儘管如此，對於某些出現的異常情形依然是不夠充分的，比如執行時間很長的請求。

整體抽樣方法：採用本方法，開發者可以直接設定追蹤點抽樣百分比，在單個追蹤點設定抽樣決策。不存在連貫性，因此通過此方法，蹤跡是沒法構建的。本方法最適合諸如資源屬性這樣的用例，需要分析的資訊跟著工作流程式傳播，直接從單個追蹤點獲取。

除了決定如何抽樣追蹤點，開發者必須確定對其中的多少追蹤點進行抽樣。許多基礎系統選擇隨機地抽取一小部分，設定追蹤點或者工作流的百分比-通常介於0.01%和10%之間。然而本方法只是捕獲了少部分工作負載，其中很小的一部分追蹤點，限制了它的使用。不過採用每個工作負載抽樣百分比可以幫助我們，不過這需要預先知道工作負載的大小。一種更加靈活的方式，由Sigelman等人提出[43],作為一種自適應方式，追蹤基礎系統用來捕獲一組追蹤點或工作流執行速率，比如500追蹤點每秒，或100工作流每秒，並且動態地調整追蹤點或工作流抽樣百分比完成這個設定的目標。儘管看起來不錯，不過還是要小心避免偏差的結果，特別是捕獲的資料用來進行統計時。建立在共享服務之上的分散式服務，自適應的抽樣速率應取決於追蹤開銷，最底層的共享服務能支援，並等比例地傳播到頂層服務。

6 如何對蹤跡進行檢視化處理？

良好的檢視化處理對諸如診斷、效能分析這樣的用例非常重要。有效的檢視化處理會讓開發者的工作事半功倍，而無效的則事倍功半，使得開發者不得不尋找其它的替代工具和技術[30,39]。確實如此，Oliner等人將檢視化處理作為未來診斷研究的核心挑戰之一[34]。本小節描述的是一種通用的檢視化端對端蹤跡方式。具體選擇什麼樣的方式取決於檢視化預先設定的用處，前期的設計選擇，以及精確度是否高於要展示的資料量。還有，底層蹤跡展示限制了檢視化的使用。DAG支援本節中的任意方法，當然，幾乎所有的流圖亦可以構建自有向樹。

表四總結了各種檢視化處理的利弊。圖五顯示不同的檢視化處理在請求展示方面的不同。而Pip採用非檢視化蹤跡的方式，即採用特定語言文字化地描述蹤跡。正式的使用者研究需要比較檢視化處理和特定語言文字描述的相對優劣，這裡我們不做相關分析。

甘特圖又稱甬道：此類檢視常用來展示單個蹤跡，同樣，可以用來檢視化具有相同工作流的多個請求。Y軸展示了整個請求，分散式系統發起的子請求；而X軸顯示了相對的時間。Y軸上專案的相對起始時間和延遲（現實時間測量值）由橫向的棒進行展示。併發很容易通過棒在X軸重疊的部分得以檢視化的鑑別出來。同樣，分叉以及合併也必須通過檢視化的方式加以鑑別，不過難度要大一些。ETE [23]和Dapper [43]均採用甘特圖來檢視化單個蹤跡。Dapper除了展示整個請求和子請求的延遲，還可以鑑別網路時間開銷，即已觀察的請求或子請求延遲減去伺服器端的時間花銷。

流向圖又稱請求流向圖：這些有向無環圖，在請求於分散式系統各元件中執行時，真實地反映了請求的工作流程。它們常被用來檢視化，顯示具有相同工作流的多個請求聚集資訊。正因為此類請求通常擁有相似的執行流程，流向圖被認為是一種非常好的儲存精確度的方式，特別是發起多個請求時。圖中的扇出（Fan-outs）表示併發活動（分叉）的開始，不同分支上的事件即併發，而扇入（Fan-in）表示同步點，即合併。在修正版的Stardust [40]和X-Trace [19]通過流向圖對蹤跡進行檢視化處理。

呼叫圖和焦點圖：檢視通常用來展示多個蹤跡，但不展示併發，分叉或者合併，因此也就談不上精確了。呼叫圖採用扇出顯示某個父函式對子函式的呼叫。焦點圖則顯示一個控制元件或函式，即所謂的“焦點節點”的呼叫棧，而呼叫圖將焦點節點作為根節點。總的來說，焦點圖特別適合診斷任務，開發者已知那些函式或控制元件有問題。Dapper用焦點圖展示具有相同工作流的多個請求，不過由於面向RPC的自然屬性，節點代表的不是控制元件或函式，而是客戶端和服務端執行的所有RPC工作。注意，一旦採用不同的工作流來檢視化多個請求，呼叫圖對路徑的展示將變得不可用[4]。圖五為a → b → c → d路徑的呼叫圖。

表四：不同蹤跡檢視化展示技術的利弊。不同的檢視化展示技術精度不一，倘若能顯示分叉、合併、以及併發，則表示為Y；需要推理，則表示為I。同樣，它們在多工作流展示方法的功能也不盡相同，是否為多個工作流是有差異的。從我們的經驗來看，這些檢視可以展示包含上百個追蹤點的蹤跡。注意，儘管呼叫圖和焦點圖有時會用來檢視化多個不同的工作流，但它們不具備路徑的展示功能。

圖五：不同檢視化蹤跡方式比較。甘特圖通常用來檢視化單個請求，流向圖則可以檢視化具有相同工作流的多個請求，同時展示分叉、合併、以及併發。不過對於不同的工作流，甘特圖和流向圖就必須單獨去顯示了。而呼叫上下文樹傳統的精度，則可以檢視化不同工作流的多個請求，比如整個工作負載。同樣，呼叫圖可以展示多個工作流，不過可能無法真實地反映正確的執行路徑。比如，呼叫圖所示的e a → b → c → d路徑，並沒有出現在請求一或二中。

呼叫上下文樹（CCTs）[4]:此檢視特別適合不同工作流多個請求顯示，確保每一個經過分散式系統，從根節點到葉節點的路徑均為合法路徑。為此採用一種很緊湊的方式，CCTs採用扇出的方式顯示函式呼叫，而非分叉，正因如此，它的精度有限。CCTs可以通過分期常數時間構建，特別適合諸如高階別的系統行為總結等任務，比如效能分析。Whodunit [9]通過CCTs進行工作負載效能分析。

7 縱覽全域性

基於上文描述的利弊和我們的過往經驗，本小節針對端對端追蹤系統核心用途，而提出的良好設計選擇。同樣，我們也給出了前人的實現選擇，並與我們建議的做比較。

7.1 推薦選項

表五斜字型行為端對端追蹤系統核心用途提供的設計選擇。對於因果追蹤機制，針對多數用例，我們建議採用靜態、動態組合，固定寬度方式，這就要求大小為常數，降低對外部線索的依賴，比起直接的動態、固定寬度方法彈性要好些。同樣靜態後設資料也是一個不錯的選擇，你需要的外部線索，比如建立發生前關係，會一直存在；或很多事件需要的線索，比如分叉、合併、併發，無需儲存。開發者需要考慮可變寬度方式是否可用，可否拿來使用。對於需要一致性抽樣的用例，我們謹慎地推薦採用基於頭的版本，如果它能滿足需要的話；而基於尾的一致性抽樣方法，同樣也值得考慮，除了具備前者所具備的之外，用途更加寬泛。接下來介紹什麼樣的用例應採用怎樣的設計。

表五：針對不同的用例，本文所推薦的設計選項，以及現有追蹤系統所採用的設計選項。推薦的選項用斜體字表示，而已存在的實現設計選項，按照推薦選項的類似的方式排序。為了便於比較，基於規則的方式，比如Magpie and ETE同樣，也包含在內。Stardust和X-Trace的修訂版已Stardust‡、X-Trace‡形式進行表示。靜態的後設資料傳播方式記為S，動態、固定寬度的方式記為DF，組合、固定寬度的方式記為S/DF,動態、可變寬度的方式記為DV。而V表示已陳述的專案某種變體。

異常檢測：本用用於對罕見工作流的鑑別，與其它工作流差異很大，因此便於開發者分析。正因如此，應採用基於尾的一致性抽樣方法，一是便於蹤跡構建，二是追蹤基礎系統在決定是否抽樣前，評估工作流是否異常。不論是觸發器因果關係，或是發起者因果關係均可以以極低的開銷得以儲存。不過前者更受歡迎，工作流在檢視化後，觸發器因果關係可以展示關鍵路徑，更容易被理解。為了鑑別來自並行過度、並行不足，併發過度等待異常，系統實現應儲存分叉、合併、以及併發行為。流向圖最適合對異常進行檢視化處理，精確度高，而且異常檢測不會產生太多結果。同樣，甘特圖也不錯。

穩定性問題診斷：用例涉及效能問題、正確性問題診斷，這些問題常見於諸多請求中。它的設計選項和異常檢測，不同的是，需要使用基於頭的抽樣方法，因為即便是低速率的抽樣，問題依然不難被察覺。

分散式效能分析：本用例涉及抽樣函式，追蹤點間延遲。控制元件間、控制元件內函式棧呼叫必須儲存起來，以便抽樣專案能夠基於上下文得以聚集，不過完整的蹤跡無效構建。呼叫棧被緊湊地表示，這就要求抽樣方法，動態、可變寬度的後設資料傳播方法必須有效地整合。整合後，這些選項有助於追蹤點日記以後設資料的形式存在，效能資料線上收集。如果需要考慮後設資料大小，可以採用固定寬度後設資料，結合基於頭，或者基於尾抽樣的方式，不過線上效能分析就變得不可能。棧的呼叫無需儲存分叉、合併、或者併發。CCTs特別適合對分散式效能進行檢視化處理，可以顯示整個工作負載，並且不會出現錯誤路徑。

資源屬性：本用例涉及系統任意級別工作歸屬原始發起者問題，因此發起者因果關係必須儲存。資源屬性最好的服務方式為動態、可變寬度的後設資料傳播方式，以及整體抽樣方法。這樣組合有助於聚集專案的客戶端ID以後設資料的形式存在，因此可以實時、線上分析，無需構建蹤跡。倘若需要考慮後設資料大小，可以採用基於尾抽樣和固定寬度後設資料加以替換，不過線上、實時分析則難以實現。當然基於頭抽樣也可以用，不過帶來的開銷很大，在低階別的聚集後，便會抽取幾乎所有的追蹤點。儘管分叉、合併、併發並不需要儲存，DAG必須作為底層資料模型被使用，用來儲存原始發起者和聚集工作的關聯關係。最後，本用例無需檢視處理。

工作負載建模：本用例的設計決策取決於什麼樣的工作負載屬性需要建模。比如，Magpie [5]建模工作負載，主要鑑別一組資源使用相關的流，資源使用代表了整個工作負載。正因如此，Magpie儲存分叉、合併、以及併發行為非常有用。倘若要對本用例檢視化，可以採用流向圖，或CCTs，它們一次可以檢視化多個蹤跡。

7.2 現有系統實現選項

表五同樣列出了現有追蹤系統實現符合本文所倡導的設計維度。追蹤系統實現多數可以依據用例進行分組，當然一個追蹤系統實現或許適用於多個用例。對於一個既定的用例，追蹤系統實現按照推薦設計選項相似的方式排序。這樣的排序表明，適合某個特定用例的追蹤系統實現，亦傾向作出我們所推薦的相似設計決策。接下來描述我們所推薦的核心案例與追蹤系統實現選項的不同所在。

對於異常檢測，我們建議使用基於尾的抽樣方法，不過Magpie [5]和Pinpoint [11]沒有使用任何抽樣技術。收集和儲存每個請求的追蹤點，確保這兩種系統實現不會丟失任何稀有事件，即異常；不過這樣它們則無法擴充套件處理大規模工作負載。Magpie無法抽樣，是因為不能傳播後設資料。而Pinpoint主要關注正確性異常，因此沒有必要儲存併發、分叉、合併。

對於穩定性診斷問題，我們建議對分叉、合併、以及資料結構進行顯式地儲存，不過Dapper沒有儲存合併，因為它採用樹作為模型，表達因果關聯關係，而非有向無環圖。Mann等人[31]近期的工作，是對大規模Dapper蹤跡進行比較，集中關注習得合併點（learning join-point）位置。接著，Dapper蹤跡被格式化以便展示習得的合併點。同樣Pip [37]不同於其它追蹤系統實現的地方，就在於使用了特定的文字表達語言描述蹤跡。Pip語言描述其它控制元件與某個開發者關切的控制元件之間如何進行互動，功能與焦點圖相似。特定文字描述語言和焦點圖特別適用這樣的場景，開發者腦海裡已在關注某個控制元件，而問題定位性任務則行不通。

修正版的Stardust [40]和X-Trace [19]使得原版在修改後更利於診斷任務。這兩個修正版均獨立地傾向於使用幾乎所有相同的設計選項。
Sambasivan等人最初嘗試使用原版Stardust,它對於資源屬性設計停留在理念中；而診斷分析則是不充分的，這就激發了人們對修正版的需要。而Fonseca等人設計的原版X-Trace用來做診斷任務的。但通過X-Trace應用於真實系統的經歷，開發者發現針對修正版所列出的設計選項比原版有用多了。

對於分散式效能分析，已有的追蹤系統滿足、甚至超越了我們的所建議的。然而對於資源屬性，已有系統則沒有使用抽樣方法，亦不能擴充套件。

8 機遇和挑戰

儘管端對端追蹤體系被證明是有用的，許多重要的挑戰依舊，此體系還有很多潛力待挖。此類系統起於收集並展示追蹤資料，即今天大型可擴充套件分散式系統所產生的複雜的海量蹤跡。同樣，我們只是觸碰端對端追蹤體系開發分析技術的冰山一角；當然許多機會依舊存在，這個富有的資料來源有待更好的挖掘。

8.1 追蹤收集中的挑戰

隨著監測體系在大小和工作負載方面的擴充套件，追蹤基礎系統必須適應更大、更復雜、更大吞吐量的蹤跡，同時還要維護追蹤資料關聯性。儘管基於頭的抽樣方法滿足核心挑戰的頭兩個標準，但它無法保障蹤跡的關聯性。比如，對於特定蹤跡的診斷會變得複雜，而且無法捕獲稀有的漏洞，比如異常。而基於尾的抽樣，追蹤點先會快取起來，直到請求完成，滿足相關性的標準，但卻不滿足頭兩個要求。

還有一種中間方式，即一旦對請求失去興趣，所對應的追蹤點就會被遺棄，看似一種不錯的方案，不過在啟用此方法前，需要認真要求蹤跡屬性，確定蹤跡棄用的最佳時機。另一種替代方式，收集通用案例低辨識度的蹤跡，僅在對某個的蹤跡感興趣時，增加辨識度。儘管如此，此方式依舊需要回答中間方式類似的研究問題。

另一項挑戰，端對端追蹤系統共享日誌，這涉及到蹤跡的解釋性。許多案例中，負責分散式系統檢測的開發者，往往和蹤跡分析結果使用並非同一類人。這就會導致混亂，因為大家的所在的環境和專業技能不同。比如，在最近的使用者研究中，Sambasivan等不得不手動的翻譯端對端蹤跡中開發者創造的追蹤點命名，這樣便於綜合分散式系統專家更好的理解。為此，重點研究必須關注，如何定義良好的檢測實踐，如何激勵這種優良檢測，如何教育使用者對檢測蹤跡或日記作出解釋。自動化檢測研究和執行時再檢測，比如DTrace [8]，有助於減少檢測負擔，提供解釋性。

最後一項挑戰是端對端追蹤基礎系統之間的整合。今天的分散式服務由許多獨立開發的部分組成，或許檢測也是由多個不同的追蹤基礎系統組成，比如，Dapper [43], Stardust [40, 47], Tracelytics [49], X-Trace [19,20], or Zipkin [50]。除非它們可以互動，否則我們會失去獲得組合服務真實的端對端蹤跡。源（provenance）社群已朝這個方向在前進，創造了開源的源模型，這個還需仔細甄別。

8.2 檢視化處理中的挑戰

隨著端對端蹤跡量和規模的增加，明白如何有效檢視化蹤跡成為一項重要挑戰。小節6所描述的技術，擴充套件成百個追蹤點為宜，而許多分散式服務產生的追蹤點遠比這多的多。比如，Wang [52]認為諸如Graphviz [22]的工具，無法有效地檢視化HDFS蹤跡，因為寫的大小為64MB甚至更大，所產生的單個蹤跡包含1000個追蹤點。即使擁有100追蹤點的導航圖對使用者也是一個挑戰，更多參見Sambasivan等人的研究[39]。大型端對端蹤跡更高層次的總結會很有幫助，但怎樣儲存恰當的屬性是必需的，包括多個層次的細節，採用富有意義的方式或總結或瓦解子圖。互動至上有助於使用者只過濾、查詢、展示關聯的資訊。

8.3 蹤跡分析中的機遇

本文所描述的端對端追蹤用例僅是所有潛在用例的一部分。依舊有大量的機會發現更多的。比如，最近的研究致力於利用端對端蹤跡自動鑑別大型分散式系統中的瓶頸服務，並分配額外的資源給它們。同樣，許多研究機會依然存在於本文鑑別過的用例中。例如，診斷分析、蹤跡間縱向地比較有助於甄別出分散式系統控制元件間的離群值（outliers）或令人不快的差異。Spectroscope [40]採用統計學手段鑑定圖之間的時序差異，採用簡單的啟發式演算法比較它們的結構，僅是一個開始，還遠遠不夠。研究應深入到更先進的技術上，比如圖核[42]，頻繁子圖挖掘[24]，用於這樣的比較。沿著這些路線，Eberle等人[16]開發出一種有潛力的技術手段來鑑別結構性異常。儘管前景不錯，但此類技術是否可擴充套件，同時還滿足端對端蹤跡中對結構、標籤、時序、領域語法展示的要求，依然存疑。

9 總結

端對端追蹤系統有多重實現形式，而不同的實現使用的蹤跡結果分析，服務於不同的開發和管理任務。基於開發追蹤基礎系統的經驗和過往研究，本文為此類基礎系統設計者提供了指南，並拎出了研究者頗有爭議的問題。

參考文獻

[1] Michael Abd-El-Malek, William V. Courtright II, Chuck Cranor, Gregory R. Ganger, James Hendricks,Andrew J. Klosterman, Michael Mesnier, Manish Prasad, Brandon Salmon, Raja R. Sambasivan, Shafeeq Sinnamohideen, John Strunk, Eno ereska, Matthew Wachs, and Jay Wylie. Ursa minor: versatile cluster-based storage. In FAST’05: Proceedings of the 4th USENIX Conference on File and Storage Technologies,December 2005. Cited on page 12.

[2] Marcos K. Aguilera, Jerey C. Mogul, Janet L. Wiener, Patrick Reynolds, and Athicha Muthitacharoen. Performance debugging for distributed systems of black boxes. In SOSP ’03: Proceedings of the 19th ACM Symposium on Operating Systems Principles, 2003. Cited on pages 1 and 4.

[3] Paulo S. Almeida, Carlos Baquero, and Victor Fonte. Interval tree clocks: a logical clock for dynamic systems. In OPODIS ’08: Proceedings of the 12th International Conference on Principles of Distributed Systems, 2008. Cited on page 11.

[4] Glenn Ammons, omas Ball, and James R. Larus. Exploiting hardware performance counters with ow and context sensitive proling. In PLDI ’97: Proceedings of the 11th ACM SIGPLAN Conference on Programming Language Design and Implementation, 1997. Cited on page 15.

[5] Paul Barham, Austin Donnelly, Rebecca Isaacs, and Richard Mortier. Using Magpie for request extraction and workload modelling. In OSDI ’04: Proceedings of the 6th USENIX Symposium on Operating Systems Design and Implementation, 2004. Cited on pages 1, 3, 4, 16, and 17.

[6] Ledion Bitincka, Archana Ganapathi, Stephen Sorkin, and Steve Zhang. Optimizing data analysis with a semi-structured time series database. In SLAML ’10: Proceedings of the 1st USENIX Workshop on Managing Systems via Log Analysis and Machine Learning Techniques, 2010. Cited on page 4.

[7] Michael Burrows. e Chubby lock service for loosely-coupled distributed systems. In OSDI ’06:Proceedings of the 7th USENIX Symposium on Operating Systems Design and Implementation, 2006. Cited on page 1.

[8] Bryan Cantrill, Michael W. Shapiro, and Adam H. Leventhal. Dynamic instrumentation of production systems. In ATC ’04: Proceedings of the 2004 USENIX Annual Technical Conference, 2004. Cited on page 18.

[9] Anupam Chanda, Alan L. Cox, and Willy Zwaenepoel. Whodunit: transactional proling for multi-tier applications. In EuroSys ’07: Proceedings of the 2nd ACM SIGOPS European Conference on Computer Systems, 2007. Cited on pages 1, 3, 4, 5, 7, 8, 9, 11, 13, 15, 16, and 17.

[10] Fay Chang, Jerey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A. Wallach, Michael Burrows,Tushar Chandra, Andrew Fikes, and Robert E. Gruber. Bigtable: a distributed storage system for structured data. In OSDI ’06: Proceedings of the 7th USENIX Symposium on Operating Systems Design and Implementation, 2006. Cited on pages 1 and 13.

[11] Mike Y. Chen, Anthony Accardi, Emre Kiciman, Jim Lloyd, David Patterson, Armando Fox, and Eric Brewer. Path-based failure and evolution management. In NSDI ’04: Proceedings of the 1st USENIX Symposium on Networked Systems Design and Implementation, 2004. Cited on pages 1, 3, 4, 5, 6, 8, 9, 10,16, and 17.

[12] David R. Cheriton and Dale Skeen. Understanding the limitations of causally and totally ordered communication. In SOSP ’93: Proceedings of the 14th ACM Symposium on Operating Systems Principles, 1993. Cited on page 6.

[13] Cloudera HTrace. http://github.com/cloudera/htrace. Cited on page 1.

[14] Compuware dynaTrace PurePath. http://www.compuware.com. Cited on page 1.

[15] Jerey Dean and Sanjay Ghemawat. MapReduce: simplied data processing on large clusters. In OSDI ’04: Proceedings of the 6th USENIX Symposium on Operating Systems Design and Implementation, 2004. Cited on page 9.

[16] William Eberle and Lawrence B. Holder. Discovering structural anomalies in graph-based data. In ICDMW ’07: Proceedings of the 7th IEEE International Conference on Data Mining Workshops, 2007. Cited on page 19.

[17] Ulfar Erlingsson, Marcus Peinado, Simon Peter, and Mihai Budiu. Fay: extensible distributed tracing from kernels to clusters. In SOSP ’11: Proceedings of the 23nd ACM Symposium on Operating Systems Principles, 2011. Cited on page 5.

[18] Rodrigo Fonseca, Prabal Dutta, Philip Levis, and Ion Stoica. Quanto: tracking energy in networked embedded systems. In OSDI ’08: Proceedings of the 8th USENIX Symposium on Operating Systems Design and Implementation. USENIX Association, 2008. Cited on pages 1, 3, 4, 7, 10, and 16.
[19] Rodrigo Fonseca, Michael J. Freedman, and George Porter. Experiences with tracing causality in networked services. In INM/WREN ’10: Proceedings of the 1st Internet Network Management Workshop/Workshop on Research on Enterprise Monitoring, 2010. Cited on pages 1, 2, 3, 4, 5, 6, 8, 9, 10, 11, 12,13, 14, 16, 18, and 19.

[20] Rodrigo Fonseca, George Porter, Randy H. Katz, Scott Shenker, and Ion Stoica. X-Trace: a pervasive network tracing framework. In NSDI ’07: Proceedings of the 4th USENIX Symposium on Networked Systems Design and Implementation, 2007. Cited on pages 1, 2, 3, 4, 5, 6, 9, 10, 16, 18, and 19.

[21] Sanjay Ghemawat, Howard Gobio, and Shun-Tak Leung. e Google le system. In SOSP ’03: Proceedings of the 19th ACM Symposium on Operating Systems Principles, 2003. Cited on page 1.

[22] Graphviz – graph visualization soware. http://www.graphviz.org. Cited on page 19.

[23] Joseph L. Hellerstein, Mark M. Maccabe, W. Nathaniel Mills III, and John J. Turek. ETE: a customizable approach to measuring end-to-end response times and their components in distributed systems. In ICDCS ’99: Proceedings of the 19th IEEE International Conference on Distributed Computing Systems, 1999. Cited on pages 1, 3, 4, 14, and 16.

[24] Ruoming Jin, Chao Wang, Dmitrii Polshakov, Srinivasan Parthasarathy, and Gagan Agrawal. Discovering frequent topological structures from graph datasets. In KDD ’05: Proceedings of the 11th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, 2005. Cited on page 19.

[25] Soila P. Kavulya, Scott Daniels, Kaustubh Joshi, Matt Hultunen, Rajeev Gandhi, and Priya Narasimhan.Draco: statistical diagnosis of chronic problems in distributed systems. In DSN ’12: Proceedings of the 42nd IEEE/IFIP International Conference on Dependable Systems and Networks, 2012. Cited on pages 1 and 4.

[26] Vasileios P. Kemerlis, Georgios Portokalidis, Kangkook Jee, and Angelos D. Keromytis. libd: practical dynamic data flow tracking for commodity systems. In VEE ’12: Proceedings of the 8th ACM SIGPLAN/SIGOPS conference on Virtual Execution Environments, 2012. Cited on page 6.

[27] Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Videira Lopes, Jean-Marc Loingtier, and John Irwin. Aspect-oriented programming. In ECCOP’96: Proceedings of the 11th European Conference on Object-Oriented Programming, June 1997. Cited on page 5.

[28] Eric Koskinen and John Jannotti. BorderPatrol: isolating events for black-box tracing. In Eurosys ’08: Proceedings of the 3rd ACM SIGOPS European Conference on Computer Systems, 2008. Cited on page 4.

[29] Leslie Lamport. Time, clocks, and the ordering of events in a distributed system. Communications of the
ACM, 21(7), July 1978. Cited on page 6.

[30] Zhicheng Liu, Bongshin Lee, Srikanth Kandula, and Ratul Mahajan. NetClinic: Interactive visualization to enhance automated fault diagnosis in enterprise networks. In VAST ’10: Proceedings of the 2010 IEEE Symposium on Visual Analytics Science and Technology, 2010. Cited on page 14.

[31] Gideon Mann, Mark Sandler, Darja Krushevskaja, Sudipto Guha, and Eyal Even-dar. Modeling the Parallel Execution of Black-Box Services. In Proceedings of the 3rd USENIX Workshop on Hot Topics in Cloud Computing, 2011. Cited on pages 11 and 17.
[32] Matthew L. Massie, Brent N. Chun, and David E. Culler. e ganglia distributed monitoring system:design, implementation, and experience. Parallel Computing, 30(7), July 2004. Cited on page 1.

[33] Luc Moreau, Ben Cliord, Juliana Freire, Joe Futrelle, Yolanda Gil, Paul Groth, Natalia Kwasnikowska,
Simon Miles, Paolo Missier, Jim Myers, Beth Plale, Yogesh Simmhan, Eric Stephan, and Van den Bussche.
e open provenance model core specication (v1.1). Future Generation Computer Systems, 27(6), June
2010. Cited on page 19.

[34] Adam J. Oliner, Archana Ganapathi, and Wei Xu. Advances and challenges in log analysis. Communications of the ACM, 55(2), February 2012. Cited on page 14.

[35] Personal communication with Google engineers, 2011. Cited on page 3.

[36] Personal communication with researchers at Carnegie Mellon University, 2012. Cited on page 19.

[37] Patrick Reynolds, Charles Killian, Janet L. Wiener, Jerey C. Mogul, Mehul Shah, and Amin Vahdat. Pip:detecting the unexpected in distributed systems. In NSDI ’06: Proceedings of the 3rd USENIX Symposium on Networked Systems Design and Implementation, 2006. Cited on pages 1, 3, 4, 5, 6, 8, 9, 10, 14, 16, and 17.

[38] Patrick Reynolds, Janet L. Wiener, Jerey C. Mogul, Marcos K. Aguilera, and Amin Vahdat. WAP5:black-box performance debugging for wide-area systems. In Proceedings of the 15th ACM International World Wide Web Conference, 2006. Cited on pages 1 and 4.

[39] Raja R. Sambasivan, Ilari Shafer, Michelle L. Mazurek, and Gregory R. Ganger. Visualizing request-flow comparison to aid performance diagnosis in distributed systems. IEEE Transactions on Visualization and Computer Graphics (Proceedings Information Visualization 2013), 19(12), December 2013. Cited on pages 14, 18, and 19.

[40] Raja R. Sambasivan, Alice X. Zheng, Michael De Rosa, Elie Krevat, Spencer Whitman, Michael Stroucken,William Wang, Lianghong Xu, and Gregory R. Ganger. Diagnosing performance changes by comparing request ows. In NSDI’11: Proceedings of the 8th USENIX Conference on Networked Systems Design and Implementation, 2011. Cited on pages 1, 2, 3, 4, 5, 6, 8, 9, 10, 11, 12, 13, 14, 16, 18, and 19.

[41] Raja R. Sambasivan, Alice X. Zheng, Eno ereska, and Gregory R. Ganger. Categorizing and dierencing system behaviours. In HotAC II: Proceedings of the 2nd workshop on Hot Topics in Autonomic Computing,2007. Cited on page 2.

[42] Nino Shervashidze, Pascal Schweitzer, Erik Jan van Leeuwen, Kurt Mehlhorn, and Karsten M. Borgwardt.
Weisfeiler-lehman graph kernels. Journal of Machine Learning Research, 12, November 2011. Cited on
page 19.

[43] Benjamin H. Sigelman, Luiz A. Barroso, Michael Burrows, Pat Stephenson, Manoj Plakal, Donald Beaver,Saul Jaspan, and Chandan Shanbhag. Dapper, a large-scale distributed systems tracing infrastructure.Technical Report dapper-2010-1, Google, April 2010. Cited on pages 1, 2, 3, 4, 5, 6, 8, 9, 10, 11, 12, 13, 14, 16,17, and 19.
[44] Byung C. Tak, Chunqiang Tang, Chun Zhang, Sriram Govindan, Bhuvan Urgaonkar, and Rong N. Chang.
vPath: precise discovery of request processing paths from black-box observations of thread and network
activities. In USENIX ’09: Proceedings of the 2009 USENIX Annual Technical Conference, 2009. Cited on
pages 1 and 4.

[45] Jiaqi Tan, Soila P. Kavulya, Rajeev Gandhi, and Priya Narasimhan. Visual, log-based causal tracing for performance debugging of mapreduce systems. In ICDCS ’10: Proceedings of the 30th IEEE International Conference on Distributed Computing Systems, 2010. Cited on pages 1 and 4.

[46] e strace system call tracer. http://sourceforge.net/projects/strace/. Cited on page 1.

[47] Eno ereska, Brandon Salmon, John Strunk, Matthew Wachs, Michael Abd-El-Malek, Julio Lopez,and Gregory R. Ganger. Stardust: tracking activity in a distributed storage system. In SIGMETRICS ’06/Performance ’06: Proceedings of the Joint International Conference on Measurement and Modeling of Computer Systems, 2006. Cited on pages 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 16, 18, and 19.

[48] Brian Tierney, William Johnston, Brian Crowley, Gary Hoo, Chris Brooks, and Dan Gunter. e NetLogger methodology for high performance distributed systems performance analysis. In HPDC ’98: Proceedings of the 7th International Symposium on High Performance Distributed Computing, 1998. Cited on pages 1 and 9.

[49] Tracelytics. http://www.tracelytics.com. Cited on pages 1 and 19.

[50] Twitter Zipkin. https://github.com/twitter/zipkin. Cited on pages 1 and 19.

[51] Matthew Wachs, Lianghong Xu, Arkady Kanevsky, and Gregory R. Ganger. Exertion-based billing for cloud storage access. In HotCloud ’11: Proceedings of the 3rd USENIX Workshop on Hot Topics in Cloud Computing, 2011. Cited on page 4.

[52] William Wang. End-to-end tracing in HDFS. Technical Report CMU-CS-11-120, Carnegie Mellon University, July 2011. Cited on page 19.

[53] Wei Xu, Ling Huang, Armando Fox, David Patterson, and Michael Jordan. Detecting large-scale system problems by mining console logs. In SOSP ’09: Proceedings of the 22nd ACM Symposium on Operating Systems Principles, 2009. Cited on pages 1 and 4.

 

打賞支援我翻譯更多好文章，謝謝！

打賞譯者