Managed Service for OpenTelemetry：阿里雲端到端鏈路追蹤最佳實務

阿里雲端到端鏈路追蹤解決方案

阿里雲 ARMS（含Managed Service for OpenTelemetry）目前已經支援使用者終端（Web/Android/iOS等）-> 雲網關（ALB/MSE/Ingress/ASM等）-> 後端應用（Java/Go/Python/.NET等）-> 雲組件（資料庫、訊息、大模型等）的端到端全鏈路打通，如下圖所示。

鏈路插樁：Java/Go/Python等主流語言推薦 ARMS 自研探針，相容開源提升多語言覆蓋度

針對 Java/Go/Python 等主流語言，推薦接入 ARMS 自研探針提升鏈路插樁的品質、效能、穩定性和易用性。同時，為了更廣泛的支援其他語言，Managed Service for OpenTelemetry全面相容 OpenTelemetry、SkyWalking、Zipkin和Jaeger 4 種主流鏈路架構以及10+ 種多語言的鏈路插樁與資料上報，如下表所示。

ARMS 與Managed Service for OpenTelemetry資料完全互連，在多語言情境建議結合使用。

ARMS 2024年發布的 JavaAgent 4.0，全面擁抱 OpenTelemetry 生態，探針底座基於 OpenTelemetry 架構進行了全新升級，並額外提供多種資源監控、效能診斷、應用安全等資料。除了更豐富的資料，ARMS JavaAgent 4.0 還支援更加靈活的調用鏈採樣策略、白屏化探針管理、全方位自監控、動態功能降級等高階特性，更加適合企業級客戶的生產環境應用。

鏈路採集與加工：深度整合阿里雲生態，雲產品鏈路一鍵接入

企業上雲的一個痛點問題就是重度依賴雲產品服務可用性，端到端鏈路追蹤可以快速定位錯慢請求異常節點，提升故障快恢效率，降低業務損失。那麼如何接入雲產品的調用鏈路資料呢？

Managed Service for OpenTelemetry與阿里雲近10款雲產品深度合作，完成了雲產品內部鏈路插樁與資料上報。對於企業使用者來說，只需在相應的雲產品控制台一鍵啟用鏈路追蹤開關，就可以直接看到相應的調用鏈，大幅簡化了鏈路採集成本，ALB 網關、MSE 網關以及 ARMS 使用者體驗監控的鏈路追蹤接入效果如下圖所示 。

受限於產品特性，不同雲產品的鏈路插樁方案有所區別，配套的鏈路資料擷取大致分為兩類：

• Trace 直接/轉寄上報：以使用者體驗監控為例，內部實現鏈路插樁與 Exporter 直連上報，埋點更精細更靈活。

• 日誌資料轉 Trace：以 ALB 網關為例，後台消費訪問日誌，再轉義成 Trace 資料，侵入性更小。

兩種方案各有優劣，通常推薦 Trace 直連/轉寄上報，此種方案更規範。但是在效能要求高或者舊系統改造困難情境下，可以考慮日誌轉 Trace（前提條件是在日誌中添加 TraceId 等鏈路上下文）。

目前，已經支援接入鏈路追蹤的雲產品、協議及接入指南如下表所示。

鏈路上下文透傳：統一阿里雲端到端鏈路協議，自研探針相容多協議轉換

從單個應用組件的視角，完成鏈路插樁和資料擷取，能在控制台上看到對應的 Trace 資料就已經成功了。但是真正的端到端鏈路追蹤必須將上下遊的 Trace 以統一的協議進行串聯，保證不斷鏈，既有技術層面的挑戰，也有協同層面的困難。

目前阿里雲可觀測已經基於 OpenTelemetry W3C 協議實現端到端鏈路打通，後續將逐步覆蓋更多協議、更多組件的全鏈路透傳，構建更完整、更靈活的鏈路生態，完整端到端調用鏈如下圖所示。

相比於新應用接入 Trace，存量應用要實現端到端協議棧統一的挑戰會更大。特別是面臨新舊技術棧切換情境（比如 SkyWalking 遷移至 OpenTelemetry），既要保證存量營運體系持續可用，又要驗證新體系的有效性，如何相容兩種不同鏈路體系共存，是影響存量應用技術棧升級或鏈路打通的最大難題。

為瞭解決這個問題，ARMS 自研探針做了大量的相容性最佳化，最終實現了雙探針共存，保證兩套體系能夠同時正確、穩定運行，直至遷移完成，如下圖所示。

ARMS 自研探針支援多協議識別與透傳，在某些特殊情境，如果上下遊系統難以變更，可以通過 ARMS Agent 進行協議中轉，比如上遊 A 應用使用 Jaeger 協議 -> ARMS Agent（接收 Jaeger，向下透傳 Jaeger + Zipkin B3） -> 下遊 B 應用使用 Zipkin B3 協議，最終實現 TraceId 的透傳與打通。