如何通過鏈路追蹤進行定時任務診

背景簡介

什麼是定時任務

定時任務是業務應用系統中存在定時週期性運行的業務邏輯。由於其運行於後端進程中往往存在執行狀態和執行鏈路的不可見性《常見定時任務技術方案》。

什麼是鏈路追蹤

隨着分佈式微服務化架構在企業中大規模運用,業務運行的應用平臺是一個由各個業務研發團隊不同業務應用組合而成的龐雜系統工程,相互之間存在各種形式的訪問交互。'

面對上述如此複雜的系統結構,對於業務入口端應用而言所有的下游服務狀態都是黑盒不可知的存在。相應的運維問題也隨之而來:

  • 入口服務不可用時,如何快速定位具體是哪個服務節點不可用及原因?
  • 如何快速定位分析業務鏈路中性能瓶頸點?
  • 如何掌控業務鏈路完整執行過程?

面對上述問題,從Google分佈式鏈路追蹤系統的Dapper論文開啓了各類分佈式鏈路追蹤的實現,出現了很多相關係統,如:Zipkin、Skywalking、Pinpoint。所有這些其核心邏輯就是在一次業務請求開始時構建相應請求的鏈路上下文信息,並在服務調用過程中透傳完善相應的鏈路節點信息,最終通過該請求TraceId(本次請求的鏈路標識)和每個節點父子依賴關係構建出一個完整的調用鏈數據結構。

整個分佈式全鏈路追蹤平臺各項主要分工:

  • 應用側完成服務調用埋點,常見方式:手動調用SDK埋點、java agent模式自動埋點
  • 服務之間通信交互,相應通信協議上需要添加Trace信息進行傳遞,保證在整個調用鏈中Trace信息共享
  • Trace信息上報至全鏈路追蹤平臺進行存儲展現

基於上述幾個主要環節,各個開源方案分別實現了各自在採集、傳輸、存儲環節的不同數據結構。爲實現鏈路追蹤領域範圍內數據結構統一,出現了OpenTracing和OpenTelemetry來定義相應的規範和協議。

爲什麼定時任務需要鏈路追蹤

分析任務爲什麼執行失敗

當業務不斷髮展,業務開發的定時任務也會越來越趨於複雜化,定時任務執行過程中會發展出如下各種形態:

  • 會調用其他業務方各類下游應用服務
  • 會調用其他中間件服務(如:redis、mq等)
  • 會切分出N個子任務分發給不同機器進行分佈式並行批處理,每個子任務處理又是一整套複雜組合

當面對此類複雜定時任務場景下任務執行如果出現異常,相應的問題定位將變得很複雜。在完整的全鏈路追蹤能力支持下,問題將能被快速定位處理。

分析任務爲什麼執行慢

一般場景下離線任務往往承擔着大批量數據處理的業務場景,因而很多定時離線任務有運行耗時長的特徵,往往在這些耗時長的任務上存在着巨大的性能優化空間,性能提升能直接優化基礎資源使用效率並節省業務成本

在任務調度平臺上我們可通任務執行超時報警,再結合任務執行鏈路追蹤能力可有效地鎖定業務處理的耗時瓶頸點供進一步業務性能優化作爲參考。

全鏈路流量控制

在全鏈路追蹤體系下,可以進行後續其他能力拓展:

  • 灰度發佈:定時任務應用發佈過程中的任務全鏈路灰度能力
  • 全鏈路壓測:定時任務通過業務測試標籤參與全鏈路壓測
  • 流量隔離:定時任務調用下游服務,下游服務根據流量來源進行隔離處理

定時任務鏈路追蹤解決方案

開源解決方案

從開源定時任務平臺看,目前常見開源方案都未支持任務執行鏈路可視化查詢,對複雜任務或分片任務執行異常下的問題分析會比較困難。

另外在開源鏈路追蹤平臺,對應開源方案中部分採集端agent集成了定時任務框架執行入口埋點採集,但該模式下與任務調度平臺側較爲割裂,從負責定時任務運維的視角出發想具體鎖定某一次任務執行鏈路,需要通過日誌或根據執行時間檢索匹配相應的執行記錄,當鏈路追蹤平臺上數據繁多想快速唯一鎖定目標鏈路存在很多不便。

阿里解決方案

