Part 4：Traces── 串連微服務的請求旅程#

在可觀測性的三大支柱中，Traces 是最年輕的一根，卻對微服務架構最為關鍵。Metrics 告訴你「有多少請求出了問題」，Logs 告訴你「單一服務裡發生了什麼事」，而 Traces 則回答最難的那個問題：一個請求從進入系統到回應完成，中間到底經過了哪些服務、每一段花了多久？

當你的系統從一個 Monolith 拆成十幾個微服務，傳統的 Stack Trace 在進程邊界就斷了。Distributed Tracing 把跨服務的調用鏈重新接起來，讓你像 X 光一樣透視整個請求路徑。

這個 Part 將帶你走過 Traces 的完整旅程：

• Ch 14 – Traces 緒論：分散式追蹤的本質、核心概念（Trace、Span、Context Propagation），以及從 Dapper 到 OpenTelemetry 的發展歷程
• Ch 15 – OpenTelemetry SDK：Zero-code Instrumentation 的威力，不改一行程式碼就能產生 Trace
• Ch 16 – Tempo：Grafana 生態系的 Trace 儲存後端，用物件儲存壓低成本，全量保存不取捨
• Ch 17 – Jaeger：Uber 開源的老牌追蹤系統，完整 UI 與豐富查詢能力
• Ch 18 – OpenTelemetry Collector：可觀測性管道的中間層，解耦應用程式與儲存後端

如果你已經在用 Grafana 生態系，Tempo 會是最自然的選擇。如果你需要獨立的 Trace UI 和豐富查詢，Jaeger 值得考慮。無論選哪個後端，OpenTelemetry Collector 都是推薦的中間層——它讓你未來換後端的成本趨近於零。