Linkerd 2.6 版本正式支持分佈式跟蹤功能

我們很高興地宣佈Linkerd 2.6版本將正式迎來分佈式跟蹤支持功能!這意味着Linkerd數據平面代表現在可以進行範圍跟蹤,允許用戶查看各項請求在Linkerd代理中花費的確切時間。相信很多朋友都清楚,在實踐場景中實現分佈式跟蹤往往非常困難,因此在本文中,我們將結合參考架構,就如何通過Linkerd使用分佈式跟蹤功能爲您提供最佳實踐與建議。

內容概述

跟蹤無疑是分佈式系統性能調試中的一大重要工具,能夠幫助我們準確判斷系統中的性能瓶頸,以及各個組件的具體延遲成本。總而言之,分佈式跟蹤做出了重要的運營承諾;但根據我們的經驗,在實際場面中踐行這些承諾往往相當困難。

首先,分佈式跟蹤生態系統往往非常複雜,其中包含一系列令人眼花繚亂的項目,例如Zipkin、Jaeger、OpenTracing、OpenCensus、OpenTelemetry以及其他種種方案選項。各個項目之間還存在一定的功能交集,而且不同項目間的互操作效果也有所區別。可怕的是,即使是用於衡量這些互操作效果的指標,也足以令人感到頭暈目眩。

更糟糕的是,service mesh的介入進一步提高了決策的複雜程度。分佈式跟蹤與service mesh之間存在着功能交集,例如繪製應用程序拓撲結構的能力等。在另一方面,service mesh中的大多數功能無需變更代碼即可實現,但分佈式跟蹤卻往往會給代碼內容造成影響。

考慮到我們在Linkerd社區當中觀察到的各類實際問題,接下來的工作就非常明確了:我們不僅要在Linkerd 2.6版本當中“添加分佈式跟蹤”並保證其易用性,同時還要幫助大家瞭解如何在自己的實際Linkerd應用程序當中享受到這項功能帶來的便利。

Linkerd 2.6中的分佈式跟蹤

首先,讓我們先聊聊Linkerd中關於“分佈式跟蹤支持”的確切定義。說起來非常簡單:當Linkerd數據平面代理在一條代理轉發的HTTP請求中發現b3格式的跟蹤標頭時(後文會提到Linkerd中爲什麼會出現這種特殊的請求格式),Linkerd就會爲該請求發出跟蹤範圍。該範圍包含請求在Linkerd代理中所花費時間的確切信息,同時也將包含後續出現的其他一些信息。

就這麼簡單。大家可以看到,Linkerd在分佈式跟蹤中的作用相當清晰易懂。但爲了讓Linkerd的這一功能實際起效,最困難的其實在於滿足其他幾個配合性條件。

還有啥條件?要使用Linkerd的全新分佈式跟蹤功能,大家需要在系統中部署以下幾個組件:

  1. 一個入口層,用於立足特定請求啓動跟蹤功能。

  2. 一套應用程序客戶端庫。(您的應用程序代碼必須能夠傳播跟蹤標頭,在理想情況下最好還能發送自己的跨度信息。)

  3. 跟蹤收集器,用於收集跨度數據並將其轉換爲跟蹤操作。

  4. 跟蹤後端,用於存儲跟蹤數據並允許用戶進行查看/查詢。

演示部分

下面,讓我們看看參考架構中的分佈式跟蹤是如何工作的。接下來,我們會具體介紹每一個組件,並闡述如何在您自己的應用程序當中使用這些組件。首先,請確保您的Linkerd 2.6 CLI正常可用,且已經在集羣上安裝了Linkerd 2.6版本。如果尚未安裝,請首先安裝或者升級。

$ linkerd version

Client version: stable-2.6

Server version: stable-2.6

開始克隆參考架構庫:

git clone [email protected]:adleong/emojivoto.git && \

    cd emojivoto

接下來,我們需要安裝Jaeger與OpenCensus收集器。這些組件對於Linkerd來說非常重要,請確保它們能夠通過安全連接從Linkerd代理處接收跨度。

linkerd inject tracing.yml | kubectl apply -f -

最後,我們需要安裝Nginx入口控制器以及Emojivoto應用程序本體。由於我們利用Linkerd注入這些組件,因此能夠在跟蹤結果中看到Linkerd代理自身。

linkerd inject emojivoto.yml | kubectl apply -f - && \

    linkerd inject ingress.yml | kubectl apply -f -

在全部準備就緒之後,我們可以使用Jaeger儀表板對系統進行整體跟蹤。

kubectl -n tracing port-forward deploy/jaeger 16686 &; \

    open http://localhost:16686

完整跟蹤

Linkerd分佈式跟蹤參考架構

這套參考架構絕不是實現應用程序分佈式跟蹤的唯一方法,甚至不能算是最佳實踐方法,畢竟具體取決於您的應用程序情況以及實際需求。但這確實是個不錯的上手起點,而且無論是否配合service mesh都能提供良好的運行效果。

這套參考架構共包含四大組件,分別爲:作爲入口的Nginx,作爲客戶端庫的OpenCensus,作爲跟蹤收集器的OpenCensus以及作爲後端的Jaeger。我們將在後文中對各組件做出具體闡述。當然,這些組件也是可以替換的,我們將在對應部分介紹可以選擇不同的替代性選項。

