如何通過鏈路追蹤進行定時任務診斷
作者：千習
背景簡介
什麼是定時任務
定時任務是業務應用系統中存在定時週期性執行的業務邏輯。由於其運行於後端程序中往往存在執行狀態和執行鏈路的不可見性《常見定時任務技術方案》。
什麼是鏈路追蹤
隨著分散式微服務化架構在企業中大規模運用，業務執行的應用平臺是一個由各個業務研發團隊不同業務應用組合而成的龐雜系統工程，相互之間存在各種形式的訪問互動。
面對上述如此複雜的系統結構，對於業務入口端應用而言所有的下游服務狀態都是黑盒不可知的存在。相應的運維問題也隨之而來：
- 入口服務不可用時，如何快速定位具體是哪個服務節點不可用及原因？
- 如何快速定位分析業務鏈路中效能瓶頸點？
- 如何掌控業務鏈路完整執行過程？
面對上述問題，從 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 有效地將用於微服務場景下的視覺化全鏈路追蹤能力引入至定時任務處理場景，這將大大提升定時任務在執行時可觀測能力，有效地幫助定時任務執行過程中異常、耗時、執行卡住等問題的定位分析。
相關連結
[1] 分散式任務排程 SchedulerX 接入全鏈路追蹤
https://help.aliyun.com/document_detail/450856.html
[ 2] 企業級分散式應用服務 EDAS
https://help.aliyun.com/document_detail/450856.html
[ 3] 應用實時監控服務 ARMS