高擴展性

Jaeger 後端設計為沒有單點故障，並能隨著業務需求擴展。例如，在 Uber 的任何特定 Jaeger 安裝通常每天處理數十億個 span。

原生支援 OpenTracing 和 OpenTelemetry

Jaeger 後端、Web UI 和檢測函式庫從頭開始設計，以支援 OpenTracing 標準。

• 通過 span 引用  以有向無環圖 (而不僅僅是樹狀結構) 表示追蹤
• 支援強型別 span 標籤 和結構化日誌

自 v1.35 起，Jaeger 後端可以使用原生 OpenTelemetry 協定 (OTLP)  接收來自 OpenTelemetry SDK 的追蹤資料。但是，內部資料表示和 UI 仍然遵循 OpenTracing 規格的模型。

多個儲存後端

Jaeger 可以與越來越多的儲存後端一起使用

• 它原生支援流行的開源 NoSQL 資料庫作為追蹤儲存後端：Cassandra 3.4+、Elasticsearch 7.x/8.x 和 OpenSearch 1.0+。
• 它透過 gRPC API 與其他已認證符合 Jaeger 標準的知名資料庫整合：ClickHouse  。
• 使用 Badger  提供嵌入式資料庫支援，以及用於測試設定的簡單記憶體儲存。
• 目前有使用其他資料庫的社群實驗；您可以在 此議題  中找到更多資訊。

現代 Web UI

Jaeger Web UI 使用 React 等流行的開源框架以 Javascript 實作。v1.0 中發佈了多項效能改進，以允許 UI 有效處理大量資料並顯示具有數萬個 span 的追蹤 (例如，我們嘗試了一個具有 80,000 個 span 的追蹤)。

雲端原生部署

Jaeger 後端以 Docker 映像的集合形式發佈。這些二進位檔支援各種配置方法，包括命令列選項、環境變數和多種格式 (yaml、toml 等) 的設定檔。透過 Kubernetes Operator  和 Helm 圖表  可以協助部署到 Kubernetes 叢集。

可觀測性

所有 Jaeger 後端元件預設都會公開 Prometheus  指標。日誌使用結構化日誌函式庫 zap  寫入 stdout。

與 Zipkin 的回溯相容性

雖然我們建議使用 OpenTelemetry 檢測應用程式，但如果您的組織已經在使用 Zipkin 函式庫進行檢測方面進行了投資，則不必重寫所有程式碼。Jaeger 透過接受 HTTP 上的 Zipkin 格式 (Thrift、JSON v1/v2 和 Protobuf) 的 span，提供與 Zipkin 的回溯相容性。從 Zipkin 後端切換只是將流量從 Zipkin 函式庫路由到 Jaeger 後端的問題。

拓撲圖

Jaeger UI 支援兩種服務圖類型：系統架構和深度依賴圖。

系統架構

架構中觀察到的所有服務的「經典」服務相依性圖。此圖僅表示服務之間的一跳相依性，類似於從服務網格產生的遙測數據中獲得的資訊。例如，圖表 A - B - C 表示在 A 和 B 之間存在一些包含網路呼叫的追蹤，以及在 B 和 C 之間存在一些包含呼叫的追蹤。但是，這並不表示存在任何包含完整鏈 A - B - C 的追蹤，也就是說，我們不能說 A 相依於 C。

此圖的節點粒度僅限於服務，而不是服務端點。

系統架構圖可以從記憶體儲存中即時建立，或者在使用分散式儲存時使用 Spark 或 Flink 作業建立。

深層相依性圖

也稱為「遞移相依性圖」，其中鏈 A -> B -> C 表示 A 對 C 具有遞移相依性。單個圖表需要一個「焦點」服務（以粉紅色顯示），並且僅顯示通過該服務的路徑。通常，除非存在一個與所有事物連接的服務（例如 API 閘道），並且它被選為焦點服務，否則此類型的圖表不代表系統的完整架構。

此圖的節點粒度可以在服務和服務端點之間切換。在後者模式下，同一服務中的不同端點將顯示為單獨的節點，例如 A::op1 和 A::op2。

目前，遞移圖只能從搜尋結果中的追蹤建構。未來將有一個 Flink 作業，它將透過匯總所有追蹤來計算圖表。

服務效能監控 (SPM)

以 RED（請求、錯誤、持續時間）指標的形式視覺化匯總的 span 資料，以突出顯示具有統計顯著請求/錯誤率或延遲的服務和/或操作，然後利用 Jaeger 的追蹤搜尋功能來精確定位屬於這些服務/操作的特定追蹤。

請參閱 服務效能監控 (SPM) 以了解更多詳細資訊。