什麼是分散式追蹤?從 Trace 到落地方案

Distributed tracing(分散式追蹤)講清:trace/span/trace ID 三個概念,點解微服務一定要靠佢搵樽頸,同 OpenTelemetry 落地四步。香港團隊適用。

最佳實務
什麼是分散式追蹤?從 Trace 到落地方案

Distributed tracing(分散式追蹤)是一種記錄單一請求(request)橫跨多個服務全過程的技術:為每個請求配一個 trace ID,沿途逐段記下耗時與狀態,最後串成一條完整路徑。 有了它,「呢單交易點解慢咗 800ms、卡喺邊個服務」可以由估估下變成一眼睇清。在微服務(microservices)架構下,這是定位效能樽頸(bottleneck)幾乎唯一可靠的方法。

首次出現的術語我們會用「英文 + 繁中釋義」,之後保留英文(業界慣用)。所以下文會直接用 trace、span。

點解微服務一定要靠佢

單體應用(monolith)時代,一個請求入到伺服器,慢就看那台機的日誌。微服務之後,同一個請求會穿過負載均衡器(load balancer)、API gateway、幾個後端服務、訊息佇列(message queue)和資料庫——任何一環慢了,用戶體驗就受損,但每台機器的指標可能全部正常。

這就是 monitoring(監控)和 tracing 的分工:monitoring 話你知「系統有冇事」,tracing 話你知「事喺邊度」。詳細分別見 什麼是可觀測性

核心概念三個:Trace、Span、Trace ID

術語 繁中釋義
Trace 一個請求由頭到尾的完整旅程,橫跨多個服務
Span Trace 裏面的一段操作,例如一次 SQL 查詢、一次對外 API 呼叫;帶有耗時、狀態、屬性(metadata)
Trace ID 串連同一請求所有 span 的唯一識別碼;各服務接力傳遞(context propagation)

將所有 span 按時間排開,就是一張 waterfall(瀑布)圖:哪個服務最慢、哪段 SQL 卡了幾百毫秒、哪個外部呼叫 timeout,一目了然。這是 troubleshooting 時最有用的一張圖。

延伸閱讀APM 應用程式效能監控完整指南:從 Trace 到告警

點樣落地:OpenTelemetry 四步

現時的標準做法是用 OpenTelemetry(OTel) 採集 trace——開源、免供應商鎖定(vendor lock-in),之後換平台只需改數據出口。

  1. 計裝(instrumentation):在服務加入 OTel SDK 或自動計裝 agent,讓每個請求產生 trace。
  2. 經 Collector 中轉:trace 先送到 OTel Collector 做批處理、遮罩(masking)與轉發,而不是直送後端。
  3. 送到後端(backend):揀一個平台儲存與展示 waterfall 圖。完整的雙寫(dual-write)YAML 範例見英文版 Datadog to OpenTelemetry
  4. 採樣(sampling)與關聯:高流量時按錯誤/延遲做 tail-based sampling 控制成本,並把 trace ID 寫入日誌,令 trace 與 log 互相跳到。

部署後如果 trace 無出現,常見是採樣設錯、埠號搞錯(4317 gRPC vs 4318 HTTP)或 pipeline 無宣告——逐步排查清單見英文版 OpenTelemetry Not Showing Traces

與 APM 的關係

Distributed tracing 是 APM(應用程式效能監控)的核心技術:APM 用 trace 加上 RED 指標(Rate/Errors/Duration)組成完整的效能視圖。可以這樣記——tracing 是「方法」,APM 是「用這個方法做成的產品」。選型與收費見 APM 應用程式效能監控完整指南

延伸閱讀Datadog 替代方案 7 選(2026):成本、功能與選型比較

常見問題

Q. Distributed tracing 同 logging 有咩分別?
Log 是逐條事件記錄,詳細但散落各機;trace 把同一請求跨服務的段落串成一條線。查跨服務慢查詢時,log 話你知「某服務報錯」,trace 話你知「呢單請求由入到出邊段慢」。兩者靠 trace ID 關聯先至好用。

Q. 導入 tracing 會拖慢系統嗎?
現代 OTel SDK 的開銷一般在 1–5%(因語言與採樣設定而異)。用非同步批次上報加上合理採樣率,對大多數系統影響可以接受,建議先在測試環境做負載測試。

Q. 一定要成日用 OpenTelemetry 嗎?
不是必須,但係主流。OTel 的好處是計裝一次,日後換平台只改 Collector 的 export 設定,唔使改程式。呢個係避免 vendor lock-in 的標準做法。

Q. 小團隊值得做嗎?
服務數量少、冇跨服務呼叫的話,基本 log + metrics 已夠。當你開始有「一個請求要過幾個服務」、而排障要靠估的時候,就係引入 tracing 的訊號。

下一步

取得專屬方案

聯絡我們

加入社群

微信扫码
加入官方交流群

立即體驗

在线开通,按量计费,真正的云服务!

立即開始

选择观测云版本

代码托管平台