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

阿里云 ARMS（含可觀測鏈路 OpenTelemetry 版）目前已經支持用戶終端（Web/Android/iOS等）-> 云網關（ALB/MSE/Ingress/ASM等）-> 后端應用（Java/Go/Python/.NET等）-> 云組件（數據庫、消息、大模型等）的端到端全鏈路打通，如下圖所示。

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

針對 Java/Go/Python 等主流語言，推薦接入 ARMS 自研探針提升鏈路插樁的質量、性能、穩定性和易用性。同時，為了更廣泛的支持其他語言，可觀測鏈路 OpenTelemetry 版全面兼容 OpenTelemetry、SkyWalking、Zipkin和Jaeger 4 種主流鏈路框架以及10+ 種多語言的鏈路插樁與數據上報，如下表所示。

ARMS 與可觀測鏈路 OpenTelemetry 版數據完全互通，在多語言場景建議結合使用。

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

鏈路采集與加工：深度集成阿里云生態，云產品鏈路一鍵接入

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

可觀測鏈路 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 的透傳與打通。