Span Metrics#

上一章提到 Traces 可以衍生出 Metrics。這一章深入探討這個「鍊金術」：如何從 Trace 的 Span 資料中，自動產生出有用的服務層級指標，而不需要額外的 Metrics Instrumentation。

Metrics from Traces#

Span Metrics 的核心概念很直覺：每一個 Span 記錄了「誰在什麼時候做了什麼操作、花了多久、結果是成功還是失敗」。當你擁有大量的 Span 資料，把它們按照服務和操作名稱聚合起來，就能得到：

  • Request Rate：每個服務/操作每秒處理多少請求
  • Error Rate：其中有多少比例是失敗的
  • Duration Distribution：延遲的 P50、P90、P99 分佈

這就是經典的 RED Metrics（Rate、Error、Duration），也是評估微服務健康狀態最核心的三個指標。

為什麼這很有價值#

傳統做法是：你需要在應用程式中分別做 Tracing 和 Metrics 的 Instrumentation。Tracing SDK 產出 Span，Metrics SDK 產出 Counter 和 Histogram。兩套程式碼做的事情高度重疊——都在記錄請求的發生、成功/失敗、耗時。

Span Metrics 的價值在於：一份 Instrumentation，兩份產出。你只需要做好 Tracing，Metrics 就能自動衍生。這帶來幾個好處：

  • 減少 Instrumentation 維護成本：不用同時維護 Tracing 和 Metrics 兩套程式碼
  • 保證一致性：因為 Metrics 直接從 Trace 衍生，兩者的數字天然對齊
  • 降低上手門檻：團隊只需要學會一種 Instrumentation

Span Metrics 不是要取代所有的 Metrics Instrumentation。它擅長產出「服務健康狀態」的 RED Metrics，但業務指標（如訂單金額、庫存數量）和系統指標（如 CPU、記憶體）仍然需要獨立的 Metrics 來源。

OTel Collector 的角色#

Span Metrics 的轉換通常發生在 OpenTelemetry Collector 中，而不是在應用程式端。Collector 提供了 Span Metrics Connector（早期稱為 Span Metrics Processor），它攔截通過 Collector 的 Span 資料，即時計算聚合指標，然後將這些 Metrics 匯出到 Prometheus 或其他 Metrics 後端。

這個設計的好處是：

  • 應用程式完全無感：不需要修改任何應用程式程式碼，只需要調整 Collector 的設定
  • 集中管理：所有的聚合邏輯在 Collector 統一處理，方便調整維度和粒度
  • 靈活配置：可以選擇要對哪些 Attribute 做聚合、要不要包含自定義的 Span Attribute 作為 Metrics Label

選擇要聚合的維度時要謹慎。如果把高基數（High Cardinality）的 Attribute（如 User ID 或 Request URL）也加進去，會導致 Metrics 的 Cardinality 爆炸，造成 Prometheus 的效能和儲存問題。

Jaeger Service Performance Monitoring#

Jaeger SPM（Service Performance Monitoring）是 Span Metrics 的一個實際應用場景。Jaeger 利用 Span Metrics 衍生出的 RED Metrics，提供服務效能的概覽儀表板。

傳統的 Jaeger 介面專注於「查看單一 Trace」——你搜尋一個特定的 Trace，然後分析它的 Span。這很適合深入調查，但不適合回答「過去一小時 order-service 的整體表現如何」。

SPM 補上了這個缺口：

  • 服務總覽：所有服務的 Request Rate、Error Rate、P95 延遲一目了然
  • 操作排名：哪些操作最慢、哪些操作錯誤率最高
  • 趨勢分析：效能指標隨時間的變化趨勢

如果你的團隊已經部署了 Jaeger 做 Distributed Tracing，SPM 是一個低成本獲得服務效能概覽的方式。只需要在 OTel Collector 中啟用 Span Metrics Connector，就能為 Jaeger 提供所需的 Metrics 資料。

適用場景與注意事項#

Span Metrics 最適合的團隊畫像：

  • 已經做了 Tracing Instrumentation，但還沒有（或不想維護）獨立的 Metrics Instrumentation
  • 想要快速獲得服務層級的 RED Metrics，作為 SLO 監控或 Alert 的基礎
  • 希望減少 Instrumentation 的重複工作

需要注意的重要差異：

Span Metrics 是從取樣後的 Trace 資料衍生的。如果你的 Tracing Pipeline 設定了取樣率（例如只保留 10% 的 Trace），那麼衍生出的 Metrics 也只反映了這 10% 的資料。這與直接用 Metrics SDK 做的 Instrumentation 不同——後者記錄的是每一個請求，精確度更高。

如果你需要精確的 Metrics（例如用於計費、SLA 報告），不應該依賴 Span Metrics。它更適合作為「趨勢觀察」和「快速診斷」的工具。對精確度有要求的場景，仍然需要獨立的 Metrics Instrumentation。

一個常見的策略是：用 Span Metrics 作為起步，快速獲得可觀測性覆蓋；隨著系統成熟，再對關鍵路徑補上精確的 Metrics Instrumentation。兩者並存，各司其職。