阿里分佈式任務調度平臺SchedulerX提供了一站式的鏈路追蹤解決方案,可以將任務執行信息與鏈路追蹤Trace信息綁定,用戶可以很方便的從任務調度側,查看某個任務、某次執行、某個分片的完整調用鏈。

阿里SchedulerX方案優勢

  • 精準定位任務執行Trace信息:常見鏈路追蹤平臺只負責任務執行的時候生成traceId,不提供和具體任務的綁定關係,想要從成千上萬的traceId中分析某個任務的調用鏈變得非常複雜;SchedulerX無論是單機任務還是分佈式任務的某個分片,每一次調度都能快速定位到調用鏈。
  • 調度側支持控制採樣率:手動運行一次支持必採樣、動態配置採樣率。
  • 免運維低成本:通過EDAS部署的Java業務應用天然支持定時任務Trace能力,無需自建鏈路追蹤服務端平臺和agent採集,降低業務成本,並且可以從任務調度側一鍵跳轉到調用鏈。

定時任務鏈路追蹤客戶案例

某電商業務定位任務執行慢

用戶案例:目前電商業務場景下都基於微服務架構體系,定時任務運行涉及的應用較多且鏈路較深,用戶對某個任務運行慢時,希望能快速定位哪個業務應用方哪個業務功能是執行鏈路瓶頸點。

以下將展示如何分析任務的執行耗時,任務觸發執行後會調用多次下游業務應用服務以完成整個業務邏輯,整個任務執行耗時較長。

如上圖所示,常規情況下一次執行<5秒,但最近兩次次執行耗時>15s,通過任務配置超時報警可監測到該執行記錄超過預期執行時間,對該執行記錄的調用鏈路進入下一步分析。

如上圖所示,通過鏈路追蹤自動跳轉獲取完整調用鏈(同樣自建平臺者可拷貝TraceId查詢鎖定),從上圖可分析獲得執行耗時佔比較高的業務應用和IP,可鎖定在下游業務應用ServiceApplication的保存用戶信息服務出現明顯耗時。

某金融賬戶批處理定位執行異常

用戶案例:某金融機構對老業務系統升級,需將所有客戶賬戶信息進行定期批量遷移升級處理至新系統,每天會從老系統中加載一批次賬戶信息在業務集羣中分發處理,完成每個賬戶信息升級遷移;當某個賬戶出現異常時,需要能快速定位執行異常的位置和原因。

通過SchedulerX的MapReduce模型進行分佈式跑批,每個子任務對應一個客戶賬戶信息業務處理,可展示每個子任務的執行列表,並提供鏈路追蹤、重跑、日誌查看等功能。

如上圖所示,當整個任務執行出現異常失敗,進入子任務列表鎖定失敗的子任務(如:賬號1000002處理失敗)。

如上圖所示,通過鏈路追蹤自動調整至該子任務的完整執行調用鏈(自建平臺可拷貝TraceId查詢鎖定),可快速定位業務處理異常位置所在的業務應用和IP。

如上圖所示,展開失敗節點詳情即可進一步獲取失敗內容信息(如案例:賬號1000002在更新名稱信息時字段超長),至此一個分佈式批處理任務且存在多方服務調用的業務執行異常即可被快速定位。

某遊戲業務分析Http執行鏈路

用戶案例:某遊戲業務系統中其內部採用了C++、Go等技術棧,SchedulerX未提供相應語言SDK直接接入,用戶則通過暴露http服務方式接入SchedulerX定時觸發運行,並支持其實現http任務執行完整調用鏈查看。

以下展示一個http服務被定時調度後,其內部還會進行下游多個應用業務服務調用。

通過上述執行鏈路即可獲得一個http定時任務在整個業務集羣中完整的執行鏈路。如果單純在鏈路追蹤平臺上來查詢該http服務的調用鏈路時,往往會羅列一堆請求記錄且無法快速區分是否是某個定時任務觸發而來的。因此對比上述方式,對任務調度平臺側運維定時任務執行狀況的場景下,SchedulerX提供了更爲清晰的任務執行鏈路追蹤分析入口。

總結

分佈式任務調度平臺SchedulerX有效地將用於微服務場景下的可視化全鏈路追蹤能力引入至定時任務處理場景,這將大大提升定時任務在運行時可觀測能力,有效地幫助定時任務執行過程中異常、耗時、執行卡住等問題的定位分析。

原文鏈接

本文爲阿里雲原創內容,未經允許不得轉載。

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