入口: Nginx

入口對於分佈式跟蹤而言特別重要,因爲其負責爲每個跟蹤創建根跨度,並確定是否應該對該跟蹤進行採樣。由入口做出全部採樣決策,能夠確保我們對整個跟蹤流程進行採樣,或者完全不採樣,同時避免產生“部分跟蹤”問題。

分佈式跟蹤系統完全依靠服務來傳遞關於當前跟蹤活動的元數據,這些元數據涵蓋當前跟蹤接收到的請求及其發出的請求。我們將這些元數據稱爲跟蹤上下文,且通常將其編碼在一個或者多個請求標頭當中。跟蹤上下文標頭的格式多種多樣,但我們希望生態系統最終能夠逐步收斂爲開放標準,例如W3C tracecontext。在今天的示例中,我們只使用b3格式。作爲最早的使用格式之一,b3格式支持範圍最廣,特別是在Nginx這類入口中擁有良好的匹配效果。

這套參考架構包含一個簡單的Nginx config,該配置會對50%的跟蹤進行採樣並將跟蹤數據發送至收集器(僅代表和Zipkin協議)。當然,對於本示例而言,大家可以隨意選擇入口控制器來替換Nginx完成以下功能:

  • 支持概率抽樣。

  • 以b3格式編碼跟蹤上下文。

  • 在OpenCensus收集器支持的協議中擴展跨度。

客戶端庫: OpenCensus

雖然服務可以通過手動方式對傳播標頭進行傳播跟蹤,但直接使用具備以下三項功能的庫能夠極大簡化操作流程:

  • 將跟蹤上下文從傳入的請求標頭傳播至傳出的請求標頭。

  • 修改跟蹤上下文(即開始一個新跨度)。

  • 將此數據傳輸至跟蹤收集器。

我們建議大家使用OpenCensus,並使用以下配置:

OpenCensus代理導出器將通過gRPC API把跟蹤數據導出至OpenCensus收集器。具體OpenCensus配置方法因編程語言而異,這裏不再一一贅述。另外,大家也可以通過本示例中的Emojivoto查看Go語言的端到端展示。

大家可能會注意到,OpenCensus項目目前處於維護模式,並計劃後續被合併至OpenTelemetry項目當中。遺憾的是,目前OpenTelemetry尚未公佈生產就緒版本,因此當下最好的選擇仍然是OpenCensus。

收集器: OpenCensus

OpenCensus收集器負責接收來自OpenCensus代理導出器的跟蹤數據,並可能需要在將數據發送至Jaeger之前執行轉換與過濾操作。這種首先將OpenCensus導出器數據發送至OpenCensus收集器的作法,能夠爲我們提供顯著的靈活性優勢。這意味着我們可以切換至OpenCensus所支持的任意後端,而無需中斷應用程序運行。

後端: Jaeger

Jaeger是目前使用範圍最廣的跟蹤後端之一,其主要優勢包括:易於使用,且提供強大的跟蹤可視化能力。當然,大家也可以根據喜好改用OpenCensus所支持的任何其他後端。

Linkerd

如果您的應用程序已經注入Linkerd,那麼Linkerd代理也將參與跟蹤,並負責將跟蹤數據發送至OpenCensus收集器。這不僅豐富了跟蹤數據的內容,同時也允許大家準確查看請求在代理及網絡上具體花費了多少時間。要實現Linkerd介入,您需要:

  • 在希望介入跟蹤的命名空間或者pod規範中,對 config.linkerd.io/trace-collector 註釋進行設置。具體設置方法爲添加OpenCensus收集器服務的地址。在我們的參考架構中,該地址爲: oc-collector.tracing:55678。
  • 在希望介入跟蹤的命名空間或者pod規範中,對 config.alpha.linkerd.io/trace-collector-service-account 註釋進行設置。具體設置方法爲添加該收集器的服務賬戶名稱,從優同確保代理與收集器之間進行安全通信。如果您將收集器作爲默認服務賬戶運行,則可以省略這個步驟。參考架構就採取這種方法,因此直接省略。
  • 確保您希望發送跨度的pod已經注入有Linkerd代理。

  • 確保OpenCensus收集器已經注入有Linkerd代理。

雖然Linkerd目前只能主動參與使用b3傳播格式的跟蹤(如之前參考架構部分所述),但Linkerd會始終以透明方式轉發未知的請求標頭,意味着其永遠不會干擾到使用其他傳播格式的跟蹤活動。我們也有計劃進一步擴展Linkerd的傳播格式支持能力,大家敬請期待。

總結

希望我們的這套參考架構能夠幫助大家輕鬆理解分佈式跟蹤的整個流程與所涉及的具體組件,並掌握如何對自己的應用程序進行檢測。雖然這裏提出的參考架構並非實現分佈式跟蹤的唯一方法,但我們希望它能夠成爲各位用戶探索新功能的理想起點。如果您還有任何建議或者疑問,也請隨時與我們聯繫!

原文鏈接:

https://linkerd.io/2019/10/07/a-guide-to-distributed-tracing-with-linkerd/

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章