Jaeger 的定位#

Jaeger 是 Uber 在 2016 年開源的分散式追蹤系統，受 Google Dapper 和 Twitter Zipkin 的啟發而設計，於 2019 年成為 CNCF 畢業專案。它是最早獲得廣泛採用的開源 Trace 後端之一，至今仍然是許多組織的首選。

Jaeger 的核心價值是完整且獨立：它自帶功能豐富的 Web UI、支援多種儲存後端、提供靈活的取樣策略，開箱即用就能提供端到端的分散式追蹤能力。

架構設計：每一層都可獨立擴展#

Jaeger 的架構採用經典的分層設計，每個元件職責明確：

  • Agent：部署在每個應用程式節點旁的輕量級進程，接收應用程式產生的 Span，做本地緩衝後轉發給 Collector。在 Kubernetes 環境中通常以 DaemonSet 或 Sidecar 形式部署
  • Collector：接收來自 Agent 的 Span 資料，做驗證和處理後寫入儲存後端。Collector 是無狀態的，可以水平擴展
  • Storage：支援多種後端，包括 Elasticsearch、Apache Cassandra、以及較新的 gRPC 外掛機制。儲存的選擇直接影響查詢能力和成本
  • Query + UI：提供 RESTful API 和 Web 介面，讓使用者搜尋和查看 Trace

近年 Jaeger 推出了 All-in-One 模式，將所有元件打包在單一二進位檔中，適合開發和測試環境。但在生產環境中，分層部署仍然是推薦做法，因為每一層的擴展需求不同——Collector 通常需要比 Query 更多的資源。

API 選擇的演進#

Jaeger 的 API 歷史反映了整個 Tracing 生態系的標準化進程：

  • 早期：Jaeger 有自己專屬的資料格式（Jaeger Thrift），Client SDK 直接用 Jaeger 的 API 送出資料
  • OpenTracing 時代：Jaeger 成為 OpenTracing 的參考實作，Client SDK 基於 OpenTracing API
  • OpenTelemetry 時代：Jaeger 全面擁抱 OTel，現在推薦直接使用 OTLP（OpenTelemetry Protocol）送出資料，不再需要 Jaeger 專屬的 Client SDK

如果你是新導入 Jaeger 的使用者，直接使用 OpenTelemetry SDK + OTLP 來送資料給 Jaeger。不要再用已經被棄用的 Jaeger Client SDK。這樣你的應用程式就能與儲存後端完全解耦——未來如果要從 Jaeger 換到 Tempo 或其他後端，只需要改 Exporter 的設定。

Sampling 策略#

高流量系統不可能追蹤每一個請求。Jaeger 提供了多種 Sampling 策略，讓你在可觀測性深度和效能開銷之間找到平衡：

  • Constant Sampling：固定取樣（全部追蹤或全部不追蹤），通常用在開發環境，方便除錯
  • Probabilistic Sampling：按機率取樣，例如設定 0.1 代表追蹤 10% 的請求。簡單有效，適合大多數場景
  • Rate Limiting Sampling：每秒最多追蹤 N 個請求。在流量波動大的環境中，這比 Probabilistic 更能控制成本
  • Remote Sampling：由 Jaeger Collector 集中控制取樣策略，各個服務定期拉取最新設定。這讓你可以在不重新部署的情況下動態調整取樣率

在生產環境中，Remote Sampling 是最靈活的選擇。想像一個場景：某個服務突然出現異常，你想把它的取樣率從 1% 調高到 100% 來抓問題。用 Remote Sampling，只需要在 Collector 端改設定，所有服務會自動套用新的策略，不需要重新部署任何東西。

Jaeger 的查詢能力#

Jaeger 的 UI 提供了直覺且強大的查詢介面：

  • 服務和操作篩選：按服務名稱和操作名稱搜尋 Trace
  • 時間範圍和延遲篩選：找出特定時間內、超過指定延遲的 Trace
  • Tag 搜尋：用 Span 的 Tag/Attribute 做條件篩選，例如 http.status_code=500
  • Trace 比較：同時查看兩條 Trace，對比它們的差異——這在排查「為什麼同一個 API 有時快有時慢」時非常有用
  • System Architecture（DAG）：自動生成服務之間的依賴關係圖

因為 Jaeger 對 Span 建了完整的索引，這些查詢的回應速度通常很快，即使資料量很大也能在秒級內回應。

Jaeger vs Tempo#

面向JaegerTempo
獨立 UI完整的 Web UI無（依賴 Grafana）
查詢速度快（有完整索引）依資料量而定（掃描式）
儲存成本較高（Elasticsearch/Cassandra）極低（物件儲存）
全量保存成本高，通常需要 Sampling成本低，可保存所有 Trace
Metrics 衍生需要額外工具內建 Metrics-generator
獨立性可獨立運作深度依賴 Grafana 生態系

什麼時候選 Jaeger？#

  • 需要獨立的 Trace UI：你的團隊不使用 Grafana，或者想要一個專門的 Trace 介面，不想把所有東西塞進同一個 Dashboard
  • 重視查詢速度和靈活性：你經常需要用各種條件搜尋 Trace，而不只是用 Trace ID 查詢
  • 已有 Elasticsearch 或 Cassandra：如果你的組織已經在運維這些儲存系統，Jaeger 可以直接利用現有的基礎設施
  • 需要 Trace 比較功能：在排查效能問題時，同時比較「正常」和「異常」的 Trace 是非常有價值的能力

Jaeger 和 Tempo 不是非此即彼的選擇。有些團隊會同時使用——用 Tempo 低成本保存全量 Trace 做為長期存檔，用 Jaeger 儲存近期的 Trace 提供快速查詢。OTel Collector 的多 Exporter 能力讓這種架構很容易實現。