Tempo 的核心理念#

Grafana Tempo 是一個只靠 Trace ID 查詢、不需要索引的 Trace 儲存後端。 這個設計決策看似極端，卻帶來了根本性的成本優勢。

傳統的 Trace 後端（如 Jaeger 搭配 Elasticsearch）會對 Span 的各種屬性建立索引，讓你可以用「service=order-api AND http.status_code=500」這樣的條件搜尋。但索引是有代價的——它需要大量的運算資源和儲存空間，而且隨著 Trace 資料量增長，索引的成本會快速膨脹。

Tempo 的做法正好相反：把所有 Trace 資料直接寫進物件儲存（S3、GCS、Azure Blob），不建索引。需要查詢時，你要嘛提供 Trace ID 直接撈，要嘛靠 TraceQL 在資料上做搜尋。

Tempo 的設計哲學和 Loki 如出一轍：Loki 只索引 Label 不索引日誌內容，Tempo 只靠 Trace ID 不建欄位索引。兩者都選擇了「用查詢靈活性換取成本優勢」的策略。如果你理解 Loki 的取捨，就能直覺地理解 Tempo。

「全都要」的經濟學#

Tempo 標題裡的「全都要」不是開玩笑。因為儲存成本極低，很多團隊選擇保存 100% 的 Trace 而不做取樣。

這翻轉了傳統 Tracing 的思維。過去你被迫做 Sampling——只追蹤 1% 或 10% 的請求，因為儲存全部的 Trace 太貴了。但 Sampling 意味著你可能漏掉那個只出現一次的關鍵錯誤。

用 Tempo + 物件儲存，每 GB 的月成本只有幾美分。你可以保存所有 Trace，保留幾週甚至幾個月，需要時再回頭查。

「全量保存」不代表「全量傳輸」。即使你想保存所有 Trace，仍然需要考量應用程式到 Collector 這段路徑的傳輸開銷。常見的做法是在 OTel Collector 層做輕量的 Head-based Sampling 來控制傳輸量，然後把通過取樣的 Trace 全部送進 Tempo。

TraceQL：專為 Trace 設計的查詢語言#

沒有索引不代表沒有搜尋能力。TraceQL 是 Tempo 自己的查詢語言，讓你用 Span 屬性來搜尋 Trace。

TraceQL 的設計靈感來自 PromQL 和 LogQL，如果你已經熟悉 Grafana 生態系的查詢語言，上手會很快。它支援：

  • 根據 Span 屬性搜尋：例如找出所有 HTTP 500 錯誤的 Trace
  • 跨 Span 的條件組合：例如找出「同時包含慢資料庫查詢和錯誤回應」的 Trace
  • 結構化查詢：根據 Span 之間的 Parent-Child 關係來篩選

TraceQL 搜尋需要掃描大量資料，查詢速度取決於時間範圍和資料量。縮小時間範圍是提升查詢效能最直接的方式。對於需要即時搜尋的場景，Tempo 可能不如有完整索引的後端來得順暢。

Metrics-generator：從 Trace 自動衍生 Metrics#

Tempo 有一個極為實用的功能：Metrics-generator。它從收到的 Trace 資料中自動衍生出 Metrics，送到 Prometheus 或 Mimir 儲存。

主要衍生出兩類 Metrics：

  • Span Metrics：每個服務的請求速率、錯誤率、延遲分佈（也就是 RED Metrics），不需要在應用程式端額外埋點
  • Service Graph Metrics：服務之間的調用關係和延遲，可以在 Grafana 中自動生成服務拓撲圖

這解決了一個常見的痛點：同樣的資訊不需要埋兩次。以前你要在 Prometheus 埋 HTTP 延遲 Metrics，又要在 Tracing SDK 產生 Span，兩邊記錄的其實是同一件事。有了 Metrics-generator，只要有 Trace 資料，Metrics 就自動產生。

Metrics-generator 產生的 Metrics 依賴於 Trace 的完整性。如果你在 Collector 層做了 Sampling（例如只保留 10% 的 Trace），衍生出來的 Metrics 也只反映這 10% 的資料，數值可能有偏差。想要準確的 Metrics-generator 結果，最好搭配全量或高比例的 Trace 保存。

Tempo vs Jaeger#

面向TempoJaeger
儲存成本極低（物件儲存）較高（需要 Elasticsearch/Cassandra）
索引策略不建索引完整索引
搜尋能力TraceQL，需掃描資料豐富的結構化查詢，速度快
內建 UI無（依賴 Grafana）完整的獨立 UI
生態系整合深度整合 Grafana、Loki、Mimir獨立運作，也可整合 Grafana
Metrics 衍生內建 Metrics-generator需要額外工具

什麼時候選 Tempo？#

  • 已經在用 Grafana 生態系：Tempo 與 Grafana、Loki、Mimir 的整合是最深的，跨信號關聯幾乎是一鍵完成
  • 成本敏感：你的 Trace 資料量很大，但不想為了儲存它們投入大量的基礎設施預算
  • 全量保存的需求：你希望保留所有 Trace 而不做取樣，以便事後回溯任何問題
  • 不需要複雜的即時搜尋：大部分的使用場景是「從 Log 或 Metrics 拿到 Trace ID，然後查看完整的追蹤鏈」，而不是在 Trace 資料上做複雜的 Ad-hoc 查詢